My Stuff
Front Page
Favorite Quotes

Vincent Foley-Bourgon
Sam Griffith
LeRoy Mattingly
Colin Putney
Matt Secoske
Sam Tesla
Andres Valloud

Leo Brodie
Avi Bryant
Alan Cooper
Steve Dekorte
Stephane Ducasse
Doug Engelbart
Eric Evans
Brian Foote
Martin Fowler
Paul Graham
Dan Ingalls
Alan Kay
John McCarthy
Steve McConnell
Peter Norvig
Niall Ross
Randall Smith
Gerald Jay Sussman
David Ungar
Rebecca Wirfs-Brock
...And So Many More...

My Amps
Corman Lisp
Dolphin Smalltalk
Cincom Smalltalk

05/01/2003 - 06/01/2003
06/01/2003 - 07/01/2003
07/01/2003 - 08/01/2003
08/01/2003 - 09/01/2003
09/01/2003 - 10/01/2003
10/01/2003 - 11/01/2003
11/01/2003 - 12/01/2003
12/01/2003 - 01/01/2004
01/01/2004 - 02/01/2004
02/01/2004 - 03/01/2004
03/01/2004 - 04/01/2004
04/01/2004 - 05/01/2004
05/01/2004 - 06/01/2004
06/01/2004 - 07/01/2004
07/01/2004 - 08/01/2004
08/01/2004 - 09/01/2004
09/01/2004 - 10/01/2004
10/01/2004 - 11/01/2004
11/01/2004 - 12/01/2004
12/01/2004 - 01/01/2005
01/01/2005 - 02/01/2005
02/01/2005 - 03/01/2005
03/01/2005 - 04/01/2005
04/01/2005 - 05/01/2005
05/01/2005 - 06/01/2005
06/01/2005 - 07/01/2005
07/01/2005 - 08/01/2005
08/01/2005 - 09/01/2005
09/01/2005 - 10/01/2005
10/01/2005 - 11/01/2005
11/01/2005 - 12/01/2005
12/01/2005 - 01/01/2006
01/01/2006 - 02/01/2006
02/01/2006 - 03/01/2006
03/01/2006 - 04/01/2006
04/01/2006 - 05/01/2006
05/01/2006 - 06/01/2006
06/01/2006 - 07/01/2006
07/01/2006 - 08/01/2006
08/01/2006 - 09/01/2006
09/01/2006 - 10/01/2006
10/01/2006 - 11/01/2006
11/01/2006 - 12/01/2006
12/01/2006 - 01/01/2007
01/01/2007 - 02/01/2007
02/01/2007 - 03/01/2007
03/01/2007 - 04/01/2007
04/01/2007 - 05/01/2007
05/01/2007 - 06/01/2007
06/01/2007 - 07/01/2007
07/01/2007 - 08/01/2007
08/01/2007 - 09/01/2007
09/01/2007 - 10/01/2007
10/01/2007 - 11/01/2007
11/01/2007 - 12/01/2007
12/01/2007 - 01/01/2008
01/01/2008 - 02/01/2008
02/01/2008 - 03/01/2008
03/01/2008 - 04/01/2008
04/01/2008 - 05/01/2008
05/01/2008 - 06/01/2008
06/01/2008 - 07/01/2008
07/01/2008 - 08/01/2008
08/01/2008 - 09/01/2008
10/01/2008 - 11/01/2008
01/01/2009 - 02/01/2009
09/01/2009 - 10/01/2009


Add this feed to a running copy of BottomFeeder

Sunday, April 29, 2007

Built-in Persistence/Transactions

We have long now been able to let the computer handle memory management in our programs via garbage collection. Why not let it also handle persistence and change management? I think these are things that should be built-in and it would be handled more easily by the virtual machine. There could be a low level API for hooking up different persistence strategies (relational, object, etc) and code would no longer have to be dirtied up with SQL or even worse HSQL. At the very least, change management of objects should be handled by the VM. How much easier would exception handling be if you could also rollback all the changes that had occurred and you could get back to the state you were in before the error? I think these should be the new primitives.

Gemstone is the realization of this on the server. It would be nice to make the code on the client as transparent as well. I know some might laugh at this idea, but I think it has merit. Just like garbage collection seemed strange at first, why not allow automatic persistent management as well?

Labels: , ,


Re: Make Debugging Tests Easy

Boris Popov left a comment on my post "Make Debugging Tests Easy":

Can you give a more specific example please? I don't see anything wrong with this, for instance,

| file |
file := self loadPaymentFile: self sample.
self assert: file validPayments size = 3.
self assert: file invalidPayments size = 1.

Well, I would probably change the file to a stream, but that's a different topic and discussion (I generally don't like to access outside resources in my test; they only cause problems later). Back to the conversation, the last two lines are what I don't like. The reason is that say another developer changes any of the code that gets called during the loadPaymentFile: and they run all tests. And let's say it's in common code and this test fails. Let's also say that we get back 2 valid payments and 2 invalid payments.

The developer is going to have no clue which one became invalid and what made it valid in the first place. You could put in comments explaining what the 3 valid payments and 1 invalid payment were to help. or you could break out and have several asserts for each of the cases. Otherwise, I have to revert code and rerun this test to see which payment is now incorrect. And then, put my code in and see where my code is incorrect. The above code makes the original intent hard to understand. Why were only 3 valid? Why was only 1 invalid and what made it invalid?

Really the above test is not incorrect per se, it's just not very thoughtful of the other developer's time. A couple of extra minutes of coding time would save the other developer a couple of hours. It's about coding and feeling sorry for the poor person that has to come behind you and figure out what you did. I try to always code with the maintainer in mind. Most times, the maintainer happens to be me and I'm always thankful I took the extra time to help myself.

Labels: ,


Thursday, April 26, 2007

Omaha Dynamic Language User Group

This month's meeting is brought to you by the letters G and B. Brent Adkisson is taking time out of his busy schedule to show us the power of Google's new GData API. It's a safe bet that you'll be astonished and will can't wait to find a use for GData for yourself. Brent has been telling me all about the exciting things he has been discovering with it. This is one meeting not to be missed.

Pizza, drinks, and a special prize (just like a box of Cracker Jack) will be provided for by this month's sponsor's Tek Systems.

Free food and stimulating conversation make for an exciting Tuesday night! See you all there.

SpeakerBrent Adkisson
TimeMay 1, 7-9pm
LocationUNO's Peter Kiewit Institute (PKI) building
1110 South 67th Street
Omaha, NE


Tuesday, April 24, 2007

Make Debugging Tests Easy

One pattern I see over and over in tests is the assumption that the tests will always run to green. Now, you might think that's an odd statement right? I mean the whole point of tests is to make them run green, right? Well, in a way, yes. But, more importantly they are a communication device to help new developers understand your intentions. Too many times, I've seen assert statements that simply check a size of a collection. Sure, the tests pass, but what does that saw? Why that specific size for that collection? It's frustrating because when I see these things, it's obvious the developer never thought the code would break after the test was passing.

Think about it if I check that the size of a certain collection is 5. I can bet in 6 months the reason will be fuzzy. Of course, you could name the 5 as a constant and that would certainly make it more readable. It is a step in the right direction even. But, why 5? If I change code and I get back 7, what does that mean? A constant might help, but it might not. Be specific in what you check. Don't get lazy in naming or being general. Spell it out. It might take more effort now, but it will pay huge dividends when the test breaks. More than likely, when a test breaks after it is running that it is unexpected.

Feel sorry for the poor developer that has to change your code and then figure out your tests. Take as much care in your test code as your main code. You will be thankful later. Your tests will spell out exactly what's wrong, be easy to debug, and most importantly easy to be fixed again.


  • Can you give a more specific example please? I don't see anything wrong with this, for instance,

    | file |
    file := self loadPaymentFile: self sample.
    self assert: file validPayments size = 3.
    self assert: file invalidPayments size = 1.

    By Blogger Boris Popov, at 10:25 PM   

Thursday, April 12, 2007

Tiny Types, Abstract Data Types, And Little Objects

Darren Hobbs wrote about one of my favorite topics: Tiny Types. I call them abstract data type, but I like Darren's name better. The idea is the same. I think it's just good design. I once thought that tiny objects were too much as well. But, I now think tiny objects is the only way to go.

Tiny objects make unit testing easier, aid in reuse, stop duplication dead, provide for better messages when things do break, puts functionality closer to where it is used, and I could go on all night. The amazing thing is at first I started to use tiny objects to put constraint checking in so that it didn't get propagated everywhere. But, something strange happened. These tiny objects started to take on more functionality and have real protocols beyond just get and set of their values.

I think tiny objects are even more important in dynamic languages than in Java. They can make stupid programming errors easy to find and correct. Also, your functionality is spread across several single responsibility objects working in concert to provide complexity.

Tiny objects are good design period.

Labels: ,


Tuesday, April 03, 2007

The Power OF Smalltalk Compels Thee

I've been talking with Edward Povazan lately and showing him Smalltalk to give him ideas for the Eclipse Groovy plug-in and he had some nice things to say here: Crazy Sensible Smalltalk - random ripples. I think us Smalltalkers forget what a unique experience we have inside of our tools. It's great to get someone excited about our world and show off what's possible. I'm hoping for great things to come for the Eclipse Groovy plug-in. ROCK!

Labels: ,

Web hosting by ICDSoft

Metalheads Against Racism
This page is powered by Blogger. Isn't yours?

My Weekly Top 20 Artists