Lonely Lion

Well…it’s either a game changer, or it will end up being really popular in Brazil.  I’m leaning towards the game changer.  Really, it’s about time, it’s good to see a big company being ambitious instead of just making a new thing that’s just like the old thing, and they’re open sourcing it.

Imagine a big cast iron pot, throw in Appengine, XMPP, Blogs, Wikis, stir, simmer, and serve.  Wave!  Some particularly interesting bits from the API preview doc:

You define the behavior of your robot by defining the events which you wish your robot to be notified. Wave contacts the robot whenever one of these events occur, such as a change made to a wave in which the robot is a participant.

I spent an absurd amount of time hand crafting an email-bot a few years ago that could respond to my old improv team’s email list with information about our upcoming shows.  It ended up being pretty useful, but took a bunch of time to write.  Anytime an announcement includes robots, I’m hooked.

The Java and Python client libraries allow you to design your robot

Python!  (Note to Google, please rewrite the above to read: The Python and Java client libraries.)

Lastly, there’s a Chess gadget!

Obviously, the real test will be adoption.  I signed up for sandbox access, because it feels like this is the future, and I want to support it.  A slew of my non-technical friends now treat Facebook (nice, but a non-open standard) like it’s email.  As a consultant I’d love to be able to suggest modern collaboration tools that don’t tie you into one particular vendor.  And most importantly, Wave looks like a heck of a lot of fun to play with.  Although I haven’t released anything of any importance on Appengine, I love the concept.  The Appengine deployment process, applied to collaboration, seems like a real win++ to me.  Nice work Googlers.

Remember that whole Appengine got the JVM link I posted yesterday?  I forgot to add one thing.  Rhino is on that list.  Meaning, you can write really awesome Javascript applications on the Google-server.  In Ted Leung’s Pycon talk he specifically points out the performance gains that several big companies have baked into Javascript, how Javascript is one of the most “known” languages, and how Python & Ruby folks should know that as soon as Javascript becomes an accepted server side language, they’re probably going to have to join or die.

Obviously, I’m paraphrasing.

That said, picture Ted as a crazy prophet saying that when the sky rains blood, it means the end of Python.  Then picture Google Appengine raining blood.  See where this is going?  Google totally released server side javascript on Tuesday.  The prophecy is coming true!

(If you watch the video, feel free to skip over the Q&A period, in which I ask a batshit crazy question and blame democracy for the inability of Python to feed more families.)

I started my first AppEngine project this evening. I was lucky enough to get into the Beta. I don’t want to be too gushy or hyperbolic, but this is the future folks.

I’m not going to cover the bits about what appengine is, I’m assuming you’ve heard. If not, head over to the appengine site and do some reading. If you’re a little bit confused about WSGI, I encourage you to read anything Ian Bicking has written over the past few years, or my humble article on building a wsgi app.

So…my plan is to build a tomato tracking application on top of THE CLOUD (cue the music). The wife and I are planting a bunch of tomatoes this year, so I’m sort of hopped up on them. The app will let folks to report on the life, well being, and eventual yields of their backyard tomatoes. It’s going to be the world’s greatest web application. I’m going to develop it before a live studio audience via the TomatoBase Google Code Project. The app will live at http://tomatobase.appspot.com.

So far, there’s not much there. Just a landing page that says something pithy, that’s protected by a Google user login. I initially thought I’d jump feet first into the Google themed stack, using their very fancy webapp api, but after reading how easy it is to just go for Django, I decided to go with what I know. There’s a few gotchas, it’s really more like Django-Lite, but it’s still pretty darn good. You lose the ORM and Admin, but still get the url mapper, controllers, middleware, templates…oh, and BigTable. Pretty good trade as far as I’m concerned.

Developing with the toolkit is pretty slick, everything runs locally until you’re ready to push, and then it’s a quick “appcfg.py update django-mater” and it goes live. So simple. I love it.

I haven’t really ventured beyond exploration into actual TomatoBase development just yet. I started exploring the user system a bit, it’s pretty straight-forward. So straight-forward that I contributed a decorator to Django Snippets that lets you use the user system in a @loginrequired sort of way. It’s here: Google AppEngine Login Decorator.

I’m moving much quicker on this than I anticipated. I thought I wouldn’t have time to explore until this weekend, but it’s a really compelling product. I’m excited for them to open it up to a wider audience. At some point I’ll write a bit about what I think this all means (this means something), but for now I’m too busy playing.