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

The Range of Content on Planet Python

I've gotten a number of requests lately to contribute only Python related material to the Planet Python feeds and to be honest these requests have both surprised and insulted me, but they've continued. I am pretty sure they've come from a very small number of people, but they have become consistent. This is probably because of my current habit of writing about NaNoWriMo every day and those who aren't interested not looking forward to having the rest of the month reading about my novel. Planet Python will be getting a feed of only relevant posts in the future, but I'm going to be honest: I am kind of upset about it. I don't care if anyone thinks it is unreasonable of me to be upset about it, because the truth is Planet Python means something to me. It was probably the first thing I did that I considered "being part of the community" when I submitted my meager RSS feed to be added some seven years ago. My blog and my name on the list of authors at Plan

Pythonic Defined

Introduction Losing is Good Strings Dictionaries Conclusion Introduction Veterans and novices alike of Python will hear the term "pythonic" thrown around, and even a number of the veterans don't know what it means. There are times I do not know what it means, but that doesn't mean I can define a pretty good idea of what "pythonic" really means. Now, it has been defined at times as being whatever the BDFL decides, but we'll pull that out of the picture. I want to talk about what the word means for us today, and how it applied to what we do in the real world. Languages have their strengths and their idioms (ways of doing things), and when you exploit those you embrace the heart of that language. You can often tell when a programmer writing in one language is actually more comfortable with another, because the code they right is telltale of the other language. Java developers are notorious for writing Java in every language they get their hands on. Ho