Nimble Code: Category Programming

Rails Under the Knife

harrisj@nimblecode.com (Jacob Harris) — Thu, 26 Jul 2007 18:20:00 -0700

After months of rehearsing and revising, I finally gave the talk at OSCON. I think it could use another month of refinement, but people seemed to enjoy it, and I actually enjoyed giving it as well. If you were at the talk, thank you for coming and feel free to let me know if you have any feedback or questions.

My talk was Rails Under the Knife, a look at the some of the internals of Rails to get a better idea of 3 powerful Ruby techniques:

Metaprogramming
Reflection
Blocks

You can download the slides at

http://s3.amazonaws.com/harrisj-share/oscon2007.pdf (5mb PDF!)

This talk is aimed at an intermediate Rails programmer who knows the basics of Rails coding (I have another similar talk for beginners called Rubyisms in Rails), but still is a bit unsure about the power trio of serious Rails hackery. Hopefully, this will help to provide some inspiration for you to delve into the Rails code on your own. Enjoy.

Packaging Your First Gem With Hoe

harrisj@nimblecode.com (Jacob Harris) — Wed, 10 Jan 2007 14:36:00 -0800

My name is Jacob Harris, and I am a rubygem addict. I’d estimate I have hundreds of them tooling around on my hard drive, useful little snippets of Ruby or C library wrappers or random noodlings. I might not actually use most of them in any of my projects, but like a vast library of unread books, I enjoy having them around. But for the longest time, I’ve been a freeloader. I’ve downloaded gems, but I’ve never written one, but it’s time I start giving something back.

And so, I’ve written my first gem. It’s nothing incredible – all things have to start simple – but I like it. It’s called Amazon Hacks and it consists of two classes (for now) to benefit people whose sites handle Amazon links. The Amazon::Hacks::Link class contains a few methods to extract an ASIN from any product link, normalize product links, and append an affiliate ID easily. The slightly sillier Amazon::Hacks::Image class puts a convenient Ruby wrapper around the convoluted syntax Amazon uses for its image transformation engine. If you work on a site that links to Amazon product pages (e.g., All Consuming), try it out and let me know if it works for you or it can be improved. It’s simple to get started, simply run

gem install amazon-hacks—include-dependencies

Which brings me to hoe. Last night, I gave a talk on hoe to the NYC.rb group and the slides are here if you want to learn more about the process.

Building Your First Gem With Hoe

Before last week, I had no idea of what it takes to create a gem, but it seemed like a lot, and I had better things to distract myself with. And it does indeed require a fair amount of busy work, what I call administrivia, to turn your snippet of Ruby code into a packaged gem, and this work has to be started anew for each gem you want to create. Now, as pragmatic programmers, we learn to automate menial tasks whenever possible, and hoe makes the creation of gems a lot more manageable by automating the busy-work away via a set of useful rake tests. The result is more time for coding, faster releases, and more likely you’ll release that gem in the first place. So, give hoe a shot, learn about gems, and start writing gems. You’re a brilliant Ruby coder, it’s time to share it with the world. And when you write that gem, I’ve got a cherished spot on my hard drive for it.

Or You Can Cheat

harrisj@nimblecode.com (Jacob Harris) — Wed, 27 Sep 2006 13:08:00 -0700

Wow, long time no blog. Work and home life have just sucked all the mental energy out of me lately. For those of you who still have kept me in your feedrolls or click here from time to time, I have a new set of slides presented for your personal enjoyment.

Last week—transfixed by the horror of an empty slate of speakers—I decided it was time to give another talk to the NYC.rb and so I spent a few days throwing together a presentation I titled Or You Can Cheat. It’s all about how you can write C extensions for Ruby and also how this something you shouldn’t undertake lightly. I have a very interesting approach to presentations: when I want to learn more about a subject, I throw together a presentation on it. I think the combination of casual interest and the abject fear of humiliation in front of my peers is a great personal motivational tool. This talk continues that trend, and while I can not claim to be a definitive expert on C extensions for Ruby, I certainly know a lot more about the subject now and I think you will too.

If you are interested, you can download the talk here

Or You Can Cheat (600K PDF)

This is a bit more silly and off-the-cuff than Rubyisms in Rails, and I really enjoyed it. There are a few references I should clarify though. First, there is the matter of arepas. The arepa is the official food of NYC.rb and it is a rite of passage here to take visiting Ruby eminences to our official supplier, the Caracas Arepa Bar. Asides from being addictively tasty, arepas serve as a perfect metaphor for Ruby extensions, in that they wrap the tasty ingredients inside a pragmatic corn flour shell. They really are that tasty. Yes, I also suppose I was a bit harsh calling Joel Spolsky a troll, but I had no other term to describe his wild extrapolation that current Ruby interpreter performance augurs that Ruby will always be slow, that Rails is a horrible web development framework, and how you should shackle your entire development environment around the slowest part. But he is right that Ruby currently is slow for some uses, and C exensions are a potent way to resolve those edge cases without throwing in the towel.

And yet, I hope you’re not dropping everything to write them.

Why the lukewarm recommendation? Well, I think Ruby performance has become an all-purpose scapegoat these days. In some cases, this is deserved (we need YARV. Now.), but it’s all too easy to blame Ruby when the real problem is your web server, your database, or some stupid algorithm you wrote that’s wildly inefficient. Rule all that out first before you dive into C extensions for Ruby. Because C is dangerous, C is tricky, and C is just plain no fun. C extensions can be like eating an arepa filled with broken glass if you aren’t careful. But they also are a useful tool for performance and especially for wrapping existing libraries and legacy code.

Which gets me wondering if there are any cool killer apps for C extensions and Ruby. Are there some cool open-source libraries that would be nice with Ruby bindings? How cool would could a combination of Starfish and RubyInline really be? Would we need to use C extensions to create rbsh, a Ruby shell? What other fun things could you do if you had nice Ruby tongs to keep that nasty C code at bay? Let me know if you have any awesome ideas and if you enjoyed these slides. And in return, I’ll try to see if I can actually blog again one of these days. Thanks.

Rubyisms in Rails Redux

harrisj@nimblecode.com (Jacob Harris) — Wed, 02 Aug 2006 09:46:00 -0700

self.promote!

I am pleased to announce that the digital shortcut PDF version (to purchase, you have to go to the Digital Shortcuts page or you can buy it from Safari Sorry!) of my Rubyisms in Rails presentation is finally available for purchase. At 54 pages in length for the low price of $9.99, I guarantee you’ll glean at least 18.5 cents of insight from each page (disclaimer: that’s a mean instructional value; although gorgeous, the title page is not particularly educational in itself).

In addition, the book is also now available in Safari Books Online, and possibly Amazon or other retailers as well. Also, be sure to check out the list of other upcoming Ruby titles.

So, what’s in it? If you’ve read the original presentation, you already have a sense of the scope of material I am covering here, but the shortcut allows me to focus on the material in greater depth. The result is a richer and more thorough examination of the examples presented in the original slides. If you are an intermediate to advanced Rails hacker, you probably know all this stuff already. But if you are a newcomer to Ruby through Rails, or you still find yourself still stuck coding PHP or Java-like Ruby, this ebook might help to align your thinking to the Ruby way.

Will I write another ebook? I’d say yes, but I’ll have to think up another interesting topic. But if you are ever thinking of creating a technical book, I’d recommend starting in a smaller dose like this first. As I discovered, even 54 pages can be a lot of work, and it’s better to test out your time commitments and abilities with something small before you start pitching large references. But that’s a topic for another blog posting. Make me happy: Buy the ebook or read it on Safari and give me your feedback. Thanks!

Update

Fixed purchase link to be go to Shortcuts page (where you can add to cart).

Things I Figured Out

harrisj@nimblecode.com (Jacob Harris) — Mon, 03 Jul 2006 09:58:00 -0700

And now for something different (and shorter, for those recovering from the length of the last post). Insanely talented Internet prankster Rob Cockburn recently posted a short and sweet article Things I Figured Out, where he listed a bunch of interesting and slightly stupid revelations he’s had over the years. This has been followed by 15 pages of reader comments chronicling their own brilliant insights and forehead-slapping moments.

I think this is a brilliant idea for an article, and I’ve certainly had my moments of utter brilliance and sheer stupidity (even this blog probably has examples of both). So, I’m going to post a few of the things I’ve figured out on my own or, failing that, learned the hard way. But since this is a technical blog only, there will be no personal idiocy. Just technical things I now know better about now

XML is Not For Everything Great for long data files, lousy for configuration files, downright terrible for love notes. It’s not one-size-fits-all.

XML Is a Minute to Learn, a Lifetime to Master It’s easy to gloss over some of XML’s subtleties when you begin, but they’ll get you later if you aren’t careful. Sadly, very few resources articulate some of the things that’ll get you, but maybe there’s a future blog post about that.

Somebody’s Done It Better Already I’m being glib here, but one of the joys of Open Source is that if you need a generic component, it’s best to look for someone who’s created it already. For instance, if you need a logger, you could write one on your own, but there are excellent libraries out there and your time is better spent writing stuff you can sell.

HTTP Blows Away Raw Sockets Unless you absolutely, positively have no choice, there is no reason you should use raw sockets instead of HTTP protocol for remote services. Sure, it might be harder to set up in the short run, but it’s so much easier to debug and maintain in the long run this is a no-brainer. Especially since small, light, and fast HTTP parsing libraries are available for all.

Often Too Much Is Worse Than Too Little Or as Donald Knuth put it, “Premature optimization is the root of all evil.” I’ve been stung so many times by trying to be clever, I’ve finally realized I should see if it’s slow before I try to fix what ain’t broke.

Stored Procedures Are Evil DBAs swear by them because they’re supposed to control access and speed up performance. In reality, they move application logic out of your program into an awkward language (SQL) that will usually fall out of sync with your application and aren’t kept consistently in sourcesafe or migrations. Worse still, they’re the trenches for warfare between developers and operations.

Developers Black-Box Way Too Much It’s too easy to leave this with a cliché admonition to “think outside the box,” but it’s sadly true. As developers, we’re taught early the useful technique of abstracting away complexity within black boxes. This is useful for that third-party API or calling operating systems, but it’s very easy to fall into that trap in your job (“we’ve always done it this way”) or your life (“I’ll just wait for career advancement to come to me”).

Physical Contact Matters The Internet still hasn’t annihilated geography yet. And personal, physical presence still matters. Meeting people is so much better than emailing them. Which I guess is just a roundabout way of saying, yet again, I should’ve gone to Railsconf. Sorry!

You’re Going to Screw Up The First Time. Just Accept It. It’s so easy to fall into the fear of not getting it right the first time, you never get started. Get over it. Accept you’re going to make mistakes the first time around and you’ll fix it later and do the best you can. And if you can, write unit tests to make it easier to clean it up when you start.

Things Break Slowly, Rarely All at Once It’s rare you can pinpoint a single decision or piece of code where everything catastrophically failed. Instead, the road to failure and mediocrity is a gradual and painful process, of many small failures along the way. It’s hard to resist the downwards momentum, because it always seems feasible to reverse. I would like to see more project management texts that tell you how to stop digging that hole.

If You Can’t Explain It, You Shouldn’t Do It. Sometimes I think half of IT operates by overwhelming your natural instincts and confusion with so much jargon, your brain just gives up. It’s a mysticism of sorts, but the wakeup to reality again is painful. My rule of thumb is if I can’t explain it in plain English using metaphors, and optionally table utensils, then it’s not worth doing. Because it most certainly will not be maintainable.

Okay, that’s all I have so far. But I’m sure the realizations will keep coming. Happy 4th of July everybody!

Are You Happy?

harrisj@nimblecode.com (Jacob Harris) — Wed, 31 May 2006 15:25:00 -0700

I read a lot of feeds. A lot of feeds. In my hobby trend-spotting (it’s like a dorkier birdwatching), I read my feeds to monitor the zeitgeist to see what the real Alpha Geeks are into. And the last year has had some interesting trends. For instance, dynamic languages like Python and Ruby are now firmly the new wave, although functional languages (Haskell, OCAML) and prototype languages (Io) seem to also be attracting interest. Web2.0 is a term bandied around casually, mocked, and even litigated over , but the concept seems to be here to stay. The most novel aspect I’ve seen about Web2.0 is that the Web has become a source of real tools many developers are using to manage their lives; as a holder of Sun stock much diminished in value, I guess I can at least take comfort in the fact that their adage “The network is the computer” seems to finally be coming true. Sure, it’s about 6 years later than predicted, but it’s happening.

But most interesting to me is when the alpha geeks flock to ideas not directly related to coding frameworks, business plans or the like. For instance, six months ago it seemed like every serious hacker was devouring Getting Things Done and blogging about organizing their lives. And now the new obsession is Flow. A conceptualiztion first coined in a book fifteen years ago, Flow is a term Mihaly Csiksczentmihalyi (don’t ask me to pronounce that) coined for that mental state where work is stimulating but not frustrating, intention translates effortlessly into action, and happiness and productivity are intertwined. Csiksczentmihalyi teased out a description of Flow by looking at the mental states of people practicing Zen mindfulness or risking bodily harm in extreme sports like rock-climbing or surfing. But he could just as easily described the euphoric states of serious computer programming. Small wonder this book has now been “discovered” by the alpha geeks, this fleeting feeling is what we find so addictive about programming in the first place.

The basic concept of Flow is that certain tasks make us happy to do them because they exist within a narrow channel between fear and boredom, because they encourage us to improve our skills but do not overwhelm us with too many challenges at once (for Donnie Darko fans, the goal of flow is to find the middle of the fear-love axis). We developers are well-acquainted with that fear. It’s the fear that keeps you from refactoring that legacy system because you’re not sure what would break, the fear that keeps us using a clunky library because we can’t test changes, the fear that makes deploying the new version to the server nail-biting because it’s crammed full of changes that might take it down. In short, fear and specifically fear of change is a constant state of mind for too many programmers, but it doesn’t have to be. A state of happiness is possible if you can conquer the fear.

Flow is the reason why some frameworks like Ruby on Rails are so appealing to programmers; it straddles that line between utter boredom (coding a web site in PHP like always) and high anxiety (having to master a complicated system like Cocoon just to print out “Hello World”). The key is allowing people to add capabilities (like authentication, tagging) as their skills grow, but not require everything to be planned up front. It conquers the fear of change, but hacking change into smaller steps. What makes a framework good (the same is true for languages, methodologies, testing, architectures) is how it destroys this anxiety.

For most of my career, the basic question asked of developers was are you productive? Computer programmers are naturally obsessed with productivity. This is after all a field where good programmers can outperform bad coders by several orders of magnitude. and for years the industry has marketed to this by selling tools that promise leaps in productivity. The key to productivity was seen only through uses of higher-level toolsets/IDEs or APIs. This is a philosophy Cote has memorably termed Right-Click Coding because of all the right clicking and fiddling you have to do to get anywhere. This was seen as a development accelerator, because it enabled poor developers to do complicated things like enterprise integration and GUI development without needing to actually write code or learn details of how things work. But, I think that overall such tools have actually decreased developer productivity in several ways. Like a teacher teaching only to her worst students in class, the wizards and libraries stifle and frustrate more able programmers. And since they remove developers from using the underlying code, wizards only accelerate bloat and complexity in their underlying code bases.

Worse of all, the fear was still out there. Indeed, like air conditioner output makes city streets hotter, they’ve made the situation worse. By piling away programming within massive APIs and single-purpose wizards, this approach has created a nightmare of complexity waiting to ambush more able developers. Now the question becomes are you compliant? Being savvy to the latest standards, libraries, or buzzwords is touted as the key. But the difficulties people have had using SOAP is but one example of how compliance doesn’t really help either. Just mention “interop” to any CTO or high-level architect and you’ll see what I mean. The complexity (and the fear) are still there, standards compliance just blames the programmer when things go wrong.

Instead, it’s time for a new question: are you happy? I think the growing interest in Flow and GTD and higher-level languages and test-driven development and agile project management reflects a sea change in attitude by the alpha geeks. Trying to find happiness through artificially increasing productivity is like putting the cart before the horse. The key point of Flow is not that productivity fights fear and creates happiness, but recognizing that creating happiness is what creates productivity. I think it’s about time, if we want to avoid the descent into compromises and disillusionment common in computer science. So, get in touch with your feelings when deciding about that design, language, system, api, etc. and ask yourself “am I happy doing this?” I think your instincts are a better guide than you know. Trust them. And don’t be afraid to be happy.

Update: I added some links to the original book as well as discussion in a short take posting. Happy reading!

Rubyisms In Rails

harrisj@nimblecode.com (Jacob Harris) — Tue, 25 Apr 2006 10:44:00 -0700

In an apparently blatant attempt to be more like Amy Hoy, I’ve decided it’s time I did some Intro to Rails writing. Tonight I’m going to be giving a little talk on what I’m calling Rubyisms as seen in Ruby on Rails. I think one of the things that makes Rails so cool is how it is built upon some of the best aspects of Ruby’s style: duck typing, symbols, blocks, and metaprogramming. And yet, I think many newcomers to Rails don’t really notice some of the magic going on behind such simple declarations as

<% 30.minutes.from_now %>

or more complicated Rails cases like

class Review < ActiveRecord::Base
  belongs_to :article
  validates_presence_of :author
end

My humble little slideshow goes out to those Rails newcomers hacking code to look like PHP or Java. The conceit is to use some sample Rails code as starting points for deeper explorations into some of the Ruby coolness lurking inside Rails. This is a nice little look under the hood, but I hope it will educate people new to Rails on how to embrace Ruby style for cleaner and cooler code.

I’m posting the slides early for some last minute feedback and I might update these files if any other errors are found. I’d like to thank NYC.rb compatriots Sebastian Delmont, Ryan Raaum, Trotter Cashion, and David Black for their help and corrections as well.

The presentation itself is two parts. I’m releasing it here in two style. The light version is stripped of interstitial chapter screens and is a lot easier on the bandwidth:

PDF Version
Flash Version (Note: Flash version is cutting off bottoms of some slides)

If you like what you see there and want to get the version I’m presenting with images, the full 2MB PDF dump is also available:

Huge PDF Version

Anyhow, I hope you enjoy my little presentation, and as always feedback and corrections are welcome in the comments.

Update (8/2/06)

This presentation is now available for sale as a digital shortcut from Informit (54 pages, $9.99). Please see my Rubyisms Redux for a small pitch and purchasing links. Thank you!

If You Can't Scoop The Poop, You Shouldn't Own A Dog

harrisj@nimblecode.com (Jacob Harris) — Thu, 02 Feb 2006 15:59:00 -0800

If you own a dog in New York, you’re probably very familiar with the sentiment of the title. New York has “pooper scooper laws” that require all dog walkers to clean up after their dogs. It’s not really pleasant to clean up after my dog, but it’s something I accept as part of owning her. It’s simply being considerate to my fellow person, but especially to my fellow dog owner; when someone doesn’t clean up, it makes all of us look bad.

Perhaps it’s a result of fatigue from having stayed up late the night before fixing an urgent bug, but the next morning at the dog run with Bella this seemed like a remarkably good aphorism about taking responsibility as as a programmer.

I can’t really give details, but I was up the night before fixing an extremely critical bug. I was fixing the bug because it was my fault. And I was fixing it that night because it was vitally important it not inconvenience customers any further (it had already affected them for a few days). And the bug was completely my fault, not the code’s, not the operating system’s, not my coworkers’ or the QA testers’, all mine. And this is what I told my boss and my coworkers, and this is what I think was also told to the customers.

This may sound like I am only pointing out what’s natural (like tooting my horn about how my heart is able to speed up when I exercise). But from my experience, software developers are horrible at handling failure. We blame it on the language we write in, the overwhelming complexity of our tasks, those testers we expect to find all our bugs for us or those project managers we expect to manage all our time for us. When we fall behind on deliverables, most of us keep silent and vainly hope we can catch up before the next milestone (a mistake so common it’s earned the euphemism hope creep among project managers). And when we mess up technically in front of the customer, we mask it in euphemisms like a technical error has occurred whose passive voice make the customer wonder if they’re being blamed and if errors just magically fall from the sky like rain.

To be fair, taking responsibility hurts. It damages your pride, makes you look bad for the moment, and might almost feel like a career-limiting move. But as Chad Fowler puts it in My Job Went To India, you must learn how to fail. Your managers might be pissed at the moment but I think honesty as well as concrete plan for fixing things and taking action will impress them. Your customers might be annoyed but will appreciate your forthrightness instead of fuzziness when explaining what broke and will love it if you can make things right as soon as possible instead of a few months. It’s good for your fellow developers because it fights the cynicism and despair that result from too much unapologetically bad software already. And it’s good for your character. You will actually turn out the stronger for having taken your lumps and emerging from it.

So, the next time something breaks (and there will be a next time), embrace it. And if that’s too hard for you to do, get a different career; and don’t get a dog.