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!
Unknown said…
As a fellow developer working with App Engine, I couldn't agree with you more -- great write-up.

Popular posts from this blog

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

Statement Functions

At a small suggestion in #python, I wrote up a simple module that allows the use of many python statements in places requiring statements. This post serves as the announcement and documentation. You can find the release here . The pattern is the statement's keyword appended with a single underscore, so the first, of course, is print_. The example writes 'some+text' to an IOString for a URL query string. This mostly follows what it seems the print function will be in py3k. print_("some", "text", outfile=query_iostring, sep="+", end="") An obvious second choice was to wrap if statements. They take a condition value, and expect a truth value or callback an an optional else value or callback. Values and callbacks are named if_true, cb_true, if_false, and cb_false. if_(raw_input("Continue?")=="Y", cb_true=play_game, cb_false=quit) Of course, often your else might be an error case, so raising an exception could be useful

How To Teach Software Development

How To Teach Software Development Introduction Developers Quality Control Motivation Execution Businesses Students Schools Education is broken. Education about software development is even more broken. It is a sad observation of the industry from my eyes. I come to see good developers from what should be great educations as survivors, more than anything. Do they get a headstart from their education or do they overcome it? This is the first part in a series on software education. I want to open a discussion here. Please comment if you have thoughts. Blog about it, yourself. Write about how you disagree with me. Write more if you don't. We have a troubled industry. We care enough to do something about it. We hark on the bad developers the way people used to point at freak shows, but we only hurt ourselves but not improving the situation. We have to deal with their bad code. We are the twenty percent and we can't talk to the eighty percent, by definition, so we need to impro