Because Rails can never have enough diversity of testing philosophies, code_anthem today announced the hottest thing to hit Rails since fixtures called Developer Driven Development (DDD).

From the article:

Development Driven Development (DDD) is a revolutionary new approach to development that focuses on … you guessed it, development! DDD takes a radical approach in an industry filled with tests, metrics, and processes by allowing smart developers to write code. Some managers and even developers have a hard time wrapping their heads around it conceptually because it does require a shift from existing thinking.

How does it work?

1. First, the developer thinks about the problem they need to solve
2. Then, they solve it (usually by writing code, not always)
3. Repeat until done

DDD vs TDD vs BDD vs FDD vs ADD vs …

There are people out there writing code who really shouldn’t be. They produce bad code and crappy software.

The obvious (and correct) solution to this problem is to only use bright, thoughtful programmers.

Nice work — sometimes we get wrapped up in the nuisances of our development methodologies and other areas that our clients ultimately have very little interest or insight into. It often takes a humorous post like this one to remind us of the core principals of what really matters, namely, creating useful software that solves real world problems. Apparently common sense really isn’t all that common these days.

From TUAW TV: The Savant experience in NYC.

Filing this one under: Things to do when you have entirely too much money (but fun to try none the less).

Full story

it “should appeal to Rails developer’s sense of humor” do

Disclaimer: Unless you are familiar with Test-Driven Development with Rails Training and Behavior Driven Development, this video probably won’t make any sense whatsoever — On the contrary, if you are a Developer or Tester / QA type who happens to work in those environments, this video is friggin’ hilarious.

end

This one caught my eye tonight and I wanted to capture it for posterity if nothing else.

No, I Wouldn’t Hire a Programmer That Has No Interest in Programming Outside of Business Hours

I read this on proggit:

A while ago my company interviewed someone who, in the course of some standard question, said that after the 5 o’clock whistle blows, they avoid computers totally. They don’t have any hobbies involving their PC and often don’t turn it on unless they are expecting an important email or need to look up directions. I followed up to ask how they got into programming and they said they took the right courses in college and now has had a few jobs doing it.

Would you hire a software engineer who isn’t a hobbyist programmer? What if they avoid computers totally at home? Does it matter if a candidate has strictly a professional interest in software and just pretends it doesn’t exist outside the office?

Here’s another way to frame this question: Would I even interview a programmer who only works their programming job from 9-5? If not, why not?

The answer is remarkably simple. No, I would not interview them, for the simple reason that I don’t know who they are and they don’t know who I am. When I am hiring, my first and best source of prospective colleagues is my network. Industry people I know. Where do I get to know people? Conferences. Open source. Blogging. Twitter. I don’t advertise my job openings on monster.com. So how did this person come to sit in front of me to tell me he(?) pretends software doesn’t exist outside of the office?

I think you have to align your values with your complete hiring process, not just with your interview questions. If you value people who are passionate about their craft, you have to use a different means of selecting prospects than if you value having warm bodies sitting in chairs. If you want a warm body with a certain minimal competence in a chair, you use monster.com and recruiters to find people. if you value community and craft, you use your network and your community.

Done this way, questions like the above tend to take care of themselves.

---

While doing some cleanup on my delicious bookmarks tonight, I came across this picture on Ruby Central showing Yukihiro Matsumoto/”Matz” with his new Mac laptop. In this particular picture, if you squint just right (or perhaps it had something to do with the fact that it was nearly 3:00AM), there is a certain resemblance between Matz and Justin Long in the Apple Get a Mac ads.

Thinking that Matz kinda/sorta looked a bit like the “I’m a Mac” guy, my twisted sense of humor immediately wondered what his PC version counter part might be in the world of programming. Not knowing a whole lot about the current .Net world, I looked up the creator of C# who turned out to be one Anders Hejlsberg who much to my surprise looked a whole helluva lot like John “I’m a PC” Hodgeman.

Talk about life mirroring art, even their life’s work mirrors this stereotype (see the sample code below) with one being needlessly complex and verbose and the other being elegant and precise (of course I’m biased – but you already knew that). See for yourself:

After all these years, they’re still at it: Gates vs Jobs

From RubyInside:

Ruby Version Manager ^{GitHub repo} (a.k.a. RVM) makes it ridiculously easy to install and switch between multiple Ruby versions on OS X and Linux. Over the last 24 hours, I’ve been playing with RVM and talking to creator Wayne E. Seguin and have been blown away with how cool (and simple) it is – you will definitely want to check this one out.

RVM’s most compelling feature is that it caters for six different distributions out of the box (MRI 1.8.6, MRI 1.8.7, 1.9.1, 1.9.2, Ruby Enterprise Edition 1.8.6, JRuby 1.3.1) and it’ll install them the first time you need to use them. RVM doesn’t mess up your current Ruby install – the RVM installed implementations are only activated manually by you and you can switch back to the “default” with one line.

It’s possible to install different patch levels if you like too and Wayne has put together a list of examples to show you the various things RVM can do from the command line (including gem management).

Time to break out the visine – the link leaves little doubt that you’ll be staring at the screen for hours to come after you check this one out.

A quick summary of the wiki:

…97 Things Every Programmer Should Know project, pearls of wisdom for programmers collected from leading practitioners. You can read through the Edited Contributions, browse Contributions in Progress, view the list of current Contributors, and also learn How to Become a Contributor yourself.

There is no overarching narrative: The collection is intended simply to contain multiple and varied perspectives on what it is that contributors to the project feel programmers should know. This can be anything from code-focused advice to culture, from algorithm usage to agile thinking, from implementation know-how to professionalism, from style to substance, etc.

Sometime around November, 97 contributions will be picked from the contributions made to this site and published in O’Reilly’s 97 Things series, which already includes 97 Things Every Software Architect Should Know (see also here) and 97 Things Every Project Manager Should Know.

The 97 chosen for the book will be the ones considered not only to be the best individually, but also the ones that fit best together. Every contributor whose contribution goes into the book will be fully acknowledged in the book and will get a complementary copy of the book when it is published. The contributions for the site are being edited by Kevlin Henney, who will also be listed as the editor of the published book.

Here’s a little taste of what’s in store at this O’Reilly Commons link.

• Fulfill Your Ambitions with Open Source by Richard Monson-Haefel
• Comment Only What the Code Cannot Say by Kevlin Henney
• Restrict Mutability of State by Kevlin Henney
• Speed Kills by Uncle Bob
• Encapsulate Behavior, not Just State by Einar Landre
• Only the Code Tells the Truth by Peter Sommerlad
• Interfaces Should Reveal Intention by Einar Landre
• Inter-Process Communication Affects Application Response Time by Randy Stafford
• Test for Required Behavior, not Incidental Behavior by Kevlin Henney
• Test Precisely and Concretely by Kevlin Henney
• Verbose Logging Will Disturb your Sleep by Johannes Brodwall
• The Road to Performance Is Littered with Dirty Code Bombs by Kirk Pepperdine
• Keep the Build Clean by Johannes Brodwall

Andy Baio of Waxy.org and Upcoming.org fame has recently published a heavily-annoted version of the 2000 documentary Code Rush which if you haven’t seen it, details the process of (then) Netscape open sourcing the code behind the Mozilla project all those years ago. This was initially posted some time ago but at the request of the director, was taken offline until recently where has now been released under the Creative Commons license.

It’s wild to watch this today and at the same look up and realize that you are (possibly) viewing it in the Firefox browser which was quite literally was born out of the labors portrayed in this movie. Andy also mentions that they’ve just posted some previously unreleased footage at Archive.org.

It comes as a surprise to absolutely no one that I’m a huge fan of the Rails Console and I advocate its usefulness for anyone learning about Ruby on Rails. In the early days of Rails, the Console was frequently overlooked in favor of some of the sexier parts of Rails but once you find yourself spending any significant amount of time inside of a Rails application, the Console quickly becomes one of your favorite tools.

That said, the Rails Console is far from perfect and before long you’ll inevitably find yourself wishing it was able to do this or that and you begin exploring possible enhancements & alternatives. One of the things that I initially wanted the Console to do a better job of was in helping me getting a better grasp in what was happening in my Rails app. I really wanted be visualize the output of some of what it was telling me.

Before too long I had added in Wirble which provided several nice enhancements to irb (which you can learn several good tips and tricks here) and life was good but being human I was left looking for other possibilities.

This path ultimately lead me to Hirb which is essentially a small view framework designed specifically for console based applications which not so ironically deals beautifully with irb and the Rails console. The official docs on its GitHub page explain xxx as:

Hirb currently provides a mini view framework for console applications, designed to improve irb’s default output. Hirb improves console output by providing a smart pager and auto-formatting output. The smart pager detects when an output exceeds a screenful and thus only pages output as needed. Auto-formatting adds a view to an output’s class. This is helpful in separating views from content (MVC anyone?). The framework encourages reusing views by letting you package them in classes and associate them with any number of output classes. Hirb comes with tree views (see Hirb::Helpers::Tree) and table views (see Hirb::Helpers::Table). By default Hirb displays Rails’ model classes as tables. Hirb also sports a nice selection menu, Hirb::Menu.

Installation is standard enough via Ruby Gems with:

sudo gem install cldwalker-hirb –source http://gems.gith

and you can quickly get into the swing of things via the Rails console via a simple call as follows:

bash> script/console
Loading local environment (Rails 2.2.2)
irb>> require ‘hirb’
=> true
irb>> Hirb.enable
=> nil

What awaits you is a much more visual experience in your Rails console. Not wanting to spoil the ending for you, I encourage you to checkout hirb’s GitHub page. These are still early days for me and hirb but so far, I like what I see and it only makes me want to dig deeper into the Rails Console to see what other tricks are hiding in there.

The Todo.txt Command Line Interface (CLI)

The sheer geekiness of this app warrants being posted but once you get past all the command line goodness – for those of us who routinely use basic text files for our daily todo’s and outlines – this is, at the very least, worth spending a little time playing with.

If you’ve got a file called todo.txt on your computer right now, you’re in the right place. Countless software applications and web sites can manage your to-do list with all sorts of bells and whistles. But if you don’t want to depend on someone else’s data format or someone else’s server, a plain text file is the way to go.

Problem is, you don’t want to launch a full-blown text editor every time you need to add an item to your to-do list, or mark one that’s already there as complete. With a simple but powerful shell script called todo.sh, you can interact with todo.txt at the command line for quick and easy, Unix-y access.