Setting up your development environment is always a tedious task. My own environment has changed many times over the years. I've recently gotten my Ruby-related setup to the point I'm finally really happy with it.

This is by no means a complete in-depth step-by-step guide of how to setup your environment like mine though. Instead it's meant as a quick reference of the tools I use, and how I use them. If you were looking for a magical silver bullet, this article is not it. If you're looking for an exciting adventure and treasure hunt, this article is hopefully it.

Ruby

I install and manage multiple Ruby versions with rbenv and ruby-build. They are not as established as RVM which has been around a lot longer, but I prefer rbenv for it's bare-bones simplicity. If you're coming from RVM, the main thing that you'll miss is it's gemset feature, which won't be an issue if you use Bundler properly. There is however a gemset plugin available for rbenv.

To install rbenv, check the ReadMe on the project page. I prefer the Git checkout method. ruby-build has installation info on the project page too, but on OS X I prefer installing it with Homebrew.

Once both are installed, you can install your Ruby version of choice, for example:

$ rbenv install 1.9.3-p0

Then set your global Ruby version:

$ rbenv global 1.9.3-p0

I tend to install a very basic set of gems, as all project-specific gems will be managed by Bundler. So obviously bundler needs to be installed:

$ gem install bundler

With rbenv this does not create the bundle executable however, so the next step is to run:

$ rbenv rehash

This creates the bundle executable in ~/.rbenv/shims, and also any missing executables for other gems you have installed.

Gem Management with Bundler

Bundler is fantastic, but if you just run bundle install as default, I would argue you're not actually using Bundler correctly as it installs the gems into your Ruby verion's gem path. One of Bundler's great features is that you can keep gems completely self-contained within a project. For that reason I use the --path option, to install gems into vendor/bundle relative to the Gemfile.

And because I'm lazy, I have a handy bash alias for my bundle install command.

alias bi="bundle install --path vendor/bundle --binstubs=vendor/bundle/bin"

The --binstubs option there leads me into how I avoid typing bundle exec before every command. It tells Bundler to package binaries from all the installed gems into vendor/bundle/bin directory within the project. Simply add the following at the very end of your ~/.profile or ~/.bash_profile:

export PATH="./vendor/bundle/bin:$PATH"

This enables you to call all of the project's gem binaries like normal, but they're Bundler aware, as if they'd been called with bundle exec.

I also have a few bash aliases for bundle exec ... which I find useful:

alias ru="bundle exec ruby"
alias ra="bundle exec rake"
alias rs="bundle exec rspec"
alias ca="bundle exec cap"
alias cu="bundle exec cucumber"

Update: Instead of using an alias to set Bundler options, you can set default Bundler config options in ~/.bundle/config. Mine looke liks this:

---
BUNDLE_PATH: vendor/bundle
BUNDLE_BIN: vendor/bundle/bin

Run bundle help config for more information.

Running Ruby Apps

For running web-based apps I use Pow and/or Foreman. Pow is my favorite of the two, but for certain projects Foreman is the better match.

I tend to go on a case-by-case basis. For example, some projects might need a few background workers, I tend to start all of them with Foreman, while I might run the web-based frontend with Pow.

MySQL, Redis, and More...

Because I run Mac OS X, I use Homebrew to install things liky MySQL, Redis, Memcache, and others. If you're not on OS X, you'll have to find your own preferred way to install these kinds of tools. But I'd imagine your operating system has some form of package management system you can use.

I was looking through my gists today on GitHub, and decided I'd do a couple of posts on some of the pieces of code I've put up there. The first of which is the sudome Ruby method.

Ever written a command-line tool in Ruby that requires root access for one reason or another? The simplest way to achieve this is to have the end user call the command via sudo. It's not the most elegant solution there is, but it works.

A more elegant solution might be what the Fink Project is doing with their fink command. It doesn't need to be run via sudo, as it calls it within itself. Meaning that when you run fink, you'll be prompted to type your password, just as if you had used sudo. Some might argue that this is not good practice, and they are probably right. But it all depends on the details of what you're doing.

A while back I was working on something which the best solution was to make sure the tool always runs as root. To get identical functionality as Fink, I wrote the very simple method shown below:

def sudome
  if ENV["USER"] != "root"
    exec("sudo #{ENV['_']} #{ARGV.join(' ')}")
  end
end

Simply call sudome as early as possible in your code. If needed it will re-run your script with sudo, requiring the user to type his password, at which point your script then has full root access to the system.

» Original Gist on GitHub

I finally found some time to rebuild my site, and add a blog. I'm also working on a portfolio, which I will probably be putting up on heartb.it. I haven't really decided how I'm gonna make the split between my personal site and work portfolio yet though.

For archival reasons I've made the previous versions of my site available for anybody who might be curious.

On an unrelated note, it happens to be my 24th birthday today, I haven't decided yet if that's a good or a bad thing. But at least I found time to push up my new site today, so I guess that's a good start at least :)

Powered by Dr. Jekyll?

My personal site has always been a very simple site. In the past it's just been a single HTML page which I've coded by hand and uploaded via SFTP. It's a simple process, and decently straight forward. This time however, I wanted to incorporate a blog as well. My first choice was WordPress, as I've used it on my previous blog. But it's overkill for what I need, and keept getting hacked all the fucking time even when I was keeping WordPress decently up to date.

So I'm using Jekyll this time around. Jekyll is a small website framework written in Ruby which generates static HTML files. It was created by one of GitHub's founders, and is used on GitHub Pages. Part of what makes it nice is that it's more intended to be a quick and elegant blogging engine, rather than just a static site generator. It let's you write blog posts in pure HTML, Markdown, or Textile. Meaning I'm writing this post in TextMate, which always puts a smile on my face.

I'll soon write a more in-depth article about Jekyll and how I'm using it.

Comments with Disqus

Since I'm using static HTML files, I'm left with only a few — but awesome — solutions to have a commenting feature on the blog. Both Disqus and Intense Debate have great Javascript-based commenting systems which work for static HTML sites. My favorite of the two is Disqus.

Deployment with Rake+Rsync

I've also opted for a much easier way to deploy to the live server once I'm done with changes locally. Namely, Ruby's Make program, Rake.

I've written a couple of custom rake tasks which run Jekyll to build the static HTML files, and to rsync said HTML files to the remote server. So instead of using a SFTP client, or something like Coda to upload and update the remote site, I simply run rake deploy from a terminal.

I get butterflies in my stomach whenever I think about how neat it is.

Source Code Management with Git

After being an avid user of Subversion for about 5 years, I switched permanently to Git last August when I spent 4 hours reading a PDF I had with me on holiday. So I'm obviously using Git for this site, and the source code is available on GitHub in all it's glory.

Design

I really focused on minimalism, to the point I'm not using a single image, but rather only text on a white background. This is a first for me, as I generally like to have nice rounded corners, or drop shadows, or something, but still simple and elegant looking.

Since the design in highly text-focussed, good typography was a must right from the start. I wanted to stray away from the standard web-safe fonts, to create a truly unique and elegant looking site in terms of it's typography. To do this, I needed to embed fonts, and I used the @font-face technique for it.

The two fonts I'm using are Colaborate for body text, and DejaVu Sans Mono for fixed width text and code examples. I got both from Font Squirrel's excellent @font-face fontkit page which has hundreds of free and ready to use kits.

The End

{insert yo mamma joke here}. Have a nice day.