iHacky code review

I am recently very fond of using facebook, so I was excited to try out the iHacky application which is a facebook application designed for developers to communicate and network among themselves.

Installation was very easy. Since I already have a facebook account, I simply followed the link given in their project page and with a simple click of button, the iHakcy application was added to my profile immediately. After trying it out, I decided to check out the source code and try to set up my own iHacky following the instructions on the Developer's guide. That turns out to be not as smooth as the installation. I faced some problem with setting up the Apache server. In the end, it took me a long time to set it up but I am still having error with the PHP and I understand why the team suggested us that we could skip installing it locally.

I am not familiar with PHP, but from the source code, they look pretty organized with plenty of comments. All in all, this application is still in early development phase and I see a lot of improvement in it.

I installed iHacky on Monday and everything was working fine, but as of right now, the iHacky application is down. Clicking on the tabs would lead me to an error pages, so I will give the suggestions based on what I remember from using iHacky on Monday.

In turn of the application's functionality and interface, I have the following suggestions:

1. Allow user to change the hackystat account detail.

2. Provides visual representation of ranking on the facebook profile page. For example, it could be done in an pyramid form like how "Who has the biggest brain" does. It would encourage people to use iHacky more often in order to get to the top.

3. Provides more informative details on the user's profile page. Right now, it is only displaying "My Last time stamp is".

4. Shows which of your friends are also using the application. Right now, I can do so by going to the iHacky development page. It could be just me but it literally took me a while before I remember that I can actually visit the application's homepage by clicking on the tiny link in the bottom of the page to see who is also using the application. Including the friends list in the iHacky homepage or in another tab would be helpful as it would encourage people to use the application if they know a lot of their friends are also using the applications.

5. Allow people to contact the developers directly. Maybe they could have the developers listed there. Facebook can show "I am online" if the user is logged on. So if user can see one of the developer is online, they can message he directly for questions.

Some other suggestions in term of documentation:
1. It would be nice to have a troubleshooting section. When I test my PHP5 installation for the first time, it didn't work. I followed the instruction to set up a test.php but then it only showed an error page.

2. The Wamp could be listed as one of the required components, with a note saying it is for easy installation of the PHP and other components.

All in all, this is still in early development phase and I really look forwards to seeing the end product. Being a Facebook addict I would surely use it everyday to network with other developers.

Hudson

Everyday when I walk into CSDL, the first thing I do is to look at the Twitter message board and the Hudson dashboard. They are both fun and informative. The Twitter message board lists all updates of everyone within the channel, it gives a sense of where everyone is going. Whereas for the Hudson dashboard, it gives visual representation of the project status. At CSDL, Hudson is displaying the status of all hackystat projects. Just take a quick look and the red(build failed) or blue(build suceeded) icons together with the "weather signs" gives a very clear picture of how the projects are doing. It is interesting to see how a single screen can provide so much information and gives a big picture of the system. It facinated me but at the same time, it gives me the impression that Hudson is quite complicated and would not be very easy to set up. I am proved wrong after installing Hudson in order to become familar with continuous integration.

So basically, my concept of continuous integration used to a simple statement: compiling and building the system as frequent as possible, such as whenever the system has been updated. After going through the tutorial and the reading, I got a more throughout idea of it, such as the benefits and basic requirements of it.

From the tutorial, it explored Hudson. The first impression is: it is so java. I know before that Hudson is written in Java but what I didn't expect is it provided such extensive supoorts to Java QA tools, such as Ant, JUnit, PMD etc. Installation of Hudson was surprisingly easy. I simply download the war file, deployed it in tomcat and I was ready to define my first Hudson project, which is the Visual Studio Sensor.

As mentioned above, Hudson provides extensive support to Java project and the tutorial also mainly covered steps in setting up a Java project. Since our sensor project is written in C#, I was worried at first if it would be hard to set it up in Hudson. But on the whole, everything were fine, the project is easily ported into Hudson. However, I faced problems when I tried to build it for real from command line using "DevEnv C:/VSSensor/VisualStudioSensor.sln /Build" as I would do on my computer. The problem is that it cannot run DevEnv and in the end, my group partner Jared solved the problem by having the buildsensor.bat.

In order to put the sensor project on the CSDL server, the computer would first of all need to have Visual Studio installed and then follow the usual procedure of setting up a project, type in the command prompt to execute build and point the path to the buildsensor.bat. Compared to building a Java project, this is more troublesome. So I am thinking if we can employ NAnt to automate the build process so that we don't have to build the system by command. This NAnt plugin could be useful.

Visual Studio Sensor Code Review

Our classmates did a review of our project: Visual Studio Sensor for Hackystat. This is the project page and the source package is available here.

In general, I am glad to see that they did not have much problem with installing the sensor. The main problem encountered is failure to build the system due to null reference to NUnit. This problem was addressed promptly by my group partner, Jared by posting a modified release.

Also, I am not surprised to see that one of the biggest problem encountered was creating another instance of Visual Studio. This was also the problem that hindered us from writing test cases for the sensor.

Based on the review, some of the sensor data now collected are apparently not useful and that is exactly what we would like to find out from the review. Apparently, some DevEvents such as CloseFile and OpenFile are not of much interests to them.

Ambient Team Code Review

The Ambient Device team gave a presentation on their current release for us to do a review of their code.

By following the installation and developer guide, I was able to check out and install the project. Installation was not difficult as I already have Hackystat installed and have a valid Hackystat account, so I don't have to go through setting up Hackystat again. Everything was fine until I try to run verify. According to the developer guide, it mentions that junit test should fail but the problem is it didn't mention which test should junit fail. So I am not sure if I am just having the error that the ambient team have or if I actually have additional problems that have to be fixed. In the end, I came across three major errors and spent a lot of time just to fix the first two. However, there is still an error: org.apache.xerces.dom.DocumentImpl.getXmlStandalone()Z that I didn't know how to be fix.

For the code itself, it was pretty organized and I don't see much problems with it but in term of documentation, it could have been better. Problems or areas that can be improved:

1. Even though the code is pretty organized, there is a lack of comments. There are comments for each class and methods but comments within methods are rare, which makes it harder for the user to understand the code.

2. The superclasses could have been more comprehensive instead of having only one method.

3. When the jar file is invoked, there is only a statement saying "LastBuild: Active" which is not helpful as it doesn't give the user any information whether it is actually communicating with the orb successfully or not.

4. For documentation, a troubleshooting section would be really helpful. Apparently, many of us are having the same junit errors that makes verify fail such as the Jaxb api problem and the javamail installation problem. So if they can provide solutions to these problems, it would make the developer guide more comprehensive and helps the user.

5. There should be instructions or references instructions to install Hackystat in their developer guide. It would be confusing for users who have no prior experience with Hackystat.

6. Another obvious problem is it takes too long for the orb to change color. This is a problem because during the wait for the orb to change color, the project situation could have been changed completely. For example, it could have gone from a failed build to a successful build again.

It was a fun experience to do this review as it gave me to chance to play with the ambient orb for the first time. The ambient team has surely got a good start with their project. There is big potential to this project. As mentioned above, I think their code is working well and the main problem is with the documentation and the color changing latency, both of which should not hard to fix as the latter could be fixed by acquiring the appropriate hardware. I look forwards to see what the ambient team is going to do with the Nabaztag as well.