RVM and “[gem] not found” errors

tl,dr: If your gems aren’t being found, check that you’ve got a current Ruby in RVM.

I had some fun tracking down why my installed gems were not being found today. I do my dev work in a virtual machine (VM) that handles most of the work with gems, but there are some commands that are run only from a physical machine, such as Capistrano tasks for deployment to our various servers. I wanted to put a patch on the staging server, and ran into the following:

bundle exec cap staging patch:apply FILE=patch.diff
zsh: command not found: cap

I checked that I had Capistrano installed by running gem list, and I had it. So I tried
bundle exec cap staging patch:apply FILE=patch.diff
zsh: command not found: bundle

I thought it was related to my terminal, maybe a bad path, some kind of RVM issue. I Googled around for RVM path issues with ZSH, and couldn’t find any places my configurations differed.

Eventually, I went to double-check which Ruby RVM was using, and got this:

$ rvm list

rvm rubies

* ruby-1.9.3-p448 [ x86_64 ]

# => - current
# =* - current && default
# * - default

Well, that’s interesting! I didn’t have a current Ruby! So I ran rvm use default, and lo and behold, my cap commands worked again.

New vim line numbering options

I was at the fantastic CSSconf.eu on Friday, and one of the presentations include code in Vim with a line numbering setup that blew my mind. It showed the current line number as an absolute number, but showed all other lines as relative numbers, making it super-duper easy to go up or down N lines in normal mode.

I asked the presenter how it was done, and was told it was “part of the SPF13 bundle.” So today I looked it up, but no luck. There was no plugin included to change the line numbers. Time to do a little more digging! In fact, there was a change made to Vim itself in version 7.3.1115 to allow more customization of line numbers. Here’s how it works now:

patch 7.3.1115 changes the ‘number’ and ‘relativenumber’ options so that instead of resetting each other, they interact with each other, so that 4 different displays can be achieved:

both set: relative numbers + absolute number in current line
relativenumber only: only relative numbers, 0 in current line
number only: only absolute numbers
neither set: no line numbering

—vim_dev Google Group thread, message on 25 June 2013 sent by Ben Fritz

Result: for totally sweet line numbers, just update your Vim and put set relativenumber in your .vimrc file!

Edit: To clarify a bit, the old behavior for relativenumber was to show 0 for the current line number, and that wasn’t modifiable. Setting number just switched you back to absolute line numbers.

IE9, JQuery/JavaScript, and broken select boxes

I hope nobody else has this problem, but just in case, here’s the thing I had to diagnose this afternoon: a few select boxes (those things that drop down a list of options and you choose one) were immediately closing themselves in IE9, which prevented changing their options. It only happened in IE, but I noticed the same elements were causing strange behavior in the Chrome developer tools—computed styles couldn’t be expanded, the attribute checkboxes were flickering, and the JS console was slow and stuttery when opening it with ESC). That behavior tipped me off that there was probably something strange happening in our code, not just in IE. Turns out that to automatically check a text input for matching content in our database, someone had implemented a jQuery function to run every 250ms, and that’s somehow interfering with the select elements. It’s not solved yet, so look forward to an update after I find a solution that (hopefully!) keeps all the functionality intact.

Update: I was unable to find the real cause of this problem. I worked around it by checking for a text match only on blur (when the text input loses focus, i.e., you click or tab away from the input field). This solved the problem, and had the side benefit of reducing the calls to the server, particularly because using JavaScript’s setInterval meant the function kept being called, even after the modal dialog had closed!

Berlin Geekettes: Women in Tech panel, part 2

Oops! I was in such a hurry to post the video yesterday that I didn’t realize it was only the first half of the talk! Here’s part two.

Berlin Geekettes: Women in Tech panel from Campus Party Europe

Here’s the video for the Berlin Geekettes panel I spoke on last Thursday at Campus Party. I hope the sound is ok; the acoustics of the space left something to be desired.

Topics of discussion include stereotype threat, “having it all” and what success means, and how to get more women involved in tech.

EDIT: There’s a second part to this video, which can be seen in my next post.

I Am Rails (And So Can You!) at RuLu 2012

I don’t know if the video from Campus Party Europe is up yet, but this from when I gave the same talk at RuLu in June.

Ordering CSS pseudo-elements (and pseudo-classes)

Look out for the order you use CSS pseudo-elements in, or you may not get the results you want. Today, I found that using li:before:first-child doesn’t work to style the :before pseudo-element on my first li, but li:first-child:before does.

Rather than chaining together the way something like .title.example (which would select element with both classes “title” and “example”, regardless of order), the pseudo-element order matters. So li:before:first-child is styling the first child of the li:before element, while li:first-child:before is styling the :before pseudo-element on the first li.

In fact, in looking up the documentation to link below, I realized that :first-child is actually a pseudo-class, rather than a pseudo-element. The docs below don’t state it, but it’s possible that in order to get correct behavior, the pseudo-class should always come before the pseudo-element.

References:
pseudo-class
pseudo-element
:before
:first-child