Cygwin bash: inspect the contents of .gitignore files

When git complained

The following path is ignored by one of your .gitignore files:puppet/modules/postgresql

it neglected to tell me which file. I used bash find to search all of the .gitignore files in my project:

$ find . -name .gitignore -print -exec cat '{}' \;
./.gitignore
.vagrant
./puppet/modules/apt/.gitignore
*.swp
pkg/
Gemfile.lock
./puppet/modules/mysql/.gitignore
*.swp
pkg/
./puppet/modules/stdlib/.gitignore
pkg/
.DS_Store
metadata.json
coverage/
Gemfile.lock
.bundle/
vendor/bundle/

The "-print" option produces the file path, then the "-exec" option calls the "cat" command to dump the contents of the file, passing the file path to cat in the '{}' argument.

Vagrant: how to fix "VM inaccessible" error

I've hit an annoying error a couple of times when trying to "vagrant up" a box after waking Windows 7 laptop from hibernation:

Your VM has become "inaccessible." Unfortunately, this is a critical error with VirtualBox that Vagrant can not cleanly recover from. Please open VirtualBox and clear out your inaccessible virtual machines or find a way to fix them.

This message came from vagrant 1.1.5. Under the hood, vagrant calls the command-line VBoxManage utility provided by VirtualBox to manipulate the VMs. vagrant helpfully traps the error flag produced by VBoxManage and serves up that vague yet soothing error message. Although considerate, the message doesn't really help me diagnose the problem. Fortunately, when run in debug mode (set VAGRANT_LOG=debug then run vagrant status), vagrant will cough up all the nasty error messages from VBoxManage.

After some digging through the debug output, I discovered that even though the actual VM is intact (I can load and run it from the VirtualBox GUI app), somewhere in its guts, VirtualBox flagged this VM as "<inaccessible>". Vagrant, rightly believing what it's told, spits out the error message.

After looking at VBoxManage's help, I found that one its commands, list vms, unsurprisingly lists all of the VMs registered with VirtualBox:

$ /cygdrive/c/Program\ Files/Oracle/VirtualBox/VBoxManage.exe list vms
"precise64" {3613de48-6295-4a91-81fd-36e936beda4b}
"<inaccessible>" {2568227e-e73d-4056-978e-9ae8596493d9}
"<inaccessible>" {0fb42965-61cb-4388-89c4-de572d4ea7fc}
"<inaccessible>" {c65b1456-5771-4617-a6fb-869dffebeddd}
"<inaccessible>" {9709d3d5-ce4d-42b9-ad5e-07726823fd02}

One of those VMs flagged as inaccessible is my lost VM! Time to fix VBoxManage's wagon, by unregistering the VM as inaccessible, then re-registering it with the correct name:

1. Open the configuration file for your lost VM. Mine was saved to C:\cygwin\home\Philip\VirtualBox VMs\rails-vm-v2\rails-vm-v2.vbox
2. Find and copy the value of the uuid attribute of the Machine node. Mine was 9709d3d5-ce4d-42b9-ad5e-07726823fd02.
3. In a Windows command prompt (or Cygwin terminal), unregister the VM with the unregistervm command, using the [uuid] value from step 2:
   $ C:\Program Files\Oracle\VirtualBox\VBoxManage.exe unregistervm [uuid]
4. Now register the VM using the registervm command, with the path to the VM configuration file:
   $ C:\Program Files\Oracle\VirtualBox\VBoxManage.exe registervm C:\cygwin\home\Philip\Virtual VMs\rails-vm-v2\rails-vm-v2.vbox

Now you should be able to start the VM as expected.

UltiSnips requires multibyte support enabled in Vim

UltiSnips, a Vim plugin, is "an implementation of TextMates Snippets for the Vim Text Editor," according to its author. I had some trouble getting it running in Cygwin, especially with an error on a Vim variable &encoding thrown by the plugin's Python code, so I hope this post will help others avoid my problems.

Make sure that

1. Python 2.6.x or better is installed for Cygwin,
2. vim is compiled with the +python or +python3 configuration flag (as appropriate), and
3. vim is compiled with the +multi_byte config flag.

You can check vim's configuration flags by running this command in a Cygwin shell:

$ vim --version | grep -E '(python|multi)'

You should see something like

+mouse_xterm +multi_byte +multi_lang -mzscheme +netbeans_intg -osfiletype
+path_extra -perl +persistent_undo +postscript +printer -profile +python
-python3 +quickfix +reltime +rightleft +ruby +scrollbind +signs +smartindent
Linking: gcc   -L.   -L/usr/local/lib -o vim.exe             -lm -lncurses            -L/usr/lib/python2.7/config -lpython2.7 -lruby191 -lrt

The + signs on the +python and +multi_byte flags indicates Vim was compiled with Python and multibyte support.

The UltiSnips Vim plugin wraps a Python application to do the heavy lifting. It will fail if Python is not available.

In addition, if vim is not configured for multibyte code, then the Python code will fail on an empty Vim variable &encoding. See line 18 in this example:



Happy vimming!

Wow, that was f***ing fast!

Today I noticed a small error in a graphic included in section 5.2 of the Edge RailsGuide Getting Started with Rails. I raised an issue on the Rails Github project, figuring, OK, I've made my little contribution to the March of Open Source Goodness.

I was pleasantly surprised when Rails maintainer Steve Klabnik responded moments later that I had indeed caught a bug, as he'd done a couple of days before on another issue I'd raised (does this guy never leave his keyboard?). In the earlier case, the error was on my part, a semantic mismatch between using Rails 3.2.12 with the edge docs intended for the new Rails 4.0.0.

This time, after I read Steve's speedy response, I gave the RailsGuide page a reload, thinking, "OK, it' probably be a couple of days before that change gets committed."

I was astonished to see that not only had Steve committed a fix for the error, he'd used my screen grab to fix it. Major grin :)

Coming from a waterfall-ish project world where changes can take weeks and months to find their way to end users, I'd call this delight "moving at the speed of Rails".

Preparing for Ruby on Rails job interviews

There are lots of excellent books and websites that provide general help with preparing for coding interviews, but few discuss the expectations of Ruby on Rails employers.

Here are a few links to fill in that gap:

• Sandeep prepared a comprehensive list of Ruby on Rails Interview Questions, covering everything from Ruby language basics (What is a Symbol?) to Rails-specific questions (What is RESTful routing?) and Test Frameworks (What is an alternative to using test fixtures?)
• Toby Hede provided an excellent list of skills Rails developers should have at entry, mid and senior levels
• Suggestions for creating a project for your resume - I particularly liked George McDowd's suggestion: write a custom app, email the source to a prospective employer, then offer to walk them through the code to prove you'd written it
• Attend a Ruby on Rails Meetup group - I've done this a couple of times, and it's a great way to get a feel for the local Rails job scene.
• A peek behind the curtain! Actual Rails employer John Philip Green posted his 11 tips on hiring a Rails Developer, and Tim Goh shared his Practical Tips for Hiring Ruby Web Developers. While you might disagree with some of their criteria for an ideal employee, e.g., a personal blog on Rails, etc., keep in mind that this is what real live hiring managers are looking for in a Rails developer. These posts let you look inside the heads of people very like the ones who will interview you. Any insight you can gain into an employer's POV will only help you prepare to meet their expectations and needs.
• OK, not Rails-specific, but Sijin Joseph's Programmer Competency Matrix is a great 10,000 foot overview of the general skillz you should have, and Steve Hanov's massive list of five essential steps to prepare for your next programming interview will keep you busy for weeks.
• Edit (26 May 2013): An extensive and excellent list of Rails interview questions from Anil Punjabi's blog.

Many of the ideas for Ruby job interviews could of course be extrapolated to any software development interview. Happy hunting!

apropos and whatis for Cygwin

apropos and whatis are Unix-y commands that display a short description of other commands available on your system.

apropos is handy when you're looking for a particular function, say reading the contents of compressed files. It tends to be over-zealous with keywords, so for example, typing apropos compare compressed files returns 184 one line descriptions on my system. Typing just apropos compressed returns a more manageable 22 descriptions:

$ apropos compressed
bzcmp []             (1)  - compare bzip2 compressed files
bzdiff []            (1)  - compare bzip2 compressed files
...
zmore []             (1)  - file perusal filter for crt viewing of compressed text

whatis comes in when you know the name of an unfamiliar command, but you want a simple description of it's purpose:

$ whatis zmore
zmore []             (1)  - file perusal filter for crt viewing of compressed text

To use apropos (or man -k or whatis) in Cygwin, you must first create the whatis database by running the /usr/sbin/makewhatis command, probably with admin permissions to write the database.

Note (15 Jan 2014): apropos and whatis will not work from a Windows command prompt unless you've put the Cygwin bin directory ahead of the Windows and Windows\System32 directories in the PATH. Otherwise, apropos and whatis, which are shell scripts, will try to use the Windows 'find'command instead of the Cygwin 'find' command

After Oil - I'm published!

About a year ago, John Michael Greer, author of the Archdruid Report, challenged his readers to submit short stories envisioning life after the end of cheap petroleum, without descending into Mad Max apocalypse, nor relying on rescue by "alien space-bats."

My short story "Traveling Show" was among the twelve that John selected, and I'm happy to report that the book is now in publication and available from Amazon in Kindle, Nook, Smashwords and good old dead trees formats.

Many thanks to John for inspiring me to write a story, and to my fellow authors, without whom the book would not have been possible. Together we might part the mists to the kind of future where we'd like our children and descendants to live.