wiredfool

I’m 3 weeks into an occasional night and weekend project — taking an hour or two when the boy is sleeping to get up to speed on Ruby on Rails. Three weeks in, maybe 20+ hours, and I’ve got a solution that’s nearly ready to be opened up to more than just in-family testing. What follows is some notes to the experience.

I’ve got some history with TurboGears and Webware for Python (and a lot of python backend non-web stuff), and a bunch of PHP recently and Frontier experience going back to the first boom. I’ve done my version of object relational mapping and scaffolding/form generation, I know what has worked in my products and where I feel that there’s friction that could be reduced.

Rails is different. Far enough different that I’m not bringing python baggage into it like I did for turbogears. I was dissapointed with TG (or was it subway?), partially because of the amount of stuff that I had to find and install, and I didn’t really gel with it. Then again, this is 6 months later, and I’ve kind of let the project go into hibernation without ever putting it on a deployment server. But this one is 3 weeks in, and I’m ready to show parts of ti to the world. That alone shows that it is possible to deploy early and often. With caching, it even runs fast enough on a old G4 to not be embarassed about it. I’d say that it’s generally about as fast as Frontier (on ancient hardware), in a ‘things take a second or so’ sort of way, not in any sort of quantified benchmarked manner. It’s downright snappy on my MacBook.

Rails on the mac is a one dmg install if you get the right dmg, and that makes a big difference.

Rails has had a lot of thought into laying things out, I like the convention vs. configuration. I like not repeating myself, but I must say that every time I’ve tried to reuse things vis subclassing, I’ve backed it out and am using copy/paste because things got pear shaped very quickly. Some stuff really is quick. I’m certainly not faster in it now than I am in php/python (well, apart from choosing a python web framework), but that will probably come with time.

There’s a good system for migrating data models forwards and backwards. That’s nice. Test harnesses are built in, also a very good thing. Basic Ajaxy stuff is really quick to implement. Edit in place is something that I’ve been wanting for a looooong time. Edit in place plus periodic autosave is enough to get around the dreaded browser window close problem.

I’ve fought with caching, since the assumption is that you’re caching html, and I’m caching images. My images get saved with .html, or they get stored in the in memory cache and then served out text/html, even though I’m setting a mime type on the return. I didn’t want to expose a gif/jpeg/png suffix in urls so that I could change the underlying representation away from png if IE6 became too much of a hassle. That’s just not an option without extensions, since the webserver won’t have a clue as to the correct mime type. My images change once a day, so what I’m doing for now is dumping them to a static directory, then serving from there with the lighttpd and having a cron job clear it out at midnight. I don’t like the cron job part, since it means that there’s something that’s not embedded in the deployment.

I’ve had some things that Just Haven’t Worked. One of my database migration scripts refused to do anything useful with the data when done in a ruby way. I think it’s because of a versioning difference between the old class and the new class, but the failure was less than obvious. (obj.find(:all) failed)

I’m certainly not writing ruby right now, I’m writing python with a ruby syntax. It would be good to go over this with someone who knows ruby and could point things out.

There’s a lot of fiddly stuff that happens around scaffolding and forms once you get rid of the scaffolding. There’s a lot of view related stuff that’s just not in my normal working flow. I don’t write forms in anything resembling html if I can help it at all, normally I drop a list of columns + data on a renderer. My stiff winds up being harder to lay stuff out manually, Tradeoff, yes. More flexible, but I kind of like the form infrastructure that I’ve built twice now.

The MVC layout is not what I was expecting, I am winding up with minimal glue in the controller, lots of stuff in the models, and html and such in the views. Reasonably to be expected, but significantly different from with the frontier view or the java servlet view. (I’m partial to the servlet view these days). It’s very hard to link to an action that returns an image and get it right. Stuff that I’d like to reuse winds up having to happen in views, which don’t reuse easily. I would have expected a more heavyweight controller, and lighter models, given that the default layout seems to be a controller/model/view for each object. This is probably because I’m just not up on ruby yet. There is another model, that of controllers for each permission level that span different object types. I’ve spent half an hour rearranging my bigest controller into admin and public and it seems to make more sense than the per object controllers.

The documentation out there is somewhat sketchy, lots of blog posts and an api document. The howtos aren’t really often what I’m looking for, and I managed to get an error message that didn’t show up in google at all. The Rails Recipes book is a help – but I’m still finding that the online resources aren’t the equivalent of python or php. To be fair, Rails the framework should be distinguished from Ruby the language – I’m comparing to language level documentation and Rails is significantly more subtle than that.

It’s not a silver bullet, but then, there never really is one. When things work, features are under an hour. It’s possible to get meaningful progress done between boy falling asleep and me crashing. We’ll see how I feel about it in another month.