Sunday, December 9, 2007

33.PrimeDirectivesRedux

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

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.

Thursday, November 15, 2007

29.MyIsern-1.3-review

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.























FileLinesViolationComments
MyIsernModel.java45, 47, 315, *Unused ContentWill probably be used as the system is fully implemented
TestMainMenuActionBean.java31, 33EJS-5Indent 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.

Saturday, November 3, 2007

25.WebAppQuestions

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.

Friday, November 2, 2007

26.StackStripesExtension

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.

Monday, October 22, 2007

21.MyISERN-1.2

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

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.

Monday, October 15, 2007

22.MyISERN-1.1.Review

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.









































FileLinesViolationComments
MyIsernModel.java105, 113, 121, *EJS-9Use meaningful variable names
MyIsernTable.java40, 58, 74EJS-9Use meaningful variable names
Display.java30, 46, 60EJS-9Use meaningful variable names
Cli.java30, 46, 60ICS-SE-Eclipse-2Left curly brace on preceding line; right curly brace on its own line
Cli.java52, 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

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.

Tuesday, October 9, 2007

16.MyIsernReview

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.

Monday, October 8, 2007

15.MyISERN-1.0

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

Sunday, October 7, 2007

14.CM.Practice

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

Saturday, September 29, 2007

12.WebSpiderReview

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:



































FileLinesViolationComments
WebAddressDatabase.java37, 55, 73, *EJS-61Some comments are unncessary
WebAddressDatabase.java106, 107EJS-52 space indent
TestWebSpider.java18, 39EJS-42blank line between description and Javadoc tags
WebSpiderLogger.java40EJS-42blank 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.

Monday, September 24, 2007

11.WebSpider

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

Monday, September 17, 2007

10.Stack

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.

Wednesday, September 5, 2007

08.CodeRulerRedux Code Ruler Results


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.

Friday, August 31, 2007

07.CodeRulerReview


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































































FileLinesViolationComments
MyRuler.java45, 46, 48, *ICS-SE-Eclipse-22 space indent
MyRuler.java53spelling error"based" instead of "baced"
MyRuler.java48, 49, 50, *EJS-25Capital letter for 2nd, 3rd, 4th…word of variable
MyRuler.java155EJS-22Capital letter for 2nd, 3rd, 4th…word of method
MyRuler.java140, 165EJS-5Indent nested code
MyRuler.java137, 138, 159, *EJS-9Use meaningful variable names
MyRuler.java136EJS-28First for loop should start with "i"
MyRuler.java30, 153EJS-42Descriptions given for only some parameters
MyRuler.java156, 162, 171EJS-76Use { }




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.

Wednesday, August 29, 2007

Code Ruler Results

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.

Monday, August 27, 2007

02.OSS.Experience

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.

Tuesday, August 21, 2007

04.FizzBuzz

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.