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...
Sooner or later you want to pages to your Rails application that are not created dynamically, but rather contain either some marketing information, legal info like imprint or terms, or even feature some sales copy you call your homepage.
When rendering your
ActiveRecord models in your controller as JSON you often wanna include more than just the default attributes that calling
#to_json on the model gives you. There are various hacks described on Stackoverflow, like overriding the
#serializable_hash methods, two of which I can even find in my current (legacy) project.
Today I wanna show you the OOP way how to do this. Spoiler: We'll create a class.
In all of my projects, I have some data that my tests heavily rely on: things like a list of currencies, shipping methods, a pre-defined list of roles, and other things that never change or very infrequently.
When writing tests, I do not want to create the same record from my factories over and over again for each and every test, but instead just have it available. How do you do that?
Having recently upgraded a legacy Rails project from 3.x to 4.2.x, one of the biggest benefits is that I can finally use some nice additions to
ActiveRecord. One of my favorites is
#distinct, which, as the name says, will return
DISTINCT records for...
I was recently called for help to update a gem in a Rails application I wrote a couple of months ago. It was important to only update a single gem (which had a known security vulnerability) and not touch any others, as this would have triggered a complete...