Rspec provides another (and sadly perhaps lesser known) facility for accomplishing the same end in a more efficient fashion. The lazily evaluated let(:symbol) {block} provides a way to extract objects (especially the current system under test), especially those which are used in multiple examples within one or more describe blocks, but perhaps not every example within a given describe or context.

The reason this is more efficient than an instance variable in a before block is that before blocks are executed on each test run, so those data values instantiated regardless, times n examples. That’s assignment cost, memory cost, and parsing cost.

Lazily evaluated blocks only incur cost when they are used. That is to say the parse cost is incurred regardless, but assignment and memory cost are only incurred in the examples which use the values returned by the instance methods that let() creates. It is easy to factor example 1 to use let blocks instead of a before block (and looks cleaner, in my opinion.)

Another benefit is that lazy evaluation provides a facility to pass different data in from each spec, since the block is evaluated when the method is called, which can be after some individual setup occurs.

As you can see, let() can be a very powerful and useful construct, if properly employed. I first discovered let() in a slide deck entitled Pure RSpec. Check it out for this and other fun RSpec goodness, and as always, happy hacking!

it "should define ACTIVITY_LEVELS" do
  Game::ACTIVITY_LEVELS.should == %w{ Low Medium High }
end
it "should define FORMATIONS" do
  Game::FORMATIONS.should == %w{ Circle Lines Scattered None }
end
it "should define LOCATIONS" do
  Game::LOCATIONS.should == %w{ Indoor Outdoor }
end

which now bothers me; whitespace separation between example blocks feels more idiomatic. In fact, someone asked me after seeing those specs “are you in a fight with whitespace?” I am not.

Also, I don’t like “should” in descriptions. Too wishy-washy sounding, and again, superflous. Speaking of superflous, spaces between curly brackets and their contents… they are it.

Really, does reading the first example require that much more effort than the second?

{ :some_key => "some value" }

vs

{:some_key => "some value"}

Call me crazy but it saves two keystrokes and just looks better to me without the spaces. Style call. YMMV.

Another thought on idiomatic tests for equality in Rspec examples suggests using the appropriate “eq” and “eql” matchers instead of the equality operator (“==”) so that’s made its way into muscle memory lately as well.

So, given the above, were I to refactor or rewrite those specs today, they would look like this:

it "defines ACTIVITY_LEVELS" do
  Game::ACTIVITY_LEVELS.should eql(%w{Low Medium High})
end

it "defines FORMATIONS" do
  Game::FORMATIONS.should eql(%w{Circle Lines Scattered None})
end

it "defines LOCATIONS" do
  Game::LOCATIONS.should eql(%w{Indoor Outdoor})
end

Looks a bit cleaner to me, probably good enough.

However, since the description isn’t really giving us any brilliant insights about the behaviour the specs are verifying, those examples could probably be factored into specify blocks:

specify {Game::ACTIVITY_LEVELS.should eql(%w{Low Medium High})}
specify {Game::FORMATIONS.should eql(%w{Circle Lines Scattered None})}
specify {Game::LOCATIONS.should eql(%w{Indoor Outdoor})}

It’s terse, but still pretty readable and obvious to most people who are familiar with Rspec (and we know our tools, right, so that’s not an issue.)

That is probably a reasonable stopping point, providing it makes sense to leave those as explicit examples. However, were we to add a few more examples, it might be sensible to consider rolling them into a test generator. It can be a useful pattern, especially if you are testing the initialization of many attributes for e.g. an API call, or some similar thing.

While this may not be the ideal example, here’s what that might look like in the context of the above specs:

constants = {:activity_levels => %w{Low Medium High},
             :durations => ["5 to 15", "15 plus", "below 5"],
             :formations => %w{Indoor Outdoor}}

constants.each {|key,val| specify {Game.const_get("#{key.upcase}").should eql(val)}}

In this case it actually adds a line, and again these particular specs are simple enough that leaving them as three individual calls to specify is not a huge deal, but imagine you were testing something like the mapping and initialization of an object from the result of an api call;

result_hash = {:some_key => "some value",
               :some_other_key => "some other value",
               :another_key => "another value",
               :yet_another_key => "yet another value",
               :more_key_fun => "more value fun",
               :moar_object => "moar stuff"}

it "maps some_key to some value" do
  SomeApiWrapper.new_from_api_result(result_hash).some_key.should eql("some value")
end

it "maps some_other_key to some other value" do
  SomeApiWrapper.new_from_api_result(result_hash).some_other_key.should eql("some value")
end

… and so on. Again, taking into account that this is a made-up example, consider that explicitly specifying that all 6 of the expected keys are properly initialized would require 18 lines of code, plus whitespace. Yes, you could build the object and assert that the result of the method you’re testing returns an equivalent object, but sometimes that isn’t as easy as it sounds, or you only need to test certain attributes… Point being, if you’re writing specs like those, you might consider using a generator, like this:

result_hash = {:some_key => "some value",
               :some_other_key => "some other value",
               :another_key => "another value",
               :yet_another_key => "yet another value",
               :more_key_fun => "more value fun",
               :moar_object => "moar stuff"}

result_hash.each do |key,value|
  it "maps #{key} to #{value}" do
    SomeApiWrapper.new_from_api_result(result_hash).send("#{some_key}").should eql("some value")
  end
end

And save ourselves some typing, some reading, and some duplicationey stuff. Since we’re kind of on a roll here, let’s save ourselves some method calls too by moving the actual call out of the example:

result_hash = {:some_key => "some value",
               :some_other_key => "some other value",
               :another_key => "another value",
               :yet_another_key => "yet another value",
               :more_key_fun => "more value fun",
               :moar_object => "moar stuff"}

actual_result = SomeApiWrapper.new_from_api_result(result_hash)

result_hash.each do |key,value|
  it "maps #{key} to #{value}" do
    actual_result.send("#{some_key}").should eql("some value")
  end
end

Congratulations. Our spec is now precious few microseconds faster. Imagine if that method were more computationally intensive, however. The longer that method call takes, the more time that one little change saves.

The last thing bothering me about that spec is the questionable value of explicitly specifying that it maps some key to some value. We could probably use the “specify” method and clean things up just that much more… this is DEFINITELY a style issue however, because the following is quite terse and may be difficult for some people to read, or understand what the spec code is really doing:

result_hash = {:some_key => "some value",
               :some_other_key => "some other value",
               :another_key => "another value",
               :yet_another_key => "yet another value",
               :more_key_fun => "more value fun",
               :moar_object => "moar stuff"}

actual_result = SomeApiWrapper.new_from_api_result(result_hash)

result_hash.each do |key,value|
  specify {actual_result.send("#{some_key}").should eql("some value")}
end

That looks pretty clean, from here. All of that said, writing for readability is never bad, some duplication in test code is usually acceptable, and use your discretion about how “clever” or dense it makes sense for your specs to be. As long as you’re writing them, you’re that much better off than someone who isn’t.

Again, allow me to reiterate that these are largely matters of preference and style, and are by no means to be taken as anything but. That said, feel free to share your rants, raves, questions or flame war inciting opinions below.

This makes it very easy to find places that are conveniently located or plan a route to many destinations.

“Information on this page is available in RSS and JSON formats for non-commercial, attributed use (CC).”

Viewing the page source reveals a hyperlink:

<a class="rss" title="Use computer software to read this page" href="/playlist/subscriptions/seeflanigan/json/1/data.js">
JSON
</a>


The “Latest” feed is exposed as “/playlist/subscriptions/[yourusername]/json/[pagenumber]/data.js”

Your “Loved” songs are available as “/playlist/loved/[yourusername]/json/[pagenumber]/data.js”

The “Popular” feed is at “/playlist/popular/3day/json/[pagenumber]/data.js”

Lastly, but certainly not least of all, there is a search api. Most excellent. “/playlist/search/[somesearchkey]/json/data.js”

If you dig around and come up with cool stuff or figure out more ways to interact with their api (or better yet, find their api documentation), please share it here?

An open source tool called ‘nmap‘ comes in real handy for just such a thing!

After installing nmap ($ sudo apt-get install nmap on Ubuntu,) running a basic scan against a remote host is simple:
$ nmap [ip of remote host]
e.g.
$ nmap 192.168.0.1

The output looks like this:
Starting Nmap 5.00 ( http://nmap.org ) at 2011-03-28 20:39 MDT
Interesting ports on yourserver.yourdomain.com (192.168.0.1):
Not shown: 993 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
135/tcp filtered msrpc
... [more open ports]
Nmap done: 1 IP address (1 host up) scanned in 26.05 seconds

Now we can proceed to lock down the irrelevant ports.

Awesome.

The rsync man page gives the syntax for a push operation.

This is the command that I end up using:
$ rsync -avz -e ssh /this/dir/ remoteuser@remotehost:/remote/dir

Hooray, rsync!

The hackery:

root@rehauedge:~# mysql -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
...
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> CREATE USER 'newusername' IDENTIFIED BY 'newuserpassword';

Sweet.

Plans to do great things to help the world, fantastic projects to give back to your favorite community of the moment, plans to make your mark, make a splash, or otherwise fulfill some high and lofty goal.

Problem for me is I get intimidated by the sheer volume and “where-do-I-start-ness” of such monumental endeavors. Or, some new shiny thing comes along and whisks away my attention, along with my motivation and dedication. Then, the project/task/plan I was so excited about falls by the wayside. It’s an ugly habit.

Sadly, many of my exciting ideas end up much like this lonely tumbleweed...

Granted, some projects find themselves less prone to such unfortunate fates. Usually, they’re the ones that put food on the table and clothes on our backs. After all, nerd’s gotta make a living, know what I’m saying?

No, the ill-fated projects I’m talking about are the “update my website”, “blog more often”, “organize my music collection” sort. Luckily, I have a panacea for avoiding the constant discontentment and feverish discombobulation that results from chronic-project-switchitis – GIVE UP!

Now that we’re rid of the quitters, a real solution. Start small. Case in point, this blog post. It’s not the sweet tutorial I wanted to write, or the awesome summation of every amazing thing I’ve been reading lately. But it’s something. It’s one post more than I had yesterday, and hopefully an inspirational one.

It was inspired by the tabs currently open in my browser, one for free node.js hosting, another about important features your website should have if you’re a freelancer.  Instead of building a website and blogging about the step-by-step process of doing so, right this very instant, all at once, I’m taking a stand against that ridiculousness. At least, I’m taking a baby step toward a more sane (and achievable) approach. I’m even going to hit publish before adding any pictures to break the monotony, or tags to aid in the everlasting quest for total organization!

Also, I’m “Talking about writing about what I’m doing. Now I’m singing about talking about writing about what I’m doing.” (Parks & Recreation quote, ignore if irrelevant to your interests…)

Point is (yes, point, finally!) do something. It’s way better than nothing, and will certainly help you reach your goal, eventually. Even if it’s just brainstorming for 5 minutes, or sorting through a pile of mail, or writing some ridiculous self-help monologue that is little more than superfluous narcissistic pandering… it’s also easier said than done, so here’s a final kick in the seat from yours truly;

follow the advice of Dr. Leo Marvin. Baby steps to the elevator. Baby steps toward finishing this blog post…

Oh yeah, and Happy Saint Patrick’s Day to you Irish and honorary Irish alike!

Keep reading if your response to that sentence was something like
“Provides what for what?”

Otherwise, just grab the code here and get your stylesheet on.

For those still following along, SCSS is an acronym (what else?) for Sassy CSS. Sassy CSS is the main syntax in Sass. It was introduced in version 3 of the project. Sass is yet another acronym (YAA) for Syntactically Awesome Stylesheets… wait for it…

“An extension of CSS3!”

It adds “…nested rules, variables, mixins, …and more.” It’s free open source software and helps me write much more manageable CSS code (along with the Compass and Blueprint frameworks…)

This Vim plugin autodetects SCSS files, and makes them look much better in my terminal window. So far, I vastly prefer it to the syntax highlighting for SASS (predecessor of SCSS) that was included with the version of Vim in my development environment.

Get it here.

Installing the plugin is easy, and requires only 3 simple steps.
1. Clone the repository
2. Copy some files
3. Restart Vim (or load them manually.)

In a terminal on Linux or OSX, issue the following commands:
$mkdir -p ~/src
$ git clone https://github.com/cakebaker/scss-syntax.vim.git

On my system, the ~/.vim/syntax and ~/.vim/ftdetect paths did not exist.

I had to make them;
$ mkdir ~/.vim/syntax ~/.vim/ftdetect

Then I just made two filesystem links -
$ ln -s ~/src/scss-syntax.vim/syntax/scss.vim ~/.vim/syntax/
$ ln -s ~/src/scss-syntax.vim/ftdetect/scss.vim ~/.vim/ftdetect/

Use Vim to open the example file provided with the plugin:
$ vim ~/src/scss-syntax.vim/example.scss
and you should be greeted by a warm wave of colorful, readable stylesheet.

Joy!

Manually loading a Vim plugin into an already running environment is easy. Just source the file (in Vim) with :source ~/.vim/syntax/scss.vim and you’re off to the races.

Have fun!