Dvorak Follow-Up - Why I Think It Is Great

Two weeks into trying out Dvorak hardly makes me into an expert on the keyboard layout, and chances are that my opinion about it will change as the time go by. So I was trying to focus more on how I managed to learn it rather than any conclusion that I have drawn.

However, I realized that since I already made the comment that "It is great", I'd better explain it in the whole aspect, even though it is just a snapshot of what I am thinking and it might very well change.

I think it is great because I am amazed at how easy it was to learn. With vows at the left hand home row, it somehow makes it very easy to remember. Most of the common key combinations stay on the home row, which makes very easy to type. Here is a good example (he calls it Dvorak poetry) that Alex sent me:

Shane Duan nodded to his sis as he situated his sedan in the shade

If you want to know what it feels like, here is the key this sentence mapped to on a QWERTY input:

:jald Hfal lshhdh ks jg; ;g; a; jd ;gkfakdh jg; ;dhal gl kjd ;jahd

I think it is great because in Dvorak, you can type the whole sentence without your hands leaving the home row. And I believe that is the case with Dvorak that you stay on the home row most of the time. I think that is the main reason why it is so easy to remember. You just need to learn the home row and you can pick up the rest as you go.

No I am not ready to commit my life to Dvorak. The website that I have referred to (http://www.mwbrooks.com/Dvorak/) has very though references on both side of the story, especially here (http://www.mwbrooks.com/Dvorak/dissent.html). And this link (http://www.utdallas.edu/~liebowit/keys1.html) referred form this link in the comment, is making a very compelling case. However, just like the author said: you don't have to believe either side of the argument. I am hoping through a first hand experience, I can make a convincing case either way.

Of course, the speed will always be the hot topic here. However, from what I have concluded so far, I am afraid there is no easy answer. As a fast typer, I felt that the speed comes from not only the ability to map a letter to a key without thinking, but also that to map the key combinations. What this means is that probably there is no much difference between the inputs as far as a fast typist concern because he or she will simply just remember the same key combos. If that is true, I might be the wrong person to try Dvorak, since I type 8 hours a day for living.

With that being said, I think that a casual typer probably would benefit more from Dvorak input. However, since all the keyboards you can see during everyday life are labeled with QWERTY, one tip to learn is not to look at the keyboard. Ironically, if you can do that, you are probably already a good typer.

I also have to be honest with you. I am a geek, and I love trying different stuff. Just the fact that I am able to say "I tried it for a year and I think..." rather than "I read it on this website one day that it seems..." is already something worth doing for me.

The last thing is really rather subjective. I never had any good feeling for QWERTY typing. I simply do it because it was the only choice. However, I somehow enjoyed Dvorak. It could be the combination of the fact of typing mostly on home row (With kjd as the keys for "the" just makes more sense) and the fun of trying something new.

Two Weeks Into Dvorak

It has been two weeks since I have switched to Dvorak and I really think it is something worth writing about.

The topic of Dvorak just came out of a lunch conversation. I was talking about the fact how sometimes we keep doing what used to useful without realizing that the circumstances have changed. A small example was how Java IDEs forget that maybe the traditional windows mapping doesnot apply anymore (who opens a file through file chooser, or print the code anymore). And IntelliJ's found of F keys making its useful features much less accessible, and that by some miracle Eclipse made the right choice of having all ctrl+alt+key reserved to refactoring related actions.

Then the topic switched to even the key board layout tha comes with every computer was not designed to make your typing fast and easy and how I heard of another kind of keyboard that is supposed to do just that. As it turned out, Adam knows exactly what it is because he has tried it before.

With Adam's reference, I was able to enable my laptop (window XP) with Dvorak keymap and find the related sites. After reading through it, I figure I'll give it a try.

I am a fast typer. I got my hands on a type writer and a typing training book when I was a kid. So I literally learned typing before I even knew all the words that I was typing. Then in graduate school for a year I got addicted to IRC and another year on text-based MUD game, both of which require intense typing in that the faster you type the more fun you can get out of it.

So you should believe when I tell you this: Dvorak is great!

I started with a online tutorial (http://www.gigliwood.com/abcd/). I do about three sessions per day, 15 - 30 minutes per session (when I am getting tired or bored and staring mixing keys). At work I still have to use the QWERTY because it would be too slow otherwise.

After a week, I felt that I can finish the lessons of the home row without problem, but my training on the other rows is not making good progress. I felt that it is because my old habbit and this half Dvorak is not working togethir. Since one major advantage of Dvorak is supposed to be the fact that your fingers stay on home row most of the time, I have decided to swithch to it full time, with my Fitnesse blog as the first target.

Well, that weekend was not too easy. It is as if I am learing to walk again. For a while I was even wondering if it is really worth the effort. Two-day is hardly a long enough period to give up, so I just lowered my target on how much I can write in a hour so that I won't be too frustrated. I also noticed that most of the time I am having trouble because I am too used to the old way that for key combination like "ing", "tion", or even "th" my figer will go without even my brain had a chance to process them in Dvorak context. So I concentrated on several key binding that is giving my trouble.

Now after two weeks, I would recommend anyone who wants to learn typing to try it out, AFTER you have read the pro's and con's on the websit and make your decision.

Memorial Weekend - A Sample of Quality of Life with XP

First of all, the criteria of the quality of life are rather subjective. If you do enjoy working on your project at home, then all I can say is that you are lucky. For me, there are so many other things besides work and software engineering that I am just too interested in to give up.

One good thing that comes with XP is that you have the control of your time. Because you always know how far you are to finish the project, your project management is fairly predictable. As a result, you can deliver the project on time, and your personal life is not affected.

So, even though my work is still busy as hell, I was still able to put it behind and enjoy my long weekend. For some person it might be really obvious, but my old buddies at JBuilder team would only know too well how obsessed I can get.

Without further a due, here it is:

Stinson Beach Hiking
This is by far the best hiking place that I have been to around bay area. The reason is simple: This is the only place that you can hike on the beach, on the grass field, and the woods in one afternoon.

Brentwood Cherry Picking
Eat all that you can pick, and buy home the ones that you cannot. Just make sure that you need to pace yourself otherwise your stomache might not be able to take it.

Ninja Gaiden
I don't understand why they want to associate this game with Dead or Alive 3, because it is totally different kind of game. Besides the normal similar quest that is quite similar to Final Fintasy X, it requires the player to analyze the enemy's attacking patterns and come up with counter measures. The last big boss was quite disappointing, though, because I just chased him around like a mad man and that killed him.

Texas Hoedown
Yes I also do not believe that there is luck in poker. But, I do believe they should put the number on those chips so that I don't have to remember them.

Joy and Pain with Fitnesse

(This blog is entered using Dvorak input, which I am going to write a blog about after I either master it or give it up)

Last Wednesday (May 18th.) I gave a presentation to the BayXP (http://groups.yahoo.com/group/bayxp/) titled "Joy and Pain with Fitness". I am putting the presentation material here, and try to explain the examples.

Joy and Pain with Fitnesse

Presentation of what we have learned during our usage with Fitnesse, an acceptance test framework, and how we have benefited from it. This presentation is intended on purpose to avoid raising philosophical issues, software engineering methodology, or what the correct usage of the Fitnesse should be. Rather, it concentrates on the retrospective of our experience with Fitnesse. It is more important to understane the reason behind

Overview
Fitness' own description can be found at its website "OneMinuteDescripiton", with the following in particular in our project:

1. Fitnesse is an acceptance testing framework. Its targeting audience is not only the developer but also the user who is going to write and run acceptance tests, like domain experts, QA, manager, etc. (And it has done a great job to achieve this goal).
2. Fitnesse is written in Java, which makes it easy for developer to assist the acceptance test writing.

What We Have Achieved
Just like an application product, we slowly developed a set of Fitnesse fixtures that allow everyone on the team, including the QAs and BAs, to set up the system state, simulate the events processing, and assert the end state of the system by writing XML document assertions and database assertions.

In order to document how to use the fixtures, we also created a "Fixture Tutorial" page, which contains all the fixtures that are available, with detailed descriptions. Each page is a test by itself, which means that people can change them and run them. This is very similar to the ones on Fitnesse page, e.g. JdbcSample, except ours are related directly to our domain.

How Fitnesse Works
The following is the outline of what we have learned in our project. It is quite possible that there are useful features that we have not discovered so you should make sure to check out Fitnesse website.

1. Fixtures are loaded through reflection by very simple naming convention. For example, if the header of the table is "Insert Person Data", then the class "InsertPersonData" will be loaded and instantiated. The packages in which Fitnesse should look for the classes can be specified through "Import" fixtures.
2. A page called "SuiteSetup" will run at the beginning of the suite and will not run for a single test. A page called "SetUp" will run at the beginning of each test all the time. The same rule applies to "SuiteTearDown" and "TearDown".
3. The following are the four most useful features to us in this project:
1. Column Fixture: The column name without the question mark is a public field in the fixture that Fitnesse will set value to. The column name with the question mark is a public method in the fixture that Fitnesse will call and compare to the value in the table.
2. Row Fixture: Great for doing assertion on a set of data. For example, if you want to assert that the person has three specific phone numbers (555-2222, 555-4444, 555-9999), you just need write the Fitnesse page with these numbers and implement a row fixture that simply returns all the phone numbers this person has. Fitnesse will do a fantastic job of comparing these two sets and show you the difference.
3. Action Fixture: The first column of each row is mapped to a public method. This is especially useful to run a sequence of actions and check the result between the actions. This fixture is being utilized by jWebFit.
4. If you use standard fixtures, all data type conversions are handled seamlessly. As explained in "DataTypesInFixtures".

Why We Love Fitnesse
We believe that tests are good and that we as XP and Agile developers should do everything we can to encourage developers to write unittests and QA/BA to write acceptance tests. In this project, we would never have achieved this level of tests without Fitnesse. To quote from our QA:

It is great to have a tool that allows me writing tests for our system. I have been quite uncomfortable with matching logic. With these many tests and assertions (over 23,000) I am feeling a lot better now.

Because it is easy and fun to write test, many things just follow naturally. Stories are written with test in mind, making them easy to verify. Acceptance tests are also written early, sometimes even ahead of the iteration. Consider this is the team that didn't know what a story card is and didn't have any automated tests, we are really satisfied with the result.

For BA and QA, or any non-technical member of the team, Fitnesse is great because it has very clean UI with neat user interaction design. It is much less itimidating than a programming language. You just feel that you are writing a Wiki page with tables that are runnable, instead of a program with limited way of writing comments. The pages are much more readable than the JUnit tests.

For developers, there are already fixtures helping them writing unit tests. With Fitnesse written in Java and loading fixtures through simple reflections, it is quite easy to hook up the Fitnesse with the existing testing fixtures, thus greatly reduces the code duplications athe cost of the Fitnesse fixtures.

Why We Hate Fitnesse
I believe it is as important to explain the struggle we had with Fitnesse as well as the success, because this way the reader can learn to use this tool effectively. It is also possible that in the limited amount of time and with project development to bring business value as our ultimate goal, we might not have learned the way that Fitnesse was originally designed for. And I'd very much like to be directed to the right direction.

No matter how many times that I say it is very easy to write Fitnesse, you still have to spend time writing it. Also because it is not the developers who write and run the Fitnesse, you get the same issues that you have for any project. What this means is that developers are taking requirement request. It is only natural that you want to help, and the better a developer you are, the more likely you are going to put down your story and write fixture instead. Before you know it, your velocity is down and you are only overwhelmed with more and more fixture requests. There is another member of BayXP who encountered the similar problem.

The target audience of Fitnesse are the none-technical member of the team so it is doing its best job to achieve that. This achievement, however, comes with the cost of the usability for developers. A developer who has been infected by TDD is a developer who has been spoiled by JUnit. With Fitnesse we have to again and again wait patiently for the suite to finish. While waiting, we have no idea how many have been run, how many there are in total, how long it is going to take. When there is a failure, we have to wait for all the tests to finish before we can see the report. (You can copy the URL and open it in another browser window but then you have to worry about running two acceptance test processes at the same time on the same machine, which can give you some trouble sometimes.) Even with the report, you still cannot open that line of code with one click. And it is a lot harder to put breakpoint at the place that you want in debug a problem.

In the spirit of Continuous Integration, we run some of our Fitnesse tests through CruiseControl. The best way we were able to figure out is to launch the server, then use the Fitnesse runner connecting to it. With the way Fitnesse is implemented, we ended up with a server thread serving the HTML, a client thread reading it, and another thread monitor the communication between these two. Somewhere it is not managed correctly and it is causing the process to hang. We spent a lot of time trying to figure out the reason but this problem only occurs on one of the Solaris machine (which happened to be our release machine), occurs 10% of the chance on our Linux machine (which is our build machine) and never on the windows machine. The closest thing that we found online is this post about how an earlier similar bug was fixed. We moved to an Linux machine for the release and bounce build machine every now and then, and moved on.

Fitnesse also tries too hard, in my humble opinion, to be everything. Rather than a simple webapp, it is a stand alone web server. This means that you have another server to manage, another account to manage and another port to open. It also has its own Wiki engine so it is another set of rule to remember (after played with 5 different rules among Wiki, Twiki, Confluence, Rubywiki, one really gets tired.) Fitnesse dose not extend JUnit framework. The whole suite is actually run as one test, which means memory will increase as the test is running because of the HTML page.

Patterns
As we work with Fitnesse, we have developed the following patterns that helped us to use it successfully.

Just like any product feature request, every Fitnesse fixture request needs to be considered and discussed. We include them in our iteration planning meeting, we estimate them, and we pair up to implement them.

As we develop the fixtures, we write the tutorial pages first, which serves as our tests for the fixtures themselves.

Fitnesse pages are saved in their original format in TXT files. We launch the server with the correct arguments so that it does not manage the history of the pages. Then we check the files into our version control system.

For each project, we use one singleton class to manage the data that we want the fixtures to pass to each other, and make sure that all fixtures are stateless. In this way, the fixtures can stay simple and we were able to optimize the tests to make all the test run under 5 minutes.

For each project, we designated one suite as our acceptance tests area. Once a tests pass, we move it in there so that it never fails. In this way, the QA can feel free to write any tests they want and still can check in.

Always remember, it is nice and cool to do everything, but it is worth the effort only when the benefit outweighs the cost. We didn't have Fitnesse tests for a project that involve Peoplesoft because it uses views that are oracle specific. We resort to jWebUnit tests for another webapp because it was not as easy to use jWebFit (However, with the helper classes that we developed later on for web tests, we are taking another look at it to see how much it would cost now. The QAs is getting a hang of automated testing and starts feeling bad about not able to write them for Web apps).

References

• QA: Quality Assurance
• BA: Business Analyst role in a development team. (http://www.xprogramming.com/xpmag/BizAnalysis.htm)
• Fit: The framework for integration test that Fitnesse is based on (http://fit.c2.com/)
• Other nice tools for web testing
• Watir: http://wtr.rubyforge.org/
• Selenium: http://selenium.thoughtworks.com/ (A movie demo)
  
• Samie: http://samie.sourceforge.net/

ThoughtBlog

Adewale Oshineye sent me an email because there was a link from my profile page on ThoughtWorks linking to this blog, to ask me if I want to add mine to the ThoughtBlog. The reason that I have not done it is because I want to start publishing this blog only when I really know what kind of blog I am going to keep here, or even if I think it is worth it to keep a blog about my experience in ThoughtWorks.

But I figure, help is already here it really does not make sense to turn it down so I replied yes. Then I figure it is time to subscribe to the blog feed to see what my fellow ThoughtWorkers are writing about, especially with ThunderBird it is so easy.

So already I have learned something new today! I thought I have known all that is to know about writing assertions (assertEquals, assertNotEquals, assertTrue, assertFalse, simple, eh?). Boy was I wrong. Joe's blog "Flexible JUnit assertions with assertThat()" sure opened up my eye.

When I was working for JBuilder, I wrote a test framework for unit-testing some part of JBuilder modules. When a test fail, it is always desirable to see as much information as possible in the error message regarding information like project configuration, run configuration, etc. However, JUnit requires you to provide a message before the assertion happens, which means that all the tests will need to spend a lot of time constructing the messages, even though they might not be needed. So I wrote this LazyAssert that only constructs the message if the assertion fails, and ended up duplicating a lot of Assert APIs. I was quite bugged by that result but concluded that there was nothing I can do.

And now I know the right way.

My hats off to Joe for sharing it with us. And again to my fellow ThoughtWorkers.

Update of an example:

Check this out:

before:

junit.framework.AssertionFailedError
...(Click for full stack trace)...
at com.company.product.person.dao.jdbc.JDBCAffiliationDAOTest.testInsertAffiliation(JDBCAffiliationDAOTest.java:92)
...
at org.jmock.core.VerifyingTestCase.runBare(Unknown Source)
...

after:

junit.framework.AssertionFailedError:
Expected: timestamp is after 2005-05-16 15:21:34.871
but got : Mon May 16 15:21:34 PDT 2005

...(Click for full stack trace)...
at com.company.product.test.BaseAsserts.assertThat(BaseAsserts.java:31)
at com.company.product.test.BaseAsserts.assertThat(BaseAsserts.java:23)
at com.company.product.person.dao.jdbc.JDBCAffiliationDAOTest.testInsertAffiliation(JDBCAffiliationDAOTest.java:93)
...
at org.jmock.core.VerifyingTestCase.runBare(Unknown Source)
...

Fellow ThoughtWorkers

One thing that I found different working at ThoughtWorks, are the fellow ThoughtWorkrs. Here are three examples:

Names
I am the kind of person that cannot remember people's name unless I get to know them personally. So even though I greatly enjoyed the book Patterns of Enterprise Application Architecture, I only know the name of the main author Martin Fowler. Well, after working at Yabe project, I picked it up one day again to look up a pattern. Guess how surprised for me to find out that of the people that I worked with, three are on the cover (David Rice, Edward Hieatt, Robert Mee). Even though only Dave works for ThoughtWorks, I think this still shows that this company is well connected.

Arguments
ThoughtWorkers are all opinionated and love a good argument. Someone told me this the first week that I joined, and I have seen it again and again. I think this is good because it will bring out the best from all sides so that we can always think of the way we look at things or do things. Of course, I can understand that it is not for everybody, even though I enjoyed every argument.

Humorous
Here is a good example. During a discussion about the practical use of loosely coupled architecture like web services, EJB, or CORBA, Dan North made the following comment that cracked me up:

You mean you don't use CORBA?? Are you mad??

How on earth do you instantiate an object without first looking up a Factory Factory using IIOP to register as a Listener for a Factory to call a Factory Method via reflection, if you don't have CORBA?

Bloody amateurs.

What is Wrong with This Code

Managing and assisting a project development is more and more interesting to me nowadays. However, from time to time, I will run into some code that I think worth documenting.

What is wrong with this code in a test case:

public void testShowAddressInvalidCountryCode() {
 DomainError e= ErrorMsg.AddressInvalidCountryCode;
 String msg = ErrorMsg.showErrorMsg(e,new DomainErrorValue(ErrorMsg.PERMANENT_ADDRESS));
 assertTrue(msg!="No error msg");
 System.out.println(msg);
}

If you don't see why, let me explain:

• Don't use negative assertions: Asserting two things not equal is most error-prone. If you assert that a return value NOT equals 0, for example, chances are that this test will still pass, even if a bug is to be introduced in the method making it return 6 instead of 5.
  
• Don't use instance comparison: If the method decide to create a new copy for return object, then it is impossible to test. For the example here, if the method innocently construct the message "No error msg" instead of returning the constant, the instance check will render useless.
• Don't do System.out during test: This will pollute the output in the console and make it useless. If it is anything need to be verified, verify it with assertions. ASH project went a little to the extreme but it has very sound reason.
• Do test-driven development: Code like this is most likely a symptom of lacking test-driven development.
  

Happy Apile Fool's Day

On this day, there are two things that I want to mention. Normally I stick this blog to my working experience, but I figure everything has an exception...

GMail bumped up everyone's storage! This is one company that keeps reminding me that you can make things better by making things right. They keep on surprising me in a good way and I just love this company more and more. As a matter of fact, I would have worked for them, if their HR were not so slow on setting up interviews (that was an interesting experience last year, switching my Google HR contact three times in two months), that I ended up running into ThoughtWorks, a company that I should have been working for since year 2000. Even though my job in JBuilder was a great experience, I am sure I can do much better in a company like ThoughtWorks.

ThoughtWorks name was mentioned in a April Fool's webpage (PaiOn Chair). I asked around and didn't hear anyone knows the folks in Cenqua. So if that is the fact, this is a good sign that we are being regarded as THE XP shop, a name that everyone is building for.

So many things to do, so little time

My blog is really falling behind, yet I have little time to do catch up. There are so many things on my plate right now that I think I should just pick one, focus on it. I am seriouse. When I cannot even find time to play "Enemy Territory" in a week, I think I am trying to juggling too many balls.

Work at the client is busy as well. We have extended our work here until the end of May, which I think is very nice. It was sort of a hard deadline that we will only be here until the end of March, and we have been working hard on the transition. With our work extended here, we can finally see the product gets release and deployed rather than having to just put faith in ourselves about the successfull of our enablement.

As part of the XPE project release, and following the book Pragmatic Project Automation, I am starting building a release script in Ruby. (Ruby is a language that I have grown more and more fond of, BTW). I figure I might as well make it generic enough so that I can use it for other projects. So I have created a rubybuilder (or Build Master) on ruby forge (http://rubyforge.org/projects/rubybuilder/). Need to do some inital check-in's of the source code and the website setup.

Another project that I need to work on is the jbuilder-opentool project. That is because I have found Eclipse more and more annoying with each and every day. I don't care what people say, this is one product that just never failed to surprise me in a bad way (instead of like IntelliJ, which always surprises you in a good way. I am too familiar with JBuilder to be surprised either way). If I can just create an opentool that allows me read the Eclipse workspace and project, I will be able to do something useful things with JBuilder, starting with profiling.

Talking about profiling, another item in my list was the performance of the webapp that we were building. Somehow it just hangs whenever trying to load from database. Finally with the DBA's help, I find out that if you use "setLong" instead of "setBigDecimal" in prepared statement for a numeric column that is used for search, the index will not be used, rather, the query will simply scan the table. Converting a long to a BigDecimal is a bit hassel, so I settled for changing the query to convert the parameter using "convert" function in sybase.

On the last note, I just noticed (Thank you WebPastie, great job Bill!), that if you search on google with "Shane Duan", the first page is all mine, different stuff I submitted dating all the way back to my start-up days. I supposed an English name "Shane" with a Chinese "Duan" is an unusual combination for a name.

Anyhow, this post barely scratch the surface of what I have been doing presently, more coming up. Not this weekend though, because the snow in Tahoe is too good to miss!!!

XP Practices in Use

So we have an opensource page built. I don't have something that I am very proud of (http://opensource.thoughtworks.com/people/shaneduan.jsp) yet, but this is still a good start. Adam, Paul and I have some good idea from our current project about writing some library to help writing testing about database related library. We still need to sort out the detail but the idea is to follow the pattern that we have so that we can run acceptance test locally against HSQLDB, and have cruisecontrol run them against the real database.

It seems that it helps by writing down my thoughts and experiences as I encounter different issues. So even though I originally meant this blog to be what I have seen and heard among fellow ThoughtWorkers, I am going to writing down what I see and hear in the projects that I work in as well.

Ping Pong Pattern in Pair Programming
Adam mentioned it before and we tried, my experience was not exactly great, because sometimes you just need to grab the keyboard because either suddenly you are in an area that you know better, you see a pattern that you want to apply to some code you wrote earlier, or you simply want to drag your partner out of the hole he or she starts digging. Either you break the pattern start coding yourself, or try to direct your partner what to write (which can be really frustrating for you and annoying for him/her). Or sometimes while fixing a test, you notice that you want to touch another class. So do you write a failing test for that class and fix yourself, or let your partner fix it, and come back fix the test you are trying to fix? My experience has always been, if something does not feel natural, stop it, if it is something that you have to keep reminding yourself, figure out why and see if it is necessary. (Yes, test-driven development can feel that way but now I cannot imagin not doing that. Well, JBuilder opentools can be an exception, but I am working on that).

However, it worked surpringly well yesterday.

It is a new area that two developers worked on. One left for vocation so one developer knows the code. Friday morning, we have three stories that we want to start on, all related to the same area. So instead of pairing, we did 'triple-paring' for a couple of hours on one story (Luckily, mine. :D). Since it was not clear how to do it, we decided to ping-pong (or rather cutthroat). And it worked very well. I noticed that we are more focused, and I don't have to keep pulling the other people's leg by asking them to write test first. And we finished rather smoothly.

So my conclusion is, pair-programming works best of two developers are on the same level, and are both disciplined on test-driven development and agressive refactoring. Ping-poing pairing works best when at least one of the developers are still yet to be fully converted. Now that I have written it, it is a little like staing the obvious.

Stand-up Token
When we started this enablment project, we introduced stand-up meeting. So sometimes people are too shy to speak up, or the conversation can drag. Roben brought in a toy ball as a stand up token. A person can speak only when he/she has the ball, and tosses it to the next person once he/she is done. It is another thing that I have heard and never figured out how it helps.

It turns out that having a ball tossed to you does have a psychological effect on you. People speak louder and clearer. Even though we didn't impose the rule that you have to ask for the ball in order to speak, people do feel a bit guilty to strike a conversation without it. Instead, we write topics on the white board and get to it right after the stand-up, which is exactly what we should do.

Role Hats
No I don't have a good experience with this one, yet. But I wonder if it is worth it to introduce a role hats. Lacking business analyst is starting to taking a toll, I think. More and more often we ask around what is the whole picture of a certain feature, because developers implemented them by implementing one story after another, and the QA tested them by writing one acceptance after another. We are using Confluence to put support document, however no one has any incentive to keep them correct (that is right, those documents we have sometimes do not match the old code we see).

Early Deployment

I read about early deployment in XP, I believe in early deployment in XP, still I didn't push it and now I am a little stressed out.

This is a project that we have decided to rewrite part of the functionalities, because of the crazy dependencies I mentioned in last several posts (which is, like, half a year ago). We figure, we are just writing new Java files. We are still going to create one jar file for which the deployment and install script will use. So at the beginning of the project (one month after it started), we did a manual deployment as a proof of concept, rather than focusing on making sure that the existing script works well with it, and then forgot about it.

Now it is time to deploy to testing server and making sure that we can do it easily (one click deployment). I started look into the existing deployment script. Then I realize that it makes some assumption and has to be changed to accomendate the changes we have made.

For one thing, the development environment here used to be Unix box with VI editors. So the CVS modules are really small, of less than 20 files. Each module has a build file that will update library (similar to Maven process), compile, archive, and upload the resulting jar (with build number at the end of the file name) into a central AFS directory. This leads to a very messy building process. For example, if module A depends on module B. At a point of time, a-1.4b100.jar is built using b-1.0b22.jar. And now you want to debug why the product does work (for release fix, for example), you will have to check out module A by its tag "ant-v1.4-b100" and check out module B by its tag "ant-v1.0-b22". Try some fix in B, run the build, upload the jar with the newer build number. Then you need to change the build number for b.jar in the build.xml of A so that the right jar file can be pulled during the build. Then run the build of project A.

Still with me? Now imagine module A depends on not only b-1.0b22.jar, but also c-2.5b23.jar, d-1.0b2.jar, e-1.5b2.jar... If that is not bad enough for you, c-2.5b23.jar can be built upon b-1.0b08.jar, in turn. Now what do you think of that?

Now that we want to encourage refactoring and usage of a real Java IDE (which is more than I can say about Eclipse). We introduced several main projects, each one contains the source directories of the existing modules so that we don't need to move files around (mainly because of CVS). However, having observed how bad it can get, we decided to build everything off the head. So we have one project called "unified" which is where the common library classes go, and several other projects depend on it (3 so far). So when we build, say, project document processor, we want the build script to call to unified build file to test and build the library jar first, then use that jar the compile the current project and run the test.

However, changing the deployment process is out of scope for this process, so we still want the current release script to work. But now that we need to upload two jar files (library jar and the project jar) rather than one, the exiting script has to be modified. And you know how tedious it gets writing scripts. So before I know it, it is already the end of iteration.

So, early deployment, get it out of the way, even if you think it is simple.

Office Friday

I did not realize the importance of office Friday until we did it last week. Last time we did it, I was working in the office so it was no much different for me, well, plus that I was crunching on the deadline to fix something so I did not find enough time just hang around in the afternoon.

This time I worked extra hours on Thursday and went to work early on Friday, so that I can take the afternoon off and went back to the office. Meeting other people in the office that have been on the road was surely fun. And it was defenitely good to chat with Dave and Scott again. I think enablement work does wear you out slowly because you have to keep teaching other people. Besides patience and money you don't really gain much. I guess one can also learn how to deal with badly designed code and old code but it defenitely is not as pleasure as working with another person who is familiar with XP and have a stimulating conversation. I am not saying the people at Drofnats are dull, it is just that repeating and explain the things that I have taken for grantetd for the last three years is really not all that exciting (seeing the delight in the deveopers' eyes was rewarding, though).

What's up with CruiseControl

The tests cannot run in IDE anymore, again!! The only thing that I can think of is that people just don't use IDE to run tests. Honestly I think this is very wrong. I'll need to send out an email to see how they are using the IDE.

Sent out email and there were no response, go figure. Although the status text is fixed and now it really shows the real status. Just a 'rebuild' button then I am all set.

A bold move and a change in direction

Everybody (well, I was singled out so I had to move along) took a bold move. Rather than spend all the time to sort out the different versions of the jar files and figure out if it is safe to upgrade the dependencies, we have decided to just put everything under one project.

The pro: Now we have the project under the parent directory of the source, rather than using links in Eclipse, we don't have to explain to others why sometimes you need to commit "api" project and sometimes "person" project. A simple set up defenitely save us a lot of time for communication. We now can refactor/rewrite the code using IDE, rather than dealing with each unit test for each class.

The con: The risk. Nobody has any idea what this blind upgrade would bring. However, since this project does not look too complicated by its own business logic, rather its complexity comes from the complicated build/deployment process, we are hoping that what we did won't come back and bite us down the road. Actually, I think we are betting on it.

On the other hand, this is not a decision that made by ThoughtWorkers, rather Wendy is quite on board with this. So if the customer is aware of the decision making and the risk taking, I don't think it will get out of hand.

A change in direction

We were going to slowly refactor the code to be cleaner design. However, after Clinton taking a look at the code and from his previous DAL experience, he suggested that it is actually easier to write another framework, and start moving the existing DAOs over. So rather than change the code in registry or newregistry, we are going to move code over to the new registry3 package that he is writing at the moment.

It is interesting to see how their developers are getting excited over this "framework writing". Clinton is pretty good at test-driven devleopment so I heop in time they will learn that the real value is in the way that he develoes this code, rather that the code or the diagram that comes out of it. Diagrams are nice only when they are not taken literally.

Adam and I are focusing on the tracer tests. I am really glad that he is also doing this because I think this is a safty net that will help us understand how the registry is supposed to work. Rewriting implies that we need to understand all the requirements that the current registry meets, and we DON'T actually have those. They are in the head of multiple person here. We are getting more and mroe information and we need to track them with story cards, however there are still a lot of unknowns.

Bringing in Business Value?

We have been working with the developers there on writing more and more unittesting coverage. However, now I am thinking that we probably should turn around and start writing acceptance test.

Talked to the QA on Friday and boy was she streessed out. They don't have any automated test. What's worse, they don't even have a testing script. She has an Excel spreadsheet that contains a list of "objectives". Whenever there is a new release, someone will deploy it on the testing server. She gets the notification and goes through her objectives. For each item, she has to access the database to find out a suitable testing data, then go to the site do the manual test. Because the database is synchronized with production periodically, there is no testing data setup. And all the steps are in the QA's head. Even the most simple test, for example, testing validating of the datefield for a user who wants to set up absence email, is not a trivial task, and it DOES get broken from time to time.

Since agile process is always about bringing business value to the customer at an early stage, I think we should write automated web tests to relief the QA of the burden, rather than keep doing exercise with the developers. It is fun and all but after all it is just writing unit test for existing features, most of which none of us (including their developers) understand.

HsqlDb and Database Design Issue

Got in memory database working, thank you HSQLDB! With this in place, we will be able to write some unittest or functional tests without worrying about stub out the database. We acquired a set of SQL from Sybase that can help us create the tables and views. However, because Sybase is not using standard data type and SQL, it was a pain to convert all the script. We had to comment out all the ones that we are not going to use.

Here is another good example of why some people should be directed instead of enabled. Because you can make table/view names case sensitive, someone here decided to create views as the same name as the table, except in different case. Thank God that the view is exactly the same as table (used only for READ/WRITE control), I was able to get by without creating it. Also that someone decided to create different view of the same name for different type of user. So it will be interesting to run into that scenario down the road.

This is what you get for not using a nice IDE

Three Drofnats developers all use terminals, vi and cvs command line. So there was no easy way to check references or do the simplest refactoring. So they came up with a few dozens of cvs moduels that depends on each other. Jar files are built through these modules and used by each other as library, in a Maven kind of way. Since everything is done manually, it is impossible to check for references or update calls when a method is changed, or even make sure no cyclic dependencies have been introduced.

For example, Module A can have three version a-1.0b1.jar, a-1.1b3.jar, and 1.2b3.jar, and requires a c-2.3b3.jar. Module B can have two versions, b-2.0b3.jar and b-2.3b3.jar, and has to depend on a-1.1b3.jar and c-2.3b3 to build the latest jar file. Module C has one version c-2.3b3 and has to depend on a-1.0b3.jar

Eh...If you have not been confused, I hope you have seen the big problem here. They have done a VERY good job on making sure the building system can handle all these versions, in a Maven like way. But I don't suppose this can be kept up for a long time.

With the introduction of Eclipse (Not my favorite IDE, not even the second most favorite by the way), we have been able to show the problem to them. However, without any automatic tests, we don't dare just upgrade all modules to depend on latest version of any other modules. It seems that we will have to find out the change between each versions, and manually update them for the simple ones. Then for the not-so-simple ones, we'll have to write functional tests first. The database is not decoupled, however, so we are still researching on how to write test without having to have a full-blown server.

To be continued...

New Project : Drofnats

Started the next project in, let's call it, Drofnats. Compared to the SFD that I visited two weeks ago, this one is just the oppsite. The IT department, at least that ones that we have been talking to, are very much open-minded, after being bitten by a bad project management.

It is quite interesting that according to the switches of scope, time, cost and quality, they are very willing to achieve high qualty, less likely to cut scope, and flexible on time and cost. I am really very happy that they picked us than the other two companies, one of which is IBM, because they could be used if not careful. It is such a good candidate for Agile development, and I really hope we can have a great success.

Today is mostly spent on preparations. The pilot inception deck power point is the most interesting. It reminds me of the design document that we had at Cysive. It is very powerful but yet not to be abused. However, I especially like the slide of "Is and Is-not". It clearly specifiies what is to be covered and what is not, in a simple two-column table. This means that it did not take too long to produce, it will be easy to change, and yet it clearly defines the scope so that everyone will be on the same page.

It is also my first agile project from beginning. In Yabe, they have already planned it by the time I came in, and it was not by a ThoughtWorker. Even though this is not from the very beginning, I still get to see the iteration zero, or the equivalence. It is hectic at certain angle, but it is being handled very well.

The project estimate chart is the next thing I should check out. I also like espeically the way priority/rick/scope is being presented by a two dimensional chart with dots whose size match the scope.

Another Day at the Beach

Another day at the beach. It does give me a lot of time to check out the CruiseControl and its competitors AntHill and DamageControl. CuirseControl is a great open source project that can play a big role on agile development, however it still needs quite a bit work on usability and features.

However, the tests cannot run together because they are affecting the state of some singleton. Interesting, I would think that all ThoughtWorkers, at least those involved in the OpenSoruce project would have an IDE and run tests through IDE. The whole tests take only 1 minute to run using Ant even with fork turned, though. I fixed the tests but too bad that the sourceforge is down, I cannot submit any changes.

Once I submit it I'll get the .Net CD from Dave and take a look into notifications in DamageControl. BTW, the MX4J and JMX are somehow more complicated to understand than I thought they should be.

More notes on notification. Ran into these two open source projects that seems to make IM very easy.
GAIM: A IM just like trillian (http://gaim.sourceforge.net/)
IMTask: A IM library (http://imtask.sourceforge.net/)
We can make CruiseControl server sending out messages through IM about building status, and we can also make a CruiseControl bot that start the build, etc. (On the bot part, maybe should start with an IRC bot)

Still looking at China IT, found quite a few IT related website. Now I just need to go through them and get a feeling on the general knowledge and conception.

Finished Two Projects

Just finished two projects of a client, let's call this client Yabe for potential legal issue.

Yabe is a big client, brought to us by friend of ThoughtWorks. They use ClearCase and Eclipse. I have to say, the set up of the ClearCase and Eclipse is very anti-agile. (I'd like to say it is the products themselves but I have met some other developers that argued that it is the setup instead of the tools themsevles). Everytime I work on this environment, time just fly by while I am staring at the screen waiting for something stupidly long to finish, and before I know it, it is already past 9pm. I cannot imagin how in-hourse developers live their lives, but I sure hope their stock options are well worth it.

(Ok. Here is a good example of how screwed up these tools, or their settings, are. I renamed a private static method that takes no argument and returns void, and it tooke Eclipse 2 minutes to come back. Auuuuuuuuugggggggggggggggggggggggggghhhhhhhhhhhhh)

Here is another testimony of ThoughtWorkers' ability. Dave and Alex (An independent consultant) pulled the subsystem and its library over to a CVS repository, and use IntelliJ to build upon it. CruiseControl is set up. Periodically we sync. up to the Yabe world using a script that Alex wrote. So with CVS and IntelliJ, we were able to happily write programs using test-driven development. Yabe has a document that supposely contains all the requirement of the new application, similar to the use case document. We divided it up into story cards, gave them numbers and came up with our estimates.

So from our team's point of view, we are doing pure XP. We pair, we track, we test, we refactor. The resulting application stays healthy wihle we continue adding more and more compilcated features (BTW, writing web application without using session tracking is not a trivial task). It is my first XP project since the one for Novell in year 2001. And it just felt like an place I belong.

One problem is that as far as the customer concerns, this is just like any other project that they have done. Throwing the document into a blackbox and hoping something good will come out of it by the time of the contract. We didn't realize that ANYTHING different from the document, we were supposed to get approval from the customer. Of course being an XP team, we simply shot an email to the client project manager, asked the question and did the change. At the end, we did more than what the document said, and yet the customer thought we were two-week behind.