This post originated from an RSS feed registered with Ruby Buzz
by Obie Fernandez.
Original Post: Rails Project Brain Dump
Feed Title: Obie On Rails (Has It Been 9 Years Already?)
Feed URL: http://jroller.com/obie/feed/entries/rss
Feed Description: Obie Fernandez talks about life as a technologist, mostly as ramblings about software development and consulting. Nowadays it's pretty much all about Ruby and Ruby on Rails.
Been too busy to breathe, but I'm finally getting some time to blog again, thank goodness.
Gavin and I went out for dinner tonight. He introduced me to Vietnamese food, one of the few world cuisines that I hadn't yet tried. Quite good and inexpensive. I was impressed. We had another round of our ongoing Ruby vs. Java debate, or rather static vs. dynamic programming languages. He keeps insinuating it would take three years to rewrite Hibernate in Ruby, and I keep threatening to go ahead and prove him wrong. I'll go ahead and slot it for my copious free time.
The crux of his argument in support of Java is all about IDE support and long-term maintainability. We both agree that large codebases tend to degenerate into crap that's hard to maintain. His contention is that given a large crappy codebase, he'd rather have good IDE support for refactoring and debugging. I don't disagree with that assessment, which is why I find myself wanting to work on smaller, more focused teams.
Speaking of small, focused teams -- myself and five other ThoughtWorkers (including Jeff Patton and Michael Granger) spent the last two weeks doing a rapid-application-development project for the large manufacturer that I've been consulting for the last six months. Coding did not start until the second week. This is our first significant Ruby on Rails project and it has given me a lot more to talk about regarding Rails development. Here are the stats so you can gauge the scope of the work done.
I'm hoping to detail these topics and findings in my next few blog entries:
We started the codebase absolutely from scratch. New team, new svn repository, new TextDrive account, new everything. Two weeks later we have a fully-functioning application with three distinct user-roles, their associated feature sets, over a dozen screens and quite a bit of functionality. Clients are very impressed by this kind of delivery performance. Keep in mind this is not a prototype we're building, although given the time-constraints we cut some corners and built up technical debt, some of which I'm cleaning up this week.
I mentioned that coding didn't start until the second week. Well, the first week was spent doing the sort of user-centered design and analysis stuff that Jeff specializes in. I wasn't there the first week because I was at Panama City Beach on vacation with my kids. The first week gave the team time to get up to speed with the domain and get a basic understanding of the domain and requirements. When I got back from vacation I was pleased to find the war room wallpapered with task outlines and screen mockups and we started coding.
Don't ever underestimate how long it will take to come up with workable data model. Data modeling is difficult and in retrospect the team should have gotten this ready during the first week.
On a related note, you can't roll out features until you have a stable database schema -- and it took us about two days to settle on a stable database schema. This threw our rough schedule of when features would be delivered way out-of-whack. It's a testament to the productivity of Rails (and to our team) that we were still able to deliver enough functionality to please the client, despite falling behind schedule within the first two days.
We used Edge Rails meaning that our Rails codebase lives in the vendor sub-directory of our project, and is linked via svn external to the HEAD version of the Rails repository. Whenever we update the project it also updates the Rails code to the latest version. This didn't cause any issues despite Rails jumping about 50 revisions over the course of the last couple weeks. Working with 'edge-rails' meant that we got to use ActiveRecord migrations and Switchtower.
Don't start doing ActiveRecord Migration until you have a stable database schema and do a release. We did create a first migration script that creates the db from scratch, creates with the schema and loads example data from SQL scripts. I'm hoping Michael posts his code that does this as a snippet or something, hint, hint!
It took us half-a-day to figure out (and we patched a bug), but Switchtower is definitely worth using for deployments.
Don't underestimate how impressed your client will be (if they're savvy, that is) that in a week, starting from scratch, you are ready to do database migration and automated releases.
Believe the hype about how easy it is to do AJAX in Rails. We loaded up the app with dynamically refreshing form components, autocomplete textfields, and a touch of scriptaculous visual effects. Very nice, and very easy to pull off. (The only exception is observe_field, which the IRC channel can testify drove me crazy)
We didn't have continuous integration (c'mon Aslak!)
We didn't focus very much on unit testing either, but it will be a priority once work picks up again. I don't feel it was that big an impact to mostly ignore testing because we haven't gotten into too much domain logic yet, mostly just CRUD, which is handled nicely by the framework.
Wow. More of a brain-dump than what I expected to write. Need to get some rest, but before I wrap it up here are some of my notes about Ruby (and) Rails coding that I jotted down during the course of the week.
At one point Michael and I renamed one of our model classes manually. Major search-and-replace pain! Where o'where is my JetBrains Ruby IDE???
Despite that sentiment, I didn't find myself missing IDE features very often. I think the lack of an IDE is overblown by Java people.
At one point I was very pleased that I thought to use Enumerable#inject all by myself and it was the proper usage. For loops are getting scarce.
Damn, I can't believe I didn't know about ri until last Thursday!!! (It's a Ruby command-line tool that gives you API docs)
I ended up rolling my own JS onchange handler and serving it up from a handler instead of trying to make observe_field work.
I'm annoyed that I can't wrap my head around getting RMagick to work on Windows.
My client wants me to look into email integration this week, and in the back of my head I'm worried that this will be a pain-in-the-ass on Windows too. Basically, I really wish I had a 17" PowerBook like Michael :-D
Textfield autocompletion works great but it took longer than it should have to figure out why it wasn't styled correctly. My friend Amy has since written an excellent guide.
calendar_helper works well once you figure out the parameters (not documented correctly!). Still happy because I got Javascript calendar widgets working in about 15 minutes which is a fraction of the time it's ever taken me before.
I thought of making a particular hash instance respond to dot notation by manipulating its metaclass, but it ended up being way too complex a solution to the problem at hand. So I used an if/else -- not as cool, but it won't make the next developer to look at this code bang his head against the desk.