Marnen Laibow-Koser's Journal

I'm getting my Rails dev environment set up on Elementary OS. That means SublimeText, RVM, PostgreSQL, Git, and Zsh.

These are some quick thoughts about the installation.

SublimeText downloads a usable binary, but there's no automated way to get it into the application launcher menu (which I believe needs creation of a .desktop file). Fortunately, a Web search turned up both some .desktop files for SublimeText and something even more convenient: a PPA that automates the whole process.

RVM and Zsh also installed easily. I also installed GNOME Terminal (because it's more configurable without resorting to editing config files) and App Grid (because Software Center is slow and crashes).

I tried to install PostgreSQL 9.3, but kept getting postgresql-common version conflicts. After a lot of time wasted in Web searching, I finally wound up forcing compatible versions by doing sudo apt-get install postgresql-client-common=154.pgdg12.4+1 postgresql-common=154.pgdg12.4+1 postgresql-9.3. Why did apt-get have to be so boneheaded? Why couldn't it determine that version 154 was available in the sources it had?

PGAdmin installed well, and I was able to use it to connect after configuring the Postgres superuser to have a password (why isn't Postgres installed like this out of the box?).

I also installed gitg, which looks like a nice replacement for GitX on Mac OS, though I'd prefer that the branches were in a sidebar, not a menu.

Ruby gems mostly installed as expected. I had to install the libxml2-dev and libxslt1-dev packages to get Nokogiri to build, and Curb (unsurprisingly) required libcurl4-openssl-dev. The pg gem, of course, required libpq-dev so it could talk to Postgres, and RMagick required libmagickwand-dev.

At this point, VM performance was getting kind of bad, so I raised the RAM to 1.5 GB. Hopefully that will help.

When I tried to run Rake on one of my Rails projects, I found that it needed a JavaScript runtime. Information I found on the Web led to me installing the nodejs package, which did the trick (and also means I can play around with Node development, which I've been wanting to do).

This probably won't be of interest to anyone who isn't a Ruby on Rails developer, but since it seems that the thing to do in the Rails community is share tips in blog posts, I thought I might as well jump on the bandwagon.

content_for is a great method to use in Rails views, but I found it hard to test in RSpec -- I couldn't mock the right object to test for the method call, and I couldn't figure out how to get the content variable out of the response. Then I stumbled on RSpec patch 12701, which was incorporated into RSpec releases some time ago (it's in 1.1.3, certainly, and I don't know how far back it goes). It seems that while response can be tested for the main body of the response, anything defined with content_for is available as if it were a hash element. So if your view looks like:

<% content_for :sidebar do %>
  <p>Here's my sidebar text.</p>
<% end %>

<p>And here's my main content.</p>

describe "my view" do
  before(:each) do
    render 'myview'
  end

  it "should populate the body content" do
    response.should have_tag("p", /main content/)
  end

  it "should populate the sidebar" do
    response[:sidebar].should have_tag("p", /sidebar/)
  end
end