Has Ruby on Rails been good to you? Has the framework helped you get a job or start your consulting career? If so, I challenge you to give 3 percent of your time for Rails 3 over the next few months. If you work 40 hours a week, 3 percent amounts to less than 5 hours a month! Could you donate half a Saturday a month to the framework that figuratively puts money in your bank account? I can, and that’s why I’m pledging three percent for Rails 3 over the next few months.

The Bugmashes have been great, but there’s still more to be done. The core team is dedicated and smart, but they can’t do it all. As of the time of this post, there are 1199 open tickets in Lighthouse, 898 open bugs, and 301 open patches. Oh yeah, and by the way, Rails has been basically overhauled and re-architected in its entirety (You might want to kick the tires a bit).

Stop whining about bundler. Stop complaining about the new routing DSL. Instead of taking the time to talk about everything that’s going wrong, put in the time to make it right. Here’s why you should pledge your three percent today:

It Makes a Better Framework

How confident are you in a framework that has 1199 open issues that aren’t going away? How much better would the framework be if developers like Jose, Wycats, and Koz were freed up to focus on the bigger picture? If you use Rails on a daily basis, your unique perspective matters, and you can help with the burden of all of these open issues.

It Makes a Better Community

Negativity is contagious. You can sit on the sidelines and complain about what’s coming, or you can get in the game and help make things happen. What stinks is that if there’s an obnoxious crowd heckling the players on the field, newcomers will be less inclined to jump in. Positivity can be a virus in the same way. If you truly love what you do and you’re grateful, exhibiting that makes the community as a whole better and it attracts newcomers to the project.

It Makes You a Better, More Marketable Developer

Knowing the internals of the framework you use on a day to day basis definitely makes you a better developer. There is no magic behind Rails, just smart design and Ruby. Consider pair programming with someone more experienced than you and how that impacts your performance. Now, imagine working with the leaders of the community on core functionality and how that can improve your skills.

Consider the benefits from a professional perspective as well. Do you think being a core contributor differentiates you in a hiring decision? If you’re a freelancer, does that provide you with something marketable over those still on the sidelines?

Get in the game. Pledge your 3 percent today and give back.

This post is for all the recruiters, hiring managers, and human resource professionals hiring developers today. At some point, someone decided that it would be cool or differentiating to post job listings asking for Rails Ninjas, Front End Hackers and Rockstar Web Developers. It’s an unfortunate practice to get your job advertisement noticed, and I urge you to stop.

For developers, words and names are important. From my personal perspective, here’s what these titles say:

• Rails Ninja – You want me to creep around the codebase late at night and inject transient bugs to foil my developer nemesis? Should I do everything on my own, or do I have an exclusive ninja clan that I hang out with? You want me to do everything my way, or the way that’s been handed down to me from centuries ago? So, basically, you want a lone wolf that goes about their business without any collaboration or direct engagement?
• Front End Hacker – Hacker? To hack a frontend project immediately resonates as short term fixes and solutions that aren’t elegant or user friendly. If you want to recruit hackers to do any type of coding beyond security and vulnerability detection, you’re in the wrong business.
• Rockstar Web Developer – This is probably the most prevalent and astonishing of titles – do you really want what this stereotype personifies working in your organization? I immediately associate this with someone that’s arrogant, self-serving, and apathetic. Besides, how effective can you be at solving problems at 9AM when you’ve been up until 4 the night before partying like a ‘Rock Star’? Please.

Some of these questions or perceptions may seem silly, but like I said, words matter. Stop using these titles! What value does this add to your job posting? What does it convey about how you perceive developers? Developers want to be respected and appreciated, not trivialized. Developers want to be understood and stimulated. Here’s three better titles that I guarantee will yield a better candidate pool:

• Pragmatic Programmers – (Note: this book is required reading for developers and anyone hiring developers) – Don’t you want to hire problem solvers? The best developers solve business problems with the simplest solution possible. They have a demonstrated history of making things work, and shipping. That’s what pragmatic programmers do.
• Motivated, Lifelong Learners – Technology changes. New platforms arise, and new languages and frameworks emerge. For the best developers, the technology doesn’t matter. As mentioned above, developers are problem solvers first and programmers second. Finding the best talent is all about finding people that can identify the best tools to solve problems, and they’re unintimidated when it comes to learning and evaluating them. These individuals are typically well informed and love to read. In almost all cases, they thrive on learning new things, inside and out of their industry.
• Social, Connected, Passionate Professionals – Books aren’t the only source of learning and discovery. For top notch developers, they realize the importance of community and engaging with peers. Exceptional talent will quickly get discouraged if they don’t have the challenge and stimulation of discourse with other stellar developers. Not to mention, connected individuals bring in more talent and great people. To solve problems, you have to communicate and collaborate. Sure, developers can tend to be introspective, but that doesn’t mean you shouldn’t like or connect with the people you work with.

Think about it from your own perspective for a moment. Can you picture yourself applying for a “CEO Rockstar”, “Recruitment Chef”, or “CTO Samurai” position? So, stop using silly titles. It only distinguishes you as someone who doesn’t regard software development as the art and science that it is.

Rails 3 is coming!

I’ve been doing a lot of thinking about how I can help clients get in a better position to upgrade to Rails 3 when it’s ready for prime time. There’s a few things you can do today with your 2.3.x application to give it more Rails 3 flava. Yeah boy!!!

Use Bundler instead of config.gem

Yehuda Katz has done a good job replacing config.gem with a more platform agnostic utility called Bundler. The API has changed around a bit with the latest 0.9 release, but he supplies a decent guide. For details on what’s changed since that writeup, check out this post from Yehuda

Use inherited_resources to get respond_with

respond_with will be a nice shortcut in Rails 3 for the rendering end of RESTful controller actions. Jose Valim’s inherited_resources actually gives you respond_with and respond_to methods for Rails 2.3.x applications. No more repetitive and un-DRY respond_to blocks

Use rails_xss

Unsafe strings will automatically be escaped by default in Rails 3. If you want this behavior in 2.3.x, all you have to do is install Koz’s rails_xss. It is surprisingly hard to break out of the habit of using h() calls in your markup, though! Additionally, be wary that you might have to hack some of your view related plugins to get them working with rails_xss.

Use More Named Scopes

Fortunately, ActiveRecord find() calls will soon be unfound in Rails applications. Pratik has done some really cool stuff with active_record. These changes are all pretty significant, but perhaps the largest deal is that the find() method and its relatives will be deprecated come Rails 3.1. One thing that is remaining a fairly consistent part of the API is named_scopes (despite a name change).

Developers should be encouraged to use named_scopes and association chains even more aggressively, now. It will certainly be easier to refactor a few named scopes around than it would be to refactor scattered find() calls all over your libraries. You should be doing this anyway, because it definitely helps with improving code and test quality

An excellent gem that can help you with this is Ben Johnson’s searchlogic. It gives you a bunch of very useful, canned scopes.

Replace references to RAILS_ENV, RAILS_ROOT, and RAILS_DEFAULT_LOGGER

Thankfully, these ugly constants have no place in a Rails 3 application. There are now methods to access these properties as part of the Rails module. So, for example, you would use Rails.env instead of RAILS_ENV

Nick Quaranto actually just wrote a solid article with the details on the Rails module.

Last night I did a talk on Thinking Sphinx at Boston.rb.

The slides are below.

Evan’s blog post with the benchmarks can be found here. There are links to other benchmarks and details.

The process library I alluded to is called God.

Other links

• Thinking Sphinx
• Sphinx
• Delayed Job (for delta indexing)
• Workling Delta Indexer
• Workling
• Starling
• Pat Allen

Let me know what you thought of the talk and the slides. I hope you found it helpful!

The first issue of Rails Magazine has been published. It looks like there is a lot of great content from some great authors.

I wrote an article about my switch from RSpec to Shoulda. A lot of issues I discussed have been addressed by both teams. Please participate in the discussion about the latest development in test frameworks.

I think it’s really cool that Rails now has a publication. Props to Olimpiu for putting it together.