Wednesday, April 27, 2005

Think Dynamic

I overheard this on the ruby-talk mailing list from Lothar Scholz:
We are using a different type of language but too many people still
think in static terms. A completition popup can't look the same as in
java/C++ and the data gathering phase can't work with static source
code analysis alone. I'm not a mac guru, but follow apple and

"Think different"

This is in response to the popular "but, dynamic languages can't have auto-completion" baloney argument. First off, Squeak and VisualWorks both have auto-completion that works very well. I do tend to use it, but not very often. I certainly don't use it as much as I do when I am programming in java. Dynamic languages don't require as much cognitive friction and things just seem to flow. Auto-completion just isn't an issue. I simply loved Lother's response because it typifies the thought divide between dynamic and static language users. We "think different" because our tools allow us to create in more grandiose ways and allows access to better abstractions.

Programming and Craftsmanship

I've been enjoying reading Ora Lassila's Blog lately. I particularly enjoyed his entry on Programming as a craft. I agree with his sentiment 150% (OK, talking about framing his source code was a little much for me, I've never written code that I was THAT proud of...There's always room for improvement IMHO). It seems all too often that people think that programming computers could be done by anybody. It's true you can take anybody off the street and teach them to program, but can you make them great? I don't think so without a lot of training and passion from the trainee. The same passion that drives a great artist must be the same passion for a programmer. It's what separates the average from the good from the great. Peter Norvig has an excellent essay entitled "Teach Yourself Programming in 10 Years" which takes the position that to be great at something you must have passion and the will to practice to become better. In the paper, he argues that programming is a craft that needs to be practice to be mastered. If you would like to read a great book on the subject, read Software Craftsmanship by Pete McBreen in which he talks about having aprentenceships and masters like in the old days of blacksmiths. I love the idea of being a craftsman practicing my art everyday. Great programmers live and breathe for code. They spend every waking moment practicing and learning about their craft. One important thing that I have found about great programmers is the lack of arrogance (I've never seen an arrogant great programmer...Arrogant programmers might think they are great, but usually are only great with hot air). The great ones are humble and know that they will never know everything. They are equally eager to learn as they are to teach. I wouldn't consider myself to be great by any stretch, but I LOVE working with great developers. In fact, I think everyone has a trick that they can teach me. Camp Smalltalk 2004 allowed me to have access to some of the best minds in Smalltalk and programming in general. Everyone was eager to share and the colloboration was envigorating. I walked away with my brain hurting! I LOVED IT! I wish we could have programmer guilds where I could go and learn. I have a list of mentors that I would love to learn under. The Master of Fine Arts program at the University of Illinois was exciting for that very reason. A chance to be mentored by the best. The internet has enabled me to get closer to the best and that's a great thing. I guess this post was more of a "right on" of what other programmers have been blogging and a wish. I wish we treated programming like a craft that someone has to work at to get good at like music and painting. All programmers are not at the same level of competence much like musicians and artists are at different levels. As with any craft, you are constantly learning new ways of doing things and pushing yourself. I think it would be fun to work on a Lisp or Scheme project full-time just for the fun of it. How awesome would that be? I play with Lisp in my spare time, but I know an experienced Lisper could teach me a lot of tricks. Now, wouldn't that be cool? Well, I'm going to go practice my craft!

Tuesday, April 26, 2005

Cool Mouse Modification

Some people have too much time on their hands, but this is cute. It's basically a way to modify your mouse. Pretty cool and inventive stuff. I wonder why no one thought of it before. Mouse on!

Saturday, April 23, 2005

Quotes

I found the following quotes on Peter Norvig's site. Lots of quick spin doctor cleverisms (yeah, I made that word up). Check it out!

Omaha Ruby User's Group

I am proud to announce a new user group, Omaha Ruby User's Group. Our first meeting is just a simple get together. I'll be there with my laptop. The only planned topic is to be bring your favorite pieces of Ruby code or your curiousity. Hope to see a lot of people there! Make sure you sign up on the mailing list. Here's the information of the when and where:

    When:May 2, 2005
    Where:Panera @ Eagle Run Shopping Center
    13410 West Maple Road
    Omaha, NE 68164

Friday, April 22, 2005

Cool Google Talk

I'm a little slow, but I finally got around to watch Jeff Dean's presentation at Washington University on Google's architecture and culture. It's a great one hour talk. It made me go out and immediately download the paper on their "MapReduce" framework. One of the things that stood out for me is the "20%" rule. Basically, Google engineers spend 20% of their time on anything that tickles their fancy and most of their innovations have come from this time. Imagine that, give developers a little free time to innovate (or just think about a different problem) can be just the creative juice to make you a market leader. I've always believed that developers should have time to pursue their passions no matter what they are. We need time to play so to speak. Google not only embraces it, but encourages it. How lucky their engineers are. He continues by statting the "MapReduce" framework came from this same rule. What started out as a simple experiment has turned into a major piece of Google's processing infrastructure. I love the simplicity of it. They took an idea from functional programming and allowed their developers to take advantage of parallel computing. The video is also interesting to see what technological feats that they had to overcome to provide fast searches. All I can say is, "WOW!"

Tuesday, April 19, 2005

Dolphin 6 is coming

Dolphin 6 is coming. I'm jumping up and down with excitement! I CAN'T WAIT! I love Dolphin 5. Let's hope I get picked for the beta team...Oh powerful Smalltalk gods, please let me be one of the first to play with the ultra cool new version. OH PLEASE....OH PLEASE!

Monday, April 18, 2005

New Version of Java Serialization Package

I've posted a new version of my on-going Java Serialization Package in Squeak to SqueakMap. It's for Squeak 3.8 (it doesn't work for older versions, sorry!) Check out my projects page for more information on how to get it. So, what's new for this release? Well, I made a ton of bug fixes, refactored some things, added more tests, added support to load classes via a class path, and started a VM simulation. Now, the simulation stuff has its tests commented out (it ain't even close to working), but I decided to include it anyway. I'm kind of shocked about how much stuff I have now in this project. What started out as a little project to just read in java serialized objects has turned into a lot more. It's also suprising because it's not something that I work on full-time, just when the mood strikes. Where do I plan to take it in the future? Well, I would like to finish up the VM simulation in the distant and adding RMI capabilities in the near. Why RMI? Let's just say I've been reading my Jini and JXTA books again...=) I must admit that coding all of this stuff has made me learn a lot about the internals of java.

Saturday, April 16, 2005

Unit Testing Structure Via Reflection

I love testing my code. I'm still not to writing the test first though. I tend to write a small bit of code and then, write the test. Bad monkey, I know! But, I do testing and coding in small steps at least. Writing the test first gets the protocol to feel right from the get go. Testing is great to ensure my code works correctly but, what if I want to test the structure of my code? You might ask why anyone would want to do that. For one, I found it great to make sure code is used correctly. For instance, I've been writing a tolerant XML parser (that also parses HTML) for use in some of my projects. In my parser, I use a temporary output stream that I keep around for purely performance reasons. The only problem is that if two nested calls try to use it, there is a clash and weird results happen. So, I restricted the use to one method. But, what if I forget about this method and use the direct accessors? Even in languages that provide constricted access, this would be a problem since access is local to the object and "private" would still make it accessible. So, I wrote a test to tell me when I have done something wrong and tell me! First, let me show you the one method that I want the internal methods in my class to call:
    useOutputDuring: aOneArgBlock

    self output position > 0 ifTrue: [self warning: 'Output is being used'].
    [aOneArgBlock value: self output.
    ^self output contents]
    ensure: [self output resetToStart]
I basically send in a block that takes the stream as an argument. It then returns the contents of the stream and resets the stream for the next user. I also added a check in the beginning to warn me if it gets invoked from nested calls. Now, here's the test method:
    testOutputConsistency

    | accessors localCalls onlyCall |
    accessors := OrderedCollection new.
    self readerClass withAllSubAndSuperclassesDo: [:class |
    accessors addAll: (class whichSelectorsAccess: 'output')].
    self assert: (accessors size = 2).
    self assert: (accessors allSatisfy: [:each | each = 'output' or: [each = 'output:']]).
    localCalls := self readerClass allLocalCallsOn: #output.
    self assert: (localCalls size = 1).
    onlyCall := localCalls anyOne readStream upTo: Character space; upToEnd.
    self assert: onlyCall = 'useOutputDuring:'
The first two asserts make sure that only one setter and getter access the instance variable, output. I like accessors, so I doubt I will ever violate those, but you never know when a brain fart might occur. The last two asserts are to make sure that there is only one sender of the "output" method and that it is the "useOutputDuring:" method. This test is super easy with Smalltalk's metaclass facilities where not only can I query a class's method and instance variables, but I can also ask questions of the code itself. Smalltalk is super nice in the fact that I can questions like "Who accesses this variable?" and "Who sends this method locally?" Very powerful stuff to use ensure code is used correctly or at least warn a developer about it.

There's a lot of possibilities to explore here. One use could be to make sure access to certain methods is caught. It might be fine to call the method, you just might want to make someone think before they use it. Think of some of the lint checks for "become:". And speaking of lint, you could have lint tests like this to make sure that are no non-referenced instance variables in your classes or senders of "halt". Just another testament to the power that we enjoy in Smalltalk.

Sunday, April 10, 2005

Meeting The Challenge

Dave Thomas made a challenge to have executable unit test comments in Ruby based on this Python project. I thought it was a neat idea. At the very least, I was inspired and thought it would be a fun weekend Ruby project. It was fun reading through the RDoc and RUnit code. I posted my code here for Executable Comment Unit Tests. It works with the Runit test framework and uses the parser from RDoc. It's only one file and not that big. It only took me one day to do the code and most of the time was spent reading code. Take it from it what you will. Now, on to my thesaurus project, my second weekend project.

Saturday, April 09, 2005

Excellent Article on Naming

Mike Clark has written an excellent article entitled: "Tame The Name". It relates to my thesaurus entry in that Mike emphasizes my point of naming things properly in code. It's a great short article and well worth a read. It will make your code-fu better, I promise.

Friday, April 08, 2005

Lazy Collections In Ruby

I ported my Squeak Lazy Collections project to Ruby tonight and called it Lazy Enumerable. It was amazingly a pretty much straight forward port. Basically, the point of the project is not to create a new collection every time you call select, collect, reject on a collection. It simply holds on to the block and the original collection. Now, the fun begins when you start nesting. For example:
    temp=some_collection.select do |each| 
    each.is_interesting
    end
    answer=temp collect {|each| each.to_something}
Basically, the lazy enumerable combines the blocks for the collect and select into one and will not calculate the merged collection until some method like each or size is called. So, how do you do that? Well, the code for calling each on the LazyEnumerable looks like this:
    def each(&proc)
    self.original.each do |each|
    if (self.monadic.nil?)
    answer=each
    else
    answer=self.monadic.call(each)
    end
    proc.call(answer) unless answer === IGNOREABLE_OBJECT
    end
    end
I simply call each on the original collection and then call the block defined in myself (which I call monadic) that simply transforms values when called. Now, I return a special value if it should be ignored. This will be covered when you add a select block. For now, let's look at the simple case of adding a block that collects:
    def add_collect(&proc)
    add_monadic_valuable(&proc)
    end
This passes straight through to this method:
    def add_monadic_valuable(&proc)
    current=self.monadic
    if (current.nil?)
    self.monadic=proc
    return self
    end
    self.monadic=lambda do |each|
    result=current.call(each)
    if (result === IGNOREABLE_OBJECT)
    result
    else
    proc.call(result)
    end
    end
    self
    end
The interesting part is when I set my instance variable, monadic. I'm basically combining the current monadic with the new one passed in. Pretty cool, huh? I think this is the kind of stuff that functional programmers love. I can see why. It feels right. Now, let's look at how to add a select block:
    def add_select(&proc)
    add_monadic_valuable do |each|
    if (proc.call(each))
    each
    else
    IGNOREABLE_OBJECT
    end
    end
    end

All I do is call the same add_monadic_valuable method, but with a twist. I create yet another block that calls the select block inside to see if the value is true or false. If false, we pass back that IGNOREABLE_OBJECT. In the Smalltalk version, I originally threw an exception but took it out when the performance suffered. So, in short, I simply turn my select into a special case of collect! Now, how do I support rejects? Do I copy the code for select and use unless? Nope, all I do is negate the reject block before I send it into the add_select method. How do you do that? Like this:
    class Proc
    def negate
    lambda {|each| !self.call(each)}
    end
    end
Yet another block trick that saves me duplicated code. And that's it! If you want to run and look at the code, feel free. Check it out here. You can also download the Squeak version via SqueakMap. This was just a little project to play around with y combinator logic. It was cool looking at the Ruby and Smalltalk versions.

Thursday, April 07, 2005

Use The Ummmmm Thesaurus, Luke

I was working on a little Ruby project tonight. Basically, it's a simple upcoming calendar for just me. Nothing special. So, I started with an Event object and it is responsible for representing a calendar entry. Now, it needed to know when it was to happen and some descriptions. So, I gave it 3 instance variables: when, title, and description. The next question was how was I going to represent when. I knew it needed to display itself and compare itself to other whens (for sorting). I initially thought of the name, DateRange, since it is responsible for holding a range of dates. But, I didn't like the name because I wanted to represent the concept of future dates and a single date. DateRange just didn't feel right because it seemed too specific. So, what do I do when I don't like a name for an object? I go to my trusty thesaurus for the answer! Within seconds, I had a page full of words and one jumped right at me: "MOMENT"! EUREKA! Moment was the perfect name for this new object. It conveys the meaning of its responsibilities exactly. This way I could have FutureMoments, DatedMoments, and even UndefinedMoments. I use a thesaurus a lot in my development lately and it's an idea that I got from "Thinking Forth". It's a simple and brilliant idea. It starts getting you to think about concise words to name the objects of your model more precisely. Anything that makes meaning clear and succinct is always good in my book!

Smalltalk For Java, C#, and C++ Developers

While reading he "Smalltalk vs. Squeak" thread on comp.lang.smalltalk, I came across this document that Fernando posted. It's written with C++ programmers in mind, but I think it's for anyone who thinks Smalltalk's syntax is weird. It starts talking about the parser and moves to why the syntax is the way it is. So, if you know of any java, C#, C++, or C developers that offer the same ole "but, it's syntax is weird" line. Point them to here. And let them feel the love too.

Monday, April 04, 2005

Omaha Smalltalk User's Group

If you could only have 1 mantra to use that had to direct all your future philosophies, what would it be? If you have ever read 'The Selfish Gene' you are familiar with the idea of memes. A meme is a contagious idea competing for a share of our mind in a kind of Darwinian selection. The meme/mantra that we will take a look at in a software context is a paper called 'Collect what works' (the mantra!) by Stan Silver. This should be a fun free for all where we will consider the idea of solution spaces, and one of my favorite quotes: 'to gain knowledge, add something everyday. To gain wisdom remove something everyday'.

This month, Gary Overgard came up with the suggestion. Go to http://www.blainebuxton.com/ostug/CollectWhatWorks.doc to read the Collect What Works paper. Also, we would like to discuss using Gary's rules engine with Seaside as a Smalltalk FIT replacement. And as always bring your favorite snippets of Smalltalk code!

We're also now on meetup.com. So, sign on up!

Here's all of the details:

When: April 12, 2005, 7pm - 9pm
Where: Offices of Northern Natural Gas
1111 S 103rd Street
Omaha Nebraska 68154

Office is at 103rd & Pacific. Guests can park in the Northern visitors parking area back of building, or across the street at the mall. Enter in front door, we'll greet you at the door at 7:00pm. If you arrive a bit later, just tell the guard at the reception desk you're here for the Smalltalk user meeting in the 1st floor training room.

Can Your Language Do This?

I've been an avid Squeaker for awhile. I use the Method Finder all of the time to find methods, but never used the advanced features despite Steve Wessels' rants about just how cool it really is. Well, I started to goofing with it tonight and nothing is going to be the same. OK, it's a simple method finder with a twist. I can type in partial names of selectors, but what if I don't know the selector. What if the only thing I know is the arguments and the answer? Well, it can find the answer! For example, say I want to find a degrees to radians conversion. So, I type the following: 180. 3.1415926.. Separate everything with periods and the last thing is the answer you desire. The method finder found the following method: Number>>degreesToRadians and Float>>degreesToRadians. WOW! How cool is that?! I spent half the night typing in arguments and the results to see what it would found. I was surprised! Squeak never ceases to amaze me. Click the Method Finder link to go to the Swiki page for more examples. SQUEAK ON!

Sunday, April 03, 2005

Late April Fool's Day Joke

Check out this April Fool's Day Joke. It describes a product called the "Commentator" and is pretty cute. I love the FUD factor control the best....=) I know it's a little late...But, it's still funny!

Saturday, April 02, 2005

Holy Numbers!

Ian Prince got a sneak peak at SmallWiki 2 and was very impressed. He added a link an introduction presentation by its author Lukas Renggli. Cruise to page 10 and you will see these numbers:

Wikipedia LOCSmallWiki LOC
Wiki-Parser117,616555
Query-Engine20,970195
I guess this proves not all dynamic languages are created equal. Wikipedia is written in PHP. These are amazing numbers! I know that Seaside makes me very productive and it's nice to have proof. But, gosh darn, if those numbers are not impressive! WOW! Avi and the rest of the seaside crew must be grinning ear to ear! The presentation goes on to talk about a meta framework called Magritte that sounds very cool. I'd imagine it also had something to do with the low numbers. I can't wait till the code is released!