Skip to main content

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.

Comments

G-man said…
I really enjoy your posts on the App Engine group. With no books yet, it's the only way to learn quickly - from others who are also experimenting!
Aral said…
As a fellow developer working with App Engine, I couldn't agree with you more -- great write-up.

Popular posts from this blog

Respect and Code Reviews

Code Reviews in a development team only function best, or possible at all, when everyone approaches them with respect. That’s something I’ve usually taken for granted because I’ve had the opportunity to work with amazing developers who shine not just in their technical skills but in their interpersonal skills on a team. That isn’t always the case, so I’m going to put into words something that often exists just in assumptions.
You have to respect your code. This is first only because the nature and intent of code reviews are to safeguard the quality of your code, so even having code reviews demonstrates a baseline of respect for that code. But, maybe not everyone on the team has the same level of respect or entered a team with existing review traditions that they aren’t acquainted with.
There can be culture shock when you enter a team that’s really heavy on code reviews, but also if you enter a team or interact with a colleague who doesn’t share that level of respect for the process or…

CARDIAC: The Cardboard Computer

I am just so excited about this.


CARDIAC. The Cardboard Computer. How cool is that? This piece of history is amazing and better than that: it is extremely accessible. This fantastic design was built in 1969 by David Hagelbarger at Bell Labs to explain what computers were to those who would otherwise have no exposure to them. Miraculously, the CARDIAC (CARDboard Interactive Aid to Computation) was able to actually function as a slow and rudimentary computer. 
One of the most fascinating aspects of this gem is that at the time of its publication the scope it was able to demonstrate was actually useful in explaining what a computer was. Could you imagine trying to explain computers today with anything close to the CARDIAC?

It had 100 memory locations and only ten instructions. The memory held signed 3-digit numbers (-999 through 999) and instructions could be encoded such that the first digit was the instruction and the second two digits were the address of memory to operate on. The only re…

How To Care If BSD, MIT, or GPL Licenses Are Used

The two recent posts about some individuals' choice of GPL versus others' preference for BSD and MIT style licensing has caused a lot of debate and response. I've seen everything as an interesting combination of very important topics being taken far too seriously and far too personally. All involved need to take a few steps back.

For the uninitiated and as a clarifier for the initiated, we're dealing with (basically) three categories of licensing when someone releases software (and/or its code):
Closed Source. Easiest to explain, because you just get nothing.GPL. If you get the software, you get the source code, you get to change it, and anything you combine it with must be under the same terms.MIT and BSD. If you get the software, you might get the source code, you get to change it, and you have no obligations about anything else you combine it with.The situation gets stickier when we look at those combinations and the transitions between them.

Use GPL code with Closed S…