I spent the weekend on reading the following papers:
1. "Today" Messages: Lightweight Group Awareness via Email by A.J. Bernheim Brush and Alan Borning
2. Group Awareness in Distributed Software Development by Carl Gutwin, Reagan Penner, and Kevin Schneider
3. Providing Artifact Awareness to a Distributed Group through Screen Sharing by Kimberly Tee, Saul Greenberg, and Carl Gutwin
4. Group Storytelling for Team Awareness and Entertainment by Group Storytelling for Team Awareness and Entertainment by Leonie Schäfer, Carla Valle, and Wolfgang Prinz
5. Portholes: Supporting Awareness in a Distributed Work Group by Paul Dourish and Sara Bly
The last one was written in 1992, which is not up-to-date so I will probably not use it as a reference. However, among the above five papers, I found it to be the best example for structuring my own paper.
Monday, September 22, 2008
Friday, September 19, 2008
Semester Plan
When you are working in a distributed work group, a general problem is maintaining awareness of what others are doing and in terms co-ordinating everyone effectively. The traditional approach to this problem is by having more meetings and more active communication within the group. However, when people are working, it would be quite distracting if they are required to communicate frequently about their status.
My thesis is going to address this problem and my proposed solution is to have a software agent called Boswell that will keep track of what you are working on and broadcast activities of interest to your group to enhance communication.
Boswell was started last semester with the main framework written in Java. My plan for this semester is to spend the rest of this month on integrating IM into Boswell. Currently, Boswell supports communication with Twitter and Facebook. From the last CSDL meeting, general feedback was that IM is likely more efficient for communication within a group. The API I am currently trying out is the Smack API. It is an API for Jabber written in Java. The goal is to have the system ready for evaluation in October. In mid-October, ICS 413 students will be invited to try out Boswell for a week and provide feedback.
From now until November, I will continue with writing up the paper and doing literature reviews. For literature reviews, my plan is to read and analyze at least 4 papers a week. A blog entry will be written for every paper that I read. The goal is to have the final draft of the thesis completed by mid-November and everything done by December for the presentation at the Fall Forum.
My thesis is going to address this problem and my proposed solution is to have a software agent called Boswell that will keep track of what you are working on and broadcast activities of interest to your group to enhance communication.
Boswell was started last semester with the main framework written in Java. My plan for this semester is to spend the rest of this month on integrating IM into Boswell. Currently, Boswell supports communication with Twitter and Facebook. From the last CSDL meeting, general feedback was that IM is likely more efficient for communication within a group. The API I am currently trying out is the Smack API. It is an API for Jabber written in Java. The goal is to have the system ready for evaluation in October. In mid-October, ICS 413 students will be invited to try out Boswell for a week and provide feedback.
From now until November, I will continue with writing up the paper and doing literature reviews. For literature reviews, my plan is to read and analyze at least 4 papers a week. A blog entry will be written for every paper that I read. The goal is to have the final draft of the thesis completed by mid-November and everything done by December for the presentation at the Fall Forum.
Wednesday, April 2, 2008
Informative Workspace Code Review
This week we had a chance to review the Informative Workspace's web application: project overviewer which is currently displayed in two of the moniotors in CSDL. It aims at providing a general overview of each of the 4 projects we are doing in ICS 414.
Downloading and setting the project up was very straight forward. At first, verify doesn't pass becuase I am using a different version of PMD and Checkstyle. The team mentioned already mentioned that they are using different versions of some of the QAs so this is not surprising. After modifying the build files to refer to the correct version instead, verify passed.
The team asked us to try and displayed our own project in the project overviewer. This turns out to be a pretty straight forward task too. All that is required is changing a couple line of PageInfoWork.java to provide my hackystat account information and the subversion url.
Possible improvement:
1. Includes a troubleshooting section. I encountered PermGem error very often at first, and I have to shut down and restart tomcat whenever that happen. At the end, I took away other .war or .jar file from the tomcat webapp folder and that stopped happening again. And also problem with deploying and undeploying the war file for multiple times in a session. These problems might be common with user and providing a section to guide user through them would be helpful.
2. A count-down clock would be more useful than just displaying the milestone date in a line.
3. Documentations on how to modify the code to display a particular project should be included. It may not be obvious to all users that all we had to do is to change a couple lines in the PageInfoWork.java to bring up their own projects.
4. Documentation for changing the PMD, checkystat version number in the build.xml should also be included. Otherwises, some users may think that they have to upgrated their QA tools in order to build the project.
5. Even though this is just for review purpose, it would be nice to include everything in all the projects instead of having to try import our own projects in the Info-Work page.
6. The tree takes up too much space and I don't think it is necessary to list out all the files. For example, for our project, the .cs files are of more interests to the users. Just looking at all the .cs files would provide a good-enough overview of our project.
All in all, the project overview had a good start and I look forwards to seeing the final product .
Downloading and setting the project up was very straight forward. At first, verify doesn't pass becuase I am using a different version of PMD and Checkstyle. The team mentioned already mentioned that they are using different versions of some of the QAs so this is not surprising. After modifying the build files to refer to the correct version instead, verify passed.
The team asked us to try and displayed our own project in the project overviewer. This turns out to be a pretty straight forward task too. All that is required is changing a couple line of PageInfoWork.java to provide my hackystat account information and the subversion url.
Possible improvement:
1. Includes a troubleshooting section. I encountered PermGem error very often at first, and I have to shut down and restart tomcat whenever that happen. At the end, I took away other .war or .jar file from the tomcat webapp folder and that stopped happening again. And also problem with deploying and undeploying the war file for multiple times in a session. These problems might be common with user and providing a section to guide user through them would be helpful.
2. A count-down clock would be more useful than just displaying the milestone date in a line.
3. Documentations on how to modify the code to display a particular project should be included. It may not be obvious to all users that all we had to do is to change a couple lines in the PageInfoWork.java to bring up their own projects.
4. Documentation for changing the PMD, checkystat version number in the build.xml should also be included. Otherwises, some users may think that they have to upgrated their QA tools in order to build the project.
5. Even though this is just for review purpose, it would be nice to include everything in all the projects instead of having to try import our own projects in the Info-Work page.
6. The tree takes up too much space and I don't think it is necessary to list out all the files. For example, for our project, the .cs files are of more interests to the users. Just looking at all the .cs files would provide a good-enough overview of our project.
All in all, the project overview had a good start and I look forwards to seeing the final product .
Wednesday, March 19, 2008
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.
Monday, March 17, 2008
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.
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.
Wednesday, March 12, 2008
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.
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.
Wednesday, March 5, 2008
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.
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.
Subscribe to:
Posts (Atom)