My Stuff
Love
Respect
Admiration
- Leo Brodie
- Avi Bryant
- Alan Cooper
- Steve Dekorte
- Stephane Ducasse
- Doug Engelbart
- Eric Evans
- Brian Foote
- Martin Fowler
- Paul Graham
- Dan Ingalls
- Alan Kay
- John McCarthy
- Steve McConnell
- Peter Norvig
- Niall Ross
- Randall Smith
- Gerald Jay Sussman
- David Ungar
- Rebecca Wirfs-Brock
- ...And So Many More...
My Amps
Links
Archives
- 05/01/2003 - 05/31/2003
- 06/01/2003 - 06/30/2003
- 07/01/2003 - 07/31/2003
- 08/01/2003 - 08/31/2003
- 09/01/2003 - 09/30/2003
- 10/01/2003 - 10/31/2003
- 11/01/2003 - 11/30/2003
- 12/01/2003 - 12/31/2003
- 01/01/2004 - 01/31/2004
- 02/01/2004 - 02/29/2004
- 03/01/2004 - 03/31/2004
- 04/01/2004 - 04/30/2004
- 05/01/2004 - 05/31/2004
- 06/01/2004 - 06/30/2004
- 07/01/2004 - 07/31/2004
- 08/01/2004 - 08/31/2004
- 09/01/2004 - 09/30/2004
- 10/01/2004 - 10/31/2004
- 11/01/2004 - 11/30/2004
- 12/01/2004 - 12/31/2004
- 01/01/2005 - 01/31/2005
- 02/01/2005 - 02/28/2005
- 03/01/2005 - 03/31/2005
- 04/01/2005 - 04/30/2005
- 05/01/2005 - 05/31/2005
- 06/01/2005 - 06/30/2005
- 07/01/2005 - 07/31/2005
- 08/01/2005 - 08/31/2005
- 09/01/2005 - 09/30/2005
- 10/01/2005 - 10/31/2005
- 11/01/2005 - 11/30/2005
- 12/01/2005 - 12/31/2005
- 01/01/2006 - 01/31/2006
- 02/01/2006 - 02/28/2006
- 03/01/2006 - 03/31/2006
Wednesday, March 29, 2006
Omaha Dynamic User's Group
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!
| When | April 4, 2006, 7pm-9pm |
| Where | Cafe Gelato 156th & Dodge 445-4460 |
Thursday, March 23, 2006
Re: Block Thoughts
Alan 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.
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.
Comments
Tuesday, March 21, 2006
Thoughts on James McGovern
Everyone else has posted their opinions on James 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:
OK, I can buy this, but when it comes to the list, he makes these mistakes:
Ruby has these things called Modules that fullfill that role.
Uh, Read the chapter "Classes, Objects, and Variables" in the pickaxe book. If you were a fan, you'd know this. Right?
Same chapter as the first one.
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...
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:
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.
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.
Comments
More Block Thoughts
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:
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:
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.
nextWord
| wordString |
wordStream := String new writeStream.
input do:
[:next |
next isAlphaNumeric
ifTrue: [wordStream nextPut: next]
ifFalse:
[wordString := wordStream contents.
wordString isEmpty ifFalse: [^Word on: wordString]].
wordString := wordStream contents.
^wordString isEmpty
ifTrue: [nil]
ifFalse: [Word on: wordString]
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:
nextWord
| return |
wordStream := String new writeStream.
return := [| wordString |
wordString := wordStream contents.
wordString isEmpty ifFalse: [^Word on: wordString]].
input do:
[:next |
next isAlphaNumeric
ifTrue: [wordStream nextPut: next]
ifFalse: [return value]].
return value.
^nil
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.
Comments
-
I agree that closures need to be cheap. But not just resource-wise: syntactically cheap too. Macros are used a lot in Common Lisp I believe to avoid typing #'(lambda (x) ...) all the time. Since in Smalltalk closures are about as succint as they can be, they tend to be used more than in other languages.
Another language that uses blocks a lot is Ruby, and that's thanks to the yield keyword and being able to send a block to a method without the whole Proc.new {} (done by prefixing the block argument with a &).
When you make it short and sweet to type blocks, people will use them all the time. And that's a good thing, of course, blocks rule!By Vincent Foley, at 10:31 PM
Thursday, March 16, 2006
Unknown Features
I was reading a paper entitled, "Objectoriented Encapsulation for Dynamically Typed Languages", and came across an interesting piece of information.
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:
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.
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
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.
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:
| result |
result := OrderedCollection new.
RTCriteria new
methodsWhere:
[:each |
each beginsWith: 'pvt'];
methodsDo:
[:eachClass :eachMethod |
result add: (eachClass -> eachMethod)].
result
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.
Comments
Saturday, March 11, 2006
Omaha Dynamic Language Meeting
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.
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!
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!
Comments
Wednesday, March 01, 2006
Omaha Dynamic Language User's Group
Controlling Pain: Augmenting Unit Testing
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.
I will be presenting the talk that I will be presenting at Smalltalk Solutions. I hope to see everyone there for the sneak preview!
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.
I will be presenting the talk that I will be presenting at Smalltalk Solutions. I hope to see everyone there for the sneak preview!
| When | March 7, 2006, 7pm-9pm |
| Where | Cafe Gelato 156th & Dodge 445-4460 |
Comments
I Have Reinforcements
Comments
Comments