Living the startup life in Atlanta, GA.

Sonali and I decided to spend the week of our fourth anniversary hanging out in San Francisco.  It was the first time that I’ve been there for pleasure since I was a little kid and Sonali’s first real visit to the city.  It’s a really neat place and way up there on the “I want to go back” scale.  

The overall vibe I got from SF was that everyone works a lot, but people just aren’t as stressed as they are in NY.  I attribute this to the city not being as cramped, the weather being a lot nicer, and the general california-ness of it all.  

You can check out the pictures These were some of the highlights:

These trees are crazy tall.

The city from across the bay

Sonali in front of the tidal pool at the Monterey Bay Aquarium

We’re not golfers, so we had no idea what “Pebble Beach” we were at until we got to here.

We were not expecting to see sea lions just hanging out on the docks.

We saw some great views on our hikes

It’s like Fondue, but Japanese. I don’t think that we’ve had as many interesting meals in as short an amount of time.

We spent our anniversary touring wine country. This is me having some very tasty Fume Blanc at the Mondavi vineyard.

Sterling won the most beautiful vineyard award.

This was way too cool. We got to tour the real-live working engine room of a Liberty Ship

Alcatraz appearing out of the deep fog. Welcome to the Rock!

We’re in a solitary confinement cell. It’s a lot less scary when you have a camera flash. That’s my good friend Chris Sun in the background there.

The best meal of the whole trip, a savory seafood Souffle.

There are a lot more pictures, so if you want to check them out, head over to the gallery.

When working on Appcelerator’s AppEngine support, I needed to find some API documentation for Beaker. I didn’t find it, but I did find this gem.

This guy can’t figure out why companies (or individual developers) would ever pay money for a hosted DVCS repository. The great thing about DVCS is that you don’t need a centralized repository. Unfortunately, this independence from centralization goes away once you have to give your software to somebody. At that point, one repository becomes the master. You could just go round-robin and pick the source off one of the developer’s boxes. You could also jump out of an airplane without a parachute. Just because you can do it doesn’t mean it’s a good idea.

Which leaves you with two options:

Option one is fight with budgeting to get a box to hold the repository. Since it probably has to be somewhat beefy, it probably just can’t come out of the normal budget. This means you talk to budgeting. Once you get the box, you need to install the software on it and connect it to the network. So now the IT department is involved. Get a developer to write a script to back up the repository regularly. Bring in the development department. Find a place to back up the repository. Figure out some way for developers to push and pull code to the master from off-site (often this means you have to poke a hole through a firewall). In a small company, that’s all one person, and the whole process takes a few hours. In a larger company, that’s three different departments, which means conference calls, emails, arguments, angst, internal billing negotiations, and a process that could take anywhere from a week to years.

Or you can pay $100/mo and not have to deal with any of it. If you’re a development manager, how would you choose?

Ben goes on to claim that this type of software-as-a-service silliness is endemic of Rails apps as is having good design. As someone who has to do more than work on Open-Source Python server code, it’s very obvious why people use these services. They are more benefit than cost. The developers put thought into the experience and it doesn’t hurt your eyes when you look at it *cough* trac *cough*. People appreciate that effort and will pay for that. Otherwise, Apple would be out of business and the iPod would have been a flop.

I like Python as a language. I’m likely to use it for my own stuff someday. However, the reason Rails became more popular, although it’s a relative late-comer, is that the creators of Rails thought about the user experience. The point is that they were designers and not pure developers. They understood that design is not just decoration. They focused on making something that was useful to somebody. Repeating that thought process isn’t copy-and-paste, it’s good sense.

I finally got around to seeing Indiana Jones last night.  It was fun, but far from great.  There were a lot of periods where I felt like I was watching a “Best of Indiana Jones” montage, rather than a whole new movie.  Almost all the stunts were lifted from the previous movies and some of the non-recurring characters as well.  What kept it from feeling like a Indiana Jones I-III mashup is the amount of grey on Harrison Ford’s head.  

Despite how predictable the movie became because of this, I actually didn’t mind it that much.  One of the strengths of the movie is that it’s not over done.  There isn’t a ton of CGI everywhere.  The credits listed a bunch of model makers.  It’s a slightly dirty throwback to 80′s adventure movies.  Which is what an Indiana Jones movie should be.

I didn’t walk out of the theater thinking “I need to see this again,” but I enjoyed watching it.  If you haven’t seen it, it’s an entertaining way to burn 2 hours (plus previews).

I’ve gotten a chance to play with the technology a bit in the last few weeks and have a few things to say about it.

My first response towards it was pretty ‘whatever.’  There was the fact that the last over-hyped Google for developers launch (GWT) isn’t really all that.  Automatically scalable web apps are pretty neat, but there are already a bunch of grid offerings available.  MediaTemple, EngineYard, and Amazon’s EC2 are all variations on this theme.  Compared to these production services, Google’s offering is a little weak.  First, like all Google products, it’s Beta.  Only 10,000 invites are available.  You can only have 500MB of storage.  You can’t upload a file larger than 1MB (found this out the hard way while building Apptunes).  You can’t launch a background process.  You can’t take too long to service a request.  And so on.  Of course, it’s a free private beta, so all the whining is only slightly applicable.  The end result was, we built support for it, built a demo, then I forgot about it and moved on to other things.

Until I few moments to mess around at work.  Our demo didn’t make much use of Google’s model support.  Nor did I have to write a lot of Python.  So I set out to build a more complex demo application that would let me play around with the persistent storage engine.  It wasn’t before long before the App Engine (and python) really started growing on me.

A major benefit to using Appcelerator is all the service backends are structured similarly.  So although I’m a Rails and Java person, I didn’t have to think too hard about where to put things in my App Engine project.  Instead I could focus on learning Python.  The good I found about Python:

• It’s a stickler for spacing.  I like this since when I was a TA I had to look at a ton of indecipherable code.
• I don’t have to write a lot of punctuation or litter ‘end’ everywhere
• The ternary operator is there, but a little weird (return1 if <condition> else return2
• Munging arrays is syntactically very sweet: notes = [{'note': note.text} for note in query]

Once I figured the syntax out (with a lot of help from the Atlhack’ers) I was able to marvel how cool the datastore is.

The neatest feature of the datastore, is that it’s a datastore, and not a database.  There aren’t any tables to define and worry about.  This forces you to think of your data in a different context.  It’s a lot more like a datawarehouse, where the pertinent question is: How do I want to access my data?  At first, I tried to treat my models like I would with Hibernate.  Then I read a post on the google group stating that “normalization doesn’t scale.”

Which brings me to another downside.  I couldn’t figure out a way to cleanly migrate or delete all existing data.  The above epiphany didn’t occur until after I pushed version 1.0.

Since it’s not a relational database, queries work differently too.  Any query you define does not get executed until you actually try and use the data.  Which means you can build a query then attach filters all the way up to the point where you access the first element.  Syntactically, it’s not very different from ActiveRecord or HIbernate, but I found the concept very cool.

Finally, there’s the undocumented, somewhat unfinished feature of automatic full-text search.  If you want check out what I did live, take a look at Yesnotes.  You’ll need a google id to log in.

After working with it for a bit, I realized a few things.  First, I spent almost the entire time focusing on my code, not on what database to run, or how the production environment should work.  Second, the whole thing makes a lot of sense (especially when tied to an ajax framework like Appcelerator).

I think Google hit the mark on this one.  If you just want to build something, App Engine is a great way to go.  There’s all sorts of small (and not so small) useful apps you could build very quickly with App Engine.  Not to sound too fanboy, but I’m really looking forward to the official launch.