IndexCards is a website that I’ve been devoting a good deal of my free time to recently. It is a family project where we draw new stuff on index cards everyday.

So it’s an Art Project?

Well yes, and no. IndexCards is:

• An Art Project – You got me, yes it’s in some ways completely non-technical.
• A Family Activity – Since my kids have gotten involved, it has just gotten better and better.
• An Evolving Sinatra Based Website – My first Sinatra based project, and I am really liking it.
• A Way for Me to Try out Tokyo Cabinet – I’ve found that I don’t always need a relational database.
• An Opportunity to Use my Razsell Gem – A live app that consumes feeds from Zazzle.
• A Design Project – Let’s face it creating a website from scratch that is part of the design community raises the bar a little.

IndexCards is an Art Project

I created IndexCards in response to the Design Something Every Day Challenge posted on Smashing Magazine at the end of 2009. I enjoy drawing and painting, but have directed so much of my interest towards Ruby and Open Source Projects (and the internet) in the past couple years that I haven’t spent time creating any art. As a new years resolution, I decided to change this by accepting the challenge.

IndexCards is a Family Activity

After a month or so of me scribbling away on little pieces of paper, my kids asked me what I was up to. So I explained that it is a project to help me to improve my artistic skills and “enjoy the journey” so to speak. They all wanted to participate and so I’ve been including them since then. Recently, I’ve started creating Art Night events where I introduce a theme and we all start drawing away. It has been a great family activity and I’ve been very impressed by all of their work.

IndexCards is an Evolving Sinatra Based Website

OK there is a technical side to this project, but that’s perfect for me. I find that I like both the technical and creative sides of things. When one side of my brain needs a break I can flip over to the other and continue working on the project. A lot of the site’s inner workings are not visible from the web, but there is definitely a web based component. For that I decided to use Sinatra and it’s been great to work with. It’s a lot more open that working with Ruby on Rails, but many of the tedious parts of working directly with Rack have been smoothed out. I’m interested
in creating another Sinatra based application.

IndexCards is a Way for Me to Try Out Tokyo Cabinet

Another technical bit I wanted to try out in Tokyo Cabinet a key value store of Mixi fame. I used the rufus-tokyo gem to interface with Ruby along with the Repository pattern. I was really worried at first that I’d get to a point where I really
needed a relational database and I’d have to rewrite the data persistence in MySql. As the project goes on, I’m finding that my fears were unfounded. Tokyo Cabinet was a great fit for the project.

IndexCards is an Opportunity to Use my Razsell Gem

Ah Razsell. I created this gem while starting out on Kung Fu Tees, a T-shirt design site I wanted to make with my kids. Kung Fu Tees, this far is vaporware, but Razsell has emerged as it’s own project any users. It allows you to query the Zazzle.com rss API and consume the feed to populate a store. Using it has caused me to make a few changes, which is great, because that’s what happens when you really use the code you write.

IndexCards is a Design Project

So I’ve always been wary of CSS and web design in general. I mean I’m ok at it, but am generally disappointed with the look of my sites when I compare them to so many of the other websites out there. Designing a website that is part of the web design community ups the ante a bit. So far I’m not
completely satisfied with it, but it is much better than I’d feared it would be.

But, Why Index Cards?

I wanted to draw daily, but I didn’t want to burden myself with a huge canvas. Index cards are the perfect size to constrain the scope of the image and challenge me to make it fit. Not to mention they are cheap and you can find them almost anywhere. That leaves a little budget for art supplies, and
I’ve been picking up a few things here and there. Just today I ordered a Lamy Safari fountain pen to try out, and am looking forward to it.

Original small works of art (OSWOA) have
stemmed from the Artist Trading Cards and ACEO communities on ebay. Maybe I can find a tie-in for those. They fit right in.

IndexCards is fun, You Should Check it Out

If you haven’t been to IndexCards go take a look. Maybe you will be inspired to do some art of your own.

Recently I was updating some gems on my server. I did a gem update and a gem update –system. Everything seemed to be running smoothly. However a few minutes later I was checking my sites and I discovered that all of my Rack based sites were down and giving a 502 error.

The Background

In my short experience being my own webmaster, I’ve found that the 502 error code is the most unhelpful of error codes. It means that your app is not working. After a few times checking my error logs I noticed that the error that was bubbling up was “No such file or directory”. So I took this and searched through my apps looking for a file that might be missing

After a few hours of searching, restarting Nginx and reinstalling passenger, my apps and my gems, I took some time to think about the issue. I realized that all of my passenger apps were now suddenly failing, but my wordpress blog was still chugging along just fine. So I decided that the problem must be with Passenger.

The Culprit

After much digging around, I found that the Nginx config was still pointing to the Passenger version 2.2.9. A version I’d removed with gem clean many hours before. Once I updated this to version 2.2.10, which was the current version installed, everything started working again.

The Moral

If you update Passenger make sure that your webserver configuration is pointing to the new version.

/usr/local/lib/site_ruby/1.8/i486-linux/tokyocabinet.so: libtokyocabinet.so.9: cannot open shared object file: No such file or directory - /usr/local/lib/site_ruby/1.8/i486-linux/tokyocabinet.so (LoadError)
        from /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `require'
        from test.rb:1

The solution was to modify the LD_LIBRARY_PATH to include /usr/local/lib

#~/.bashrc
 
 export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib

The call went out the other day for participants in the Rails 3.0pre BugMash on Jan 16th – 17th. Included were some imple instructions for cloning Rails 3 and creating a new Rails app from it. So I pulled it down and gave Rails 3 a test spin.

Project

I decided to start a project for making a sort of universal friends list. One that encorporates XFN tags and OpenID. The data could then be used as a resource for other sites to seed a friends list. In order to claim an OpenID as your own you need to authenticate it.

Bundler

The first thing I noticed was the existance of the Gemfile in the rails root and how empty config/environment.rb is. I’d read on about the new bundler and thought it was going to be painful, but I was wrong, it was actually a joy. It even removed gem after I commented out the requirement statement in the Gemfile.

Plugins

I installed Authlogic as a plugin, after failing to get it working as a gem. I’ve had the same issue with Rails 2.3 so I don’t think this is an issue with Rails 3. The OpenId Authentication plugin worked fine as well.

Routes

The new routing module took a little getting used to, but after a few mistakes I got it working correctly. In the end config/routes.rb looks much cleaner, and still contains lots of commented samples. Also the legacy routing is commented by default, which is nice since that’s something I do anyway.

Premade .gitignore

Speaking of nice defaults, creating the rails app made .gitignore file for me with tmp / db / log already in it. Very Nice!

View validation

One thing that came as a bit of a surprise to me that the views are validated against the models. If you reference a field on the model in the view that does not exist, Rails will now error and tell you that it’s not there. So you need to rake db:migrate to have it recognize the fields on a model.

Conclusion

I have really liked what I see of Rails 3 thus far. Thanks to all those that have worked on it. I think that I will start using this version by default.

Huh? It’s 2010? I haven’t posted in 6 months? What happened?

Summer of Learning Challenge

The Summer of Learning Challenge didn’t happen. I didn’t even do it. No excuses. I did other things.

All is not lost

Around the end of 2009, I dusted off my idea of creating a git based wiki like publishing portal with Rack. I put it together in about a week or so and it’s slowly evolving and gaining some content. It’s fun, even exciting, to bypass frameworks and DSLs and all the opinionated code and build something on the leanness that is Rack. A great learning opportunity to boot. So maybe something came of the challenge after all.

Rubyyot – Rack + Git

It’s up on rubyyot.com with the source on github still wonderfully rough around the edges and in need of a code review. Ahh, to create something again.

Flannel – Warm and fuzzy

I made my own markup parser for this, it’s called flannel and an liking it so far. Of course it too is still in it’s infancy, but I’m not only using it to format my wiki thing, I’ve also given it a little command line attention to allow it to transform text files for my blog posts. It’s warm, fuzzy and everything is just as I want it, and if not, I change it.

This is part 4 of the increasingly mis-named Getting started with Ispec and Ioke trilogy. Last time we discussed the let keyword and I started working on the template object which represented the template to be parsed into a document.

Previously I used ISpec to assert that we could evaluate on cells on Bag. I wanted to start off this time by proving to myself that I could just as easily use activatable cells on Bag as well.

    it("should evaluate method on bag",
      bag = Bag mimic
      bag bread = method("butter")
      evaluator = Evaluator mimic(bag)
      evaluator evaluate(bread) should == "butter"
    )

As you can see, this time instead of assigning a string to a cell on the property bag an evaluating it, I instead assigned a method which returned a string to a cell and evaluated it. Sure enough it worked without any changes to the code. This creates some interesting possibilities, though I haven’t thought through all of the ramifications at the moment.

Sure enough it worked.

Next I wanted to push the envelope on Evaluator a little bit by defining the method which will do the work of parsing the template and injecting the values from the property bag into it.

describe("parsing",
    it("should return the template when the bag is nil",
      evaluator = Evaluator mimic(nil)
      template = Template mimic
      template text = "An extra special template"
 
      document = evaluator combine(template)
      document should == "An extra special template"
    )
  )

This is really a small step, and as I get more familiar with TDD and BDD, these seem to the the steps that I’m most comforable with lining up and knocking down when implementing new features. The other part of this is, doing the simplest thing that could possibly work to pass the spec / test. In this case, this is the simplest thing.

Evaluator combine = method (
  "Generates a document from a template and bag",
 
  template,
  template text
)

From here, I think that the next step is going involve using Ioke’s implementation of Regexp, which I will need to read up on. So I think I will cut this short for today and wait for next time for that topic.

The Code

The code for this example is available on github tagged as start_ispec_4

I am currently wrapping up an initial release of a new gem that wraps the Simpy.com API. I like social bookmarking and used delicious for years before switching to Simpy as my primary service. Simpy is not the biggest online bookmarking service, but I’ve decided to use it for reasons I will outline in another post. In any case I’ve put together a gem that wraps the API with the help of Httparty. It actually turned out much simpler than I expected it to be, httparty did all of the heavy lifting, but again that is for another post.

So, I have a functioning gem for Simpy, now I want to make something useful with it. The reason I made the gem was to simplify my bookmarking which is overall a mess on multiple workstations in multiple locations. Since I’ve recently been getting familia with cron, I’ve decided to make a script to store urls locally and use cron to run a script that pushes a file of pages to Simpy.

As I touched on briefly, I’ve been unhappy with all my previous bookmarking solutions thus far. This time I want to make it, dead simple. I don’t want to have to enter any additional information if I don’t want to, just a url and have it go on it’s merry way. However to post the link, I will need to at least have the page title. Pulling a page title from a url is really outside of the scope of RSimpy. Ruby makes it fairly simple to do, but I don’t want to isolate the functionality to a script. Ruminate to the rescue, but what is Ruminate?

Ruminate

Well the answer to that question is that I’m not really sure. A few months back, I made a gem with jeweler called ruminate with the description “Extracts statistics from html documents”. Actually, I’m not really sure what I originally had in mind when I setup this gem, but it will be useful now since I want to extract at least the page title. Once I get the ability to extract a page title, I can make a script that is simply glue code to put Ruminate together with RSimpy and voila!

Bootstrapping the project

I have a vague idea of something that I want Ruminate to do, that is I want to be able to query a url to return the title of the page. It’s obviously not the entire purpose of the gem, but I’m sure that will be lots of other bits that will come together in time.

The question is, How do I kickstart this project with TDD to get it off the ground?

Programming by Intention

Programming by intention is the practice of writing code, while pretending that any methods or classes you might reference already exist and operate in the way that you reference them. It’s a great way of uncovering a simple intuative API that you might otherwise would have missed.

I’ve seen it described in two books, first in Everyday Scripting with Ruby, from The Pragmatic Bookshelf. Secondly, it’s used in an excellent book I’m currently reading called Test Driven from Manning.

There are a number of sources stating that TDD is about design first and automated testing is a nice by-product. In my limited experience with TDD, programming by intention is the crux of this design, and by extension the primary purpose of TDD.

Cucumber

One of the things that I really like about cucumber is that you can plainly state your intent and important bits of your feature focused domain in plain English and match that up to executable code. To describe the ability of Ruminate to grab the title of a url, I made the following test:

Feature: Get Page Title
  In to get the page title
  A user of ruminate
  Will request a page title
 
  Scenario: Requesting the title of a page from the page
    Given the url "http://www.google.com"
    When I execute the request
    Then the "title" should be "Google"

I let cucumber auto-generate the regular expression blocks and came up with the following steps:

 
Given /^the url "([^\"]*)"$/ do |url|
  @url = url
end
 
When /^I execute the request$/ do
  query = "Select title from #{@url};"
  @result = chew query
end
 
Then /^the "([^\"]*)" should be "([^\"]*)"$/ do |msg, value|
  assert_equal value, @result
end

As you can see I’ve decided to try out a sql like syntax for the tool. I thought it sounded interesting, we’ll see if I keep it. In any case, I now need to make this test pass with the help of a mixin, that I’m including in features/support/env.rb

# features/support/env.rb
$LOAD_PATH.unshift(File.dirname(__FILE__) + '/../../lib')
require 'ruminate'
include Ruminate
 
require 'test/unit/assertions'
 
World(Test::Unit::Assertions)

# lib/ruminate.rb
require 'query_parser'
require 'engine'
 
module Ruminate
  def chew query
    parser = Ruminate::QueryParser.new
    query_object = parser.parse query
    engine = Ruminate::Engine.new
 
    engine.execute query_object
  end
end

Here I’ve used the mixin to split the method into to operations and encapsulated each of these into a class. Programming by intention has now generated a mixin and two classes that have a clean separation of responsibilities. Here is the simplest thing that could possibly work to make the feature pass.

# lib/query_parser.rb
module Ruminate
  class QueryParser
    def parse query
      nil
    end
  end
end

# lib/engine.rb
module Ruminate
  class Engine
    def execute query
      "Google"
    end
  end
end

Obviously this isn’t the final code, but it gives us the minimal implementation to pass the feature. Now I can turn to Test::Unit and shoulda to flesh out tests and implementations to make it work in a more useful manner.

What I really wanted to show here is how to get a TDD project started. I know that I’ve struggled with this in the past. What to test first can be a big decision, one that can create a type of code writers block. When this moment happened where everything just came together and I was able to generate a mixin and two orthagonal classes with a simple feature, I wanted to write it up.

The Code

The full code for this example can be found on github with the tag simplest-thing-that-could-possibly-work