The Real Adam The cult of Adam Keys

My current foster-hussy-girlfriend. She's kind of a spaz, but oh-so adorable. Doubly so when she's "frogged out" as above.

Lazily Announcing version_fu - an update of Rick Olson's acts_as_versioned that works with dirty attributes. Jordan McKible's plugin is nascent, but since I have a soft spot in my heart for most things data versioning, I thought I'd point it out.

Massive kudos to John Resig for his JavaScript Processing port. Take this plus the new-to-me JavaScript Information Visualization Toolkit, and it seems likely that data on the web is going to get a lot prettier (and less Flashy) in the next 6-12 months. Huzzah!

Changing git submodule URLs

Pro-tip: if you're using submodules with Git to manage dependencies (say Rails plugins), you can get yourself into trouble. Like half-a-day of wasted trouble.

The rub comes when you need to make a change to some plugin. Suppose you were using Brain Buster for your captcha and then decided you need to make a change. The git submodule command doesn't really seem to offer a way to change the URL for the submodule. Let me summarize what I've found in trying to do this.

The Wrong Way

• Fork/create your own version of the submodule in question
• Change the URL for the submodule in .git/config and .gitmodules
• Cross your fingers and hope for the best

The Right Way

• Fork/create your own version of the submodule in question
• Remove references to the existing submodule in .git/config, .gitmodules and nuke the submodule directory
• Commit
• Add the new submodule URL
• Commit
• Make changes in your submodule
• Commit changes in the submodule (not the parent project)
• Commit the changes in the parent project (otherwise you'll only get the old version of the submodule in future pulls)
• Enjoy the hair you didn't have to rip from your scalp

Learn from my mistakes, people.

Ruby for non-Rubyists

Yesterday I spoke to a pleasant mix of Java, .NET, Ruby, Python and PHP developers at Dallas TechFest. My goal when speaking to enthusiast crowds of this sort is to show the light that I've found in my programming journeys over the past couple years. This time around I tried to take a page from the inimitable Richard Feynman by structuring my talk into two sets of "Six Easy Pieces".

The first part starts off with the stance that programming shouldn't suck. From there I talk about the intercontinental railroad, Sapir-Whorf, Pattern Languages, the Gang of Four and flattery. In the end, we have an idea of how to better approach programming so we can have fun doing it.

The second half is partially showing off Ruby and partially a gauntlet thrown down to other languages. The main point is to show a progression of ideas I see in lots of Ruby code, from sensible naming to closures ending up with metaprogramming powering declarative programming and internal DSLs. You can implement the ideas from the beginning in any language. However, the ideas towards the end require a more progressively designed language. I'd love to see non-Ruby implementations of the programs towards the end of the presentation, if only for comparison and Rosetta Stone purposes.

Thanks to everyone who was in attendance and especially those who stopped to chat with me before and after the presentation. Without further ado, please enjoy Six Easy Pieces (Twice Over).

Beautiful multi-line blocks in Ruby

I need a new drug. One that won't quit. One that will let me sensibly structure the use of blocks in Ruby such that they can run across multiple lines and yet still chain blocks together.

OK, so its not really a drug I need, per se. Though, I'm sure what Huey Lewis really needed was a new drug. But what I need is a convention, or perhaps some syntax. It should say to you, "HEY. Adam's doing something clever with blocks here. Keep your eyes open."

I find myself desiring a new syntax and/or convention, when using blocks. I've been trying to write in a more functional style lately, especially a pure-functional style wherein you never call a method for its side-effects. I don't think I'm the only person doing this. Jim Weirich sort of alluded to it in a post about when to use do/end vs. braces. Rick DeNatale took it a step further. I want to lay it bare.

Let's start with something innocuous:

ary = [1,2,3]

result = ary.map do |n|
  x = n * 4
end

result # => [4, 8, 12]

You get the value back of each object in the array, mapped to the result of calling the block. Fun times. Now, let's put it on one line and do something clever with it.

ary.map { |n| n * 4 }.select { |n| n == 4 } # => [4]

Now we're cooking! Ruby's syntax allows us to chain methods and blocks. Which turns out nice in this case where I want to filter down the array of mapped values. But let's pretend we need to do something clever in those blocks.

  
    ary.map { |n|
      n * 4
      # Some
      # clever
      # things...
    }.select { |n| 
      n == 4 
      # More
      # clever
      # things...
    }.any? { |n| 
      n == 4 
      # Gratuitiou
      # clever
      # things...
    } # true
  

That's the best I could come up with for chained, multi-line blocks. It looks "Weirichian". Despite that, it kinda makes me vomit in my mouth.

So, since I got awesome feedback on my last question of taste, I'm tapping you, my favorite Ruby developer, for more. The ground rules are that you can't extract the logic into a real method and you can't jam everything onto one line. You have to use multi-line blocks. What looks good to you here?

Joshuadamon's Halotography is utterly amazing:

I'm really impressed with what he's done with some clever camera manipulation and probably some Photoshop loving. All Halo fans should check this out.

Can I send you a message?

Object#send - the joy of Rubyists and the scourge of those who would write refactoring tools. Let's talk about it.

I recently ended up writing some code that would have proven really hideous if I couldn't call #send. So I had a class like the following (written using code generation for brevity):

class Foo
  %w{one two three}.each do |name|
    class_eval <<-EOC
      def #{name}
        '#{name}'
      end
    EOC
  end
end

I needed to call one, two or three from a bit of code that takes some user input (in this case, an attribute value in a template language). So I cooked something like this up:

%w{one two three foo}.each do |arg|
  meth = case arg
  when 'one'
    :one
  when 'two'
    :two
  when 'three'
    :three
  else
    raise 'Unknown arg'
  end
  
  puts Foo.new.send(meth)
  
end

So I'm using a case statement to convert valid method names to symbols, which I then pass to #send and bam!, my method is called. This made my code a ton easier to write and I'm here espousing the technique to you.

But what is the drawback? Well, if someone were to ever really get up the courage to tackle the task of building a refactoring browser for Ruby, this sort of thing would give them fits. They can't really tell where those methods are called on my class until they are actually called. Heck, given the code above, they can't even figure out what methods exist on Foo without running the code.

The other drawback is that this code is a little hard to read. Most new casual Rubyists won't think to search for the symbol version of a method name. Its even harder if you're still somewhat new to Ruby and you aren't aware this sort of thing even happens.

For me personally, the concise code I can write with #send far outweighs the drawbacks. I preach the importance of code reading regularly, and its how one can get over the "hump" that is knowing how to navigate software that sends dynamic messages to objects.

Your homework is to share how you feel about #send in the comments.

SNL Transcripts: Luke Perry: 02/06/93: Weekend Update with Kevin Nealon:

That wasn't English, Keith! I mean, you're talking in Esperanto, or some language twins teach each other! I mean, the King's English, man! I mean, throw us a bone man - alright!

I wanted to post a video of the Weekend Update skit where Mike Myers plays Mick Jagger and Mick Jagger plays Keith Richards, but it appears such video does not exist on the web. You'll just have to read the transcript and make it happen in your head.

Exploratory hacking in TextMate

My first foray into screencasting:

'Tis a little tutorial on a little bit of joy I use regularly. In TextMate, you can add xmp markers like so:

1 + 2 # => 
String.class # => 
%w{foo bar baz}.each { |w| w.upcase } # =>

Then if you hit Ctrl+Shift+Command+E, you get this:

1 + 2 # => 3
String.class # => Class
%w{foo bar baz}.each { |w| w.upcase } # => ["foo", "bar", "baz"]

This is a great way to do exploratory hacking. Plus, you don't feel like you're doing "printf" style debugging. And that makes everyone feel cooler!