It’s programming 101 but it’s easy to miss in practice. If a condition has multiple expressions, some may never be evaluated. Use that fact to your advantage.
Rubinius 2.0 is on it’s way and it’s shaping up to be a serious contender. Adding support for Rubinius to your gem should be pretty painless.
Here at [i] it’s common for us to depend on support utilities like ruby-debug or perftools. Fortunately Rubinius comes with a very solid debugger and profiler. The best solution I’ve found is to use Bundler’s :platform rules to limit what libraries get loaded.
In the world of Ruby’s conditional assignment operators,
||= is Alec Baldwin; charming and versatile. But not many people know about
||=’s little brother… the
Mike Swieton recently posted Never say “Click” advocating the use of custom steps over browser-centric ones. I firmly disagree with with the consequences of that strategy.
In very few types of consulting do you wield such power and influence over the success or failure of the clients objectives as you do in software development. Intensifying the your power, is that fact that often the client is oblivious to that influence. This is a simple reminder how not to be seduced by the dark side.
Writing routes that are conditional upon whether a user is logged in is easy with Rails 3 but if you find yourself (as many of us do) stuck with a Rails 2 app, here’s how to achieve the same fancy routes without the latest Rails.
It’s no secret that we love user stories. We’re behavior driven and focus our daily tasks around user actionable stories. But near the launch of a project, or the end of a milestone, things can get hairy. Unmaintainable even. And workflow from the team can suffer, especially if there’s anyone working remotely.