Tag Archives: programming

Teach Yourself a New Programming Language in 21 Minutes (Or 2-3 Years, It Depends)

17 Replies

You’re sitting at work, grinding out a bug in the legacy system, when your boss comes in and tells the team that you finally get the chance to rewrite the whole system–and even better, you get to do it in Clojure! (Or Scala or Erlang or Rust or Dart or some other Language You Only Know A Little About But Have Secretly Wanted To Learn For A While Now.)

Or maybe you’re happy with the language you’re using, but your VP of Software Architecture just spent $150,000 on a suite of Enterprise Tools which includes a module that will let your project scale infinitely into the cloud… all you have to do is learn Clojure. (Or Scala or Erlang or Rust or Dart or some other Language You’ve Only Heard a Few Mutterings About But Desperately Want To Avoid Learning.)

Either way, you’ve got a problem: you need to ramp up in this new language. And whether you want to become a super expert guru ninja rockstar in the language, or just learn enough of it to make it go away, you want to do it fast–and that means you want to avoid making the same mistakes I made learning Ruby and JavaScript over the years. Mistakes which I have learned to fix, mind you, and so without further ado I present:

Teach Yourself A New Programming Language In 21 Minutes (Or 2-3 Years, It Depends)

All you need to do to learn a new language is learn:

  • How the language encapsulates data
  • When the language invokes execution of code
  • Where do the semicolons and braces go

I’m not entirely kidding. This was my strategy for a decade and to this day if I need to get something bashed out quickly in a new language I’ll skim a language reference and let the compiler tell me when I make syntax errors.

In general, as long as you’re staying largely inside the world of what I call “BOLS” (Block-Oriented, Lexically-Scoped) Languages, such as C, C++, VB, Java, C#, PHP, Lua, Python, Ruby or perl, you can in fact learn enough pidgin to get by very very quickly with this method. Granted, in those last three languages it will be obvious to experienced programmers that you’re writing inelegant code. But you can get by, is what I’m saying.

If you’re the second kind of programmer I mentioned, you might be done. Just read this next section for a caveat and then you can hopefully stop there.

Don’t Stop There If You Can’t Stop There

As you’re learning the new programming language, ask yourself the two vital tradeoff questions:

  • Do I really want to learn this language bad enough to actually learn this language?
  • Can I afford the time and energy needed to fumble around being bad at this language?

See, this strategy is especially useful if you know you don’t plan to ever actually learn the language. I have written some pretty arcane bash scripts in my day, but to be honest I wrote my first bash script 10 years ago and in that time I’ve written less than 10,000 lines of bash scripting code. It’s just not worth learning to me, so I keep some files around with examples of the most obvious kinds of things I want to do, and when I need a new bash script–usually about twice a year–I have all the pieces I need right there. BAM. Ignorance is bliss, and laziness is, occasionally, brilliant time management.

But this strategy is especially awful if you know you don’t plan to ever actually learn the language, but you turn out to be wrong. It ends up that you find yourself using it on a regular basis, and hilariously, you don’t even notice this for years and years. This is true for me of elisp, the flavor of lisp used to program emacs. I’ve written elisp for years longer than I have bash, but maybe only twice as many lines of code. I find myself needing an elisp tweak on a weekly basis, and end up spending an hour researching how to do it. And two or three times a year I find a problem that I could solve elegantly in elisp, if only I knew how to express what I was thinking as lisp code. But I don’t solve the problem. I merely sigh, and learn to live without whatever cool new feature I was thinking of.

I wrote that paragraph in present tense because I still haven’t figured out that I really do need to actually learn that language. Shut up.

Sometimes work and politics can affect your decision as well. If you and your boss agree that the Next Big Thing will be written in Language Y, then you have the need and your manager has the afford.

(And sometimes these two forces are in conflict. I could write an entire blog post on the political machinations involved when you and your boss disagree on the do/don’t want or can/can’t afford questions. Skunkworking a cool language or shirking a lame one is a topic for another post, one I’ll probably never write, but basically it would be all about office politics. I’ve seen people get fired for a successful skunkworks project and others get promoted for sandbagging a project. People sure are complicated!)

Okay, NOW if you’re the second type of programmer, you can safely stop reading. If not, you’re pretty much out of luck for the “21 Minutes” part of learning a new language. But keep reading, because the 2-3 years bit isn’t until the very end. Most of the mistakes I’ve made learning a new language I have made in the first few days.

Truly Embracing A Language Takes Time, But You’re In A Hurry, So…

If you want to embrace a language, it’s going to take time. You’re going to have to internalize the language’s entire approach to solving problems. You’re going to have to learn its idiosyncracies and its warts, and you’re going to have to learn its power moves and elegant applications. That all takes time, but if you’ll permit me to point out my favorite pitfalls and some less-traveled paths around them, I can maybe show you a trick or two for leveraging your learning.

But first, good news/bad news. I’m writing this assuming you already know a programming language or three or seven. The good news is, the more languages you know, the faster you can recognize the basic syntax patterns and logic structures of a new language. But the bad news is: the more languages you know, the more they tend to blur into a common model of computation in your head. This can make you blind to the elegant weirdnesses of your new language. Resist the urge to judge weird things quickly; they often turn out to be the most powerful features of the language once you “go native”. If you see something you can’t stand, remind yourself that you haven’t seen everything there is to see, and give the new idiom a chance. Try it out and learn its tradeoffs. It’s okay to discard a bad idea in JavaScript once you understand why it’s a bad idea in JavaScript… but it’s never a good idea to discard a feature of a new language based on your instincts–because your instincts come from other languages, not this one. (Read up on The Blub Paradox if you haven’t heard of it before.)

TL;DR This Is Mostly About Your Blind Spots

I should have put that TL;DR up at the top, but if you don’t know by now that I’m that kind of jerk, you must be new. Welcome to my blog! Anyway, here’s the list. I’ve included illustrations about Ruby, Python and JavaScript, because those are the three languages where I stunted my own growth unnecessarily the longest.

  • As you start learning the core principles of the language, listen hard for hints and clues from its culture. Ruby has block syntax, but a rubyist often cares more about naming than blocks vs. Procs. Python has list comprehensions, but a pythonista often cares more about being able to quickly uncover all the working parts than to have a slick but magical-looking API. JavaScript has objects and polymorphism, but listen to a good JavaScript programmer and you’ll find them more interested in the functions themselves–and their prototypes.
  • Be ready to try totally new ways of thinking. Be ready to abandon bottom-up provability for Ruby’s top-down “programming by wishful thinking” approach. Be ready to trade off a more efficient algorithm in Python for one that is more readable and maintainable. Be alert to the pains you’ll feel trying to write object-oriented code in JavaScript–that’s JavaScript’s prototype system refusing to be hammered completely into an OOP-based inheritance model.
  • Learn where the minefields are. Ruby is a memory hog. Python’s primitives aren’t actually objects. All numbers in JavaScript are floating-point numbers–there are no integers.
  • Learn which minefields you can ignore or work around. Entire models of webservice design have been rethought and reinvented to compensate for Ruby’s apache-unfriendly execution model. Python isn’t THAT slow to begin with, but if you really need bare-metal speed it’s easy to write a C extension. Many JavaScript libraries provide “polyfills”–bits of code for old versions of JavaScript that implement features added to newer versions of the language so that you can write code against a stable JavaScript version and still have a prayer of it working in most browsers.
  • Most importantly, learn which minefields you CAN’T ignore. Treat them like minefields that you must commute through daily. Stop and pay close attention. Map them out carefully. For example, metaprogramming in Ruby is a very dangerous feature, but it’s not a defect; it can be used responsibly. Python’s whitespace enforcement makes it difficult to express certain ideas succinctly, but that whitespace enforcement produces a predictable rhythm to the trained pythonista’s eye, and it is most definitely a feature–don’t let your code fight it; learn to restructure your thinking. And while almost everybody considers JavaScript’s semicolon insertion rules to be eccentric bordering on insane, you MUST learn them if you want to avoid having your program suddenly stop working just because you deleted a comment or swapped the load order of two completely unrelated files.

You can make good inroads to these blind spots in a few days or weeks if you’re just aware of them. So here’s the hard part: Last of all, learn the idioms. From here on out it’s all about learning to think in the language. That’s going to take you a bit longer, and there’s nothing for it but to talk to other programmers, find some online references, maybe buy a cookbook… but mostly, it’s going to take writing code. Lots and lots of code. In my experience (both personal and observing coworkers and clients) this last part’s a doozy–plan on it taking a couple years or more.

Whaaat. You did say you really wanted to learn this language, didn’t you?

Start Small. Start Growable.

Leave a reply

Languages Should Be Growable

One of the fun things in Computer Science is finding new and mind-blowing stuff that turns out to be 15 years or more old.

I just watched Guy Steele’s 1998 OOPSLA talk, Growing a Language. If you haven’t watched it, go watch the first ten minutes and you’ll be hooked for the rest of the talk. I don’t want to give anything away but there’s a huge bomb that he drops in the first ten minutes that not only kept me riveted for the rest of the talk, but then made me rewind it and watch it again. (Remember how you watched Sixth Sense, and the bomb gets dropped at the end and you had to watch it again? And then the director explained his use of the color red in the movie, and you had to go watch it a THIRD time to see that the bomb was constructed right there in front of your face the whole time? Yeah, Guy’s talk is like that.)

In his talk, Guy discusses whether a language should be large or small; a large language lets you say many things easily but requires that you and your listener both learn many words before you can say anything. A small language lets you both start talking immediately, but requires that you spend a lot of time creating new words before you can say anything interesting.

I won’t tell you whether Guy thinks you should create a large language or a small one–in fact, Guy won’t tell you either. But he does make it clear that a good small language must be growable, and a good large language must be both well-groomed and still growable. He even goes so far as to say that most good large languages are the ones that started small and grew over time, with good cultivation.

Bless his misguided heart, he then says that Java is a good language. I have to point out that this establishes his crazy-person street cred right there, but in a way, he’s right: Java DID start small enough to be easily understood. It grew slowly, and with careful curation. This was in 1998, and Guy then goes on to point out that Java is fundamentally broken and ungrowable unless they add some growth mechanisms to the language, such as generics and operator overloading. Most Java programmers today think of these as “having always been there” in the language, and they’re probably part of the reason Java is not only still around, but a dominant language in the industry today.

Applications Should Start Small… and be Growable

So I’m working on an new app right now, and I want to do some good OO design up front to ensure that the app looks and works well. But I’m stuck trying to figure out where to start. Funnily enough, I opened Sandi Metz’ book, POODR (Practical Object-Oriented Design In Ruby) for some guidance, and I found this astonishing guidance right there at the top of chapter two:

“What are your classes? How many should you have? Every decision seems both permanent and fraught with peril. Fear not. At this stage your first obligation is to take a deep breath and insist that it be simple. Your goal is to model your application, using classes, such that it does what it is supposed to do right now and is also easy to change later.”

Sounds familiar, doesn’t it?

Libraries Should Be Growable… or Well-Grown

I’m a fan of RSpec. If you’ll permit me stretching Guy’s language metaphor, it’s a big language for testing, with many words. I can test very complicated ideas without extending the language, and someone who has learned RSpec’s language can read my complicated ideas without learning new words.

MiniTest is a very tiny testing language. It has only a few words. As a programmer not used to constructing new words in my testing language, I initially found MiniTest to be insufferably repetitious. Each test used ten words or so, and nine of them were identical in all of my tests. When presented with this frustration, Ryan Davis shrugged with annoyance and snapped “so write an abstraction method!” It wasn’t until I watched Ryan write tests at MountainWest RubyConf this year that I realized that he does this all the time. This means that a) he was not kidding b) he was not being dismissive and c) that adding words to minitest’s language is in fact exactly how MiniTest expects to be used.

Interestingly, while I think RSpec’s large language is elegant and well-curated, many programmers feel that RSpec has grown in the wrong direction, or has at least become buried by overgrowth. Ryan felt that even Test::Unit had too much cruft in it, let alone RSpec, so rather than prune the language back, he started fresh, started small, and most importantly, started growable.

When Ryan spoke at MWRC, he created a new testing word that I felt did not make much sense. Even watching him define it I thought “Okay, I understand the abstraction, but that word is horrible. It doesn’t communicate what the word does at all.” That’s the drawback to small languages: naming things is hard, and small languages require you to name things from the start. Had I been pairing with him we’d have had a splendid argument about the name of the abstraction method he wrote. But that sort of fits into Guy’s logic as well: growth should be carefully curated. As you grow, you’ll create new words, and those words should be easy to learn and understand or you can’t communicate well.

Growth Should Be Curated

I’m gritting my teeth as I type this, but I have to own up to it: The growth of Java has been well curated. C# has also been well-groomed, even if I think the language designers have carefully and consistently solved all the wrong problems with the language.

I think PHP is probably the poster child for bad growth*. That’s in addition to its internal syntax inconsistencies; I’m just talking about the language’s internal methods. For a quick example, see how many different clumps of consistency you can find just in the string functions. For a longer example, read @eevee‘s rant, PHP: A Fractal of Bad Design. (TL;DR? Fine, just click on the rant but don’t read it–just scroll down to see HOW LONG it is.) PHP’s problem is twofold: they added things inconsistently, and they were unwilling to prune things back out of the core once they had been added. PHP has grown much faster than Java and C#, because the maintainers were willing to make mistakes rather than deliberate for years in committee, but like Java and C#, PHP hasn’t gone back and fixed mistakes once made.

In my opinion, Ruby sort of gets a B+ on growth curation. A lot of words are unnecessary synonyms (count and size and length, for example) while other words are occasionally synonyms that suddenly change meaning when you’re not expecting them to (Array#count and ActiveRecord::Base#count, for example). Some things in the language are pretty bizarre edge cases (The Kernel#test method, for example) and in the new Ruby 2 release one major feature (Refinements) was brought in under strident protest. But by and large the methods across the entire language are consistent with each other, and when they vary it is usually to be consistent with some external protocol that they are modeling. Ruby 2 was willing to break backward compatibility in order to fix mistakes and grow sufficiently. I also cut Ruby some slack because it’s growing extremely fast in comparison to other languages, and having the breaking changes in Ruby 1.9 for 3 years before committing to Ruby 2 let the community keep pace.

So Grow, But Grow Carefully

And that’s sort of my whole point here: Size and growth are key tenets at every level of abstraction: for a single application, a broadly applicable test suite, or an entire language, two rules I’m drilling into my head right now are

  1. Start Small. I can’t say “Always Start Small” because sometimes the problem you need to solve is big. But it is fair to say “Always Start As Small As Possible”.

  2. Start Growable. This one IS gospel for me. However big I choose to start, I think growability is essential for success.

  3. (Bonus Rule) Curate your growth, but don’t be so afraid of growing wrong that you become afraid to grow. Be willing to grow and then weed.

And if all else fails, start over with a new small thing and start growing again.

* Note: Every time I kick PHP’s tires I get hate mail from offended PHP programmers who assume I’ve never used the language. The fact that PHP programmers are the only group worse than rubyists when it comes to language fanboyism is a topic for another day, but for now, let me just say $$dispatcher->$$method. If you’ve never written your own framework in PHP, that little snippet of code means I am better at PHP than you. I have pushed out, much like an agonizing stool the day after an all-night taco binge, a little over a million lines of PHP code. It is the foul tongue of Mordor, but I have earned the right to dislike it purely on its lack of merit. If you like it, that’s fine. It’s your choice. I’m not saying PHP doesn’t have its good points or that I can’t write clean code in it. I’m just saying it’s not worth it to me.

Two Questions

Leave a reply

Recently I was talking with a friend about coaching and specifically the act of helping younger developers improve themselves. I had a sort of microepiphany when I realized that I’ve been improving myself for over two decades with the same pair of questions, originally unconsciously and only recently in my active consciousness. The next time you do something you want to get better at, ask yourself these two questions:

What about this makes me feel good? This is a VERY specific question, and it is NOT “what do I like about this?”. It’s often hard to answer. You are not allowed to say “I don’t know”, and you are not allowed to settle for answering the much easier question “what about this do I like?”—although that can be a great guide into discovering what it is that makes you feel good. If you wrote an elegant passage of code, or did something clever, or shipped a really nasty hack but saved the company (thus buying them time to refactor your nasty hack) by shipping on time, that’s what you like. But go beyond this. What about that makes you feel good? Did it make you feel smart? Did it make you feel artistic? Did it make you feel like a hero? Did it make you feel like somehow, against all the odds, you might just be starting to “get it” as a programmer?

Take a moment and really just let yourself feel good about what you did. If you can find that and tap into it, you have just found a well inside yourself that you will return to again and again in the future. Congratulations, you’ve just found the reason you’re going to spend the rest of your life getting better at this.

If you can’t answer this question, don’t sweat it. But don’t be surprised if your life ends up going a different direction. Find something else that makes you feel good, and do that instead.

What about this could I do better? Most days, you’ll think of something right off. There was some duplication, or a lack of symmetry in the code, or your variable names were kind of awkward.

Other days it’s a bit harder. “Writing this bit felt a bit grindy, like I was pushing out lots of boilerplate. I don’t see how to fix it, but does it really have to hurt this much?”

The best days are the days when you try and try and just can’t answer it. Important: this doesn’t mean you did something perfect. Far from it, and far better: it means you’ve actually managed to see your blind spot. “This”, your brain is telling you, “this empty space, here… is where more knowledge will fit.” Those are the days that herald “getting it” on a whole new level.

So, them’s my questions for you. What made you feel good? What could do better?

Felt any good or done any better recently?

CoffeeScriptCookbook.com: How YOU can help!

1 Reply

CoffeeScript is awesome. There’s a HUGE problem with The CoffeeScript Cookbook, however: it does not exist.

Want to help me fix that? Please say yes.

I just bought the domain coffeescriptcookbook.com, and I want to give it to YOU. I mean it. I want to open-source the website code and crowd-source the cookbook content. Partly because I know a lot of folks are WAY smarter than me and partly because I just don’t have enough time to make the CoffeeScript Cookbook as awesome as I need it to be.

Ideally I want to build a sort of “vettable wiki” or perhaps a very trusting git-based website, where people can submit code samples quickly and easily (but still have some way to prevent people publishing XSS attacks without any kind of safeguard). Here’s a short list of what I would like. If any of this enthuses you, please send mail to my gmail account, “ratgeyser”. [Edit: added Geoffrey Grosenbach’s excellent tips]

Getting the Cookbook code/site off the ground:

  • Cookbook versioning. As of this writing, CoffeeScript is at 1.0.1. When it updates, I’d like people to be able to see in the cookbook what version introduced or changed a feature, or even to say “I’m using version x.y.z, please only show me valid recipes for that version.”
  • Syntax highlighting. Sort of obvious there, I guess.
  • Examples runnable in-browser, the same way they are on The Main CoffeeScript Website.
  • Automated recipe testing. Essentially, if you submit a recipe that’s supposed to evaluate 3 + 4, you should be able to put something like # => 7 underneath it, and if the code DOESN’T evaluate to 7, the recipe should be flagged as broken.
  • With automated recipe testing in place, we now have the ability to check a recipe against various versions of CoffeeScript. You write a recipe for version 1.1.0, and the site can immediately say “works in 1.1.0 and 1.0.2 and 1.0.1 but not in 1.0.0”. Then it can add those recipes to the cookbooks for those versions. Also, when a new version of CoffeeScript is released, all recipes can be checked against it instantly, and you immediately get a working Cookbook for that version.
  • Website design that doesn’t suck. I’m a programmer, I draw boxes around everything and every website I design looks like ass. And not just regular ass, I mean ass from 1996.

Contributing CoffeeScript Examples

  • Promotes good CoffeeScript style (as opposed to code that compiles but isn’t idiomatic)
  • Helps new programmers learn how to get over common roadblocks
  • Self-checkable examples where possible (see the bit above about automated testing)

Thoughts? Ideas? Offers to help? Let me know!

Tourbus 2 is Out!

Leave a reply

I just released Tourbus 2.0! You can get it by cloning the tourbus repo in that link, or by simply installing the gem from rubyforge.

What’s TourBus?

TourBus is a ruby framework for stress-testing a website. You define “Tourist” classes that “tour” their way through your site, and then tell tourbus to send a load of them at your site.

What’s New

Better Syntax, and tested support for most rubies. TourBus 2.0 has been tested and found worky on:

  • JRuby 1.6.0 <– strongly recommended, as it has better threading
  • MRI 1.8.7p334
  • MRI 1.9.2p180
  • REE 1.8.7-2011.03

Upgrading from Tourbus 0.9

  • Your tour classes will change; they are now called tourists and they go on tours, instead of being called tours who run tests (which really never made sense anyway)
  • Open your tour class, and change it to inherit from Tourist instead of Tour.
  • Change before_tests and after_tests to before_tours and after_tours.
  • Rename all your test_ methods to be tour_ methods. E.g. “def test_simple” => “def tour_simple”
  • That’s it! Tourbus should now run normally.

Quick and Easy Setup

gem install tourbus

Okay, let’s say you have a website running at localhost:3000 and you want to test that home.html includes the text “hi there” even when being pounded by hundreds of visitors at once. Let’s install and set up everything all at once! cd into your project folder, and do the following:

mkdir tours
 
echo 'class Simple tours/simple.rb

That’s it, you now have a tourist ready to wander over to your site and request the home page. Let’s run him and see that everything’s okay:

tourbus

You should see a clean run followed by a text report showing what happened. If that worked, let’s make your tourist go through the website 10 times in a row. But let’s ALSO make 100 different tourists to the same 10 laps with him, all at once:

tourbus -n 10 -c 100

Happy server stressing! Check out the README for more info.

Bonus: Isolating Tourbus

Here’s how I like to install tourbus. I cd into my development folder, and then do:
rvm install jruby-1.6.0
rvm use jruby-1.6.0
rvm gemset create tourbus
rvm gemset use tourbus
git clone git://github.com/dbrady/tourbus.git
cd tourbus
gem install bundler
bundle install
gem build tourbus.gemspec
gem install tourbus-2.0.1.gem # (update version if it changes)

Next I cd into my project and do

echo 'rvm use jruby-1.6.0@tourbus' > .rvmrc

This lets me run tourbus under jruby and its own gemset, so even if my website is running rails on MRI, I can still get the lovely JVM native threads when tourbussing my site.

James Edward Gray: Associative Arrays and Ruby Hashes

5 Replies

Yesterday I put out a little screencast showing some ways of Creating Ruby Hashes. James Edward Gray II pinged me on Twitter and basically said “Great screencast! Ooh, but you forgot this! Ooh, and this! And this!” and so of course there was nothing to do for it but invite him to do a pairing screencast with me.

This video is a bit of a weird hybrid. You get 7 minutes of podcall, then 18 minutes of screencast, then another 12 minutes of podcall. James shows off some of the “hot new awesomeness” of Ruby 1.9, and then points out that this awesomeness has been around for a couple of years and nobody’s using it, in spite of it having been in the current Pickaxe for nearly as long. Along the way we talk about regular expressions, testing dogma, and the importance of never squashing creativity in the open source community. All in all, an incredibly fun time for me. James threatened to come back and do another one with me on regular expressions, and I’m mentioning it here in writing so that everybody knows I plan on taking him up on that offer.

No podcast, because half of it is us typing into a shared screen session. But here’s the video. You may need to watch it on Vimeo or download it to see the font clearly.

Associative Arrays with James Edward Gray II from David Brady on Vimeo.

CRAZY Bash Programming with Wayne E. Seguin

3 Replies

Okay, let me start by saying “holy freaking crap”.

I met Wayne E. Seguin at MountainWest RubyConf, and we immediately hit it off, much to the dismay of many onlookers. At one point Evan Light said “It would be interesting to find out which of you two has the most disturbing sense of humor.” Both Wayne and I immediately shouted “OKAY!” and then I didn’t hear what either of us said after that because everyone around us was screaming “NOOOOOOOOOOOOOO!!!!!!!!”

Now, Wayne created the incredible rvm, or “Ruby enVironment Manager”, and what’s more, he created it all in bash rather than using a “real” programming language like Ruby or Python. It turns out that Wayne’s been doing a lot of bash scripting, writing BDSM which doesn’t stand for what you think it stands for and instead stands for “Bash Deployment and Server Manager”. Then again the project image is a penguin dressed in leather cracking a whip over a 4U server wearing a ball gag. So maybe it also means what you think it means.

But I digress. The point is, Wayne’s been doing a LOT of programming in bash lately.

A few weeks ago, I tried to add rvm-prompt to my bash prompt, and found that I couldn’t. I learned enough bash scripting a couple years back to write a totally sweet bash prompt that showed my git branch in different colors based on the name. Master and Production branches show in an alarm color, story branches in a calm cyan, etc, like so:

But while my prompt was sweet, my bash prompt programming was… well, not so sweet. It chained half a dozen sed scripts together to inject the ANSI color codes for each branch name, and like I said, was so complex I could not debug it. I showed it to Wayne with a mutter about “I should probably extract this to a function or something”. Wayne looked at it and made this sort of incoherent cry of alarm and dismay. In his defense, this was the prompt:

A few hours later, he called me on Skype and said, “Can I help you with your bash prompt?” I said “Sure!” and Wayne turned on screen sharing.

What I didn’t know is that he had Haris Amin on the line as well, and he had prepared an entire bash programming lesson for us.

What HE didn’t know is that I have been in the habit of recording my Skype sessions. When Wayne switched us to his Adobe Connect sharing session, I said, “Hang on, you’re not sharing this with Skype, I need to start my OTHER screencast recorder.”

And here it is. The most awesome hour I spent last week:

CRAZY Bash Programming with Wayne E Seguin and Haris Amin from David Brady on Vimeo.

Yes You Should Test Private Methods (Sometimes)

4 Replies

Lasse Koskela recently wrote Test Everything, But Not Private Methods on his blog. Thank you for writing this, Lasse. This is one of the most intelligent, albeit still wrong, posts I’ve read on the topic. Lasse specifically addresses one of my greatest concerns, which is simply that “if it can possibly break, it should be tested.”

It turns out that on the face, we are in agreement: you should not leave complicated code untested. Lasse’s answer (which is repeated by several folks, including Michael Feathers and Mike Bria) is simply to not write complicated private methods. If you have a complicated private method, you should make it public and test it. If it doesn’t belong on the public interface of the class, then move it to another class or create a new one where it can be public. As Michael Feathers puts it in his book Working With Legacy Code: “the real answer is that if you have the urge to test a private method, the method shouldn’t be private; if making the method public bothers you, chances are, it is because it is part of a separate responsibility: it should be on another class.”

I’m a huge fan of Michael Feathers, bordering on Fanboy lunacy, so I’m a bit hesitant to disagree with him. Also, to be fair, I agree with Lasse one hundred percent–about 90% of the time. However, Mike and Lasse present “extract method to class” as a panacea when it is in itself merely a tradeoff with serious consequences of its own.

Extracting a class dilutes and adds complexity to your namespace. Code should struggle very hard to earn a spot at this level. I spend a lot of mental energy on a project trying to understand the class hierarchy, so much so that it is worth my effort to spent time trying to keep it well-organized to assist this understanding. A method that was meant to be private and to serve a class at a specific point in time suddenly becomes a public object. Care must be taken to either make the new class generic enough and provably safe to be used by arbitrary clients, or to prevent other classes from accessing the class at all. If you find yourself trying to figure out how to control access to the class, chances are the code you are trying to extract really should be private after all.

If you are going to extract the private method to a class, considerable care should be taken that it does not, in fact, still fall under the responsibility of the class that contained it. If your new class ends up with an “-er” name, especially “-Manager” or “-Controller”, it’s probably just a Functor–a method call masquerading as an object. If the moved method has many side effects, especially ones that modify instance variables, the moved method will end up taking many arguments and returning many values that the original class must then use to modify itself. You may just end up passing in the original class to the method. Now what you’ve done is replaced the “this” keyword with a variable named “that”. This is a code smell; it’s called Feature Envy, and the solution is to move the method into the envied class. If the new class has the original class’s name in its own, you’ve all but conceded that the new class is useless in isolation from its progenitor; all you’ve really accomplished in this case is cluttering up the object namespace in order to achieve one outcome: making the private method testable. Lasse eschews inelegant workarounds like reflection nonsense or package hackery, but complicating the object map is just as inelegant if it achieves nothing more than making a private method public.

Another counterargument is–and though this is a situation that I wish did not actually exist, every developer has in fact faced it–extract class is not a free refactoring, and on large legacy projects it may be prohibitively expensive. Suddenly “change the design” becomes “they shouldn’t have designed it that way in the first place” and the only solution is to invent a time machine, go back in time, and not have done it wrong. This isn’t practical.

Sometimes you have a method that is, and should be, both private and complex enough to require testing. When that happens, you should test it.

I agree with Lasse and Mike about the problems inherent with testing private methods; I just don’t think their proposed solution is always workable.

This post is getting long, so I’m going to breaak it into to two separate entries. Next up: I want to present some cases when I think I should, even using TDD, design and write private methods that should be tested. I’m also going to address what I think is the primary concern of anti-private-testers, that testing private methods is testing implementation. (Teaser: I completely agree–but I hope to show you why, in some cases, that’s not a problem or at least an acceptable tradeoff.)