The other day I wanted to verify that a certain controller action returns a 404 response when a record isn't found. This is the default behavior for Rails applications - the framework will respond with the 404 code when it encounters an
ActiveRecord::RecordNotFound exception (read more below why this is happening).
Ever got frustrated by looking through your
db/migrations folder, searching for a specific migration, to see if it was applied to your database? Or you're afraid of running
db:migrate on production, because you're not sure which migrations it will apply? Every had to change a migration while developing, being constantly counting migrations because
db:migrate:rollback just isn't handy enough?
There's help via another Rake task, which is not mentioned in the Rails Guides:
In a previous blog post I've written about value objects and their benefits. Today I want to see how we can make use of those value objects within our ActiveRecord models.
Since Rails 5, there's the Attribute API, which lets us define - surprise,...
Sidekiq is probably the most popular background processing framework for Ruby. Not only is it fast and reliable, it also has the concept of a middleware, which lets you hook into the lifecycle of jobs.
Some of Sidekiq’s own features are implemented as a middleware, for example auto-retrying of jobs. We wanna start with something simpler, and add a middleware that simply prints the name and list of arguments provided of the job that’s about to be executed to the Rails log.
In the last couple of weeks I've repeatedly stumbled over a smell in a project I'm working on: the classifier of an object was inflected by the prefix of its name. As an analogy, think of the ISBN code, where groups of numbers have a special meaning.
rubocop is the de-facto standard tool when it comes to checking for coding style violations in your Ruby (on Rails) projects. It’s configurable and integrates with most editors via plugins.
And even though I’m using an integration for my editor of choice, Atom, sometimes it happens to me that I commit code that’s violating our coding styles. That’s kind of embarrassing and sets me back a couple of minutes each time (waiting for a CI run, checking GitHub, fixing the violation, waiting for CI again,…).
Wouldn’t it be nice to guard myself against this issue? May I present to you: pronto and git hooks!
Here's a typical scenario I'm facing with nearly every of my projects: I want to render some data in a header, footer or sidebar - like the total number of photos uploaded today, or the latest five reviews that were left on a site, or the latest five blog posts that were published.
Typically, I would solve this with a
before_filter in my
ApplicationController, fetch my data, assign it to an instance variable, add a partial which renders the data, and then include it in my application's layout.
Out of frustration with a stuck test on a Rails project I recently explored the possibilities of debugging Ruby scripts on OSX. There are various built-in ways how to debug (e.g. via
puts or more gems like
pry-byebug), but because I didn't want to deep-dive into the project I wanted to stay with built-in tools that ship with my operating system.
The first thing I could remember about system debugging was
gdb, or also known as the GNU debugger. OSX no longer ships with gdb or any other tools of the gcc toolchain, but instead uses the LLVM toolchain. The substitute there is called
lldb. Getting started is actually quite easy, as you've probably installed XCode already and so you also have
Oftentimes there are multiple ways to achieve the same thing in Ruby. For example, one thing I've recently tried to make a habit of is to use
#zero? when checking if a value is, well, zero. It definitely reads nicer than doing a
value == 0 comparison, but is it also faster?
Keeping the source code of your application in good structure is important. But structuring the code of your test might be even more important: When I'm new to an app, my second look is at the tests, to both see what's the level of coverage and to...