I’m feeling inspired by the recent Smashing Magazine tribute to _Why and a tweet from Ray Hightower about another developer who blogged about his month of new technology. I want to challenge myself to do the same. It’s time to get back to creative exploration.
The last 3 months have seen almost every spare moment at home given to wrapping up open projects from the consulting business I closed down early this year so I could focus on my new job. It’s been a tough road, making sure that my leftover client work didn’t intrude on the workday.
I have 4 projects about 95% complete and a small site that’s 60% done. It looks likely that I can wrap them all up, Lord willing, by the middle of June. In that time, I will also give away what’s left of my hosting clients and may be done managing servers! That will finally leave time for fun and exploratory coding as well as putting in extra time at work now that we are hitting crunch time. I’m SO looking forward to no longer being pulled in a dozen directions.
Unlike my previous mode of building new web apps that could become subscription services, I’m planning to release all my stuff on GitHub (I just open sourced the code to Am I Down and will probably release my filtering Twitter Proxy this week). The practice and fun of creation are what i want most. The idea of adding a new business that im responsible for sounds awful.
The next few months will be great!
UPDATE (7:21pm):So…I find out that RVM symlinks into .gem/, so deleting completely may have been a bad idea. But…I was able to do “rvm reload” and “rvm update –head” that seem to have restored the symlinks I broke in the process. Life is good again.
While trying to install the latest Rails3 beta, I was beating my head against the following error:
ERROR: While executing gem ... (ArgumentError)
marshal data too short
I’m running RVM and despite attempts to run “gem install rails –pre” on various ruby versions, every time I got the some error.
After bruising my head against nearby objects for a while, I found a small reference on a blog about gems in ~/.gem. After wiping them out, everything worked great! In the process, I blew away /usr/local/ copies of the gems as well (so your mileage may vary).
I decided to try out Rackspace Cloud for a new worker server that Am I Down needed. Since I wanted to keep the system tight on memory usage, I decided to go with Ruby Enterprise Edition. Unfortunately, I ran into a snag getting it installed via RVM (the terrific tool for running multiple versions of Ruby).
I kept getting this error after running “rvm install ree”:
Error running './installer -a /home/username/.rvm/rubies/ree-1.8.7-2010.01 --dont-install-useful-gems ', please check /home/username/.rvm/log/ree-1.8.7-2010.01/install*.log
There has been an error while trying to run the ree installer. Aborting the installation.
I couldn’t find anything on how to fix this as I poked around Google. Since I use zsh (via the amazing Oh My Zsh project), I figured that had to be conflicting with it. I did resolve one issue caused by the old version of zsh installed via “sudo aptitude install zsh” by compiling zsh from source (a newer version).
The Solution: Install Readline headers
But…back to the issue at hand. The solution became clear when I tried to install REE from source. The REE installer complained about missing “GNU Readline development headers”. Running the installation for readline fixed it.
sudo aptitude install libreadline5-dev
From there, RVM installed REE no problem.
Update (3/5/2010): Wayne, the author of RVM kindly wrote to me on Twitter within hours of this post to see if there was some working improperly with RVM. It turns out that I missed a clear set of instructions that indicated the need to install readline5 when using REE. Thanks Wayne!
If you use Cucumber, chances are good that at some point in your testing, you needed to verify that a certain set of database records had been created. While this flies in the face of most BDD best practices, I’ve run into a few edge cases the last few months that required this level of minutia. Ideally, you’d use RSpec or Test::Unit for checking database/model level details, and let Cucumber focus on the higher level full stack checking.
In my case, I needed to verify that the admin tool I’m creating builds records necessary for the public side of the site (which hasn’t been built yet). There really wasn’t any visibility in the admin area to this data, except when it’s created. While I did have a solid set of RSpec tests for the model functionality, I felt it necessary to make sure those model methods were called correctly through the controllers and routing that went on.
As a result, I wrote this step:
Then /^I should find these "([^\"]*)" records$/ do |model_name, table|
model_name.constantize.count.should == table.hashes.count
table.hashes.each do |record|
model_name.constantize.find(:first, :conditions => record).should_not be_nil
end
end
You would use it in your Cucumber feature like this (intentionally bland example):
Then I should find these "Post" records
| title | permalink | category |
| A blog article | a-blog-article | Technology |
The first row specifies the fields that will be used as conditions. The following rows will be used to search against. The step will make sure that at least record in the model matches. It will also verify that the number of records in the model matches the number of rows in the Cucumber feature.
