Blaine Buxton: Positronic Vibrations From Alto Doradohttp://blog.blainebuxton.com/
"COMPUTER POWER TO THE PEOPLE! DOWN WITH CYBERCRUD!" - Theodor Nelson2006-04-14T21:16:01Zen-US

Playing With Procs And Objectshttp://blog.blainebuxton.com/2006/04/playing-with-procs-and-objects.html
One of the things that I love about Ruby is the ability to treat methods and blocks as the same:<br /><pre>def square(number)<br /> number * number<br />end<br />method = method(:square)<br />block = lambda {|number| number*number}<br />numbers = [1, 2, 3]<br /><br />#prepare to get the same answer<br />p numbers.collect(&method)<br />#result: [1, 4, 9]<br />p numbers.collect(&block)<br />#result: [1, 4, 9]</pre><br />At first glance, you might think this happens because of method and block having a common method in :call. But, you would be wrong. Try this code and watch it fail:<br /><pre>#This fails<br />class Symbol<br /> def call(*all)<br /> method(self).call(*all)<br /> end<br />end<br />p numbers.collect(&:square)<br />#result: ERROR!</pre><br />Well, the first clue is the weird "&" in front in all calls. This converts a Proc object to a block to be passed into the call. The interpreter expects an object to be a Proc after the "&" or it complains you didn't give it one. What are we to do? Well, thankfully, the interpreter tries to do the conversion by calling :to_proc. Let's try it:<br /><pre>class Symbol<br /> def to_proc<br /> method(self).to_proc<br /> end<br /> <br />end<br />p numbers.collect(&:square)<br />#result: [1, 4, 9]</pre><br />This works like a charm! Now, by simply implementing :to_proc we can use any object to a call that expects block.<br /><pre>class MyComplicatedCalculation<br /> #lots of instance variables..too heavy for a mere Proc<br /> def to_proc<br /> #calculations that could end world hunger go here<br /> #For now, simply return a simple answer<br /> lambda { | number | 42 }<br /> end<br />end<br /><br />p numbers.collect(&MyComplicatedCalculation.new)<br />#result: [42, 42, 42]</pre><br />I do wish Ruby just allowed me to implement :call and be done with it, but implementing :to_proc isn't much more work. Have fun!Blaine2006-04-14T20:31:00Z

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

class Symbol def to_proc method(self).to_proc end

endp numbers.collect(&:square)#result: [1, 4, 9]

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

I do wish Ruby just allowed me to implement :call and be done with it, but implementing :to_proc isn't much more work. Have fun!]]>Movedhttp://blog.blainebuxton.com/2006/04/moved.html
I moved my blog to a bright new <a href="http://blog.blainebuxton.com">location</a> and you can access the <a href="http://blog.blainebuxton.com/index.rdf">feed right here</a>. It's been a long time coming. If anyone runs into any problems, let me know!Blaine2006-04-14T20:07:00Zlocation and you can access the feed right here. It's been a long time coming. If anyone runs into any problems, let me know!]]>Nintendo and Casual Gamershttp://blog.blainebuxton.com/2006/04/nintendo-and-casual-gamers.html
<a href="http://www.cincomsmalltalk.com/blog/blogView?showComments=true&entry=3322404177">James Robertson</a> talks about the market that Nintendo is after and it's the causal gamer. I must admit they get all of my gaming money (which isn't much). I'm probably what they consider a casual gamer. I don't play that much and when I do it's just to have some mad fun to clear the mind. Nintendo has the best "fun" games. Bar none, my favorite games ever are the Mario and Donkey Kong off-shoots (Donkey Kong Country, Mario Kart, Mario Bros, Wario, Yoshi, etc). Plus, I like carrying my games with me. The PSP peeked my interest when it came out, but I really don't enjoy racing real cars, shooting people, or robbing people. I want escape. Nintendo gives me that and fun in spades. Besides, the DS touch screen and on-line play is awesome. I dare anyone not to get addicted to Mario Kart.Blaine2006-04-14T01:15:00ZJames Robertson talks about the market that Nintendo is after and it's the causal gamer. I must admit they get all of my gaming money (which isn't much). I'm probably what they consider a casual gamer. I don't play that much and when I do it's just to have some mad fun to clear the mind. Nintendo has the best "fun" games. Bar none, my favorite games ever are the Mario and Donkey Kong off-shoots (Donkey Kong Country, Mario Kart, Mario Bros, Wario, Yoshi, etc). Plus, I like carrying my games with me. The PSP peeked my interest when it came out, but I really don't enjoy racing real cars, shooting people, or robbing people. I want escape. Nintendo gives me that and fun in spades. Besides, the DS touch screen and on-line play is awesome. I dare anyone not to get addicted to Mario Kart.]]>Mini-Fighthttp://blog.blainebuxton.com/2006/04/mini-fight.html
From <a href="http://www.roadrunnerrecords.com/blabbermouth.net/news.aspx?mode=Article&newsitemID=50898">Blabbermouth</a> comes this funny bit of news about MiniKiss vs. TinyKiss. It does't get much stranger:<br /><blockquote><i>Robert W. Welkos of the Los Angeles Times is reporting that Joey Fatale, the 4-foot, 4-inch New Yorker who heads the all-dwarf KISS tribute band MINIKISS, is denying published reports that he tried to sneak past security last month at the Hard Rock Hotel and Casino in Las Vegas to confront a rival band leader, 4-foot "Little" Tim Loomis of TINY KISS, for allegedly ripping off his idea for such a group.<br /><br />Loomis, a former drummer for MINIKISS, was performing with TINY KISS, which includes three little people and a 350-pound woman, on St. Patrick's Day at Beacher's Madhouse, a Las Vegas variety show, when the incident occurred.<br /><br />Show host Jeff Beacher told The Times on Monday that Fatale "tried to sneak in saying he was TINY KISS" and had to be escorted from the premises. According to the New York Post, Fatale's lawyers sent a legal cease-and-desist letter to the show trying to shut down the act.<br /><br />Loomis told the Post: "[Fatale] came out here [to Las Vegas] and tried to cause trouble, so I had him 86'd from the Hard Rock. The impression I got was that he was looking for a fight. He'd been threatening me over the phone."<br /><br />But Fatale disputed the accusation, telling The Times: "This whole thing about me going to the Hard Rock with my gang — that didn't happen. What happened was, I went there because somebody told me [TINY KISS was] doing the show that night…. Nobody escorted me out of there. I went there by myself to approach them as a gentleman."<br /><br />Fatale says he has "nothing to say" about Loomis, except, "He's a nice guy." And, he added, "This is all a big publicity act for the guy at Beacher's."</i></blockquote>Blaine2006-04-12T11:19:00ZBlabbermouth comes this funny bit of news about MiniKiss vs. TinyKiss. It does't get much stranger:

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

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

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

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

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

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

]]>Revisiting Old Code And Privatehttp://blog.blainebuxton.com/2006/04/revisiting-old-code-and-private.html
I've been looking through old code as of late and well, it's...it's...EMBARASSING! There I said it. Does anyone else do this? I was looking at my Thesaurus project (my Squeak version and soon-to-be Java version) and was appalled at a lot of the code. So, I spent sometime refactoring and getting the code back into shape. My Thesaurus project in Squeak was a quick excursion into writing Morphs and that code was fine. What made me crinch was my parsing code! For one thing, I put all of the code for parsing into one class. It was doing all sorts of stuff with the HTML elements that it had no business doing. The first order of business was to move all of the low-level HTML traversal code into a new class. This made the parser much more readable and took away the noise inside of it. The next order of business was the actual traversal code. I made some huge blunders in my implementation of the depth-first/breadth-first algorithm. I knew the first problem was when I couldn't even understand what I was doing!<br /><br />Here's the original code:<br /><pre>elementsIn: anElement do: aOneArgBlock depthFirst: aBoolean<br /> | left children |<br /> left := OrderedCollection with: anElement.<br /> [left isEmpty]<br /> whileFalse: <br /> [| next |<br /> next := aBoolean ifTrue: [left removeLast] ifFalse: [left removeFirst].<br /> (aOneArgBlock value: next) == false<br /> ifFalse: [children := OrderedCollection new.<br /> next elementsDo: [:each | aBoolean ifTrue: [children addFirst: each] ifFalse: [children addLast: each]].<br /> left addAll: children]]</pre><br />YUCK! What was I thinking with two checks for depthFirst or not? Here's the new code (which is a new class by the way!):<br /><pre>pvtDo: doBlock depthFirst: isDepthFirst <br /> | searchQueue dyadic |<br /> dyadic := self pvtCurryForContinue: doBlock.<br /> searchQueue := OrderedCollection withAll: self pvtChildren.<br /> [searchQueue isEmpty] whileFalse: <br /> [| next continue |<br /> next := self class on: searchQueue removeFirst.<br /> continue := [next addChildrenTo: searchQueue depthFirst: isDepthFirst].<br /> dyadic value: next value: continue]</pre><br />Now, you might notice some weirdness like the #pvtCurryForContinue:. All it does is to call the continue block by default if the block only accepts one argument. Otherwise, it let's the block continue through. Here's it's implementation:<br /><pre>pvtCurryForContinue: doBlock <br /> ^doBlock numArgs == 1 <br /> ifTrue: <br /> [[:each :continue | <br /> doBlock value: each.<br /> continue value]]<br /> ifFalse: [doBlock]</pre><br />This is my functional programming training shining through. This code is much cleaner and easier to read than the one before.<br /><br />This was just one simple example. I used the Thesaurus project to refactor to see how enforcing private members in Smalltalk would feel. So far, I found a lot of breaches of encapsulation that I had not noticed in the heat of development. Even with categorizing methods as private and with comments, I still broke the boundaries. The pvt at the beginning makes it obvious and Squeak's compiler tells me immediately when I have done something wrong.<br /><br />After the refactoring, I felt my design was much cleaner overall. So far, I'm enjoying using pvt at the beginning of my private methods. It makes me get into the habit of "telling" my objects instead of "asking" which I generally do well. But, it helps when I'm weak in the rush to get something done or simply not as focused as I should be. The public protocol is obvious and minimal. Plus, if I have too many pvt methods, I start looking through my methods to break the object down further.Blaine2006-04-02T19:50:00ZHere's the original code:

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

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

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

After the refactoring, I felt my design was much cleaner overall. So far, I'm enjoying using pvt at the beginning of my private methods. It makes me get into the habit of "telling" my objects instead of "asking" which I generally do well. But, it helps when I'm weak in the rush to get something done or simply not as focused as I should be. The public protocol is obvious and minimal. Plus, if I have too many pvt methods, I start looking through my methods to break the object down further.]]>Omaha Dynamic User's Grouphttp://blog.blainebuxton.com/2006/03/omaha-dynamic-users-group.html
It's time for the most exciting user's group in Omaha to have another explosive meeting! Brent Adkisson will be blessing us again with another of his great presentations. This time he will be presenting Advanced Javascript and AJAX. If you've ever wondered how to get your mind around Javascript, Brent is going to show you! It's guaranteed to expose features of Javascript that you might not have known existed. I hope to see everyone there!<br /><table border=1><tbody valign=top><br /><tr><td>When</td><br /><td>April 4, 2006, 7pm-9pm</td></tr><br /><tr><td>Where</td><br /><td><a target="map" href="http://www.mapquest.com/maps/map.adp?cat=Cafe%20Gelato&formtype=address&addtohistory=&address=N%20156th%20St%20%26%20W%20Dodge%20Rd&city=Omaha&state=NE&zipcode=68101&country=US&location=plc%2fQ5PYSvDvVSN56s%2fLvn%2fuyl3WeedQ3drwhUJ1k6UZuRfAZk9kDOUolNIkzkCIkWQKRpFM5r%2ftkftZ%2fAQTnN2dl5pG%2frdOgyYZNzMTA5QPA5%2fzvaG6%2b50y7JELphMjJxdtHOeyZ6I%3d">Cafe Gelato</a><br/><br />156th &amp; Dodge<br/><br />445-4460</td></tr><br /></tbody></table>Blaine2006-03-30T01:39:00Z

]]>Re: Block Thoughtshttp://blog.blainebuxton.com/2006/03/re-block-thoughts.html
<a href="http://www.cincomsmalltalk.com/userblogs/knight/blogView?showComments=true&entry=3320515639">Alan Knight</a> posted about <a href="http://www.blainebuxton.com/weblog/2006/03/more-block-thoughts.html">More Block Thoughts</a>. He made some excellent points. I particularly loved adding the #collecting:, #selecting, etc protocols on streams. <br /><br />The funny thing is that the method that I used as an example was part of a larger object that actually was a stream. The stream, named WordStream, wrapped a character stream and returned a Word object on each invocation of #next. Alan mentions that my Word object is "a little bit messier" than strings. And in the context of the single method, I think he is right. But, in the larger context it makes sense. The Word object has a protocol to answer things about the itself like "am I common (the,a,is)?" for example. It's just not a simple wrapper around a String. It's much more.<br /><br />I love Alan's views on streams, I'm a fan of pipe-filter designs for transformation. The WordStream was simply being fed a character stream to get more meaningful objects out. The users of WordStream only needed to know that it gave them Word objects via the stream protocol. I hate dealing with primitives and the minute I can transform something into a tangible domain object the better.<br /><br />I feel like I should have given a more thorough example and not one out of context. It would have made the design decision a little more clear. And I could have shown off an example of the pipe-filter pattern. But, I was too thrilled with my new use for blocks.Blaine2006-03-23T23:17:00ZAlan Knight posted about More Block Thoughts. He made some excellent points. I particularly loved adding the #collecting:, #selecting, etc protocols on streams.

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

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

I feel like I should have given a more thorough example and not one out of context. It would have made the design decision a little more clear. And I could have shown off an example of the pipe-filter pattern. But, I was too thrilled with my new use for blocks.]]>Thoughts on James McGovernhttp://blog.blainebuxton.com/2006/03/thoughts-on-james-mcgovern.html
Everyone else has posted their opinions on <a href="http://duckdown.blogspot.com/2006/03/additional-thoughts-on-why-ruby-isnt.html">James McGovern's Thoughts on Ruby and the Enterprise</a>. I figured, "what the hell? Why not post mine too". James McGovern lists some problems for the Ruby community to address, but stumbles from the mistakes. So, I'll start out with a nice quote:<br /><blockquote><i>Many folks haven't figured out that I too am a fan of Ruby.</i></blockquote><br />OK, I can buy this, but when it comes to the list, he makes these mistakes:<br /><blockquote><i>Does anyone agree that the notion of packages / namespaces should be a part of every modern language?</i></blockquote><br />Ruby has these things called Modules that fullfill that role.<br /><blockquote><i>I also couldn't find the equivalent of instance variables. Wouldn't that make reuse at an enterprise-level somewhat problematic?</i></blockquote><br />Uh, Read the chapter "Classes, Objects, and Variables" in the pickaxe book. If you were a fan, you'd know this. Right?<br /><blockquote><i>Shouldn't the notion of methods being public, private and protected also be a part of every modern language?</i></blockquote><br />Same chapter as the first one.<br /><blockquote><i>Does anyone in the community acknowledge that software vendors and even many large enterprises don't build on top of scripting languages because they don't want their intellectual property so discoverable?</i></blockquote><br />Um, if you write your code on the server, why does that matter? Ruby shines on the server-side. Do we need to protect ourselves from ourselves? Wasn't that a problem with the Y2K problem? Didn't they have issues finding the original code and developers had to search through assembly language. Sounds fun to me...<br />But, my favorite is...<br /><blockquote><i>Ruby seems to be missing something that is otherwise fundamental in other languages which is support for Regular Expressions.</i></blockquote><br />It's built in. But, you know Java didn't have Regular Expressions until 1.4 if memory serves me correctly. I remember Java was useful without it, but boy it does make somethings easier. But, if you heavily depend on regular expressions in your code, I hope never have to maintain it.<br />And this one took me over the deep edge:<br /><blockquote><i>Ruby folks as another predictor (different from guarantee) tend to not design (Yes, I know the agile party line here) and are successful in getting applications to work quickly but tend to skip out on long term maintainability. Maybe the best thing that Java folks can do for the Ruby community is to bring more of a software engineering mindset to development.</i></blockquote><br />This one got my blood boiling. I love design; I think about design; and I live for design. I get angry when people do not think before they code. I know some in the agile community think you should sit at the terminal all of the time. But, I think it's important to know how the components of your application are going to fit together before you start. You might not have all of the details, but you should know what the interfaces and what their purpose are. <br /><br />Thought does not mean "Big Upfront Design". Coding right away is gross negligence. CRC cards are still an excellent tool. Hell, simple message send and class diagrams still help my thought process. <br /><br />To lump all of us together and call us hacks is disturbing. Ruby takes a lot from Smalltalk . Just remember all of the GoF Patterns come from examples in every Smalltalk-80 image. Don't damn all of us for the few who don't think. Besides, I've seen my fair share of poor designs in all languages including Java. Good design goes beyond language. Period. End of story. Languages are simply amplifiers that aid in the implementation of design.<br /><br />Most of the critism has been overly harsh and I think his intention was to advise. But, when you get so much wrong, it's hard to take it seriously. Ruby has a lot of senergy behind it and the thing that has shocked me is the fanaticism. We need to take some advice from "The Pragmatic Programmer's" book and show everyone how cool are toolset is and not attack them. But, by the same token, we should correct those that are mistaken. It's a thin line.Blaine2006-03-22T03:09:00ZJames McGovern's Thoughts on Ruby and the Enterprise. I figured, "what the hell? Why not post mine too". James McGovern lists some problems for the Ruby community to address, but stumbles from the mistakes. So, I'll start out with a nice quote:

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

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

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

Ruby has these things called Modules that fullfill that role.

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

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

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

Same chapter as the first one.

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

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

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

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

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

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

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

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

Most of the critism has been overly harsh and I think his intention was to advise. But, when you get so much wrong, it's hard to take it seriously. Ruby has a lot of senergy behind it and the thing that has shocked me is the fanaticism. We need to take some advice from "The Pragmatic Programmer's" book and show everyone how cool are toolset is and not attack them. But, by the same token, we should correct those that are mistaken. It's a thin line.]]>More Block Thoughtshttp://blog.blainebuxton.com/2006/03/more-block-thoughts.html
So, I whipped out the following code to get words from a character stream (input). I read the next word (all alpha-numeric characters) and return it or nil if none were found. Simple, huh? Here's my implementation:<br /><pre>nextWord<br /> | wordString |<br /> wordStream := String new writeStream.<br /> input do: <br /> [:next |<br /> next isAlphaNumeric<br /> ifTrue: [wordStream nextPut: next]<br /> ifFalse: <br /> [wordString := wordStream contents.<br /> wordString isEmpty ifFalse: [^Word on: wordString]].<br /> wordString := wordStream contents.<br /> ^wordString isEmpty<br /> ifTrue: [nil]<br /> ifFalse: [Word on: wordString]</pre><br />Simple, but the duplication in it was bugging me. So, I thought, "If I made a block that did the duplicated code, what would that look like?" I quickly made my changes and it looked like this:<br /><pre>nextWord<br /> | return |<br /> wordStream := String new writeStream.<br /> return := [| wordString |<br /> wordString := wordStream contents.<br /> wordString isEmpty ifFalse: [^Word on: wordString]].<br /> input do: <br /> [:next | <br /> next isAlphaNumeric <br /> ifTrue: [wordStream nextPut: next]<br /> ifFalse: [return value]].<br /> return value.<br /> ^nil</pre><br />Even simpler! This has a distinctive functional programming style to it. I'm using the block to return from the method which is unusual to be used liked this. But, it was in the spirit of "saying it only once". You might think the return could be moved out of the block, but I only want to return if wordStream contents are empty. <br /><br />I could have done the same thing with exceptions, but it would been cumbersome in such a small method. The duplication is gone and the meat of the method is clear. Exceptions are useful when returns need to happen in nested method calls.<br /><br />The fun thing about this example is that you could use blocks with return to bail out of searches instead of using Exceptions. Of course, you can do the same thing in Ruby. This is the first opportunity to explore this and like all tricks you should think about its use before you do it. I thought it fit perfectly for this method.<br /><br />Blocks and closures are too cool. They can help in so many ways. But, they need to be cheap.Blaine2006-03-22T01:35:00Z

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

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

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

Blocks and closures are too cool. They can help in so many ways. But, they need to be cheap.]]>Unknown Featureshttp://blog.blainebuxton.com/2006/03/unknown-features.html
I was reading a paper entitled, <a href="http://www.iam.unibe.ch/~scg/Archive/Papers/Scha04bOOEncapsulation.pdf">"Objectoriented Encapsulation for Dynamically Typed Languages"</a>, and came across an interesting piece of information.<br /><blockquote><i>Some Smalltalk dialects attempt to solve this problem by using a special naming convention to specify internal methods. In the Squeak dialect, for example, methods whose names begin with pvt are effectively private: the compiler ensures that these messages can be sent only to self. However, this approach not only prevents accesses to such internal methods from outside of their class but also from other objects of the same class. Thus, the pvt convention is a form<br />of object encapsulation: in practice it is often too strict, because it prevents many commonly used data structures and patterns from being implemented. As with Python’s double underscore, this approach is clumsy because changing the access attributes of a method requires renaming it.</i></blockquote><br />Huh? I've been using Squeak for a little while now and never knew of this feature. I even asked my good friend and fellow Squeaker, Steve Wessels, about it. He told me that he had never heard of it. The paper continues with this nugget:<br /><blockquote><i>The utility of the pvt feature is reflected in the Squeak image: although this feature has been available for years, only 9 out of about 40,000 methods in the latest Squeak image use it.</i></blockquote><br />OK, I had to go check this out, so I fired up my trusy 3.8 image and did the following:<br /><pre>| result |<br />result := OrderedCollection new.<br />RTCriteria new <br /> methodsWhere: <br /> [:each | <br /> each beginsWith: 'pvt'];<br /> methodsDo: <br /> [:eachClass :eachMethod |<br /> result add: (eachClass -> eachMethod)].<br />result</pre><br />I got a result of 31 methods. Some of those come from Komanche and Celeste which are not part of the base image. Still, how come I never found about this? Squeak is just full of little nuggets. I'm constantly uncovering little things like this.<br /><br />It's something new for me to try out and see how I like it. I've been an extreme encapsulation kick as of late and this is just adding fuel to my fire. I don't like adding pvt to the front, but it makes it painfully obvious when I'm breaking the rules and things like the refactoring browser help when I decide to change my mind.<br /><br />So, I wonder what other little surprises are out there still waiting for me? Squeak is a surprise a minute! Oh yeah, the paper is an excellent read and I highly recommend it. I'm going to have to try out the stuff in it as well.Blaine2006-03-17T04:38:00Z"Objectoriented Encapsulation for Dynamically Typed Languages", and came across an interesting piece of information.

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

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

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

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

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

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

So, I wonder what other little surprises are out there still waiting for me? Squeak is a surprise a minute! Oh yeah, the paper is an excellent read and I highly recommend it. I'm going to have to try out the stuff in it as well.]]>Omaha Dynamic Language Meetinghttp://blog.blainebuxton.com/2006/03/omaha-dynamic-language-meeting.html
It just keeps getting better and I'm not saying that because I'm the organizer. Last week, we had representives from several dynamic language camps (PHP, Ruby, Smalltalk, Groovy, Lisp/Scheme, and Javascript), plus a lot of curious folks. The attendance was diverse and it was fun to give a previous of my STS talk. It was a practice run and I have several things to improve on. I appreciated everyone's patience and we had a fun discussion afterwards regarding "eliminating pain" via unit testing. It was great showing off Smalltalk. I can't wait to give my "Introduction To Seaside" talk which I hope to include some of the new libraries like Seashore and the new AJAX stuff.<br /><br />Next month, we have a talk on advanced Javascript by Brent Adkisson. Trust me, it's not to be missed. Brent gave a great talk last time on DynAPI and this one promises to be even better! After that, we have several great talks coming on the following topics: Lisp, Ruby On Rails, Groovy, and Seaside! Everyone is invited, let's keep the momentum going!Blaine2006-03-12T03:13:00ZNext month, we have a talk on advanced Javascript by Brent Adkisson. Trust me, it's not to be missed. Brent gave a great talk last time on DynAPI and this one promises to be even better! After that, we have several great talks coming on the following topics: Lisp, Ruby On Rails, Groovy, and Seaside! Everyone is invited, let's keep the momentum going!]]>Omaha Dynamic Language User's Grouphttp://blog.blainebuxton.com/2006/03/omaha-dynamic-language-users-group.html
<span style="font-weight:bold;">Controlling Pain: Augmenting Unit Testing</span><br />Smalltalk has a highly reflective and lively environment that can be used to augment traditional unit testing. It allows us to do things that are only dreamed about in other environments. We can easily question and interrogate code or any aspect of the system. It is not hard to implement tests to ensure code correctness, enforce metrics, and scrutinize resource allocations. You can be creative and take the stance of using tests to stop and minimize the cost of change. There is a large variety of characteristics that can be tested, from run-time correctness to code quality. This presentation will give real world concrete examples in Smalltalk.<br /><br />I will be presenting the talk that I will be presenting at Smalltalk Solutions. I hope to see everyone there for the sneak preview!<br /><table border=1><tbody valign=top><br /><tr><td>When</td><br /><td>March 7, 2006, 7pm-9pm</td></tr><br /><tr><td>Where</td><br /><td><a target="map" href="http://www.mapquest.com/maps/map.adp?cat=Cafe%20Gelato&formtype=address&addtohistory=&address=N%20156th%20St%20%26%20W%20Dodge%20Rd&city=Omaha&state=NE&zipcode=68101&country=US&location=plc%2fQ5PYSvDvVSN56s%2fLvn%2fuyl3WeedQ3drwhUJ1k6UZuRfAZk9kDOUolNIkzkCIkWQKRpFM5r%2ftkftZ%2fAQTnN2dl5pG%2frdOgyYZNzMTA5QPA5%2fzvaG6%2b50y7JELphMjJxdtHOeyZ6I%3d">Cafe Gelato</a><br/><br />156th &amp; Dodge<br/><br />445-4460</td></tr><br /></tbody></table>Blaine2006-03-02T03:00:00ZControlling Pain: Augmenting Unit TestingSmalltalk has a highly reflective and lively environment that can be used to augment traditional unit testing. It allows us to do things that are only dreamed about in other environments. We can easily question and interrogate code or any aspect of the system. It is not hard to implement tests to ensure code correctness, enforce metrics, and scrutinize resource allocations. You can be creative and take the stance of using tests to stop and minimize the cost of change. There is a large variety of characteristics that can be tested, from run-time correctness to code quality. This presentation will give real world concrete examples in Smalltalk.

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

We must resist the temptation and make supple, agile code. That means we must make classes. Objects are good...=) Trust me.]]>String: How I Loathe Theehttp://blog.blainebuxton.com/2006/02/string-how-i-loathe-thee.html
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:<br /><pre>class Album {<br /> String title;<br /> String artist;<br /><br /> //Assume the usual getters/setters and general behavior<br /> <br /> public static Album[] byArtist(String anArtistName) {<br /> ...<br /> }<br />}</pre><br />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:<br /><pre>class Album {<br /> String title;<br /> Artist artist;<br />}<br />class Artist {<br /> String name;<br /> Album[] albums;<br />}</pre><br />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.<br /><br />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.<br /><br />"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. <br /><br />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.<br /><br />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...Blaine2006-03-01T01:30:00Z

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:

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...]]>Morphic: What a Strange Cool Worldhttp://blog.blainebuxton.com/2006/02/morphic-what-strange-cool-world.html
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.<br /><br />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.<br /><br />I can't wait to start playing around with Tweak and see how it is.Blaine2006-02-27T01:57:00ZIt 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.