Posted by Doug
Wed, 19 Apr 2006 12:12:49 GMT
Productize seems like such a good idea. Even David seems to give it praise. It seems though this good idea had a short life-span.
For those who don’t know, Productize is a method of making a Rails app a “parent” and then having multiple instances of that app that all shares the same code base allowing for individual tweaks. For myself, I was wanting to productize typo so that I could easily host many typo blogs. At work we use productize on our website to provide our primary US site and also a customized UK website.
Productize was originally released pre Rails 1.0. With The Big Milestone, there was some scrambling to get productize to work. The problem is that productize pokes fairly deep in the internals of Rails class loading. That code seems to be not yet as stable as it should be. Each release of Rails seems to break productize.
To make matters worse, it doesn’t seem like Duane Johnson is still using or working on productze. With the 1.0 release, the patches and work arounds for productize came from the community. I never did see anything directly from Duane.
Now that Rails 1.1 and 1.1.2 are out, productize is broken again. For such a good idea of minimizing duplication, it doesn’t look good for productize. Members of the core team have said there’s no interest in making it part of Rails core and no desire to “support” it and the internal hooks it needs. In my mind, this moves productize into the “high risk” category.
I never did get typo to the point where it would work nicely with productize. Right now we depend heavily on it at work, but that’s changing. We’ve decided to take the core pieces of our app and make them into and engine/plugin and then split the US and UK sites into separate apps. When we first introduces the UK site, productize’s primary assumption held true: everything is the same unless it’s different. Now that our UK site is fairly mature, the department heads of the respective sites are pretty much assuming everything is different unless it’s the same.
Posted in Programming, Internet, Ruby on Rails | 2 comments
Posted by Doug
Fri, 24 Mar 2006 13:39:56 GMT
I’ve been doing some hacking on my Ruby and Ruby on Rails configuration for Emacs. I don’t think it’s done (are these things ever?), and maybe not even as good as TextMate. I’ll share it anyway in the hopes that someone can find it useful. You can find my writeup and the configuration file on my Emacs And Ruby wiki page. Notable funcationality:
- Interactively running tests in various ways
- Go To Alternate File
- Snippets
Posted in Emacs, Programming, Ruby on Rails | 2 comments
Posted by Doug
Wed, 08 Mar 2006 13:43:13 GMT
At last night’s XP Cinci we did an interesting exercise called “The Fishbowl”. Mark Windholtz setup his powerbook with a terminal, Safari, TextMate and a time tracking application he had been working on. We then each took turns pair programming on the big screen. While there were two of us “at the console” all the time, we swapped one of them out every 10 minutes.
The exercise was interesting for several reasons. Mostly it turned out to be a good example of what test driven development looks like in Ruby on Rails. The skill level of xp-cinci is split pretty evenly. About half of us have done significant RoR development and the other half is either just interested or just learning. Regardless of skill level though, no one was going to code in public at an XP meeting without writing tests. The best way to learn TDD is by doing. Until you’ve lived through the development cycle of TDD it’s hard to really grasp what it feels like.
The other benefit from the exercise was a fairly lively discussion on “this is how we do it in Rails” versus “this is what I’m used to in Java.” Most of xp-cinci comes from a strong Java background. Even though about half of us are “ruby nubies,” pretty much everyone has a very strong developer background with one technology or another. Here’s a for-instance. I coded up a method that used MyModel.find_by_id(params[:id]) and was asked why I used find_by_id rather than just find. I said that I liked how find_by_id returned nil so I could use it as a false value when doing error checking. As a long-time Java smart-guy, Ed Summerfield was pretty quick to jump on this as a bad practice. He demonstrated how his Rails controllers looked using begin and rescue. I’m not entirely convinced that assigning nil to an object as a fail condition is bad, but his code looked fairly neat with all his error trapping in rescue blocks.
While the skill levels of various members varied, our application we worked on wasn’t really the typical “hello world” style application of tutorials. We started with a working application. Mark and Scott are actually using the application as part of their consulting work at Rails Studio. This gave us the chance to work in a more “normal” fare. We had an existing database we were migrating; we had existing code we had to live within; and we had a “real” customer looking for “real” improvements to their application.
Last night’s meeting was different from our usual fare. It was back to a hands on style where we actually wrote code. While we didn’t get very far in terms of feature points, I think we made a lot of progress in general understanding of both coding practices and Rails development. I hope we continue doing more and talking less.
Posted in Programming, Test Driven Development, Ruby on Rails, Community | Tags Cincinnati, Rails, Ruby, testing | 5 comments
