Functional Programming Considered Harmful? Nonsense!

Luke Plant recently wrote a blog entry on "Why learning Haskell/Python makes you a worse programmer". He rants about how difficult it is to write in a functional way in C# (and Java as well). And ends with this quote:

The moral of the story: don't bother improving yourself, unless you have the freedom to improve your environment accordingly. That's rather depressing. Can anyone put a better spin on this and cheer me up?

After reading this article, I was reminded of an argument to remove objects and blocks from Smalltalk. Basically, the argument of closures versus objects is futile. They both have their place and strengths in design. But, without closures, you can use simple objects as a substitute.

Luke's article argues how hard it is to instill functional programminging in languages like C# and Java. I think while it is hard to use pure functional style in these languages, it's matter of changing the way you think about it. I find since I don't have blocks/closures in Java, I use more of a stream approach (think pipe/filter pattern). It's a little trickier in the iterator objects, but the users of the code have to write less and their code is easier. I used this technique to good effect in my Reflective Testing Framework. As for side-effect free programming, I think it's a good goal to try to attain. We have a thing called encapsulation which can localize the effects of change. It's all in the way we think about it.

So, the next time, you see a road block because Java or C# doesn't have some feature from one of your favorite dynamic or functional languages. Think about the goal of the feature and ways you can attain it. Sure, code is more succint in Ruby, Python, Haskell, Scheme, and a host of other languages, but for those of us in the trenches, we might not be able to use them. We're stuck with Java/C#/C++. Be creative and remember to always keep your code easy to understand.

Ruby Quiz #6: Too Simple?

Matt Secoske and I were pairing last night and we decided to work on quiz #6 from the Ruby Quiz book. Here's our code complete with tests.

require 'test/unit'
require 'test/unit/ui/console/testrunner'

module Enumerable
  def in?(candidate)
    any? {|any| any.in? candidate}
  end
end


class Fixnum
  def in?(candidate)
    equal? candidate
  end
end


class Range
  def in?(candidate)
    include? candidate
  end
end


class BuildRegexp
  GUARD = /^[0123456789]+$/
  
  def initialize(candidates)
    @candidates = candidates
  end
  
  def =~(candidate)
    GUARD =~ candidate && (@candidates.in? candidate.to_i)
  end
end

class Regexp
  def self.build(*candidates)
    BuildRegexp.new(candidates)
  end
  
end


class BuildTest < Test::Unit::TestCase
  def test_lucky()
    lucky = Regexp.build(3,7)
    assert('7' =~ lucky)
    assert(!('13' =~ lucky))
    assert('3' =~ lucky)
  end
  
  def test_month()
    month = Regexp.build(1..12)
    assert(!('0' =~ month))
    assert('1' =~ month)
    assert('12' =~ month)
  end
  
  def test_day()
    day = Regexp.build(1..31)
    assert('6' =~ day)
    assert('16' =~ day)
    assert(!('Tues' =~ day))
  end
  
  def test_year()
    year = Regexp.build(98,99,2000..2005)
    assert(!('04' =~ year))
    assert('2004' =~ year)
    assert('98' =~ year)
  end
  
  def test_num()
    num = Regexp.build(0..1_000_000)
    assert(!('-1' =~ num))
  end
  
end

Test::Unit::UI::Console::TestRunner.new(BuildTest.suite()).start()

Of course, we excitedly looked up the answer in the book and were shocked. Their final answer was longer and harder to understand. Our code uses less of the regular expression class. In fact, we only used it as a guard to make sure we could convert the input to a number. We also made heavy use of polymorphism and duck typing(in?, =~). As you can see the code is very short.

The quiz was to build a Regexp to handle any list or range of numbers. The tests are taken exactly from the book and of course, we wrote them first. Well, actually, we wrote them at each stage. At one point, we were using Regexp extensively until we hit the last test. And that is when the change in requirements caused all of the code you see above.

How fun! We looked at each other and wondered, "Was our solution too simple?" We then laughed and said, "Nah." We were both proud for our simple and readable solution.

What Do You Value?

I keep coming back to a study that Steve McConnell mentions in Code Complete 2. The study was conducted by Gerald Weinberg and Edward Schulman to study the setting of quality objectives. The table below taken from the book always shocks me.

Objective To Maximize	Minimize Memory	Most Readable Output	Most Readable Code	Least Code	Minimize Programming Time
Minimum Memory	1	4	4	2	5
Output Readability	5	1	1	5	3
Program Readability	3	2	2	3	4
Least Code	2	5	3	1	3
Minimum Programming Time	4	3	5	4	1

Basically, it shows we achieve what we value. But, it also shows that the worst performer on the other metrics was "Minimize Programming Time" and the best overall is "Most Readable Code". I think we should always strive for readable code, but this study shows that the side effects are nice too.

I think sometimes XP shops can get too caught up in miniminizing programming time and thus, lose sight of the quality we should value most. We just need to be mindful and keep our code readable!

Behaving Poorly At Work

If you feel bad at work, go home. Feeling bad is no excuse to behave poorly. It's unprofessional and juvenile at best. OK, I'll get off my soap box now.

Matt's Ruby Log Splitter

Matt Secoske posted a Log Splitter on his blog. I thought it was a fun exercise, so I wrote my own as well. My version is different in that I made the work of splitting files into a class of its own that understands the same protocol of IO stream (or the parts that I need right now). All you do is simply create it like any another File object, except add a block that evaluates when the file should be split into a new one. The code at the bottom uses it. I tried to keep close to the input parameters of Matt's original code. Later on, I inspired him and he came up with a DSL version. Remember, I whipped this code up pretty quickly and I was having a bit of fun with Ruby. Enjoy!

class SplitFile
  def self.open(suffix, mode, &when_to_split)
    self.new(suffix, mode, when_to_split)
  end
  
  def write_all(enumerable)
    enumerable.each {|line| write(line) }
  end
  
  def write(line)
    open_next() if should_split?(line) || @file.nil?
    @file.write(line)
  end
  
  def close()
    @file.close() unless @file.nil?
    @file = nil
  end
  
  private
  def initialize(suffix, mode, when_to_split)
    @suffix = suffix
    @mode = mode
    @when_to_split = when_to_split
    @file_count = -1
  end
  
  def open_next()
    close()
    file_name = next_file_name()
    puts "Writing file #{file_name}"
    @file = File.open(file_name, @mode)
  end
  
  def next_file_name()
    @file_count += 1
    "#{@file_count}_#{@suffix}"
  end
  
  def should_split?(line)
    @when_to_split.call(line)
  end
end


FILE_SUFFIX = ARGV[0] ? ARGV[0] : "split.log"
MAX_LINES = ARGV[1] ? ARGV[1].to_i : 500000

lines = 0
split=SplitFile.open(FILE_SUFFIX, 'w') do |line|
  lines += 1
  result = lines >= MAX_LINES
  lines = 0 if result
  result
end

begin
  split.write_all($stdin)
ensure
  split.close
end

Python and XML in Omaha

It's time for another bodacious meeting of the Omaha Dynamic Language Group! This month we have a great presentation by Mike Hostetler on "Python and XML". Mike has a lot of passion for Python and he wants to show off one of the strong points of Python: XML. He will be taking us on a journey into the Python libraries. It should be a trip of elegance and simplicity. Come join us September 5 @ 7pm.

We do have a new location this month. Here's the details:
Creighton University
2500 California Plaza
Omaha, NE 68178

Parking
Additional Information:

Enter the west end of the Old Gym.

Go up the elevator to the fourth floor.
You're there.
Restrooms are on the 2nd floor, unfortunately.
Vending machines are on the 1st floor, around the wall to the right of the elevator.
Anyone asks, you are attending the Omaha Dynamic Users Group meeting on the fourth floor of the Old Gym or ODUG.

Think Good Thoughts

Saw this on a t-shirt:

Think Good Thoughts.
Words become actions,
Actions become habits,
Habits become character,
Character becomes destiny.

I love it!

Oh No! Let's Not Hurt Our Brains!

I couldn't believe this when I read it. It's an article arguing against closures in Java because they might be hard for some developers. I guess we should have never moved beyond ones and zeros either. Paradigm shifts always require us to look at things differently. I know I looked at the world differently after I learned Smalltalk or Lisp or Erlang or Haskell. Each of these languages pushed me into unfamiliar territory. Sure, it all looked alien and weird when I started with each one, but I soon learned.

To not do something because you are afraid of the average programmer is ludicrious. They never will become more than average if we don't push them. I'm sure object-oriented programming was scary at first for a lot of developers, but they learned. To not do a feature because it might confuse the "not-so-bright" developers is assuming too much. I'm reminded of a quote by Paul Graham:

"If you think you're designing something for idiots, odds are you're not designing something good, even for idiots."

If you don't know the power of closures, please go read "Structure and Interpretation of Computer Programs" right now! Don't worry...It's not only for smart people.

Pepsi through the nose hurts...

Need a good laugh? Read "How To Write Unmaintainable Code" right now! I've ran into a lot of the code he talks about and it's not only hard to maintain, but hard to refactor as well! An excellent anti-essay that will make you laugh, but also teach you what to avoid. Feel sorry for those that have to clean your mess at 3am in the morning.

Goodbye, Smalltalk

I'm having to say good-bye one more time to my favorite language. Oh, don't worry, I'm not leaving the community. I just will not be doing Smalltalk full-time at my job. I haven't been doing it for awhile anyway, but I occassionally walked over to the Smalltalk side of my shop and helped out on hard problems. my new gig will be 100% Java.

I'm looking to the future with excitement. RubyConf is going to be interesting to see how their community works. My experiences with the Ruby community have been positive, but it's been by all email. It will be cool to meet a lot of people in person. Of course, it will be cool to give a demo of Squeak or Dolphin to anyone that wants one.

The sad new is that I will probably not attend any of the Smalltalk conferences any time in the near future. Everyone will be missed! But, I will be out there trying to show Smalltalk to anyone curious (at RubyConf and beyond).

I will always love Smalltalk...

Generics not so bad

I've been working Java 5 the past 6 months and while there's a lot about generics that make me cringe, they are not that bad. "What?!", you exclaim. The 433 pages of FAQ outlining all of the fringe cases and the single variable names do make me want to pull my hair out. But, the 433 pages outline mostly things that you should never do anyway. I have found that generics make bad design and poor programming harder. This is a good thing. Generics become painful when you try to have lists of lists of lists of lists. It forces you though pain to refactor to objects.

I've also noticed that Hibernate forces you in the same ways. Everytime I do something complicated in Hibernate, I have found it's a pain. And everytime there was an easier and more elegant approach that would not only appease Hibernate, but make my design better.

Funk Card Ready, Mothership Taking Off

It's official. I resigned from my current position this week. I will be joining Union Pacific to do J2EE and some Jess. I'm excited about the team that I'm going to be a part of. I love playing with rules engines and this position is working closely with clients. Union Pacific is trying to solve some wicked hard problems and I think my brain is going to be stretched. Should be mad fun! I hope the team knows what they have gotten themselves into...=)

Amen Brother!

Small Teams Make Better Software is simply a great blog post. It hits the nail right on the head. I'm a firm believer in agile processes, but I'm becoming less and less enamored with XP. Anyway, it's a great article that is glowing about agile with the caveat that you must know the context to use it. Excellent stuff!

Diet Pepsi Jazz: Strawberries & Cream

The best soft drink ever made. I'm so much in love. It makes any bad day feel good. I wonder if they would let me be their spokesmodel....=)

Gross Code

Mike Bowler finds some gross code. Unfortunately, there's tons of examples in the JDK. My favorite has to be the Collections class in java.util. Why you ask? For example, the method sort(List) really should have been on the List interface. I also don't like the fact that it modifies the List and doesn't return a copy. I'm of the opinion that utility classes are usually a warning sign of lazy design. I understand that you do need them, but I try to hide their usage behind my objects. I never expose them.

Jerry Goldsmith

I just read that Jerry Goldsmith died of cancer at age 75 recently. Wow. As far as movie soundtracks, he's one of my favorites. He gave the world creepy music in "The Omen", futuristic pomp in "Logan's Run", tribal dissonance in "Planet of the Apes", and so much more. His music was inventive and fit the scenes perfectly. His music and legacy will live on in my heart.

Critical Communities

I was reading a blog entry on the Java and Ruby communities. It was interesting in the fact that the chose the Java community because of "critical" participants like the Bile Blog. It was argued that the Ruby community is too over-zealous and not critically introspective.

Well, I'd like to be brutally honest right now. Cursing and calling people "stupid" does not make a community. It discourages existing members and pushes potential new members away. I think being introspective and honest in your community is a must. I see this in spades in both the Ruby and Java communities. If you look long enough at the Ruby blogs, you will notice that we are all aware of the problems. Same goes for the Java community as well. But, what makes me love the Ruby community is the "roll up your sleeves and help" mentality. If you don't like something, work to make it better. I find this extremely positive. Now, I know this is in the Java community as well, but it's more pronounced in the Ruby community.

I find that the Bile Blog gives the Java community a black eye and it's one of the reasons why people are flocking to the Ruby community. It's more positive and not yet mired in endless negativity. I would be shocked if there was ever a Bile Blog for Ruby.

I like being apart of both communities. They both have things I love. But, I love the overwhelming positivity of Ruby. I think a lot of that comes from Matz.

Interesting Quote

"I always knew one day Smalltalk would replace Java. I just didn’t know it would be called Ruby."
-- Kent Beck

I got it from ozmmdotorg blog.

Shallow Knowledge

I'm rediscovering my "AI self" this week and came across this:

IF a person has a pink monkey
THEN take a refrigerator

It comes from the excellent book, "Expert Systems: Principles and Programming" by Giarratano and Riley. They use it as an example to make their point about shallow knowledge structure. It made me laugh because it's so silly, yet made their point perfectly clear. I love the book and it's one where you can pick it up and start reading at any point. A great book to read if you're interested in expert rule systems. Plus, they have funny examples that make you think.

Sepultura and Talladega Nights

We saw "Talladega Nights" on Friday and it was a hoot. But, I shocked in one of the final scenes when they used music from Sepultura's "Arise" album. I couldn't believe it. I'm an old school thrasher and underground metal lover. Back in the day, it would have been unheard of to hear something like Slayer or Metallica in a movie, yet alone Sepultura. It put a big smile on my face. I'm wondering if Will Farrell is a metal fan ("Master of Puppets" is played in a scene in another of his movies). Pretty cool to hear some of the music that I moshed to when I was young. Funny thing is that music still sounds great after all of these years.

My Wife: The quick pick me upper

Last week was a devestating for me personally. I put a lot of energy into something that just wasn't meant to be. It was one of those "if it doensn't kill you, it will make you stronger" moments. I've been hurting all week and my wife knew it. I didn't talk about it much, but I was distant.

So, what does she do? She gave me an empty journal with a mocked up cover of the book I want to write eventually. She knows my ambitions and the cover was gorgeous. It had a lot of funny quotes from various people about my book (of course, they were fake). But, it's exactly what I needed to lift my spirits.

She always knows exactly what to say to me to cheer me up. This gift touched me beyond words. It is the journal I will keep for my ideas on "Balance". She is the person that picks me up when I fall and tells me to push forward. This week has been a failure week and my new journal will be where I write my new successes.

I love my wife. She is the best. I wish everyone had a Michelle in their lives.

I'm reminded of two quotes that keep me going:
"Winners are losers who got up and gave it one more try."-Dennis DeYoung
"Good thoughts bear good fruit. Bullshit thoughts rot your meat."-George Clinton

More About Examples

I've been meaning to post some comments Joe left me:

Blaine,

I don't read your blog as often as I'd like, but whenever I do it gets me thinking.

I cut my teeth on the first edition of "Java in a Nutshell" and agree many of the code examples are horrible. For some unfathomable reason, most Java books make little or no attempt to teach OO concepts, choosing instead to focus on syntax and the API.

The problem with correcting code is that your corrections are open for correction :) In fixing the "baby sins" you've created, IMHO, a more egregious one. public methods with filname parameters is generally a Bad Idea as it allows a careless coder to corrupt any file of his choosing.

Well, but, I was trying to show a simple example. Wait a minute. I'm in the very quicksand that I complained about. Ouch. You are so right. I would generally have file access behind some kind of broker and then had the operations split out. Darn it! Maybe I should keep my mouth shut because it's hard to come up with succint yet correct examples.

You've also created some minor baby sins (embryo sins?) yourself. I believe redundancy does not necessarily lead to clarity. The repetitive "InCents" while well intended, gets downright annoying. I only need to be told once that we're dealing in cents. When you switch to another unit measure, let me know, otherwise it should be safe to assume nothing has changed. Make cents, er, sense? By renaming the method to addCentsToPurse, it pretty clear that cents is the order of the day.

Well, I usually have an object to represent money. Wait a minute. I'm down my rat hole again. DARN IT! You are exactly right. The "InCents" does get annoying. I usually put them in when I'm dealing with legacy code that deals in primitive. I don't like dealing with primitive types at all. Again, it's hard to come up with good examples. I should have done the right thing. I wrote the counter example in haste and committed sins in my rush.

Your constant and variable names are a little too "techie." I've lately come to understand that if code can be read by a non-coder, coders will be able to read it all the faster. seek(TOTAL_AMOUNT) is less technically accurate than seek(RECORD_POSITION) but it more clearly indicates what we expect to find at that location.

Another great suggestion and one that I fight with constantly. I do try to come up with good variable names, but I do fall into the techie trap a lot. Thank you for giving me more ammo to fight this battle in my head.

So, here's my version (hoping the format looks ok):

private static final String PURSE = "blah";
private static final String READ_AND_WRITE = "rw";
private static final int TOTAL_AMOUNT = 100;

public void addCentsToPurse(int cents) throws IOException {
RandomAccessFile purse = new RandomAccessFile(PURSE, READ_AND_WRITE);
try {
purse.seek(TOTAL_AMOUNT);
int centsInPurse = purse.readInt();
int total = centsInPurse + cents;
purse.seek(TOTAL_AMOUNT);
purse.writeInt(total);
} finally {
purse.close();
}
}

As a final note, I'm always tempted to combine multiple lines, as in:

purse.writeInt(centsInPurse + cents);

While this is a trivial example, it does help with debugging to use a new variable and multiple lines.

Jeff

WOW. Excellent code. I love these kinds of comments. It should a lot of faults in my code and I learned a lot. Great stuff. And we got a better example out of it to boot. Thanks, Jeff...You ROCK! I will work harder to make my code the best it can be and encourage everyone else to do the same thing.

My Boys!

Go check out Hematovore right now. These are the guys that I hung out with in college. Ah, the memories and this is their band. This stuff seriously rocks. You must go now if you like good rock music! They have a new CD out and I'm so proud of them.

Running

I took up running in the morning last winter and got hooked. I stopped in March because of allergies and a busy schedule. I just recently started again and I immediately noticed this time how much better I felt during the day. My attitude is more positive and I can think more clear. If I don't have my morning run, I can tell a huge difference. I think at this point, I will not quit again. It just feels too good. Plus, the amount of ideas that I'm having is incredible. I feel in charge and ready to take on the world. Why didn't I notice this difference the first time I quit? It's like night and day. Here's to feeling great and running!

Lisp In Omaha

Sam Tesla gave the whirlwind presentation on Lisp that left the group simply breathless. It was great. He went through all of the basics with wit, charm, and knowledge. I even forgave him for his quips on Scheme (which he knows that I love). He mainly stayed on the language and ventured a little bit into history (but, really that could be a two hour plus discussion in itself). All in all, if you missed it, shame on you! In the meantime, I'm going to work on Sam to do a sequel. Two hours is too short on such a cool subject.

The next meeting looks to be equally great: Python and XML by Mike Hostetler. See you all there!

Hard Week

This has been a hard week for me. It started out hopeful just to turn out worse than I ever expected. Oh well, life goes on. On to more positive pastures right? So, what better way to wash away the blues than color it RED! Yep, I'm going to RubyConf! This should be so much fun and I finally get to meet all of those cool Ruby enthusiasts! I can't wait.

I, Coder

Charles Nutter writes an eloquent blog entry "On Coding". I couldn't have said it better about what it means to be a coder.

Code is my religion.
Code is in my blood.
Elegance is not optional.

My heroes are all coders. I'm proud to be part of this journey with many others. So, Charles count me in as one of those with passion. I do this its strange that we are outcasts and people think us strange. But, I love being eccentric. And I love being around others that have the same passion. It's the reason I started all of the user groups and attend conferences. Ideas give me strength. Coding makes me feel alive.

As a side note, I love the term coder too. I hate the terms: "hacker", "geek", and "nerd". Coder to me symbolizes someone with passion about their craft. I can relate to that.

Re: Do We Have To Sacrifice Virgins?

Ben Bleything said:

Blaine-

I can't speak for Obie, of course, but I certainly don't feel the way you seem to think. I'm incredibly impressed by Seaside and Smalltalk in general. Avi is clearly a very smart guy doing very smart stuff.

I was IMing Obie during the talk, and said "it's probably just because I don't understand smalltalk, but this feels like total voodoo to me".
But I don't think voodoo is a bad thing. Voodoo is what gets me interested in something; I want to figure out how it works.

I don't feel like I'm in any position to comment on whether or not Seaside poses a "threat"... I don't even totally buy that there's a competition.

Perhaps I flew off the handle a bit. I think it's because I see so much synergy between the Ruby and Smalltalk communities. I consider myself to be both. I'm a dynamic language enthusiast (and President of the Omaha Chapter). Both technologies excite me and the communities ROCK! I just don't like to see bad blood or the appearance there of. Thank you for clarifying for me. I just want to keep the positive interaction to keep going.

Obie Fernandez posts more thoughts and clarified his meaning of "voodoo". I took the bad voodoo connotation because of the use of the word "heckling". I don't like it when technology I love does not get the respect it deserves. It seems Obie meant no disrespect.

It's all love, guys. I want both of us to be successful. And Ben, you are right. We are not in competition. I never meant to insinuate that at all.

"We're all stars. It's just your shine is different!"-Chocolate, Graham Central Station

Do We Have To Sacrifice Virgins?

Obie Fernandez (and Ben Bleything) had some thoughts on the Seaside presentation at OSCON:

Avi, on how to do maintenance and debugging on Seaside servers: "We can just vnc into the server. Squeak has vnc built into it."

Django Jacob, "Of course it does..."

I'm having fun in this session, sitting next to Ben Bleything, and trying not to contribute to the sporadic chuckling and heckling about the voodooo magic of Seaside. This is definitely one of the more enjoyable sessions I've attended so far, but I don't think Seaside poses serious competition to any of the major web frameworks.

I'm a little disappointed with this coming from Rails developers. I guess when you become the mainstream you can start thumbing your nose at non-mainstream technology. I see both Rails and Seaside as technologies to show how easy things can be. Sure, Seaside seems more like voodoo and the ideas "out there". But, the technology and ideas have been around for quite sometime. I guess I love being a part of the lunatic fringe. It's always more fun. I've enjoyed the meteoric rise of Rails, but I guess I thought Ruby enthusiasts would have more respect for what Seaside is doing. Or at least understand it. I wonder how many java developers still heckle and chuckle at Rails' voodoo? I didn't expect such comments from my dynamic brothers.

Don't worry guys, I still love you. There's space for both of us. You are always welcome at my table. I would never heckle you, only share my ideas and thoughts.

"First they ignore you, then they ridicule you, then they fight you, then you win."-Gandhi

Long methods

Yes, I do get allergic reactions when I see any method that I have to scroll. Small methods are the best, the smaller the better. That's all I have to say about that.

Code Pet Peeve

I've been unlucky lately. I keep running into coding pet peeves of mine. One of them is the following:

try {
  //something potentially dangerous
} catch(Exception ex) {
  ex.printStackTrace();
}

OK, you can probably guess I hate the variable name "ex" and that I also hate the catch all Exception (generally, always catch the lowest level exception class you're expecting). The most offensive and biggest peeve though is the "printStackTrace()" method call. The worst is that this is the default in the code templates that come with Eclipse! Its good when you're trying to get things working, but many developers leave it in all the way to production. I avoid it at all costs. If I care, I log it or throw a more domain specific wrapped exception. The problem is when you try to find the stack trace in the logs. Of course, you can redirect standard out and error to some log, but why bother? Do it right the first time through.

I always remember the pragmatic programmer's mantra: "Dead programs tell no tales". Think about your exception handling and never settle for the defaults. It's sloppy and you will pay the devil eventually.

August Omaha Dynamic Language Meeting

August brings us another great talk from none other than Sam Tesla. He will presenting us with the many wonders of Lisp. If you've ever been curious about the origin of dynamic languages, please come! See the lambda calculus come to life. Fun will be had by all. Be prepared to be delighted.

Please notice that we have changed locations. I got the meeting room at Panera Bread. Just tell them Blaine sent you. Cafe Gelato unfortunately closed. It will be missed! It's been our home from the beginning.

When	August 1, 2006, 7pm-9pm
Where	Panera Bread 13410 W Maple Rd Omaha, NE 68164 (402) 964-1110 We have reserved the backroom

Good Code and Examples

Why are so many examples in books so poor? For example, take this one from page 254 of "Java In A Nutshell" 5th edition:

//Open a file for read/write ("rw") access
RandomAccessFile f = new RandomAccessFile(datafile, "rw");
f.seek(100);   //Move to byte 100 of the file
byte[] data=new byte[100]; //Create a buffer to hold the data
f.read(data);   //Read 100 bytes from the file
int i = f.readInt();  //Read a 4-byte integer from the file
f.seek(100);   //Move back to byte 100
f.writeInt(i);   //Write the integer first
f.write(data);   //Then write the 100 bytes
f.close();   //Close the file when done with it

"What's so wrong with this?!", you ask. It's chock full of baby sins. It's important that beginners will copy the example and try it on their own. Sometimes this code is tweaked into production code. Just think someone at 3am is probably answering a pager because of a bad code example somehwhere in the universe. Why not take the opportunity as teachers to show off exemplery code?

So, what are the sins? Right off the bat, poor variable names. It should be an abomination to have single letter variable names. We're in the 21st century finally! Variable names don't take up much more space. Why not be intention revealing?

The next sin is that the example is not useful. It would be nice to have a small example of what a random access file is good for.

The magic values is the next killer. Why not make constants? Production code should never have magic values neither should your examples.

The final sin is the worst. No finally or any exception handling code on the file close. You need to always make sure you leave the file in a good state (i.e. not open). There's several ways to do that, but at least make sure your examples ensure they close themselves.

Here's how I would have done the same example:

private static final String READ_WRITE_ACCESS="rw";
private static final int TOTAL_RECORD_LOCATION=100;

public void addAmountToTotalAndSave(int amountInCents, String fileName) throws IOException {
 RandomAccessFile totalFile = new RandomAccessFile(fileName, READ_WRITE_ACCESS);
 try {
  //go to total record location
  totalFile.seek(TOTAL_RECORD_LOCATION);
  int previousTotalAmountInCents = totalFile.readInt();
  int newTotalAmountInCents = previousTotalAmountInCents + amountInCents;
  //reset position to total record location so that we can write new total
  totalFile.seek(TOTAL_RECORD_LOCATION);
  totalFile.writeInt(newTotalAmountInCents);
 } finally {
  totalFile.close();
 }
}

I could have broken this code out more, but I wanted something concise to show RandomAccessFile without much fluff. But, I also showed good coding practices. It's also a simple example that beginners could easily wrap their head around. Remember we are the teachers and it is our job to always show great code.

Animals And Colloboration

My wife and I have been enjoying going to the zoo during the member appreciation days. It's been fun to watch and talk with the zoo keepers as they are feeding the animals. Last wednesday, we watched them feed the elephants. The interesting thing was that we always noticed that they kept the elephants separated. Someone asked, "Why?" The answer was simple, yet surprising: The elephants didn't get along. This got me thinking. Isn't it funny that we expect people to just get along when we randomly throw them on a team?

I've always believed that teams should pick their members. The most successful teams I've been on have all liked and respected each other. Sometimes the universe did align and I got on a random team thrown together that everyone magically jelled. But, that's only happened twice. It's easier to find people that all get along in small teams because the more people the more conflict and communication there will be. It's important when interviewing people that they interact with everyone on the team. Technical skills can be taught, but if someone rubs you the wrong way, then they are better being on another team. I firmly believe that there's a team for everyone.

Colloboration is richer in smaller teams that respect and like each other. The synergy is incredible. I just find it funny that even in the wild, not all animals get along. But, in the corporate and business world, we expect people to be randomly slammed together and just get things done. It just doesn't happen. Why build the team morale when you an start out of the gate with one kick ass team?

Lady in the Water

We went to go see M. Night Shyamalan's "Lady in the Water" on my birthday. What a wonderful movie. I love all of Shyamalan's movies. He's the best film maker out there right now. We gets you so involved with the characters that the plot seems almost secondary. Every minute of it was enjoyable. I wish there were more movies made like Shyamalan makes them.

Email Fixed

If anyone has been trying to send email via my web interface, please try again now. My provider changed how I was receiving mail and it started to kick things back. But, everything is good now.

July Omaha Dynamic Languages Meeting

July brings many surprises. Unfortunately, I will not be able to present Seaside because I will be out of town. But, fret not, I will be presenting Seaside in October. Jeremy Sydik has been kind of to step in short notice to give an overview of his trip to RailsConf! It might be a little short, so I thought it might also be nice to swap code/tell stories. So, fire up those computers and bring in those cool snippets that you are proud of! Or bring up a cool story on how dyanmic languages helped the day! We can all learn new tricks. I will miss everyone!

When	July 11, 2006, 7pm-9pm
Where	Cafe Gelato 156th & Dodge 445-4460

Practices of an Agile Developer

I just finished reading "Practices of an Agile Developer". It's filled with tons of practical advice. I think it should have been called "Practices of a Good Developer. Period.", but I doesn't have the nice sexy ring to it. It's extremely short and they touch on the topics. It's great if you don't have a lot of time on your hands. I still recommend "Code Complete 2" for more coverage on good practices. But, I loved the "how to work with people" aspect of it which is unusual in technical books, but common in manager texts. The devil/angel quotes were cute and entertaining. It's certainly not a dull moment with lots of excellent analogies (common for the pragmatic programmer series). Anyway, I recommend it and it doesn't take long to read at all.

Back To Opera

I downloaded the lastest Opera today. I left Opera a year ago because Firefox held so much promise. Well, I liked the thoughts behind Firefox (Javascript coding with GreaseMonkey, Plug-ins, etc), but I have decided to return to Opera. It's faster. The interface is better planned and it just fits the way I browse the web. Oh, did I mention it was faster and doesn't hog the CPU at weird times? Opera is love. I am going to miss Sage though.

What A Compliment!

Brent Adkisson just started his blog and gave me a compliment. Perhaps one of the best that I've ever heard. It'll be one of those that I stash away for those rainy negative days.

If you know Blaine you have had a glimpse of one of the best coding minds I have ever had the pleasure to meet.

Wow! Brent is too kind. I don't think I would go that far...I'm still a journeyman in my mind. Brent is a great guy. Always laughing and smiling and never ceases to put me in a good mood. Oh, and did I mention, he's a kick ass coder as well?! I only keep the best company (so I always plenty of brains to learn from).

Iterable and for

I love the fact that there's a new interface in java.util: Iterable. Why you might ask? Could it be for the new shorthand for?

List someList = ... ;
for (SomethingCool each : someList) {
   ...
}

Well, that would be one reason to get excited. Close, but no cigar, no, I like the fact that the method iterator() has been split from java.util.Collection. It allows one to have infinite collections. Most of the time, you don't care how large the collection is, you just want to traverse over its elements. Iterable allows you to do just that. All you care about is that it can produce elements. This means if you have a large file, you could read it in chunks without anyone being the wiser. They would just have an Iterable object and not know how things worked in the back end. Encapsulation at its finest.

  String insanelyLargeFileName=...;
  RecordReader reader=RecordReader.on(insanelyLargeFileName);
  for (Record each : reader) {
    ...do something cool with each record...
  }
  class RecordReader implements Iterable {
    ...
  }

The client of RecordReader knows nothing about how many records are read in from the file at once nor should they care. They just want each record. We could for example read in 500 records in at a time or just one. It doesn't matter. We could even pass how many to read in at once as an argument to on. Throttling is left to us as a performance enhancement in one class.

Iterables allow us to have true object streams. How cool is that! For giggles, we could have also implemented it totally differently. This time I return an Iterable when asked instead of making the RecordReader implement it. I like this approach much better.

String insanelyLargeFileName=...;
  RecordReader reader=RecordReader.on(insanelyLargeFileName);
  for (Record each : reader.records()) {
    ...do something cool with each record...
  }
  class RecordReader{
    ...
    public Iterable records() {
      ...
    }
  }

The naive (or simplest) implementation of records() could simply return the entire collection of the file using an ArrayList. And when the file got too big, then move to a custom Iterable object that could read in chunks of the file. By putting iterator() into its own interface, we got a greater flexibility beyond the nice new for sugar. Polymorphism is a wonderful thing wouldn't you agree?

I use Iterables all over the place in my Reflective Testing Framework to traverse over classes, class path items, and methods. It allowed me to have a nice pipes and filters pattern throughout the code. It also made it easy for others to extend what I have done. Have fun! Iterable might be the best new feature of Java5.

Talk Went Great!

Matt Payne had great things to say about my talk:

"a Java 5 tour de force presentation that was backed up with a whole bunch of fantastic BSD licensed code"

WOW! You can't ask for a better compliment than that! Harish Keshwani had good things to say as well.

The thing that shocked me the most was how well my talk and Matt Secoske's on Performance fit so well together. We discussed our presentations before the meeting, but didn't plan on them being such a one-two punch! It was very cool.

I can't wait to expand the code that I have. ROCK!

Automated Standards Enforcement

In celebration of my talk tomorrow night, I have started a page on Automated Standards Enforcement. There's not a lot of content there yet. But, I plan on adding plenty of examples and more resources. Right now, I link to a bunch of books, articles, and my two frameworks. One is written for Squeak and the other Java 5. Both have source and tests available. I'm going to try to have the Java presentation up soon. My talk from Smalltalk Solutions is already there. Enjoy!

Right On

Mike Bowler said:

The majority of programmers fall into the non-expert category. They can see the differences between some of the less powerful languages like Visual Basic or Java™. They do not, however, understand how much more powerful some languages are.

You have to have a deeper understanding of languages to be able to compare them effectively. If you don't understand closures or continuations, for example, then you won't understand why languages that support them are more powerful than languages that don't. If you don't have a good grasp on the idea of self modifying code then you have no hope of understanding why lisp macros are so incredibly powerful.

Someone who only knows languages like Java™ or Visual Basic or C#, will not be able to appreciate why Smalltalk (or Ruby, or Lisp, or ...) is a more powerful language than what they already know.

Right on!

Four is The Perfect Team Size

The most successful teams that I have been have all been small. In fact, I've long believed that four was the perfect team size (three the minimum, and five the max). Of course, this was simply a gut instinct. It has been experience. I never thought to look up an research on the matter.

I was talking with my co-workers today and about fell over myself when one of the mentioned that the optiomal team size was three to five. I asked him why he felt this and he said, "Well, I found some research that says so." The look on my face must have been priceless. Eagerly, I asked him to give me the papers. He kindly told me to google "Optimal Team Size". I asked him what made him look it up and he replied, "I wanted to know the optimal group size for role playing games."

Here are the best articles that I found. Enjoy reading! All of it gave me lots of information to chew on.

The most telling quote was one by Steve McConnell. He not only advocates a small team, but relates what we've always known: code quality is dependent on the qaulity of the programmer. Methodology plays a little role in all of that. It's all about the people. Check it out:

According to Capers Jones's "Program Quality and Programmer Productivity" (IBM Technical Report TR 02.764, Jan. 1977), on small projects, construction errors make up about 75% of all errors found. Methodology has less predominance, and the biggest influence on program quality is the skill of the individual writing the program.

On typical larger projects, construction errors taper off to about 50% of total errors, while requirements and architecture errors make up the difference. Presumably, this is related to the fact that proportionately more time is spent in requirements development and architecture on large projects, so the opportunity for mistakes in those activities is proportionately larger.

I thought it was cool that there was research out there to prove my gut instincts.

Lead Vs. Follow

It is written that a great leader is not only good at leading, but following too. The same rule can be applied to coders. Sometimes you take the lead over a design when you feel the passion and other times you let someone else take the reigns. The important thing is not to feel the need to always be the one in charge. Let others lead.

Following does not mean to blindly go over the cliff, but to question and suggest. Realize that the person leading has the final decision. Without a clear leader, tug of wars result in code decay of the worst kind. Trust your team partner, but make sure your communication is clear when you disagree.

Too many times developers get into the mindset of always wanting to be the lead dog. Resist the urge. Learn to standback, do things differently, and most importantly grow and learn from doing a design differently. You will also gain the respect and admiration of your team. If you want people to support you, you must support them too.

When Is Too Complex, Too Complex?

This Java Generics FAQ is a whopping 433 pages in PDF form. Holy Moses! I went to print it out at work and was shocked by the size. The special cases are simply amazing. There's things that I hadn't even thought about it. It's comprehensive and well-written. 433 pages is a whole book on one small feature.

I've been using Java 5 at work and I must admit it makes developing proper frameworks possible, but it also complicates matters. It made my life as a framework developer nicer, but made the life of my user more difficult. Features should make my user's life easier, not mine. Simplicity is the key to good design.

Re: Cool Block Idea

Colin Putney was kind to inform me that #--> method from the previous is already implemented in Squeak! In Squeak, it's called #in:. So, the code before looks like this now:

((2 in: [:x| x * x ]) in: [:x| x + 5 ]) in: [:x| x sqrt ]

How cool is that?

Cool Block Idea

Howard Oh had the following suggestion on comp.lang.smalltalk.dolphin:

Block is one of the reasons that makes Smalltalk so lovable. But sometimes, block can make expressions very hard to read, because we human read parameter object first and then read inside the block just like Smalltalk runtime would do. This makes our reading cursor jump to right end and then back to left.

A guick example that can depict this point can be...

[:x| x sqrt ] value: ([:x| x + 5 ] value: ([:x| x * x ] value: 2))

An idea came up to me a few minutes ago,

Define a method for Object

Object>>--> aBlock

    ^aBlock value: self

This new method can transform the example expression to...

2 --> [:x| x * x ] --> [:x| x + 5 ] --> [:x| x sqrt ] 

What a cool idea! How I love messages and closures!

Why I Love The Smalltalk And Ruby Communities

This discussion on Lisp and its community is revealing. I've found comp.lang.lisp to be imitidating, not because of the hostility of some of the posters, but because everyone is so scary smart. It seems a lot of people have felt the wrath of impatient masters. The discussion shows a community taking a good long hard look at itself.

I remember not looking at PLT Scheme for years because of their poor behavior at Lightweight Langugages Conference Two. Matz gave a talk at the same conference and it's when Ruby won my heart. The community follows his lead. I have had nothing but great experiences in the Smalltalk and Ruby communities. I am thankful for that. The exchange of ideas and enthusiasm of people is contagious. I wish the same for the Lisp community.

I guess I'm shocked. I've always found Lisp folks to be helpful. The Lisp community has a lot going for it with two new books published last year. Renewed interest from a young audience is growing. I say forget the past and bury all hatchets. Start new. Lisp and Scheme are mad fun.

Upcoming Talks

I almost forgot to post about the talks that I'm giving in the near future. If you're in the Omaha area, please stop by. It's going to be a blast!

June 20,2006 - Reflective Testing In Java
Omaha Java User's Group
This is my talk from Smalltalk Solutions geared toward Java. The idea is the same, but the implementation is different. I will show how JUnit with other technologies can be used for contract enforcement and uncovering design smells. If you have any interest in meta/reflective systems or AspectJ, then this might be the talk for you. The presentation is itself written in Java5/AspectJ using the Eclipse/SWT APIs. Expect the unexpected! Learn how automation in testing can not only verify your code, but your designs as well! Stop code smells before they stink.

July 11, 2006 - Seaside
Omaha Dynamic Language User's Group
My infamous Seaside presentation updated for 2006! Same Smalltalk goodness, but with added more. I plan on adding topics for persistence and Seaside/Javascript integration. See the future of web development. Seaside is unapologetic in many of its stances and it makes for an extremely elegant framework. This is a great talk if you're curious about Smalltalk to see the power of the environment and language.

I hope to see everyone there at BOTH!

National Day Of Slayer

Yes, I will be observing National Day Of Slayer tomorrow. They are the band that got me started down the road to extreme music. Long live metal! I will be playing "Reign in Blood" and "South of Heaven" as loud as I possibly can.

A Dare

I have a simple dare. In fact, it's a triple dog dare to all developers. Are your ready? Here it is:

Stop using the same examples to show how great your favorite technology is.

Programming in general has "Hello, World" and every beginning programming book uses it. Even worse is the heavy use of "foo bar" in all its forms. Used to be cute, but not any more.

But, the worse by far is the fibonacci sequence used by every beginning functional programming article to prove the elegance of recursion or functional pattern matching. Come on. There are examples that prove it much better (pick anything in the real world). And that leads me to the final one...

ATMs are used as the example in almost every book in OO design. It's played to death and no longer interesting. Certainly, there's better examples than that out there now, right? And no, don't continue with the bowling example. It's already a cliche in all of the agile books.

Computer science is an exciting field filled with untapped potential and great ideas. But, cliched examples, while good for comparisons, fall flat in their simplicity. Fibonacci doesn't show the elegance obtained from functional programming. Much like showing that you can create a function to add one to prove the elegance of closures. I think a meatier example grounded in the real world will excite the reader much more. This is my dare. Dare to write an original example that makes me realize how clever you are and not @#$%^& ANOTHER FIBONACCI EXAMPLE?!

Code As Prose

Reading great code is like reading a great book. If you don't believe me, download Seaside or Dolphin Smalltalk. Of course, there's more examples than just that (Lisp 1.5 manual, Paul Graham's Lisp books, Structure and Interpretation of Computer Programs, etc), but I digress. You might now think I'm off my rocker and my brain is burnt from too much heavy metal music. But, I have a point to make.

There are simple rules to follow when writing: Outline your ideas; know your audience; and be concise. I'm sure there's more, but these are the three that I strive for. The funny thing is that these concepts correlate directly to code. Code is not merely communicating with the compiler and making things happen. If your software does anything of value or importance, it will be read by other people.

The act of design is the way we frame our ideas before we code. It allows us to plan out the high level view. It should not spell out everything, but give a blue print to how things will interface. It's the journey of thinking about the design that helps us. Code with a clear design is easier to maintain. Otherwise, it's a collection of incoherent thoughts glued together that might execute, but breaks often.

Writing your program for the computer is flat out wrong. In reality, the computer never really reads your code nor does it have to. It's the poor person awoken at three o'clock in the morning because a developer forgot to check for a null condition. It's the team interfacing their project on your library. In short, it's humans. We know this. Your audience is fellow developers. Take the extra time to name your variables well. Don't succumb to i,x,y, index, or each. Think about what business functionality you are implementing and write in that language. What if you had to give your code to someone non-technical? Could they understand what the code was doing? They should. Requirements live on in the program listing. Always strive for creating a domain specific language inside of your code.

Don't repeat yourself. I can't say it more simply. Don't be too clever and be concise. Prevent clutter from ruining the flow of a good program. Try to say the most with the least. It's good advice in art, writing, and programming.

There's probably more parallels that I could draw from, but I thought to keep this post simple. I enjoy reading books on good writing because I can try out new ideas for writing my code. I'm always asking myself how I could write something better for other developers to read. You can't learn from or maintain unreadable code. It's not hard to write well. It just takes practice. I'm amazed at how much code I read that is written for the computer. There's an over abundance of good code out there. The only way to become a great author is by reading great authors. Open source gives us a plethora of great code to admire and learn from. Get reading!

Is it all coming back to Smalltalk and Lisp?

Read Glenn Vanderberg's excellent article from "No Fluff, Just Stuff Anthology" now. He makes a strong case for Smalltalk, Lisp, Ruby and dynamic languages in general. The revolution is coming. Are you ready? Go get your squeak on!

Pair Programming: Is All The Time Too Much?

I work in an eXtreme Programming shop and we pair on ever single line of code. But, too much pairing can be bad. Some pairing partners, while excited initially to try something new, grow complacent after the honeymoon wears off. It's hard to keep them engaged. Pairing all the time stifles creativity because developers are simply uncomfortable taking risks in front of others (we are mostly introverted). It creates a strange group think atmosphere where pairs do what is comfortable and familiar. Few branch out and try new things. The ones that do, do it at home without the fear of failure in public. Sad but true.

Pairing on every single line of code is the path to broken windows. eXtreme programming enthusiasts scoff and grumble at this notion. Why? To ignore that developers are mainly introverts is fighting an uphill battle against human nature. The very thing that eXtreme enthusiasts claims that they embrace. Agility to me is about thinking to solve problems, not adding stifling processes or pithy mantras.

If pairing all the time is bad, is it alright to go back to our lonely cubes? NO! There is immense value in pair programming. In a good session, there's an unparalleled exchange of ideas and an unbeatable code review process. I find the good things happen if the pairing is not constant. Always pairing can be tiring mentally and physically. We all need time to recharge our batteries and reflect. Extended breaks can give us the spark of inspiration to solve that complex puzzle in our design that's been plaguing us.

The key is balance. Doing anything to the eXtreme risks team burn-out. Balance should really be the point of being agile. Take the advice of your mother. Everything in moderation is a good thing. Otherwise, you risk off going off the edge. Constant pairing erodes the benefits of it. Of course, the opposite is also true. The lonely coder can be a dangerous tumbleweed in your codebase.

My proposal is simple: Pair during design and creation of unit tests, not coding. This is where collaboration is a must and the most fun. A test-first approach helps a pair to design the domain language for business. It boils away all unnecessary abstractions and allows the pair to get to the heart of the problem. It becomes the design while providing the harness to verify its validity. Pairs challenge each other to write tests that express the business the most succintly.

Allow pairs to break apart to write the code that satisfies the tests that they write together. This allows personal time for reflection and to try out new ideas. It gives the much needed time to reflect and the exhilaration of collaboration. The pair should come back together after the code is complete and review what each other has done. A refactoring of each other's code is good at this point. Allowing the sharing of information without one pair becoming disenfranchised with a dominant other. Of course, if pairs feel the need to discuss issues as they come up in the code, they should. Remember, it's all about balance!

I have seen first hand the pitfalls of pairing too much. The code and design eventually suffer. Spaghetti ensues and no one wants to work on the brittle system. Quality slips and the team descends into finger pointing and negativity. Pairing only amplifies the problem because developers have no way to get away and heal their wounds. Everyone needs some time alone. But, we also need interaction to stay fully engaged. Everything to the eXtreme is bad. Balance is the order of the day. I will not offer any cute quotes or clever acronyms, just simple advice.

If you're thinking of trying out pairing or are just a burnt out XPer, try out my advice. It offers the best of both worlds. It's a meeting in the middle and is good to try out a new way of working together. You can have your cake and eat it too. Just don't eat only cake. You need your vegetables too.

More Info On Rails Presentation

Matt Secoske has posted some details of his talk on Rails, June 6, in Omaha.

Rails Is Coming To Omaha

June 6. Be There. Matt Secoske will be giving the Rails presentation that will leave everyone breathless. If you live in Omaha, you do not want to miss this. The Ruby onslaught is coming. Grab the nearest closure and hold on for dear life! Extreme productivity might just run over you.

The location for the Omaha Dynamic Language User Group has changed for just this presentation. Attendance expected to me in the millions. Come early with your appetite for technological wonders.

See everyone there!

Eclipse Thesaurus Plug-In

I have a new version (1.01) of my Thesaurus Eclipse Plug-In. I basically had a bout of inspiration while I was researching SWT. It now has back and forward buttons. I added the ability to get more entries without scrolling down the page. There's quite a few bug fixes too.

The source is included. The model has been tightened up. I moved responsibilities to where they should have been in the front place. Hind sight is a wonderful thing. I'm still having fun with SWT and amazed that it does exactly what you tell it to. It's a nice framework to deal with. It all makes sense and looks wonderful!

Devil Horns

I have a confession. Metal did not originate the devil horns hand thingy. I have a second confession. I don't know who did. I have a third confession. The same hand gesture is used at P-Funk shows and has been like that for years. Ronnie James Dio is attributed as the originator in metal circles, but I think P-Funk has been using the symbol for years before him.

It's funny how similar early funk and metal truly are. Both are extensions to a group of people disenfranchised by the establishment. Funk in my book will always be a more organic, yet still loud form of rock'n'roll. Same thing with metal. It's just funny that two of my favorite forms of music use the same symbol to show respect.

I'm sorry I just had to post on this topic. I couldn't be quiet any longer. It's just not right for metal to take all of the glory and not acknowledge our alter egos in the funk world. I hope everyone understands. I got to go put on a "Motor Booty Affair" followed by "Holy Diver"! Funk and Metal on!

Back on Planet Statika

At work, I've been doing Java work again. It's weird going from Smalltalk to Java to Smalltalk and now back to Java. I've kept up to speed on my Java skills, so it's not like I'm starting from ground zero. We've been using Java5 and the generics are not as bad as I thought. They are actually quite handy to catch those pesky cast problems. But, they can get hairy if you don't have a proper object model.

Java is a different way of thought and there's advantages and disadvantages. The advantages are the sheer number of frameworks to pick from. It can be overwhelming. We decided to go with simply Hibernate/Tomcat/Axis for a simple SOAP web service. It's strange going back to a compile/wait cycle, but it's not bad. As for the disadvantages, it's a lot of configuration files with awful error messages if you happen to miss type your class name.

It's an interesting journey. I'm curious as to how Groovy makes the Java experience easier since it gives me my beloved "cheap" closures. It integrates tightly with Java (similiar syntax) and accepts the fact you are running on the JVM. Hopefully, I'll get a chance to try it out on a small piece.

Don't worry I still love Dynamica and will travel there in the evenings to dream. I will never give up my Smalltalk, Lisp, or Ruby, my brothers!

Positive

Just to a note to anyone that sees me being negative. Quickly remind me to:

Stop Complaining and take action. Return to positive form.

I've been trying to be a lot more positive these days. I was stressed at Smalltalk Solutions (not the conference, but other things in my life) and it showed. I took action when I came back and I've been in the best mood. My new mantra is to take action whenever something is making me unhappy and negative. Work toward eliminating the negative situation.

I quit smoking. I quit over-eating. I can quit being negative too.

Rock on!

The Power of Blocks in DSLs

Charles Nutter has a great blog entry on a Bytecode DSL written in JRuby. If you look closely at the code, he's making great use of Ruby's blocks. It makes the code succint and powerful. Oh yeah, it's fun, too! The example could be done in any dynamic language with closures (Groovy for example).

I'm loving the examples of DSLs coming out of the Ruby community right now. They show off the expressive power of method_missing and blocks (or doesNotUnderstand: in Smalltalk). There's a lot of power in those two simple features that allow you to express higher level concepts easily.

My First Eclipse Plug-In

I got my first Eclipse plug-in working! I'm so excited! It works in Eclipse 3.1, Windows XP, and Java 1.5. I'm so proud of myself. It was a lot of fun to program. You might ask yourself, what is it? Well, it's a Thesaurus that accesses www.thesaurus.com and reformats the output to make all words clickable. It still needs more work like keyboard shortcuts, the ability to click on a word in the editors, and back/forward buttons.

SWT was a complete pleasure. It's an elegant design and far better than Swing (I could write a book about all of the bad design decisions in it). So now, I have one of my favorite tools in Eclipse as well. ROCK! My next project is the ability to give presentations in Eclipse. I'm thinking Groovy might be the perfect vehicle.

What I Love About The Ruby Community

Chris Petrilli writes about one of the things that I love about the Ruby community:

Spiffy. In some ways they’re juts rediscovering what the Smalltalk world has had for a long time, but there’s a lot of new stuff happening too, and the “spirit” of the community is what attracts me. There is a certain unwillingness to accept wrote answers and look for new solutions. They also seem, unlike so many others, to not have forgotten where so many of the ideas come from.

The youthfulness and excitement of the Ruby community attracted me to the language even before Rails. It was the knowing your past, but looking at the future that got me. I love it. It makes me look past a few shortcomings in the language (like & and that blocks are not first class objects). But, it's going to be a fun journey with so many passionate people.

Learning To Like iTunes

When I won my iShuffle last year, I was very angry with Apple after installing iTunes. It installed itself itself between my computer and the CD-ROM (which I found out when I uninstalled it and my CD-ROM disappeared). And let's not forget that it tried to rearrange my existing MP3s after I told it NOT to. It was a frustrating experience and it cooled my desire for a Mac real fast. So, I uninstalled it; set my computer back to its initial before-iTunes state; and downloaded a Python script to add MP3s to my iShuffle. I love my iShuffle.

Fast forward another year and I have won another Apple product: the Nano iPod. I have talked to several people who think of me as crazy for my rants against iTunes. They told me that iTunes is wonderful and what is my problem? Well, I told them that I hate the "by song" view. I listen to albums gosh darn it! They assured me that they too have big collections and iTunes is awesome. Maybe I'm missing something here, no? I install it; try in earnest to use it; and go as far as to download Podcasts.

To cut a long story short, I've spent the weekend with iTunes. I learned how to get around what I thought were deficiencies. The path to liking iTunes is underway. My real complaints were really that it was a different way to work on my MP3s. It's already forcing me to tag all of my MP3s in my iRiver so that they can be easily imported into iTunes. I even learned how to sync both of my iPods.

My lust for a Mac is increasing.

Cool Pictures

Adriaan van Os has posted some great pictures of Smalltalk Solutions 2006. I especially liked this one:

Hold on one minute while I channel the gods of Smalltalk past
I never thought I looked silly but, this proves it! The pictures are fabulous. They are pure fun!

Smalltalk Solutions 2006

I've been spending most of the day recovering from the massive idea exchanges at Smalltalk Solutions 2006. I had so much fun talking with everyone. I'm starting to feel comfortable giving presentations and I think it shows. As given by this review by James Robertson:

Blaine gave a good talk. He was funny, self deprecating, and well prepared.

If he only knew how many times I practiced and the amount of time I used for research. I'm glad it showed. I enjoyed giving it and I can't wait to unleash it on Java and Ruby crowds! So, what were my favorite presentations? Bar none, it had to be Brian Foote's keynote and Lukas Renggli's talk on Pier. But, I must admit I got private sessions where Colin Putney showed his design for Monticello2 (WOW). Andres's thoughts on the coding contest, and Hans-Martin Mosner showed me some "Behavior" magic. I will soon be taking over the universe with the information given to me.

I learned so much during the conference. Everyone I talked to gave me fresh perspectives on a wide range of topics. I'm still busy writing in my journal all of the great conversations I had. I can't decide if my brain is hurting from caffeine withdrawal or all of the possibilities. I think it's the latter.

My only real complaint is that we didn't have a space to have a Camp Smalltalk. I would have loved to paired with some folks. Maybe next year, we can find a spot in one of the coffee shops and take it over.

I can't wait till next year!

Number Two In The World!

I became the number two Smalltalker in the world this past week. It feels great. The coding contest this year was so much fun. Michael Lucas-Smith came up with such a great puzzle to solve. I loved every minute of it. I used Dolphin 6 for my player and it was an absolute pleasure to program in. My brain hurts.

My great friend, Andres Valloud is number one and for good reason. I knew I was beat when we compared designs after the contest. Andres's design was just gorgeous I hope he blogs about it. I learn so much from him. I wish he would blog more about what goes on inside of his head. It's refreshing how he thinks and he's the type of person that makes you push yourself harder to do better work (or shall I say art?).

Great design won the contest. I hope Andres blogs about his design and decisions in the contest. It would be a lot of fun to read.

We're talking about doing the coding contest next year and we're batting around a lot of ideas. Now, we'll get to think about the contest from the reverse direction. I'm excited about working with him on that.

Smalltalk Solutions Cometh

I'm leaving for Toronto tomorrow to attend Smalltalk Solutions. I'm so excited! I will be presenting as well as you all know. Nervous doesn't even being to describe my anxiety. Let's hope I don't get booed off the stage when I present "Controlling Pain: Augmenting Unit Testing". I've been practicing to reduce my twitches and it should be an incredible experience. To give everyone an extra incentive to show up, my talk is all in Squeak (No PowerPoint here, buddy).

After Smalltalk Solutions, I will be focusing on presenting the talk in Java and Ruby versions. I'm dubbing it "Reflective Testing" and it should make for more fun presentations!

I can't wait to see everyone! See you guys at the pub tomorrow night!

May Omaha Dynamic User's Group

April showers bring May flowers or shall I say another awesome Dynamic Language User Group Meeting. This month we are honoured to have Scott Hickey presenting Groovy. His presentation will cover an overview of the language highlighting Groovy's dynamic programming features. He will also show some common Java programming idioms and show how we can replace Java with Groovy to make our application code more readable. I simply can't wait! As always bring everyone you can.

When	May 2, 2006, 7pm-9pm
Where	Cafe Gelato 156th & Dodge 445-4460

Playing With Procs And Objects

One of the things that I love about Ruby is the ability to treat methods and blocks as the same:

def square(number)
  number * number
end
method = method(:square)
block = lambda {|number| number*number}
numbers = [1, 2, 3]

#prepare to get the same answer
p numbers.collect(&method)
#result: [1, 4, 9]
p numbers.collect(&block)
#result: [1, 4, 9]

At first glance, you might think this happens because of method and block having a common method in :call. But, you would be wrong. Try this code and watch it fail:

#This fails
class Symbol
  def call(*all)
    method(self).call(*all)
  end
end
p numbers.collect(&:square)
#result: ERROR!

Well, the first clue is the weird "&" in front in all calls. This converts a Proc object to a block to be passed into the call. The interpreter expects an object to be a Proc after the "&" or it complains you didn't give it one. What are we to do? Well, thankfully, the interpreter tries to do the conversion by calling :to_proc. Let's try it:

class Symbol
  def to_proc
    method(self).to_proc
  end
  
end
p numbers.collect(&:square)
#result: [1, 4, 9]

This works like a charm! Now, by simply implementing :to_proc we can use any object to a call that expects block.

class MyComplicatedCalculation
  #lots of instance variables..too heavy for a mere Proc
  def to_proc
    #calculations that could end world hunger go here
    #For now, simply return a simple answer
    lambda { | number | 42 }
  end
end

p numbers.collect(&MyComplicatedCalculation.new)
#result: [42, 42, 42]

I do wish Ruby just allowed me to implement :call and be done with it, but implementing :to_proc isn't much more work. Have fun!

Moved

I moved my blog to a bright new location and you can access the feed right here. It's been a long time coming. If anyone runs into any problems, let me know!

Nintendo and Casual Gamers

James Robertson talks about the market that Nintendo is after and it's the causal gamer. I must admit they get all of my gaming money (which isn't much). I'm probably what they consider a casual gamer. I don't play that much and when I do it's just to have some mad fun to clear the mind. Nintendo has the best "fun" games. Bar none, my favorite games ever are the Mario and Donkey Kong off-shoots (Donkey Kong Country, Mario Kart, Mario Bros, Wario, Yoshi, etc). Plus, I like carrying my games with me. The PSP peeked my interest when it came out, but I really don't enjoy racing real cars, shooting people, or robbing people. I want escape. Nintendo gives me that and fun in spades. Besides, the DS touch screen and on-line play is awesome. I dare anyone not to get addicted to Mario Kart.

Mini-Fight

From Blabbermouth comes this funny bit of news about MiniKiss vs. TinyKiss. It does't get much stranger:

Robert W. Welkos of the Los Angeles Times is reporting that Joey Fatale, the 4-foot, 4-inch New Yorker who heads the all-dwarf KISS tribute band MINIKISS, is denying published reports that he tried to sneak past security last month at the Hard Rock Hotel and Casino in Las Vegas to confront a rival band leader, 4-foot "Little" Tim Loomis of TINY KISS, for allegedly ripping off his idea for such a group.

Loomis, a former drummer for MINIKISS, was performing with TINY KISS, which includes three little people and a 350-pound woman, on St. Patrick's Day at Beacher's Madhouse, a Las Vegas variety show, when the incident occurred.

Show host Jeff Beacher told The Times on Monday that Fatale "tried to sneak in saying he was TINY KISS" and had to be escorted from the premises. According to the New York Post, Fatale's lawyers sent a legal cease-and-desist letter to the show trying to shut down the act.

Loomis told the Post: "[Fatale] came out here [to Las Vegas] and tried to cause trouble, so I had him 86'd from the Hard Rock. The impression I got was that he was looking for a fight. He'd been threatening me over the phone."

But Fatale disputed the accusation, telling The Times: "This whole thing about me going to the Hard Rock with my gang — that didn't happen. What happened was, I went there because somebody told me [TINY KISS was] doing the show that night…. Nobody escorted me out of there. I went there by myself to approach them as a gentleman."

Fatale says he has "nothing to say" about Loomis, except, "He's a nice guy." And, he added, "This is all a big publicity act for the guy at Beacher's."

Revisiting Old Code And Private

I've been looking through old code as of late and well, it's...it's...EMBARASSING! There I said it. Does anyone else do this? I was looking at my Thesaurus project (my Squeak version and soon-to-be Java version) and was appalled at a lot of the code. So, I spent sometime refactoring and getting the code back into shape. My Thesaurus project in Squeak was a quick excursion into writing Morphs and that code was fine. What made me crinch was my parsing code! For one thing, I put all of the code for parsing into one class. It was doing all sorts of stuff with the HTML elements that it had no business doing. The first order of business was to move all of the low-level HTML traversal code into a new class. This made the parser much more readable and took away the noise inside of it. The next order of business was the actual traversal code. I made some huge blunders in my implementation of the depth-first/breadth-first algorithm. I knew the first problem was when I couldn't even understand what I was doing!

Here's the original code:

elementsIn: anElement do: aOneArgBlock depthFirst: aBoolean
 | left children |
 left := OrderedCollection with: anElement.
 [left isEmpty]
  whileFalse: 
   [| next |
    next := aBoolean ifTrue: [left removeLast] ifFalse: [left removeFirst].
   (aOneArgBlock value: next) == false
    ifFalse: [children := OrderedCollection new.
       next elementsDo: [:each | aBoolean ifTrue: [children addFirst: each] ifFalse: [children addLast: each]].
       left addAll: children]]

YUCK! What was I thinking with two checks for depthFirst or not? Here's the new code (which is a new class by the way!):

pvtDo: doBlock depthFirst: isDepthFirst 
 | searchQueue dyadic |
 dyadic := self pvtCurryForContinue: doBlock.
 searchQueue := OrderedCollection withAll: self pvtChildren.
 [searchQueue isEmpty] whileFalse: 
   [| next continue |
   next := self class on: searchQueue removeFirst.
   continue := [next addChildrenTo: searchQueue depthFirst: isDepthFirst].
   dyadic value: next value: continue]

Now, you might notice some weirdness like the #pvtCurryForContinue:. All it does is to call the continue block by default if the block only accepts one argument. Otherwise, it let's the block continue through. Here's it's implementation:

pvtCurryForContinue: doBlock 
 ^doBlock numArgs == 1 
  ifTrue: 
   [[:each :continue | 
   doBlock value: each.
   continue value]]
  ifFalse: [doBlock]

This is my functional programming training shining through. This code is much cleaner and easier to read than the one before.

This was just one simple example. I used the Thesaurus project to refactor to see how enforcing private members in Smalltalk would feel. So far, I found a lot of breaches of encapsulation that I had not noticed in the heat of development. Even with categorizing methods as private and with comments, I still broke the boundaries. The pvt at the beginning makes it obvious and Squeak's compiler tells me immediately when I have done something wrong.

After the refactoring, I felt my design was much cleaner overall. So far, I'm enjoying using pvt at the beginning of my private methods. It makes me get into the habit of "telling" my objects instead of "asking" which I generally do well. But, it helps when I'm weak in the rush to get something done or simply not as focused as I should be. The public protocol is obvious and minimal. Plus, if I have too many pvt methods, I start looking through my methods to break the object down further.

Omaha Dynamic User's Group

It's time for the most exciting user's group in Omaha to have another explosive meeting! Brent Adkisson will be blessing us again with another of his great presentations. This time he will be presenting Advanced Javascript and AJAX. If you've ever wondered how to get your mind around Javascript, Brent is going to show you! It's guaranteed to expose features of Javascript that you might not have known existed. I hope to see everyone there!

When	April 4, 2006, 7pm-9pm
Where	Cafe Gelato 156th & Dodge 445-4460

Re: Block Thoughts

Alan Knight posted about More Block Thoughts. He made some excellent points. I particularly loved adding the #collecting:, #selecting, etc protocols on streams.

The funny thing is that the method that I used as an example was part of a larger object that actually was a stream. The stream, named WordStream, wrapped a character stream and returned a Word object on each invocation of #next. Alan mentions that my Word object is "a little bit messier" than strings. And in the context of the single method, I think he is right. But, in the larger context it makes sense. The Word object has a protocol to answer things about the itself like "am I common (the,a,is)?" for example. It's just not a simple wrapper around a String. It's much more.

I love Alan's views on streams, I'm a fan of pipe-filter designs for transformation. The WordStream was simply being fed a character stream to get more meaningful objects out. The users of WordStream only needed to know that it gave them Word objects via the stream protocol. I hate dealing with primitives and the minute I can transform something into a tangible domain object the better.

I feel like I should have given a more thorough example and not one out of context. It would have made the design decision a little more clear. And I could have shown off an example of the pipe-filter pattern. But, I was too thrilled with my new use for blocks.

Thoughts on James McGovern

Everyone else has posted their opinions on James McGovern's Thoughts on Ruby and the Enterprise. I figured, "what the hell? Why not post mine too". James McGovern lists some problems for the Ruby community to address, but stumbles from the mistakes. So, I'll start out with a nice quote:

Many folks haven't figured out that I too am a fan of Ruby.

OK, I can buy this, but when it comes to the list, he makes these mistakes:

Does anyone agree that the notion of packages / namespaces should be a part of every modern language?

Ruby has these things called Modules that fullfill that role.

I also couldn't find the equivalent of instance variables. Wouldn't that make reuse at an enterprise-level somewhat problematic?

Uh, Read the chapter "Classes, Objects, and Variables" in the pickaxe book. If you were a fan, you'd know this. Right?

Shouldn't the notion of methods being public, private and protected also be a part of every modern language?

Same chapter as the first one.

Does anyone in the community acknowledge that software vendors and even many large enterprises don't build on top of scripting languages because they don't want their intellectual property so discoverable?

Um, if you write your code on the server, why does that matter? Ruby shines on the server-side. Do we need to protect ourselves from ourselves? Wasn't that a problem with the Y2K problem? Didn't they have issues finding the original code and developers had to search through assembly language. Sounds fun to me...
But, my favorite is...

Ruby seems to be missing something that is otherwise fundamental in other languages which is support for Regular Expressions.

It's built in. But, you know Java didn't have Regular Expressions until 1.4 if memory serves me correctly. I remember Java was useful without it, but boy it does make somethings easier. But, if you heavily depend on regular expressions in your code, I hope never have to maintain it.
And this one took me over the deep edge:

Ruby folks as another predictor (different from guarantee) tend to not design (Yes, I know the agile party line here) and are successful in getting applications to work quickly but tend to skip out on long term maintainability. Maybe the best thing that Java folks can do for the Ruby community is to bring more of a software engineering mindset to development.

This one got my blood boiling. I love design; I think about design; and I live for design. I get angry when people do not think before they code. I know some in the agile community think you should sit at the terminal all of the time. But, I think it's important to know how the components of your application are going to fit together before you start. You might not have all of the details, but you should know what the interfaces and what their purpose are.

Thought does not mean "Big Upfront Design". Coding right away is gross negligence. CRC cards are still an excellent tool. Hell, simple message send and class diagrams still help my thought process.

To lump all of us together and call us hacks is disturbing. Ruby takes a lot from Smalltalk . Just remember all of the GoF Patterns come from examples in every Smalltalk-80 image. Don't damn all of us for the few who don't think. Besides, I've seen my fair share of poor designs in all languages including Java. Good design goes beyond language. Period. End of story. Languages are simply amplifiers that aid in the implementation of design.

Most of the critism has been overly harsh and I think his intention was to advise. But, when you get so much wrong, it's hard to take it seriously. Ruby has a lot of senergy behind it and the thing that has shocked me is the fanaticism. We need to take some advice from "The Pragmatic Programmer's" book and show everyone how cool are toolset is and not attack them. But, by the same token, we should correct those that are mistaken. It's a thin line.

More Block Thoughts

So, I whipped out the following code to get words from a character stream (input). I read the next word (all alpha-numeric characters) and return it or nil if none were found. Simple, huh? Here's my implementation:

nextWord
 | wordString |
 wordStream := String new writeStream.
 input do: 
  [:next |
  next isAlphaNumeric
   ifTrue: [wordStream nextPut: next]
   ifFalse: 
    [wordString := wordStream contents.
     wordString isEmpty ifFalse: [^Word on: wordString]].
 wordString := wordStream contents.
 ^wordString isEmpty
  ifTrue: [nil]
  ifFalse: [Word on: wordString]

Simple, but the duplication in it was bugging me. So, I thought, "If I made a block that did the duplicated code, what would that look like?" I quickly made my changes and it looked like this:

nextWord
 | return |
 wordStream := String new writeStream.
 return := [| wordString |
   wordString := wordStream contents.
   wordString isEmpty ifFalse: [^Word on: wordString]].
 input do: 
  [:next | 
   next isAlphaNumeric 
   ifTrue: [wordStream nextPut: next]
   ifFalse: [return value]].
 return value.
 ^nil

Even simpler! This has a distinctive functional programming style to it. I'm using the block to return from the method which is unusual to be used liked this. But, it was in the spirit of "saying it only once". You might think the return could be moved out of the block, but I only want to return if wordStream contents are empty.

I could have done the same thing with exceptions, but it would been cumbersome in such a small method. The duplication is gone and the meat of the method is clear. Exceptions are useful when returns need to happen in nested method calls.

The fun thing about this example is that you could use blocks with return to bail out of searches instead of using Exceptions. Of course, you can do the same thing in Ruby. This is the first opportunity to explore this and like all tricks you should think about its use before you do it. I thought it fit perfectly for this method.

Blocks and closures are too cool. They can help in so many ways. But, they need to be cheap.

Unknown Features

I was reading a paper entitled, "Objectoriented Encapsulation for Dynamically Typed Languages", and came across an interesting piece of information.

Some Smalltalk dialects attempt to solve this problem by using a special naming convention to specify internal methods. In the Squeak dialect, for example, methods whose names begin with pvt are effectively private: the compiler ensures that these messages can be sent only to self. However, this approach not only prevents accesses to such internal methods from outside of their class but also from other objects of the same class. Thus, the pvt convention is a form
of object encapsulation: in practice it is often too strict, because it prevents many commonly used data structures and patterns from being implemented. As with Python’s double underscore, this approach is clumsy because changing the access attributes of a method requires renaming it.

Huh? I've been using Squeak for a little while now and never knew of this feature. I even asked my good friend and fellow Squeaker, Steve Wessels, about it. He told me that he had never heard of it. The paper continues with this nugget:

The utility of the pvt feature is reflected in the Squeak image: although this feature has been available for years, only 9 out of about 40,000 methods in the latest Squeak image use it.

OK, I had to go check this out, so I fired up my trusy 3.8 image and did the following:

| result |
result := OrderedCollection new.
RTCriteria new 
 methodsWhere: 
  [:each | 
   each beginsWith: 'pvt'];
 methodsDo: 
  [:eachClass :eachMethod |
   result add: (eachClass -> eachMethod)].
result

I got a result of 31 methods. Some of those come from Komanche and Celeste which are not part of the base image. Still, how come I never found about this? Squeak is just full of little nuggets. I'm constantly uncovering little things like this.

It's something new for me to try out and see how I like it. I've been an extreme encapsulation kick as of late and this is just adding fuel to my fire. I don't like adding pvt to the front, but it makes it painfully obvious when I'm breaking the rules and things like the refactoring browser help when I decide to change my mind.

So, I wonder what other little surprises are out there still waiting for me? Squeak is a surprise a minute! Oh yeah, the paper is an excellent read and I highly recommend it. I'm going to have to try out the stuff in it as well.

Omaha Dynamic Language Meeting

It just keeps getting better and I'm not saying that because I'm the organizer. Last week, we had representives from several dynamic language camps (PHP, Ruby, Smalltalk, Groovy, Lisp/Scheme, and Javascript), plus a lot of curious folks. The attendance was diverse and it was fun to give a previous of my STS talk. It was a practice run and I have several things to improve on. I appreciated everyone's patience and we had a fun discussion afterwards regarding "eliminating pain" via unit testing. It was great showing off Smalltalk. I can't wait to give my "Introduction To Seaside" talk which I hope to include some of the new libraries like Seashore and the new AJAX stuff.

Next month, we have a talk on advanced Javascript by Brent Adkisson. Trust me, it's not to be missed. Brent gave a great talk last time on DynAPI and this one promises to be even better! After that, we have several great talks coming on the following topics: Lisp, Ruby On Rails, Groovy, and Seaside! Everyone is invited, let's keep the momentum going!

Omaha Dynamic Language User's Group

Controlling Pain: Augmenting Unit Testing
Smalltalk has a highly reflective and lively environment that can be used to augment traditional unit testing. It allows us to do things that are only dreamed about in other environments. We can easily question and interrogate code or any aspect of the system. It is not hard to implement tests to ensure code correctness, enforce metrics, and scrutinize resource allocations. You can be creative and take the stance of using tests to stop and minimize the cost of change. There is a large variety of characteristics that can be tested, from run-time correctness to code quality. This presentation will give real world concrete examples in Smalltalk.

I will be presenting the talk that I will be presenting at Smalltalk Solutions. I hope to see everyone there for the sneak preview!

When	March 7, 2006, 7pm-9pm
Where	Cafe Gelato 156th & Dodge 445-4460

I Have Reinforcements

As Joshua Kerievsky says in his book Refactoring to Patterns, so many developers have an obsession with using language primitives such as strings, integers, or enumerations. Whether that’s because they think that it’s too much work to make a class, or it’ll take too many CPU cycles, or it’ll eat up too much memory, it doesn’t matter. The obsession with primitives is unhealthy and it leads to spaghetti code that is hard to refactor.

We must resist the temptation and make supple, agile code. That means we must make classes.

Objects are good...=) Trust me.