My Stuff
My Amps

Add this feed to a running copy of BottomFeeder

Linux World 2006 Speaker

Tuesday, February 28, 2006

String: How I Loathe Thee

There I said it! I hate strings. I really do. Nothing screams, "BROKEN WINDOW!" louder than unnecessary abuse of strings. But, you say, "Blaine, you can't be serious! We need strings! How else would we represent names and labels?" OK, you got me. We need strings, perhaps it's the abuse that I loathe. I think an example would be good here. Let's say we had a client who wanted to keep track of his albums and group them by artist. So, we quickly come up with the following class definition:
class Album {
String title;
String artist;

//Assume the usual getters/setters and general behavior

public static Album[] byArtist(String anArtistName) {

This looks pretty harmless doesn't it? You might even say that it is "the simplest possible thing that could work". You would be right. Most of our methods would in the Album model object. But, what we're missing here is the power of objects and spreading behavior out amongst cooperating objects. We would also have methods on Album that really shouldn't be Album's responsibility. Basically with just strings, we miss out on the power of objects. The obvious solution might be to use:
class Album {
String title;
Artist artist;
class Artist {
String name;
Album[] albums;

At least, we could put that search method from above into an instance method of Artist and it would be easier to traverse the object model. We wouldn't have to worry about Album validating the artist name. Oour behavior would be spread out amongst several objects and closer to the data . We will be programming closer to the language of my user which is always should be the goal. Can you sit your client down and have them understand your code? If not, there's too much geek string talk going on.

But, you say, "Blaine, the first class is SO EASY TO MAP TO OUR PERSISTENCE FRAMEWORK! Surely, it should be the way to go!" Yeah, let's make our whole model pay the unreadable tax simply because we want to make one aspect of our system easy to implement. A model that speaks the language of the user is easier to maintain and increases understanding of the domain. It's always easier to read the message directly than deciphering what you did six months ago. Strings allow behavior to be ill-placed and meaning to be lost or worse obfuscated. It's the slippery slope to design smell and broken windows.

"OK, Blaine, you're going off the deep end here! The example you gave sucks! I don't see your point. Strings are simple. Objects are more complicated. Why go through the extra hurdle if my model doesn't demand it?" Alright, alright, alright! Strings are primitives like numbers and dates. They should be treated as such. It's a matter of taste, but I believe you should use atrings only for primitive things. You might see artist as simply a String, but what happens when your client wants to know more about an artist? We could easily add this new information to an Artist object for little cost.

In the first example, what really is the instance variable "artist"? Is it the name of the artist? It could be and that would be the assumption. But, it could be anything. Hell, someone might even stick XML into the artist variable. Nothing stops them. Our intention is not specific. An Artist objects reveals exactly what we want and adds little complexity, but gains us the ability to be more agile to our client. Our readability is increased. We also have lower cognitive friction because behavior is in the right place. Strings force behavior to be placed in unnatural spots if abused.

I've seen too many examples where strings are overused and make refactorings difficult. The reason is that meaning is generally lost and it's hard to know what the String is truly representing in spaghetti code. I've even seen people hack around them (like putting XML in a field and parsing it in methods). I've seen it all. The point here is not to avoid Strings, but look at them for what they are. Primitives. Sure, the above example could have stayed like the first. And it might have enjoyed a nice happy life. The minute the client needs additional information is when we should make an Artist object and refactor. Use common sense. Overuse of strings makes me take out my code reviewer magnifying glass because generally there's sinister bugs lying underneath. They are used too often by lazy modelers who don't want to create an extra class because it wasn't "the easiest possible thing", oops, I meant, "simplest" (yes, there is a HUGE difference, one makes the answer on thought, the other on laziness). Now, don't get me started on strings in test cases as short-cuts to comparing objects. That's another blog entry...


Sunday, February 26, 2006

Morphic: What a Strange Cool World

One of the things that I love about Squeak is its environment. Once you get past the beginner stage, it offers a wealth of exploration goodness. One of my favorite tricks is when I want to learn how something is done, I simply go through the menu options of a morph while it's on screen (you can get a menu on any morph via the halos). I find the option I want to know about and then alt-click twice. This brings up the halos for the menu item. I then simply debug it (since the menu item is a morph as well). The inspector shows you all the information for the menu item including what it calls when clicked. It's a great way to learn how morphs are put together.

It might not seem like much, but I love the fact that everything in morphic is inspectable and changeable. It makes playing a lot of fun. Morphic can be frustrating sometimes, but I love how easy it is to find out how things are put together with it.

I can't wait to start playing around with Tweak and see how it is.


Friday, February 24, 2006

Update: Collecting Seashells

We discussed an article, "Collecting Seashells" a while back at the local Smalltalk User's Group. The author, Stan Silver, graced me with an updated version along with a few other things. Enjoy! If you haven't read them, then do so. It's a collection of bits of advice. Good stuff.


Ken Pugh Answers His Critics

I need to go buy "Prefactoring" by Ken Pugh. I've read a little bit in the store and it's on my wish list. It looks like a common sense approach (like much of the agile techniques), but he has been getting some heat in his Amazon reviews. I think that's silly because I think what he says is right on the money:
There is no “big design up front” in prefactoring. The “Think About the Big Picture.” guideline is not about big design. It suggests that you spend a little bit of time investigating the environment in which you are going to create your software. The environment (e.g. a corporate infrastructure, J2EE, or web services) may provide numerous services (e.g. security or error handling) that you don’t need to develop or it may suggest ways for structuring your code to fit into the framework.

Following the prefactoring guidelines does not mean you don’t refactor your code. The guidelines can help keep the smells out. But when code starts to smell, refactor it. As you go through development, you gain more knowledge about the total project, which can generate new ideas. Performing a retrospective after every release, as one guideline states, can help direct this generation of new ideas. Agility is about delivering working software to the customer. Iterative and incremental development and customer communication, as shown in the example in the book, are key principles to enable that delivery. You can use multiple tools to achieve the goal – refactoring – performing transformations on created code is one tool; prefactoring – thinking about things before coding is another.

Read his complete answer. He explains very well that being agile requires thought and not mindless mantras. Sometimes I think XP zealots get too carried away with themselves.

Thinking about your solution before you code it does not mean big upfront design. No craftsman in his right mind would start carving a piece of wood before some initial planning. Thought is cheap and if it can save refactoring later, then let's do it! Think, it ain't illegal yet.


Refactoring and Agile

Dave Thomas (of OTI fame, if you don't know who he is, go to his website now and start reading) wrote a great article entitled "Agile Programming: Design to Accommodate Change". In it, he discusses the oft forgotten table-driven design technique. But, the thing that I found most striking was his take on agile:
Refactoring improves code, usually increasing the function while reducing code bulk. However, such refactoring or restructuring often forces the application to undergo a complete development cycle, including unit, acceptance, and regression testing, followed by subsequent redeployment. In a large IT or engineering production system, this can be time consuming and error prone.

Agile programming is design for change, without refactoring and rebuilding. Its objective is to design programs that are receptive to, indeed expect, change. Ideally, agile programming lets changes be applied in a simple, localized way to avoid or substantially reduce major refactorings, retesting, and system builds.

There in a nutshell is what agile is to me. The goal is not to refactor, but to try to avoid it. Let's face it, refactoring happens because understanding changes and cruft naturally builds. But, our goal should be to avoid it at all costs. Refactoring should be used for unforeseen obstacles. We shouldn't knowingly put opportunities of refactoring into our code base from the start. Let's take Dave's advice and design to accomodate change!


Quotes on Testing

Can you guess where the following quote came from?
I think that's wht good programmers do - they test continously and at every opportunity. "Test early and often" is their motto. It's not that they have fewer bugs, but that the habit of continual testing has kept their bugs private, and consequently cheaper.

Hint: It's not from any XP book. Give up? OK, I'll tell you: "Software Testing Techniques" by Boris Beizer. What a fabulous book. I bought it because it discusses at length what the brunt of my talk at Linux World is on. He calls it structural testing (testing the code and design instead of the functional correctness). I highly recommend it. Did I mention it was written in 1983? Why do I keep unearthing these long lost tomes?! If anyone knows of any more, let me know!

I'll leave you with another quote from the book that I just loved:
There are some persons who claim that they can write bug-free programs. There's a saying among sailors on the Chesapeake River, who sandy, shifting bottom outdates charts before they're printed, "If you haven't run aground on the Chesapeake, you haven't sailed the Chesapeake much." So it is with programming and bugs: I have them, you have them, we all have them - and the point is to do what we can to prevent them and discover them but not feel guilty about them. Programmers! Cast out your guilt! Spend half of your time in joyous testing and debugging! Thrill to the excitement of the chase! Stalk bugs with care, and with method, and with reason. Build traps for them. Be more artful than those devious bugs and taste the joys of guiltless programming!

Oh, did I mention that these lovely quotes were from the introduction? It gets better! Sure, some of the book is outdated, but there are several great nuggets of information to be had. I'm going to go run off and do some guiltless programming right now.


Thursday, February 23, 2006

Squeak 3.9

I'll admit it. I'm getting excited about the new release of Squeak 3.9. It will have Traits built it in (this alone should make any Smalltalker giggle in delight), but we will also get pragmas! VisualWorks has had support for pragmas for quite sometime and they are great for adding meta-data to your methods and classes. They make a lot of things nice (like marking methods private, adding various bits to your methods, etc) and they work a lot like Java's Annotations in 1.5.

In a normal world that would be enough, but nope the awesome folks comin up with the next version have packed into tons of new playthings. The UI has changed a bit for the better and everything seems a bit more snappy (of course, this could just be my perception).

Squeak on!


Saturday, February 18, 2006

Live at Planet of Sound

My good friends in Connecticut love to rub in how cool the Northeast truly is. A mysterious package landed in my mailbox recently containing a CD called "WCCC Live at Planet of Sound". It's a collection of acoustic numbers from well known rock acts played live. The production is excellent and I've been blasting it in my car recently. But, in the end, I know it's just a ploy by my friends to make me long for the days past when I lived there. The amount of talent that foes through Connecticut is unbelievable. I make a yearly trek up there just to experience it and laugh with my good friends. The CD was a great gift and I miss my buds! =) And one more thought, it has finally replaced Coheed and Cambria in my car. My wife thanks them.


Wednesday, February 15, 2006

Refactoring Panel

I will be apart of a panel to discuss how to refactor and be doing a live demonstration. Actually, Alan Wostenberg is going to give us a piece of horrible code that we have never seen and we're going to refactor it live. The code example is in Java and we'll be showing how nice Eclipse makes refactoring as well. Should be a lot of fun! If you're in Omaha, come on by!

What is Refactoring?

Tuesday February 21, 2006
11:30 am - 1:00 pm
Event Location: Anthony's Restaurant, 72nd & F Street, Omaha

"Without daily attention to design, the cost of code changes skyrockets. The result is poorly designed, brittle, hard-to-change systems"{1}.

Refactoring is a disciplined technique for improving the design of existing code, one small step at a time. Come listen to our panel descussion on when and how to do it.

Then learn as our panelists perform several refactorings on a Mystery Algorithm in a live demo under deadline pressure. How can our heros improve this poorly-written Mystery Code when they don’t even know what it does?


Monday, February 13, 2006


Trust me. You want to see "Describe once, Get everywhere". And then you'll want to play with it. If there was ever proof that our amps go to eleven, then look no further. Lukas Renggli will be talking about Pier which is based on Magritte at Smalltalk Solutions. I can't wait. I'm so excited! The cool frameworks just keep coming.


Cleaning Up External Resources

James Robertson blogs about how easy it is to clean up resources in Smalltalk via #ensure: which is simply a message send to a block.
stream := 'someFile' asFilename writeStream.
[stream nextPutAll: 'Foo'.
"other code here"]
ensure: [stream ifNotNil: [stream close]]

But, I can't resist showing the Ruby version:"someFile", "r") do | stream |
#other code here

I love it. It takes the block one step further. The block in the Ruby code gets passed to the open where it "ensures" the stream is closed. Pretty clever. Of course, we can have the same thing in Smalltalk and it's usually something that I usually implement:
'someFile' asFilename readDuring: [:stream | "other code here"]

We simply implement #readDuring: like this:
readDuring: aBlock
| stream |
stream := self writeStream.
[aBlock value: stream] ensure: [stream close]

If we cracked open the Ruby source we would see something similiar to the above implementation. I love it when my language allows me to be concise from existing parts! Don't you? Closures rule!


Sunday, February 12, 2006

Now, Why Would I Want a PSP?

Vincent Foley recently blogged about the New Super Mario Bros. game for the DS. It looks awesome! Now, I ask you why would you want a PSP? I love my DS and I can't stop playing Mario Kart. Yes, I'm addicted. My wife is also.

There's a lot of good games coming up on the DS. We've been enjoying "Elektroplankton" (more of a fun music maker...very creative). The "Feel The Magic" guys are coming out with a new game. And a whole bunch more! I keep waiting for the Donkey Kong Country port for DS. I'm sure they would have more than a few surprises up their sleeves!

I can't wait for the Nintendo Revolution. All of Nintendo's products are fun and creative. I can't say the same about Microsoft's and Sony's offerings. I have no interested in pimping hoes, stealing cars, shooting people, or fighting. But, put me behind a wheel with Yoshi throwing shells and I am an addicted mad man!

The PSP is boring and the DS is creative and different. Let's hope Nintendo keeps going and kicks some boring trite booty! =)

  • Hey Blaine,

    if you can manage to find it, I would highly suggest that you try Phoenix Wright: Ace Attorney. It's an amazing game, it's a lot of of fun. I wrote a review on my blog a few weeks ago:

    By Vincent Foley, at 1:31 PM   

  • Probably because the PSP has a much easier to see screen, has movies so that you can watch a movie on a plane flight.

    I'll be the first to admit that some of the games on Nintendo are my favorites. I'm still considering a Nintendo Gameboy Advance SP after I get another contract.

    By smalltalker2, at 8:22 PM   

The First Dynamic Language Group Was A Success!

I almost forgot to blog about the good news! The turn out for the Dynamic Language Group was awesome! We tripled the attendance from the previous user groups that I was hosting. We packed the local Cafe Gelato to gather around Brent give his awesome talk on DynAPI. The cool thing was that we watched his presentation via VNC on our own laptops since we didn't have a projector and this was a small cafe. We improvised and I enjoyed the experience better than having a projector! I hoped everyone else did as well. I had an absolute blast.

Brent has been kind enough to post his presentation with examples. He gave a fabulous talk that spurred much excited commentary. DynAPI is a great show of what you can do with Javascript and do easily. It's also a great example of good Javascript. We even had a discussion on my favorite topic: prototype languages. We are lucky to have such talent around Omaha. It's amazing.

Hope to see even more happy dynamic lovers next month!


Thursday, February 09, 2006

Say No To Tactical Relief

Oh, I love this quote taken from page 11, "Object-Oriented Software Metrics" by Mark Lorenz and Jeff Kidd:
The skill of developing a high-quality model of your business in objects takes time. Throughout the project, someone needs to resist the temptation to take shortcuts in model quality that provide tactical relief but strategic disaster.

Just remember your special "defender of the object model" this Valentine's Day, OK. Give them a hug and thank them for their wisdom and strong headedness.


Sunday, February 05, 2006

On Rigid Rules

David Buck had some excellent thoughts on hard and fast rules in com.lang.smalltalk concerning the often hotly debated "getters/setters" argument:
Rules like "don't write getter and setter methods" are off the mark.
The problem is not getters and setters. The problem is coupling and distribution of knowledge. The fear is that if you have getters and setters on an object, then other objects are going to extract the private data of the object, do some processing on it and write it back. This operation increases the coupling between the two objects and
leads to a poorer design.

When it comes right down to it, there is basically one problem that object oriented programming tries to solve: rigidity. Rigidity occurs when a small change in the design requires significant changes to the code. For example, if you decide to rename an instance variable, any method that uses that instance variable needs to be modified. If you need to add a parameter to a method, any other method that calls it
needs to be modified in order to pass in an extra parameter.

What we want is what I call "Local Change, Local Effect". This means that a change in one area only affects a small amount of code in that area and doesn't cause massive changes and propagation of changes.

Back to getters and setters. The getters and setters on their own aren't a problem. It's how and why they are called that can cause problems. If other objects are calling getters and setters then doing work on the result, it's likely that many objects need to do the same work. This results in duplicated code. Duplicated code causes rigidity. Any design change that affects this code will affect all
copies requiring changes to be made across the system. It's better to have one copy of the code performing this operation and the natural place to put that code is in the original object.

Having said that, there are many cases where instance variables of an object are fundamental to the object's behavior and you need to be able to set them or get them. Just have a look at why you are getting or setting the variable. If it leads to duplicated code or distribution of knowledge, you are introducing more rigidity.

I have found myself in the dreaded "getter/setter" debate and I refuse to debate it anymore. David's reply above is eloquent and gets to the heart of the matter: good design. "Getters/setters" is not seeing the forest for the trees. Read the entire thread. It's a lot of fun and everyone made great points.


Beyond Mainstream Languages

José Antonio Ortega Ruiz has written an excellent article on Beyond Mainstream Object-Oriented Programming Languages. In it, he talks about the problem with modern object-oriented languages. He sings the praises of Smalltalk (simplest, cleanest syntax), but yearns for something MORE! He then goes on about prototype-based langauges like Self and Slate. He had very positive remarks on Slate and basically hails it as the future. Slate is a lot of fun to play with (I haven't blogged about it much, but I digress). Anyway, it's a fun read and I especially loved following the links (read the debate on whether an object is a poor man's closure or a closure is a poor man's object, GREAT STUFF!). I need to get back to do some prototype programming. I think Slate might just satisfy that itch, plus I've been wanting to play with Slate's dispatch mechanism.


Saturday, February 04, 2006

Maxims Of Good Style

Taken from Tutorial on Good Lisp Programming Style by Peter Norvig and Kent Pitman:

  • Be explicit

  • Be specific

  • Be concise

  • Be consistent

  • Be helpful (anticipate the reader's needs)

  • Be conventional (don't be obscure)

  • Build abstractions at a usuable level

  • Allow tools to interact (referential transparency)

Good rules to live by when you are programming in any language.


Acid Bath

I just bought their demos collection recently and it sent me down memory lane. I remember seeing them in Raleigh,NC in front of six people shortly before they broke up. Their second album was about to come out and they played as if the place had been packed. It's amazing that it's been over ten years since I first heard them and their music still has an impact on me. No band has come since to match what they did. From folky acoustic numbers to sludgy dirges to fast paced metal, they did it all. The lyrics are easily the most disturbing yet poetic that you'll ever hear. They run the gamut of emotions of the dark inner soul. I loved this band and I hated they ended so prematurely because of a drunk driver.

It's great to hear the demos to the albums that I have listened to more times than I care to count. Damn, this stuff just grooves. Nothing is better than southern sludge.


Friday, February 03, 2006

Smalltalk Future?

Brandon Werner writes:
It’s hard to predict where the product will be going in the future however, especially with Ruby gaining so much momentum. In fact, as oddly highlighted by Cincom’s Smalltalk Digest itself, a Smalltalk User Group in Omaha, Nebraska recently decided to merge with the Ruby Users Group. This is probably a good indication of where Smalltalk programmers will be going in the future, and it might make Cincom’s Smalltalk an even harder sell to the young hacker evangelists that a language needs to rise above the fray.

I think the future for Smalltalk is bright. Ruby has a wonderful and energetic community which I think only works in Smalltalk's favor. Why you ask? Well, I think that a lot of developers will check out Ruby, love it, and go no further. But, I think curiosity will get the best of some of them and they will try out Smalltalk. And the love affair will begin...

In the end, Smalltalk is here to stay. It will be the tool of choice for businesses that need a competitive advantage. I think the Ruby and Smalltalk communities are good for one another and it's why we joined the two groups together. We were getting spill over from both groups (Smalltalkers interested in Ruby and the other way around). It seemed to make sense to share ideas. Ruby's community is incredible as is Smalltalk's.

Just because we joined the groups shouldn't cause any alarms on the future of Smalltalk. The water is fine, trust me.

  • Hi Blaine,

    Just to add my 2 cents - I'm using Ruby to get /back/ to Smalltalk. Foolishly I left the fold about 8 years ago to pursue C++ and finally Java. I see Ruby and Rails as my way back into Smalltalk development.



    By Mel, at 2:23 PM   

Wednesday, February 01, 2006

PocketPC and 1G memory card

I use my PocketPC a lot. It keeps me organized and I put research papers on it to read during lull periods. Over christmas, my wife talked me into buying a one gigabyte flash card (I only wanted the thirty-two megabyte). I've been filling it up with classic computer science books and various research papers. I wasn't even making a dent in it. But, I found the perfect use for it. I got the Squeak3.8 DVD and it has the Squeak Swiki. Beautiful. I put the Swiki on the card last night and now I have it all in my pocket.

Of course, I still haven't made a big dent in my one gigabyte card....=) How cool is that?


Metalheads Against Racism

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