I thought it would be good to write down a few of my thoughts from CodeMash before I forget about it. There’s certainly more that impacted me, but something is better than nothing.

Pre-Compiler: Test Driven Development: From Concept to Deployment by Leon Gersing

Leon did a great job of somehow getting 50 people in the room to contribute to the same project. I was also amazed that the same number of people were able to share “what they did yesterday, what they are going to do today, and any blockers” in under 15 minutes. It was actually closer to 8 minutes on a few of the stand-ups.

I came away with some more GIT experience and a better idea of how to run an agile team. I liked the idea of starting from story cards and decomposing them into tasks and then allowing them to be spread out amongst the crowd. The one thing that was a little haphazard was the coordination of connected tasks.

The Not-GIT Talk by Jim Weirich

Jim is definitely one of my A-List speakers. He always prepares so well, knows his stuff, but also knows how to communicate it so dummies like me can understand it. I loved the way that he built up a so-called source control system from scratch (conceptually), solving problems along the way. This is top-of-the-line material. Oh, and you can see his presentation at the Pragmatic Programmer’s store in a screencast format.

NoSQL: Death to Relational Databases by Ben Scofield

There are a lot of non-relational databases. Need to explore them on my own to discover pros and cons of when they are beneficial and non-beneficial.

Ben encouraged us to start with a non-relational database from the beginning of a project to see how you would do things differently. He also mentioned the idea of polyglot persistence, that is having many different storage means for different purposes. This could be an interesting idea to explore as well

The Five Habits of Successful Lean Development by Mary Poppendieck

Purpose, Passion, Persistence, Pride, Profit

Mary gave a lot of examples of how these P’s play out. Persistence stuck out to me the most. She asked the question “What makes people really good at what they do?” The answer she gave was deliberate practice, and expert performance over a long period of time (10 years or 10,000 hours). This corroborates what Malcolm Gladwell talks about in Outliers.

1. Identify a specific skill that needs improvement
2. Devise (or learn from a teacher) a focused exercise designed to improve the skill
3. Practice repeatedly
4. Obtain immediate feedback immediately and adjust accordingly
5. Focus on pushing the limits and expect repeated failures
6. Practice regularly and intensely, perhaps three hours a day.

User Stories: Closing the Agile Loop by Barry Hawkins

You’ll never be as ignorant while building software about what is required for a project then when you negotiate the contract of what is in scope.

Treat a User Story as a placeholder for interaction, not a substitute for interaction. Here’s how User Stories differ from a Use Case.

• Smaller in Scope
• Not permanent artifacts
• Too brief to stuff with UI requirements
• Focus on functionality
• Facilitate iteration planning
• Analysis catalyst, not an analysis product

A User Story follows a format such as

Description of what’s needed

As a ________ User, (who is doing the action)
I want to ___________ (what do they want to do)
so that ______________. (to clarify the purpose and business value)

Conditions of Success (Acceptance criteria)

Scenario: _________
Given _____________
When I ____________
Then _____________

I’m electronifying my notes from conferences and such. Here’s my notes from Jim Weirich’s SOLID design principles in Ruby talk from eRubyCon 2009.

1.) Single Responsibility Principle
a class should have 1 reason to exist
describe the purpose of your class in a single sentence (you shouldn’t need and/or)

2.) Open/Closed Principle
you should be able to extend a class’ behavior without modifying it

3.) Liskov Substitution Priniciple
require no more, promise no less

4.) Interface Segregation Principle

5.) Dependency Inversion Principle
depend on abstractions, not concrete-tions

** Note that my notes are a little bit shotty, because the days prior to the conference I was totally totally strapped at work and thus rest-deprived.

Here are a few keybindings to help navigate in less

space | forward 1 screen
b | back 1 screen
Enter | forward 1 line
k | back 1 line
g | home
G | end
/text | search
n | next search
N | reverse next search
q | quits
v | open


In October, when my Laptop turned 5, and started getting a little fritzy, I started thinking about what my next machine should be. I considered getting another laptop, perhaps a MacBook. I really wanted a machine that would not complain if I worked it too hard. Laptops are great for portability, but I don’t really do that much travelling, and when I do, I have my work laptop.

My option B was to buy a pre-built desktop. The retail market has brought the cost of buying a new machine tremendously (I love the Gateway Media Center PC I bought a few years ago), but there are a few things I don’t like about buying from the retail market.

Components cost $1K

1. You get a package deal, which often gives you things you don’t really want or need
2. You are most often tied to a specific Operating System
3. You have limited customization

So, I settled on option C, building my own box. This would satisfy my desire to customize the machine components to my liking, pick my own OS, and select only what I really want. I needed to do a bit of research to see what is the best stuff out there. I found some good articles on what and what not to do and got advice from some friends. At the end-of-the-day, this is what I settled on.

Microprocessor

First things first, I needed to pick a CPU. Intel has been the front-runner in developing chips, so I looked in to their line. Honestly, I didn’t really even know what was out there. I settled on the Intel Core i7 920 processor.

The i7 920 is a 64-bit architecture, so you can add a lot more memory. The clock runs at 2.66 GHz, and has 4 cores (and is able to run 8 threads). That’s like putting 8 processors on one chip. My laptop has 1 core and 1.6 GHz, so this was multiplying my processing power by 16 (Moore’s Law in action).

The processor also comes with a larger-than-life heat sink (the size of a CD spindle) and fan (which sits on top of the heat sink to keep it cool).

Motherboard

Once I decided on the processor, I by default had picked the Intel X58 Express Chipset that I would need to use. I decided to go with the ASUS P6T Motherboard, which supports the Intel LGA1366 Platform. It has plenty of ports (built in Ethernet and sound), and plenty of room to grow (6 memory slots).

Memory

The memory modules needed to be DDR3 and under 1.65V. I wasn’t sure how much memory to get, so I picked a number greater than my current 1GB. So, I made like a linebacker and picked 6. I picked Corsair XMS3.

Hard Drive(s)

I wanted to set up a redundant RAID drive set, so I picked a set of 1TB Seagate Barracuda drives. They have a 32MB cache and run at 7200RPM and the best part was they were under $100 a piece.

Graphics Card

This was a tough one, because there are so many NVidia cards out there from different brands, with different model numbers. It’s a mostly intangible market. The two figures that actually meant something to me were the price tag, and the amount of memory on the card. I lucked out and found a great associate when I went to pick up my order at MicroCenter. He directed me to an EVGA NVidia card that has 1GB of memory for $70. I about crapped my pants when I saw that. A good graphics card makes the world of difference.

Case, Power Supply, and Additional Fan

When I went to the store, I found the Antec Three Hundred ATX Case, and the Antec Basiq 500 Watt power supply. The case has two built in fans, and three spaces for additional fans. I picked up an additional fan for the front for $20.

DVD-RW Drive

The DVD drive I bought was a $20 Samsung OEM Super-WriteMaster Dual/Double Layer 22x DVD±RW Burner.

Keyboard

I picked up a $15 Microsoft Curve keyboard as well. This one is quite ergonomic. Strike one up for M$.

Dual 17″ Monitors & Mouse

I already owned two 17″ LCD Monitors and a Logitech V450 Nano, so I didn’t need to add any additional cost for that.

FInished in Four Hours

Operating System

After using Ubuntu Linux at work for the last year, it was not a difficult choice to make Ubuntu Linux 64bit my core Operating System (I also run a Virtual Box VM of Windows XP inside of Ubuntu).

The Total Package

My shopping trip to MicroCenter was well worth it. The sales associates were very helpful, and it was nice to have the piece of mind to touch and see your product and take it home immediately. The total cost for the trip was $1000.

The time has gone by so fast. Before I knew it, my baby James has grown up to be a 3-year-old. He is such a sweet little kid. It’s fun to see James all grown up (no longer a baby). I still can’t imagine Joey at this age.
Kelly and I both think that he’s cautious like me, whereas Joey is free-spirited like his mom.

Last night, I made James a little parking lot on the dining room table with his ‘Cars Movie’ cars (the lines were made out of mini-marshmallows). When he got up this morning and saw the table, he unparked each car carefully, and then clustered the mini-marshmallows in a heap from which he shot them rapid fire in to his mouth like a semi-automatic machine gun. Five-seconds later, 40 mini-marshmallows had been cleared from the table and found a happy home deep down in the belly of a 3-year old.

James’ birthday party was a bit of a bust, We took a trip to the Orange Township park, but the weather decided to be a bit cold. We stayed for about an hour and then head home, meanwhile thinking about the Costco sirloin that was thawing on our kitchen counter. As I thawed myself at home, I was very thankful for the blessings of being able to have a family.

I ran across a good article about the current state of the economy. It’s a good explanation of the mess we are in, how we got here, and some current thoughts on how to get out.

It’s been a long time since I posted anything in my blog, so I thought I ought to break the silence. Lately, I’ve been trying to get myself caught up on the test-driven/behavior-driven development philosophy. If you are a programmer, maybe you can relate to my struggles of learning how to get it right.

Test-Driven Development is a programming philosophy that encourages the developer to specify test test conditions before writing the code to meet the specification. To me, this is counter-intuitive. I guess I am naturally a brute and think the best way to figure something out is to play with it, and than after a while it should just work.

Ironically, the chapter on Testing in the Agile Web Development with Rails book comes well after the first attempts at hammering out Rails code for a shopping cart application. I understand why the book is written the way that it is, and am greatly appreciative of the book, but there ought to be a Test-Driven version of the same tutorial, so that people can see first-hand how to test-first in development.

It also hasn’t helped that my first attempt at writing tests have been less than perfect too. I’ll end up writing 6 or 7 lines of test code to test one case for a method. The verboseness of tests has negatively reinforced me in to thinking that testing is hard.

What’s more frustrating is that I’ve heard expert developers talk about only having a line or two of test code to test a method. This has seemed to me to be an unatainable ideal. How are you supposed to test code that is ten lines long (or more) with one or two lines of test code? That’s unpossible.

But, recently I came to the realization that if the methods I am writing are smaller and do more specific things, then they are a whole lot easier to test. This is mostly because the tests can move towards the ideal of the expert: short, meaningful, specifications. This in turn helps me to actually write the test first, because I know I can specify the behavior of code that is less complex.

Some of the recent developments in RSpec have helped this ideal even further. For instance, see David Chelimsky’s post on RSpec 1.1.12 He notes that what you could have done

In order to test this:

class Person
  validates_presence_of :email
end

You would have in previous versions of RSpec written:

describe Person do
  it "should validate presence of email" do
    person = Person.new(:email => nil)
    person.should_not be_valid
    person.should have(1).error_on(:email)
  end
end

In RSpec 1.1.12, you can reduce this down to the following:

describe Person do
  it { should validate_presence_of(:email) }
end

This is due to:

• an implicit receiver from the describe block Person.new
• custom matchers for validate_presence_of (which are available through plugins like rspec-on-rails-matchers or you can make your own matchers
• self commenting specification code

Three lines of code. Three lines of test. That’s pretty darn cool. Perhaps, it’s not possible to have a line by line spec for everything, but this is a lot better than before.

I’ve still got a fair bit of inertia to overcome before I’ve got TDD under my belt. The more I tell myself that test-driven development is less about testing than it is about developing well-written code, the more motivated I am to do it. I hope this is an encouragement to unit testing newbies.

Today I was writing some specs with RSpec, the Ruby BDD Testing Framework. In between tests, classes aren’t reloaded by default, so I went about try to figure out how to reload a class for certain tests.

Active Support defines a method on Class called remove_class. This provides half of the equation. The other half was to reload the class again. So, I wrote a method on the Object class that should handle most cases. Note, this may not work with namespaced classes, but it did the quick and dirty job of helping my specs to reload the class.

# Call this method like
# MyRubyClass.reload!
# or
# MyRubyClass.reload!('/path/to/file/my_ruby_class.rb')
class Object
  def reload!(file = nil)
    remove_class(self)
    load(file || "#{self.to_s.underscore}.rb")
  end
end

All I needed to do was then call this method when I needed to reload the class.

MyRubyClass.reload!