Why I Rarely Use HABTM
Code: databases, design, lifecycle, Rails, schemas
Comments Off on Why I Rarely Use HABTM
I was chatting with Kori Roys about database design and I mentioned offhandedly that I almost never use has_and_belongs_to_many in Rails. Kori’s ears perked up and he asked why that is.
From Fixtures to Factories
Code: factories, factory_girl, fixtures, Mocha, Rails, Ruby, testing
Comments Off on From Fixtures to Factories
Automated tests need example data, and it’s a pain to have to construct a complete object in every test, especially when there are a lot of non-optional fields.
NearbyGamers To-Do List
Biz: aggregation, events, groups, NearbyGamers, news, performance monitoring, Rails, stores, to-do
Comments Off on NearbyGamers To-Do List
NearbyGamers has been growing steadily without a lot of direct action on my part. I’ve been bugfixing and moderating, but aside from some performance improvements in November, it’s been quite a while since its had any user-visible improvements. Mostly this has been because I keep distracting myself with side projects: they’re deceptively simple to start but always have some area(s) of significant non-obvious complexity and a need for time-consuming polishing and refinement. I’m going to finish them off and then give attention to NearbyGamers.
OpenOffice.org Losing Viability
Code: community, Django, open source, OpenOffice.org, Rails
Comments Off on OpenOffice.org Losing Viability
OpenOffice.org developer Michael Meeks analyzed 2008 commit data to show that the project is losing steam: decreasing numbers of commits, developers, and companies. He rhetorically asks about how the project is losing technical quality:
Open Source Communities
Code: community, Django, open source, Rails
Comments Off on Open Source Communities
Open source projects should be judged as much by their community as by their technological achievements. The code tells you what it’s good for, but the community tells you what its future is.
Communities need to be active to continue improving the project, deal with bugs and changes to their ecosystem. If no one is interested enough to talk about the project, none of that will happen. Newcomers need to meet experienced users to be sold on why to use the software, to get help as they learn their way around, to maybe be drawn into contributing to the project itself.
Some communities are maladjusted. They self-defeat (see the section on Bion’s support groups), they lack plans or goals, they abuse newbies to keep from growing or changing, they’re more interested in bringing something down or defending turf than building up their own project. Some successful projects start with a grudge to pick, but most that do so fail to develop their own identify, and you can hear that in a cacophony of blame and flames in their social spaces.
Productivity is the best way to tell if a community is well. Even if it doesn’t have regular releases, it needs explicit plans on a reasonable schedule to meet measurable goals. Good software is produced by careful and deliberate iteration.
All well and good, but what about the slugfest between Django and Rails? When do we get to the part where I reveal myself as an irrational, deceptive propagandist because I say anything nice about the project you don’t prefer? Better question: why is there so much vitrol between the two?
The two are far more alike than dissimilar: extracted from projects that were created in similar dynamic languages from late 2003 through 2004, their core functionality was routing URLs to templates rendered with data retrieved with an ORM.
The biggest early difference is in these two contemporaneous blog posts: Django releases, Rails turns 1. Django was wrongly seen as a Python copy of Rails on its release, though it’s just a case of convergent evolution: to solve similar problems they developed along the same lines.
If success is binary, both Rails and Django are successes. They’re strong, reliable tools for building websites quickly. They are their respective languages’ leading web frameworks. Speaking personally, I enjoy working daily in both.
If success is relative, Rails is far more successful than Django. By any measure I can take, the Rails community is at least ten times larger. For example, Indeed has more jobs and Google Trends shows more searches:
And yesterday I posted about the difference in books with a ridiculous title. The difference between eight books and dozens can’t be explained away by Python being simpler, the Django docs being better, or Rails being more of a moving target (all true); none of them would stop publishers from trying to profit from an audience. The jobs, the searches, the books: they’re imprecise metrics that all point the same direction.
Rewind. Rails and Django were roughly technologically equivalent. They were both once a little flaky and incomplete and Definitely Didn’t Scale. But with the aid of good marketing, Rails turned its earlier release into a lead in in the developer market and created a vibrant, growing community (even if that community acts out a self-parody roughly annually).
Rails has had more resources in the form of bloggers, coders, writers, trainers, and users, and it’s used them to push in far more directions than Django has. Rails has explored dead ends like components, built plugins and changed course to use better integration with its package manager, and soon the entire Merb sort-of-fork project is merging into Rails with the results of its successful experiments.
Django hasn’t moved nearly as fast, it hasn’t had the resources to make as many mistakes to learn from. The Django community is recovering from an 18 month gap between feature releases (0.96 on March 23, 2007 and 1.0 on September 3, 2008). 1.0 included a lot of great features and improvements, but it was a long, quiet year-and-half getting there while Rails was continuing to iterate.
It’s not a question comparing 1.0 minus .96 against 2.2 minus 1.2.3. It’s about activity and momentum, Django lost it while Rails has used the network effect to grow the most active web development community to build better software. Count the amount of blog posts, consultancies, newbies, rants, silliness, projects, and weaknesses addressed instead of books and see how Rails has succeeded. It is its own ecosystem instead of only being part of the web.
The Django and Rails communities fight so much and so rudely because they’re too similar not to. Projects survive and thrive because they have attention from developers, and developers don’t often pick up two tools to do the same job (usually it’s one tool for every job). Community is the lifeblood of every open source project and the world of difference between Django and Rails is evidence.
Django vs Rails: The Dead-Tree Edition
Code: books, Django, Rails
Comments Off on Django vs Rails: The Dead-Tree Edition
Deploying Crontab With Your Rails App
Code: cron, Rails, yak shave
Comments Off on Deploying Crontab With Your Rails App
This is a short one. If cron is an old friend, don’t futz around with weird Ruby. You know the pitfalls of cron (environment variables, long jobs without lock files). So write your crontab and check it into config/crontab.
Code: AASM, Bort, ConfReader, design, haml, open_id_authentication, Paperclip, planning, Rails, RailsRumble, resource_this, restful_authentication, RSpec, scheduling, teamwork, web
Comments Off on RailsRumble Postmortem
I failed to launch my Rails Rumble project ConfReader. Why?
Code: crunch, experiment, Rails, RailsRumble, web
Comments Off on RailsRumbling
I’m participating in RailsRumble this weekend, from 8 PM Friday to 8 PM Sunday. The goal is to build a web application in Ruby on Rails in 48 hours, and I welcome the change of pace of a small project. It’ll be a fun weekend crunch to build it, and I hope it will be a long-term resource for the development community.