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

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…

Interrupting Coders Isn’t So Bad

Here’s a hot take: disrupting coders isn’t all that bad.

Some disruptions are certainly bad but they usually aren’t. The coder community has overblown the impact. A disruption can be a good thing. How harmful disruption might be a symptom of other problems.

There are different kinds of disruptions. They are caused by other coders on your team, managers and other non-coders, or meetings throughout the day.

The easiest example to debunk is a question from a fellow developer. Imagine someone walks over to your desk or they ping you on Slack, because they have “one quick question.” Do you get annoyed at the interruption when you were in the middle of something important? You help out your teammate quickly and get back to work, trying to pick up where you left off. That’s a kind of interruption we complain about frequently, but I’m not convinced this is all that bad.

You are being disrupted but your team, of which you are only one member of the whole unit, is working smoothly. You unstuck …

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…