Last time we packed a Rails application into a single file so that we can isolate bugs and easily share reproduction steps on GitHub or in a gist.
This time I wanna continue with the idea of crafting single files Rails applications that present an isolated topic by actually making them respond to requests. For that, we need to boot a webserver. Of course Rails has us covered here, since we can easily invoke
rails server in our terminal, and Rails will boot our app and make it accessible via HTTP. We only need to find the right lines that make
rails server work and invoke them in our app.
As you might know from previous posts, I keep a Rails playground project around. That’s a small application with a bunch of models, controllers and accompanying tests. It allows me to quickly try out a new gem that was mentioned in a blog post, see the effects of a configuration flag, or quickly prototype other ideas.
Sometimes however, even that very simple Rails application is too big. For example, when I want to share the application with friends or the internet. A default Rails application consists of a bunch of files that span multiple directories. That’s no longer suitable for a GitHub Gist or a simple email. Also, telling people to look at a bunch of files, but ignoring others, isn’t too easy. What’s important, what can be ignored?
Rails is a great framework and it’s really damn easy to start a new project, but I sometimes miss the beauty of Sinatra applications, where everything is contained in a single file - easy to ready, easy to modify, easy to share.
Turns out, there’s a way how to put all of your Rails application code into a self-executing file. I first discovered this while browsing the Rails’ GitHub issues, where people would share a self-contained rails application in a single file. Later on I noticed that those bug report templates are even mentioned in the Rails Guides.
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!