Lonely Lion

Sometime over the summer, Wilbur (my adorable two year old son) and I started playing around with Garageband.  I’d record him saying something, or banging on the keyboard, and then lay down some Garageband loops underneath it.  He liked sitting on my lap at the computer and listening, and he especially liked banging on the keyboard.  So, for Christmas, I upped the ante and asked Santa for a MIDI keyboard and a fancy Novation Launchpad to control a entry level copy of Ableton Live.  We’ve been playing around with both things for a bit now, making a series of really terrible songs.  Clearly, we’re driven by process rather than product.

I’m going to start posting our masterpieces here, to this award winning blog.  So, seriously, get ready for some hot trax.  This first hit is called “Par-Tai”.  It was recorded this morning at 6:30 am, while we let Camri sleep in a bit after a particularly hard night of Wil waking up every hour.  If you hand Wil a microphone, chances are he’ll say “Par Tai”.  Which is how he pronounces “Party!”  It’s adorable, and guarantees that he’s going to rule the par-tai when he gets older.

Just before the holiday break, I left PSC and accepted a job at skinnyCorp the parent company of Threadless. Like most good things, there’s a little bit of sad in there for flavor. In this case, I left a group of people that I respected and loved working with. I learned a lot at PSC, and am grateful they gave me the opportunity that they did.

I’m really thrilled to be at Threadless, I’ve interacted with them for a while now, so the move felt right. I joined as the VP of Technology, inheriting a sterling group of tech awesome dudes from the equally sterling Harper Reed. The job means that this blog will most likely stray into topics that I haven’t written about in the past, exciting process-y management-y type topics. One of the advantages to working at a place like skinnyCorp is that their company is an open book, as evidenced by their Threadless365 project, so I’m confident that I’m not going to be giving away any top secret information.

2010 is going to be a good year.  I’m resolving to tweet less and blog more.  Or…really…tweet the same, and blog more.

Last week I gave an Amazon EC2 presentation at the Day of Cloud conference here in Chicago. My slides from the presentation cover some basics about EC2. It was a good day, lots of good speakers, and lots of attendees that were interested in getting their apps into the mysterious clooooouuudd.

The kicker is, I spent a fair amount of time explaining how to set up a relational database on EC2, just in time for Amazon to announce that they’re releasing very easy to use MySQL instances. Luckily, I have a half hour tomorrow at the Chicago Google Tools User Group to revisit the Amazon talk. I’ll revise the talk to focus on Amazon’s new offerings, specifically how to get a reasonable web app up on Amazon using RDS as a database back end.

I understand the irony of giving the talk at a Google tools group, but it can’t hurt to know how to move your applications off of AppEngine and on to other services. It’s all part of Data Liberation, right?

Now, with video:

I’ve been involved with a handful of EC2 deployments at PSC, and they’ve all ended up with a custom AMI. Basically, starting up an existing base Ubuntu server, installing and configuring packages, and saving the new image as a custom AMI. It’s not a bad way of doing things, but I had a nagging feeling that there was an easier way. Especially given the ease of deploying an AppEngine app. Granted, they’re two completely different animals, but still…there had to be something better.

Eric Hammond, of Alestic fame, answered a bunch of my nagging subconscious questions with the release of runurl. Now, you build and host your configuration scripts, and pass a list of the scripts to run on server start up through passed user-data scripts. In theory, it’s possible to start up a new base server, and automate the build out through hosted scripts. It means slower start up time, but significantly less configuration and AMI maintenance. For a webserver cluster, where you have some time to get new nodes up, this method makes more sense than the standard AMI-saving method. Nice work Eric!

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’m often heard to mutter, “The JVM is the future man…if you’re a Python or Ruby developer, you should really get up on it. It’s the future.” Google agrees with me (it isn’t the first time, they’re constantly hitting me up for advice). They released the JVM for Appengine complete with a fancy Eclipse plugin.

Although the majority of the documentation talks about the release of Java for Appengine, there’s an important distinction to make…they reallly released the JVM for Appengine, as evidenced by this nice post about which JVM languages will work on Appengine.

So, really, in one swoop, they released Jython, JRuby, Scala, Javascript, and Clojure. That’s pretty slick.

Sure Java is arguably way less nice than Python and Ruby, but the JVM is pretty great. Languages that target it as a platform open up a lot of otherwise closed Enterprise doors. If you want to write Python or Ruby as your day-job, you should really start paying attention to the JVM.

Pycon 2009, as of 2pm on Friday, is the best Pycon I’ve been to yet.  The talks this year are really well put together, it’s clear that the speakers are high caliber and spent time on their talks.  Despite the lower attendance numbers (thanks Economy!), it feels like Python is poised for some significant growth.

The Python VM panel, with representatives from Jython, IronPython, PyPy, cPython, and the relatively new Google-cPython-speedup project-unladen-swallow, is laying out a future for Python the language points pretty clearly at “Python is an objectively good language, let’s get rid of this silly implementation idea.”  Meaning, developers want to write Python, and they want it to run everywhere, and they want to leverage other tools, regardless of origin language, in their language of choice, which…thankfully, is Python.

Like a lot of developers nowadays, I’m spending some time learning Objective-C & the Cocoa Framework so that I can jump into iPhone development. I’m clearly a little late to the game, but I usually am, so…no worries.

So far, I’m keeping an open mind (which can be tough for me, as I’m 32 but act like a cranky 72 year old). It’s surprising, Objective-C isn’t as wildly complicated as it first looks, the really disorienting thing is working in Xcode. I’m so in love with the straight simplicity of building apps in Emacs that all the dragging and dropping throws me off. Granted, in my recent (undocumented) foolings with Java, I started to covet all the work that Eclipse was doing for me, however, something about all the magical dragging and clicking makes me nervous. What’s it doing in there?

I’ve also got that old sharecropper feeling, which is kind of rough. Once you develop your fancy iPhone app in Objective-C and Cocoa, you can reuse libraries to build it out as a OSX app, but that’s about it. You can develop a OSX app in Python or Ruby through bridges to Cocoa, but you can’t use that code on the iPhone, iPhone is Objective-C only. You could move some of your heavy lifting to a web service, but then you’re tethering your fancy iPhone app to require a network connection.

Anywho, it’s an interesting thing to learn, I’m sure I’ll have fun with it, it just doesn’t feel like it has the wide open opportunities that learning Python did, or Java does.

[youtube=http://www.youtube.com/watch?v=InI5n3NTvR4&color1=0xb1b1b1&color2=0xcfcfcf&hl=en&feature=player_embedded&fs=1]

I heard mashup and cloud computing. Despite the buzz-ish nature of both, it’s an encouraging sign. As much as I love Everyblock, I think they’d agree that it would be nice to see the federal, state and local governments publishing data, rather than concerned parties scraping stuff.