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
Stephane Ducasse
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!
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.
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:
- Source Code Management provides historical information on code that could be problem sources. Think about it. If we see that one class is changed more frequently than any other class, then that might indicate a potential god class or at the very least a class that needs to be closely examined. Why does it change so often? We could ensure our design guards properly against unstable classes in the system and so that they do not effect the stable portions. You could test for rate of change (if there's a huge jump, then your tests could warn you. Maybe they shouldn't fail, but a warning color of yellow might be indictative that the code is correct, but there is a design problem.
- Metrics calculations can be useful for uncovering design smells. You could place thesholds in your tests for whatever metric calculations your team wants to track. If a certain threshold is passed, then a test fails. This makes you look at the offending code right away and stops design smells in their infancy.
- Method wrappers during execution of unit tests and verifying the results. For example, mark your private methods (via pragmas or method categories) and check if any code called it externally. This is just one simple example. I know there's more lurking.
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
Why XML?
So, I've been playing around with Ajax and rich client web stuff lately. I wonder why not just use Javascript to pass data instead of XML? I know there's frameworks to read/write serialized XML objects out, but why not Javascript? I found that Javascript was easier to traverse the objects and I was able to add behavior (of course, you need to be careful on pushes to the server to insure against malicious code, but I digress). So, I get the power of objects and not just data structures. If you're pulling information, Javascript seems like such a better match. It's a more natural fit for the client side and it's not hard to generate/parse javascript code (if it's just data as in XML). XML traversal is kludgy at best on the client side. Maybe an XPath framework would be nice, but why go through the trouble? You have a perfect representation that fits naturally with no fuss. I wonder if its another case of we-have-to-use-XML-because-it-is-portable.
Declarative Programming
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?
Well, there is already some help already out there. There are a few implementations of Javascript engines out there (for example, Rhino for Java, which I have used on several occassions, is excellent). Why not write your validation code in Javascript? You can then execute the same code on the client as you do on the server. We've just removed duplication, but then you must decide where to draw the line. And if you're not careful about what goes in Javascript and what doesn't you can end up in the same boat as before. But, running Javascript on the server for validation is a possible solution. But, Ajax will bring even more code to the client.
This is where I think DSLs and declarative thinking will shine. Why? Well, I can create a language that is intepreted on the server sid, and is used to generate the client side Javascript code. Tt will be more readable, faster, and closer to the user's language. Ruby and Smalltalk make DSLs a snap. I used a simple use of DSL for generating my Javascript code in my Agent program. I simply used polymorphism and exchange the real Agent object with one that generates the Javascript code. No duplication.
I think much like we have OO-relational mapping frameworks (and we don't have to deal with SQL in only limited contexts), we'll have server-client code mappings that will take care of the Javascript code for us. So, we can stay mainly in one language and not duplicate code. I've worked on a small Ruby framework to serialize Ruby objects as Javascript objects (it was very simple and just a proof of concept), but we also need to transfrom methods to Javascript as well (like the validation rules). A DSL will help in making that job easier. Much like in a OO-relation mapping framework, we make the distinction between storable/non-storable objects.
Ajax is simple to program, but I can see the complexity rising in any project of sizeable length. Much like we don't have to think about SQL with great frameworks like ActiveRecord, TopLink, Hibernate, and Glorp, I think a new breed of frameworks will emerge for Ajax that will make us not have to worry about Javascript as much. it's not that Javascript is bad (I love the prototype dynamic nature of it), but having duplicated code/definitions are the enemy here.
Of course, I wouldn't be suprised if people were not already working on them. I was thinking of playing with some implementations (for example, writing rules with blocks and using the rules for code generation of Javascript and intepretation on the server side). But, we'll see. It'll be a lot of fun to watch! Especially since Ruby On Rails already has Ajax support (but, I don't know how far they go). Rock on!
Well, there is already some help already out there. There are a few implementations of Javascript engines out there (for example, Rhino for Java, which I have used on several occassions, is excellent). Why not write your validation code in Javascript? You can then execute the same code on the client as you do on the server. We've just removed duplication, but then you must decide where to draw the line. And if you're not careful about what goes in Javascript and what doesn't you can end up in the same boat as before. But, running Javascript on the server for validation is a possible solution. But, Ajax will bring even more code to the client.
This is where I think DSLs and declarative thinking will shine. Why? Well, I can create a language that is intepreted on the server sid, and is used to generate the client side Javascript code. Tt will be more readable, faster, and closer to the user's language. Ruby and Smalltalk make DSLs a snap. I used a simple use of DSL for generating my Javascript code in my Agent program. I simply used polymorphism and exchange the real Agent object with one that generates the Javascript code. No duplication.
I think much like we have OO-relational mapping frameworks (and we don't have to deal with SQL in only limited contexts), we'll have server-client code mappings that will take care of the Javascript code for us. So, we can stay mainly in one language and not duplicate code. I've worked on a small Ruby framework to serialize Ruby objects as Javascript objects (it was very simple and just a proof of concept), but we also need to transfrom methods to Javascript as well (like the validation rules). A DSL will help in making that job easier. Much like in a OO-relation mapping framework, we make the distinction between storable/non-storable objects.
Ajax is simple to program, but I can see the complexity rising in any project of sizeable length. Much like we don't have to think about SQL with great frameworks like ActiveRecord, TopLink, Hibernate, and Glorp, I think a new breed of frameworks will emerge for Ajax that will make us not have to worry about Javascript as much. it's not that Javascript is bad (I love the prototype dynamic nature of it), but having duplicated code/definitions are the enemy here.
Of course, I wouldn't be suprised if people were not already working on them. I was thinking of playing with some implementations (for example, writing rules with blocks and using the rules for code generation of Javascript and intepretation on the server side). But, we'll see. It'll be a lot of fun to watch! Especially since Ruby On Rails already has Ajax support (but, I don't know how far they go). Rock on!
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.
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
Omaha.st
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.
Here's all of the details:
When: November 8, 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.
Omaha.rb
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:
| When: | November 7, 2005 |
| Where: | Panera @ Eagle Run Shopping Center 13410 West Maple Road Omaha, NE 68164 |
Subscribe to:
Posts (Atom)
Posts
