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.
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.
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! :–)
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:
You create a matching key pair, a private key and a public key.
You add the public key to the list of authorized keys on the remote machine you want to access.
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)
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/id_rsa.pub.
The key fingerprint is:
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 id_rsa.pub, 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:
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 id_rsa.pub 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 id_rsa.pub into the next command, so that it can be used there. The common man usually calls this
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:
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! :–)
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
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.
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
To be more specific, these days I enjoy working with
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.