GIANT ROBOTS SMASHING INTO OTHER GIANT ROBOTS

thoughtbot is pairing up with Ben Orenstein to present a Vim course, this time at WorkBar. As part of this collaboration WorkBar is offering $50 off your first month’s membership if you register for the Vim course.

One thing you will discover at this course is the history of the command `grep’. This all starts back with `ed’, the original unix editor. ed was a command-line editor that worked identically to the colon-commands in vi and vim—in fact, you can press Q to get into ed mode (then type vi to get back into vim). From the ed editor you can issue common line-oriented commands like s, d, y, and so on:

:%s/rdoc/docr/g
:/include/d

If you’re following along at home you may wonder “how can I see the contents of this file?” Well if you just want to see every line you can use %p (% is “the whole file”, and p is “print to screen”), though it’s more likely that you want to see a small series of lines. 10,20p will show you lines 10 through 20, but maybe it makes more sense to see all lines matching a regular expression.

From ed, to see all lines matching “include”, use g/include/p. To see all lines matching “docr” use g/docr/p. In general, to see all lines matching the regular expression “re”, use g/re/p.

… And that’s how grep got its name.

Sign up now for the Vim course at WorkBar with Ben Orenstein on September 1st from 5PM to 9PM.

Sometimes, test driven development is really annoying, and the abundance of untested applications out there suggests that I am not the first person to have had this thought.

The thing is, there are limitations to test driven development.  The workflow of test development essentially goes like this:

1. Create a user story that encapsulates a chunk of functionality of the application
2. Write tests for this story (which should fail before you have implemented anything)
3. Write the code to make the tests pass

What is missing from this flow, however, is a period of time to consider the overall design of the code in the application.  If you’re not careful, your program can end up like an old school map of Africa - the small details are right, but the overall structure is off.

Test Driven Development rests on the assumption that you basically know the optimal way to make your tests pass in advance.  If you’ve written several similar apps, you probably do know how to fill in your tests.  However, if you’re new to programming, or if you’re creating a unique program, you may not.

Recently, my coworker Jason and I encountered this problem when working on the open source app GNITE. GNITE requires an internal large tree structure that can support up to 5 million nodes.  Neither of us had worked with trees that large before, and we didn’t know what the stumbling blocks were going to be.  So, we decided to spike it out.

A spike is a quickly written, untested piece of code that’s intended to be thrown away.  You intentionally abandon your best practices in the interest of quickly learning about good ways to design your app. Once you’ve gained everything you can from it, however, you scrap it and don’t build anything else off it.

In our case, we started out fooling about with jsTree, to display the tree, and the ruby gem ancestry, to organize the tree structure in the database. (If you want to check it out, it’s up on github here and you can see it working here.)   As it turned out, ancestry and jsTree worked well together - ancestry stores the entire lineage of each node on the node itself, which made things like asynchronous search work well with jsTree.

Happy with our initial findings, and looking to push our luck, we extended our program to parse large, compressed tree files.  Once we had the large tree in the database, the display behavior remained satisfactory, but the act of parsing a tree took a long time - too long to be a regular occurrence on the website.  Initially, we had considered making parsing trees a regular part of the work flow, but the 5 to 10 minute load times suggested that we would need to look into some sort of caching (or, possibly, a different way of storing nodes on the back end with a quicker insertion.)

In the end, we decided caching uncompressed trees in the database could be a potential solution, given the amount of space we had.  In our case, the most straightforward approach for displaying trees worked out well, but not for saving and loading trees.

Now that we have a loose idea of the structure we’re going to pursue, we can keep it in mind when we’re writing our code.  And, we have some really relevant example code to work off, which will (hopefully) make the “getting the tests to pass” step in TDD quite a bit easier.

Still without plans for August? Did you know that August is our nation’s warmest and most-traveled month? Looking for a nice trip? Well…have I got a deal for you!

Come relax on the sandy shores of Massachusetts’ own wicked beautiful Cape Cod at our previously announced event: CAPE CODE! Join thoughtbot’s team of designers and developers and stiff management types while we bask in the glorious New England sun. It’s the most relaxed you can be and learn about web programming at the same time.

Hey, maybe you can dig up some clams while you’re there.

Suspenders is a Rails project template used as a base app for all of our client work. It has gone through a few changes that better reflect our development stack and also allow us to test changes to suspenders itself.

RSpec

As you may know, we are spec’ing our apps with RSpec along with shoulda matchers now. This along with cucumber for integration tests is the testing stack that we’ve been using for a while. RSpec replaces Test::Unit in suspenders.

jQuery

For our front-end behavior we’re using jQuery. The ecosystem around jQuery Core, jQuery UI, and the slew of third-party plugins help bring life to our applications. Using jQuery also gives us an easy transition for mobile web app development with tools like jQTouch. jQuery replaces prototype/scriptaculous in suspenders.

Dependencies

Our projects depend on a number of gems. Some have native extensions and therefore cannot be vendored in the project - I’m talking about our friends nokogiri and RedCloth. In the past we would check if the gems where installed, and installed them if they weren’t. Now that suspenders-gem is the preferred way of installing and using suspenders, we have added these as rubygem dependencies on our gemspec.

Testing suspenders

The creation of suspenders-gem affords us the opportunity to write integration tests for suspenders. In the past, testing updates to suspenders was a manual process because of the nature of the template. But from now on we can write cucumber scenarios that verify that the suspenders project starts in a clean state.

Take her for a ride!

Along with these major changes, versions of all other dependencies were bumped to the latest stable versions. Take suspenders for a ride and let us know what you think:

gem install suspenders
suspenders create billion_dollar_idea