Jared's Engineering Log

Informative Workspace Code Review

2008-04-02T00:59:00.000-07:00

General Thoughts on Wicket

It was very interesting seeing Wicket in action for the very first time. I was amazed to see how empty the corresponding html pages were in comparison to their respective Java classes. Based on what I've seen from both Wicket and Stripes, it appears that Wicket is more powerful, allowing the page to be totally controlled from the Java classes (if you want), whereas Stripes seems more centered around form components and links.

Installation

Following the Installation Guide was simple enough. When it came time to modify the Project Overviewer's source code to get it to retrieve my Visual Studio Sensor project, however, I ran into several problems. Most of the problems were self-inflicted, but I did notice that this part of the installation was not documented anywhere (no guides, no powerpoint).

The Code

Overall, the code seems fine. It is well modularized and well commented both internally and with Javadoc comments. Based on what I have seen of Wicket, the code seems to be adhering to the general Wicket practices. One suggestion that I have would be to implement a base class like "PageProject.java" and have "PageIHacky.java", "PageInfoWork.java", and "PageVSSensors.java" extend it instead. This class would provide the functionality of the pages (since I envision them all to be very similar) while at the same time allowing the developer to customize the content as well. All the code would be in one place making it easier to make changes to the system.

System Issues

ant -f verify.build.xml passes, but it only passes the first time you run it per Tomcat instance. Something about the application can only be deployed and undeployed once per Tomcat instance on my computer. After talking with Fei about this, it seems that the JVM is somehow locking up the folder so it doesn't allow the web application to be undeployed (meaning it can't be redeployed properly). Because of this, the Project-Overviewer is no longer available to be used.

Documentation Issues

Overall, the documentation was pretty decent. The Installation Guide was intuitive enough, but is somewhat geared toward a user who has worked with Java, Tomcat, and environment variables before. While this may not be a large problem since the typical user of this application would more than likely be a programmer, providing a little more detail would not hurt.

Another thing that I did notice about the documentation was that the Developer's Guide did not mention anything about Wicket except that certain Wicket jar files are required libraries. Because Wicket is such a large portion of this project, acknowledging its role in the project and providing links to tutorials, examples, and other sites of interest would be a definite enhancement to the guide.

Is it Helpful?

The general goal of the application--to provide an overview of the project--is certainly a noble and worthy cause. Software engineers and developers would all like to be able to see an overview of the status of the project. However, while the goal is sound, the application itself could be better. The single directory listing of all files within the project takes up a lot of screen real estate. Right now, the project overviewer project itself takes up 2 full screens to display all of its contents. The disturbing part is that it isn't even that big of a project. Imagine a project with thousands of modules and hundreds of packages. How useful would the project overviewer be in its current format with respect to that project? Would users be willing to scroll through all those files? And if not, would users be realistically able to see what is the project overview these? These types of questions must be considered before development continues.

One suggestion that I have is to look into ways to better organize lots of content when space is an issue. Maybe displaying the files as parts of different categories such as "Most Modified", "Least Modified", etc. would allow users to get a general feel for the system without having to look through all the files.

Conclusion

While this project may still be in the early development stages, I think there is a nice foundation here from which a full fledged web application can develop. Right now a lot of functionality is hard coded into the application itself, making it very rigid and inflexible. That being said, the parts that are hard coded in seem to work fairly well so it would just be a matter supplying that configuration ability. Since it is meant to be part of the informative workspace, more research should probably be done to figure out whether the current form of this application is in line with what software developers would want to have.

iHacky Code Review

2008-03-19T02:48:00.000-07:00

General Thoughts

Overall, the system is in a very rough state. Functionality of the system is very limited and very basic. It appears that most of the work has been done on the back end setting up the database, server, and the integration with Facebook. Now that the back end is up and running, it is now time to work on the interface itself.

The Code

I have don't have much experience with PHP or with FBML so I cannot really take apart the code. One issue that I did notice was that some of the PHP pages have little or no commments. Internal comments are very important to new developers so each page should contain the necessary comments to understand the code.

System Issues

Understandably the system is in a rough state at the moment, but the aesthetic appearance of the system is severely lacking. At this point in time, functionality is far more important than beauty, but at some point the aesthetic appearance of the system should be addressed.

Also, perhaps one of the most important links on the system, the Need Help? link, does not work. Another issue with the system is that it is not possible to change your Hackystat account once you have set it.

Documentation Issues

The documentation looks pretty good overall. I didn't try to install the system on my own computer, but the documentation to do so looks pretty decent. One problem that I saw with the documentation was that the screen shot on the iHacky homepage doesn't look at all like the current system. The screen shot should be changed to reflect the current state/look of the system.

Also, in the InstallationGuide it does not specify that you have to be logged into Facebook in order to add iHacky. I didn't bother registering with Facebook because I already had a Facebook account. Since the guide did not specify that you had to be logged in I just clicked on the link. When I did so I got an error page saying that "the page you requested was not found". Normally, Facebook says the page you have requested requires that you log in if the page exists. I'm not sure if that is a problem with the way Facebook handles applications or if it is a problem with iHacky's application page, however, if I was just a regular user who has no idea that the application actually exists, I would have thought that the application was broken and would not have bothered pursuing it further.

Also, I'm not sure if the use cases are still relevant given the current state of the system. If they are no longer relevant, they should be removed or edited to reflect the current system.

Potential Problems With iHacky and Suggestions

There does not seem to be a clear, precise idea of where this system is going based upon the presentation (although it does lay out a general road map), the documentation, and looking at the actual system itself. The use cases provide some ideas of how the system will be used, but I'm not sure if they are still accurate or relevant based on the current state of the system. Hopefully the problem is simply that the use cases and other documentation that lays out the "vision" for the system are simply missing or deprecated. If that is not the case, then immediate action is needed so that the details of how the "specific communication mechanism between each user" will work (for example) can be laid out (along with all the other items mentioned in the road map).

Under the current configuration, the networking feature of the system is not really present. The road map provided in the presentation mentions some ideas on how the networking can occur, but once again it is very general. From the current system, I'm guessing that tools, teams, and projects will be used as a networking area. But even in these areas, the "vision" seems somewhat fuzzy. Like right now, the projects tab takes project data from Hackystat and displays it. But how does this network software engineers together? Are you going to generate links within the Hackystat data or is it just going to be list of projects you're working on while using Hackystat. What happens if the project is not using Hackystat? Will there be a way you can add those projects?

One solution to clear things up might be to hold a brainstorming session to figure out what aspects/characteristics/interests of a software engineer would other software engineers be interested in. This common ground could then serve as the basis for how to network software engineers together. Here is a list right off the top of my head:

Languages (Java, C, C++, etc.)
Tools (Eclipse, Visual Studio, Ant, etc.)
Areas of Interest (GUI, Web Design, Game Programming, etc.)
Projects (Current, Future, Dream, etc.)
Growth (What new areas do you want to experience?, What languages do you want to learn?, What tools would you like to experience?, etc.)
OS Platform(s)
Experience

Once you have a list then you can build your system around them and focus on providing networking options for all of them.

Conclusion

Overall, the potential of this project is really high. One problem with lots of potential is that it is difficult to narrow the focus. In reality, the narrower the focus, the better, as it is better to do a few things well then to do lots of things ok.

Hudson

2008-03-17T02:39:00.000-07:00

The CI Breakdown

To be quite honest I did not know very much about Continuous Integration (CI) until I went through the tutorial and read the article. One reason for my lack of knowledge about CI is that I have never worked on a large scale project that would require CI in order to keep the project manageable. CI can keep a project manageable by building, testing, and verifying the project often (every time the code repository changes) in order to spot issues as quickly as possible. Spotting issues right away allows for these issues to be fixed as quickly and as early as possible which makes them far easier and far more manageable to deal with.

One aspect of CI that I found to be particularly interesting is that CI is only as good as your software engineering practices. I guess in a lot of respects, it is no different than an emma or a findbugs. These tools are quite helpful but they are only helpful if you actually run them. The same is true for CI. CI is only helpful if you practice good software engineering practices like those listed below (description here)

Avoid infrequent check-ins
Avoid broken builds
Avoid minimal feedback
Avoid spam feedback
Avoid a slow build machine
Avoid bloated builds

If you avoid these CI anti-patterns as they are called, then CI will prove to be a truly beneficial tool for you. Overall, I think that Hudson and CI will be a vital tool for me in the future, as it can automatically check to make sure the latest commit to the repository builds successfully, and if it doesn't, immediate action can be taken to fix the problem.

Hudson and the Visual Studio Sensor

I was able to use Hudson to build the Hackystat Visual Studio Sensor project that I am currently working on. Using Ant to build C# projects is somewhat tricky and better handled through NAnt, which is not supported by Hudson. Therefore, I had to go for the command line build option that comes with Hudson. Basically what I had to do was turn the command line instance into an instance of the Visual Studio 2008 Command Line. From there I could just run "devenv %PATH%VisualStudioSensor.sln /Build" to build the system. To set up the Visual Studio 2008 Command Prompt, I copied the contents of the vsvars32.bat file (which sets up the Visual Studio 2008 Command Prompt) into a .bat file which I called buildsensor.bat. At the end of the .bat file I put the "devenv %PATH%VisualStudioSensor.sln /Build" line to build the system. Luckily Hudson defines an environment variable %WORKSPACE% which can be used to get to the files checked out of the repository.

Running the Build on the CSDL Server

In order to run the build on the CSDL server, you would have to install Visual Studio 2008 and set up the path to the buildsensor.bat file in Hudson. This seems like somewhat of a pain to do just to build the system so I am currently looking into various alternatives. One alternative is to use csc.exe which comes with the .NET framework. Basically it is a C# compiler which can be used to compile .cs files. I am not sure how how extensive the compiler is or how it compares to the "Build" command in Visual Studio, but it looks promising and would require much less space (Visual Studio requires several gigabytes). The other alternative would be to tackle C# building in Ant. There appears to be an Ant library for .NET building, but I believe it uses csc as well to build the project. Other than how to build/compile the system, the Visual Studio Sensor project can be setup relatively easily:

Select the "Build a free-style software project"
Setup the Subversion repository by linking the google code repository and providing the proper authentication
Select the "Poll SCM" option under "Build Triggers" and schedule it as "* * * * *" (every minute check the repository for changes)
Then under "Build" check the "Execute Windows batch command" option and setup the path to the buildsensor.bat file
Then setup the "Post-build Actions" with possible email notification

Visual Studio Sensor Code Review

2008-03-12T10:55:00.000-07:00

Documentation/Guides:

In general people seemed to like the documentation and guides (user and developer) that came with the sensor. There were three areas that needed further clarification or modification.

The first area was that NUnit and two NUnit tests were included with the original distribution, but documentation for its installation and how to run the tests was not created. In actuality, NUnit should have been removed from the distribution before it was released as the tests serve no real purpose and it would simplify working with the source code. A later distribution, released last night, corrected this issue.

The second area that needed clarification was "VisualStudioSensor - For Testing.AddIn" Some of the people working with the source code had errors saying that their project could not find "VisualStudioSensor - For Testing.AddIn" file. Further clarification of this must be included in the Developers Guide to help those working with the source code.

Lastly, it is apparent now that the sensor is only compatible with Visual Studio 2008 that includes the latest .NET Framework 3.5. The handlers and everything else we were using really hadn't changed much from Visual Studio 2005, so I had assumed (which is always dangerous) that the sensor would be compatible as long as the user had the .NET Framework 3.5. Also, apparently not all versions of Visual Studio 2008 come with .NET Framework 3.5 so I modified the guides to indicate that users and developers may have to install this as well.

Bugs/Limitations

Other than the NUnit reference error, the biggest limitation of the system is that only one instance of Visual Studio can use the sensor at a time. Because Visual Studio does not allow more than 1 solution to be opened in an instance at a time, this could present a real problem for developers who want to work with more than 1 solution at a time. At this point in time, I am not sure how to fix this problem but I will definitely look into possible solutions for this as it is a major system limitation.

Also, several people thought the data collected by the sensor was not very useful and was somewhat limited. I am not sure if this is really a Visual Studio sensor issue or an issue with the Hackystat sensor data type conventions. When developing the sensor we tried to follow the Eclipse sensor quite closely so that we could adhere to the sensor data type conventions. All I can say on this at the moment is it is my opinion that the user shouldn't be so interested in the data that is collected by the sensor, but rather in the ways that the data can be used, measured, and displayed. But having said that, this is something we will definitely look into further.

The sensor does not show it is running when a new solution is opened (and the other solution is closed). This type of feedback would be useful to a user who is working with multiple solutions in Visual Studio and will definitely be added to the next release (if possible).

Suggestions:

Increased feedback on the status bar (perhaps a verbose mode) to give the user a better sense of what is going on.
Limit the number of characters per line.
Add DevEvents when the user accesses help.
Add DevEvents for debug and release.
Improve user/developer documentation.

Ambient Hackystat Code Review

2008-03-04T22:28:00.000-08:00

The code that was reviewed can be found here:
Ambient Hackystat Code Reviewed

Installation and Setup:
Based on the documentation provided in the Developers Guide I was able to successfully install and setup the server for use on my computer. One problem with the code is that a person cannot verify whether the system is actually running as expected since it does not pass the ANT task verify.build.xml. It fails at the JUnit task which is troublesome even though the team had mentioned this during their presentation. The main reason is because it is not documented in their Developers Guide. In fact it says to "invoke ant -q -f verify.build.xml to make sure everything is running fine." If an outside developer were to come and try to use the system, they would think that they have not installed the system correctly. Another problem with the setup and installation is that the team assumes that the user is familiar with Hackystat. While this is not an unreasonable assumption, it may cause problems for a user who has not used Hackystat before as the Developers Guide only points the user to the Hackystat homepage. One idea might be to add more specific information involving Hackystat such as registering and setting up both ant and Eclipse sensors. Since this is an open source project, you would like to try to include as many users/developers as possible by making setup and installation as easy as possible.

Part of the setup task involved being able to change the color of the Ambient Orb from whatever the current color of the orb was to the color GOLD. For good measure, I also changed the orb's animation to HEARTBEAT. The XML file that I used to make these changes is shown below:



<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<triggerActionPair>
  <interval>60000</interval>
  <trigger>
      <project>
          <host>http://dasha.ics.hawaii.edu:9876/sensorbase</host>
          <projectName>Default</projectName>
          <username>default@hackystat.org</username>
          <pwd>thisisnotarealpassword</pwd>
      </project>
      <triggerType>LAST_BUILD</triggerType>
      <comparation>EQUAL</comparation>
      <value>FAILURE</value>
  </trigger>
  <action>
      <deviceType>AMBIENTORB</deviceType>
      <deviceId>123-456-789</deviceId>
      <actionType>CHANGE_COLOR</actionType>
      <value>GOLD</value>
  </action>
  <action>
      <deviceType>AMBIENTORB</deviceType>
      <deviceId>123-456-789</deviceId>
      <actionType>CHANGE_ANIMATION</actionType>
      <value>HEARTBEAT</value>
  </action>
</triggerActionPair>
<triggerActionPair>
  <interval>60000</interval>
  <trigger>
      <project>
          <host>http://dasha.ics.hawaii.edu:9876/sensorbase</host>
          <projectName>Default</projectName>
          <username>default@hackystat.org</username>
          <pwd>thisisnotarealpassword</pwd>
      </project>
      <triggerType>LAST_BUILD</triggerType>
      <comparation>EQUAL</comparation>
      <value>SUCCESS</value>
  </trigger>
  <action>
      <deviceType>AMBIENTORB</deviceType>
      <deviceId>123-456-789</deviceId>
      <actionType>CHANGE_COLOR</actionType>
      <value>GOLD</value>
  </action>
  <action>
      <deviceType>AMBIENTORB</deviceType>
      <deviceId>123-456-789</deviceId>
      <actionType>CHANGE_ANIMATION</actionType>
      <value>HEARTBEAT</value>
  </action>
</triggerActionPair>
</configuration>

No changes to the code were necessary to make the changes occur, but I did add print statements to it so that more information would appear while the server was running.

Overall the system seems very modularized, logical, and well put together. As with any review, however, the issues are of the biggest concern.

Top 5 System Issues:

Commenting/User Feedback
Documentation
JUnit tests
Error detection
Orb color change time interval

The biggest issue with the system is the lack of internal comments within the code and the lack of user feedback when the server is running. For someone who was not involved in this project, it was difficult at times to go through the code to figure out what exactly each part did as there were no internal comments to provide the necessary and helpful descriptions. The Javadoc comments were pretty good, but I was often forced to literally figure out what each part of each method did if the method was lengthy or if the purpose of certain parts were not clear from the Javadoc comments.

When the server is actually running, it would be nice to see more helpful user feedback (or at least provide an argument to activate user feedback) so that users can see what is going on as the system is running. Right now, once the server starts up (I am using the Last Build trigger) all I get is "INFO: LastBuild: active. org.hackystat.ambientdevice.trigger.LastBuildTrigger activate". When I first started using the server, I didn't even know what this meant so I had to go into the code and look to see where these statements came from.

Documentation issues (somewhat understandable at this point in time) needs to be brought up to the level of code. At this point in time, the code seems to be way out in front of what the documentation covers as even the types of triggers that are implemented and are shown in the Triggers wiki page do not match.

JUnit testing remains a large issues as the potential developers who check out the code cannot determine whether the system is functionally correctly or whether their setup/installation is incorrect.

Some error detection needs to be added to the main method to catch errors in the configuration.xml file as it is pretty easy to cause the system to crash right now. All I did was change the trigger type to an invalid enumeration and I got an ugly error message (although a developer should be able to figure out what is wrong) with no recommendation on how to fix it.

The orb takes way too long to change color and/or animation. I've heard from another person testing the system that it took nearly an hour for the orb to change color. On average it seems to take somewhere between 10 and 20 minutes for it to change. Either way, the lag time is a problem that may not be able to be resolved, which raises the issue of how time sensitive triggers, such as commits, will be handled.

Recommendations:

Solidify the interfaces so that they actually help determine what needs to be in each class that implements them. Right now, there seems to be some inconsistency between the different triggers (for example) as far as what is included in them--the CommitTrigger.java is missing the getProject() method--and what needs to be in them.

Remember that this is an open source project so the 3 Prime Directives need to be followed thoroughly. Keeping these prime directives in mind will really help with the documentation and commenting issues that currently exist.

JUnit testing issues must be resolved so that verify will pass. When I was working on it earlier I was getting this JAXB error which I managed to correct by updating Java 6 to update 5. Currently I am getting this org.apache.xerces.dom.DocumentImpl.getXmlStandalone()Z error which occurs when the HackystatTriggerTestHelper.java tries to get a new instance of the sensorbase. So basically, maybe post the problems your having with JUnit to the class discussion board so that we can all take a look at it and see if we can solve it? Because right now I am not even sure I am getting the same errors as you guys are.

REST

2008-02-24T23:33:00.000-08:00

REST stands for REpresentational State Transfer and is an architectural style used for web applications and HTTP related domains. REST is based upon five key principles (from http://www.infoq.com/articles/rest-introduction):

Provide a URI for every resource/noun/thing
Use links (URLs) to provide more information on a resource
Utilize standard methods (GET, POST, PUT, DELETE)
Provide multiple representations of a resource
Communicate statelessly (separates the client and server to simplify interaction)

In general, some of the benefits of using REST include:

Caching support
Simplifies the client side application
Independent of the server which allows for greater server scalability
Easier integration of parts and applications

Should the Visual Studio Sensor project provide a RESTful interface?

The Visual Studio Sensor relies on the Hackystat SensorShell to transmit data to the Hackystat SensorBase. Because of this the Visual Studio Sensor project does not have to provide a RESTful interface as it needs only to successfully communicate with the SensorShell (which then in turn transmits data to the SensorBase). Since the SensorShell is a client-side "middleware" library that is an independent module of Hackystat (and subsequently part of another project under the Hackystat domain), whether the SensorShell provides a RESTful interface or not is beyond the scope of the Visual Studio Sensor project.

Does the Hackystat API obey REST design principles?

The Hackystat API does obey REST design principles. It utilizes URIs for users, projects, sensor data types, and sensor data. In addition, the sensor data type resource collection incorporates links to point to more information for each individual resource. The Hackystat API also uses standard methods which are the HTTP protocol methods GET, POST, PUT, DELETE, and HEAD. Lastly, communication is handled in a stateless fashion as it does not have to keep track of client states in order to communicate. All in all, the Hackystat API seems to follow the REST design principles to the letter.

Does the Hackystat ProjectViewer obey REST design principles?

The Hackystat ProjectViewer does not obey REST design principles and instead relies on RPC (Remote Procedure Call). It still incorporates the use of URIs but relies on methods or "verbs" rather than on resources or "nouns" like a REST design would.

Introduction to Hackystat Framework

2008-02-11T01:20:00.000-08:00

I was able to successfully complete all tasks in regards to introducing myself to a software engineering measurement collection and analysis (through Hackystat). I read through the relevant tutorials and documentation, successfully installed the Eclipse sensor and Ant sensor, and was able to send data to my public Hackystat server account using the example system StackyHack.

Overall, it took me about 3 hours to read through the documentation, install the system, and troubleshoot. There are numerous tours, tutorials, and user guides that are provided with Hackystat. The documentation provides a solid introduction and foundation from which a user can learn about and get a feel for the Hackystat framework. Because of all the documentation, it took me about 2 hours to go through all the various parts. Installing the system was actually relatively simple consisting of just unzipping archives, creating environment variables, and moving files to appropriate directories. This portion did not take more than 20 minutes. I did have to spend about 40 minutes to troubleshoot my Hackystat connection to the server. The connection worked perfectly with Eclipse, but Ant proved to be a little more difficult. Turns out that you can't put the quotes for the ANT_ARGS environment variable that are shown in the documentation . Also, I had the sensorshell.properties in the wrong directory which did not help matters. Other than those general issues of familiarizing myself with a new framework/system (terminology, following setup instructions, etc.), those were the only issues that I encountered.

Somewhat ironically, Hackystat will help me to develop additional sensors for it. The reason I say that is because it will help track my software development process, so that my teammate and I can determine whether our development process is following a healthy trend (when viewed through the telemetry viewer). If our development process is following a healthy trend, then we can continue following our current procedures and processes. However, if the trend is not healthy, then adjustments will need to be made otherwise our sensors will most likely not be any good because our development process is flawed (too little coverage, too many code issues, too few commits, etc.).

All in all, Hackystat seems to be a good example of the three prime directives for open source software engineering:

The system successfully accomplishes a useful task.
An external user can successfully install and use the system.
An external developer can successfully understand and enhance the system.

It satisfies prime directive #1 because the system provides useful metrics on software engineering processes which is extremely helpful and useful to software developers. It satisfies prime directive #2 because I (who for the most part am an external user) have just successfully installed and used the system. Lastly, it satisfies prime directive #3 because you can join the project, check out the subversion repository and work to improve the current features, or in the case of myself, add new sensors to the framework.

After formally introducing myself to Hackystat, I look forward to the opportunity I have to improve the framework (by adding new sensors) and to utilize its abilities/metrics to improve my own software development process.

My First Professional Portfolio

2008-01-28T08:50:00.000-08:00

Building my first professional portfolio was a very valuable experience. Not only did I gain a valuable tool that will hopefully provide with me an edge over other potential job seekers, but I was also able to learn about myself during the process.

Perhaps the greatest asset that I gained from creating my professional portfolio was that I was able to reflect on where I stand in terms of my technical background and my experience in the field of Information and Computer Sciences. Upon my reflection I realized that not only do I need to gain more experience through jobs, projects, or otherwise, but I also need to bolster by technical experience by adding more depth to the breadth that I already have. Ideally, I would want to improve my depth at the same time that I improve my experience, but I will gladly study on my own time if necessary. Hopefully, ICS 414 will help me in both areas as I will gain a showcase project in my Hackystat Visual Studio sensor, and at the same time, improve my depth in Java programming and software engineering tools and practices.

Working on my professional portfolio has also made me realize how powerful a tool a blog can be. A blog provides a nice place where you can really showcase your interests and your passions in a free and relatively well organized means. Sometimes it is hard to express or hard to get people to listen to ideas not pertinent to the subject at hand. A blog can provide a great snapshot of your overall interests and passions. I hope to use my blog in this fashion.

The great thing now is that I know what I need to work on and I have a professional profile that I can use to showcase new achievements. Overall, I would have to say that having to create a professional portfolio was a very positive experience even though it brought to life some not so pleasant facts.

33.PrimeDirectivesRedux

2007-12-09T18:26:00.000-08:00

1. Interactive Development Environments (Eclipse, VisualStudio, etc.)

PD2 - Interactive Development Environments (IDEs) do not really apply to external users unless they are going to launch the system from an IDE. In that case, many IDEs provide support for running systems in them.

PD3 - IDEs are very useful to software developers who are skilled at using them.

PD1 - Because IDEs and their features can greatly help developes in their coding and development, it allows the developers to implement a system that accomplishes a useful task.

2. Coding Standards and Coding Standards Compliance Tools (Checkstyle, etc.)

PD3 - Coding standards and Coding Standards Compliance Tools allow the developer to create code in a consistant manner. This helps to not only make the code more readable to the developer and any teammates, but also makes it more readable to an external developer because the code is consistent no matter who is writing it.

PD1 - If the code is more readable then it will also be easier to understand and therefore easier to maintain and improve. This will make it easier for a system to perform a useful task because developers will be able to understand it and maintain it (to either fix it so that it will do a useful task or maintain it so that it continues to accomplish a useful task).

PD2 - Coding standards really have no relation to external users other than allowing developers to more easily create or maintain a system that the external user will eventually use.

3. Build Systems (Ant, Make, etc.)

PD3 - Build systems provide greater flexibility for team-based, cross-platform development. It allows for developers using different IDEs and who have different development environments to be able to independently build and test the system regardless of what they are using (certain prerequisites must be met however). This is ideal when an external developer wishes to take a project and work on it.

PD2 - Moreover, an external user who has some technical background can use a build system to create an executable to run the system.

PD1 - In either case, build systems will help bridge developers and users together and allow the system that performs a useful task to be both developed and utilized.

4. Automated Quality Assurance Tools (PMD and FindBugs, etc.)

PD1 - Automated Quality Assurance Tools are useful in finding potential bugs or areas in code where potential problems lie. The real strength of Automated Quality Assurance tools is that they can find problems, defects, or bugs that developers or other experts may not be able to find through manual testing or inspection. The ability to find these types of problems will really benefit the system by allowing it to accomplish a useful task with minimal errors.

PD1 & PD2 - It will also allow both external developers and users to work with the system that has as few bugs as possible.

5. Black and White Box Testing

PD1 & PD2 - In order for a system to accomplish a useful task it must be tested to make sure that it accomplishes its task(s) in a consistent and expected manner and is affected by as little bugs as possible. To help with this process, both black box(functional) and white box (structural) testing should be conducted. After all, the system is no use to an external user if it accomplishes a useful task, but only accomplishes it sporadically or intermittently between errors.

PD3 - Also, black and white box testing will help to ensure that the system runs correctly should an external developer try to work on it further.

6. Automated Testing Tools (JUnit, HttpUnit, etc.)

PD3 - Automated testing tools are a nice means for developers to see if changes that they have made to the system have any rippling effects overall.

PD1 - If a change is made, the developer can run the automated tests to see if they all still pass. If they all still pass then the system will most likely not have been negatively affected overall. If they all do not pass, then the new change has negatively affected other aspects of the system. Automated testing tools can help to ensure that a system continues to accomplish a useful task since the system can be quickly tested without taking too much of the developer's time.

PD2 - External users, however, are not directly affected by automated testing tools other than the fact that if the system works as expected (due to thorough testing) they will be happier.

7. Configuration Management (CVS, SVN, etc.)

PD3 - Configuration management is critically important in the development process. It helps to track what is going on with a software system so that when problems arise the problems will be easier to indentify and fix. Even if there is only one developer working on a project, configuration management makes it very easy to rollback changes and restore the system to a previously working state.

PD1 - Overall, configuration management provides another tool for developers so that they can produce a system the performs a useful task.

PD2 - In the end, the external user will be more readily satisfied if the developers can utilize configuration management to make it easier to create and implement the system.

8. Issue Driven Project Management

PD3 - Issue driven project management provides a nice means of tracking what has been done to a system and what still needs to be done in the future. It provides an important organization tool and works nicely in conjunction with a version control system to manage a project. Developers can take advantage of issue driven project management and its organizational and management benefits to create the best possible system.

PD1 - The system will benefit greatly because it will hopefully insure that all outstanding issues are completed before the system will be released for use. This makes it highly more likely that the system will accomplish a useful task and accomplish that task well.

PD2 - In the end, the external users will benefit because any issues that have been discovered will have been addressed before release to external users.

9. Use Cases

PD1 - Use cases provide a means for capturing user requirements when designing a new system. The advantages of use cases are that if they are done correctly, it increases the chances that the system will preform a useful task since the use cases will provide scenarios of what the user expects the system to do and how the system should do it.

PD2 - Because of this, use cases also increase the odds that the external user will be satisfied with the system since hopefully the system was built based on what they envisioned it to do.

PD3 - Lastly, use cases allow the developers to have a clear picture of what the user wants the system to do, and how the system should go about doing that. This makes the development process much easier since the requirements are well-known.

10. Software Review

PD1 - Conducting software reviews should only benefit the system by making sure it accomplishes a useful task in a logical way and that it has met any requirements specified.

PD2 - External users will benefit from software reviews because whoever did the reviewing would have run into problems (at least the major ones) with the documentation, installation, or use of the system.

PD3 - External developers will benefit from software review because hopefully all the documentation and installation problems will have been worked out following the review, allowing the developer to focus on the system and the task(s) that it should accomplish.

11. Agile Methods (XP, Scrum, etc.)

PD1 - One of the possible negatives of agile methods is that it may not be applicable to larger systems and projects because it emphasizes interaction between developers and users (and requires a smaller group to be truly successful). However, smallers systems that accomplish useful tasks must still be developed and the agile method is very good at that.

PD2 - One of the characteristics of agile methods is that it focuses on interction between users and developers. While this may not directly benefit an external user (who has no direct involvement or stake in the project) it can benefit them indirectly depending on what was conveyed by the stakeholding users.

PD3 - External developers can benefit from agile methods if they choose to enhance or work on a system in a group. If the external developer joins a group of developers who have been working on the system for a while using agile methods, the external developer will be able to jump right into the process because it is not so strongly rooted in doing things in a precise, process-following manner.

12. Open Source Licenses (GPL, CPL, etc.)

PD1 - Open source allows the system to be worked on by a large amount of developers. With large amounts of developers working on a system, one would think that a system that accomplishes a useful task would be created.

PD2 - External users benefit from open source licenses because the software is usually free and accomplishes some useful task that the user can utilize.

PD3 - External developers really benefit from open source licenses because it allows them to work on preexisting projects during their free time that maybe they cannot develop at work.

13. Online Hosting Services (Google Project Hosting, SourceForge, etc.)

PD1 - A system that accomplishes a useful task can only help if it can be found. By having online hosting services available, more people including users and developers can have access to it and either use it or help improve it.

PD2 - Online hosting systems usually include documentation with it or provide a forums or some other means to get the documentation information that a user might need. External users benefit from this because they have access to documentation when they need it.

PD3 - External developers benefit from online hosting systems because they have free access to a variety of different systems that they can download and further develop.

MyISERN 2.0 Review - Team Yellow

2007-12-09T17:41:00.000-08:00

Project Reviewed:

MyISERN-2-Yellow Distribution
MyISERN-2-Yellow Homepage

1. Installation Review

I was able to download the system as a distribution .zip file. However, I could not unzip the zip file using the Windows unzip tool (it said there was nothing to extract). After consulting with my group members, I was advised to use Winrar instead. Once I was able to extract the files, I began the process of installing the system. This turned out to be far more difficult than one would like.

The project uses XAMPP which I guess is some kind of package that includes popular php tools such as Apache, MySQL, and PEAR (along with PHP). After some minor tweaking I was able to get XAMPP working.

Symfony turned out to be much more difficult to work with than XAMPP. It required a variety of components to make it run and the documentation provided by Team Yellow doesn't really explain how to do that. I am not sure if the components are supposed to inherently work after installing XAMPP, but once I got XAMPP to work I could not figure out how to make them work. After looking at other documentation online, and they all seemed to geared more toward a Unix environment rather than Windows so they weren't that helpful. Even the file for Symfony is archived in a .tgz which is more geared towards a Unix environment. So after working on it for like an hour, I could not get Symfony to work.

Here are the results from invoking the following ant tasks:

Due to installation issues I was unable to run the equivalent php tasks on the system.

2. Code format and conventions review

Due to the use of the new language PHP, I am unfamiliar with what the code format and conventions should be.

3. Test case review

Black Box Perspective

Due to installation issues I was unable to look at the black box testing. Although I must admit, I was interested in seeing how you would conduct black box testing on PHP.

White Box Perspective

Once again, due to installation issues, white box testing could not be evaluated.

Break da buggah

Due to installation issues tests could not be broken.

4. User Interface review

I was unable to look at the user interface because of the installation issues.

5. Summary and Lessons Learned

This project review really taught me the value of having good documentation and explanation in wiki pages. Up till this point, everyone had pretty much been using the same languages, tools, and environment so installation was never a problem. When a team decides to migrate to a new language, tools, and environment, they must make sure that their documentation is excellent otherwise other people who have no experience working with their project components will not even be able to run the system, let alone review it.

29.MyIsern-1.3-review

2007-11-15T12:05:00.000-08:00

Project Reviewed:

MyISERN-1-RED
Authors that I am Reviewing: Sonwright M. Gomez, Phuoc Le, and Ivan Wu

1. Installation Review

I was able to download the system as a distribution .zip file. However, I was not able to use the system without using the web interface (there was no jar file or means to create one). It was not difficult to figure out how to run system, I simply had to change the tomcat manager password to match my password, then type the command "ant -f tomcat.build.xml" and then point my web browser to "http://localhost:8080/myisern-1-red/". The installation guide was clear, concise, and easy to follow as it mentioned the above steps to use the system (but did not mention anything about changing the password or user name for the tomcat manager).

Here are the results from invoking the following ant tasks:

JUnit ran successfully

Checkstyle ran successfully

PMD ran successfully

FindBugs ran successfully

ant -f verify.build.xml ran successfully.

2. Code format and conventions review

The code is very well organized into distinct modules. Other than some inconsistencies between the format of the javadoc tags (some have a space between the description and the other @return, @param, etc. and some don't), I see no real format or conventions errors.

File	Lines	Violation	Comments
MyIsernModel.java	45, 47, 315, *	Unused Content	Will probably be used as the system is fully implemented
TestMainMenuActionBean.java	31, 33	EJS-5	Indent 2 spaces

3. Test case review

Black Box Perspective

Black box testing is incomplete. Due to time constraints, the newly created classes for the web application have not been tested. Also, the myIsernXmlLoader class is not tested thoroughly even though it should have been tested in previous versions. Because it is not tested thoroughly some of the classes in the collaborations, organizations, and researchers packages are not tested either. Overall, black box testing does not establish all the equivalence classes and as a result, does not test a member of each of them. Once again, however, this is likely due to time constraints.

Thoroughly testing the myIsernXmlLoader will generate the necessary equivalence classes in the collaborations, organizations, and researchers packages. Additionally, testing on the server side should generate the necessary equivalence classes in the action package.

White Box Perspective

Because the black box testing does not generate all the equivalence classes, white box testing it not nearly complete. Here are the results from running Emma:

Emma Coverage Summary
class:	60%	15/25
method:	25%	54/215
block:	29%	706/2434
line:	26%	165.2/626

As is shown, the coverage is not good as the vast majority of methods are never tested. Once again because the myIsernXmlLoader is not tested thoroughly the coverage on the non-web app side suffers. Also, once the web application is tested, the web app side of the white box testing will be dramatically better.

Break da buggah

The red group did a good job of stating the known issues with their system up front. Because of this, I cannot really break their system without overlapping one of the known issues.

So instead, I'll just offer some ideas for printing/displaying researchers, organizations, and collaborations. Based on the way your current system is set up, you can display/print the type you want by creating variables in your DisplayActionBean class to let your jsp page know which one you want to display (collaborations, organizations, researchers). So before you forward the resolution (printCollaborations(), printOrganizations(), printResearchers()) you can set the appropriate variable and check for it in your jsp page by using the jstl tag or (if/else if/else). So your current would be inside of a or for example.

4. User Interface review

The interface is very easy to use because it is very intuitive. All the links are clearly labeled and the buttons are very descriptive. The only thing I would recommend is not abbreviating the researchers as R, the collaboartions as C, and the organizations as O for the edit feature.

As far as screen real estate is concerned the web application works very well with a large screen as well as a very small screen. I see no room for improvement in this area.

In general, the only improvements I see is to finish implementing all the actions and to allow for display by category (i.e. just collaborations, just organizations, and just researchers).

5. Summary and Lessons Learned

After looking at Team Red's code I realized that a simple interface can be very good especially when screen real estate is a design issue. A simple design is very compatible with a small screen in particular. Also, it was very interesting to see another group's version of the web application. To be able to see their interpretation and implementation of the requirements now provides me with a chance to go back and take a "new" look at my group's web application.

25.WebAppQuestions

2007-11-03T13:14:00.000-07:00

1. Explain in your own words the meaning of the web "request-response cycle".

A client makes a request for information from a web-server. The web-server will then try to match this request with the appropriate response. An example of a typical response would be a HTML page. When the client receives the response, the client can then make another request which will trigger another response, thus forming a request-response cycle.

2. Explain how servlets facilitate processing of the request-response cycle.

Servlets expand the ability of the request-response cycle, by allowing for dynamic content to be included in responses. Since they are Java classes, they can be easily tailored to fit the domain in which they will be used.

3. How do you login to the Tomcat Manager?

If Tomcat is running, simply direct your web browser to the url http://localhost:8080/. Then click on the link: "Tomcat Manager" and type in the user id and corresponding password. If Tomcat is not running type in "startup" on the command line (assuming you have added the Tomcat bin folder to your path environment variable) and follow the above steps.

4. What is the Tomcat Manager used for in the StackStripes application?

The Tomcat Manager is used to deploy the StackStripes 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 the system name ("stackstripes" or "stackstripes-" for instance). Inside that directory there are jsp files which are the homepage and other pages for the web application. Then there is a "META-INF" subdirectory and a "WEB-INF" subdirectory. The "META-INF" directory contains meta information about the web application. The "WEB-INF" directory contains the configuration file "web.xml", along with a "classes" directory, a "lib" directory, and possibly a tags directory. The "classes" directory contains properties files and the java classes. The "lib" directory contains the jar files used by the web application. The "tags" directory contains implementations of tag libraries.

6. How do you build a war directory structure in Ant? Where is this accomplished in the StackStripes application?

Using a build.xml file, you need to create an Ant task which extends a the Ant task used to create a jar file. The extension comes from the fact that you need to "WEB-INF" directory and all the subdirectories and files stored there. An example taken from the Ant Manual is shown below:

In the StackStripes application, this is accomplished in the "build.xml" file in the following manner:

7. How do you install a war directory in a running Tomcat server? What information does the Ant task need to accomplish this?

You simply copy the .war file and paste it into the $CATALINA.HOME/webapps directory. If you are using an Ant task to do this, then you simply set the location to copy the .war file to $CATLINA.HOME/webapps directory.

8. What is the "Model2" architecture? What are its advantages?

The Model2 or MVC (Model-View-Controller) architecture, is a software engineering design where the model or the data is separated from the user interface or view, in order for each to be unaffected by changes to the other. This is accomplished by adding a controller that handles the interaction between the model and the view.

9. What are JSP pages? How are they related to servlets?

A JSP page is a page that allows for both static and dynamic content to be generated on the same text-based page. The static content can be rendered in a number of formats including: HTML, WML, and XML. The dynamic content is generated using JSP elements.

10. Why is there a delay when retrieving a JSP page for the first time? Where is the Java code for that page stored?

When a JSP handles a request for the first time, the JSP page must be translated and compiled into a servlet class. The servlet class is stored in the J2EE_HOME directory so that if JSP page is called on to handle another request, it does not have to be translated and compiled again.

11. What are JSTL tags? Why are they useful? What is an example JSTL tag from the StackStripes system?

JSTL are tag libraries that allow JSP pages to have functionality in areas such as basic scripting functions, XML processing, formatting, and database access. JSTL tags are useful because they are in XML format which allows for people who are not experienced with programming to use them more easily. An example of a JSTL tag from StackStripes is shown below:

12. What are Stripes tags? Why are they useful? What is an example Stripes tag from the StackStripes system?

Stripe tags link buttons and fields on a webpage to methods in the web applications java classes. The tags are useful because they easily link the webpage to the ActionBean class through the get/set methods and any handler methods. An
exammple of a Stripes tag from the StackStripes system is shown below:

This tag links the button called "Double It" to the method doubleIt in the StackActionBean class.

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 allows for a webpage to be accessed via programmable code rather than through a browser. HttpUnit is different from JUnit because it allows for webpages and web applications to be tested whereas JUnit only tests code. This is also why HttpUnit is useful. An example of HttpUnit from the StackStripes system is shown below:


  WebForm pushForm = response.getFormWithID(pushFormParameter);
  WebRequest pushRequest = pushForm.getRequest();
  pushRequest.setParameter(numToPushParameter, "1");
  response = conversation.getResponse(pushRequest);

This code pushes the number "1" onto the stack in the StackStripes web application.

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?

The "index.jsp" page had to be modified to add a button for the double it feature using the stripes tag for buttons. The StackActionBean and StackModel classes had to be modified to add the appropriate doubleIt methods. Nothing else had to be modified (the controller remained the same). Because of that, I learned that the MVC design pattern is flexible and allows for easy additions.

15. What are the equivalence classes that need to be tested for the Double It button?

Test the double it button on an empty stack, a small stack, and a large stack.

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 states that there is only one instance of a class that is instantiated. An example of it in StackStripes is:


  private static StackModel theInstance = new StackModel();
  private ClearStack stack;
  private StackModel() {
    this.stack = new ClearStack();
  }

It is needed so that everyone who is using the class is using the same instance of it.

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?

TestStackModel.java exercises code on the client side. TestStackActionBean exercises code on the server side. In order for Emma to report on the server side coverage, Tomcat must be shutdown first.

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:
Checks to make sure that tomcat is running.

tomcat.undeploy:
Undeploys/removes the web application from Tomcat.

compile:
Compiles all the code.

war:
Builds the war directory structure.

tomcat.deploy:
Deploys/adds the web application to Tomcat.

junit.tool:
Runs all JUnit tests.

junit.report:
Creates the HTML JUnit report.

junit:
Checks for JUnit errors and runs junit.tool and junit.report.

26.StackStripesExtension

2007-11-02T13:04:00.000-07:00

Distribution download: StackStripes Implementation

All tasks were completed successfully. Emma coverage is at 100% and the "Double It" button works as expected.

The most difficult part of this assignment was testing. I had to adjust a little to getting used to testing both the client and server side of the application. In one sense, it almost felt like testing the same thing twice. For instance, you test the stack model's push and pop feature, but then you also have to test the actual web application's push and pop feature, by interacting with it through HttpUnit. In past assignments, all we did was test our code (the client side) and that was it.

As far as working with Tomcat, JSP, JSTL, Stripes, and HttpUnit I felt that they were all pretty easy to get a handle on as long as you looked over the documentation and readings that were provided with them. I really like how easy and intuitive it is to use Stripes and JSP to create a web application. However, I am not sure that my opinion on this will remain the same once we try to tackle a far more complex web application such as the MyISERN system.

21.MyISERN-1.2

2007-10-22T10:20:00.000-07:00

Milestone 1.2.1022

Project Homepage
Download Latest Release

What was difficult about this assignment?
The difficult part of this assignment was having to complete all the assigned tasks. This time there was much more to do than simply code, test, and fix. We also had to write use cases and put together a PowerPoint presentation.

Another difficult aspect of this assignment was testing. I found out that it was very difficult to test command line usage in JUnit tests because the I kept running out of memory when testing the input task for milestone 1.2.1022. I was testing the input capability by reading in input from a text file to simulate user input. That strategy seemed to work pretty well, but I guess it takes up a large amount of memory to do that so I kept running out of memory. Because of this, I was unable to fully test the input class, and as a result, both black and white box testing suffered.

Also the validate XML ant task turned out to be very difficult to satisfy. The collaboration years, it turns out (at least the way we handled them), does not get written to the XML file in a valid manner (when there are no collaboration years). However, the system still runs and everything is ok on the system side, but I guess the XML file is not up to par. Right now the only I can see to fix it is to put in a bogus value like 1000 for null collaboration years and then disregard this value when reading the data into the system. However, I refrained from doing something like that because then XML data by itself is not valid according to system specifications.

What problems were encountered in organizing the group and carrying out the work?
We divided up the input task into 3 issues, one for collaboration, organization, and researcher. Then everybody tried to help everyone else to do the use cases and the PowerPoint. This turned out to be a not very efficient way of tackling this milestone. That is because the 3 issues are basically the same issue, with a large amount of copying and pasting and then modification to fit each type. Also, because people were not assigned smaller tasks that they could finish on their own, everyone had to help everyone else out when they ran into problems and we spent a lot of time helping each other instead of working on what we were assigned.

Were all of the assigned tasks completed? If not, why not?
All of the tasks were completed successfully.

What will you do differently during the next Milestone to improve the process and the product of your efforts?
For the next Milestone, I will create smaller tasks for each person to work on. That way the person assigned that task should be able to complete them on their own or with minimal help from another group member.

19.UseCaseSpecification

2007-10-22T09:39:00.000-07:00

Our Use Cases

From this assignment, I learned that use cases really do help you understand and focus on what the user needs are and reminds a software engineer that the system needs to focus on meeting those needs. I understood the principle of use cases after reading about them, but after having to go through the process of recording them and then reconstructing them into specific use cases, I realized and learned just how important they can be in helping to view the system from the user's perspective.

I also learned that making the use cases specific really does help and not hinder understanding the needs of the user. Originally I thought that if you make the use cases specific, then you would only be getting the user needs for that specific situation. However, after writing use cases, I realized that while some of the user needs that you learn from use cases may only apply to that particular case, other specific needs can be extracted from the use case that apply to the system as a whole. If you wrote only general use cases, then you would only be able to extract general user needs which may not prove to be very helpful at all.

22.MyISERN-1.1.Review

2007-10-15T23:53:00.000-07:00

Project Reviewed:

MyISERN-1-Brown
Author that I am Reviewing: Kevin English

1. Installation Review

I was able to download the system as a distribution .zip file. However, I was not able to download the latest distribution from Kevin's Engineering Log (was the older version), and I had to go to the team's project page to get the latest distribution. The system allowed for the creation of a jar file "myisern.jar" which could be used to execute the system instead of having to use ant or Eclipse. It was not difficult to figure out how to run system, I simply had to type the command "java -jar myisern.jar" and a usage message appears that shows what args are supported. It also prints out a message that says "Thank you for shopping at Walmart".

Here are the results from invoking the following ant tasks:

JUnit ran successfully

Checkstyle ran successfully

PMD ran successfully

FindBugs ran successfully

ant -f verify.build.xml ran successfully.

2. Code format and conventions review

The code is very well organized into distinct modules. Other than the Cli.java class which contains some consistent errors, I see no other significant format or convention errors.

File	Lines	Violation	Comments
MyIsernModel.java	105, 113, 121, *	EJS-9	Use meaningful variable names
MyIsernTable.java	40, 58, 74	EJS-9	Use meaningful variable names
Display.java	30, 46, 60	EJS-9	Use meaningful variable names
Cli.java	30, 46, 60	ICS-SE-Eclipse-2	Left curly brace on preceding line; right curly brace on its own line
Cli.java	52, 60, 190, *	?	White space between methods

3. Test case review

Black Box Perspective

Black box testing looks good. All the classes are tested by generating equivalence classes and checking for the expected output or return values. Most of the testing does not involve testable boundary conditions so the black box testing looks very good.

White Box Perspective

The white box testing is not quite as good as the black box testing. Here are the results from running Emma:

Emma Coverage Summary
class:	92%	11/12
method:	89%	62/70
block:	88%	2020/2293
class:	82%	318/390

As is shown, the coverage across the lines of code is not great and several methods are never tested. Based on the Emma coverage summary and actually looking at the report, the white box testing does not fully cover the code. Most of the problems with the white box testing occurs in the Cli.java class and is due to the fact that not all the possible argument input types are tested. So to improve white box testing, I would simply recommend testing all possible argument input combinations, just to double check that the system is in fact executing the right code based on the input arguments.

Break da buggah

Although the white box testing is not as complete as one would like, because of the way that the command line arguments are handled, I cannot think of a way to break the code short of actually going in and manually rewriting code to produce an error.

4. Summary and Lessons Learned

After looking at Kevins's code I realized that the code I have written thus far for MyISERN is not modularized at all at the class level. My group has written different methods for the various tasks, but everything is still in the class MyIsernXmlLoader.java. After looking at Kevin's code, it dawned on me that only code pertaining to loading MyISERN information from XML files should be contained in the class MyISERNXmlLoader.java. So as soon as we implement the new input ability for the system, I will work on modularizing our group's code into intuitive class modules. Not only does it make the code much more logical in terms of organization, but it also makes modifying it much easier because everything is split into logical parts (and other parts will likely not be affected if one part is changed).

I've also learned that you don't necessarily have to handle command line arguments in the main method of one the classes you implement to perform a task. Instead, you can implement your own class that handles all the command line argument intricacies and then executes the necessary code based on the results of the checks that are performed. This seems like a very logical and modular design that I will definitely consider including something like it in my own group's code.

18.MyISERN-1.1

2007-10-15T03:22:00.000-07:00

Milestone 1.1.1015

Download Latest Release

What was difficult about this assignment?
The difficult part of this assignment was delegating all the work so that we would not get in each other's way or spend all of our time doing the same task. Also, when multiple are programming the same system, it is difficult to make everything consistent and easily readable. While we do share the same ant tasks such as PMD, CheckStyle, and FindBugs, the actual code that we write may not necessarily be consistent. One of us might choose to use a void method, while the rest of us use methods that return strings for instance. This type of inconsistency can make code very difficult to debug and read at times. I found that I had to spend a good amount of time making our code as consistent as possible so that it was more readable and easier to debug and change.

What problems were encountered in organizing the group and carrying out the work?
We divided up the various tasks into distinct issues. Since each issue was pretty much independent of the other issues, we assigned one person to work on each issue. The problem with this approach though, was that because only one person was working on each task, if the person ran into trouble, then no one else was working on that issue. I'm not sure if it would have been better for everyone to work on the same issue using the XP approach. During our in-person meetings we used that approach to do some of the tasks and it turned out pretty well. The only problem is during the in-person meetings, we only have one computer so it is a little inefficient.

Were all of the assigned tasks completed? If not, why not?
All of the tasks were completed successfully.

What will you do differently during the next Milestone to improve the process and the product of your efforts?
For the next Milestone, instead of just dividing up the work, I (our group) will attempt to divide the work to better cater to our strengths. I think this will help us to better use our time and will make achieving the next milestone far easier, since hopefully it will be a much more efficient process. Also, I think we will try having one person work on the main method and testing, and the other two people working on the task methods. This will allow the code to be more consistent and easier to debug and change. Another possibility is to define team standards that we will use to program, so that everything will be as similar as possible.

16.MyIsernReview

2007-10-09T00:41:00.000-07:00

Project Reviewed:

MyISERN-1-Orange
Author: Michal Zielinski

1. Installation Review

I was able to download the system as a distribution .zip file. The system allowed for the creation of a jar file "MyISERN-1-Orange.jar" which could be used to execute the system instead of having to use ant or Eclipse. It was not difficult to figure out how to run system, I simply had to type the command "java -jar MyISERN-1-Orange.jar" and the 3 tables appeared.

Here are the results from invoking the following ant tasks:

JUnit ran successfully

Checkstyle ran successfully

PMD ran successfully

FindBugs ran successfully

ant -f verify.build.xml ran successfully.

2. Code format and conventions review

One thing I noticed about the code is that the code used to generate the 3 tables is placed in the main method. Even for a small assignment like this one, I would recommend moving the code to one or more non-static methods and if anything, use a static method to generate the GUI.

Another issue that I noticed is that the code is very case specific. The code used to generate the 3 tables knows exactly how many rows are in each table. This means, that if more organizations, collaborations, or researchers are added, the code will need to be changed for each addition.

Another issue is the commenting of the main method. Two types of comment markers are used: "//" and the "/** * */". Since the comments are within a method, only the "//" type should be used. Also, the comments are very general and do not really add anything to the code.

One additional issue I noticed in the main method is that the toString() method is called on several String objects even though it is unncessary.

3. Test case review

Black Box Perspective

Several MyIsernXmlLoader objects are created and all the methods are tested. Because all the newly implemented code is in the main method, the only way to test it is to invoke the main method. If the code is taken out of the main method and placed in individual methods, the code can be more effectively tested (if they return something). Since the main method is a void method, it is much more difficult to conduct black box testing since the return values cannot be tested.

White Box Perspective

Several additions were made to the main method to allow the organization, collaboration, and researcher lists to be tested to see if they contain the expected values. This is a good test to make sure that the getCollaboration(), getOrganization(), and getResearcher() methods are returning the expected lists. Combine that with the tests that make sure the collaborations, organizations, and researchers sizes are accurate, and everything needed to create the tables has been tested. Since, the main method contains all the code to create the tables, however, whether it actually creates the proper tables cannot be effectively tested. To fix this, I would recommend moving the code to create the tables from the main method to their own non-void methods. This will allow the return values generated from these methods to be tested against their expected values.

Break da buggah

I modified the researchers.example.xml file to add a fourth researcher to it. I modified the TestMyIsernXmlLoader.java by changing the expected number of researchers to 4:

assertEquals("Check researchers size", 4, loader.getNumResearchers());

I then ran the ant -f junit.build.xml task and it passed successfully. When I recreated the jar file and ran the jar, the fourth researcher did not show up in the table. This is the expected result, however, because the size of the researcher table is hard coded into the system instead of being based on the number of researchers in the researcher.example.xml file.

4. Summary and Lessons Learned

After looking at Michal's code I realized just how difficult void methods are to test. A lot of the time, there is no effective way to test the method using JUnit because no values are returned. And if there is a lot of code in the void method, then that can make JUnit testing pretty worthless. In this particular case, testing can be done on the void methods visually by inspecting the tables and visually checking to see that they have the rights results in them. However, this defeats the point of using the JUnit ant task.

Another interesting lesson learned from this exercise is that just because the various ant tasks run successfully on your computer, does not mean that they run successfully on someone else's computer. Michal emailed me saying that the tasks run successfully on his machine and provided a screenshot as evidence. However, when I ran the tasks on my machine, the findbugs.build.xml task had 1 warning. At this point, the only thing I can think of is that maybe we are using different versions of findbugs? Irregardless of the discrepancy though, the warning that it generated was correct since calling the toString() method on a string is unnecessary.
After further review, it turns out that I was using FindBugs 1.2.0 and Michal was using FindBugs 1.2.1. So one lesson learned is that it is important that everyone is using the same version of all software engineering tools

I've also learned from reviewing Michal's code, that the code I came up with for my own system needs to be revised so that it can be better tested. I will revise my code by adding another return method and by making my methods return testable values. This way, I can write better tests for my system which will better insure that it is functioning properly.

15.MyISERN-1.0

2007-10-08T02:29:00.000-07:00

Group: MyISERN-1-Red

Here is the link to my group's project homepage: MyISERN-1-Red Homepage

This assignment was quite interesting. I have never really worked in a group on a programming assignment before, so it was a very novel experience for me. What made the assignment difficult was not the programming, but rather getting used to learning and using SVN and Google Projects. Also, at times, I found it difficult to adjust to working with other people. I found that at times I was going about the assignment as if I was working on it by myself. Our group used MSN messenger groups to facilitate communication and to meet, so I would often forget to tell (type) the other people in my group what I was doing. Luckily, whenever I did this, I was never working on the same thing as anyone else in the group. So ultimately, a lesson learned was making sure I vocalize my ideas and thought process to the group as often as possible, so that we can all stay on the same page and do software engineering in a coordinated and efficient manner.

Another difficult aspect was trying to meet in person. Even during the school week, it is somewhat difficult to coordinate everyone's schedule to be able to meet in person. In the real world of software development, this is not really a problem since everyone is working in the same office. However, as University students, we have different class and work schedules so coordinating all of that can be difficult. Luckily, through the use of MSN, we were able to conduct functional (if not rather informal) meetings online. MSN (or any instant messenger) proved to be a rather useful tool because we could use it to bounce ideas off of each other while we were programming. We could also use it to ask each other for help in areas that we were having problems and to check on each other's progress. In one sense, it was kind of like we were programming and working in the same office.

Working with JAXB and XML was a little difficult at first because I have had very little experience with either. However, once I got the basic understanding of JAXB down, I was able to utilize it to work with the example XML files that were provided. The tutorial for JAXB was very useful to gain a basic understanding of it. In the future, if I am working with unfamiliar tools or aspects, I will definitely look for tutorial type documentation.

Here is the link to my group's project homepage: MyISERN-1-Red Homepage

14.CM.Practice

2007-10-07T20:02:00.000-07:00

Overall, I felt that this assignment was pretty straight forward. Even though I was using SVN and Google Project for the first time, the use of both of them was pretty intuitive. Because of that, I was able to complete all three tasks successuflly. One problem I had with SVN was that I had committed both my bin and build folders so I had to figure out how to delete them. Eventually, I realized that the TortoiseSVN option when you right click on something allows you to do a lot of things, including deleting files and folders from the trunk directory. The only other thing that I had to get used to with SVN was the icons that appear on the folders. When the bright red "!" appears on a folder or file that you have made changes to, but not committed, it makes it seem like you did something wrong when you really haven't.

As far as lessons learned, because of the simplicity of this assignment, I haven't really learned a lesson other then to check the TortoiseSVN menu option for various features. I'm sure in the next assignment, I will learn more valuable lessons as I really start to work with SVN and Google Projects.

My Project website

12.WebSpiderReview

2007-09-29T11:59:00.000-07:00

Reviewed Package Author: Andrew Wong

Overview

The system is logically designed and seems to use both code and variables very efficiently. In general, the code is tested quite well, however, the system is prone to fail if the passed arguments are not in the correct order. There also is a discrepancy between the way that this system counts the total number of links and the way other systems count the total number of links. This system counts the start url as a link and only counts links that have not been visited before. In other words, it counts the total number of distinct links and the start url (even though technically it should not). Because of this, the totallinks function returns a value that is off from what other systems are returning (usually less).

Installation Review

The project was extracted from the zip file successfully.

"ant -f verify.build.xml" executed successfully. Results were:

JUnit

ran successfully.

CheckStyle

ran successfully.

PMD

ran successfully.

FindBugs

ran successfully.

Emma

coverage was not 100% but covers 100% of the WebSpider package. Does not cover 100% of the hackystat logger package (missing catch statements).

Emma Coverage summary

class: 100% (7/7)
method: 96% (26/27)
block: 97% (636/659)
line: 96% (156/162)

The creation of the jar file using "ant -f dist.build.xml" was also completed successfully.

Invoking "java -jar webspider-wongandr -totallinks http://hackystat.org 100" runs the WebSpider program without incident.

Code Format and Conventions Review

Code Formatting Corrections Recommended:

File	Lines	Violation	Comments
WebAddressDatabase.java	37, 55, 73, *	EJS-61	Some comments are unncessary
WebAddressDatabase.java	106, 107	EJS-5	2 space indent
TestWebSpider.java	18, 39	EJS-42	blank line between description and Javadoc tags
WebSpiderLogger.java	40	EJS-42	blank line between description and Javadoc tags

Test Case Review
Black Box Perspective:

WebAddressDatabase.java:

Both test classes TestWebAddressDatabase.java and TestWebSpider.java invoke WebAddressDatabase.java although only TestWebAddressDatabase.java invokes it directly. Interestingly, TestWebAddressDatabase.java does not invoke all methods from WebAddressDatabase.java even though it is specifically created to test WebAddressDatabase.java. Between the two, however, all methods are tested.

WebAddressEntry.java:

This data structure is tested thoroughly by TestWebAddressDatabase.java. The data structure is tested to make sure it is functioning as expected.

WebSpiderLogger.java:

Based on the output generated when the jar file is invoked with logging, WebSpiderLogger appears to be working correctly. However, no tests in either test classes exist to see whether the logger is performing as expected. The class is tested indirectly by using the logging command in both test cases (in TestWebSpider.java). The minimum tests I would recommend would be to at least test to make sure that when "-logging" is not included as an argument, that logging is then turned off.

WebSpider.java:

The test classes cover all the methods within WebSpider.java. However, there is no testing to see if the passed arguments are valid, in the right order, or even if there are the correct number of arguments. Also, the testing for WebSpider.java does not see what happens when the "-logging" is not included. Because of this, the system seems prone to errors because of the lack of testing of the passed arguments.

White Box Perspective:

WebAddressDatabase.java:

This class does have any real errors that can be thrown. Because of this, TestWebAddressDatabase.java does a thorough job of testing this class.

WebAddressEntry.java:

Overall, this class was tested thoroughly. It functions as expected, so no further error checking must be done.

WebSpiderLogger.java:

This class is tested thoroughly as well. It functions as would be expected, the coverage is adequate.

WebSpider.java:

Only the normal operations of this class were tested.

The main method assumes that at least 3 arguments will always be passed to it. If there are more than 3 arguments (4 or more), then it only takes the 4th argument and checks if it is "-logging". No error conditions are present for if there are less than 3 arguments or if the 2nd or 3rd arguments are out of order. If the first argument is not "-totallinks" or "-mostpopular" then the getTotalLinks() and the getMostPopular() methods are not called, but the 2nd and 3rd arguments are still passed to create the WebSpider constructor and the integer value for maxPages.

I would recommend testing for no arguments, for some of the arguments, for arguments that are out of order, and for arguments that are in the right order but missing the "-logging" command. And then modifying the code to check for these errors.

The way that the code is set up, testing the passed arguments seems to be the only area that requires additional testing.

Break da buggah:


/**
 *  Test that causes the system to fail.
 *
 * @throws Exception  Thrown if a web page fails to parse.
 */
@Test
public void breakDaBuggah() throws Exception {
  String test2[] = new String[4];

  test2[0] = "-mostpopular";
  test2[1] = "20";
  test2[2] = "http://www.google.com";
  test2[3] = "-logging";

  try {  
    WebSpider.main(test2);
  }
  catch (Exception e) {
    fail("Webspider execution failed.");
  }
}

This test reverses the order of 2nd and 3rd passed arguments. It causes the system to fail because of a number format exception that is not caught in the main method. The system tries to pass a string as an int. Here is the error message generated from the command line:

Exception in thread "main" java.lang.NumberFormatException: For input string: "http://hackystat.org"
at java.lang.NumberFormatException.forInputString
at java.lang.Integer.parseInt
at java.lang.Integer.valueOf
at edu.hawaii.webspider.WebSpider.main

Summary and Lessons Learned

From this exercise, I've learned that testing is almost as time consuming as actually coding the system. Thoroughly testing the system involves far more than just making sure that the Emma coverage is at or near 100%. It involves thinking about every method and every error that can be thrown. Not only do you have to make sure that the system performs as expected under normal circumstances, but that the system is resilient when it comes to handling improper and unexpected input (either for a method or for passed arguments). This involves adding additional error checking features to the system to make sure that the system does not fail from simple errors such as passing the arguments in the wrong order.

I've also learned that thorough testing involves testing each individual class, no matter how small or irrelevant it may seem to the overall system. Even though the some classes are relatively insignificant when compared to the overall system, if these smaller classes are not at least tested to ensure that they do what they are supposed to do, then the system itself is already possibly prone to serious errors.

I've also gained more knowledge working with the various tools and figuring what needs to be changed in the various files (such as build.xml) and what needs to be added in order for them to all work (junit.build). And although, some of the tools such as PMD may seem quite annoying at times (being very picky) they ultimately help you to consistently build a functional system that adheres to certain standards, as efficiently as possible.

11.WebSpider

2007-09-24T02:06:00.000-07:00

This was a difficult assignment. One problem that I had was that there was no given expected output based on the input ("http://hackystat.org") that we all had to use. Because of that, I could not determine if I was doing the assignment correctly and had to rely on the group message board to determine if I was getting something close to what other people were getting. In the end, my total number of links did not exactly match what other people were getting, but it was relatively close.

Although the assignment was difficult, I felt that I was able to learn from it. This assignment required me to get much more familiar with ant and all the other various tools we use to build our code. For example, I was forced to modify the build.xml file because I could not get JUnit to work because the build.xml file was missing the JUnit jar file. I also realized just how annoying PMD and CheckStyle can be at times, particularly PMD. At the same time, however, I also learned to appreciate how PMD and CheckStyle keep your code easy to read by keeping your coding style consistent.

Luckily, I was able to complete the first three tasks and my code can be downloaded from the following link:

Download My WebSpider

10.Stack

2007-09-17T02:04:00.000-07:00

I was able to complete all tasks for this assignment. I fixed the problem about not being able to upload files on unix because I realized that I was over the disk usage limit.

Download My Stack System

The only problematic task in this assignment was creating the javancss.build.xml file. I had never worked with xml before and had never designed anything similar to a *.build.xml file. Luckily, I was able to study the other *.build.xml files in addition to online examples of the javancss.build.xml file and its documentation. In the end, I was able to produce a javancss.build.xml file that stores its results in an html file based on what I found online.

Right now, I don't quite understand the specifics of each QA tool that we are using. This is mainly due to the fact that I have not thoroughly gone over the readings in 09.Readings. I'm sure that once I read them in detail I will have a better understanding of ant along with each QA tool that ant invokes. I really like Emma though, because it tells you what parts of the code you have not tested with JUnit.

Based on what I've seen, the biggest difference between SCLC and JavaNCSS is that SCLC can be used on a multitude of programming languages including C, C++, Lisp, and Perl, while JavaNCSS is Java specific. Because JavaNCSS is Java specific, it suits us much better than SCLC because it can pick up java features such as Javadoc.

08.CodeRulerRedux Code Ruler Results

2007-09-05T02:25:00.000-07:00

I implemented version 2 of my Code Ruler code alone. The link to the code is below:

CodeRulerRedux Implementation

After looking through The Elements of Java Style book along with our own standards, I modified and implemented code that adheres to the Java coding and documentation standards. As far as strategy for the actual game, I saw an interesting for loop in Jianfei Liao and Jon Lao's code that heavily influenced my own method for capturing enemies as a group. It looked around for enemies that were next to each individual knight and captured them as it came across them. That seemed to work much better than the method I had come up for capturing all enemies in a particular grid area. Also, I saw that they went after castles first and then after enemies, which was different from my code because I just went after the nearest enemy. After modifying my code to capture castles first, I noticed that it was much more effective than just capturing the nearest enemy. I also learned from Michal and Chiao-Fen Zielinski's code that you could actually control what type of unit (knight or peasant) your castle produced, so I immediately modified my code to take advantage of this discovery!

Version 2 of my ruler dominated Migrate Ruler, Gang Up Ruler, and Split Up Ruler. The results of tests are shown below:


Version 2 Test Results:

My Ruler vs. Migrate Ruler

   1: 982 - 0     W

   2: 984 - 0     W

   3: 988 - 0     W

My Ruler vs. Gang Up Ruler

   1: 877 - 120   W

   2: 914 - 86    W

   3: 931 - 66    W

My Ruler vs. Split Up Ruler

   1: 904 - 64    W

   2: 869 - 116   W

   3: 898 - 94    W

The results were much better than my previous results (shown below) because I went 9-0 instead of 5-4 and the scores were much more consistent in that I consistently won by a large amount. It seems that my currently strategy works with all types of rulers whereas my previous strategy struggled with Split Up Ruler. Overall, I think the biggest difference between Version 2 and Version 1 is that Version 2 controls the unit production much, much better than Version 1 and my capture strategy is much more effective now that I go after castles first and capture any enemy next to my knights.


Version 1 Test Results:

My Ruler vs. Migrate Ruler

   1: 934 - 0     W

   2: 958 - 0     W

   3: 936 - 0     W

My Ruler vs. Gang Up Ruler

   1: 812 - 98    W

   2: 641 - 526   W

   3:  36 - 600   L

My Ruler vs. Split Up Ruler

   1: 157 - 635   L

   2: 356 - 485   L

   3:  86 - 627   L

From this assignment, I learned proper Java coding and documentation standards, gained a better understanding of Eclipse, and learned the value in looking at other people's code. I think all three of these lessons will prove to be tremendously valuable as the semester goes on.

07.CodeRulerReview

2007-08-31T00:23:00.000-07:00

Michal Zielinski & Chiao-Fen Zielinski's Code Ruler Review

File	Lines	Violation	Comments
MyRuler.java	45, 46, 48, *	ICS-SE-Eclipse-2	2 space indent
MyRuler.java	53	spelling error	"based" instead of "baced"
MyRuler.java	48, 49, 50, *	EJS-25	Capital letter for 2nd, 3rd, 4th…word of variable
MyRuler.java	155	EJS-22	Capital letter for 2nd, 3rd, 4th…word of method
MyRuler.java	140, 165	EJS-5	Indent nested code
MyRuler.java	137, 138, 159, *	EJS-9	Use meaningful variable names
MyRuler.java	136	EJS-28	First for loop should start with "i"
MyRuler.java	30, 153	EJS-42	Descriptions given for only some parameters
MyRuler.java	156, 162, 171	EJS-76	Use { }

Your code is not overly complex in terms of the amount of loops and thus, should execute relatively quickly. With that in mind, you could implement a more sophisticated algorithm for your peasants to acquire land and still be under the 0.5 second limit per turn. Maybe have each of them look around for the closest land controlled by another ruler or that is unclaimed. That way they all won't be traveling in one group as well.

Code Ruler Results

2007-08-29T10:21:00.000-07:00

I constructed this code alone. I attempted to implement a ruler that would divide his knights into groups and attack the enemy in groups. My peasants would wonder around and claim the nearest land that did not belong to me. This was my basic approach to implementing a ruler. Below is a link to my implementation:

CodeRuler Implementation

Test Results:


My Ruler vs. Migrate Ruler
1: 934 - 0      W
2: 958 - 0      W
3: 936 - 0      W
My Ruler vs. Gang Up Ruler
1: 812 - 98     W
2: 641 - 526    W
3: 36 - 600     L
My Ruler vs. Split Up Ruler
1: 157 - 635    L
2: 356 - 485    L
3: 86 - 627     L

My strategy worked well against rulers that did not have an overly sophisticated strategy. Gang Up Ruler and Migrate Ruler are relatively simpler rulers. Gang Up Ruler groups his knights into one large group and travels around the grid. Migrate Ruler simply groups his peasants and knights and moves around the grid. These two rulers do not have a terribly sophisticated implementation and thus, I was able to defeat them (5-1 against them). Split Up Ruler, however, has a more sophisticated implementation in terms of capturing opponents. When my knights and his knights went into head-to-head combat, Split Up Ruler's knights always won. Since he always defeated my knights, I was defeated relatively easily (0-3).

The lessons that I learned from this assignment were getting more familiar with Eclipse, JavaDoc, and the new Java 5 features. I still need to figure out how to fully utilize JavaDoc, as I was unable to generate comments for my fields in my HTML file.

02.OSS.Experience

2007-08-27T01:54:00.000-07:00

Overview:

OSS: MediaSort
Link: http://sourceforge.net/projects/mediasort

SourceFourge description:

"MediaSort is a tool to automatically rename your media files (pictures, mp3, ...) with their metadata attributes. You can sort your pictures by date, camera ... or other EXIF attributes. MP3s by author, album .. or other ID3 tags. Java GUI based on Ant."

Prime Directive 1:

MediaSort allows the user to rename files based on the metadata--commonly called tags--that are stored within various digital files. MediaSort focuses on FS, MP3, and OGG metadata attributes. This tool is incredibly useful to people who have large libraries of files where the metadata is accurate, but the files lack a naming convention. This tool will allow the user to quickly organize his or her file library. Because the tool provides a useful functionality, Prime Directive 1 is satisfied.

Prime Directive 2:

The installation of MediaSort was very simple. Simply download the bin zip folder, unzip the folder, and click on the command script titled "run." Once the GUI opens up, simply point the applet to the source and target directories, select the metadata attributes you wish to include and the order in which you want them to appear in the file name, and click "Copy" or "Move." It is a very easy applet to install and use and thus, I would have to conclude that Prime Directive 2 was satisfied.

Prime Directive 3:

The code for MediaSort is not overly difficult to understand or interpret, however, there is very little documentation and commenting of the code. Although the code is not extremely difficult to understand, documentation and commenting are a must for open source projects to ensure as much as possible, that any external developer can come in and enhance the system. Due to the lack of documentation and commenting within the code itself, MediaSort does not satisfy Prime Directive 3.

04.FizzBuzz

2007-08-21T17:29:00.000-07:00

public class FizzBuzz {
  /**
   * @param args
   */
  public static void main(String[] args) {
    for (int i = 1; i < 101; i++) {
      if (((i%3)==0) && ((i%5)==0)) {
        System.out.println("FizzBuzz");
      }
      else if ((i%3)==0) {
        System.out.println("Fizz");
      }
      else if ((i%5)==0) {
        System.out.println("Buzz");
      }
      else {
        System.out.println(i);
      }
    }
  }
}

The total time it took to create this program in Eclipse was 5 minutes 20 seconds. Much of the time was spent using the Eclipse tutorial to figure out how to run a java application in Eclipse. After using the tutorial to write the infamous Hello World program, writing the FizzBuzz program was relatively easy. Other than figuring out how to use Eclipse, I did not encounter any other problems with Eclipse or java.

In general, this assignment has shown me how difficult it can be to implement even relatively simple programs that are syntactically and stylistically correct without a computer. The moral of the story is that while technology may be a great asset, we shouldn't rely on it to the point that we cannot function without it. In a world, where many of us use the compiler as a crutch, it is actually hard work, dedication, and practice--and being able to implement simple programs by hand--that separates a decent programmer from a great one.