Archive for the ‘Ruby’ Category

Developer’s journal: devise, Rails 3, RSpec, and more

Friday, July 9th, 2010

I keep a text file open as I work, and when I learn something, or fix a bug, I make a note of that in the text file. I call it my journal. It’s pretty low-tech, but text search turns out to be a sufficient way to look up past experiences when I find myself thinking “this problem seems so familiar”. There’s another benefit too: I find keeping simple notes about what I’m doing—what problems I’m solving, what approaches I’m using, what’s working and what could work better—keeps me focused on my goals. It turns out learning a programming language or a web framework is not as hard as training your mind to solve programming challenges efficiently.

Here are some things from my journal: I’m working on a Rails 3 app right now, something I plan to flog and promote mercilessly in upcoming posts. I’ve encountered some mysteries for which there was no simple HOWTO information easily available via web search. I thought I’d share the answers I cobbled together:

  1. How to get RSpec and RSpec-Rails for Rails 3;
  2. How to make devise routing work with related nested routes;
  3. How to spec controllers that use devise to restrict access to logged-in users;
  4. How to get verify :method to work in Rails 3.


3 languages

Tuesday, June 29th, 2010

I need to clarify my interests. I keep getting calls from recruiters who want to hire me to do Perl or database management. So, I am trying out an experiment in self-analysis by describing my enthusiasms as they relate to specific programming languages. I am currently interested in the web software applications of Ruby, JavaScript, and Clojure.

It isn’t all about programming languages. There are topics and concerns that span software development and computer science. But PLs are one great way to summarize one’s experience and efforts. And I’m a language nerd, so I like PLs as ends in themselves. So, here is my little essay on the 3 languages I like most right now, and, more importantly perhaps, what I want to do with them in the coming months. This is my summer of hustle, and this post is part prelude, and part wishful thinking, about all the things I’d like to tackle.


Mustache support for Rails 3: template handler

Wednesday, June 23rd, 2010

I sure am glad I went to the Bmore on Rails hack night yesterday. I got some invaluable help from Paul Barry hacking together a working template handler for mustache in Rails 3.


Mustache support for Rails 3: generator

Wednesday, June 16th, 2010

At RailsConf, Jeremy McAnally noted that no one had built a new-style Rails generator for the mustache template system. So I’m giving it a try. You can see my progress so far on github. I’ve forked the rails3-generator project started by José Valim and carried on by several contributors, and I’ve added just a little bit of support for mustache file creation in controller and scaffold generators. I was greatly helped by Paul Barry’s post on adding a Haml generator to the same project.

The next steps are to flesh out the generator templates and try to get a working mustache template engine. Mustache and Rails don’t officially work together yet. That’s a goal for mustache 1.0. I’m excited, however, about Martin Gamsjaeger’s promising implementation.

I’d like to see a gem that gives you complete Rails support for mustache: the template engine, generators, helpers, and documentation. I’d also like to see the gem work with Tilt, which claims to provide a generic interface to mustache already.

If you’re interested in helping, well… fork me!

On Ruby monkeypatching and Clojure’s protocols

Friday, June 4th, 2010

I read an interesting article by Dave Fayram (kirindave) contrasting monkeypatching in Ruby with protocol extension in Clojure. The article compares two of my favorite languages, but I think it was unfortunate to present monkeypatching as the main way to “associate behavior and data in a flexible way.” In fact, Ruby has a number of safer ways to extend types and single objects. (And in Ruby even monkeypatching doesn’t have to be dangerous.)


My asynchronous concurrency talk at May Capital Area Clojure Meetup

Monday, May 31st, 2010

I was lucky enough to present a talk about asynchronous concurrency in Clojure (and JavaScript and Ruby as it turned out) on May 27th in Reston. Thanks to FGM and Matt and Russ for organizing and hosting the Capital Area Clojure meetup.

I have the slides available for review from scribd below. There’s plenty about agents and futures in there, plus a look at Evented IO in Node.js and tuple spaces with Rinda. After the break, I also offer a few observations about the content in light of questions asked in the meetup and my own reflections.

Asynchronous concurrency in Clojure and a few other languages


Lazy Enumerators in Ruby

Wednesday, September 30th, 2009

I gave a talk on Ruby’s Enumerators at the DC Ruby Users Group in August. I’ve posted my slides from the presentation, if you’re interested.  Basically, I discovered that enumerators make lazy evaluation easy to implement in Ruby, and applying lazy techniques with enumerators may yield more efficient and elegant code.


A Ruby on Rails mystery, and the price of magic

Monday, June 22nd, 2009

I count myself lucky that I can earn a living programming with Ruby and in particular with the Ruby on Rails framework. But every tool, even the best, has a few surprises up its sleeve. Sometimes you get hung up on something quirky, but more often you’re having a problem with a feature—something that’s there by design. This is my story about one such problem I had with a Rails feature, how I diagnosed it, and what it means: metaprogramming is awesome, but it comes at a price, and in imperative languages, the price is side effects.


Some gems from RubyNation 2009

Monday, June 15th, 2009

Nothing close to a complete review of all the quality talks I heard at RubyNation, the following is just a summary of cool things I learned about while attending.

For other resources, and some of my own snarky comments, take a look at the Twitter Channel for the event: #rubynation

TupleSpaces and Rinda

Luc Castera gave an excellent presentation about concurrency and distributed programming in Ruby. After basically saying that using Ruby’s built-in facilities for concurrency was a myth, he laid out several alternative approaches and applications. The most interesting was using Rinda to implement TupleSpaces in Ruby. Rinda can run as a service listening on a port, and it can manage a queue of messages to be processed by a TupleSpace, which is basically an associative value store, or a mini-environment. Other processes can monitor the contents of the spaces and pull data from them to run operations. This is the actor model: the spaces share nothing and communicate asynchronously with messages.

Take a look at Luc’s slides for all the info. Great talk. I’m going to look into Rinda as soon as I can.

Reek: A code complexity metric tool

Mentioned during Mark Cornick’s excellent talk on refactoring, reek is a tool to measure the perceived complexity of your Ruby code. Reek doesn’t like repetition, and it really hates long methods. It certainly doesn’t like my code: reek returned 41 warnings about my latest controller. More about reek on github.


From Relevance Labs comes a homegrown BDD framework that ended up embracing RSpec while promising to make your tests run faster. Use metadata to group and target your tests, and you may never have to wait for an hour for all your specs to run. According to Aaron Bedra, it’s also beautiful code to look at: a good example of metaprogramming in only 2 KLOC. And someday soon its tiny heart will beat inside RSpec proper. More on micronaut at Relevance’s blog.


How did I miss this? Already in Ruby 1.8, these constructs will be even more important in 1.9. They’re essentially lazy data implementations. Roughly:
>> r = [1,2,3,4].cycle
=> #<Enumerator #f00ba2>
>> r.take(5)
=> [1,2,3,4,1]

Directed Graph Data Stores

Holy Cow! I’ve only just learned the difference between Tokyo Cabinet (it’s a key-value store) and CouchDB (document-based data store). Ben Scofield, in his talk on categorizing comic books, explained these both but also brought up Directed Graphs, which I haven’t thought about since SICP. There don’t seem to be any highly-visible implementations of this storage method, although I believe that RDF models data as directed graphs. This is going on the top of my research list. Cool stuff.

A Wildcard: Reia

There was a lot of buzz about the new Reia programming language, but little concrete information. The estimable Hal Fulton gave a talk on the Ruby-like language for the Erlang VM, but even he didn’t seem to know much about it. Its creator user to run revactor, a Ruby framework that implemented the Actor model, and a language with Erlang’s spooky power and Ruby’s “curb appeal”, as Russ Olsen has it, would be superb. But it seems we’re a long way from being able to evaluate whether Reia will make a mark.

Lingo and Memes

Did anyone else hear the phrase “bikeshop it” several times during different talks? And how about the rainbows and puppies in Ben Scofield’s talk? I didn’t make it to Danny Blitz’s talk on Tiger Teams (Raarrr!), so I’d warrant I missed out on some great terms.

My Clojure Lightning Talk

I put together a 6-minute talk on Clojure, with Paul Barry’s help. The slides are here. I wish I’d also been able to mention type hints, for when you want to speed things up with static types; metaprogramming with macros and first-class functions; and Clojure’s robust metadata system. Maybe I’ll get to give another version of it again.

Peace on Earth, good will toward Ruby web framework programmers

Tuesday, December 23rd, 2008

I’m reading the news on Twitter that a remarkable and wonderful thing has happened in the world of Ruby web developers: Rails and Merb are going to merge. Here are announcement posts from DHH and Yehuda Katz. And here is the requisite humorous site tracking whether the two are combined. As Matz says (by way of bryanl), “Love matters. It’s the greatest reason behind Ruby.”

Besides being encouraging to see two camps of alpha-geeks put ego aside for the common good, I think the rapprochement is tremendously good for the Ruby world and for web developers. The two camps are agreeing to take what’s best about each platform and put it in the new one. As a Rails developer, I get the Merb team’s improvements and advancements without having to choose a different platform. Merb developers get to practice their techniques within the Rails juggernaut and become Rails performance experts in the process. 2009 is already looking better.