Binary Code

The folks over at FriendFeed have found a neat, geeky way to give instant gratification to changelog/feature junkies*: publish the Mercurial changeset descriptions.

I particularly like this change:

changeset: 9aa41470d10f
user: bret
date: 2008-02-27 15:30:19
description: More rounded corner images. Why must corners be rounded? Why, Web 2.0, why?

Dude, I feel your pain.

(*I confess I feel this way about Adium betas. I read all the changelogs - probably the only software I do that with.)

“I’ve seen things you people wouldn’t believe.” - Roy Batty

One of the things I thoroughly enjoy about Ruby are the linguistic gymnastics it allows developers to pull off. In my brief time with Ruby I have laughed at the cleverness and audacity of more code than any other language I can recall. Not a “ha ha” laugh of mockery or dismay, but one of sheer delight in the truly weird shit that other people tweak out of it.

Rails’ gymnastics with method_missing(), alias() chaining, to_proc() weirdness - clearly that way lies madness! …or does it?

Whether I think the use of those techniques is a good idea or not, or whether I choose to follow down those obscure and dark meta-programming pathways or not is a personal choice of really no consequence at all (unless, perhaps, you have to maintain my code) but that they can be done at all is of significant consequence to all developers. The existence of these features is sufficient to stretch my mind and affect my thinking about how programming languages can and should and do and might work and for that I celebrate them.

It is no small understatement to say that in fifteen years as a developer no other language has instilled in me the joy of simply poking and prodding at it, and following along as others smarter than I poke harder and prod deeper at it, than Ruby has.

“Liberty means responsibility. That is why most men dread it.” - George Bernard Shaw

Of course the black sheep of Ruby meta-programming is so-called “monkey-patching”, a most excellent term if ever there was one.

Oddly enough, when I first heard the term, in the context of Rails, I didn’t fully understand the implications at the time and took monkey-patching to mean simply the dynamic addition of functionality to a class (ie: “adding stuff”) whereas I now correctly understand it to mean both that and the dynamic modification of existing functionality in a class (ie: “screwing with stuff”). Unfortunately for me my first understanding has imprinted itself so deeply to the point where I intrinsically think of monkey-patching as a Good Thing™ and often get caught unawares when someone rips off on a rant against it (that Good Thing is not a statement of absolutism, kindly calm yourself down before firing off a “you’re an idiot because!” comment, those who tend to do so).

Not that I don’t absolutely anti-disagree that screwing with stuff is not a good idea. I am vehemently in the “don’t fuck with established, documented functionality” camp. If your clever gem over-rides my Ruby’s Object#eql? method I’ll cheerfully join the mob and bring my torch (the burny kind, not the battery-operated kind, for my British readers).

But I really enjoy additive monkey-patching. I like that I don’t have to wait for the language designers to decide to incorporate new functionality. I like that I can install a gem and get Integer#even? intrinsic to all my numbers (yes I am aware of how trivial the code to implement that functionality is, thank you very much). I like that sometimes I have to lean back in my chair and think “module or monkey-patch?” before hacking away. It’s a good dilemma to have, this thinking about the fundamental implementation, and implication, of language functionality.

Is monkey-patching over-used? Abused? I don’t know; I honestly don’t have an opinion on that. My experience says less is better so if I had to pick a side I’d tend towards the “monkey-patch as last resort” camp but sometimes it seems to make perfect sense.

But only as an additive.

To deal with this schism in my thinking about monkey-patching I’ve come up with another term for code that screws with established functionality: donkey-patching (the poker plays in the room should get the reference immediately).

If I may steal from the Wikipedia and modify their monkey-patch definition a bit:

A donkey patch (also spelled donkey-patch, DonkeyPatch) is a way to extend or modify established, standard core runtime code without altering the original source code for dynamic languages (e.g. Smalltalk, Javascript, Ruby, Perl, and Python).

A common source of unintended consequence, teeth-nashing, anger and frustration.

A bad idea.

Friends don’t let friends donkey-patch.

Chalain has successfully killed FizzBuzz by creating the FizzBuzz Ruby gem:

irb(main):002:0> require 'rubygems'
=> true
irb(main):003:0> require 'fizzbuzz'
=> true
irb(main):004:0> puts fizzbuzz

I have nothing to add to this except: sweet.

Now what?

First, allow me to state that while having never played with Adobe AIR or Flex 3 I’m sure they’re fine products and many people I respect seem to thoroughly enjoy them. However Hank Williams seems to think they’re going to kill Windows in Adobe Introduces Windows Killer (also over on CenterNetworks):

What Adobe is doing is building a platform to replace all operating systems as a development target, and the implications of this are profound.

For most applications it does not make sense to write directly to the OS any more.
…
Adobe AIR is a tool that allows developers to build Flex applications or HTML/Javascript applications that work on the desktop but have access to the Internet and can synchronize between the web and the desktop when offline.
…
Adobe’s strategy is a death stroke to Windows as a strategic monopolistic platform.
…
RIP Windows 2008.

I appreciate the sentiment (and even the unspoken “OS X Killer / Linux Killer” nature of it) however two things bug me about the hyperbole in Hank’s statements:

1. Windows et al. are operating systems yet Hank is really talking about application-space. Big, big difference there. As great as Flash is it needs something to sit between it and the networking hardware (unless Adobe’s also created their own OS underneath AIR?) and that’s going to be either Windows or Mac OS or Linux. Desktop app killer? Perhaps. OS killer? I don’t see how.
2. Write once, run anywhere (WORA) on the desktop has thus far failed on both fronts. The track record of this genre is not so great. Whither Java.

Hank also makes no mention of that pesky elephant in the room of WORA: usability and ubiquity of user interface. It would be great to think “hey, my next web site can really be a desktop app and I’ll sell it for millions to all users!” but I suspect that AIR apps that look like Windows apps will flop with OS X users and AIR apps created by Linux users will be inscrutable and unusable by anyone but Linux users (ok I kid… actually I don’t).

On the other hand MySpace is wildly successful and it proudly presents steaming piles of shit for a UI so who the hell knows.

Update: AIR is a slick wrapper for the WebKit rendering engine, SQLite, and a ton of custom HTML and OS-specific code underneath it. Not only is AIR not an “OS killer”, it’s extremely heavily dependent on the underlying OS.

Fun thread over on Reddit in which people with either way more skills or way more time than me compare their bash prompts.

Me, I’m boring. I just use:

PS1=”\w/: “

I also feel the need, in this command line-oriented post, to mention Blacktree’s Visor, which kicks all sort of Terminal ass and looks wild to boot. Hotkey’d to:

Ctrl-Shift-`

Tickets went on sale today for RubyFringe and I was on the fence about it but… its a geek party in my home town - how could I not?

See y’all in Toronto on July 18!

(And while Reg is promising “something wild” to demo, I don’t quite aspire to that but I do promise to have…something.)

In the specification of a current project we have need of a profanity filter. While writing the spec I thought it would be a fun diversion to see how quickly and in how few lines of code a reasonably functional basic profanity filter could be created in Ruby (I don’t actually enjoy writing documentation so I’m easily convinced to do otherwise).

Fear not. The following code won’t see production. I’m aware of how easy it is to circumvent the “protection” and besides the final project will be in PHP, through no fault of Ruby’s. (Don’t even go down that road).

This was originally a one-liner but I couldn’t resist wrapping it in a function and adding in basic (ie: poor) pluralization:

# A bare-bones word ('profanity') filter that checks a string of text for prohibited words
# and returns any that appear in the prohibition list. Also checks for some basic plurals.
# Not intended to be comprehensive, complete, or  particularly expansive. Just hacking.

def filter_profanity( check_str = "", prohibited_words = [] )
  prohibited_words += prohibited_words.map { |w| w + “s” }
  return check_str.downcase.gsub!(/[^a-z]/, ” “).split( ” ” ).uniq!.map { |w| w if prohibited_words.include?( w )  }.compact!
end

# This will spit out a list of the words contained in “str” that aren’t allowed according to “prohibited”
str = “This is a CAT and another cat and some dogs. And parrots too.”
prohibited = ["cat", "dog", "pigeon", "ocelot"]

puts filter_profanity( str, prohibited )

Question: Can the pluralization be worked into it such that the function is once again a one-liner and is still readable by the average Rubyist? I haven’t figured out a way but….

Update: Seems like this might benefit mightily from the inclusion of Jeremy McAnally’s acts_as_good_speeler Rails plugin. Implementation is left as an exercise for the compulsive-obsessive reader.

Thoroughly enjoyable talk by Zed Shaw about the history and economics of Mongrel: Mongrel, 2500 Lines, and Economics.

Well worth watching if any of the proper nouns in the sentence above are familiar to you.