naildrivin5.com

Website of David Bryant Copeland

Make Tests Clean and Clear without Duplication

January 08, 2012

Some collegues and I were dicussing dupication in tests, specifically how much repitition of code across tests is acceptible. On the one hand, you want each test to stand on its own and indicate what it’s testing. On the other hand, just because we’re in a test doesn’t mean that all the rules about duplication of code don’t apply; tests need to be maintained to, and if you make a large change, you don’t want to have to change it in several places.

How much duplication is too much or, what does duplication in tests mean, and how does it affect the understandability and maintainability of our tests?

2011 In Review

January 02, 2012

At the start of 2011, I blogged about a “professional goals” file I found on my computer, and compared it to what happened. I kindof enjoyed the exercise, so here’s a repeat.

Review of 'Working with Unix Processes'

December 22, 2011

I just finished reading the short and to-the-point Working with Unix Processes, by Jess Storimer. Although I cut my teeth on C and UNIX programming, it’s been a while, and I figured I’d check the book out to see what insights it might have, especially given that it’s written from a Ruby perspective.

In short, I’d recommend this book to someone interested in command-line Ruby (and who might have my book), but who has very little UNIX programming experience. This book is a crash-course in the basics of UNIX Process management.

That being said, if you are (or have been) familiar with things like fork and exec, you’ll find this book a bit too light, especially given the price (update 1/2/2012 see inside).

Introducing Methadone, the Awesome Command-Line Library

December 19, 2011

I’ve spent the last year writing a book on building awesome command-line applications in Ruby. Over the course of writing it, I’ve used a lot of Ruby libraries for building command-line apps, and none of them work quite right. In my book, I spent significant time on OptionParser, since it’s builtin, and GLI, since I wrote it (and since it’s actually very fully-featured compare to the alternatives).

I just finished up an appendix where I showed alternate implementations of the running examples using main, thor, and trollop. I did this for a few reasons:

  • These tools are popular, and people have asked if they’d be included
  • They are, by and large, very different from how OptionParser and GLI work
  • I wanted to give them a real shakedown

I also surveyed many other tools, but, alas, I couldn’t include everything. Each of these tools have a common theme, which is to avoid the boilerplate of OptionParser, and make it really easy to parse command-line arguments. They all have done this, but at a cost. All of them are less powerful and extensible than OptionParser, and only slightly more compact (or, in the case of main, more verbose).

Enter methadone, which has all of OptionParser’s power, but the compactness of these other frameworks.

My Book's in Beta!

October 25, 2011

Build Awesome Command-Line Applications in Ruby

Control your Computer, Simplify your Life

Woot!

My Book is in Beta! Whoohoo! It’s all about writing amazing command-line apps in Ruby. This isn’t about hacking together UNIX commands, or bash scripting…this is about making apps that are easy to learn, easy to use, easy to write, and that will delight their users. Seriously, stop making crappy command-line scripts, read my book, and start kicking ass.

It’s been a long time coming. Please stop now, and go check it out. I started this almost a year ago during PragProWriMo, where I wrote (almost) every single day in November of 2010. When I saw that Travis Swicegood (one of the few who made it all the way through) had gotten his manuscript accepted, I cleaned up a chapter and submitted and the Prags accepted!

I’ve spent my time since then writing, re-writing, re-organizing, and working hard to get this thing done. It’s in beta, meaning that you can buy the e-book and read the work in progress. It’s almost complete, just a few chapters to go, and by reading it in beta, you can give me valuable feedback to make the book even better.

Check it out now!

DC's New 52 Review

October 21, 2011

I’ve always liked superhero stuff, but was never into comics as a kid. Reading Wikipedia summaries of the insanity that is the DC universe’s continuity makes me never want to touch the stuff. Now, it seems, they’ve thrown all of that out and started things fresh. Though it’s not a reboot. Whatever.

image

Why I'd never work for Google, Twitter, or Facebook

August 01, 2011

Just got back from OSCON 2011. There were some really interesting talks, and “the big three” were all over the place: Google, Twitter, and Facebook. I attended the Twitter talk on how they moved from Ruby to the JVM, as well a talk by Rob Pike (of Google) on Go. I use Twitter and Google a lot, and enjoyed hearing about how they work (Facebook, on the other hand, I use begrudgingly).

My first reaction to these talks was “Wow, it sure sounds like a lot of fun to work at these places!” From inventing programming languages to using Scala to scale a massive architecture, it sounds like developer shangri-la. Until recently, I was slinging Spring MVC code in vanilla Java. Sucks for me, right?

This is lazy thinking, and I haven’t fallen victim to it in quite a while. Ask yourself: “Why would Google spend the time and money to get Rob Pike to work for them and invent an entirely new programming language?” Ask: “Why would Twitter spend the time and money to design and deploy an elegant, scalable architecture using the JVM and Scala?”

An awesome new programming language, or an impressive, scalable architecture is not an end to itself. These are tools that serve some other purpose.

In the case of Google, Twitter, and Facebook, that purpose is to serve ads.

Although Steve Yegge’s keynote features him “quitting” his project at Google (which he describes as “sharing cat pictures”) to work on some higher calling (still within Google), he’s just trading one ad-serving system for another.

Google+ isn’t about sharing cat pictures, it’s about serving ads. Twitter’s massive network of 140-character bits of information isn’t about connecting people across the globe or to view current trends in worldwide thinking, it’s about serving ads. Facebook isn’t about entertaining yourself with games or sharing interesting links, it’s about serving ads.

So, why are the best and brightest in the industry busting their asses to work at these places? If all you care about is watching performance metrics increase, or playing with something new, or just watching lots of tests pass, I guess it’s nice to get paid well. But, how can this be truly fulfilling? For me, it wouldn’t be. I need the tools I’m building, the products I work on, and the architecture I’m helping to create to all serve something I’m interested in.

I’m not saying that my code needs to save the world or support humanitarian causes, but it should at least be something that I like, or I would use, or that I care about.

And I can’t fucking abide advertisements. Honestly, I don’t know anyone who does. Except, apparently, a lot of really smart software engineers.

I spent a dollar on something that's free

April 28, 2011

Co-worker sent out an email today, letting everyone know about a handy Mac app called cdto. You drag it to Finder and, if you click it, it will open a Terminal window where the current working directory is the folder you’re viewing in Finder. Pretty handy.