Living the startup life in Atlanta, GA.

One of the most annoying things about deployments are dealing with databases. In the Java world, using Hibernate to generate your schema is pretty common. It works well in development, where you generally re-create and re-seed your database after each model change. However, it can be disastrous when deploying. It felt like each sprint needed a dedicated day for diff-ing the database schemas and figuring out what changed and what needed to be applied. Often, indexes would be forgotten, resulting in un-foreseen slowness.

Ruby on Rails solves that problem with using migrations. Migrations describe how to move from one version of the database to the next. While it’s built into Rails, I came across Standalone-migrations on GitHub. Not surprisingly, it exposes the core functionality of Ruby on Rails migrations, allowing you to embed it in any kind of project. You’ll still need Ruby to run the migrations along with the correct gems for connecting to the database.

Of course, Ruby on Rails migrations have a few downsides. Personally, I believe that the database should be aware of constraints and relationships. This has other practical benefits, such as automatic indexes. By default, Rails Migrations do not support foreign key’s natively. Simon Harris wrote a plugin to automatically associate foreign keys. Way easier than writing SQL.

Getting a rails plugin to work standalone required some munging, so I ham-fisted Standalone Migrations and Foreign Key Migrations together and put the project on GitHub. If this is something you need, clone my fork of Standalone Migrations.

These are my pretty random thoughts relating to Atlanta Startup Weekend2.

I like the multi-idea format.  It kept people engaged and happy.  A lot of folks felt the idea selection phase took to long.  I was an early supporter of this idea.  However, in retrospect, it might not have been a bad thing. 

Based on the ideas posted to the website, I went into Friday night planning on helping out with Giving Time or the project called Seed Stage Records.  By the end of the night, I really wanted to work on “Mark’s Horrible Idea” or “Get Me A Date.”  Hearing the pitches, it became clear that a lot of the ideas weren’t well thought out or appropriately researched.  This made me uncomfortable, since there really isn’t much time.  The ideas that were better seemed to draw incredibly huge teams.  This is also disconcerting, since you’re likely to spend more time arguing than actually doing things.  

“Mark’s Horrible Idea” and “Get Me A Date” were incredibly appealing, simply because they were quirky, morally questionable, and pitched as jokes.  Which meant they felt nothing at all like a day job.  I’ve already got one of those, along with a bunch of side projects.  I came to ASW2 to have fun, and these were the projects that seemed the most fun to work on.

I pretty much ended up as the front person for “Mark’s Horrible Idea” (rebranded Reepli.com.  This taught me some really important lessons. 

Teams are crucial

We were able to accomplish what we did because all of us had worked together in the past. This made it possible to check our egos at the door and focus on who would be best doing what. The project was originally “Mark’s Horrible Idea” but I ended up taking on the biz dev and marketing duties. That happens a lot in the real world. What doesn’t happen a lot is that transition occurred without any real conflict or founder’s anxiety. Structuring the team that way just made the most sense.

Having a good team that understands each other and knows how to make each member useful is crucial to getting something done in a short amount of time.

Context Switching is Hard

I’m not a biz-dev person, I just played one at ASW. Something I find incredibly hard and will work on more in the future is switching between coder and something else. When you’re programming and deep into the problem, it’s important to switch gears and focus on the points that are relevant to your audience. They probably don’t care that you use Capistrano. They probably do care what problem you solve and how you intend to make money.

Also, as the de-facto team lead, a lot of what I needed to do was make sure everyone was being productive and knew their importance to the goal. However, as a programmer, my desire was to stick my headphones on and jump head first into the code. Finding the right balance isn’t easy.

Beware mock data

More often than not, this ends up on a projector in a room full of people. Thankfully, everyone found it funny and nobody was offended.

Credits

I’d once again like to thank everyone for their hard work and point out their key contributions (in no particular order).

• Amro Mousa did some front-end and worked extensively on the search components
• Hamed Hashemi built search and reply modules and assisted with all the server work
• Mark Luffel pitched the idea that made us laugh. He also built a lot of the front-end and tossed in a most of the AJAX
• Erik Peterson our resident rails uber-guru built a ton of the backend and wrote the unit tests. We had nearly 75% of our code covered thanks to him
• Joe Uhl wrote the reply transformation module, before his real startup called and he had to leave us for the weekend

Thanks guys!

Also, thanks to Lance Weatherby and the ATDC who made it all possible.

One Rails thing that has always felt just a bit un-rails like is deployment. There are a ton of solutions out there. I’ve used Lighttpd, fast-cgi, and mongrel proxied by Apache. Almost all of these have been tedious, a pain, and failure prone.

The Dutch have come to our rescue with Passenger (aka mod_rails). Passenger allows you to run your Rails apps natively within Apache. No need for proxies, mongrel clusters or anything else. They even claim that it recovers from server errors.

The best part is that it’s brain-dead simple. If you can execute a few lines on a command line and add a virtual host to Apache, you can host your Rails app in Passenger.

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.