Benefits of Keyword Arguments

When I first heard about keyword arguments in Ruby, I’ll admit I regarded them as a bit of a toy. Part of this was because they were only supported by Ruby 2.0 (2.1 if you wanted required kwargs), and at the time most of my projects were using 1.9. But I also didn’t see, at first, how they fundamentally differed from using a params hash.

What are Keyword Arguments?

What does this do for us? The second and third options allow us to make a little trade. Instead of having to remember the order of the arguments, we just have to remember their names.

When Should I Use Keyword Arguments?

Is this a good trade?

It depends. From one perspective, connascence of name leads to looser coupling than connascence of position. Looking at it this way, keyword arguments are always a good trade.

On the other hand, look how much shorter and more readable option one is, both to define, and to call. There are particular circumstances that strongly indicate the use of keyword arguments:

First, if your method signature is likely to change. Adding new param, especially in the middle of the list, can break every piece of code that calls your method, or worse, introduce subtle bugs while appearing to continue to work.

Second, if you have a long list of params. It’s a lot easier to get two or three arguments right in a method call than six or seven.

Another Use For Keyword Arguments

Keyword arguments can also be mixed and matched with other types of parameters. This could be used to write Smalltalk/ObjectiveC type methods, possibly in a DSL as an alternative to the traditional currying style:

Traditional:  expect(thing).to_receive(:foo).with(1, 2)

Smalltalk-esque:  expect(thing, to_receive: :foo, with: [1, 2])

Posted in Uncategorized | Leave a comment

Wire Up Your Dependencies With Wiredep

One of my favorite tools for building Angular apps is Wiredep. Manually including javascript and CSS dependencies into an HTML file can be a pain.

It’s not that big of a deal, really, but figuring out which files a bower package provides, remembering their paths, and typing them into the right spot in the right file can break you out of your flow state in a hurry.

Assuming you’re already using bower to manage your dependencies, it will probably take less time to get wiredep up and running than it would to set up another dependency without it.

First, install wiredep:

Next, edit your top-level html file to tell wiredep to put the dependencies:

Now run the following:

Wiredep will insert all the CSS and javascript include tags for the files provided by your installed packages:

Rerun the command each time you install a package with bower instead of manually adding the includes.

Be sure to keep any non-bower includes outside the bower/endbower sections or they will be clobbered next time you run wiredep.

For bonus points, add a Grunt task so you can just type grunt wiredep . With grunt-wiredep, there’s even a way to update your karma.conf.js too.

Posted in Uncategorized | Leave a comment

self in Ruby

Using self in Ruby comes naturally if you’ve been writing Ruby for any length of time. It’s easy to gloss over its meaning and significance, however.

Take, for instance, the following class.

Why didn’t #blend_in work as expected? We missed a self. We should have written self.make = new_make.

It’s easy and sometimes tempting to memorize heuristics like “always use self. when calling a setter.” While rote memorization can help keep beginners from getting mired in the details, at some point it’s important to dig into the why.

Obviously if we leave off self., we’re assigning a local variable. But why does Ruby do this?

Ruby specifically tries to make setters look like regular variable assignments. In most cases, this makes Ruby very simple and elegant. It can also introduce ambiguity. Does make = new_make mean #make=(new_make) or does it mean ‘assign the value of new_make to a new local instance variable called make?’

There’s no way for Ruby to know. Did you notice I clarified the second case by writing it out in English? That’s because there’s no clearer, more unambiguous way to write it in Ruby. Because there’s no other way to write it, if Ruby defaulted to using a setter when one existed, there would be no way to define a local variable with the same name as a setter.

While it’s generally not good practice to do so, there are cases where it might be useful.

Using self in Ruby getters

So why don’t you need to use self. when calling a getter? In some cases, you do!


Posted in Uncategorized | Leave a comment

List of Online Code Checkers

We’ve all been there. There’s that one task you’ve been avoiding on your todo list. It’s not even that hard, to be honest. It just involves something finicky, fiddly, and unfamiliar. Maybe it’s a particularly tricky regex or a shell script that needs written. Luckily, it’s the 21st century and there are a plethora of resources to aid coders in these tasks. May I present The Big List of Online Code Checkers:

Devops Stuff

mod_rewrite Rules:
Shell Scripts:
SPF Record:
Subnet Calculator:

Runners up – local devops tools for checking syntax

Apache: apachectl configtest
Bind: named-checkconf /etc/named.conf
Nginx: nginx -t -c conf/nginx.conf
Postfix: postfix check
SSH: sshd -t – Use this every time if you don’t want to get locked out :)

Coding Playgrounds

These are great for spiking on a solution in a less-familiar language.

Collaborative Editor:
Regular Expressions:

Online Code Checkers, Formatters & Converters

CSS validator:
HAML to ERB converter:
HTML Tidy:
HTML validator:
Javascript Minifier:
JSON validator/formatter:
RSS/Atom validator:


robots.txt: Google Webmaster Tools
Structured Data:
XML Sitemap Generator:

This is just a small sampling of what’s available. There are online code checkers, validators, converters, formatters, and generators for just about anything you can imagine. Next time you find yourself with a dreaded task in

What online code checkers, formatters, or generators do you use on a regular basis?

Posted in Uncategorized | Leave a comment

Handling Exceptions in Ruby

Handling Exceptions in Ruby is Easy!

Exceptions are Ruby’s way of allowing us to attempt to recover from errors. The basic syntax for handling exceptions in Ruby goes something like this:

We can gather more information from an exception like so:

Notice we rescued StandardError and not Exception. There are many types of exception you might not necessarily want to rescue. For example, pressing CTRL+C or sending SIGTERM to the process would not work as expected and you might have to resort to SIGKILL.

Implicit Contexts

It’s not always necessary to explicitly type begin. Class, module, and method definitions and ruby blocks serve as implicit rescue contexts.

Rescuing exceptions is a good use case for a logger.

Multiple Exception Handling

You can handle multiple types of exception differently. Just be sure to put specific exception types before StandardError if rescue it.

Re-raising Exceptions

You can re-raise an exception after doing something with it. raise knows to re-raise the exception in the rescue context.


You can retry the error-prone task after rescuing.

Just be sure to check whether you’ve already retried first to avoid an endless loop if the fix doesn’t work.

Cleaning Up

In some situations there’s code that needs to run whether there’s an exception or not. The most common example is closing a file handle

Defining Your Own Exceptions


Use fail rather than raise to surface an exception unless you are reraising as above.

Posted in Uncategorized | Leave a comment

Using dotenv to store environment-specific config

What Is dotenv

dotenv sets environment variables from a .env file,  to be accessed via ENV in Ruby. Using dotenv allows you to specify important global, environment-specifc configuration settings like API keys and secrets, usernames and passwords, and URIs in a file that’s not checked in to version control. These settings can then be accessed at run time using ENV['VARNAME'] .

Oh you mean like config/database.yml or config/environments/**.rb in Rails?

A lot like that. However, those files are generally checked in to version control software. It’s not a good idea to have important production passwords in your repo.

Why Should I Use dotenv

Fundamentally, configuration is not part of your application. It doesn’t belong in the same repo as the app itself. Putting it there can create numerous problems:

  • Developers accidentally or naïvely committing changes that work for them but not others to a shared development-specific config file, breaking other developers’ dev environments
  • Configuration containing sensitive passwords getting accidentally checked into version control, potentially leading to a security breach
  • Creation of additional environments for QA, staging, etc. that are ‘just like production, except…’ leading to bloat and churn in config files

Using dotenv

  1. Add .env to your .gitignore
  2. Add dotenv to your Gemfile:
    gem 'dotenv-rails' if you’re using Rails or  gem 'dotenv' otherwise
  3. Create the file .env in the root directory of your project and specify variables inside, one per line, like so:
  4. If you’re using Rails, you should be able to access ENV['MY_CONFIG_VAR'] , but certain cases may require more tweaking, so see the readme if you have trouble
  5. If you’re using another framework or building a plain old Ruby app, add this somewhere that will be loaded before you need to access any variables:

  6. Set the same variables in a .env file for each environment (staging, production, etc.) and place these directly on each server (or with the code for configuring/provisioning servers)
  7. You’re done!

Strictly speaking, using dotenv in production is not recommended, so long term it may be worthwhile to find another way of setting the necessary environment variables. That said, many do use it in production without issue.

By way of example for step six, if you use Capistrano to deploy your app, the production .env file would live in the shared directory and be symlinked during deploy.

Posted in Uncategorized | Leave a comment

Building a Rack App / Ruby Web App

Have you ever wanted to build a super basic ruby web app? Maybe a single-page sort of thing, something that displays the temperature in your backyard or the number of emails in your inbox. The sort of thing where a simple HTML page won’t work, but a framework is overkill.

PHP got its start doing this sort of thing. While you can build object-oriented MVC frameworks with PHP, the reason so many people started using it was because if your server was set up for it, you could just rename index.html to index.php and paste in some code between <?php and ?>. Done.

Alas, it’s never been quite that simple with Ruby, but we do have Rack.

About Rack

What’s Rack? It’s how frameworks like Sinatra, Rails, Hanami, etc. talk to web server software. Or as the Rack website puts it “Rack provides a minimal interface between webservers that support Ruby and Ruby frameworks.”

Also from the Rack website, here’s a super simple Rack app:

This would go in the file This file tells the rackup command what to do to run your application. (Ever notice that Rails apps have a

The command ‘run’ tells it what to run. The thing it runs is a Proc that gets passed something called env, then returns an array with ‘200’ (as in the HTTP status code OK), a hash of response headers, and an array of strings.

While it does a great job of showing just how simple the interface is, the code above isn’t very exciting or useful. Let’s make something that does stuff! Inspired by, I bring you: Is it April Fools?

Building a Rack App

To start with, let’s write an index.html.erb:

Now let’s build something more classy/object-y than a proc. Here’s my_rack_app.rb:

In case you’re wondering, ERB#result accepts an optional instance of Binding, which lets us pass in our current execution context. That’s how we’re able to use the self.april_fools? method within the erb file. If we didn’t need this, we could just call #result with no arguments, and it would be given a new context.

Because we defined, the MyRackApp class will behave like a proc. This will allow us to make much prettier:

So easy!

Running Our Rack App

To see it in action, use the rackup command in the same directory as your rackup runs on port 9292 by default, so go to http://localhost:9292 in your browser to see it.

Posted in Uncategorized | Tagged , | Leave a comment

The Ruby Logger – Keep a log

You’ve used the Ruby Logger if you’ve ever built a Rails app, or even started up a development server and watched the output scroll by. But because Rails provides logging out of the box, it’s not often necessary to think about it.

If you’re building a plain old ruby app, however, logging is something you might think about implementing at some point. When that time comes, Ruby’s built-in Logger class has your back.

Instantiating a Ruby Logger

That’s all there is to it.

Of course instead of writing to stdout, you could also write to stderr, a file (and optionally set up rotation of log files) or even a custom class that implements write and close.

The custom class option is useful if you want to log to both stdout and a file, want to create a dummy log for testing, or if you are using something like highline to do your IO.

Configuring your Log

Severity threshold

Logger has the following severity levels from least to most severe:

Logger::DEBUG, Logger::INFO, Logger::WARN, Logger::ERROR, Logger::FATAL, Logger::UNKNOWN

These are the constants you can set the severity threshold to. (They correspond to 0, 1, 2, 3, 4, and 5 respectively, but use the constants whenever possible.) Anything below the severity threshold will be ignored.

Set the threshold like so:

Better yet, set environment-specific values in the environment’s dotenv file.

App name


The default is an instance of the Formatter class. If you want to specify your own, you can subclass Formatter, or use a proc. The following example would print only the message, ignoring everything else.

Sending messages to the Ruby Logger

The Ruby Logger has a method for each of the error levels

For more information, check out the documentation.

Posted in Uncategorized | Tagged , | Leave a comment

Shorten Map and Each Commands

Or: Pithy Procs for Working with Enumerables

Typing out code blocks every time you want to use map or each is a bit of a pain, and often unnecessary.

You may know that (1..5).map { |n| n.to_s }  can be rewritten as  (1..5).map &:to_s.

But what does the latter really mean?

The ampersand lets Ruby know you’re passing something to be used as a block and not an argument. It also calls #to_proc on the something. Symbol#to_proc is implemented in C, but for our purposes, it maps to something roughly like this:

Here’s another example:

(1..5).each { |n| puts(n) }  can be rewritten as (1..5).each &method(:puts).

Method#to_proc is also written in C, but the documentation includes a ruby equivalent:

What about something like (1..5).map { |n| n * 2 } ? (1..5).map &2.method(:*).

What else can we pass in? Anything with to_proc. Lambdas? Check.


Implementing #to_proc

Why not add a to_proc method to a command class?

In the above, only one PurchaseCommand is initialized; the same command is used for all items in the cart. It might be a bit clearer to write it this way:

This also allows us to hold a reference to the command for later use, if, for example we wanted do something with its shipment.

Not just for map and each!

This isn’t limited to each and map.

(1..10).partition &:odd?

Be careful, though. While arr.reject &:nil?  is shorter than arr.reject { |i| i.nil? } , arr.compact  is shorter still, and arguably more intention-revealing. At least if you know your enumerable methods.

Posted in Uncategorized | Tagged , , , , | Leave a comment

Reorder Git Commits Through Rebasing

The other day I was working on a pull request when I discovered I had forgotten something trivially simple that should have gone in the commit before the one I just made. If I hadn’t have made that other commit, I could just --amend it. I could git reset HEAD^, amend my commit, then restage and redo my second commit, but that’s a lot of steps and could get ugly in a hurry if the target commit was more than one commit back.

What would be perfect would be just making an extra ‘oops’ commit and squashing it later. But squash and fixup meld into the previous commit. If only there were a way to change the order of commits so I could squash as desired.

As it turns out, there is!

Reorder Git Commits with an Interactive Rebase

Reordering git commits is about as intuitive as it gets. Simply:

  1. start an interactive rebase – in my case with git rebase --interactive HEAD~3
  2. change the order of the commits in your editor
  3. save and quit.

You can even squash or fixup at the same time.

It’s even right there in the comments, though a bit opaquely: “These lines can be re-ordered; they are executed from top to bottom.”

‘Executed’ refers to the commands in your rebase (e.g. pick). So the reason this works is the pick command actually adds the commit. Order matters. I guess I always thought pick meant “yes keep this one” rather than “add this one to the end of the queue.”

reorder git commits - before


reorder git commits - after

Reorder git commits and fixup

As always, the standard history-changing caveat applies. If you’ve already pushed changes to a shared branch, you’re going to have to live with your oops commit. If you’re working on a private topic branch or you haven’t pushed yet, rebase away ;)

Posted in Uncategorized | Tagged , | Comments Off on Reorder Git Commits Through Rebasing