Dipping My Foot In The Mac Waters

Well, today I dipped my toes in Mac waters with a PowerBook G4. I haven't had much time to dive into yet, but so far so good. Now, I need to get Squeak, Self (finally!), and F-Script installed. I'll keep everyone up to date on my findings. Wish me luck!

L'Atomium

I've spent the evening looking at pictures taken of L'Atomium in Brussels. I must go see this in person. It has to be the coolest thing I have ever seen. The inside is way cool. If I ever become rich, I want my house to look like this (both inside and out). I'm in complete love with it.

You are missed, Dawn

Power lines,
Steel webs confine,
Violating the brownish sky.
Hard grey smothers,
Earth, like cancer.
Cracks revealing,
Ground below.
Broken and bleeding,
every seed, every stone.

One of my favorite albums of all time, Fear of God's "Within The Veil" began with the above quote and you knew it wasn't going to be a cheery album. It's been ten years since Dawn passed and this has to be the darkest week in metal. We lost three great musicians all of which released albums that I cherish and love. So, today I raise my glass and listen to my metal brothers and sisters that are no longer with us. You all are missed dearly.

Are We Worrying About The Wrong Things?

Frank Kelly has written an excellent article entitled:"Are we worrying about the wrong things?" It's mainly aimed at the Java community, but it has relevance to all of us. The points he makes are problems in any programming language (minus the closure and language debate ones). It's great reading.

I agree whole-heartily with him. After awhile, I get tired of the same old language wars (pick your tools, know them well, and kick booty). We all need to know our tools better.

The core of the article is the message: Get better at your craft and mentor others on what you learn. It's up to us to make our community better. The time of being smug is over. We're in the same boat, let's help each other out.

I love Smalltalk, but I'm not afraid to use other tools. And I really don't mind Java that much (most of my rants come looking at poorly written Java). Good design is good design no matter what language. Yet, I see under-abundance of talk on design. I'm still shocked at meeting people who have never read Rebecca Wirfs-Brock's excellent "Object Oriented Design" or "Structure and Interpretation of Computer Programming". Both excellent books on design that transcend language. If you don't have them, buy them now and get "Code Complete" as well.

Anyway, the article is awesome and is a good wake-up call to us to look at the bigger picture.

Good Quote

"One's destination is never a place, but a new way of seeing things." -Henry Miller

Thought And Readable Code

Chris makes the following observation while wondering why the functional folks are such zealots:

No tool solves every problem. Put down the damned hammer and pick up a screw-driver once in a while.

I agree with the above sentiment. I love a lot of different languages for various reasons. I often say that everyday I get closer to becoming a functional programmer because that style keeps rearing its head in my code. But, like anything it needs to be tempered.

It's all about balance and simplicity. I think the functional guidelines of trying to make most objects stateless and composition to the smallest and simplest are wonderful. The code you write reads well and if you try to restrict the places where you change, then it's easier to find bugs when problems arise.

The point is don't go overboard with your ideology. The end goal should always be readable code. Readable code changes information in few places. Readable code is easier to maintain. Readable code performs well. Readable code cares about the programmer that has to pick up the pieces once you're on to something else. Readable code is small. And finally, readable code is simple.

But, readable code takes thought. Design takes thought. Most of the zealotry that I witness is from people who want to remove thought. They think great code comes from restriction. It does not. It comes from freedom to have choice. Sure, you can make a bad choice, but sometimes the bad choice might be the good choice in certain situations. But, the choice requires thought. Any hard and fast rules should be looked upon with suspension. In the wise words of George Clinton:

Think! It Ain't Illegal Yet!

Oh, and if someone still wants to make religion and dogma out of anything technical (like the functional and XP evangelists), tell them to:

Go Wiggle

I'm going to think about making better code and designs.

Shallow are words from those who starve...

...For a dream not their own to slash and scar.

Chuck you are missed, bud. Thank you for enlightening us with such great music before your untimely death. Let the metal flow!

Thinking And Sharing Ain't It Cool?!

Jeff Wild had a few comments about my Jakarta Commons post. Good stuff. It got me thinking though. The Jakarta Commons Collections library allows you to combine predicates, transformers, and closures via utility classes. And that's where my head was because my problem at work needed to have the predicates combined in different ways and I didn't want to pollute the public API of my class unneedlessly with each special case. But, Jeff made an excellent point. Do I want the clients of my code to have a dependency on the Jakarta Commons Collection library? What's a developer to do?

Then, it occurred to me. I should just make my collection of objects it's own domain specific object that I can then send the proper messages to. Thus, instead of a Collection object, you have an AccountCollection object that wraps around an ordinary collection. And this is where I can stick the "active" method. It's not static and reads so much better.

But, what about being able to combine predicates, transformers, and closures? I didn't discuss that in the original post. My post was inspired by a problem at work where I needed to combine different predicates on in-memory objects. So, it would be nice to have a "where" method that selects a subset of my new AccountCollection. I could even make the "where" functionality available in an abstract collection so that future domain specific collections could enjoy its benefits. But, to combine predicates, it's still ugly with all of the static utility method calls. Yuck. OK, what if I write my own abstract predicates, closures, and transformers that can chain themselves? For instance, you could have "and" and "or" methods to predicate; "then" for closures; and "as" method for transformers. Underneath the covers, could simply call all of the static utility methods. I get readability back (getUser().getAccounts().active() and getUser().getAccounts().where(Account.BY.olderThan(DAYS_90).and(Account.BY.active())).

I like this approach better and it keeps the knowledge shared. You could put the most frequent queries in the the domain specific collection, but still leave it open for future extension of less used queries or transformations.

Yet, again, this approves the more you move functionality down and spread responsibilities around, the easier your code becomes to read. Thanks to Jeff for making me thinking of where my solution was ugly.

Case Statements...They're Still Used?! Say it Ain't So!

It seems you can get a null pointer exception using enumerations and case statements. Ouch, my first gut instinct is why use a case statement? The enumerations in Java 1.5 support methods. Let polymorphism be your guide.

Of course, I'm surprised the minds at Sun let such mistakes go by. Both auto-boxing and enumerations allow null pointer exceptions that most coders will not catch because typically you don't expect them (because of the expansion of the real code). I think this is going to catch a lot of unsuspecting developers. Java has trained our eyes and minds to where potential null pointer exceptions could lie. Ouch. The rules have now changed.

Again, nulls rears its ugly head to smash down all of that compile type checking non-sense. It all compiles, but will it run? How much do you want to pay for safety that's not guaranteed? I'd rather not fight monsters with blankeys, but with a real sword (unit tests).

Getcha Pull

Thank you, Dime, for all of the great tunes, riffs, and solos. You are missed, my brother. You were taken from us too soon.

Agile Religion

I was going to write a blog entry about this Agile debate at Thoughtworks. But, Micheal Burke said it all much better than I could. So, I reproduce it here for your reading enjoyment. Man, I wish I had written this.

I thought Patton's definition of "software success" (taken from the blog post) was interesting:

'We knew we?d delivered successfully not when the ?EAR file as uploaded to the server,? but when we saw end users successfully working with the software on a daily basis.'

Depends on the scope of a project I suppose, but for me, I would add to that sentence "and in 5 years' time".

That draws in concerns such as flexibility of design, level and quality of documentation, ability to accomodate increasing volumes, anticipation of change, etc.

A lot of these things are anathema to the Agile dogmatist mindset (you ain't gonna need it!), and, dare I say it, the typical consultancy mindset (I've used my glorious methodology, now the maintenance guys can take over and I'll move on to the next gig - but first I'll blog about how great I feel about it.)

Given the investment in money, people and time for software of any real significance, just having something that is good enough today is, not, well, good enough.

The point that 'Agile' is now an overused cliche is well made. As is the use of 'Waterfall' to paint any project that doesn't call themselves 'Agile'. They're just labels that lazy people use to pigeonhole - kind of like music genres!

All I can add is, "AMEN BROTHER!" I totally agree.

Apparently, I like bad music

Blender made a list of the 50 worst music artists. It should come as no surprise that I like artists on that list. The guilty were: Skinny Puppy, Oingo Boingo, Whitesnake, and Kansas. How many artists do you like make the list? Fess up now...

Metal

Tenacious D's performance on Saturday Night Live singing their song, "Metal" was awesome. I was in tears. Just remember, nothing can stop the metal. Let the metal flow! Jack Black and crew ROCK!

Jakarta Commons: Collections

Lately, I've been using the Jakarta Commons Collections library quite a bit since I've been back in Java 1.4 land. The library gives you everything you're used to with iteration methods available in Ruby and Smalltalk (do, collect, select, detect, etc). But, with the verbose and cumbersome syntax of anonymous methods the point of what you're trying to do gets lost. For example,

Collection activeAccounts=CollectionUtils.select(someAccounts, new Predicate() {
 public boolean evaluate(Object object) {
  return ((Account)each).isActive();
 }
});

Wouldn't this be nicer:

Collection activeAccounts=CollectionUtils.select(someAccounts, Account.BY_ACTIVE);

One, it's lot less typing and reads much better in your logic. I've put the Predicate on the Account class. I really liked doing it this way and made my code read much more cleanly. Also, by having the Predicates defined on the objects that they were operating on, it made it easier to find which Predicates had already been defined. Everyone wins right? Well, no, I started using the same technique for Closures and Transformers too. My objects started to get crowded because I look putting my public static declarations at the top. Now, what to do?

Well, I was speaking to Matt Secoske one morning, we naturally started to discuss my dilemma of growing predicates and he had a simple answer: Put them in inner classes. At first, I scoffed at the idea, but after thinking about it, I came up with the following code:

public class Account {
 public static final Predicates BY=new Predicates();

 //Class stuff...

 //Put this at the bottom of the class
 static class Predicates {
  public Predicate active() {
   return new Predicate() {
    public boolean evaluate(Object each) {
     return ((Account)each).status.isActive();
    }
   };
  }
 }
}

I have no idea why I didn't like the idea at first. But now, my client code looks like this:

Collection activeAccounts=CollectionUtils.select(someAccounts, Account.BY.active());

The client reads the same, but now, I've gotten the implementation of the predicates out of the way. Everyone wins. I also put my transformers in their inner class named AS and one for closures called EACH. The important thing is that I keep meaningful information at the top and my client code reads well. Another thing to note is that now I can hide more information and expose less. You would be amazed at how much data is exposed in predicates. Yet, another nice side effect.

You will also notice that in the resulting code that I used a status instance variable to figure out if it was active so that I didn't have to duplicate the protocol of the status object through the Account object. My code has been getting simpler and it's been shocking me.

The point should always be to make the clients that use your objects life easier and more readable.

To Closure or Not

First, read this before continuing.

Both of the extreme cases seem comical. One takes the position of nothing but objects and the other nothing but blocks. It seems that pure object-oriented programming is at odds with functional programming. But, it's not. They need each other. I think Smalltalk and Ruby strike a good balance in this area. Blocks are used as lightweight objects (ala syntactically cheap) where a full object definition would be cumbersome. But, having nothing but blocks would also be problematic. For bigger things, we use full objects. It's the balance of having both that allows us to choose the one that allows us to more succinctly express our solution.

I don't know why people argue these things. There are problems that are better expressed in objects and others in closures (blocks). Why do I have to choose one over the other? I want both! There's also a lot that object-oriented programmers can learn from functional programmers and visa-versa. In fact, I'm always shocked how much functional programming is in pure object-oriented languages like Smalltalk and Ruby.

I'm going to go message something.

Notes From One of Alan Kay's Talks

Notes from Alan Kay's talk at O'Reilly Emerging Technology Conference 2003. Now, I was searching for something else and came across this. The interesting bit is the exchanges of emails between L. Peter Deutsch and Alan Kay.

"interactive LISP -- a metainvention, the Maxwell's Equations of programming. Today is the 40th aniversary of the first interactive implementation by a 16-year-old Peter Deutsch. It was the first time a programming language became an operating system."

WOW! Really, that's all I can say. Peter does correct the above quote. But, I'll leave that to you to discover. Makes me wish I would have asked more questions when I met Peter at Camp Smalltalk. Darn it!

Prefactoring Hate

I was shocked to find developers appalled by Ken Pugh's "Prefactoring" book. In both cases, it's amazing how much they missed the whole point behind the book by focusing on exact definitions. I think it's an excellent book on design and who couldn't use another of those? It seems to me that the XP zealots are the only ones that have a problem with it (look at the comments at Amazon). I remember the Amazon comments when the book came out, but I just ran across the above blog entries. Oh well, each to his own and if you're curious, Read this article by Ken Pugh for more on "Prefactoring". I strongly suggest you read the book. There's too much good advice in there to be ignored. The discussions on abstract data types and collections are awesome.

After A Rough Day, This Made Me Laugh.

I was browsing the net and found this....

I don't why, but it made me chuckle. It cheered me up a little from a very dark day.

About Time

The glorious end to text-based command line environments is around the corner:

Commands are not Text-based
Unlike traditional command-line interface commands, Windows PowerShell cmdlets are designed to deal with objects - structured information that is more than just a string of characters appearing on the screen. Command output always carries along extra information that you can use if you need it. We will discuss this topic in depth in this document.
If you have used text-processing tools to process command-line data in the past, you will find that they behave differently if you try to use them in Windows PowerShell. In most cases, you do not need text-processing tools to extract specific information. You can access portions of the data directly by using standard Windows PowerShell object manipulation commands.

This was taken from the documentation for Microsoft's PowerShell. All I can say is: FINALLY! Tools like grep have their place, but man, working with objects is so much nicer. I just started to look into this, but I'm liking it thus far. I've been waiting forever for a command line environment that dealt with objects instead of dumb old text.

Compile Time Reflection

I want compile time reflection in Java. They came close with giving me this:

Class someClass=MyObject.class

But, I wish it went further. If you're going to make me go through the pain of verifying everything at compile-time, then make my life easier for example:

try {
    Method method=MyObject.class.getDeclaredMethod("doSomethingCool", AnotherObject.class, String.class);
} catch(NoSuchMethodException problem) {
   //handle reflection exception that could have been caught at compile-time
} catch(SecurityException problem) {
   //handle reflection exception that could have been caught at compile-time
}

Right now, if I mis-typed "doSomethingCool" then it wouldn't get caught until run-time.Now, we don't want to make the baby Gosling cry, do we? How about this:

Method method=MyObject.class.doSomethingCool(AnotherObject,String);

For one, it's more succint and no need for any try/catch blocks because the compiler did all of the work. Another nice side effect is that you can check regular visibility constraints (if I call the above in MyObject and doSomethingCool is private, then all is good. Otherwise, don't allow it if outside of MyObject). Now, I don't have to set the setAccessible() method on Method and no security check. Now, of course, you can also use this for fields as well. In fact, it's simpler.

Now, I ask since they gave us ".class", why didn't they finish the job? Java reflection has always seemed half way there to me.

Just don't get me started on JavaBeans (where are the collections?).

Beauty. Remember that word.

Cool story about Lisp from Conscientious Software by Richard Gabriel:

In 1958, John McCarthy was thinking about a symbolic differentiation program in a programming language that was later to become Lisp. He was concerned about the “erasure problem”: no-longer-needed list structure needs to be recycled for future use. In subsequent languages, such problems were handled either by the structure of the program being restricted to trees (stack allocation of data and its trivially automatic deallocation through stack popping) or by explicit allocation and deallocation (malloc/free). His comment on erasure / explicit deallocation:

The recursive definition of differentiation made no provision
for erasure of abandoned list structure. No solution
was apparent at the time, but the idea of complicating
the elegant definition of differentiation with explicit
erasure was unattractive.-John McCarthy

It’s worth a pause to notice the style of research described. McCarthy and his colleagues were trying to design a programming language. Part of their methodology was to write the program they thought should be able to do the job and not the program that a compiler or execution system would require to make the program run well. In fact, the beauty of the program was foremost in their minds, not correctness down to the last detail. Beauty. Remember that word.

Eventually the first Lisp implementers decided to ignore the bug—the fault of not explicitly erasing abandoned list cells, causing the error of unreachable cells accumulating in memory, leading to a failure to locate a free cell when one is expected—until the failure occurred and to repair it then. This avoided the problem of entangling a common set of functionality (keeping available all the memory that should be) with a pure and clear program (symbolic differentiation). The failure the fault eventually caused was repaired, along with a lot of other similar errors in a process named at the time and still called garbage collection.

What are you waiting for read the whole thing. It's awesome and will make you think about how we can write better software. The garbage collection story put a smile on my face. "Beauty. Remember that word." I couldn't have said it better. We should always strive for beauty in our designs.

I Am Object

One thing that many Java developers that I work with think is weird is that I speak in first-person for my objects. For example:

"I should calculate the total when given a new line item"
"...that is not my responsibility..."

I act like I am the object. It's so natural to me that I don't even think about it. Now, this is very common when designing with other Smalltalkers as well. Are we the only ones that do this? And if so why? Is it because we are behavior-ists (ala Wirfs-Brock) and not data-ists? I don't know, but I think it's funny and it's what makes being a Smalltalker a joy.

Fate Is Weird

I said good-bye to Smalltalk earlier this year for what I thought was the last time. Now, by good-bye, I mean no longer working full-time in it. Did you really think that I could ever *NOT DO* Smalltalk? Anyway, I had relegated myself to Java-land with possible probation to Javascriptville or Rubypolis.

Well, I am pleased to announce that I will be returning (once again) to the land of messages and freedom. I can't wait to start. I will be working with some scary smart folks and doing outrageously cool feats of programming acrobatics. And it can only be done in Smalltalk. How lovely.

The railroad was awesome in retrospect and I had a blast. It was short-lived and I wish I could have stayed longer because I was just getting some steam on my project. Oh well, this new opportunity was just too good to pass up. The railroad has some cool aspects that I never thought about and the shipping industry is an interesting domain.

ROCK! Pass the messages and hold the data. I'm back to writing elegant code unhampered by a stuffy old compiler!

Why Lisp Has The Parentheses

I finally figured it out. It's so that you keep things small. When you have too many paranthesises, you're doing too much in your function. Small is elegant. And that is why Lisp makes you a better programmer in my mind. Of course, figuring out the Y combinator (recursive functions without names) from "The Little Schemer", macros (programs writing programs) from "Advanced Lisp", and all of "Structure and Interpretation of Computer Programs" help you make you great as well.

Null: The Runtime Error Generator

I never for the life of me want to hear another argument about how static typing catches errors at compile. I really don't. It drives me crazy! When you have to cast arguments to get them to the right thing in generic situations, it's frustrating. But, that's not the biggest sin. After writing the following line for the uptenth time:

if (something != null) {
    something.doWhatYouWereBornToDo()
}

You know what I mean. It's inevitable in legacy java applications. Now, I generally only do null checks on my inputs and avoid null conditions at all cost. But, the other day it got me thinking:

Null gets around all static type checking at compile time.

It's not a real type. It can be ANYTHING. At compile time, it slips under the radar because it only exists at runtime. So, what is my typing system doing for me? I find NullPointerExceptions tend do great damage on lazy (bad, whatever you want to call it) code. And let's face it, we've all had those days where we weren't exactly on the ball. NullPointerExceptions are sitting there to wake us up.

I really don't mind static typing. But, let's not kid ourselves. Allowing nulls throws out the safety of the compiler catching our dumb mistakes because most of mine are of the null variety (the dumb ones that is).

Of course, we could just reference everything by their interface and do the Null Object pattern and be smart about messages to ignore and which ones to worry about. But, it's a lot of typing without much gain.

Now, you might be saying to me, "But, Blaine, you imbecile! Don't you have nulls in Smalltalk, Ruby, and Lisp?" Yes, we do and it's called nil. But, we don't pretend to catch all of our dumb mistakes up front. And our nil is an ordinary object which we can add messages to. Nil, our null, is a little bit more powerful. Does it still sting when we make a programming mistake? You bet it does.

Enough on that, just don't get me started on primitive arrays in java. They are even sneakier and there's a plethora of stuff that the compiler doesn't catch.

Till next rant, keep your objects small and your messages plenty. AMEN!

Worst Web Site Ever?

Could this be the worst website? Probably not, but I'm sure it could be in the running...This is the site of one of the independents running for governor of Nebraska. Embarrassing. Not only is it annoying to read, it says absolutely nothing about the "issues" except ones that everyone can agree on. It even comes complete with an inappropriate cartoon. I expect republicans and democrats not to address issues, but I expect more from independents. Needless to say, he didn't get my vote. But, it's funny to look at his site. It's truly bad.

Happy Belated Halloween

We carved pumpkins this halloween. My wife did the scariest spider you have ever seen. Check it out!

How cool is that? So, you might guess what I might have done. I was thinking carving either Alice Cooper or this:

And of course, my wife, Michelle had to quickly take a snapshot of me in all of my techy glory.

Now, I must ask the question, am I knight now or what? I even used Squeak to edit the pictures.

By the way, I used Melissa Winger's "Powered By Smalltalk" logo. Thanks! It was a blast to carve!

Ruby and Continuations

I've been quietly observing the debate in the Ruby community over continuations being discontinued in 2.0. My stance is that the wrong debate is happening. It's not whether or not to include a feature. I think the debate should be "said feature should be possible". I want the power of being able to write continuations into Ruby if I want them. Why burden the language with extra features that only a few want? Make it possible for them to implement the feature themselves. If the features become popular, then include them in like you would a library. It's for this reason that I love Smalltalk and Lisp. There's no reason Ruby couldn't have the same power.

I didn't say it, honestly!

From Six Word Stories About Programming Languages

Smalltalk
All your concepts belong to us.

Lisp
(no ‘they all belong to (us))

MOHAHAHAHA! Ok, I'll stop the diabolical laughter now.

Welcome To World, Duncan Manning

I would like to congratulate my great friend, Richard Manning, and his wife, Emily. They ushered in a new addition to their family, Duncan Manning, on Monday. A bouncing boy that will undoubtly be keeping them busy. I just got the news today and am so excited for them! How proud they must be. Welcome, Duncan!

Rebol in Omaha

We're doing something very special this month. We're doing a workshop on Rebol. Stan Silver will be our guide through the thickets of the Rebol programming language. if you think Rebol has something to do with Cobol, then you need to come to this meeting. Rebol is a cool dynamic language that has more in common with Self, Ruby, and Lisp. It's going to be interactive and a lot of fun. It will be November 7, 2006, 7pm-9pm. I hope to see everyone there!

Here's the location specifics:
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.

PropertyDescriptor in JavaBeans

Does the JavaBeans framework have too many assumptions exposed? Does it suffer from a lack of encapsulation? I'm not talking about JavaBeans, but the framework that enables JavaBeans. Go take a quick look at PropertyDescriptor and what do you see? It knows a lot of things including read and write methods. What could be so wrong? For one, it's a dumb object (ala data structure), but that's not a bad thing given its name. But, I think it's powerless. It exposes all of its internals and has no encapsulation. But, this is a simple framework, why is that bad?

OK, it's time for an example. Spring is all of the rage (and rightfully so) and injects by the exposed writer methods in an object. But, wouldn't be nice not to expose them, but give Spring priviledged access to these fields and basically disallow ordinary access. What if I could have a custom PropertyDescriptor for just those fields. Well....

Right now, I could have a private writer and have a custom PropertyDecsriptor to grant access to it. But, what if I didn't want to add unnecessary noise to my class? Besides, it seems like a lot of trouble. Let's dream for a bit shall we?

What if instead of having getReaderMethod() and getWriterMethod(), we had getPropertyAccessor()? What would this new method return? How about this:

public interface PropertyAccessor {
    Object get(Object receiver);
    void set(Object receiver, Object newValue);
}

And this would be the default implementation:

public class MethodPropertyAccessor implements PropertyAccessor {
    private Method reader;
    private Method writer;
            
    public MethodPropertyAccessor(Method reader, Method writer) {
        this.reader=reader;
        this.writer=writer;
    }
    public Object get(Object receiver) {
        try {
            return reader.invoke(object, null);
        } catch(...PlethoraOfReflectionExceptions) {
            throw new RuntimeException(reflectionException);
        }
    }
    public void set(Object receiver, Object newValue) {
        try {
            writer.invoke(object, new Object[] {newValue});
        } catch(...PlethoraOfReflectionExceptions...) {
            throw new RuntimeException(reflectionException);
        }
    }
}

More of the knowledge in how to get/set properties in the object are known to the PropertyAccessor. We could then provide our own PropertyAccessors like we could have one built by giving it the Field itself. Like this:

public class DirectAccessPropertyAccessor implements PropertyAccessor {
    private Field property;
    
    public DirectAccessPropertyAccessor(Field property) {
        this.property=property;
        this.property.setAccessible(true);
    }
    public Object get(Object receiver) {
        try {
            return property.get(receiver);
        } catch(...PlethoraOfReflectionExceptions...) {
            throw new RuntimeException(reflectionException);
        }
    }
    public void set(Object receiver, Object newValue) {
        try {
            property.set(receiver, newValue);
        } catch(...PlethoraOfReflectionExceptions...) {
            throw new RuntimeException(reflectionException);
        }
    }
}

Users of the PropertyAccessor would not have to know how the field is accessed (whether via methods or direct access or by going through other objects). By hard-wiring to always use methods, the JavaBeans framework has exposed too much of its internal implementation to the outside world. If they would have hidden more, it would have been more flexible. Of course, the examples need more fleshing out to handle things like primitives (but, you're not using those anymore are you since you have autoboxing, right?).

I wanted to show this as a simple example of why encapsulation is good. I've made the code more flexbile, simpler, and easier to test even. The PropertyAccessor is simply a facade around the business of accessing a field. Pretty simple stuff.

Just think if you had this with so many java frameworks that use JavaBeans. Wouldn't it be nice?

RubyConf 2006

I made it back from RubyConf in one piece. What fun! I drove up with Matt Secoske and the car decided to get sick while we were there. But, it was only minor. Anyway, I got to speak to a lot of people (and there's still people that I missed and didn't get a chance to chat with). It's nice sitting it at home relaxing now. It was a fun weekend of hacking Ruby and chatting about coder things. The funniest bit has to be that I wound up give a demo of Squeak and Seaside while I was there. I just can't help myself! It's hard for me not to get excited about dynamic languages and the one closest to my heart. I also got a chance to update my Lazy Collections implementation which I will post soon. It's also great to be back with internet. It's funny. This was the second coder conference I've been to with limited access. It was a great time and I enjoyed all of the festivities! See everyone next year! Ruby On!

The Gospel Of Closures

I gave my talk on closures at the Omaha Java User's Group and had a blast. It was great showing off the power of closures. I even got to to blow minds with the Y combinator. Don't worry I didn't scare them. I used it as an example of how you can take it and then showed them a simpler example to implement the same thing. Functional programming is becoming mainstream and that's a good thing in my book.

Tour Updates

Just want to let everyone know that I will be speaking at this week's Omaha Java User Group meeting (October 17 @ 5:30pm). I'll be speaking alongside Matt Secoske, Kyle Dyer, and Scott Hickey. It will be a short talk, but it will be exciting. I promise! I hope to see everyone there.

Next up, I'll be attending this year's Ruby Conference in Denver October 20-22. I can't wait. It's going to be so much fun! New people to meet and exchange ideas with.

Eclipse Mylar

I'm in love. This is just too gorgeous. I spent the evening playing around with Mylar. I started using it with my work on TimeAndMoney and was quickly impressed. And I haven't even hooked it up to an issue tracking system yet.

Basically, it keeps the context of what you're working on. You create tasks and it pays attention to what you're editing. The cool thing is when you start switching tasks. It switches out the editors to exactly where you were and it creates a custom working set with only the files you were working on (you can also show everything and it greys out the least interesting items). I'm impressed and it works great with Eclipse 3.2. Finally, I have Squeak projects for Java and a whole lot more.

Now, I need to get Bugzilla installed...

Strings suck

All I have to say is, Amen, brother!" I see too many objects that are only comprised of primitive language types. Why not take it one step up further and make domain-specific primitives? A "Name" object might seem silly at first, but you soon find you can add validation logic and other behavior. Put down your procedures and data structures and grab an object. You'll be glad you did.

What Makes Ruby Roll

Obie Fernandez reports from JAOO where he hosted the "What Makes Ruby Roll?" track. The following quotes are bitter pills to swallow though.

Kevlin Henney said...
Someone will have rewritten it by then. Yes, will succeed where Smalltalk failed because it's not bound up in the smalltalk environment (you can open up Ruby files in Notepad). Also, do not underestimate how important a 'normal' if statement is. The biggest problem with Smalltalk is Smalltalkers.

The first part of the quote is right. Smalltalk is too much change for most developers to accept. You have a new syntax to learn, a new environment to learn, and a completely different way of thinking. It's too much for a lot of developers. It's human nature. An image-less Smalltalk would have a nicer entry point since developers love their editors (you spend a lot of time there and well, when you learn one well, you don't want to leave it). The last part of the quote really hurt. I see myself as a lot of things. I see myself as rubyist, a smalltalker, a java programmer, and a bunch more. But, I can see where the arrogance of certain Smalltalkers can detract from the true message. It makes me sad. Smalltalk is a cool language to program in and I love talking about it. But, I know it has warts like anything else. I hope no one ever sees me as an arrogant Smalltalker. I want them to see me as passionate and thoughtful.

Dave Thomas said...
As long as the people who have big checks are running on the CLR and JVM Ruby will have to crossover to those platforms to succeed. Business and economics were the downfall of Smalltalk, not natural selection. The "arrogance of the smalltalk communities sealed the lid".

Another quote right on the money, but stings me in the heart. It's true. Marketing killed Smalltalk and the arrogance that their product was better. The sad fact was yes, Smalltalk was better than C++ and Java, but having a better product doesn't win. Java had a lower cost of entry (familiar syntax, could use any text editor, and a familiar work flow) and it was good enough. Maybe if Smalltalk had been marketed correctly, maybe the story would be different. And one more thing, yeah, the arrogance of some Smalltalkers didn't help our cause.

It's always interesting to see how the rest of the developer commounities see us. I feel like we get lumped in with the grumpy Lispers. We both have great languages with communities that can be intimidating. I hope that never happens with Ruby because right now their community is inviting.

Seaside Presentation

My Seaside presentation went well last night. I got to show off Squeak, Smalltalk, and Seaside to a bunch of folks. The code browser in the web browser always amazes along with the immediate updating of pages. I love showing how Seaside gives you not only a simpler framework, but also deals with common thorny issues like back button and multiple windows. I hope I got a lot of people excited about Smalltalk. My favorite part of the night though was the reaction I got when I shut down the image, restarted it, and was at the exact point that I left it instantly. The power of image-based development compels thee! I also got some shocked faces when I said that I NEVER shutdown my web server running in Squeak even while developing. Everything stays live. Feel the freedom NOW! Seaside and Smalltalk give such great demos. I really don't have to do much.

Six Weird Things/Habits/Facts About Me

I found this on a blog of my friend, Derek Davis, and thought it was mad fun.

1. I own lots of music (enough to fill an 80 gig MP3 if they made one), but I do not own a stereo. I prefer to listen to music on headphones.


2. Territorial. I do not like anyone to be in my space when I'm not around. And I do not like it when neighbors park in front of my house.


3. I loathe cigarette smoke even though I'm an ex-smoker.


4. I love high fiber cereal. The higher the better.


5. I carry Equal and a pen wherever I go. I'm freakishly prepared for anything.


6. Encyclopedic knowledge of heavy metal that stems from being a rabid fan (I love a lot of other genres, but metal is my favorite). I can name not only the song, but the artist, album, side (remember records?), year, producer, and my first impression when I first heard it.

Seaside and Smalltalk in Omaha

I'll be giving my Seaside talk at this month's Dynamic Language User Group. I will probably spend sometime explaining why Smalltalk is so cool. Then, we'll go through continuations and why cheap closures are good. There's more to Seaside than just continuations and I will also touch on that. If you have ever been curious about Squeak, Seaside, or Smalltalk, then come on by. It's going to be explosive! It will be October 3,2006, 7pm-9pm. I hope to see everyone there!

Here's the location specifics:
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.

XP Youth

Obie Fernandez had this to say about pair programming:

Truth is, pair programming is one of the only effective ways that a lot of us have ever witnessed keeping average developers from pissing away 95% of their productivity engaging in non-work such as reading and writing blogs, instant messaging, personal email, shopping online and otherwise wasting time on bullshit.

So, we need the XP youth to keep us inline? If I'm not doing my job, I should be fired. Period. End of story. We all can't be above average, but we all need mental breaks (I doubt most developers spend 95% of their time shopping online).

Pair programming has pluses and minuses. It takes a certain personality to be good at it. I've had very few good pairs in my career. Nothing can match the creativity of two minds locked in a common crusade. It's great. BUT, I have found it takes a person that can take constructive critism of their ideas, is vocal, loves programming, and the most important: listens. Your average developer if he's browsing the net for 95% of his time probably doens't "love" what he/she is doing. I found while pairing can give the illusion of productivity, it's easy for one part of pair to be asleep at the wheel to speak. If you don't love what you do, you will find ways to avoid doing it no matter what hurdles managers throw at you.

I love pairing with passionate yet humble programmers (the greatest minds I have met have been this way). But, I hate pairing with ego maniacs. I love short bursts where we colloborate intensely and then go program solo for a short while. Get back together and show each other what we did. Rinse, repeat. I find it keeps the creativity spark alive (because you can experiment without the sucritiny of another to verify if the idea is good) and the interaction rich. It allows the feeling of working together, as well as ownership of a piece of it.

Pairing should be something that is not mandatory. It should be up to the programmers. Anything forced is going to cause people to find ways around your dogmatic rules. It's human nature. XP should be agreed upon, not enforced.

Confession Time

"A wise man changes his mind, a fool never" - Spanish Proverb

Well, at least it makes me feel better right? Well, I have a confession to make. In the past, I have argued for the use of accessors on instance variables. I liked accessors because they looked the same in the code as a method call and the flexibility. But, several months ago, I tried writing code without accessors. I was shocked by what I found about myself. First, it was hard after programming with accessors for so long and it didn't feel natural. But, I got over that in the first month or so. Second, I noticed that I broke encapsulation of my objects less. In fact, if I felt the need to access an instance variable outside of my class, I questioned myself thoroughly and generally tried to find another way.

I thought I was writing good code, but I was making little sins that added up. Forcing myself to use accessors only when necessary caused my objects to be more self-contained. I started writing smaller objects. My code got way better. So good in fact, that I find myself on the other side of the accessors debate.

Yes, I now frown upon the use of accessors by default. It leads to data structures (not objects) and controllers (not objects). The funny thing is the road to breaking encapsulation is one paved with small sins along the way. Besides, with today's tools, it's easy to switch the accessors if needed.

Oh well, I had to get that off my chest.

Too Many Toys?

I sometimes wonder do developers have too many toys? In Java, we have a plethora of open source frameworks to choose from for our next or current project. There are so many options that it can literally make your head spin right off! I've been on several Java projects in my career and every single one of them has used a different technology stack. In fact at my new job, I didn't know a few of the frameworks that were being used at all. With all of these technology choices, it would seem our life should be a piece of cake, right? Well, guess what? It's not.

There's one thing that hasn't changed. Good design and thought. Frameworks are only amplifiers in this regard much like languages. They can make our life easier if we apply them to good sound design principles. But, I think that's what is missing in our field. Go to any Border's and Barnes and Noble bookstore. Hell, go to any coder's shop and what you will find are rows and rows of books on the latest "cool" frameworks and languages. It's all vocational. You might find a little section on design if that. And it's not like we don't have great books on design. Hell, I can list several and still have more to recommend! These are the books that will stay on my shelf long after the latest framework fad or language has gone to the legacy island of old technology. It amazes me how many developers are up on the latest technology, but have never read a book on design (or maybe just one).

It shocks me. Knowledge is our most treasured asset. I strive to understand the core concepts and to go beyond. I'm always trying to learn from anything I can find (even non-software books) if it can give me a glimmer of understanding more about our field. Sometimes, I think though, we get so caught up in the flavor of the month, that we neglect the knowledge that will survive after the fads are dead.

Do we have too many toys? We're spending all of our time playing with them and not learning the core concepts that's behind them. I think that's sad. I love solving hard problems, but I want to spend my learning the problem domain. I want to learn the business of my users so I can solve their problems in elegant ways. The world of business is one of the most fun beasts to tame. I don't get excited anymore about applying the latest technology to a problem, but by solving it period. The tools needed are in your head. The frameworks only amplify what is at the core. When push comes to shove, it's still takes thought to do a good design.

So, here's my solution: read one non-vocational technical book per year. Understand it. Become it. Or at least be able to argue why you hate it. I read more books about design that any other every year. It's time well spent and it only makes you a stronger developer. Rock on, brothers!

Design Patterns of 1972

Sam Griffith sent me a link to "Design Patterns of 1972". What a great read. It's a call to arms to take our languages further. Mark uses several pattern examples from computing past and shows how they were implemented later into programing languages so that they became eventually invisible. I loved the fact that he says that we shouldn't stop at design patterns, but figure out how to incorporate them into our language. I've long believed we are doomed to repeat past sins if we don't research the paths traveled before us. Just go read "Software Fundamentals: Collected Papers" by David L. Parnas and prepare to be shocked if you doubt what I say. Anyway, Mark's article is awesome and thanks goes to Sam for showing this to me!

Now, let's roll up our sleeves and take our industry further!

I miss Zappa

I wish Zappa was still around. I always loved his wit (read his autobiography if you have a chance, it's classic). This exchange between him and a talk show host is too funny (via "Influence: The Pyschology of Persuasion" by Robert B. Cialdini).

PINE: I guess your long hair makes you a girl.
ZAPPA: I guess your wooden leg makes you a table.

Made me laugh. Time to fire up "Grand Wazoo".

Working On The Railroad

My new job is going fantastic. I'm programming in Java and learning a ton of new frameworks. I'm becoming very impressed with Tapestry. And it's great to finally see Spring in action. The domain is challenging. This is the first time I've been in the shipping business so everything is new. Of course, business is business so there is some familiarity. I am having an absolute ball. Oh, did I mention I have a window seat? Well, I do!

Time And Money Library

I'm proud to announce that I am the project manager and a developer for the Time And Money Java Library. It's an exercise in Domain Driven Design. I'm having a lot of fun with great developers. ROCK!

Updated: Comment Unit Tests For Ruby

I finally got around to updating my Comment Unit Tests For Ruby just for the fun of it. It's more robust, has a better model, and it has tests. I can now put unit tests in the comments of my code. I started using it on a project that I have and I'm loving it!

Here's a simple example:

### >>> 3 + 4
### >>= 7

You can even use variables:

### >>> a='i'
### >>> b=' love '
### >>> c='michelle'
### >>> a + b + c
### >>= 'i love michelle'

And if they are part of the same comment, it will keep the variable bindings active, so you can do this:

### >>> a + ', robot will never die'
### >>= 'i, robot will never die'

And finally, if comparing two objects bores you, then you can create your own equality check like this (notice the >>>?):

### >>> a = 5
### >>> b = 4 + 1
### >>? a == b

Enjoy and Ruby on!

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.