After almost three months of local project, which I intend to log sometime soon, I am back on the road again.
This time I have my Verizon national access card that allows me get connected to do things like writing this blog at the Oakland airport. I could request the extra battery but with only 3-hour travel time I doubt the weight is worth the benefit.
Next project is an ASP.NET application and have quite a few ThoughtWorkers on it. I am afraid that is as much as I am allowed to say. I would like to whine about the painful download/install process I have been through in order to run the application, but I don't think anyone, like .NET or not, would care.
This project is on a 4-10 schedule which means once I get myself comfortable with the code and my role, I will be able to spend only 3 nights in the hotel and sleep at home 4 nights per week. Not that I am tired of traveling but there is something to "sleeping in your own bed".
Tuesday, August 29, 2006
Monday, August 28, 2006
A Good Read: Eight Barriers to Effective Listening
Labels:
Communication
http://www.sklatch.net/thoughtlets/listen.html
Richard Watt hosted an OpenSpace session in the last HOD. I was thinking about checking it out at the time. But other things came up and I forgot about it.
I cam in the office today preapring for the next project and saw the printout at the printer. Figure I better grab a copy and blog it before that happens again. (Also need to buy "Getting Things Done").
Richard Watt hosted an OpenSpace session in the last HOD. I was thinking about checking it out at the time. But other things came up and I forgot about it.
I cam in the office today preapring for the next project and saw the printout at the printer. Figure I better grab a copy and blog it before that happens again. (Also need to buy "Getting Things Done").
Saturday, August 26, 2006
Tying Up Loose End - Cotta
Labels:
Java,
OperSource
So I have rolled off another project and I am going on the next project right away next week.
Typing up a few the loose end at the moment, since I won't be able to have a couple of weeks beach time like I did last time.
I have started with Cotta because this is most close to being ready. Based on the feedback and my experience with Ruby file handling, I have finalized the core API. Release candidate is now available. Even though I still prefer setting all the API right on the first release, my busy schedule just won't allow it. I think I'll release 1.0 and leave it like that, until I get a chance using it or get some feedback from the field.
Of course, SourceForge is done, so in the meanwhile, only the website is available.
More blog coming up with last project, and other loose ends.
Typing up a few the loose end at the moment, since I won't be able to have a couple of weeks beach time like I did last time.
I have started with Cotta because this is most close to being ready. Based on the feedback and my experience with Ruby file handling, I have finalized the core API. Release candidate is now available. Even though I still prefer setting all the API right on the first release, my busy schedule just won't allow it. I think I'll release 1.0 and leave it like that, until I get a chance using it or get some feedback from the field.
Of course, SourceForge is done, so in the meanwhile, only the website is available.
More blog coming up with last project, and other loose ends.
Tuesday, August 22, 2006
Why Lotus WebAccess is not My Favorite Webmail Client
Labels:
Interaction Design
I am on a machine that has 1.99GHZ dual CPU, 2GB of RAM, and 75GB of harddrive. Yet for every scroll up and down action in my inbox view, it sends a separate request. So even when I know the exact date an email was sent, it still takes forever to locate it.
And I noticed this is on the log out screen today:
* Secure: Delete all traces of my personal use of Domino Web Access and Web pages from this computer but keep program elements (boosts performance when next person logs on).
* More secure: Delete all traces of Domino Web Access and all other Web pages in the Temporary Internet Files folder.
Right... I understand what they are trying to do. But what's up with the "Secure" and "More Secure" notion? Apparently, the "Secure" is not so "Secure" after all when there is a "More Secure", isn't it?
And I noticed this is on the log out screen today:
* Secure: Delete all traces of my personal use of Domino Web Access and Web pages from this computer but keep program elements (boosts performance when next person logs on).
* More secure: Delete all traces of Domino Web Access and all other Web pages in the Temporary Internet Files folder.
Right... I understand what they are trying to do. But what's up with the "Secure" and "More Secure" notion? Apparently, the "Secure" is not so "Secure" after all when there is a "More Secure", isn't it?
Friday, August 11, 2006
Benevolent Dictator
Labels:
Project Management
This came up during a chat with someone while I was visiting the office.
This is a term that has its own history (http://en.wikipedia.org/wiki/Benevolent_dictator), but is now applied to a kind of management style for software development. In opensource development, Codehaus is probably the most famous for this management style (project despot). You should read "Codehaus Manifesto" if you want to understand it fully.
In Agile software development, the developers have (or should have) the absolute power on deciding how and when a business value can be delivered. While this brings lots of benefits, which we won't get into here, it does bring certain risks at the same time.
Different developers might have different opinion on design of certain part of the system, or no one have strong opinion over several sound solutions for the same problem. This is when benevolent dictator steps in, makes a decision in the team's place, and move on.
Of course, this is not nearly as easy as it sound. I did a little dig (very little, mind you) on my previous projects and pulled together the following criteria:
* The power should be used when necessary but ONLY when necessary.
* Any decision is a team's decision. Everyone takes the credit, everyone accepts the responsibility.
* Decision is not final in the sense that objections are noted and tracked, so that the wrong ones can be amended as early as possible.
* The title of "benevolent Dictator" is better granted.
At last, here is a PDF file that I have on my bookmark, which I think is related: "Agile Project Management.pdf"
This is a term that has its own history (http://en.wikipedia.org/wiki/Benevolent_dictator), but is now applied to a kind of management style for software development. In opensource development, Codehaus is probably the most famous for this management style (project despot). You should read "Codehaus Manifesto" if you want to understand it fully.
In Agile software development, the developers have (or should have) the absolute power on deciding how and when a business value can be delivered. While this brings lots of benefits, which we won't get into here, it does bring certain risks at the same time.
Different developers might have different opinion on design of certain part of the system, or no one have strong opinion over several sound solutions for the same problem. This is when benevolent dictator steps in, makes a decision in the team's place, and move on.
Of course, this is not nearly as easy as it sound. I did a little dig (very little, mind you) on my previous projects and pulled together the following criteria:
* The power should be used when necessary but ONLY when necessary.
* Any decision is a team's decision. Everyone takes the credit, everyone accepts the responsibility.
* Decision is not final in the sense that objections are noted and tracked, so that the wrong ones can be amended as early as possible.
* The title of "benevolent Dictator" is better granted.
At last, here is a PDF file that I have on my bookmark, which I think is related: "Agile Project Management.pdf"
Wednesday, August 09, 2006
Ask "Why Do You Ask"
Labels:
Coach,
Communication
As a traveling consultant working for a company pushing for agile, I keep on being asked for similar question repeatedly. "What do you do in stand-up?" "Why is TDD good enough to spend time on?" "What do you mean the velocity is 20 this week, 25 last week, and 18 the week before???"
Naturally, I trid to come up with the best answer based on the experience I had had, the books and articles I had read, the other conversation that I had had with other people, and the understanding that I had gained about the one who asked the question. Slowly, my answer to the above questions became bigger and bigger, with more details, more angles, as if I was getting closer and closer to the truth.
WRONG...
What I have realized in the past year, was that the best way to answer these questions, actually, are:
Here is a true case.
When I was traveling in China, I stayed late in the office one day to do some market research and spike on BuildMaster project. Another ThoughtWorker, who was doing some of his own thing, turned to me and asked "So what have you been working on lately?"
Since he expressed interest in DbFixture before, and that I knew he was on beach at the moment, I thought he was looking for something interesting to work on. So immediately I went on talking about the problem that I was trying to solve and the "grand" vision that I had with BuildMaster, Cotta and jBehave. I went on for 5 minutes (if not more) and realized none of them gained any interest. Going out on a limb, and out of a bit frustration, I finally asked the million-dollar question.
Turned out that he had an idea of starting an open-source project to help WebServices testing and would like to get me involved because of all the xFixture projects that I had been working on.
Granted, it was not exactly a straightforward question. Yet more and more I start paying attention to the motivations behind the questions rather than the questions themselves, and even sometimes observing the conversations others have.
And the rest is history.
I can now control myself much better nowadays instead of "blah blah..." for minutes.
Otherwise, I might as well say "42"
Naturally, I trid to come up with the best answer based on the experience I had had, the books and articles I had read, the other conversation that I had had with other people, and the understanding that I had gained about the one who asked the question. Slowly, my answer to the above questions became bigger and bigger, with more details, more angles, as if I was getting closer and closer to the truth.
WRONG...
What I have realized in the past year, was that the best way to answer these questions, actually, are:
Give a 30-second brief answer. Stop, and ask: "Why Do You Ask?"Different people have different situation, and are seeking the solution to different problem when asking the same question. In this case, giving a by-the-book answer, no matter how pragmatic or complete it is, does not necessarily solve that problem.
Here is a true case.
When I was traveling in China, I stayed late in the office one day to do some market research and spike on BuildMaster project. Another ThoughtWorker, who was doing some of his own thing, turned to me and asked "So what have you been working on lately?"
Since he expressed interest in DbFixture before, and that I knew he was on beach at the moment, I thought he was looking for something interesting to work on. So immediately I went on talking about the problem that I was trying to solve and the "grand" vision that I had with BuildMaster, Cotta and jBehave. I went on for 5 minutes (if not more) and realized none of them gained any interest. Going out on a limb, and out of a bit frustration, I finally asked the million-dollar question.
Turned out that he had an idea of starting an open-source project to help WebServices testing and would like to get me involved because of all the xFixture projects that I had been working on.
Granted, it was not exactly a straightforward question. Yet more and more I start paying attention to the motivations behind the questions rather than the questions themselves, and even sometimes observing the conversations others have.
And the rest is history.
I can now control myself much better nowadays instead of "blah blah..." for minutes.
Otherwise, I might as well say "42"
Monday, August 07, 2006
Why Eclipse is not My Favorite IDE
Labels:
IDE
Need to find a way to exclude certain folders in my Eclipse Ruby project so that it does not show up in the Open Resource dialog. Searched on line and find this in Eclipse bug database:
Maybe it is now a good time to reconsider the investment in Komodo
---
Update: Thanks for Robert for pointing this one out and I stopped pounding my head (a lot less at least):
apparently you can right click on the directory, select "Properties", and check the "Derived" check box, which will do the trick.
There is now technology in place to support exclusion filters in the workspace.
You can create an exclusion filter in I20060110 by creating a linked resource
to the "null" file system. The linked resource will hide any file system
resource with the same name, thus acting as an exclusion mechanism.
Maybe it is now a good time to reconsider the investment in Komodo
---
Update: Thanks for Robert for pointing this one out and I stopped pounding my head (a lot less at least):
apparently you can right click on the directory, select "Properties", and check the "Derived" check box, which will do the trick.
Loading All Test Cases in Ruby
Now that I finally understand that '$:' in '$:.unshift' is a variable reference, and that 'require ...' is literally a method call loading the file, I realized why there are no utilities in ruby to load all the test cases for you:
create a file 'ts_all.rb' at the root directory of the test with the following content:
# test/unit module that will pick up all loaded testcass automatically
require 'test/unit'
# find where the root directory of the tests is
root = File.dirname(__FILE__)
# do a name matching and iterate through all tc_*.rb files
Dir.glob("#{root}/**/tc_*.rb") do |file|
# load the file (assuming naming convention)
require "#{file}"
end
That is it! Executing 'ruby ts_all.rb' will just run all the tests.
create a file 'ts_all.rb' at the root directory of the test with the following content:
# test/unit module that will pick up all loaded testcass automatically
require 'test/unit'
# find where the root directory of the tests is
root = File.dirname(__FILE__)
# do a name matching and iterate through all tc_*.rb files
Dir.glob("#{root}/**/tc_*.rb") do |file|
# load the file (assuming naming convention)
require "#{file}"
end
That is it! Executing 'ruby ts_all.rb' will just run all the tests.
Subscribe to:
Posts (Atom)