Jake Scruggs

writes ruby/wears crazy shirts

Run Track Run

Apprenticeship is a big part of Obtiva (the consultancy where I work) so I introduced my friend Leah to Obtiva, they hit it off, and now she's an apprentice in the studio. Now apprenticeship at Obtiva is a paid, billable position. She's pairing everyday on a medium sized Rails business skill development project and learning a lot, but what just blew me away was the development of the "Run. Track. Run." project.

Leah is a runner and for years she's been talking about how she'd like to create a decent running website that could import Gamin GPS data and produce useful graphs for runners. Apparently all the sites out there plot every single point of data returned from the GPS device, with little-to-no smoothing, and so the graphs are extremely noisy and hard to read. Wouldn't it be great if an actual marathon runner designed a website for runners? At which point I would usually say: "Yeah, that's a great idea -- we should do that someday."

Here's the cool thing: A few months ago the developers in the studio were talking about putting together a Rails Rumble team, Leah brought up her idea for the website, the Obtivians loved it, and now it exists. Go see it right now if you want: Run. Track. Run. That's awesome. Leah had never written a line of Ruby code before this summer, but she got to be on a team of experienced developers (and one talented designer) who helped her implement a very cool website. She didn't pay these people -- they all volunteered to do it because they thought it would be fun to spend 48 hours building a website from scratch (which is the idea behind Rails Rumble). So in addition to getting paid to learn Rails as a day job, Leah got to build a website that had been rattling around her brain for some time now.

That sort of thing makes me proud to be an Obtivian and proud of Leah for implementing her idea.

I like RSpec, but I'm not a huge fan of it's built in mocking framework. So, when I have the choice, I swap it out for Mocha. However, I really miss mock_model. If you haven't used it, mock_model is an RSpec method where you pass in an ActiveRecord object and it stubs out a whole bunch AR magic so you don't have to. This is crazy useful when testing controllers because when you controller has a line like this:

I don't want to dig through a ton of Rails code to figure out what I need to stub on this model, I just want it to work. But I just found out that Mislav Marohnić has written a plugin that implements mock_model for Mocha -- so now I can get the best of both worlds. You can find it here:

Thanks Mislav.

So I had this form in a Rails view that needed some changes so, amongst other things, I changed this:
form_tag(:action => 'search')

to this:
form_tag(:action => 'show', :method => :get)

I had noticed that the show and search methods essentially did the same thing (and had the same views) -- which I why I refactored. However, when I made the change I got a 500. I was using restful routes and this form needed to be a get -- which I thought I had indicated. But I had not -- what should have put in the view was this:

form_tag({:action => 'show'}, {:method => :get})

There's this idiom in Ruby where we don't put curly braces around hashes if we don't need to, but I've consistently lost a bunch of time to mistakes like the one above. So I'm thinking about explicitly denoting hashes with curly braces in my future Ruby code just to improve intentionality.

The Omni Resort was beautiful -- this was our view during lunch:

Lunch at the Omni Resort 1

Lunch at the Omni Resort 3

Lunch at the Omni Resort 4

I liked the Hotel but everything was very expensive. Breakfast buffet? 20 bucks. Awesome (really good bacon) but still 20 bucks. Dinner? 40-50 bucks. Cab ride there from the airport? 80 bucks.

There was a tanning bed convention being held right next door. They got a security guard in front of their door while we did not.
Tanning Beds

The next 2 pics are of the lazy river. I did a couple of laps (assisted by the current) and it was very nice.
The Lazy River 1

The Lazy River 2

A fountain and one of the many pools.
Fountain at the Omni Resort

During the Matz Q&A my friend and fellow Obtivan Andy Maleh got up and asked some questions.
Andy Talks to Matz

A wonderful, awful idea: ruby in the browser (and oh by the way it actually works!) by Christopher Nelson

Chris thinks that while Javascript is an excellent programming language, he likes choices so why not provide people with the option to run Ruby in the browser? Also, while programming rich web apps he found that oftentimes he ended up with business objects in Javascript and in duplicate objects in Ruby. Not very DRY. He wanted to be able to use his Ruby logic server-side and in the browser.

Two ideas that didn't work out:
JRuby - the java security manager stopped him from doing just about anything
Silverlight wasn't available for his operating system when he started the project

Rubyjs is what he ended up using. Rubyjs is a ruby compiler that uses ParseTree to produce javascript.

The translation is, of course, not without some changes:
Strings become Immutable strings
Procs become Functions
Hashes becomes custom hash object

Chris then showed us a hangman game written in Ruby, then compiled to javascript. We peeked under the covers to look at the outputted Javascript and it's not very pretty. Neither is bytecode, I expect.

You can do Class level meta programming. You can even do method_missing (which resource intensive) in Rubyjs.

He wrote a rails plugin so you can do this in your views:
<%= rubyjs "my_class", "my_method" %>
The above line, when executed, will grab my_method out of my_class, turn it into a javascript file, write it out, and load the javascript file in the view. It's even smart enough to check last modified times to figure out if it needs to re-compile the method.

Microunit is his port of Miniunit so that he can test his rubyjs code.

Red is another Ruby to javascript compiler -- he didn't use it, but it's worth looking into. He thinks its source code is easier to read, but it lacks some features of Rubyjs (no class level meta programming or method_missing). Red does have a very active community.

The Ruby Code Review. A Play in One Act by Jim Weirich and Chris Nelson

So this was a dramatization of a meeting between a consultant and client. Chris played an employee of MyTwitterFaceSpaceBook, who has brought in a consultant, Jim, to do a code review.

So they run the tests:

Chris - "We run the new_features_test rake task"
rake new_features_test:


Jim explained the broken windows theory. Chris then explained that they've been having problems with their fixtures. They use fixtures to test validations by having invalid fixtures. Which leads to problems with other tests when invalid data blows things up.

Jim put valid_options (which returns a valid option hash) right on the model -- interesting. He says you can it somewhere else if you like. I would.

Jim recommends Continuous Integration like CC.rb. How do you cover the uncovered? Jim recommends doing it a little bit at a time. He comments out the whole untested method, then only uncomments enough to make the test pass.

While reviewing the code, they found some interesting metaprogramming -- If a user has a friend named Bob Jones, then that user gets a methods called bobjones, which returns the Bob Jones object. Awesome. Unfortunately there's a user named "Des Troy" that overwrites the Rails destroy method.

Chris and Jim had a great chemistry. Chris' "But dude, it's awesome 'cause it's metaprogramming" performance was funny and a little too real.

Seattle.rb Rocks! by Seattle Ruby Brigade

This presentation was sort of a lightning talk just for the Seattle Ruby brigade. Why do they get their own lightning talk session? 'Cause they have 90 unique gems and over 400 gem releases between them. You can check out their many projects at http://rubyforge.org/projects/seattlerb/

Eric Hodel UPnP

Eric wanted to watch movies on his Playstation three through his laptop or maybe it was the opposite -- he talked fast. So turning the PS3 into a media server? Or is the computer the media server? Anyway it looked cool.

JD Barnhart

Extended the Rad DSL to talk to the little circuit board that everyone loves: The Arduino. He made it do lots of stuff. Here's a video of it linked to some servos hitting wine glasses with tiny hammers:

Here's a cool LED tower controlled with resistive strips

(My buddy Josh Cronemeyer has also been messing around with the Arduino:

Phil Hagelberg Bus Scheme

What is Bus Scheme? It's Scheme implemented in Ruby while riding on the bus to work. I usually just listen to podcasts.

Ryan Davis
Confessions of a Ruby Sadist - the short version:

  • I like to hurt code
  • People will press charges if you hurt them
  • But code won't
  • Make your code your bitch

He's written a few projects that he uses to keep his code in line:
Autotest runs your tests behind the scenes while you code - you get notifications when you break stuff right away.

Heckle mutates your code and runs the tests again. Mutated code better not pass the tests.

Flog measures the complexity of your code.

Flay finds structural similarities in code that are ripe for DRYing up.

Aaron Patterson
He wrote Nokogiri - Which is basically a lot like Hpricot but faster. And then _why the lucky stiff heard about this speed boost and re-wrote Hprocot to be faster than Nokogiri:
Oh, it is ON.

What Every Rubyist Should Know About Threads by Jim Weirich

Concurrency is becoming bigger as computers get more cores. If you look at a graph of clock speed they flattened out in 2003.
Past performance gains:

  • clock speed (not so much anymore)
  • execution optimize
  • cache results

So if clock speed is not going up at a rapid pace anymore, now what?:
  • hyperthreading
  • multicore (the new saviour)
  • caching

Applications will need to be concurrent to exploit multicore machines. 100 CPU machines are on the horizon. Race conditions are trouble:

If thread one has this:
shared_variable += 1

And thread two wants to do the same thing:
shared_variable += 1

What if the first thread looks up the shared_variable and find that it's 25 but before it can change it the second thread reads the value (still 25 because it hasn't changed). Now the first thread will add one (shared_variable becomes 26) and write the result back to memory, then the second thread will add one to the stale number (25) and write 26 back to the shared memory. The output of those two threads running should have been 25 + 1 + 1 = 27 and yet the output was 26. Not good.

To fix this you need to disable context switching when touching a shared object and then re-enable it afterward:

m = Mutex.new
m.synchronize do
shared_variable += 1

Now all is well. However, this is trickier than it sounds -- if you have multiple objects interacting it's difficult to see where things must be synchronized. Also, you can get into situations where a circular relationship causes a deadlock:
1 waits on 2 waits on 3 waits on 1
Nothing can happen because threads are all waiting on each other.

To make your project thread-safe you must:
  1. Protect every shared memory access with a synchronize
  2. Be aware of extended situations
  3. Have a strategy in place for deadlock
  4. Evaluate every line in every library you use to make sure they follow the above steps

To sum up: Threading is hard.

Jim gently pointed out that if you really want to avoid race conditions you might want to use a language that was designed from the ground up to avoid these problems like Erlang, Clojure, or Haskell.

Using Metrics to Take a Hard Look at Your Code by Me

Good crowd. Everyone seemed pretty interested and there were a bunch of questions. I consider the talk a success. Except that I left my video adapter on the stage. And my laser pointer slide advancer thingy. What? I was nervous!

Ruby Kata and Sparring by Micah Martin

Micah used to be very serious bout martial arts and he thinks the becoming a good developer has some parallels with becoming a good martial arts practitioner. Micah's martial arts teacher didn't look very impressive, but he was a master. You'd be on the floor before you knew the fight had started. He got there through disciplined practice. To become a master coder you need to practice outside the office.

Kata - detailed choreographed patterns of movements. In matial arts you practice series of punches, kicks, blocks, etc.

Dave Thomas:

Uncle Bob:

What about performance? Every time you try for a belt you perform your Kata. This does three things:
The publicness of the performance motivates the student.
It's also a measurement of skill.
And it shows respect for your art.

Micah then performed a live coding kata for us. He has been practicing implementing Langston's Ant in Ruby. He bowed before starting and then cranked out some code TDD style.

Sparring is common in martial arts. In Ruby you have the Ruby quiz and the Rails Rumble. Micah announced another contest starting... Now!

The Battleship Tournament ends on Ends Nov 30, 2008. The challenge is to build a computer AI to play Battleship, but winning against other AI's is not everything. The winner will be determined by winning matches and the quality of the code as measure by various metrics. If you're interested check out these URL's:

After having a number of drinks at the Pivotal Labs party I finally made to the hotel's lazy river (which is sort of a simulated river that goes in a big circle). Drunkenly doing laps around some palm trees while resting in an inner tube is a good time.

Aristotle and the art of software development by Jonathan Dahl

How do you identify a good programmer? Jon says Ethics. Ethics is about how you live your entire life. He thinks the what makes a good software developer and what makes a good person have parallels in their answers.

Kant -- Only act on principles that you would like to become universal law. Kant would have loved Haskel.

There are principles in software, but sometimes they conflict such as DRY vs write understandable code. DRYing something up can make it hard to read.

John Stuart Mill
Utilitarianism -- what matters is the effect of the action. The ends justify the means. However, It's hard to know whether the effects will be good ahead of time. The Pragmatic Programmer is a good outcome of Utilitarianism. But Utilitarianism may lead to sloppy code and processes. Or the Cowboy coder.

Aristotle - ethics as virtue. The person is the important part. For Aristotle:
ethics == a life well lived == happiness == virtue

each virtue is between two extremes:
rashness > courage > cowardliness

Aristotle says that you become good by doing good. Which is kinda of circular. To become a good programmer, hang around the good and look at their code.

Jon thinks that Aristotle would like Ruby because Ruby is written for us as programmers. Haskel is based on math and Java is for business requirements but Ruby is for people. Also, to harken back to Matz's point from yesterday, Ruby is between two extremes:
Lisp > Ruby > BASIC

Fear of Programming by Nathaniel Talbott

A significant part of what we do as programmers is art. And we can learn from artists who aren't afraid to talk about their feelings. At this point

  • Fear is an emotion that effects our productivity.
  • Fear of a blank page and a blinking cursor.
  • Fear of existing code:
  • Legacy code that's hard to understand and work with.
  • Good code can inspire fear as you might mess it up.

Nathaniel then walked around the room, Oprah style, and had people volunteer things they are afraid of:
  • Fear of not finishing.
  • Fear of putting it into the wild.
  • Fear of loss of excitement about coding.
  • Fear that what you write will be useless.
  • Fear that someone has written it better before you and you just haven't found it.
  • Fear that my imagination outreaches my ability.

Fear is good as a warning mechanism, but pathetic as decision making tool. You can manage fear by learning. Much fear comes down to a fear of the unknown. Testing is an antidote to fear and it's a great way to break a problem down.

"The War of Art" and "Art and Fear" are two books Nathaniel recommends on this topic.

How do you, the audience, deal with fear:
  • Pair programming.
  • Talking it through to someone else.
  • Tackle the worst thing first.
  • Write fears down on paper.
  • Taking a walk.
  • Writing only the test cases.
He ended with the idea that passion and love are the ultimate antidotes to fear.

Better Hacking With Training Wheels by Joe Martinez

"We all have a stake in each other" -- we use each other's code in many, many libraries.

What automatically checks the quality of our code? Joe wants to encode rules in a standard way (called wheels) so that you could drop it into Training Wheels and it would enforce your rules on the code. People who write new libraries could include a wheels directory in their library which would offer suggestions.

Interesting idea -- on my current project we've be having problems with people calling destroy_all on an ActiveRecord class for no good reason. We could define a rule that shoots out a warning every time you do that.


NeverBlock, trivial non-blocking IO for Ruby by W. Idris Yasser

"Neverblock enables concurrent DB and network access without thew need to change the program flow" Which is awesome.

Idris said that the Evented model is good but you must adjust your code while Neverblock doesn't need any adjustments. So you can take your Rails code, require some files, swap out the mysql driver for the Neverblock one in the database.yml and you're done. If you use Thin that is. But still very cool

Neverblock uses Fibers (new in Ruby 1.9) which are normal methods that can be paused and resumed at will:

f = Fiber.new do
x = 5
Fiber.yield x
x = 6
Fiber.yield x
x = 7

puts f.resume #=> 5
puts f.resume #=> 6
puts f.resume #=> 7
puts f.resume #=> Error, dead fiber called

Fibers use less resources than Threads in Ruby.

Neverblock supports PostgreSqL and MySQL (with the MySQLPlus driver)

Neverblock also supports sockets.

Neverblock needs Rails 2.1, but not quite compatible with 2.2 yet.

Neverblock can work with Ruby 1.8 -- they implemented Fiber-like things using threads.

Lightning Talks:
A nice Japanese man got up to promote RubyKaigi (Ruby Conf in Japan). He said they'd like to have more non-Japanese speakers. It is happening July 17-19th 2009.

Duby -- Charles Nutter
Statically typed Ruby hybrid. For speed reasons? Yes, it is faster.

Rubists you might not know
A Japanese programmer got up and talked about two Rubyists we might not know. One was the release manager of Ruby 1.9 and the other was Itojun - the IPv6 samurai The presenter was quite upset when he talked about Itojun as he had passed away last year. By all accounts he was much loved.

Ryan Davis - Flay
Flay looks for structural similarity. It finds code that is duplicated. But since it uses ParseTree, to look at the code, it can find code that does the same thing but look different. Which is freakin' awesome. Use it to DRY up your code.

Ryan also wrote Change so you can change the class of a Ruby object on the fly. Which is evil and he admits that. In fact he revels in it.

David Chelimsky -- cucumber
Cucumber is a re-write of story runner. It now uses tree top which means stories can be in any language. Also the BDD with RSpec book is finally coming out. Beta in December, real book in April.

The Nature of Truth - Yossef Mendelssohn

truth in Ruby:
'this sentence is false
All of the above are true

Not true:

sudo gem install truthy
so now you can say:
and know the answer. Finally.

Conferences - are really fun
and make you stupid

Introducing Flunch the gem that tries to re-assign getters to setters and vice-versa. Cause... Um, it was fun. But it didn't work. However if you try stupid stuff like this you will learn a lot. I think that was the point.

Another testing thing. Seems to be a mix and match for various levels of Rspec, shoulda, rr, and other things so you can customize your tests to taste.

At this point my computer's battery finally gave out. It's about 10:21 and I'm going relax in my room for a bit before I go to sleep. My presentation is at 2:10 tomorrow.

Today was a long fun day.

I was thinking today that most people design their talk to last 50-55 minutes but I've noticed that conferences have shorter and shorter times slots. 40 minutes + 5 for questions is becoming the standard. So the end slides tend to go by pretty fast.

Another thought: Print the ID badge for the conference on both sides. Exactly the same information on both sides. Fully 50% of the people at Ruby Conf have their badges turned around to the white side and when I can't remember their names (even though we were just introduced) I can't cheat because all I see is a stupid white rectangle. Somehow GLSEC managed to figure this out, why can't other conferences?

JRuby: What, Why, How...Try It Now by Tom Enebo and Charlie Nutter

Why JRuby? Well the JVM is awesome. 15 quadriliion man years of work or something. 15 quadriliion Sun man years can't be wrong, right?

They have declared that Ruby 1.8 is "done" (again) and 1.9 mode can be triggered with a flag. Full 1.9 compatibility is coming.

Was it two years ago when I first saw them talk? Yeah, I think it was at the Rails Conf 2007. So about 1.5 years ago. JRuby was pretty impressive then and it has come a long way since.

Now that Rails 2.2 is thread safe you can really take advantage of that with JRuby. They showed a ridiculous graph comparing Rails 2.2 under load with MRI and JRuby. JRuby crushed the competition like a grape.

Btw: It's kind of amazing how many people here have the brand new Macbooks and Macbook Pros. Those things just came out, like what, a month ago?

Ruby In the Clouds by Jim Menard

Jim uses 10gen which is a different stack indeed:

Babble is the App server? Mongo is the DB? Javascript is server-side?

Whoa, I walked into this talk thinking it would be another putting your ruby/rails app on the EC2 cloud. This is a totally different direction.

Other Features on 10gen:
Multiple server-side programming languages including
* Python
* Ruby
* JavaScript

Multiple server environments including
* Standard 10gen

Multiple frameworks including
* Rails
* Django

Multiple deployment options including
* 10gen-provided hosting - deploy on 10gen managed infrastructure
* Run-your-own-cloud on your own infrastructure or hosting

The thing about this is that without ActiveRecord working, you'd have to code for 10gen from the start. Or face a very arduous conversion from ActiveRecord to their custom way of accessing the DB. Jim sez ActiveRecord support is coming soon.

The Big idea behind 10gen is that you could write your app and never have to worry about scaling it. Which is pretty cool.

MacRuby: Ruby for your Mac by Laurent Sansonetti

Everyone wants to develop Cocoa in Ruby. It can create awesome Mac apps. But you need to develop in Objective-C. Which is not so pretty. However, they both share some of the same concepts and ideas.

RubyCocoa exists, but it's a bridge. So conversion is happening and that is slow and resource intensive. And each runtime has a different garbage collector!

MacRuby interprets Ruby on the Objective-C runtime. Kinda like JRuby does with the JVM.

All objects in MacRuby inherit from NSObject.

HotCocoa is a thin Ruby layer on top of Cocoa. He showed some code and it really looked like Ruby. Slick desktops apps for the Mac written in Ruby are coming for Christmas (the projected "Production Ready" date of MacRuby).

From the audience: "What about iPhone apps?"
Laurent: (said in an outrageous French accent) "I'm sorry I can not answer this question"

Time for a break -- surely they'll have low-carb treats, right? Maybe just this once?

Woke up 15 seconds before my alarm went off again today. Perhaps I'm a little keyed up?

Keynote - Matz "Reasons behind Ruby"

Matz's presentation started out with the question: Why Ruby? He asked why even though Ruby has lots of problems, like all languages, why do we love it? Which is interesting. I've seen Matz talk a few time now and he always talks about the love of languages. The idea of loving what you do is never far from his mind. When Matz was young, his first computer was a pocket computer in 1980 -- only 1400 steps allowed. Only 150 memory places. And the Language was BASIC.

Later he found Lisp and it was the opposite of everything in Basic -- total freedom to do just about anything. And he loved it. That was, however, before he started using Lisp. When he started using Lisp in practice, he wasn't having a good time.

Basically Matz felt that Basic took all the power from him, but Lisp gave too much back. He wanted to have a framework to guide him, but also to have power when he needs it. Which lead to Ruby.

As always, Matz's talks are hard to sum up. You really have to experience one to know what happened.

Scaling Ruby (without the Rails) by Gregg Pollack

This talk was another one of Gregg's great survey talks where he picks a topic and then reviews all the cool things going on in that area. And his Keynote-Fu is strong. This time he was covering tips and trick to make your Ruby code faster.

In a situation where you have a bunch of threads, each will get a slice of time. But anytime Ruby drops into some C part then it blocks all the other threads because it doesn't know where it can pause the C stuff. Any IO operation is typically blocking. Making database calls is another common example of this. You can use Neverblock to have concurrent db calls.

If you have 4 CPUs and 4 threads you still only get 1 CPU. This is Green Threading and it really doesn't use all your processors to their fullest capacity. If you want use all 4 CPU, then you need 4 processes. Many Mongrels is an example of this. Most Rails apps typically run a whole pack of Mongrels to take advantage of multicore processors. Unfortunately, now you have a full stack duplicated a whole bunch of times and the memory waste is huge.

Native threads are cool and coming in 1.9, but are not concurrent due to Global Interpreter Lock. Of course you always go to JRuby (which runs on the JVM and has true native threads).

Event Machine - a fast single threaded application. It runs one thread at a time until it's done - this can be much faster (instead of each getting a slice of time). However slow requests can hold up fast requests. So Event Machine is best for fast requests. In Merb you can optimize certain requests to be deferred requests (if you know what's slow). Then you get the best of both worlds.

DBSlayer sits between the DB and your processes. You can add more DB's on the fly -- which is kinda wild.

Message Queuing with Starling. If the server dies it can recover -- nice. Very scalable as you can just add more workers.

Dropping into C -- Ruby Inline lets you drop into C inline in your Ruby code if you need close to the metal speed.

You can use Ruby-prof to profile your code like so:
RubyProf.profile do
# some code

You can print out fancy html output and even show call trees.

Speed up Tricks:
Method calls are slow:
"Hello " + @name + ", how are you?" vs
"Hello #{@name}, how are you?"
less calls == better
The first example is slower because of the two extra "+" calls

Destructive methods are faster than their non-destructive counterparts as they don't create a new object. So gsub is slower than gsub!

If you are doing case switching then you should put the most popular one first so the other, less popular, conditions are not evaluated.

Rails 2.2 has built in support for memoize so you can save the output of a method call and return that response the next time the method is called.

Gregg asked all bloggers to mention that Envycasts are available online (including this talk). So I hope you're happy now, Gregg.

Also you can go to RailsEnvy.com/rubyconf for the pdf of this presentation.

Simplifying Desktop Development with Glimmer by Andy Maleh

Andy wanted to create a multi-platform Ruby rich client application framework. His goals were to be concise and DRY, to only ask for the minimum info needed, and to value convention over configuration. He came up with Glimmer.

Glimmer uses Data Binding
The view and the model observe each other so that changes in one are automatically propagated to the other. Which is nice and effortless. An example he showed is where in the view he bound two different text fields to the same attribute on a model. Then when he typed in one field, the changes just showed up on the other. Without adding any additional code. This Blew My Mind as I am a guy who lives and breaths the web.

He showed the code behind the a simple TicTacToe game. It was concise and easy to read.


Glimmer will soon become an Eclipse project.

OK, off to lunch. Back at ya later in the day.

What a nice conference! Emphasis on nice. First Joel Adams, chair of Computer science at Calvin College, got up and welcomed us. Calvin College is where GLSEC was held and it looks so shiny and new I wondered if it had just been constructed. I stayed in a room the was about 200 feet from where I gave my talk.

Then the mayor of Grand Rapids, George Heartwell, gave us software dudes a nice little welcome speech. He implored us to see downtown Grand Rapids and then talked a lot about jobs and growth. I know Michigan has had hard times, but from the looks of the airport and Calvin College (which is about as scientific a survey as it gets) Grand Rapids must be a city on the grooooow.

The opening Keynote was given by Michael Cloran who is the the CEO of Interactions.

He started off with a live demo of the "Service Factory." He spoke, through his phone, to a computer and it parsed his voice and answered his questions. It was scary impressive. Typical line from the extended dialoge he had with the machine: "I have a flight at 5 or 6 today from altanta to London, oh wait I'm mean chicago to London I was in atlanta yesterday and I was wondering if you could tell me the gate and exact times" And then it nailed the response. Whoa.

Of course then he revealed that the secret behind the fabulous voice recognition was real human beings. He went on to explain that this is part of what he calls "The second service revolution." The First industrial revolution was about craftsman. The 2nd was assembly lines where each person did one thing. And thats the deal with his call center. Other call centers have employees who either know or look up all the answers. This takes lots of training -- which is bad new in an industry with high turnover. Cloran's company breaks up the calls and sends each person's response to a different "Intent Analyst." So an IA sits in front of a computer and gets a message on his or her headset along with some text on the screen describing the context. The IA then indicates to the computer what the person wants and the software does all the magic of providing the response while the IA is off listening to another snippet.

What's really interesting is that about 60% of calls are assigned to 2 different IA's, without their knowledge, and they get points if they both provide the same response. The one who gets there first is given double points. Their point average is directly linked to their hourly pay. Of course incentive pay inspires people to try and game the system so they've been constantly tweaking the system to eliminate "cheating." An example Michael provided was that there are common mistakes new employee's make so seasoned pros would quickly imitate those mistakes to get more points. They had to write algorithms to catch the cheating and penalize it with triple negative points. Reminds me of Joel Spolsky's classic "The Econ 101 Management Method"

Of course, as a start-up they made their fair share of mistakes. In the beginning they made a proof of concept demo and then when they got funding they just kept modifying it instead of re-writing some very sloppy code. This cost way more time than it saved. And they didn't write unit tests until the complexity threatened to overwhelm them. One of the biggest things he regrets is separating the QA and Dev teams. They thought that Sarbanes-Oxley demanded such a separation (later they found out it didn't) and this separation lead to lots of inefficiency, anger between the teams, and morale problems.

They also had IT problems. In traditional IT you can delay something as long as you want without much penalty. However, if you approve something that fails, you're in huge trouble. What incentive is there to do something fast? Need to analyze risk and reward, put it in front of the business, and then not freak out when trouble comes.

All in all, one of the most interesting keynotes I've heard in a long time.

"Encapsulated Process Objects" - Jeff Dalton

Jeff's deal is that he combines Agile and CMMI into one thing. Which is interesting because CMMI is usually associated with non-agile waterfall projects. Dalton stated that most devs see process as a ridged, audit-driven thing that demands slave-like adherence. But he doesn't. He sees CMMI as much more flexible than most people realize. His "Encapsulated Process Objects" are meant to be a smorgasbord of choices you can pick from when developing a project.

Unfortunately he went kinda fast and used a lot of terms I wasn't familar with. For example, when talking about "verification" in CMMI he mentioned that you could use either pair programming or Fagen inspections or test based design. Is Test based design the same as Test Driven Development? And what's a Fagen? (insert Dickens joke here) When fulfilling Feature Validation you could use "Use Cases," "Simulations," or "Prototypes." Uh, OK. Are use cases user stories? 'cause I've used those before.

So I felt kinda lost. But I did make a mental note to contact him if I'm ever in a place that demands CMMI so I can figure out how to wedge in Agile/XP

Here's a strange thing about GLSEC: I only saw about 10 other open laptops during the whole day. How do these people attend a session without a Macbook Pro to type on? The wifi was wide open!

"Taking the 'Pro' Out of 'Process': Test Process Improvement for Everyone" - Jess Lancasteru

This talk was about improving your QA team's processes. Jess started out by saying that test process improvement is hard because you don't know what to do, when to do it, or how to do that which you eventually decide to do.

Jess is a big fan of the Test Process Improvement Model (TPI) and recommends this book:
"Test Process Improvement: A step-by-step guide to structured testing"
as a way to assess and improve your testing processes.

I have to admit that during this talk I sat near a window, so as to be near a power outlet for my Mac Pro, and it was a beautiful fall Michigan day. 70 degrees, beautiful colors, trees waving gently in the wind. It was hard not to stare out the window. I may have missed some things.

Jess fessed up early to re-using an internal slide deck for this presentation and it showed. Some key terms weren't defined and the points on the slide sometimes seemed a bit off of what he was saying. If you are interested in using TPI, then he recommends an excel spreadsheet found here:
It helps you use TPI to score your testing process.

"The Art of Refactoring" - Kealy A. Opelt

Kealy started out her talk with a shout out to Martin Fowler and his seminal book "Refactoring". She defined refactoring thusly:
Refactoring improves design but does not add observable behavior.
And she cautioned that Refactoring is dangerous without unit tests.

Why refactor?

  • Improve design
  • Make code easier to understand
  • It helps you find bugs
  • It helps you program faster

The rest of the presentation was workshop style in that she would identify a code smell (say "Long Method") and then use one of the prescribed cures to make it better (like "Extract Method"). She even gave us real paper handouts on which we could practice with our neighbors -- I haven't done worksheets since my teaching days. Wait, do W2 forms count as worksheets? Or 1040 forms? Anyhoo, it was some old school fun.

Other examples were:
Feature envy -- when an object is interested in another object much more than itself. Solution: Move methods into the envied class.
Data clumps -- a bunch of variables that have to do with each other. Solution: Create a class to hold that data.

"Using Metrics to take a Hard Look at Your Code" - Me

The talk went OK. It's a presentation that shows a fair amount of Ruby code and the crowd had only a few Ruby users so that may have put a damper on things. Also they didn't really laugh at any of my jokes. But I soldiered on and I think a few people got some value out of it. A software development track at an XP/Agile conference is an interesting thing in that most people are going to be out of their element. Much as I was confused by the CMMI guy's jargon, my audience had to struggle with some unfamiliar terms in my talk. In a way, it's a good thing to be exposed to new ideas. But in another, much more real way, it can be a little depressing.

"Moving from 1.0 to 2.0: How We Brought an Application From Client-Specific to Generic and Marketable" - Sam Williamson

This talk was about how a startup made all the wrong decisions early on and yet managed to right the ship and get some working software into the wild. And then modify it to be generic enough to be sold to many different companies.

Sam is part of a small distributed team and he recommends: http://www.jingproject.com/ to make quick screencasts that can be viewed on the web. They used Jing daily during standup to show what they had been working on the day before. Sounds like his standup was a little more heavyweight than the ones I'm used to but that makes sense when everyone works in different cities.

Early on they had no source control, no tests, and no consistent way to build the project. After getting kicked around a bit, they added in tests, visual source safe, CruiseControl.net, and agile practices (they had to do remote pairing with screen sharing).

They had to interface with lots of different systems. From a shared drive on a mainframe, to a database, to an actual service. They wrote interfaces to wrap all of the services to minimize the coupling. Not only did it insulate them from changes in the third party systems, they could now go to other clients with different systems and all they had to write was a new bit of code that used the interface. Ha-Zaa for good design!

Last night when I got off my plane from Chicago, I realized that I would be in Grand Rapids for less than 24 hour so I could check in for my flight to Detroit (and then Orlando) before leaving the airport. What a jet-setter I am. I have to say that I always anticipated that being a jet-setter would be more glamourous.

"Agile is More than Just Makeup: Going the Distance with XP" - Michael Swieton

Practices matter. There's a tendency in crunch time to say "screw pairing, we need to go fast." but abandoning your practices during troubling times "is like turning off the light just when it gets dark" -- Ron Jeffries

This was pretty general talk about agile practices, testing, mocking, and dependency injection.

I'm kinda running out of steam here. It's 10:28pm and I'm in coach on my 3rd flight in the last 30 hours so while Swieton's talk was good, I'm giving it a bit of the bum's rush.

Jason Huggins - Final Keynote

There's a another keynote to discuss? Ah hell.

But seriously folks, Jason is the creator of Selenium (a web testing framework that is definitely not named after the cure for Mercury poisoning), a former colleague of mine at ThoughtWorks, a recent quitter of the Googleplex, and now trying to get together a start-up. His new venture is called "Sauce Labs" and is dedicated to putting web testing on the cloud. Instead of running 1000 click through your website tests in serial, he'll help you start up 1000 servers on EC2 to run crazy fast.

Jason's talk was mostly about how the transition from silent documentation (another name for a manual) to screen casts is similar to the transition between silent movies and the talkies in 1927. He talked about how David Hanson's Rails screencast in 2004 changed the game for documentation in software and we're only just beginning to realize the fallout. Huggins really digs Castanaut for automated screencast generation even if it does talk in a scary computer voice.

All in all, GLSEC was a good time and I'm glad I was able to attend. The hotel and conference staff were really nice and very helpful and so I'd like to thank them here. In a blog they will never read. OK, time to get some airplane sleep for tomorrow is Ruby Conf!

Flew in on election night for the Great Lakes Software Excellence Conference. I'll be giving my metrics talk tomorrow and then I'm off to Orlando, FL to give that talk at Ruby Conf. GLSEC is more of an XP/Agile/Process conference and I'm excited to be attending. The last time I was at a similar conference was XP/AU (Extreme Programming/Agile Universe) in 2004 when I was an apprentice at Object Mentor. I was just about to go back to my job as a high school physics teacher, but I did have an application in at ThoughtWorks. Ah, memories.