Marcel Fahle

Snippet: Compare Model Instances in the Rails Console Using Sprintf

Today we had some technical problems with one user account on Jumblzar (albeit our testing suite), and I wanted to check out this particular user and compare the individual attributes with a user that didn’t have these issues. Since our User Model has around 50 attributes, I wanted a side by side comparison with the working user.

sprintf to the rescue!

I don’t use sprintf in real life very often (even though I probably should), but here it came in handy. What I basically do is, I iterate over the attributes of one of my two user models, u (the working one) and u2 (the faulty one). I then throw the attribute name, as well as the assigned values of each user model into sprintf and format the output with "%26s - %42s || %42s", which basically means “the first parameter you send me is a string and we make it 26 characters wide, and the other two parameters (the actual values) are gonna be strings each 42 characters wide”. Et voilĂ , a nice side by side comparison of my user models in just a few minutes – here a little excerpt:

A side note: By default Array#each returns the original array at the end of the iteration, and since the console always returns the return value of the last command, we would see a whole lot of gibberish right after our nicely formated list. So instead of feeding the console the original array from the iteration, I just add a nil after the block, so rails returns that.

Projects Galore and Resume

I finally added a bunch of projects to my portfolio to get you a better idea of the work I’m doing. There will be much more in the near future and I’m even thinking about a Hall of fame kind of thing, where I show some really, really old stuff, just for the fun of it (it is actually quite funny!). It takes a while to find all those things in my archive though, as I piled up a good bunch of projects over the last 16 years. I also added a resume (finally!), as I’m actively job hunting right now! So if you, or anybody you know has a fun freelance gig, shoot me an email. Thanks! :–)

What’s Up With Those SSH Keys?

Alright kids, let’s kick this off with some basic shell-fu, which will serve as a good foundation for things to come: SSH Keys and how to properly use them for authentication.

Up until two years or so ago, I actually didn’t know much about it, so I guess it’s not so super-basic after all (or I’m just a bit behind). Either way, SSH Key authentication is good, m’kay and it basically works like this:

  1. You create a matching key pair, a private key and a public key.
  2. You add the public key to the list of authorized keys on the remote machine you want to access.
  3. If then the private key on your computer matches the public key on the remote machine every time you try to login, you’ll be granted access.

Easy as pie. And besides being more secure than the regular password authentication, it is also a ton more convenient. So let’s dive into more detail, shall we? (Note: I’m working on Mac OS X here)

Key generation

SSH Keys are a pair of cryptographic thingys that look basically like a bigass string stored in a file. You create your keypair with ssh-keygen, which gives you a ton of options to create, manage and do all kinds of stuff for your authentication key pleasure. Just run man ssh-keygen to learn about all available options and the types of keys you can create. Us being total rookies, we just use the basic stuff and focus on RSA keys, which is probably the most common cryptography algorithm for SSH keys and definitely what all the cool kids use these days.

To generate your keys, open a Terminal window and cd into the .ssh directory, underneath your home directory.

$ cd ~/.ssh

If the directory for whatever reason doesn’t exist, just create it.

$ mkdir ~/.ssh

Now run the magic command. I’ll explain what happens below.

$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/yourusername/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /Users/yourusername/.ssh/id_rsa.
Your public key has been saved in /Users/yourusername/.ssh/
The key fingerprint is:
xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx user@host

So, we run ssh-keygen with the -t option to set the type of keys, in this case rsa. For me rsa is also the default option, so -t isn’t really necessary, but the command looks more impressive that way. It then asks you where to store the key, where the default is fine, so confirm by hitting the Enter-Key. It’ll then create two files, id_rsa which is your private key – the one you’re not supposed to give to anyone, not even your mom – and, your public key. Feel free to hand this one out like flyers to your next party.

Afterwards you get asked for a passphrase, which is basically like a password to use your key, except you’re not really limited on what kind of characters you can enter. The passphrase is totally optional, but every geek in the world will strongly suggest that you go all nuts here and enter something different than your birthday or the name of your dog. Whitespace, punctuation, weird characters, hell, I think even chinese characters are allowed in here. Enter it a second time to confirm and you’re done.

Other common options here are:
-C comment to add a comment to your key, usually used as description of who created the keys and when. -b bits Specifies how long the key is in bits. 2048 is the default and totally cool. -p Lets you change the passphrase of your private key.


So how do we use our shiny new keys for authentication on a server now? Well, we just have to tell our server all about your new public key, which means, we have to add it to the list of authorized keys of the user you’re planning to access the server with – we’re using the root user in this example. To do that, we can just use one kick-ass ninja command:

cat | ssh 'cat >> .ssh/authorized_keys'

Pure Magic! Here’s what it does: the first part to the left of that vertical bar thingy (pipe) usually prints out whatever is in the file, but instead of printing it out into your Terminal window (some smartass might call it STDOUT), the vertical line forwards whatever comes out of cat into the next command, so that it can be used there. The common man usually calls this “piping”.

So now that public key gets “piped” into the following ssh command, it logs you as a root user onto your server (this is the only time you have to enter you root password), and then executes another command – that’s the stuff in the single quotes: 'cat >> .ssh/authorized_keys'. And here the cat “cats” our output from the first cat command and appends (that’s what >> does) it into a file called authorized_keys, which lives in the .ssh directory of the user’s home directory. authorized_keys holds, as the name might suggest, all the public keys that are allowed to log into your server, of course only regarding the user that file belongs to – in our case root.

In the case that you’re greeted with an error message, that the .ssh directory doesn’t exist, just hack a more advanced version of our ninja command into your terminal, to take care of the creation of this very directory:

cat | ssh 'mkdir .ssh; cat >> .ssh/authorized_keys'

Either way, that’s all there is to it. And now, it’s time to…

Use the keys, young Skywalker

That’s really the easiest part of this article. You can now just log into your server with the standard ssh command without entering a password at all:


And that should do it! I could probably philosophize hours about why it’s bad to use the root user for this, or how to make your server more secure, but in case I ever wanna make some serious coin with this blog, I better write another article for that stuff. But for now, it’s time to say goodbye. Comments, Facebook likes, Retweets and whatever else helps making me rich and famous, is much appreesh! :–)

Custom Compilers With CodeKit

Recently I needed to do some static HTML stuff and wanted to use Haml for this. LiveReload, which I’m using since quite some time, lets you setup watchfolders and compiles all kinds of stuff for you like CoffeeScript, LESS, Sass and Haml. Unfortunately it would only accept the hash syntax used in ruby prior 1.9 and that’s because LiveReload uses my system ruby by default, which is 1.8.7.

shit adds up
%html{lang: 'en'}
%html{:lang => 'en'}

It gives you the option to switch to another ruby version, but doesn’t support installations via rbenv (it will probably be introduced in version 3 of LiveReload). I read somewhere that RVM is supported, but I can’t validate this.

Long story short, I needed a different compiler to take advantage of the new syntax. Since I like the watchfolder simplicity of LiveReload, I took a look at CodeKit. From what I can say right now is, on the compiler end it does basically the same thing as LiveReload (please correct me if I’m wrong, I’m only using it for like 5 seconds), but offers a bit more flexibility when choosing your compiler. In my case I just went into the settings for Haml and pointed to the Haml binary inside my latest ruby installation (~/.rbenv/versions/1.9.3-p194/bin/haml), et voilĂ : Ruby 1.9 syntax in Haml.

Hello World

The blog is back, yay! Unfortunately I wasn’t able to save the data from my last blog, but that doesn’t really matter since the subject will mostly change anyway. It will still be mostly work related stuff, but since I shifted away from AS3 programming a while ago, most of the things you’ll find here is Ruby and JavaScript related.

To be more specific, these days I enjoy working with Rails, CoffeeScript, backbone.js and the shell, so expect a lot of that. I’ll also put all those things in here, I learned in my daily work life and want to remember in the future. That could range from highly advanced jedi tricks to absolutely beginner one-liners even your mother knows, but somehow I happened to just find out about. If I want to remember it, it’ll land in here, no matter how trivial it is.

So that paired with a few paragraphs on the projects I’m working on here and there and some personal things I’m interested in, like filmes and books and stuff, should lead to a collection of pretty awesome content, don’t you think?

Oh, and I’m doing the whole thing now in Octopress and vim, so bear with me if the look and feel of this blog will change a lot in the first days/weeks.

That being said, thanks a lot for stopping by and I hope you enjoy the ride.

Marcel Fahle, August 2012