Code Review: Informative Workspace Project

Since I am one of the developers for this project, I would like to dive right into what the weakness are for our system, because those are what really matter to me.

First of all, the current system, in short, is just a tiny bit more than useless. The reason I said it's almost useless is because the current system is very limited in terms of functionality, and it's totally a failure in terms of usability.

For the functionality, it only has a date picker that doesn't really do anything rather than allowing the user to pick a date (hell, so what!), and a tree that displays the structure of the system with some hackystat sensor data for the related members. (yeah, but in a totally ugly and sloppy way) And both of these don't even work for every project. The projects are all set, the user cannot create or delete any project. Heck, the user can't even have much interaction with the current system. We spent quite a lot of time getting the directories tree up, but it turns out that it's not even that useful for indicating the logical "whereabout" of the developers. The structure of the tree gives more information in terms of how the project is set up, and how the files are laid out. But this kind of information is easily obtainable from the project repository, and it's not something that you need to see 24/7. In other words, having that kind of information 24/7 in the telemetry wall is a little bit waste of resource.

For the usability, I didn't realize it's such a great trouble to modify the code until someone aims me about the problems he encountered while tackling the code. I have to agree, it's simply lame. Things that seem to go without saying for me could be quite meaningless to people who didn't write the code. Even with the comment, there is not much help. Not to mention that the comment for the system right now is not sufficient at all. The idea to push back the implementation of a GUI for the user to customize the account information and such is proven to be wrong. It is almost a necessity from the view point of the users.

Finally, when it comes down to the point that is the system actually useful or not, my own opinion is that given the vision of the system - to give an overview of the project - this system should be very useful. However, the current system certainly doesn't fulfill this vision. The poor representation of the member status and the over-usage of the screen estate are major problems right now, and it is obviously not the correct way to go. Professor Johnson recommended the usage of JTreeMap. Although the idea of it seems very amusing, the implementation of it doesn't really fit into the current system. I can almost feel the the big change of the system is coming along. Well, hopefully it is a good one.

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.

The REST Architectural Principle

After reading some articles about the REST architectural principle, I really think it is a very reasonable architecture, and I am a little surprised in the real world we somehow just don't do things in the way that they supposed to be done, also known as, the RESTful way.

Last semester when I was doing the MyISERN project, the application was accessed through a serious of "action beans". Therefore, the URL is mostly something like /host/researchers.do, which is converted from the ResearchersActionBean. There are many problems with URL like this: one of the most common issues is that people cannot bookmark the page because the URL is always the same. Moreover, the URL does not represent the data on the page in a meaningful way.

Now since I know about REST, I would like to have my current Informative Workspace project being RESTful. The idea of informative workspace is to make the software development process more transparent, and thus there will be many relevant data involved. The REST principle can provide a good way to represent these data in a more reasonable way. For example, we can have some URL like these: (well, with the assumption that the system is a web application)

host/projects/ambient-device/code-complexity
host/projects/iHacky/milestones/2008-02-20

Technically, REST refers to giving a unique URI to every resource, and URL is only a subset of URI. However, I believe the concept is the same. Through the composition of the URL, the user can have a better understanding of what data is being represented in the page. I believe the real problem would be how to represent all these data in a way such that they can be helpful to the development process.

On the other hand, the SensorBase API pretty much obey the REST principle. For example, the resource is named using the URI specification: host/projects/owner/projectname. Also, it uses the standard HTTP methods such as GET, POST, and DELETE to control how the different data are represented, or, control how the different services are provided.

In terms of the Project Viewer, it doesn't seem like it obeys the REST principle to me. At the moment, the URI does not give information owner of the project, as well as the projects. Also, the user doesn't have access to the other data of the project from the Project Viewer itself. (well, it does give the URI for the SensorBase and DailyProjectData, but it requires the users to enter it from the browser.)

How to build a simple survey using Google Docs

Today I discover the new feature of the Google Docs spreadsheet, and I think it would be cool to share the process with the others:

So first of all, you would need a Google account. Duh. Then now go to the Google Docs page and create a new spreadsheet. It will open a window like this:



You don't really have to put anything into the spreadsheet, unless you want to. The survey almost take cares it all. Now click on the Share tag on the top-right corner, you will see a prompt for naming the spreadsheet, and after that, you will see a window like this:



You can check the "Anyone can view this document at". It will generate a link to view the document. By doing that, you can let people to see the result without even publishing the document. But for people to view it without the Google account, you will still have to publish it. Then now check the "to fill out a form" option, and the page will become like this:



As obvious as it shows, you can now "start editing your form". A new window will show up, and you can edit the form in the several ways. Here's a sample one I just made:



After you done playing with the form, click the "choose recipient" button, and now you can specify who would like to survey:



Finally, click the "invite people" button, then you are done! The recipient will get an email with the survey and once they fill it out and submit, the answers of the survey will automatically transfer to spreadsheet, very neat, isn't it?



By now I hope you understant how to do it on your own!

First Impression of HackyStat

I do not know how much time I spent on this assignment because I did a little of it over the course of couple days. The time I spent each day ranged from 5 minutes to 1 hour. The reason that I didn't finish it in one time is mainly due to the overwhelming documentation. I had bad experience from open source software that has no detailed document, so I was happy to see that HackyStat provides such a fully detailed documentation. However, it seems to be a little tiring to go through all that material in one time.

Anyways, the installation of the eclipse sensor was a no-brainer. The GUI setting made it so easy that I got it working without really reading the tutorial. However, the ant sensor was a little more troublesome. First, it took me a while to figure out the double quotes for the ANT_ARG variable is unnecessary. Then the format of the sensorshell.properties file made me confused since it comes with a .txt entension, which turned out to be unnecessary too. Lastly, I couldn’t find the antSensorTest.build.xml at all, and the website seems to have no information about the whereabout of the file either. Although it took some time, I managed to solve all the problems at the end.

In terms of Three Prime Directives, I think HackyStat has done a pretty good job. It definitely accomplishes a useful task by gathering the software development data from the sensors; the detailed documentation helps an external user to successfully install and use the system, although it still can be improved; lastly, since this is an open source project, an external developer should have no problem to understand and enhance the system.

Overall, I feel the HackyStat is very impressive. However, there are some questions that I concern about the system, such as:
* Can the user change the account password? (there is no way to remember the default one!)
* How does it measure the data for a project? (share a same account would be odd)
* Does the data gather from the sensor really useful? (e.g. opened a file in eclipse doesn't mean much)
* What if there is no internet connection, would the services become not available? (that would suck!)

Hopefully, as my experience with HackyStat grows later in this semester, these questions can be solved.

Changing Perspective

I read this article few days ago. The main theme of the article is about what the life of a software engineer is like. It is quite interesting to me that the author considers programming as producing art, just like the poets creating poems. For a very long time, I believe coding is some sort of elegant work, but I never really think of it in terms of art. To me, arts are something like the Mona Lisa, or the Ninth Symphony.

As an ICS senior, from time to time, I would imagine myself becoming a normal programmer after graduation. Then all I do is coding, coding, and coding. 8 hours a day, 5 days a week. It seems like an endless cycle to me, and honestly speaking, I feel that absolutely boring. What if one day, our technology is so advanced, such that we invented some programming machines that can produce quality code as human? If that ever comes true, what is the value left inside a programmer like me?

After reading the article, I think it might be about the time for me to change my perspective of programming. Computer language is like a brush: if it’s in the hand of some incompetent persons, it is no more than a brush; however, if it’s in the hand of an artist, it can become the key to unlock the artistic palace. It is the person that determines what the product can be, either junk or treasure. The creativity of human can never be replaced by the machine. Therefore, there are always some values left inside me, and there would be always something that only I can do.

Someday, if people ever ask what I do, hopefully I can proudly tell them: I write programs, like the poets write poems.

And no, I don’t fix computers.

My First Professional Portfolio

I have just built my first professional portfolio. After this learning experience, I feel strongly that I am still not in the good shape of being a decent computer science professional.

The reason I had that feeling comes from the fact that I have almost literally nothing to say about my expertise when it comes down to a serious level. Although I have been an ICS student for almost four years, I barely had done something that is profound and significant enough that I would like to put down on my portfolio to show to the other people. I had written several C/C++ and Java applications, but those are merely for the course assignments and they hold no important value in terms of demonstrating my computer skills.

The only completed project that I finally put on the portfolio is the MyISERN project that I had been working for the last semester. However, even with such a project that I almost spent the whole semester on, I still feel like it is not good enough as a showcase product. There are still many things can be improved, or have done better. The other project that I put on is the Informative Workspace that I will be working on for this whole semester, and hopefully by the end of this semester it can become a project that I am proud to show to the other people.

Besides the projects, actual work experience that is related to the computer science field is another thing that I found myself missing. I had worked for a while before, but my jobs were totally unrelated to my field. I strongly felt the severe lacking of practical experience as well as the skills and knowledge towards my major.

However, things are not as bad as I mentioned after all. After doing my portfolio, I realized many of my weakness in terms of professional skills and knowledge, and I am more motivated to develop these weaknesses into strength in the future. I believe this is a good thing that I learned from building my first professional portfolio.

MyISERN 2.0 Review

The code I reviewed is from team yellow.

1. Installation
I can download the distribution file without any problem. I also unzipped it with ease because I used the WinRAR, but my other team member had problem unzipping it while using the default window unzipper.

Since there is no installation guide, I followed the developer guide and tried to build the system. Since team yellow is using a whole new system, there is no easy runnable war file. I downloaded XAMPP and Symfony as the guide told me to. When I tried to install the XAMPP, I had problem of getting the Apache server running. However, my other team member do not have that problem. After googling several pages, I discovered that this is quite a common problem, and there are many ways to "tweak" around it. I use the word "tweak" because none of them seem to guarantee to fix the problem. I finally got the XAMPP homepage show up on my localhost after I turned off my firewall and stopped some of my IIS services, which I have no clue what those services are used for.

However, my journey is pretty much ended here. I tried to install the Symfony framework, which is a lot harder than the XAMPP. The link provided in team yellow's guide does not give any useful information and it is more suited for unix users. The "pear" command-line thing seems come up from nowhere. I searched inside the folders from XAMPP and Symfony, and I did find some things called "PEAR", I tried every single execuatable, but they did not give me any luck. I tried to refer to the guide from team lime, which is using the same framework, but team lime is using WAMP, which is something different from XAMPP, and thus did not go too well either.

My other team members are pretty much stuck as I do. I finally had to give up after like two hours of searching the internet and reading relevent materials. Although Edward is managed to get the Symfony working at the end, he did not get the web app running still.

2. Code format and conventions
I have no experience for programming in PHP, therefore I do not know how well-formatted the code is. I remember team yellow mentioned a PHP eqivalence of checkstyle in their demo, but due to the reason I couldn't get the system running, and there is no guideline on how to run the tool, I have no clue to test it out.

3. Test case
Black box perspective: Since the system is not built, I cannot evaluate this.
White box perspective: Same reason as above.
Break da buggah: Same reason as above.

4. User interface
Although I am not able to build the system, I am able to see part of the website in my browser from those PHP files. The interface is very clear, and I like the coloring of the table cells which makes the whole page pretty neat. However, since these are partially of the interface, I cannot really evaluate it.

5. Three Prime Directives

Since the program cannot be built, it does not accomplish a useful task. As an external user, I am not able to install and use the system. As an external developer, I am not able to enhance the system easily, maybe I could get it working after putting considerable amount of effort into it.

6. Summary and lesson learned
From this review, I once again realized how important the documentation can be to a system. I had terrible experience working with software that has bad documentations. I do admire the courage of team yellow to take on a brand new system. Here is one suggestion I have: create a detailed installation guides with A LOT of pictures in it, you can safely assume the users have no knowledge of any tools you have used here, which is probably true for most of the class. Do not refer to any other online guides, they might not suit your system the best.

Prime Directives Redux

For each tool or technique, please provide one or more concrete examples of how it satisfies each of the three prime directives. If you feel the tool or technique does not apply to one or more of the three prime directives, please discuss why.

1. Interactive Development Environments (Eclipse, VisualStudio, etc.)
These IDE tools satisfy PD 1 because they obviously accomplish the task of developing software by providing an integrated environment with editor and compiler. The programmer can easily write programs and test the code all within the IDE.

These IDE tools also satisfy PD 2 because in this case, the developer, or programmer, is the main user. Since programmer’s tasks are to write programs and test programs, and these IDE tools can successfully accomplish these tasks, it indicates that the user can install and use these tools.

In terms of PD 3, these IDE tools score differently. If the IDE is open source, it is quite easy for an external developer to enhance the system since the developer can know about what is going on inside the system, assuming the system provided sufficient documentation. On the other hand, if the IDE is not open source, then it all depends on how much documentations the IDE provides, and how much restriction is applied. For example, Plug-in, which is a small portion of code that attaches to the system to enhance certain ability of the system, is usually allowed, and it is often easy to write with the provided API of the system. However, redesign of the system, such as major algorithm change, is commonly prohibited for closed source systems.

2. Coding Standards and Coding Standards Compliance Tools (Checkstyle, etc.)
This technique and the corresponding tools satisfy the PD 1 because they accomplish the task of ensuring a standard, consistent, and readable coding style through out the program by either enforcing a formal coding standard or automatically formatting the code with software tools.

This technique and the corresponding tools satisfy the PD 2 because they provide an easy way to format the code of a program, without the developer level requirement. For example, the users just have to follow the coding standard to write consistent and readable code, and they are not required to understand the rational behind the standard. Also, the users just have to run the coding standard compliance tools without knowing how the tools reformat the code to make it match the standard.

This technique and the corresponding tools also satisfy the PD 3 by giving control to the developer. The developers can adjust the coding standard easily according to their needs. For example, the developer can simply add additional rules to the compliance tools when they need it, and the new rules would be automatically applied to the whole program when the tool runs.

3. Build Systems (Ant, Make, etc.)
These tools satisfy the PD 1 because they successfully accomplish the task of building up a runnable file for the project by breaking down the project to separate components and create dependency among these components.

These tools satisfy the PD 2 because the developers and programmers, as the users, can use them relatively easy. These tools are usually well-adopted in its own domain, so the documentation and support are sufficient to allow the first time users to install the tools successfully.

These tools also satisfy the PD 3 because the developers can customize the build files to fit the desire of different projects. It is also independent to the IDE, so the developer can choose whatever IDE they feel comfortable with to develop the project.

4. Automated Quality Assurance Tools (PMD and FindBugs, etc.)
These tools satisfy the PD 1 because they accomplish the task of improving the quality of a program. Base on the tools, different aspects of the quality can be improved: optimization, subtle bugs, logical error, code convention, etc.

These tools may not satisfy PD 2 too well because most of these tools do not run alone, and they need to integrate with some other build tools in order to be used easily. Although this is not hard for a programmer, it could be troublesome sometimes.

These tools satisfy PD 3 because the developers can configure the tools in various ways so that they can check whether some certain aspects, or quality, of the program have been obtained. It allows the developers to develop different projects but have an overall guaranteed production quality.

5. Black and White Box Testing
This technique satisfies the PD 1 with the assumption that the testing are useful testing. With useful black and white box testing, the quality of the program is improved. However, if the testing is not good or useful, it means nothing to the program and thus does not accomplish a useful task.

This technique satisfies the PD 2 to a certain degree because with good black box testing, it implies the system is usable, and with good white box testing, it implies the system is stable. Together it gives the ability to use the system for the users. Again, this is under the assumption of the testing is good and useful testing.

This technique satisfies the PD 3 with the same assumption. For example, the developers writing black box testing do not need to know the internal structure of the system, yet with sufficient and high-quality testing which simulates the users’ tasks, the quality of the system will be enhanced. The more testing the system can pass, the higher quality of the system will have. Of course, granted those testing are useful ones.

6. Automated Testing Tools (JUnit, HttpUnit, etc.)
These tools satisfy the PD 1 because they provide an easy way to write tests and run test for a program. They provide predefined functions which are frequently used and often helpful for writing tests, and it simplified the programmer’s job of building a test case from scratch.

These tools satisfy the PD 2 when they have sufficient documentation and support. After all, it is not helpful to have these testing tools but the programmers do not know how to write them.

These tools satisfy the PD 3 because these tools enable the developers to create test cases in a more consistent way and thus easier to maintain. With these tools, the scalability of the testing can be increased in a more efficient way because they are well-organized and automated through small incremental build-ups.

7. Configuration Management (CVS, SVN, etc.)
These tools satisfy the PD 1 because they accomplish the task of providing a way for collaborative software development. Different developers can cooperate efficiently by using these tools to maintain a master copy of the code and still develop on their own copies.

These tools satisfy the PD 2 and PD 3 together because as the developers use these tools, they can keep track of what the other developers are doing and ensure that everyone is staying on the same stage, which can help to produce more high quality code.

8. Issue Driven Project Management
This technique satisfies the PD 1 by providing a way to manage the project process.

This technique is not really applicable to the PD 2 since it is only a technique for software development.

This technique satisfies the PD 3 because it keep tracks of every step of the development by a series of issues, which makes it easier to trace back and modify in the code according to the issues, hence gives higher quality of code.

9. Use Cases
This technique satisfies the PD 1 because it provides an easy understanding of what the system is able to do and how should it be done by describing them in use cases, which are essentially user stories and scenarios.

This technique is not really applicable to the PD 2 since it is only a technique for software development.

This technique satisfies the PD 3 by guiding the design and implementation of the system toward the users, who determine if a system is useful or not. By applying this technique, the developer would have a higher chance to develop system that satisfies the users’ needs, in other words, a higher quality system.

10. Software Review
This technique satisfies the PD 1 because a review can give useful feedback to the developer. It accomplishes the task of acquiring feedback about the system.

This technique is not really applicable to the PD 2 but it is related to the PD 2 since the usability of a system is closely tied to how much the reviewer can use the system.

This technique satisfies the PD 3 because the feedback from a review of the system can help to improve the design and implementation of a system, which in turns brings up the quality of the system.

11. Agile Methods (XP, Scrum, etc.)
These techniques satisfy the PD 1 because they accomplish the task of allowing software development in an agile way: change is usual, frequent, and good, and it should not be hard to make change.

These techniques are not really applicable to the PD 2 since they are only techniques for software development.

These techniques satisfy the PD 3 by adding “agility” to the software development process, which allows the system to be changed frequently without too much penalty, and adopt the new requirement.

12. Open Source Licenses (GPL, CPL, etc.)
These licenses are not really applicable to the PD 1 because they have nothing to do with the functionality of a software system.

These licenses satisfy the PD 2 by allowing more people to use software freely that are open source, and thus create more usability.

These licenses satisfy the PD 3 by allowing developer to enhance or change the open source software the way they want without restrictions or with minimal restrictions.

13. Online Hosting Services (Google Project Hosting, SourceForge, etc.)
These tools satisfy the PD 1 because they provide an easy way to host a software development project.

These tools satisfy the PD 2 because they are well-adopted to specific domain and have great community support, thus they are very easy to use.

These tools satisfy the PD 3 because the developer can easily host their project without the hassle of setting a server. This would greatly increase the ability of personal or small group software development.

MyISERN 1.3 Review

The code I reviewed is from team blue.

1. Installation
I can download and install the code without any problem. There is a jar command to create a jar file, but I believe that is what is left from the last group since the file is named as "myisern-1-green.jar". All the QA tests are passed except for the Emma, which complains about the missing of the coverage.xml file. I would recommend the team to model their program after the StackStripes, which should easily fix this problem. There is a readme.html file comes with the package, but again, it is something from the last group.

2. Code format and conventions
The code do not violate much rules, however, there are some private variables are not commented in both the model and action bean. Other than this, there is no big problem.

3. Test case
Black box perspective: Only the listing functionality seems to be working correctly. Everything other than that seems incomplete. Adding or editing buttons would cause the program to crush.

White box perspective: Since Emma did not pass and there is currently no JUnit testing written, there is not much white box testing are being done.

Break da buggah: Clicking on the adding or editing button can crush the program.

4. User interface
The interface of website is very straight forward. The screen estate is well preserved since the program is still usable with only half of the monitor size. Although I would prefer some "Back" buttons that allows the users to navigate back to the previous page, as well as a link back to the homepage.

5. Summary and lesson learned
Overall, team blue's code still has a lot of work to be done in order to complete all the core functionalities. Consider this is only a work-in-progress result, it is acceptable. Besides that, the team seems to be on track and working towards the correct way.

Stack Stripes Extension

Source code

This assignment is very straight forward, and I have completed all the tasks. However, there are some obstacles I encountered during the process.

The first problem was the Emma error. It showed error on missing the coverage.ec file on the first time I ran verify test with the fresh code from the downloaded package. However, this error disappears after I try to run the junit test. According to the discussion on the class website, it might be caused by launching the Tomcat server besides the project’s directory. I tried to reproduce the error by launching Tomcat on the root directory, but it did not work somehow.

The second problem was the concurrent exception when I tried to create the action for the Double It button. Since this is a web application, we can only run it over the browser. The error message page was a blast for me when the first time it showed up. I was a little clueless at the beginning because I was expecting some error message in the console from eclipse. Then very soon I notice the error message was showed in the error page like they would in the console. With those messages, I was able to fix my bug very quickly.

There were also many minor problems while I tried to go through all the tasks, such as how to launch Tomcat server in different ways, or create new forms in the JSP page. However, they are very minor and got fixed very fast.

Overall, this assignment is quite easy, which is what it supposes to be. From this assignment, I have gained a rough image how the client-server application should work. Also, I learned many new concepts, such as servlets, JSP, JSTL, etc. This assignment only reflects a tiny portion of the web application, and I believe as the semester go on, I will learn a lot more about it.

WebAppQuestions

Questions:

1. Explain in your own words the meaning of the web "request-response cycle".
This is the cycle where the client, usually represented as a user, sends out a request to the server, usually represented as a website, and then the server gathers the necessary information to construct a response, and sends back the response the client and waits for the next request to complete the cycle.

2. Explain how servlets facilitate processing of the request-response cycle.
The servlets use the ServletRequest interface to define methods for getting information from the requests, which contains the data passed between a client and the servlet; and it uses the ServletResponse interface to defind methods for constructing responses, which contain data passed between a server and the client.

3. How do you login to the Tomcat Manager?
In order to login to the Tomcat Manager, the user must first start up the Tomcat server, then open the browser and type in http://localhost:8080, click on the Tomcat Manager link, where the user will be asked for user name and password for login. The information is defined in the file $CATALINA_HOME/conf/tomcat-user.xml.

4.What is the Tomcat Manager used for in the StackStripes application?
In the StackStripes application, the Tomcat Manager is used to deploy and undeploy the application and maintain the sessions for the application.

5. What is the directory and file layout of an installed web application like StackStripes? (This is NOT the same as the directory and file layout of the StackStripes distribution!)
The directory will be named after the application, for instance, StackStripes. Then inside the directory, there are META-INF and WEB-INF folders, and some jsp files which might be under some subfolders. The jsp files define how the web application will look like in the browser. The META-INF folder contains the manifest file for the application, and the WEB-INF folder contains the classes files for the application, and the library used in the application, which usually are jar files. The WEB-INF folder also contains a web.xml file, which is the configuration for the Stripes.

6. How do you build a war directory structure in Ant? Where is this accomplished in the StackStripes application?
To build a war directory structure in Ant, a target must be created. This target must invoke the Ant task “war” to create a war file and specifies a configuration file usually named web.xml. In the StackStripe application, this is done inside the war taget in the build.xml file.

7. How do you install a war directory in a running Tomcat server? What information does the Ant task need to accomplish this?
One way to deploy the application in a running Tomcat server is to set the autoDeploy attribute to “true”. Alternative way is to do it via an Ant task. The necessary information for the task include: the war file, and the deploy parameters and the install URL.

8. What is the "Model2" architecture? What are its advantages?
Model2 is an architectural pattern used in software engineering. It separates the data (model) and user interfaces (view), and uses a controller to connect the two components, so that they do not affect each other when modified. It has the greater scalability and modularity.

9. What are JSP pages? How are they related to servlets?
JSP pages are used to create web content that has both static and dynamic components. It relates to the servlets by accepting the dynamic request.

10. Why is there a delay when retrieving a JSP page for the first time? Where is the Java code for that page stored?
This is because the JSP page must be compiled into a Java Servlet, which is a piece of pure Java code to go through, and it does not require this process after the first time access. It is store under the $J2EE_HOME directory.

11. What are JSTL tags? Why are they useful? What is an example JSTL tag from the StackStripes system?
JSTL tags are a collection of tag libraries that provide common functionality while writing JSP pages. They are useful because they fit in HTML better than Java code, and provide reusability as well as Expression Language, which is very convenient. In the StackStripes system, the JSTL tag is used.

12. What are Stripes tags? Why are they useful? What is an example Stripes tag from the StackStripes system?
Stripes tags are the ones start with the prefix “stripe:” They are useful because they link the JSP pages to the Java classes automatically and provide very powerful functionality. In the StackStripes system, the Stripes tags are used.

13. What is HttpUnit? How is it different from JUnit? Why is it useful? What is an example use of HttpUnit from the StackStripes system?
HttpUnit is open source software that can provide automated testing by emulate the browser behavior. It is different from JUnit because it provides easy way to write tests that can simulate the user behavior on a web, such as clicking a link. It is very useful for testing web application. In the StackStripes system, it is used to test the task of user clicking the buttons on the web.

14. What needed to be changed in order to implement the Double It button? What didn't need to be changed? What did you learn about the MVC design pattern from this exercise?
To implement the Double It button, a new JavaBean method for the double operation must be created, also a new form must be created in the JSP page. Everything else that worked before do not have to be changed. This is the advantage of MVC design, it separate the data, which is the Stack model, with the view, which is the JSP page. So when we change the JSP page, it does not affect the data.

15. What are the equivalence classes that need to be tested for the Double It button?
The class needed to be tested for the Double It button is StackActionBean because it is related to the user interface (view). The StackModel class has nothing to do with it, thus it does not require testing.

16. Provide two screen images of your new StackStripes application with the Double It button, one showing the page before and one showing the page after hitting the "Double It" button.
Before:

After:

17. What is the singleton design pattern? What is an example of its use in StackStripes? Why is it needed?
The singleton design pattern enforce there is always only one instance exists for the class. In the StackStipes system, the stack is implemented in this way. This is needed because it prevent multiple stack is being used by different users.

18. Some of the StackStripes tests exercise code on the "server side", while others exercise code on the "client" side. Which test classes exercise code on the "server", and which exercise code on the "client"? How does Emma deal with this to create appropriate coverage data?
The StackModel is tested on the client side, and the StackActionBean is tested on the server side. Emma combines the coverage from both side to create appropriate coverage data.

19. Running 'ant -f junit.build.xml' results in the following target invocations: tomcat.check, tomcat.undeploy, compile, war, tomcat.deploy, junit.tool, junit.report, junit. Explain what each of these targets do.
tomcat.check – check if Tomcat server is running
tomcat.undeploy – undepoly the application if there is one running on the server
compile – compile the source code
war – create the new war file using the web files
tomcat.deploy – deploy the application on the server
junit.tool – runs the JUnit tests
junit.report – report the JUnit results by creating HTML report file
junit – ensure the junit.tool and junit.report has been run

20. (Optional) If you have experience using one or more other web application frameworks, discuss your initial reactions to Stripes. How is it similar, or different, or better, or worse than your previous experience?
I have used a little ColdFusion framework before, but I only set up the database on the server side and it is a local server as well. Many things are quite similar in the two frameworks, they both have their own tags to do specific tasks that are more powerful than normal HTML tags, and they both have a manager-like feather to maintain the sessions.

MyISERN 1.2

Milestone release
User Guide
Developer Guide
Release Notes

This assignment turned out to be very repetitive, and also very difficult on the details. Although we have finished all the tasks, they are not done in a very elegant and efficient way.

The command line interface for inputting data is more complicated than I thought. By complicated, I mean the tons of if and else causes and several infinite loops inside almost every function. The backbone of the program is relatively simple, but that is only based on the assumption of the user do not input error data and knows what to input. A lot of effort has been spent on error checking. However, there are still some minor bugs in the program. We did not notice these bugs until we did the data input at the very end, where we did not know most of the data. If the data is complete and correct, the program will work perfectly fine. However, if the data is incomplete, the program will throw out a bunch of errors due to the schema requirement. Although the errors are all caught by the error checking and indicated, fixing them is such a harsh and tedious job.

What makes this assignment very repetitive and boring is the data input part. It is very often that the information is incomplete, and we will have to end up guessing. Also, because we assigned different data for different group members, such as one person does the researchers and another person does the organization, the program has a serious problem when merge these data together. The different names of organizations and researchers, which are chosen by different group members, give out many invalid links errors, even though they are essentially referring to a same organization or researcher.

This assignment once again showed the importance of face-to-face group work. At the last minute when we tried to figure out the data errors, we were using instant messengers, which was extremely inefficient. Also, a good planning ahead is still not achieved. Although we took our time to scratch out the structure of the program when we met, there are still many changes happened during the actual implementation. The failures to foresee these changes gave us quite a bit of troubles.

In terms of improvement to the system, there are many can be done. First is the Emma testing. We did not cover most of the methods in the editing class, which has many user input inside. Although Professor Johnson said it is not quite possible to do a detailed testing case for it in one week, I still feel unsatisfied for the low coverage of code. On the other hand, a more strict and accurate error checking should be implemented. The current system will still miss some error input.

Overall, this is another lengthy and hard assignment. Well, I think the good thing is I am starting to get used to it.

Use Cases

Use Case Wiki Pages

This is not a really difficult assignment, since we have gathered the necessary information we need to create the use cases.

We decided to use a use case template to keep our uses cases consistent. This is easily done. After several Google searches, we found some templates that might fit our needs. We modified the templates so it matches our use cases. At first we tried to fill out the use cases using tables, but then very soon we found out it is almost impossible to have a nicely formatted table in the Google project wiki pages. The only way to preserve the new lines is using the code block, which has some weird color when the content is not a real code. Also, some new lines are not preserved somehow. However, we figured this would be the best we can do in these Google project wiki pages.

In this assignment, I have a better understanding of use case. When writing a use case, consideration for both the user and the system are necessary. Also, a clear flow of how the process will be very helpful. Although use case is better when writing as scenarios, it is very easy to get wordy. A balance point between detained description and concise story is important. Lastly, use case driven design seems reasonable approach for developing software. After all, the users are the ones who determine whether the software satisfy their need. Knowing how they would use the software would save a lot of unnecessary mistakes.

MyISERN 1.1 Review

This time we are able to choose the author to review. Therefore, I chose one of the graduate students group to see how they are doing differently from us. The author I picked was Andrew Wong from the Silver group.

Installation Review:

The source code is downloaded successfully. The Google project page also includes the wiki pages for user guide, develop guide, and the release notes. Following the instruction in the user guide, the jar file is successfully created. The verify task ran successfully also, which implies the JUnit, Checkstyle, PMD, and FindBugs are all passed as well. However, when I tried to execute some of the commands to generate the tables, I saw some really chaos and random display instead of a nicely organized table. It took me a while to figure this out: the author is doing the display based on the column numbers, which is obviously a number greater than the normal width of a command prompt window. I tried to resize my command prompt window to 800 columns, and then a nicely structured table finally showed up. The information is mostly horizontally listed, which requires a quite a big width for the window to display them correctly.

I would recommend the author to put this issue into the user guide, since normal users would not resize their command prompt window to verify the display, and they would simply consider the program is not working.

Code format and conventions review:
There are not many code violation can be found. However, for most of the files, the private data members are not documented. (For example, line 46-48 in MyIsernXmlLoader.java) Other than that, the code are well written and easy to read.

Test case review:
Black box perspective: The program does print out the information correctly when there is enough room to display them. However, duplicates and invalid links in the data files are not shown. I would expect to see, for example, at least an error message showing that there is duplicate researcher in my researchers XML file, so that I can go ahead and change it. Other than that, the black box testing seems to be working pretty well.

White box perspective: The Emma report is as follow:
Emma Coverage summary
class: 100% (1/1)
method: 97% (9/10)
block: 100% (497/508)
line: 100% (104/108)
Besides one method that has not been covered, all the other codes are tested. I looked into the Emma report and found out the non-tested method was a method that involves the enum type classes, which Andrew has been mentioned in the discussion. I personally do not know much about enum type, and it seems like the non-tested methods are somehow generated inside an enum class, which is not really inside the program. With the fact that the Java development team is probably responsible for the testing for the enum class, I consider the author did an excellent job in the white box testing.

Break da buggah: There is not really a way to "break" the program, but there are some ways to cause it malfunction, or at least, not functioning as expected. The first way is mentioned before, to execute the program in a normal command prompt window, which it does not print out information correctly. Secondly, the program does not print out error message most of the time for some invalid command calls. For instance, if I invoke the “-describe –all” task by passing something other than “researchers, organizations, collaborations”, the program will simple do nothing.

Summary and Lessons Learned:
Overall, the program is pretty well written. One thing I really like about is the modulization of the program. The author breaks down the program into loader, printer, query engine, checker, and command line parser. Consider this MyISERN project would be last for two semesters, it is definitely necessary to factor the program into different components, which does not interfere each other when one gets changed. I have been thinking to modulize my whole program, and now the Silver group gives me a very good example of doing this. Despite the tremendous amount of work to modulize my current chubby program, I think it is worth the time and effort to do so.

MyISERN-1.1

Milestone release
User Guide
Developer Guide
Release Notes

This is another very challenging assignment. Although I managed to accomplish all the tasks, I feel strongly there are many improvements can be made.

The hardest part of this assignment would be the unclear requirement. Although the requirements are posted on the course page, many of them are not clarified, especially the one that asks for link verification. Even though Professor Johnson answered it in the discussion, it still left me quite a bit of confusion. It seems like it could be done in several ways, and there are pros and cons in each way. I think this is what will happen in real life too. The customer do not always give clear requirement of what they want, or more often, even the customer themselves do not know what they want.

Another hard part of this assignment was the cooperation in the group. We started working for the different parts of the assignment, and then very soon we encountered the conflict problem while we were trying to commit our own files. Although we worked in different code, the conflict still appeared somehow. I think for student group project, commit conflict will be more often since students tend to work together around the same time and commit the code at the same time. Anyhow, we figured out the problem by merging or all updated to a same version.

Last hard part of this assignment is the testing-base design. Since our code are supposed to be tested by JUnit, I tried to avoid using void methods as much as I can. However, the requirements of this assignment seem to be still printing stuff out on the standard output. I could have made the methods return some values, such as true or false, or even a list or a map, but I really did not see the purpose of doing that. It simple violates the nature of the requirement. If the requirement is to print out something, then the methods should print out something without returning anything. After a little bit debate, we stick with the void methods.

For the possible improvement during the next assignment, I would first make sure what the framework of the program would be like, then list out all the classes, methods, and variables that will be implemented. In this way, everyone could work differently but still go towards a same goal. Besides, I would try to find a balance between the design and testing, and avoid the usage of void methods. After all, they are not good in the sense that they cannot be tested easily. Also, one thing I will definitely do is the issue organizations. In this assignment, our issue management was very poor, and I did not figure out how to edit an issue till the very end. It was simply a mess. In my opinion, the red team did very well on this. They divided the issue according to the requirement, thus for every commit there is always an issue to be related. This can avoid the redundant creation of the issues.

Overall, this assignment is not easy, but as usual, I learned a great deal of stuff from it.

MyISERN Review

I was assigned to review Jung Kim’s code this time, but by the time I was writing this review, I could not find the entry from his blog for the MyISERN assignment. Therefore, I went to his team’s Google project page to download the source code.

Installation Review:

The source code is downloaded successfully. There is no wiki page for the user guide or something like that, but after all this was not required in the previous assignment. I had no problem at all while trying to import the project into eclipse. I invoked the verify test in the command prompt, and it ran successfully. This implied the Checkstyle, PMD, FindBugs, and JUnit tests should all be passed.

Since the first MyISERN assignment is relatively simple, there is not much code added in the program. I can easily understand the code.

For the program execution, I invoked “ant jar” and it creates a jar without any problem. Then I invoke the jar file by “java –jar” command. The tables were printed out correctly. Overall, the program does what it supposes to do, and it functions correctly.

Code format and conventions review:

There are a few violations in the code:

File	Lines	Violation	Comment
MyIsernXmlLoader	152, 169, 196, *	EJS #7	Unnecessary blank line within a method
MyIsernXmlLoader	142, 159, 194, *	EJS #9	Pick more meaningful variable name or give it a comment
MyIsernXmlLoader	191	EJS #27	Name for collection should be plural

Test case review:

Black box perspective: The test does print out the table as expected. Other than that, the number of researchers, organizations, and collaboration are also tested, but that is given from the initial files. However, printing out the table is the only objective of the assignment, and the data are all given, there is not much black box testing can be done.

White box perspective: The Emma report is as follow:
Emma Coverage summary
class: 100% (1/1)
method: 90% (9/10)
block: 98% (497/508)
line: 96% (104/108)
Although the coverage is not 100%, it does not mean the testing is not sufficient from our experience of code coverage. By inspecting the testing case, I found out the reason for the missing coverage is that the main method has not been tested. However, since main method is “evil”, and JUnit is almost useless when it comes to testing of the standard output, I consider the author has done a fairly good job on the testing. Also, there is one line of error checking code is not covered. As mentioned above, the data for the assignment is given, thus an error input cannot be produce and the error checking will never be executed.

Break da buggah: I could break the program by running it outside its original folder, because the XML data files are defined such that they are located within the original folder. However, this seems a little bit too extreme to me because I think only a programmer that knows the internal structure of the program would know this could cause the program to fail.

Summary and Lessons Learned:
Overall, the program is pretty well written. It functions correctly and safely. One lesson I learned is that when the data is given, there is still no guarantee that the program will not go wrong. Furthermore, things tend to change a lot in real life, and errors usually emerge during the change. Another lessoned I learned is the importance of documentation. Not only the meaningful comment in the code is necessary, but also a user guide or manual is very helpful.