Sunday, July 27, 2008

How to Delay First Impressions of Google App Engine

Most of the buzz about the App Engine has died down, except among the developers actually using the platform. When the first public announcements were made, I was a part of the original group of developers first given access. This privilege was wasted. I did nothing with it. This has changed, which is a topic for a different post. I thought I'd take a moment to make my mark on the "What I think about Google App Engine" wall.

A proper review is difficult, for a number of reasons. Namely, there is a very vague understanding of the difference between this "Preview Release" and what we'll have when it launches with all official status and commercial potential. We can only hope that any big changes won't interfere with our existing applications. If that does happen then existing players might turn to AppDrop for help, although any mass migration is highly doubtful. In any case, what everyone is talking about is what App Engine is now, not what it might turn into at some unknown point. (As a side note, it would be really great if that point was less unknown!)

What is a review of App Engine really about? Their choice of included libraries, as well as the promotion of Django templates into such a defacto standard (already having Guido's blessing) is one thing to talk about. The differences between BigTable and traditional relational databases is a big topic of debate. We can discuss the development server and deployment method, as well as the control panel available to us, if we want to focus away from the actual programming for a moment. In the end, what we really need to care about is the thing Google set out to solve: experience.

They changed the experience in two meanings of the word. A less experienced developer can now make a successful launch. All developers can have a much better experience. The experience, both in history and present, is of the full cycle of development. App Engine isn't doing anything for writing code. That is all low-bar when you look at the tools they use that were already available and in wide-use, like Python and Django. The value added spice of App Engine is what you do when you aren't writing code.

People complain about the choice of language, if they aren't already Python lovers. Some people just don't like the choice of included template system. There are complaints about BigTable in App Engine and its problems compared to a "normal" database. These debates are all bunk. People are complaining about the very things that don't matter one bit. In the end, we might develop a hundred libraries for doing the same thing, because we all think we know the slightly better way to do it, but App Engine exposes our primary flaw: we're developers. We're great at solving problems, building solutions, and writing code. We run out of steam when it comes to doing something with it. Our problem solving desire is a largely academic one.

If a software developer solved world hunger, he would blog about it and move on to the next project.

App Engine would read that post and actually go out and implement the solution the developer forgot about. It does a great job at what it solves, and I love using it. What I'm doing with it and why not enough developers care about it are both stories for other posts.

Friday, July 25, 2008

How to Defend Twitter's Spam-Fighting Follow Throttling

So, the twittersphere is in an uproar about those dropped follower counts. Is everyone more afraid of the lost high-count vanity or that so many people follow without thought that we might never regain many of the legitimate follows? Either way, there is a lot of complaining about the apparently service mishap from the company that we shell over so none of our hard earned dollars to. The mistake is one thing, but I see quite a bit of sentiment against the very method they undertook to combat the spam problem. I challenge that claim, because I think they're on the right track limiting follows, and I'm going to explain why.

For Popular People This Means...


You're popular by how many people follow you, not the other way around. You can go on your way, with thousands of people hanging on your every toilet flush, and Twitter can still limit those damn spammers from following you along with ten-thousand other ego filled, txt-fingered masters of the twitterverse.

For "Community Managers" This Means...

Now, ReadWriteWeb makes a claim that so-called "community managers" are harmed by these changes. Examples include Comcast, JetBlue, and Pandora, who use Twitter to keep in touch with their customer base. Now, kudos to some random guy at each of these corporations signing up under his employer's name. However, a reasonable use case falling under this category of twitter account just shouldn't be worried with how many people they can follow. Just like the populars, its all about how many people are listening to you, because what those peasents have to say doesn't even register to you.

No one is reading closely to a timeline filled by thousands of follows!

For Spammers This Means...

Don't follow thousands of people when only a couple dozen morons fall for your bullshit.

For Twitter This Means...

Discourage the need for any legitimate uses of massive follow lists, you blue bird lovers. The value of following anyone breaks down soon after hitting three digits, so figure out why people are doing that in the first place. There is a small set of reasons that are even conceivably plausible.

Heavy twitter users who have migrated over to IM or TXT based usage may have discovered a nearly hidden feature about your follow lists: it is two tiered. That's right, you have important people and everyone else, but this is only revealed if you start to use IM or TXT and filter the updates you get, likely to reduce phone charges. I found a different usage, because limiting the updates was great, even when I have unlimited txt on my plan. When I started using desktop clients more often than my phone, I wanted that back. Bring this to the forefront and let us have our active follows and our passive follows. We should probably only care to see our passive follows on some broad timeline, versus our narrow timeline. While you're at it twitter, lets make this taggable, but that's a whole other story.

Aside from this, the only other reason I see is the number of things you can't do on twitter without explicitly following someone, or being followed by them. Open up direct messages (optionally), even without follows. Let us do more without following people. Of course, the addition of passive follows, as I mentioned previously, would do just as well to fix this.

The number one benefit these changes would have would come from expanding the notification options to ignore the passive follows. That is, don't tell me if someone is following me passively, because they don't really care about me, so I don't really care about them. They can put whatever restrictions they want on active follows, within reason, and we can all still keep track of thousands of twitterers, without looking like spammers. All you need to do is attack the number one reason spammers mass-follow: they're abusing twitter to send plain old fashioned e-mail spam, with a very crappy costume.

In The End

Summing up with the bold lines:
  • No one is reading closely to a timeline filled by thousands of follows!
  • The value of following anyone breaks down soon after hitting three digits
  • they're abusing twitter to send plain old fashioned e-mail spam, with a very crappy costume
Concluding easily that automated checks and limits on following lots of people is fine, because only spammers have a real reason to do it.

Monday, July 07, 2008

How To Host Every Language in Every Language

Atul writes:
Last week, Scott Petersen from Adobe gave a talk at Mozilla on a toolchain he’s been creating—soon to be open-sourced—that allows C code to be targeted to the Tamarin virtual machine. Aside from being a really interesting piece of technology, I thought its implications for the web were pretty impressive.
The next steps Scott took are the most interesting, because he starts using this to build stock Python and Ruby runtimes that are hosted on Tamarin. This is a fascinating solution to one of our biggest itches: more languages on more platforms.

Imagining the sheer number of languages (most) this opens up to running on any Tamarin run-time (Flash and Firefox 4) is mind boggling. Go on, let your mind be boggled. Combine this with the basic idea being targetted to other platforms and you've got a lot of possibilities. Target other bytecode, like Java or .Net, and you open up more possible cross-builds than you can count. Platforms begin to fade on the borders.

At the same time, Mozilla is already busy learning to convert DLR bytecode to Tamarin bytecode, so I guess Java is the only bytecode left anyone (maybe) cares enough about getting to run on it. Down the road, could this mean Flash (and Firefox 4) will be the only platform supporting, essentially, any and all languages and libraries, in some form or another? Impressive.

Not only would Tamarin support Python, but potentially all major implementation of the language. Choices are great.

Of course, the same will be done for every platform, and once again the pattern repeats itself. Vendors will fight over control of the platform, just to be made irrelevent by one layer above them.
I write here about programming, how to program better, things I think are neat and are related to programming. I might write other things at my personal website.

I am happily employed by the excellent Caktus Group, located in beautiful and friendly Carrboro, NC, where I work with Python, Django, and Javascript.

Blog Archive