If you find yourself needing a backend interface, you can either get an admin plugin of the shelf, like
RailsAdmin or ActiveAdmin, or
build your own. The of-the-shelf options provide a lot of functionality and are really worth a look.
You can also build your own backend. Building your own gives you maximum freedom. It requires a bit
more work, but it might be preferrable, especially if your customer also needs to work with it.
There are some awesome tools out there to help you build your own backend. I'll show you how I would
go about making such a backend. I'm using Rails 3.1 (the rc5 at this moment) on Ruby 1.9.2. I might
gloss over some details here and there, so use your own expertise to fill in some gaps.
→ read more
Jeff Kreeftmeijer talked about Cucumber
and Steak at the last Amsterdam Ruby
Meetup. He hit upon an important theme in software development:
reducing complexity; in this case the extra layers of complexity introduced by Cucumber
features and step definitions. And he's absolutely right. If you don't need the natural
language Cucumber provides, then you should get rid of the extra complexity and use Steak
instead.
As much as I agree with this, I think there is a way of using Cucumber that makes it a valid option
to use it in more cases than you think. It's for doing Behavior Driven Development with a high focus
on the problem you're trying to solve. Let me explain what I mean by this.
→ read more
TL;DR: I've just released metrical. It is a tiny wrapper
around metric_fu.
MetricFu is awesome. It helps me keep my code clean by identifying problem spots in my code.
Unfortunately, it's difficult to get running. MetricFu requires to be run with Rake. But by doing
that, it becomes part of your project's dependencies. Especially if you're using Bundler.
→ read more
If you're testing arrays a lot, like ActiveRecord's (named) scopes, you should know the following RSpec matcher: =~. It doesn't care about sorting and it gives you all the output you need when the spec fails. Here is an example:
→ read more
About once a month I read an article on comparing Ruby to another programming language. Usually it makes the point that Ruby is dynamic and open and therefore it is less suited for reliable applications for big companies with big needs.
To me this sounds like a professional carpenter saying that a chainsaw is less useful for making big things because you can hurt yourself with it or make a big mistake more easily. While it might be true that these things can and do happen, it's not a definitive reason not to use it. And while other tools might be better at a certain task, it can still do the job just fine.
With great power comes great responsibility. I cannot lecture you on the precautions you need to take when using power tools, but when it comes to software development the things you need to do is testing and refactoring. I believe this to be true for every programming language, just as you always need to be careful you don't hurt yourself or others when you saw something, no matter which kind of saw you use.
→ read more
Want more?
See the rest of the articles.