This review is for the Project Overviewer widget for the Informative Workspace Project.
Installation and Developers Guides:
Installing the Overviewer was fast and simple by following the Installation Guide, but going through the Developers Guide took a while in my case since I reformatted my computer. I didn't have the environment variables setup aside from what's needed for Hackystat so that took extra time to go through - Probably the same amount of time as someone who hasn't had much experience working in a Java environment. I also had to look for different versions of the tools, although I think the Emma version listed was a typo since build 2.1.5312 doesn't exist. After the variables were set up I tried to do an ant verify that didn't work initially because ant was complaining about my ANT_ARGS variable being unspecified from an xml file so I took that out. Not sure if anyone else ran into that or if it was just me. Verify passed afterwards.
Code:
Overall the code looks good with a decent amount of documentation. I think that it could use a little cleaning up though - just spaces in between lines of code to improve readability. I also fiddled with getting the iHacky repository to show instead of the Informative Workspace (IW) repository and ran into a bug.
All I did was change the relevant information such as repository address, and Hackystat project owner and members. After I made the changes, I compiled the program and deployed it on Tomcat. When I clicked on the IW Project link it wouldn't load. After an hour of looking over the code and making a minor change based on a hunch, I recompiled the program and deployed it back on to Tomcat. The problem was that the Overviewer didn't like having 3 developers in developersList. I didn't test for any higher value though so once I removed a developer from the list, it finally showed the iHacky repository.
As for the use of Wickett, I initially thought that it would have been more of a pain to use over Stripes, but after finally seeing it work it seems pretty much the same. Instead of jsp and Action Beans, we have html pages and ... Pages.
Usefulness
Right now the overviewer displays all of the files in a project's repository, or displays information about the project such as features and upcoming milestones. On the CSDL Telemetry Wall where the IW project is being tested on, the overviewer is currently taking up two screens. If I remember correctly, the team has stated that the overviewer will eventually just take up 1 screen and act as a focal point for any other data in the other screens.
This is supposed to be an overviewer, but I'm not getting a sense of how looking at the entirety of a repository gives a good overview. According to a quote on the project's webpage "when an interested observer walks into your team space, s/he should be able to get a general idea of how your project is going in 15 seconds, and be able to get a deeper perspective on real or potential problems by looking more closely." Having a countdown of a milestone and having a feature list seems like it fits that description, but I can't picture that information along with the repository view all on one screen giving the observer a general idea in 15 seconds. I don't even see how automation will help to improve it once automation is implemented. I guess I would suggest that the repository view be something that the interested observer be able to access when they want to get the deeper perspective. Replace the repository view on the front page with something simpler to get the observer to interact with the IW and make the text larger on the milestone countdown and features so it can be seen from a longer distance.
Tuesday, April 1, 2008
Tuesday, March 18, 2008
Arthur C. Clarke (December 16, 1917 - March 18, 2008)
I was saddened to find out about Sir Clarke's death as I am a fan of his Odyssey and Rama novel series and firmly believe that 2001: A Space Odyssey is still THE BEST Sci-Fi movie to date. I was listening to Eve Radio around 1:00pm (-10 GMT) and the DJ made a comment that Clarke was not dead, but merely with aliens. It seemed like an odd thing to say so I went to check the news through iGoogle and there it was, a headline announcing his death.
Clarke is best known to most people as a grand master of science fiction, but he is also a visionary. He popularized the ideas of geosynchronous satellites and space elevators, and although the ideas did not originate with him, he did elaborate on them. He predicted that satellites in geosynchronous orbit would be great for telecommunication relays, and authored books going over their technical details. In his 1979 novel, The Fountains of Paradise, he introduced his ideas for space elevators. He also wrote a two part article in 1981 called "The Space Elevator: 'Thought Experiment', or Key to the Universe?" He supposedly said that space elevators will be his legacy and I hope it's true.
Up until the end of his life and through his deteriorating health from post-polio syndrome, Clarke continuously worked on something - a novel, a cause, an idea. He received many awards, honors, and even knighthood. It amazes me and makes me wonder where his drive to do all that he has done came from, and I hope I have even a tiny bit of the drive he had as I go on with the rest of my life past college.
Goodbye Sir Arthur Clarke.
Clarke is best known to most people as a grand master of science fiction, but he is also a visionary. He popularized the ideas of geosynchronous satellites and space elevators, and although the ideas did not originate with him, he did elaborate on them. He predicted that satellites in geosynchronous orbit would be great for telecommunication relays, and authored books going over their technical details. In his 1979 novel, The Fountains of Paradise, he introduced his ideas for space elevators. He also wrote a two part article in 1981 called "The Space Elevator: 'Thought Experiment', or Key to the Universe?" He supposedly said that space elevators will be his legacy and I hope it's true.
Up until the end of his life and through his deteriorating health from post-polio syndrome, Clarke continuously worked on something - a novel, a cause, an idea. He received many awards, honors, and even knighthood. It amazes me and makes me wonder where his drive to do all that he has done came from, and I hope I have even a tiny bit of the drive he had as I go on with the rest of my life past college.
Goodbye Sir Arthur Clarke.
Monday, March 17, 2008
Continuous Integration with Hudson
Today I learned about continuous integration using the Hudson server system and before this I didn't know anything about continuous integration. It was pretty simple for me to get up and running by just following the tutorial on this site (just make sure you register on IBM first). It may take longer though if you do not already have some prerequisite software installed such as the Java JDK, ANT, and JUnit.
Continuous integration (CI) is a process where projects are automatically built to make sure that any issues encountered will be detected as early as possible in the software development cycle. This automated process requires various types of tools to work. The minimum tools required are an automated build system, a testing framework, and a code repository. Other tools can be used as well to increase the quality of the project such as PMD and FindBugs. For my trial of Hudson, I used the Ant build system, JUnit test framework, and subversion code repository.
So the way the CI process works is pretty simple. The user specifies the code repository's url, when and how often the repository must be checked for a new build version of the project, and then it is downloaded, built, and tested when a new version is found. It's such a simple process to run, but its usefulness and success depends a lot on the developers.
The process of CI alone will not ensure a quality system. There are practices called anti-patterns in this article that developers follow that can make CI a failure for them. A couple of the anti-patterns mentioned in the article that I find myself guilty of doing:
As I mentioned earlier, I used Hudson to get a feel for continuous integration. Installation was pretty simple and the only problem I ran into, which was pretty stupid, was when I couldn't get Hudson to load on my system after using the "java -jar hudson.war" command. At the time I had my Apache HTTP server running, and it too was using port 8080. After a few minutes (yes it took me minutes) to realize that I could just stop the server! The rest of the Hudson installation and configuration went smoothly afterwards. Oh, and I used the ambientHackystat project to test out Hudson.
CSDL Hudson Server
Getting the ambientHackystat project working on the CSDL server won't take much effort since it is a Java project. I suspect that the server is already setup with Ant and JUnit so all that's left to do is create a new project, specify the subversion repository url, the interval for Hudson to check the ambientHackystat code repository, that Ant should be executed when Hudson has downloaded the recent build, then specify the location for the test reports xml file.
Continuous integration (CI) is a process where projects are automatically built to make sure that any issues encountered will be detected as early as possible in the software development cycle. This automated process requires various types of tools to work. The minimum tools required are an automated build system, a testing framework, and a code repository. Other tools can be used as well to increase the quality of the project such as PMD and FindBugs. For my trial of Hudson, I used the Ant build system, JUnit test framework, and subversion code repository.
So the way the CI process works is pretty simple. The user specifies the code repository's url, when and how often the repository must be checked for a new build version of the project, and then it is downloaded, built, and tested when a new version is found. It's such a simple process to run, but its usefulness and success depends a lot on the developers.
The process of CI alone will not ensure a quality system. There are practices called anti-patterns in this article that developers follow that can make CI a failure for them. A couple of the anti-patterns mentioned in the article that I find myself guilty of doing:
- Checking code in to the repository infrequently. The idea behind this is that code should be checked in frequently so that other team members know what's going on with development and allow them to give their own input before changes go too far.
- Submitting broken code. Broken code can remain unfixed for a long time even if other members try to fix it, but it can also hold up development in the long run.
As I mentioned earlier, I used Hudson to get a feel for continuous integration. Installation was pretty simple and the only problem I ran into, which was pretty stupid, was when I couldn't get Hudson to load on my system after using the "java -jar hudson.war" command. At the time I had my Apache HTTP server running, and it too was using port 8080. After a few minutes (yes it took me minutes) to realize that I could just stop the server! The rest of the Hudson installation and configuration went smoothly afterwards. Oh, and I used the ambientHackystat project to test out Hudson.
CSDL Hudson Server
Getting the ambientHackystat project working on the CSDL server won't take much effort since it is a Java project. I suspect that the server is already setup with Ant and JUnit so all that's left to do is create a new project, specify the subversion repository url, the interval for Hudson to check the ambientHackystat code repository, that Ant should be executed when Hudson has downloaded the recent build, then specify the location for the test reports xml file.
Subscribe to:
Posts (Atom)