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).
Sunday, September 26, 2004
Thursday, September 16, 2004
What's up with CruiseControl
Labels:
IDE
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.
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.
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.
Monday, September 06, 2004
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.
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.
Thursday, September 02, 2004
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.
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.
Wednesday, September 01, 2004
This is what you get for not using a nice IDE
Labels:
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...
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...
Subscribe to:
Posts (Atom)