without_scope

I’ve been here at Tycoon for well over a year now. I remember thinking out loud about whether or not I should take this job. On that post is a thoughtful reply from the CEO which, while encouraging me to follow my heart, played a large role in my decision to join the team here.

There were some rough patches but, it’s worked out well. They have a tremendous team here and I’m proud to be a part of it. That’s not what this post is about though.

The PHP shop

They were a PHP-exclusive shop when I started. They were more than open to using Ruby though, in fact they seemed to be looking forward to it. However, after a few months of planning and discussion, when it came time to pull the trigger the same old arguments came out. Ignoring what was actually said, a lot of it really came down to conservatism and fear of the unknown. We only had one Ruby developer (me) as opposed to several PHP devs and no one wanted to effectively bet the next several months of the business’ productivity on the new guy.

This is entirely understandable and while I like to think of what could have been, it was the right decision for this company. We split up the work in a way that I still got to do most of my work in Ruby while the rest is PHP. Not a bad deal and it’s worked quite well.

Making inroads

Hey Rich, what do you use to deploy your code?

From that point forward our PHP application was deployed via Capistrano. Very little trouble, it just worked.

Next up, we needed a pretty simple stand alone background worker daemon. A bit of Ruby and the daemons and beanstalk-client gems and we had a worker that’s served us quite well for some time.

The gates swing open

I noticed the migrations in the PHP app were simply SQL files that each developer had to remember to pipe into mysql. So, I wrote a little script, migrate.php, that ran those files for you and kept a schema_versions table maintained with what migrations it had run. This worked great but, honestly, I was a little taken aback by the response:

Can’t we just use Rails’ migrations?

Absolutely. So, I hacked up the smallest possible rails app that still supported migrations and Lou Kosak used some his new found Ruby ability to pare that down quite a bit further by monkey patching Rails.

Now our PHP/CodeIgniter application has it’s database schema managed by Rails migrations and everyone seems happy. We’ve discussed creating a gem for this but, I expect this will be quite a bit easier in the more modular Rails 3.

Next up, we switched from Subversion to Git like the good Rails CodeIgniter application we are. One problem, we used svn:externals pretty heavily and Git submodules aren’t a direct equivalent and feel a bit funky. Lou had an answer in the form of a couple of Rake tasks.

The next big step, that we’re still getting working, is testing. This too, will use Ruby and there’s no wringing of hands.

Every developer here seems genuinely excited about Ruby now. I’m excited to see them learning what I was, admittedly poorly, trying to explain all those months ago. I’m looking forward to a Ruby filled 2010 here at Tycoon.