Code Review: iHacky Project

I did my review by following the installation guide from the iHacky project site. The process is so easy because I already have a facbook account and hackystat account. The actual usage of the application is pretty much the same as what the team demonstrated during the class time, and there's really nothing much I found useful at the moment. So far, the only useful bit of functionality of the application seems to be the searching for the peopl who use the same tools as me. (On a side note, when I tried the search, the auto-complete feature didn't work for me. Is there any special steps required to trigger it?)

In terms of the source code, since I have literally no knowledge of PHP, I can't give too much comment on it. However, I do see the lack of QA tools used for the project. The team should at least provide a way of building the system, so that the project can be actually applied in the telemetry hudson.

In terms of documentation, the installation guide should probably specify that the user must be login into facebook before they actually click the link to the add the application. Also, I don't understand why the application cannot be found within the facebook application search, because that was the initial way I tried to find the application, and I believe that's how most people will look for an application in facebook.

In terms of usability, there are quite a lot of problems exist in the current system. First of all, in the profile, the user is required to enter their hackystat account info. However, there's no way to change this info after it's been set. Also, I tried with another account with false hackystat info, the system didn't detect that. I suggest the team to add some sort of authentication mechnism on this. Second, the tools tab, as the Hong said, should be integrated into the profile page. Then in the profile page, the tools should have link on them or near them that the user can simply click on the link and find the people who are using the same tool. Third, the team tag seems to belong the projects tag. I don't really see the reason of separating them. Also, in the projects page, I personally don't really need the "default project". Maybe a link to create new project in hackystat can be included here. Lastly, I don't know what the invite tag is for.

Honestly, the system right now has very very limited actual usage. Instead of trying all sorts of different ideas, I think the team should be focusing on one particular feature and keep working on it to make that feature become actually useful. The tools is one of the good features to work on for now. By enabling the user to edit the tools they use, and finding other people who use the same tools, are something good to know. Also, besides what tools are used, I would also like to know the information on how frequent the tools are used, when was the tool used last time, etc. The hackystat sensor could provide all these information easily. Right now, only the projects information comes from hackystat, and it's not something that useful for me. Also, the whole class is suppose to have this system installed by now, so the team could use us as their initial users base. After all, facebook is all about community connection, but the system is only been used internally by the 3 developers right now.

Overall, the iHacky team is on a good start for the project. From the developer guide, I can see how hard it is for them to get their project up on facebook and running, and they are using PHP, which is something that they are not familiar with. Right now things are set, I'm expecting them to provide something more insignful and useful in practice in the next milestone.

Hudson - My first impression of continuous integration

Things I learned about continuous integration that I did not know before
The Hudson is running on the CSDL telemetry wall since the semester began, and I kind of grab the idea of what it is doing by looking it so often since my project requires me to look on that wall every now and then. What I didn’t notice, however, is that it not only does compile and build the project, but also runs various QA tools, such as checkstyles, PMD, findbugs, JUnit, etc. Also I didn’t know that Hudson is so automated that once you set it up, you can almost forget about it. The features that Hudson offers are far more than I expected.

Problems I had to resolve in order to get the informative workspace system to build under Hudson
I have encountered various problems while I was trying to getting my informative workspace system to work under Hudson, but the real problem that took me quite a while to figure out was to make the system deploy in tomcat by Hudson. First of all, since the system is deployed in tomcat, it requires the tomcat to be running first. And since tomcat is using the default 8080 port, I have to somehow change the port for Hudson. (Well, actually now I think about it, maybe deploying Hudson in tomcat would also solve the problem.) Anyways, what I did was putting the "--httpPort=8081" parameter. However, changing the port didn't solve my problem. I still got the error of deploying the war file into tomcat, and it is a http response 505 error. After some googling, I guessed the problem was caused by the "C:\Documents and Settings" folder, which was the default home directory for Hudson to store a local copy of the SVN files. Since the way I deploy my war file is using ant script, and ant doesn't like the spaces, it simply refused to work. After I set up a variable HUDSON_HOME and points it to a folder without space, things went very smooth. (I still haven't set the emma up, but I was thinking to exclude it from my normal build routine anyways, so I will just leave it as it is for now.)

Update: Later I tried to create a new job with space in the name and the deployment also failed. This could be the original reason for the failure in the deployment. But since ant doesn't like space anyways, I would rather to keep things simple by eliminating both the spaces in HUDSON_HOME and in the job name.

Steps Philip has to carry out in order to get the informative workspace system running using the CSDL Hudson server
Other than setting HUDSON_HOME to a folder without space (which I assume is already been done), I don't see there are any extra steps needed for getting the informative workspace system running in the CSDL Hudson server.

Code Review: Visual Studio Hackystat Sensor Project

I have downloaded the setup zip file from the project site, and the installation process was pretty smooth and easy by following their installation guide. Since I am already a Hackystat user, the only external work I need to do is moving the sensorshell.jar file into the correct folder. After that, the sensor is working as intended, and the data is sent correctly by checking via the sensor data browser.

The sensor data types that are available right now are quite a lot. I simply used my visual studio for only 20 seconds (yes, only 20 SECONDS), and there were about 30 different sensor data sent. However, I doubt the usefulness of some of the sensor data types. For example, open and close files. I open and close files quite often without changing anything inside them, and with visual studio debug mode, it's very usual that it will open a file that's not-so-related to your project while you were caught with errors during the debug. For me, I usually close down whatever file that's opened by VS because I know 99% of the time that file isn't the cause of the problem. Therefore, recording data like closing a file doesn't hold any significance to me. Also, the data type of BufferTransition refers to the focus change of a window. From my own experience, switching among different windows is a quite normal and very often task while using an IDE. I am not exactly sure how this data type is is defined, but I am assuming it records whenever the user changes the focus from one window to another window. If that's the case, it would simply generate so many data with no real meaning. What I really want would rather be something like, the window has focus for a certain amount of time and the user is active during this period of time. This way it means the user has probably done something more meaningful in that particular window. Well, it's only my thought.

In terms of bugs, there is an overloaded problem about having more than one instance of VS will cause the sensor to malfunction. Also, the prompt of verifying the sensor has started doesn't show up when I open a solution file, which I assume is the more usual way of how the VS users start working on their project. Technically this isn't a bug, but it would be nice to confirm that the senor is working correctly.

For the testing, I can find two NUnit tests in the source code, but I don't know how to run them, and the developer guide doesn't mention that either. Hopefully they can provide some instruction on that in the future release. Speaking of the source code, the initial distributed version doesn't build successfully due to a null reference to the NUnit stuff. After consulting with Jared, one of the developers, he resolved the problem quickly and re-distributed another working version of the source code. Now only if the real world open source community can be this responsive, the world will be a much nicer place to live.

Overall, the team did a good job on building the sensor. It's functional and easy to install and use. I expect the team will create some sort of GUI interface to configurate the sensor later, and what I would like to see is something about choosing a project for the data that is collected for, just like the eclipse sensor. Because my project is building up something that is somewhat depended on that, I really like that feature to become available in the future.

Code Review: Ambient Device Project

The source code and powerpoint for the ambient device project.

Here is my review for the current code base of this project:

I. Passing the verify.build.xml
The verify functionality is provided, however, it fails on the JUnit. Although the team clearly mentioned this both in wiki and the presentation, I was not surprised by it. What really surprised me was its fail on the PMD violation:

C:\ambientHackystat-0.1.303\src\org\hackystat\ambientdevice\device\orb\AmbientOrb.java:20 A class which only has private constructors should be final

However, this is NOT the fault of the ambient device team. The reason for this is because I'm using the PMD version 4.1 instead of the version 4.0. Actually, there are some QA tools that I'm using are on the newer version, but PMD is the only one that gave different result. I wonder if it is a good thing or not to use the newer version, since we had the problem of using newer FindBugs before, and the newer version of Emma is still buggy from my experience.

II. Changing the orb's color
This is actually easier than I expected. Well, it still could be hard for a normal user without any technical knowledge. By changing the user name, password, device ID, and value for the color in the XML file, one can change the color by running the jar file provided with the modified XML file. From my experience, the time it takes to change the color can rage from 4 minute to 18 minute. Honestly, I have yet to see its practical usage if it takes that long to indicate any change. Also, I assume the team would provide a better interface later for changing the XML file, or otherwise they should start thinking to provide one.

III. Improvement & Suggestion
Since I'm still not fully understand the structure of the system, I don't think I can give too much suggestions on improving the design of the system. There are, however, somethings that can be improved easily. First, some comment explaining what the code is doing would be helpful. The whole system almost has no comment besides some mandatory javadoc comment, which isn't helping much. Also, from the schema, it seems like that all the triggers have a comparison attribute, which I don't think it's necessary. For example, a fail unit test can just return a value of false, instead of doing a comparison. (Well, I'm assuming that's what it's doign according to the schema)

IV. Top five biggest problem in the system
Here's what I found that is most problematic, although some of them are due to the device itself, not the programmers.
1. The color changing latency is way too long, which makes the device practically useless. Also, many color differences is hardly noticeable by human eyes.
2. Documentation is lacking. Not to mention the lack of comment inside the code, but also the lack of detail in the installation guide. For the purpose of a code review, the developer guide might be sufficient, but the installation guide should at least let people know what they can do by bringing up the server, or more precisely, what would happen by having the server up. I don't see that from the installation when I was doing the review.
3. There are too many unnecessary libraries included in the system, such as the derby, restlet, gwt.
4. There is no real "mesh-up" with the HackyStat framework for the current system. I can see some of the triggers are pulling data from the HackyStat sensorbase, but it doesn't seem like they are working right now for me.
5. Many JUnit testing cases still fail. But since this is only for the code review purpose, I would expect the team to fix them all later.

V. Summary
Overall, the ambient device team has done a pretty nice job of getting the orb to work. They already have the basic structure of their project setup, and what is left for them to do is to refine and put in more features to the system.