Part of the build quality problem I mentioned yesterday had to do with the fact that changes are getting promoted to our test and production environments that aren't supposed to be.
Our source control system is based in ClearCase, and we are using UCM. We have our projects set up where there is a stream that cooresponds loosely to the code that is in productions, and then we have developer streams under that stream. If there is a feature/enhancement, then we create streams for those features/enhancements under the main stream, and then developers join under that feature stream to work on it.
What happens is that developers sometimes make fixes in the feature streams, instead of the top level streams, and thereby tie thier fixes to feature code that isn't really ready to go up. To prevent this from happening in the future, the project manager for that team wants to prevent developers from creating thier own activities, and she is intituting a policy of more thorough checking of code that is to be integrated into the application. This is really only a start, however, since the integrator isn't necessarily going to realize when a change that wasn't part of a change request has been stuck in with an approved change.
To solve the image problem we have been seeing recently in this application, I'm going to re-implement the conversion piece as an external RMI server running in a different, headless JVM on the same server. I have to do this because the J2EE application server we are currently using only supports JDK 1.3. I need JDK 1.4 to support headless AWT calls, which the conversion process makes. I'm creating this server as a Generic Server that can be started up with the main application server. This should eliminate network problems from the picture, as well as provide re-startability, and the conversion process should be faster.
I made some changes to the ODBC Driver that the DataStage team was using to access our internal iSeries servers. I enabled connection pooling for the driver, and that seemed to help performance quite a bit. A test job that was running at about 25 rows per second, jumped up to about 100 rows per second.
I've been trying to help out another team here to develop a user defined reporting tool for an application that we sell. The application will use JasperReports for pretty report formatting, and it will be tightly integrated with the rest of the application. I haven't had as much time to help out with that project as I would have liked, but a co-worker of mine is working with me to help that team.
Our source control system is based in ClearCase, and we are using UCM. We have our projects set up where there is a stream that cooresponds loosely to the code that is in productions, and then we have developer streams under that stream. If there is a feature/enhancement, then we create streams for those features/enhancements under the main stream, and then developers join under that feature stream to work on it.
What happens is that developers sometimes make fixes in the feature streams, instead of the top level streams, and thereby tie thier fixes to feature code that isn't really ready to go up. To prevent this from happening in the future, the project manager for that team wants to prevent developers from creating thier own activities, and she is intituting a policy of more thorough checking of code that is to be integrated into the application. This is really only a start, however, since the integrator isn't necessarily going to realize when a change that wasn't part of a change request has been stuck in with an approved change.
To solve the image problem we have been seeing recently in this application, I'm going to re-implement the conversion piece as an external RMI server running in a different, headless JVM on the same server. I have to do this because the J2EE application server we are currently using only supports JDK 1.3. I need JDK 1.4 to support headless AWT calls, which the conversion process makes. I'm creating this server as a Generic Server that can be started up with the main application server. This should eliminate network problems from the picture, as well as provide re-startability, and the conversion process should be faster.
I made some changes to the ODBC Driver that the DataStage team was using to access our internal iSeries servers. I enabled connection pooling for the driver, and that seemed to help performance quite a bit. A test job that was running at about 25 rows per second, jumped up to about 100 rows per second.
I've been trying to help out another team here to develop a user defined reporting tool for an application that we sell. The application will use JasperReports for pretty report formatting, and it will be tightly integrated with the rest of the application. I haven't had as much time to help out with that project as I would have liked, but a co-worker of mine is working with me to help that team.