Archive for the ‘Ruby’ Category

So What’s the Deal with IndexCards?

Wednesday, March 24th, 2010

What’s all this IndexCards nonsense?

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.

Getting 502 Bad Gateway with Passenger after cleaning gems

Thursday, February 25th, 2010

502 Bad Gateway

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.

Date.parse() is not your friend.

Sunday, February 7th, 2010

I’ve started looking at Ruby 1.9 with multiruby, and one of the first things that I found in testing is that Date.parse assumes European dates (dd/mm/yyyy format) in v1.9. The solution is to use strptime() instead so you can specify a format.

Date.strptime("12/31/2009", "%m/%d/%Y")

Can't find tokyocabinet native extentions

Monday, February 1st, 2010

I was trying out rufus/edo today after installing Tokyo Cabinet. and I kept getting the following error

/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

Getting a project off the ground with TDD and Cucumber

Sunday, June 21st, 2009

RSimpy

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