My Stuff
My Amps

Add this feed to a running copy of BottomFeeder

Linux World 2006 Speaker

Sunday, January 29, 2006

Slideshow In Squeak

Alright, I spent the weekend playing around with Squeak and came up with the following snippet:
| allProjects  doBlock |
allProjects := ((Project allProjectsOrdered copyWithout: Project current)
addLast: Project current; yourself)
doBlock :=
[:project | | enterBlock exitBlock |
enterBlock := [(Delay forMilliseconds: 1000) wait. allProjects next ifNotNilDo: [:next | doBlock copy value: next]].
exitBlock := [World removeActionsWithReceiver: enterBlock].
project world
when: #aboutToEnterWorld send: #value to: enterBlock;
when: #aboutToLeaveWorld send: #value to: exitBlock.
project enter].
doBlock copy value: allProjects next.

It basically makes a slideshow of your projects and shows them one second apart. The obvious solution didn't work:
((Project allProjectsOrdered copyWithout: Project current) 
addLast: Project current; yourself) do: [:each |
(Delay forMilliseconds: 1000) wait.
each enter]

The reason is that when a project is switched, all of its threads are terminated on exit. This makes sense if you think of each project as it's own "world". So, I quickly whipped out the code in the first snippet. It was basically an understanding for me to try out different things. There's so much to explore and learn.

I want to give my presentation in Squeak and show off our great environment. I'm having fun playing around. It's funny, I've been a Squeak developer for at least a few years now and still haven't fully explored Morphic. Mainly, I've worked on backend frameworks or Seaside. But, I dabble every year for a small amount of time. The presentation will give me a reason to more fully explore the untapped potential.


Functional Programming in Javascript

Needle (the next version of HttpUnitTest) has been in research mode for quite some time now. I've been mainly trying different paths and see how they feel. One thing that I thought would be great would be able to test javascript as well as HTML. Right now, HttpUnitTest is 100% Smalltalk, but I thought it would be better to able to express tests in Javascript and run the tests in the browser. This is similiar to the approach of Selenium, but I wanted to do it like we did on HttpUnitTest. I love the API of HttpUnitTest. It's simple and allows for more flexible checks. It's also more object-oriented in that I'm not checking text, I'm looking at tagged values.

Here's an example from the HttpUnitTests:
 | browser |
browser := self browserClass on: 'http://localhost:8008/seaside/go/counter'.
self assert: (browser h1 allSatisfy: [:each | each text = '0']).
self assert: (browser a text includesAllOf: #('++' '--')).

browser click: [:a | a text = '++'].
self assert: (browser h1 text includesExactly: #('1')).

browser click: '++'.
self assert: (browser h1 text includesExactly: #('2')).

browser click: '--'.
self assert: (browser h1 text includesExactly: #('1')).

This is a test for the counter example in Seaside. Basically, you create a browser object and point it to an initial url. From there, you navigate by finding a hrefs and form submits. To verify, you simply nagivate the current page in the browser. You do this by simply sending the html element name to each level you want to look at.

For example, when you send the #h1 to the browser object, it returns all h1 elements it finds in a collection. You then, further constrain what comes back by sending the message #text which actually returns a collection of all the contents of the h1 tags. It works exactly like XQuery. But, we're doing it with messages. Pretty cool, huh?

HttpUnitTest makes extensive use of doesNotUnderstand: and generating code on the fly for its simple API. It's a trick that allows us to be more succint and still have all the power of Smalltalk. But, we don't have doesNotUnderstand: in Javascript. What are we to do? I played with several approaches and finally decided, "What if I took a functional approach?" What if I return a function instead of a collection? So, the above example would look like:
find(document, 'h1').includesExactly(['1'])

The initial find function simply is the seed and return functions that we then send in element names. The cool thing is that functions are first class objects in Javascript so they can have other functions and data hanging off of them as well. I was shocked when I first implemented this to only check for element names (other bells and whistles forthcoming) was very short. Here's the code:
    function forEach(array, func) {
for (var i=0; i < array.length; i++)

function findChildrenFromElement(anElement, name) {
var upper=name.toUpperCase()
var left=[anElement]
var result=[]
while (left.length > 0) {
var next=left.shift()
if (next.nodeName == upper) {
} else {
forEach(next.childNodes, function(each) {
return result
function findChildrenFromArray(anArray, name) {
var result=[]
forEach(anArray, function(each) {
var subResult=findChildrenFromElement(each, name)
forEach(subResult, function(eachResult) {
return result

function findAll(anArray, aString) {
var innerResults=findChildrenFromArray(anArray, aString)
var result=function(newSearch) {
return findAll(innerResults, newSearch)
return result

function find(anElement, aString) {
return findAll([anElement], aString)

The seed function find really is simply a call to findAll which is a recursive call to itself, that returns a function calling itself on the next call and the results are stored in an instance variable of the function called contents. The hard worker is findChildrenFromArray. He searches the DOM model for matches of the element name and returns the top results (it stops searching when it finds a match). The rest are support functions.

To expand on this further, the only thing that needs to change is the element name check to make it more general since we're going want to find elements based on attribute values and inner text matches. And wouldn't it be nice to use regular expressions as well (like find me all tags that match h[1-6]). The only thing that would need to change is to send a dicriminator function to findChildrenFromElement instead of the name and use it to check for a match.

I was shocked how little code this was and I have not lost any of the expresssibility of the Smalltalk version. The extra parenthesises are a drag, but it's a small price to pay to test not only your html, but also your javascript. The next research item was to integrate with JSUnit. So, I could use the same framework for testing my web pages. I could test my javascript and html together. I'll keep you posted.

Oh you might be wandering, where is Smalltalk going to be in Needle? Well, right now, my thoughts are it will be driver and it will generate the Javascript needed to test. My thought right now is that I don't want to leave my Seaside environment, but still test everything. I want the feel of HttpUnitTest, but the piece of mind knowing I'm testing not only my html and navigation, but my Javascript as well. I also want Needle in more environments as well. I'm thinking it would be nice to have a version for Java and Ruby. We'll see.

  • Can you make the code font size bigger? It's hard to read the code with the text grey and the font so small. Looks pretty good from what I can read, tho.

    By smalltalker2, at 12:26 AM   

  • Done. =)

    By Blaine, at 12:57 PM   

Saturday, January 28, 2006

Controlling Pain: Augmenting Unit Testing

I realized that I have yet to blog about my presentation at Smalltalk Solutions! For those interested, I will be giving my talk on April 26, 2006 @ 1:00-1:50pm. I hope to see a lot of people there. This is my first conference talk and I'm so excited. I'm nervous. It's an honour to share the stage with such great thinkers. I can't wait! Anyway, here's the details from my proposal:

Typically, unit testing ensures that individual pieces of an application work as expected. However, in practice this can easilylead to a state in which we settle to have just a minimum level of confidence in our code, like some sort of silly mistake insurance. But, what if we looked at testing as a means to prevent and eliminate pain, to actually increase the amount of confidence we have in our work by pointing at places where the cost of change needs to be reduced?

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.

This power can be used to prevent pain by working inside the unit test framework. For example, you can have a metric test which, upon reaching some threshold value, presents a failure with the top offenders. Moreover, you can even check that resources are cleaned up properly between each test, and fail if proper procedure is not performed. You can even verify that private messages are not sent outside the class and that deprecated methods are no longer used.

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.


Sunday, January 22, 2006

The Least Understood Thing in Computing

Before Christmas, Brian Foote made a blog entry about "The Least Understood Thing in Computing". His answer was simply "reflection". Sadly, I think he is overtly optimistic. I agree that an understanding of "reflection" is badly needed. Reflection is what makes frameworks like Hibernate and Spring possible. But, I still think they could go farther.

But, I would have answered: "encapsulation". Designs with properly encapsulated objects and layers make for great architectures. But, I've seen far too much code that exposes various aspects of the internals of the layers unneedlessly. Designs that are comprised of merely data structures and processors are complex and hard to maintain. The benefits of Good OO Design are well known and they are several good teachers. But, I keep running into procedural poo that refuses to encapsulate the internal workings of itself. Now, before anyone gets uppity, I know you can do great design in procesdural langauges as well. Information hiding works there too via modules.

I read Parnas's "Some Software Engineering Principles" article in which he talks about how easy it was for programmers to dissect programs into flows, but it was difficult to break them into modules (or objects). One of our greatest tools to aid in fighting complexity and increasing understandability is "encapsulation". Look any complex system and it will be comprised of several easy to understand sub-pieces that work well together as one cohesive. The human body is an excellent example of this. We are comprised of different systems that are comprised of even smaller systems. Nature is recursive with a keen eye for hiding information at each layer.

I think everyone in computer prgoramming knows that encapsulation is a good thing, but it's hard to achieve and is it really understood? I see designs that expose their internals all the time. It's something that is preached, but practiced in pockets. Accidental architectures arise from information exposure. Knowing what to expose and what to hide takes thought and planning in design. It just doesn't happen.

This post might seem pessimestic, but it's really a rally cry for doing better. Software projects succeed and fail for various reasons. But, I think a mixture of good technical leadership, shared vision, and good design is at the core of every success. The heart of good design is encapsulation and failure rates of 60% plus tell us we can do better. Let's start with good designs. The Pragmatic Programmers has several articles on good design and you could even pick up "Software Fundamentals" by David Parnas.


Sunday, January 15, 2006

Oh My! The Wait For Dolphin 6 Was Worth It!

I finally got around to using Dolphin 6 this weekend. I upgraded my projects in no time. I had a few problems but, they were because I called private methods without realizing it (the gods of encapsulation spoke and smited me). Truth be told, my tests found all of the problems except one. Nice.

Enough about my projects, "How is it?" you ask! Let me tell you it is a gorgeous front-end. The text editor also jumps up at you. The auto-completion is extremely accurate and helpful. I never thought I could be more productive in Smalltalk, but the guys at Object-Arts have proven me wrong. The second thing that you notice is the graphical layout tool. It is improved greatly! It now gives you examples to look at and it's simply easier to work with. I love it! You'd think they would stop there, right? Nope, they also added version control (which I was using in Dolphin 5) which works a lot like Envy.

But, wait there's more! Not only do you get all of those things, you also get this thing called "Idea Space". Basically, it's like a tabbed web browser (ala FireFox and Opera) for coding. It took a little while to get used to, but the boys used to programming in Eclipse are going to love it!

All in all, Dolphin 6 is even more fun to program than Dolphin 5. Other Smalltalk vendors should take note. The UI is awesome with lots of bells and whistles that aid you in producing and examining code. I did find some bugs, but apparently they've already been fixed. Overall, a solid product that was worth the wait. I can't wait to explore the changes in the object libraries. Treasure awaits!

  • Does Dolphin have a version control system or configuation management system? I don't like simply exporting packages as flat files.

    By booger, at 11:54 AM   

  • Yes it does. It's built into version 6.

    By Blaine, at 5:03 PM   

Thursday, January 12, 2006

Do The Simplest Thing That Could Possibly Work

A lightweight stick that is used to beat down arguments in XP projects. I came to XP thinking that the above mantra was the greatest thing since sliced bread. I still think it's a great mantra, but it needs to be taken with a grain of salt. Why? You might ask. I have seen it used too many times to disregard a potentially good idea simply because someone didn't want to think. To me, agile is about being pragmatic and delivering business value without unneeded overhead. This takes care, patience, and most importantly thought.. I get frustrated with XP because of the dogmatic mantras that developers sling around to avoid pondering alternative solutions.

I believe you should at least reason about your problem a little bit before coding. Just don't jump right in and start coding away like a mad man. I'm not talking about documenting detailed UML models with long descriptions before coding either. A simple whiteboard session to get the bird's eye view. I've found an hour or less is perfect. I find that flushing out ideas in front of a whiteboard before coding gives everyone the vision to implement the code correctly. Vision is an important aspect of team software. It gives everyone the high level perspective to know how their piece will fit in. It also gives everyone ample opportunity to speak their ideas. But, I have found in XP that coding is the king and that vision is never matured and every pair implements their piece. Guess what? The pieces don't always fit. So, we have to refactor mercilessly where a simple whiteboard session could have saved hours (and in some cases days). A stitch in time saves nine. How true.

The fact that some developers use the mantras, "Do The Simplest Thing That Could Possibly Work" and "You Ain't Gonna Need", to shoot down ideas and be the devil's advocate is annoying. It's used when an idea is not understood by certain members of the team (which is not a good thing, but discussion helps understanding). I've seen this phenomenon too many times to count. Being agile doesn't mean throwing your brain out of the door. The confusion arises in the fuzzy nature of these sayings. From who's perspective are we talking? Simplest for the developers? The users? The managers? Who? I generally take it to mean "The Users". But, most developers take it to mean simplest for them. And then, there's what people's definition of simplest is. Some think simplest means easiest and others think it means most convenient. Ironically, I take the simplest possible thing for the user and using the simplest (not the easiest, but the one with least moving parts) design. Sometimes, I think I stand alone on this. But, I know other developers take the same definition.

For example,what is simplest XML files or relational databases for object storage? Now, before I even get started it is true that you can hide the storage mechanism behind objects and plug-n-play the solution. But, is it really that simple? While, yes, in theory, I should be able to unplug one solution and plug in the other using the strategy pattern. It assumes developers will never break encapsulation (aka "Look at that private method, change it to public! We need to use it!) and the discipline is in place to make sure the interface is strictly enforced (aka "Look this interface is too coarse grained...let's add a bunch of small grained methods...this ain't no sippin' broker!"). In practice, you will have developers of varying expertise and once encapsulation is broken, you can no longer plug-and-play your solution without major refactoring. Also, little assumptions are made along the way that can degrade the quality of the interface (aka "Man, this file broker performs awful! I know, let's create a summary object and store it as well!"). Again, I get back to developers need to have discipline and vision so that the design allows the strategy pattern in our storage brokers to remain in tact. Otherwise, our interface is compromised and our membrane of encapsulation collapses into endless refactoring.

OK, I got off the discussion of XML files versus relational database storage. Which is simplest? You could argue that file storage is the simplest from the point of view of just storing objects. Right? If you are at the point of deciding storage, you are in the infant stage of your new product. Files will be nice to get the objects right before dealing with the headache of OO to relational mapping. So far so good. We are being pragmatic right? But, what about the view point of concurrency? ACID transactions? searching? Are files still the simplest possible thing? I don't think so and here's why: relational databases have been tuned by experts, people who make a living thinking about transactions, concurrency, security, and searching. All of which are not trivial topics. Now, my purpose in my job is to deliver value to my customers. How is making a file system searchable, concurrent, and acid delivering business value? It's not. So, I pay a small penance to the complexity gods to enjoy the fruits from the blood of the experts. You have to look at the bigger picture. Delivering a production enterprise system using a file system is bordering on gross negligence. I know it has been successful for certain startups (Paul Graham comes to mind, but he had the "best of the best" working for him, I'm talking general enterprise development in corporations). Of course, an even easier solution would be to use an object database, but I realize it might not be an option for everyone.

You might be thinking that I am against "Doing The Simplest Possible Thing", but I am not. I think it should not be a gauntlet that is thrown to stop arguments. I don't think it should end discussions. In fact, I think it's a value that doesn't need to be brought up in discussions. It's something to internalize and not used to make your easy solution win. You live and breathe it. You show others through example. I consider myself to be agile and not XP. I'm deeply pragmatic and think about my solutions. Dogmatic mantras are tools to not use your grey matter. Simple solutions do not just pop out of thin air. The simplest thing takes thought and understanding of the problem from all angles. It also takes practice and knowledge. The worst idea is to only have one. Experts make the simple look easy. How many people read the GoF patterns book the first time and said to themselves, "Wow, why didn't I think of that?"

  • Blaine,

    Don't conflate the feigned ignorance of the devil's advocate with XP methodology. These people would be sabotaging your effectiveness no matter what banner they flew. The principle is "Do the simplest thing THAT COULD POSSIBLY WORK". That depends on what you are trying to accomplish this iteration. If ACID, concurrency, etc. are requirements of this iteration, by all means go with the database. If they aren't, you may still decide to use a database, but you don't have to. If you are in an early iteration you may choose to use files because they give you better debugging capability. Your experience is also key in this: If you have enough domain knowledge to know that you need a database, stick to your guns. You must communicate this to your colleagues.

    I think if you talked to the originators of XP they would agree with your approach to planning. Design and programming takes a lot of thought to do right. It is not for the mentally lazy, which is what it sounds like you are running into. It also sounds like you have some cowboys on the team. XP is very much about communication within the whole team which should avoid the clashing implementation problem.

    One other point: It sounds like you are concerned about needing to refactor. XP accepts that ALL software is going to change no matter what the methodology involved in creating it. Encapsulation will be broken no matter what you do. It will always be somewhat painful to switch the implementation of your data store for example. The key is to accept that this will happen and have the courage to tackle it as you find it and refactor the code instead of programming around it and letting a big ball of mud accumulate. (That's how the broken encapsulation usually starts - somebody programming around something rather than thinking about the design and refactoring)

    Good luck, and remember - it's only programming!

    By jhemmelg, at 1:45 AM   

  • Thank you for your comments. I'm not concerned with "needing to refactor" per se. But, I am concerned with refactoring unneedlessly. I understand changing requirements and being quick on your feet. You have to be or you'll be dead in today's market. But, I also understand to be nimble on one's feet, you must reduce refactoring by thinking about your design. Experience tells you what you'll need and will not. A good designer makes this distinction and that's why they are worth their weight in gold.

    I know user's will change their mind, but mostly infrastructure concerns from project to project remain roughly the same.

    My point is to remain agile and reduce the amount of work you don't do.

    By Blaine, at 7:53 PM   

  • Experts make the simple look easy. How many people read the GoF patterns book the first time and said to themselves, "Wow, why didn't I think of that?"

    Pretty much, I did. I didn't use the wow word, though. Bad day at the office, Blaine?

    -- Mr. Too Analytical

    By smalltalker2, at 7:36 PM   

  • Hehehe, yes, it was a bad day at the office....=) I shouldn't type when mad.

    By Blaine, at 3:31 PM   

Tuesday, January 10, 2006

Chuck, I miss you bro!

When I'm having a bad day at work, I put on "The Sound Of Perseverance" and it picks me up. It's one of the few albums that speaks and touches me deeply. I wish Chuck could have stayed. These are the lyrics that gave me strength today:
What pain will it take
to satisfy your sick appetite
go in for the kill
always in sight-prey
the time always right-feast
feed on the pain-taste
sorrow made flesh-sweet
live how you want
just don't feed on me
if you doubt what i say
i will make you believe
shallow are words from those who starve
for a dream not their own to slash and scar

I miss you, bro!


Sunday, January 08, 2006

My Favorites From 2005

I thought it would be fun to share my favorite albums of 2006 with thoughts.
  1. Coheed And Cambria-Good Apollo, I'm Burning Star IV
    By far my favorite album this year! I had gotten their previous album 2 months before the release of this mammoth. I quickly fell in love and bought their first disc as well. I love this band so much. Their music is just simply incredible. I love the fact that they can make a 9 minute song sound like 3. I totally lose myself in this album. The bass player is simply phenomenal! A great mix of rock, metal, prog, and pop. The music is diverse yet it all fits into a cohesive whole. The live show was incredible too!

  2. Arsis-Diamond for Disease
    I swear these guys are channeling Chuck Schuldiner! I miss Chuck's music greatly and these guys deliver up a tasty mixure of extreme melodic metal zaniness. I love it. They remind me a lot of later era Death with more gusto. It's passionate and these guys are the future of death metal.

  3. Clutch-Robot Hive-Exodus
    These guys groove so hard. The go-go bits are brilliant and the music simply crushes. Besides, any band that works the lines, "Rocking with Dokken" and "Tipping Cows in Fields Elysian" into their music has got my vote. Clever lyrics and great songwriting. These guys should be huge. I can't wait to see them live. It took me awhile to get into them, but this album is the one that sold me!

  4. Story of the Year-In The Wake of Determination
    Anthemic pissed off music. This is basically old school thrash with a great singer. Emo my ass. This is great stuff. Who needs the next Metallica when you have this?

  5. Crowbar-Lifesblood for the Downtrodden
    HEAVY. I love Crowbar. They are the kings of consistent output and never disappoint. Crushing.

  6. Alice Cooper-Dirty Diamonds
    The master returns and this time it's his best in years. This albums shows all the facets of Alice in a classic rock setting. I hope Alice keeps making them like this.

  7. Biomechanical-The Empires of The World
    This took a few spins for me to love it. It's technical thrash with lots of riff changes. It will make you dizzy, but once you get used to the curves in the track, this is one fun rollercoaster!

  8. Vendetta Red-Sisters of the Red Death
    Surprise album for me. The subject matter will make you squirm, yet they make it sound so catchy. This one got stuck in the player and I love to sing along to it. Of course, people probably think I'm strange.

  9. Pig-Pigmata
    PIG returns with his best album! Careful arrangements and clever electronics are spreadout this tour de force of what Pig does best. He gives you a good sampling of what he's up to and it makes for an interesting and never boring ride.

  10. Thrice-Vheissu
    Wow. "Artist in the Ambulance" was good, but this just sets the standard to a new high. Super catchy music that stays creative without tripping over itself or being too self indulgent.

  11. Candlemass-Candlemass
    Messiah returns with the might Candlemass and quite frankly Messiah can make sound great. His voice is just unmatched. Of course, the rest of Candlemass outdid themselves on this comeback disc. It's like they never left. Oh, this band throws me back to my younger years. What fun!

  12. Dredg-Catch Without Arms
    Another surprise band for me. It took me a few listens to grow into this disc, but what we have is catchy atmospheric rock. I can't describe this band well, but I know I love them. Tight band live too.

  13. Bloodbath-Nightmares Made Flesh
    FUN. Simply put. This is another throwback to my old years when we would sing the sickest lyrics and laugh ourselves silly. Mad fun. Great old school death metal with tongue firmly in cheek.

  14. Corrosion of Conformity-In The Arms Of God
    Black Sabbath worship. Man, they have the grooves and feel of old school Sabbath without becoming a copycat. The whole southern heavy vibe is just awesome. The lyrics as usual are great. They brought back the politics and turned the volume up again! I don't care, this band always puts out something good and you never know quite what to expect. It's always a little bit different.

  15. Firewind-Forged By Fire
    Anthemic power metal that's just fun. Lots of great guitar work to boot as well. It goes a little overboard and I love it for that. This again takes me back to the old days of power metal. Mad fun again!

  16. System of a Down-Mezmerize/Hypnotize
    I never heard anything before this band, but I love both of these discs for their quirky nature. The goofy lyrics and never know what to expect make these a fun listen.

  17. Russell Allen-Atomic Soul
    WOW! The voice of Symphony X outputs a disc that trumps his main band! He wrote all of the music and played most of the instruments. What we get is a spirited romp through rock history. Again, this is an album to put on and just crank the volume!

  18. Confessor-Unraveled
    OK, I loved this band when I was younger, but I have never heard a comeback album like this. Simply put, this is their best album and it spent a lot of time in my player. Slowly played doom with a great singer and progressive flourishes. Great musicianship and songs. I can't wait for the next!

  19. Chiodos-Alls Well That Ends Well
    It took me a little while to get into the singer on this album, but I'm glad I did. The music is fantastic. I love the keyboard player.

  20. Avenged Sevenfold-City of Evil
    I hated the song "Bat Country" when I first heard it because the singer didn't click with me, but once I gave the song a chance, I loved it! These guys suck you in with an old school sound with a punk feel. It's got urgency and enough to hooks to sink a battleship.

Honorable Mentions:
Funker Vogt-Navigator
Between The Buried and Me-Alaska
Arch Enemy-Doomsday Machine
Nevermore-The Godless Endeavor
The Fall of Troy-Doppelganger
The Design-Into The Moat
Grand Magus-Wolf's Return
Porcupine Tree-Deadwing
Roadrunner United-The All-Star Session


Saturday, January 07, 2006

Omaha Dynamic Language User Group

The Smalltalk and Ruby user's groups have been combined into the new and exciting Dynamic Language User's Group. The new group will be about all dynamic langauges. So, we'll be talking about a lot of languages. The first meeting will be on February 7, 2006. Our first topic will be DynAPI which is cool Javascript open source project and presented by Brent Adkisson. Our meeting place and email list has changed too. I hope to see everyone! Sign up for the new list!

WhenFirst Tuesday of the month, 7pm-9pm
WhereCafe Gelato

156th & Dodge



Wednesday, January 04, 2006

I'm so excited!

Look! I will be a speaker at Smalltalk Solutions 2006! How cool is that? The speaker list is impressive and I'm anxious to meet both Avi Bryant and Brian Foote! April can't come quick enough!

Seriously, my presentation is based on some of the stuff I've been blogging about meta-testing. I plan on doing a java version of it as well once Smalltalk Solutions is over. It will be interesting to see the different implementations.



It's not everyday you can read find well-written Javascript code, but I found some great examples in the DynAPI. It's a Javascript library with all kinds of goodies and it even has an editor that's all Javascript as well. Pretty cool stuff....I'm still looking through it all, but from the examples, it's plain simple!

I'm impressed!


Dynamic Language Failure in 2006? Please!

From Relevance:
...2006 will show that dynamically typed languages are a fad and Java and .NET will again rule the day, and especially that 2006 will be the year that we see one spectacular failure of Ruby in the enterprise and this will be the death knell of this trend.

I don't wish failure even on my worst enemies. I can't believe somebody would blog such trite. Dynamic languages are a fad? Please. Lisp is the grand daddy of them all and what year was it conceived? Hint: It was WAY before the birth of java and .net.

Why can't we all just get along? I've been apart of successful java and smalltalk projects. Each had their own unique challenges. Developers are attracted to each because of their experience and success with their choice. Why wish failure? Are you feeling threatened? I keep hearing "the hype machine" from java folks and I just wish they would go back to 1997 and realize that they were "the hype machine" back then. Is java fad? Far from it. But, Smalltalk and the recent crop of dynamic languages are not either. The important thing is to ask, "why is there hype around THIS technology?" instead of demoaning everyone's enthusiasm for it. I find that everytime developer's get excited, I start asking that question. The discussions are always lively and I walk away with a different perspective. We should all be learning from one another instead of bitching that the newest toy is not ours.

It's a big world. There's room for all of us. I wish everyone no failures and only successess this year. No matter what your technology choice is!


Monday, January 02, 2006

Dear Virgin and Thirty Seconds To Mars

I would love to listen to your new CD "A Beautiful Lie", but you have copy-protected it. I prefer to enjoy my music on my mp3 player because I have a plethora of choices at my fingers. But, you have prevented me from ripping my music to mp3 for my enjoyment. I only listen to music on my mp3 player and sure, I could rip it with different technology (like WMA), but why be different just for you? I have software that makes sure the volume levels between albums are consistent and I can not do that with your options. You've also made me feel like a common criminal. I never share my mp3s and buy every piece of music that I have on my player. So, I will not purchase any more of your CDs and enjoy any of your music. If I were you, Thirty Seconds To Mars, I would switch labels because I will never purchase any of your CDs while on Virgin.


Sunday, January 01, 2006

Encapsulation and Minimal Interfaces

In my previous post, I was writing about how I was using java's reflection API to make sure that my domain objects were conforming to the constraints of the Hibernate project. So, my objects could be persistable by anybody. At one point, I needed to know if a class was abstract (because then I know I culd't instantiate it) or final (because then this cuts down on the possibilities that Hibernate can do for proxies). Here's the code that I used:
    private boolean isAbstract(Class klass) {
return (klass.getModifiers() & Modifier.ABSTRACT) > 0;
private boolean isFinal(Class klass) {
return (klass.getModifiers() & Modifier.FINAL) > 0;

What does this have to do with encapsulaton and minimal interfaces? In the code, they are odds with one another. The minimal interface is to simply have the getModifiers() method, but I believe this breaks encapsulation. I'm basically being exposed to how modifiers are implemented in the object, Class. Should I care that modifiers are really integers? If I got rid of the getModifiers() method and replaced it with corresponding methods isAbstract(), isFinal(), and etc. Then, I would not have a minimal interface, but I would have proper encapsulation.

I'm not trying to respark the humane vs. minimal interface debate. But, I'm trying to point out that sometimes they can be at odds with one another. And when they are at odds, which one would you pick? Me? I will always pick encapsulation because objects should always hide their internal implementations.

I also brought this topic to show that by placing more value on a minimal interface. You sacrifice one of the most important attributes of object-oriented programming: encapsulation.


Metalheads Against Racism

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