Is sloppy written code slowly creeping into your codebase? Finding tabs in your source files, but the team is using spaces? You research on a freshly merged PR, but the code has zero comments on classes or modules?
I’m guilty of all the points raised above. I’ve previously written about how you can use Pronto to check for style violations when committing your code.
Truth be told, the solution detailed in that blog post isn’t for everybody, and doesn’t work in all situations. You might be in a hurry, cause you need to pick up your kids from school, and you just wanna commit that code and push it. You ignore the warnings raised by RuboCop, and send it off for your team to review.
What if there would be somebody reviewing your PRs, leaving you actionable comments on violations, and even giving you and your team the chance to discuss the bad spot in your code, even ticking it off as “good enough for now”?
Luckily, Pronto can do it all. In this blog post I’ll walk you through the steps to integrate Pronto with Codeship and GitHub. I’m assuming you already have your tests running on Codeship’s platform.
2016 was the second year I worked as a freelance developer. Of course my previous roles in companies involved some level of development, but I often considered those to be too quick & dirty (prototyping ideas for applications in safety critical environments) or as a temporary solution (CTO in a tech startup, after-work co-founder).
I still learn new techniques, new tools and gain new insights (e.g. into Rails) every single day, but here are five habits that I developed over the last years that help me to do a better job. It’s not so much about specific know how, more of a mindset to know your tools, and keep on pushing to get better.
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