"COMPUTER POWER TO THE PEOPLE! DOWN WITH CYBERCRUD!" - Theodor Nelson
Tuesday, November 29, 2005
Agent Remote Control
I've posted a new version of my Agent Remote Control project. You now can not only output Microsoft Scripts, but it now also generates an HTML page that can only be run in IE (because it requires ActiveX). I went looking through the code and I was shocked. I took the source down off the site until it can be properly cleaned up. It was atrocious. So, I've been spending time cleaning up code. I fixed a lot of bugs as well. I'll put the source up later. But, for now, download the application and be prepared to lose a lot of hours laughing. If you want to know what Agent does, look at my quotes page in IE and you'll see a little character appear and talk. Remote Control allows you to script him.
Thursday, November 24, 2005
Dolphin 6 is a Reality!
If you didn't already know, click your way to Object Arts and take a gander a Dolphin6! It's finally here! Christmas came early. I'm so excited! Happy Thanksgiving today. Make sure to eat lots of turkey and play with the Dolphin...=)
Tuesday, November 15, 2005
Well, I found a slew of articles last night written by Stephane Ducasse. He is my new personal hero. Everytime I get to thinking about a problem, it appears that he has already paved the way for me. For example, my thoughts on metrics via source code changes, he's fully completed them with the article, Finding Refactorings via Change Metrics. I also learned quite bit on metrics from "Metrics, Do They Really Help?" It pointed me in several great directions to book. It's just incredible. His website is overflowing with great computer science research. I keep coming back and finding new gems everytime.
He's an active member of the Squeak community, author of several books (did I mention that they rock too?), and he maintains the Smalltalk book list. I'm so glad to have someone like him in my community. I hope to someday meet him in person and shake his hand. Until then, I'll keep reading. I've got much to learn! I would like to thank Stephane for all of his great work and being such a good mentor through his writings!
Monday, November 14, 2005
Alternative Methods of Testing
This was a topic of discussion at Smalltalk Solutions after Niall Ross' talk on concurrency testing. The floor was opened up for other methods of testing a system. Michael-Lucas Smith brought up how he used SmallLint (a tool that exposes a plethora of code smell symptoms) to prevent certain code smells from entering the system. I went on to explain how I used what I called "Source Code Tests". Basically, I make tests that check compiled code for forbidden method calls in the system.
It's a topic I've been thinking a lot about lately and I'm planning on presenting some of my thoughts at the next Smalltalk User's Group Meeting. Basically, I feel that testing is crucial to a successful project. Unit tests are great for finding errors quickly. Wouldn't it be great if we could use tests to help us find other problems rapidly? Michael-Lucas Smith's usage of Lint in his unit tests stamp out code smells before they even get started. I started to write "Source Code Tests" to stop the usage of APIs that cause performance problems from getting out of hand. It's worked great because it stops bad code from starting or continuing. What other ways could we possibly test? Here's some additional testing methods:
And that's just a few, I'm sure there's more. The point is to look at what problems would you like to know about early and fix? The earlier we find problems, the easier they are to fix. Anything that will help find code and design smells is a good thing. What other tools do we have now (like Lint and Metrics) that we could use from our tests? It's a fun topic to think about! Of course, I welcome any feedback because I want to know how I can not only better the correctness of my code, but my design as well.
Sunday, November 06, 2005
Is declarative programming going to become more important for the richer client web? I've been playing around with Ajax programming. It's easy, but one thing keeps coming up: the coupling of front and back-end. I see it as a possible source of duplication. It's not like it's a new problem either. I've seen several projects where the client and server validation code was duplicated. It's insane to write the same code in two or more languages! Why not just one?
Wording and Definitions
A common problem when you put two humans into a room is misunderstanding in language. Different backgrounds, perceptions, or outlooks give people different definitions to words. I generally strive to use common words in a project so that we can avoid some of this confusion, but it always seems to creep up. The thing that surprises me is it comes up at the weirdest times. Usually, in heated discussions when in a fever of disagreement, you find you were arguing over definitions. And not the intention of getting the goal accomplished. A relief comes over the room and consensus occurs. But, you feel like the time leading to it was wasted. If only we could have only come to the conclusion sooner!
What's the solution? Project dictionaries are excellent for this. Create a spreadsheet with the words of the domain. Write the definitions from the dictionary and the end user's perspective. And then stick to them. But, this only addresses the business domain words, what about everything else? For example, we recently had a difference of perception over the definition of the word, "collaboration". At first, I was shocked that we could differ on such a common word. But, the ensuing discussion helped me realize how better to deal with certain members of my team. I learned how to be a better team partner to them.
The rush of wasted time came over me again and I quickly brushed it off. I realized discussions of definition are not wasted time! But, opportunities to see how people perceive their world and to more successfully communicate with them. Sure, it's a long way to get to the point, but the journey is what is important here. What I used to think of as wasted time, isn't.
Much like the discussions of the project dictionary are good. Those long detours over definitions are good as well. But, the outcome is different. The project dictionary is an aid for understanding the problem, and differences of definition allow us to learn more from our team partners.
Saturday, November 05, 2005
It's time for the Smalltalk User's Group. It snuck up on me. So, I thought we could bring in our favorite pieces of Smalltalk code and willing to discuss. It sounds like more fun than we should be allowed to have. Bring your elegance!
Here's all of the details:
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.
It's time to hold another great meeting of the Omaha Ruby User's Group. We'll be discussing everything about Ruby. I recently wrote some Ajax code and I thought it might be nice to compare the "raw" way and the "Rails" way. So bring your favorite pieces of Ruby code and 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: