The Three Prime Directives discussed throughout this semester are defined Here.
To summarize, they are
1. The system successfully accomplishes a useful task. (Is it useful?)
2. An external user can successfully install and use the system. (Is it usable?)
3. An external developer can successfully understand and enhance the system. (Is it enhanceable?)
For each software engineering tool or method we have used or discussed this semester, I will briefly outline how it pertains to these directives (if at all). Rather than specifically describing each tool, I will explain how each type of tool affects the Three Prime Directives.
1. Interactive Development Environments (Eclipse, VisualStudio, etc.)
Interactive Development Environments (IDEs) describe a huge variety of tools used by many types of software developers. They range from complete, contained tool kits to only slightly enhanced text editors. The goal of IDEs is to enable more efficient and correct programming.
IDEs do not directly affect any of the Three Prime Directives. Most of the tools provided IDEs do not affect the directives at all. Only the third directive could potentially be affected by the use of these tool kits. If the user uses a specific, defined set of tools, it could enable a developer to more easily recreate the original development environment. Use of the same development environment could make it easier for a developer to read, understand, and improve or maintain the system.
An example of a powerful development tool provided by most IDEs is colorized keywords for a specific language. Eclipse provides this tool and it can make reading the code much easier.
2. Coding Standards and Coding Standards Compliance Tools (Checkstyle, etc.)
Coding standards provide clearly defined standards for code style. While style may not directly affect the system itself, it greatly affects the readability of the code. Coding standards compliance tools enable the system developer to ensure all of the code complies with a defined standard.
Since the style of the code is not seen by the user, the first two Prime Directives do not affected by coding standards. However, following coding standards can greatly improve the readability of the code. Therefore, it can make the final system much easier to enhance and maintain, even by the original developer.
Checkstyle, the Java coding standards tool used this semester, provides clear errors when the specified coding standards are not met. It ensures the code is more easily readable and all members of a software team follow the same standards of code.
3. Build Systems (Ant, Make, etc.)
Build systems provide configuration and automation for any or all steps of building of a system. They directly affect every Prime Directive because of the importance of configuration. Many systems must be built first to run on the system. Build systems provide a simple procedure to build, install, or run a system. Without this procedure, configuration can be very difficult and time-consuming for a user or developer.
Make is a very popular and heavily used build system. It allows a developer to create a file that will compile, install, or perform many other tasks automatically. When a user or developer downloads a system, they can simple type "make", rather than having to follow a complex series of instructions.
4. Automated Quality Assurance Tools (PMD and FindBugs, etc.)
Automated quality assurance tools are a family of tools that provide automated, standardized tests that can be run on a developing or completed system. Many of these tools parse the code directly to try and detect certain types of errors. While many developers do not use these types of tools, they can affect the second two Prime Directives by improving the quality of the system. A system with less bugs will be a system that is more usable and and easier to enhance.
The Java tools we used this semester (PMD and FindBugs), while sometimes annoying and difficult to satisfy, was useful at times. It would occasionally reveal bugs that would have been problematic.
5. Black and White Box Testing
Testing is a very important phase in the development of any system. Black box testing focuses on the overall behavior of the system (or components), while white box testing is concerned with details of the code itself. Both of these systems can improve the quality of the system. As mentioned earlier, system quality affects Prime Directives two and three. In addition, black box testing can increase usefulness of the system (Prime Directive 1) by revealing requirements and desired behavior of the system.
For most of the software I created this semester, I used both of these testing techniques. I created many "use case" types of tests for black box testing. These tests performed certain actions a user may take and test the outcome. I also used the tool EMMA to test code coverage of white box testing.
6. Automated Testing Tools (JUnit, HttpUnit, etc.)
Automated testing tools provide a simple and routine way of testing the system. Like previously discussed, this can increase the overall quality of the system, thereby increasing the ability to achieve the Three Prime Directives. For the Java software I created this semester, I used JUNIT to run tests on the system. It was a very useful and powerful tool that made the testing process simple and straightforward. It also made it easy to test components during development, allowing test-driven design.
7. Configuration Management (CVS, SVN, etc.)
Configuration management tools are essential for any software project with more than one member (and very useful for every project). CM tools provide a safe and effective way of managing, tracking, and documenting changes to the system. In addition to making development much easier and smoother, it also improves the quality of the system (thereby affecting the Three Prime Directives). The documentation and tracking of changes and versions also makes it easier for developers to enhance and change the system.
I used SVN this semester and found it rather useful. It took some learning to be able to quickly and easily work with SVN, but once I was comfortable with it I found it very useful. It made working with group members easier and allowed for easy version control and documentation.
8. Issue Driven Project Management
Issue driven management is a process of dividing the tasks of development into issues and working on individual issues at a time. While it could be argued that it increase overall system quality, this method of development does not, necessarily, help the system to satisfy the Three Prime Directives. Use of this type of organization is not essential to a system, though for some projects it can be a very useful documentation and communication tool. If used correctly, the documentation it provides can be useful for developers enhancing the system.
I found the Google project hosting issue tracker to be a useful tool when I was working in groups. It provided a method of task division that aided group work. I do not, however, think it directly affected the Three Prime Directives in my experience.
9. Use Cases
Use cases are a powerful tool for requirements definition, elicitation, and testing. Since use cases are directly concerned with the users and requirements of the system, they play a large role in satisfying Prime Directive 1 ("is the system useful?"). With proper use case definition, one can make sure the system meets the needs of the users and provides clear use. In addition, it can improve the overall quality of the system through better black box testing and acceptance testing.
I used a form of use cases in my black box testing for many projects. With the use of JUNIT and HTTPUNIT, I tested specific behavior of a user to guarantee the system met the users needs.
10. Software Review
Software review involves having a third party review and test a system. This is the only real way to be sure the system meets the Prime Directives. No developer testing or tools can guarantee the system meets the Prime Directives. Having a third party install, run, and test the system can directly make sure the Prime Directives are met (at least 2 and 3).
We were asked to have other groups test our software several times throughout this semester. I found their review and feedback useful, especially the bug description and testing review.
11. Agile Methods (XP, Scrum, etc.)
Agile methods are techniques of a specific family of software development models. They stress simplicity, rapid releases, close interaction with users, and other techniques. This style of software development is not essential, and is more of a project management choice. It is a debate as to how this affects the Three Prime Directives, as there are many other software development models that can be used. For example, the spiral model or waterfall model may be more appropriate for certain projects.
12. Open Source Licenses (GPL, CPL, etc.)
There are many different open source licenses, but they all share the goal of making source code available. Projects that are open source tend to be community types of projects that have many people working on them. This type of development environment can produce high quality products in a short time.
The use of open source licenses (when paired with community support and communication) can also guarantee satisfaction of the Three Prime Directives. The first Prime Directive is met because the community would not work on a system that is not useful. With so many people installing running, and working on the system, it is guaranteed to be usable (Prime Directive 2). Finally, with so many developers, there has to be extensive documentation and methods to enhance the system (Prime Directive 3).
A prime example of the power of open source licenses is the development of the Linux operating system. This open source system is considered by many to be superior to other, proprietary systems such as Windows.
13. Online Hosting Services (Google Project Hosting, SourceForge, etc.)
There are many online hosting services available on the Internet today. They provide easy access to source code, documentation, and binaries. Making a system more widely available along with its documentation and use/development guides helps the system meet all three Prime Directives. More people will use the system, it will be easier to obtain and install, and the resources will be available to users and developers.
I used Google project hosting this semester and found it a easy to use tool for uploading of project material.
Summary
All of the tools and methods we have been introduced to this semester help in the developing of a system that meets the Three Prime Directives. There is no one tool that will solve all the problems of software development, but many can help. With the right tools and methods, the development of a useful, usable, and enhanceable system is possible.
Sunday, December 9, 2007
Friday, November 16, 2007
29.MyIsern-1.3-review
Reviewing Team Purple.
Team Purple distribution available Here
Installation review:
I began, as any user should, by looking at the installation guide available Here. The guide is short with just a few bulleted points. It was all very simple except for a couple points of confusion:
- "run the junit task..." is a bit confusing. I was not immediately certain that this was the command "ant -f junit.build.xml."
- There is no mention about the URL of the project once it is deployed. I had to go into the tomcat manager to find the exact URL of it. It would be helpful to mention this in the installation guide.
Other then the above confusing points, it was quite simple to install and run the MyIsern-purple system.
I then ran the verify ant task. I was quite impressed with the sheer volume of tests running. It seems they tested the project quite thoroughly. Verify, however, does not pass. Some warnings from Findbugs causes it to fail. The 9 Findbugs warnings range from simple redundant ToString() operations to perhaps more complex problems involving non-serializable objects and HttpSessions.
Code format and conventions review:
I was quite surprised by the number of classes that were present in this code. However, the design seemed quite clean. I could not find many code conventions violations, though I did find some redundancy in certain parts of the code:
- The login() method in the LoginActionBean.java file separately checks if the username, password, or both failed. This can all be done with a single check to greatly reduce the complexity.
- In the CollaborationFormActionBean.java file on line 129 the .toString method is used on a String.
- Perhaps some of the class names are too verbose. For example CollaborationFormActionBean is a bit long for a class name.
Most of the code seemed to follow the guidelines quite well. I could not find many violations.
Test case review:
As I mentioned earlier, there are a rather large number of tests for this project. Running the junit task takes around 30 seconds to complete with 42 total tests running.
Black Box Perspective:
Since black box testing should focus on I/O behavior, it must deal with the UI for this type of project. UI testing, however, can be difficult on this type of client-server application. While there were a large number of tests, particularly dealing with login/logout behavior, some of the more basic tests of the linking system were missing. To greater cover black box testing, it may be useful to create a series of tests (perhaps another test class) that checks all links and navigation through the system. A large part of web applications is navigation through the system, so it is important to test it.
There may also be an issue with concurrency, which is nearly impossible to test for. I would think it would fall into the black box perspective since concurrency issues come about when certain I/O events take place at certain times. There are no tests that deal with concurrency, though I do not think it is even feasible to test concurrency.
White Box Perspective:
The emma results were fairly good for this project, considering the difficulty of testing server-side components. The results from emma were
Emma Coverage summary
class: 88% (29/33)
method: 67% (172/255)
block: 61% (1908/3153)
line: 62% (405.1/656)
For many of the classes, general tests were performed over the entire class (or functionality), yet not many had tests for each individual method. The coarse granularity of the tests focused more on Black box testing. For example, the LoginActionBean class only have tests for the SecurityFilter and various standard login events. Each specific method of the class is not tested, as should be attempted with a white box testing perspective. Many very small tests could be added to test each small piece of code. This could increase the coverage as well.
Break Da Buggah:
I think many people had trouble getting the system complete by this stage, so I was not surprised to find an unfinished section of the project. The "about us" link leads to a non-existent page called reports.jsp. This is simply a finishing problem and not an actual problem with the project.
Another small bug I found involved adding new objects. When a new collaboration is being added, the Years list is not filled with any values, so it is impossible to specify what years the collaboration took place during. This is simply a matter of propagating the list even when a new entry is being created.
User Interface review:
At this point in the project, I try not to focus on aesthetics of the pages at all. The "fluff" can be added later once all of the functionality is available.
The basic navigation of the system is quite nice. It is easy to view each list and navigate to the edit page. I like the feature that automatically propagates the edit form when the user clicks on the edit button for a particular row. It reduces mouse clicks and enables users to quickly and easily make changes. The use of thumbnails for researchers is nice as well. Perhaps even logo thumbnails could be added for the organizations table.
I think an easy way to see all of the data for every entry would be nice. The lists for each type (Researcher, Collaboration, or Organization) only contain the names. Some users may way to see every Researcher and their organizations in a single table, for example. Either an additional page is needed to display this information or the lists could contain all the data relevant to each object.
The system works quite well with a small amount of screen space. At 1/3 width and 1/3 height of my screen, I was still able to see the tables and all of the text boxes (on the add/edit pages).
One small change I would suggest is using a button instead of link for the "create" button after the tables. Using a button and perhaps placing an additional one just before the table could make it easier for new users.
Summary and Lessons Learned:
I learned a great deal from reviewing this project, since our project is less polished at this stage. While there are many components to this system, they are well integrated and nearly everything works perfectly. After reviewing this project, I may break up my project at this point to modularize it.
The login system using the SecurityFilter works very well. The login system used by my project is very different. Perhaps the SecurityFilter method is better.
I also realized how thorough the testing needs to be for this project. Since 1.2 this project has become much more complex and the volume and quality of test cases needs to reflect that. I will add many more tests to my own project now that I have seen many methods of testing this type of project.
Team Purple distribution available Here
Installation review:
I began, as any user should, by looking at the installation guide available Here. The guide is short with just a few bulleted points. It was all very simple except for a couple points of confusion:
- "run the junit task..." is a bit confusing. I was not immediately certain that this was the command "ant -f junit.build.xml."
- There is no mention about the URL of the project once it is deployed. I had to go into the tomcat manager to find the exact URL of it. It would be helpful to mention this in the installation guide.
Other then the above confusing points, it was quite simple to install and run the MyIsern-purple system.
I then ran the verify ant task. I was quite impressed with the sheer volume of tests running. It seems they tested the project quite thoroughly. Verify, however, does not pass. Some warnings from Findbugs causes it to fail. The 9 Findbugs warnings range from simple redundant ToString() operations to perhaps more complex problems involving non-serializable objects and HttpSessions.
Code format and conventions review:
I was quite surprised by the number of classes that were present in this code. However, the design seemed quite clean. I could not find many code conventions violations, though I did find some redundancy in certain parts of the code:
- The login() method in the LoginActionBean.java file separately checks if the username, password, or both failed. This can all be done with a single check to greatly reduce the complexity.
- In the CollaborationFormActionBean.java file on line 129 the .toString method is used on a String.
- Perhaps some of the class names are too verbose. For example CollaborationFormActionBean is a bit long for a class name.
Most of the code seemed to follow the guidelines quite well. I could not find many violations.
Test case review:
As I mentioned earlier, there are a rather large number of tests for this project. Running the junit task takes around 30 seconds to complete with 42 total tests running.
Black Box Perspective:
Since black box testing should focus on I/O behavior, it must deal with the UI for this type of project. UI testing, however, can be difficult on this type of client-server application. While there were a large number of tests, particularly dealing with login/logout behavior, some of the more basic tests of the linking system were missing. To greater cover black box testing, it may be useful to create a series of tests (perhaps another test class) that checks all links and navigation through the system. A large part of web applications is navigation through the system, so it is important to test it.
There may also be an issue with concurrency, which is nearly impossible to test for. I would think it would fall into the black box perspective since concurrency issues come about when certain I/O events take place at certain times. There are no tests that deal with concurrency, though I do not think it is even feasible to test concurrency.
White Box Perspective:
The emma results were fairly good for this project, considering the difficulty of testing server-side components. The results from emma were
Emma Coverage summary
class: 88% (29/33)
method: 67% (172/255)
block: 61% (1908/3153)
line: 62% (405.1/656)
For many of the classes, general tests were performed over the entire class (or functionality), yet not many had tests for each individual method. The coarse granularity of the tests focused more on Black box testing. For example, the LoginActionBean class only have tests for the SecurityFilter and various standard login events. Each specific method of the class is not tested, as should be attempted with a white box testing perspective. Many very small tests could be added to test each small piece of code. This could increase the coverage as well.
Break Da Buggah:
I think many people had trouble getting the system complete by this stage, so I was not surprised to find an unfinished section of the project. The "about us" link leads to a non-existent page called reports.jsp. This is simply a finishing problem and not an actual problem with the project.
Another small bug I found involved adding new objects. When a new collaboration is being added, the Years list is not filled with any values, so it is impossible to specify what years the collaboration took place during. This is simply a matter of propagating the list even when a new entry is being created.
User Interface review:
At this point in the project, I try not to focus on aesthetics of the pages at all. The "fluff" can be added later once all of the functionality is available.
The basic navigation of the system is quite nice. It is easy to view each list and navigate to the edit page. I like the feature that automatically propagates the edit form when the user clicks on the edit button for a particular row. It reduces mouse clicks and enables users to quickly and easily make changes. The use of thumbnails for researchers is nice as well. Perhaps even logo thumbnails could be added for the organizations table.
I think an easy way to see all of the data for every entry would be nice. The lists for each type (Researcher, Collaboration, or Organization) only contain the names. Some users may way to see every Researcher and their organizations in a single table, for example. Either an additional page is needed to display this information or the lists could contain all the data relevant to each object.
The system works quite well with a small amount of screen space. At 1/3 width and 1/3 height of my screen, I was still able to see the tables and all of the text boxes (on the add/edit pages).
One small change I would suggest is using a button instead of link for the "create" button after the tables. Using a button and perhaps placing an additional one just before the table could make it easier for new users.
Summary and Lessons Learned:
I learned a great deal from reviewing this project, since our project is less polished at this stage. While there are many components to this system, they are well integrated and nearly everything works perfectly. After reviewing this project, I may break up my project at this point to modularize it.
The login system using the SecurityFilter works very well. The login system used by my project is very different. Perhaps the SecurityFilter method is better.
I also realized how thorough the testing needs to be for this project. Since 1.2 this project has become much more complex and the volume and quality of test cases needs to reflect that. I will add many more tests to my own project now that I have seen many methods of testing this type of project.
Monday, November 5, 2007
25.WebAppQuestions
1. Explain in your own words the meaning of the web "request-response cycle".
The request-response cycle is the method by which web applications retrieve data from sources on the web. The client sends a request to a server that will use the data in the request to return a response. When the client performs some other action, it sends another response and the cycle continues.
2. Explain how servlets facilitate processing of the request-response cycle.
A servlet is a program that runs on the server to handle requests and return responses to the client. Unlike client applets that run on the client side and send requests, a servlet receives requests from the client, performs some operations, and returns a response.
3. How do you login to the Tomcat Manager?
To login to Tomcat Manager you simply run Tomcat on your local machine and connect to http://localhost:8080/ and click on the "Tomcat Manager" link. You are then prompted for the username and password that is defined in the conf/tomcat-users.xml file.
4. What is the Tomcat Manager used for in the StackStripes application?
The Tomcat Manager enables you to make the StackStripes program available to web users. The StackStripes application provides the Tomcat Manager with locations and configuration options of files that are to be deployed on the server and the manager makes them accessible to clients.
Any application that is deployed on Tomcat and therefore available to web users is contained in the webapps directory. Within the webapps directory, each application will have its own directory structure. The StackStripes application has, within its folder in the webapps directory, the following files/folders:
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!)
META-INF - Contains meta file(s) with various meta data about the application.
WEB-INF - Contains the actual application and configuration files.
index.jsp - The default page that loads when no specific file is provided.
6. How do you build a war directory structure in Ant? Where is this accomplished in the StackStripes application?
A war directory structure can be built using ANT with a build.xml file. The build.xml file for the StackStripes creates a war structure in the "war" target. It contains a war element that creates a .war file in a specific file location defined within the element.
7. How do you install a war directory in a running Tomcat server? What information does the Ant task need to accomplish this?
If configured to automatically deploy, you can simply place a war directory into the webapps folder to install it on the server. The Ant task needs only to know the location of the webapps folder which is available in the $CATALINA_HOME environment variable.
8. What is the "Model2" architecture? What are its advantages?
Model2 is also knows as MVC (or Model View Controller) because it structures the client/server architecture into three components. The model contains any data or structures needed to maintain it (ie. database), the view contains the client presentation, and the controller accepts requests from the client and gives necessary data to the model. This architecture provides modularity and allows each component to be built in such a way that changes to one will not impact the others.
9. What are JSP pages? How are they related to servlets?
JSP (or JavaServer pages) are pages that are compiled into Java servlets on the server. They allow the server to dynamically generate pages in response to a client request.
10. Why is there a delay when retrieving a JSP page for the first time? Where is the Java code for that page stored?
Since they must be compiled into a servlet the first time the page is being retrieved, there is a delay for the JSP compiler to run on the server. However, once the servlet is compiled it is contained within memory and does not need to be compiled for further use.
11. What are JSTL tags? Why are they useful? What is an example JSTL tag from the StackStripes system?
JSTL tags are a set of tags usable within JSP pages provide methods for performing common tasks without the need of embedded Java. Since they allow you to perform tasks without embedded Java, they allow better separation of the application from the user interface defined in the JSP pages. The StackStripes system uses "c:forEach" tag to easily iterate and display all of the elements of the stack.
12. What are Stripes tags? Why are they useful? What is an example Stripes tag from the StackStripes system?
Stripes tags are tags defined by the Stripes web application framework. They enable you to easily link JSP tags with classes and methods in the Java application. Many Stripes tags are needed by the StackStripes system, for example the tag
< stripes:submit value="push" name="push"/>
causes the method called push to be evoked when the user clicks the "push" button.
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 provides a method for visiting and performing operation on websites automatically within code. It allows us to test systems that operate on the web, while JUnit is limited to a single local system. Every test that is performed on the server requires HttpUnit to run. Every test of the JavaActionBean class of the StackStripes uses HttpUnit.
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?
Very little had to be changed to implement the DoubleIt button. I simply had to add a new form to the JSP page and add the functionality to the StackModel class. The controller component did not have to be changed. This exercise illustrated how the MVC architecture allowed functionality to be added without changing every component.
15. What are the equivalence classes that need to be tested for the Double It button?
There were only two equivalence classes that needed to be tested: doubling an empty stack and doubling a non-empty 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.
And after clicking the "Double It" button.
17. What is the singleton design pattern? What is an example of its use in StackStripes? Why is it needed?
The singleton design pattern restricts the class to having only a single instantiation. For all users to interact with the same stack, this method is required. The stack in the StackStripes system is defined as a singleton by declaring the constructor as private and defining a single instance variable was static.
18. Some of the StackStripes tests exercise code on the "server side", while others exercise code on the "client" side. Which test classes exercise code on the "server", and which exercise code on the "client"? How does Emma deal with this to create appropriate coverage data?
The tests in TestStackActionBean are run on the server while the tests in TestStackModel run on the client. Emma can collect coverage data from both classes of JUnit test cases, but it cannot collect the data on the server until Tomcat is shutdown. That is why the emma.build.xml file shuts down the Tomcat server.
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 Tomcat is currently running on the local machine and that it has the correct login/password.
tomcat.undeploy - deletes StackStripes from the Tomcat server.
compile – compiles the StackStripes system.
war – builds the war directory structure to be deployed on the Tomcat server.
tomcat.deploy – deploys the previously created war file to the Tomcat server.
junit.tool – runs all JUnit tests.
junit.report – creates the JUnit report files.
junit – Runs both the junit.tool and junit.report targets.
The request-response cycle is the method by which web applications retrieve data from sources on the web. The client sends a request to a server that will use the data in the request to return a response. When the client performs some other action, it sends another response and the cycle continues.
2. Explain how servlets facilitate processing of the request-response cycle.
A servlet is a program that runs on the server to handle requests and return responses to the client. Unlike client applets that run on the client side and send requests, a servlet receives requests from the client, performs some operations, and returns a response.
3. How do you login to the Tomcat Manager?
To login to Tomcat Manager you simply run Tomcat on your local machine and connect to http://localhost:8080/ and click on the "Tomcat Manager" link. You are then prompted for the username and password that is defined in the conf/tomcat-users.xml file.
4. What is the Tomcat Manager used for in the StackStripes application?
The Tomcat Manager enables you to make the StackStripes program available to web users. The StackStripes application provides the Tomcat Manager with locations and configuration options of files that are to be deployed on the server and the manager makes them accessible to clients.
Any application that is deployed on Tomcat and therefore available to web users is contained in the webapps directory. Within the webapps directory, each application will have its own directory structure. The StackStripes application has, within its folder in the webapps directory, the following files/folders:
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!)
META-INF - Contains meta file(s) with various meta data about the application.
WEB-INF - Contains the actual application and configuration files.
index.jsp - The default page that loads when no specific file is provided.
6. How do you build a war directory structure in Ant? Where is this accomplished in the StackStripes application?
A war directory structure can be built using ANT with a build.xml file. The build.xml file for the StackStripes creates a war structure in the "war" target. It contains a war element that creates a .war file in a specific file location defined within the element.
7. How do you install a war directory in a running Tomcat server? What information does the Ant task need to accomplish this?
If configured to automatically deploy, you can simply place a war directory into the webapps folder to install it on the server. The Ant task needs only to know the location of the webapps folder which is available in the $CATALINA_HOME environment variable.
8. What is the "Model2" architecture? What are its advantages?
Model2 is also knows as MVC (or Model View Controller) because it structures the client/server architecture into three components. The model contains any data or structures needed to maintain it (ie. database), the view contains the client presentation, and the controller accepts requests from the client and gives necessary data to the model. This architecture provides modularity and allows each component to be built in such a way that changes to one will not impact the others.
9. What are JSP pages? How are they related to servlets?
JSP (or JavaServer pages) are pages that are compiled into Java servlets on the server. They allow the server to dynamically generate pages in response to a client request.
10. Why is there a delay when retrieving a JSP page for the first time? Where is the Java code for that page stored?
Since they must be compiled into a servlet the first time the page is being retrieved, there is a delay for the JSP compiler to run on the server. However, once the servlet is compiled it is contained within memory and does not need to be compiled for further use.
11. What are JSTL tags? Why are they useful? What is an example JSTL tag from the StackStripes system?
JSTL tags are a set of tags usable within JSP pages provide methods for performing common tasks without the need of embedded Java. Since they allow you to perform tasks without embedded Java, they allow better separation of the application from the user interface defined in the JSP pages. The StackStripes system uses "c:forEach" tag to easily iterate and display all of the elements of the stack.
12. What are Stripes tags? Why are they useful? What is an example Stripes tag from the StackStripes system?
Stripes tags are tags defined by the Stripes web application framework. They enable you to easily link JSP tags with classes and methods in the Java application. Many Stripes tags are needed by the StackStripes system, for example the tag
< stripes:submit value="push" name="push"/>
causes the method called push to be evoked when the user clicks the "push" button.
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 provides a method for visiting and performing operation on websites automatically within code. It allows us to test systems that operate on the web, while JUnit is limited to a single local system. Every test that is performed on the server requires HttpUnit to run. Every test of the JavaActionBean class of the StackStripes uses HttpUnit.
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?
Very little had to be changed to implement the DoubleIt button. I simply had to add a new form to the JSP page and add the functionality to the StackModel class. The controller component did not have to be changed. This exercise illustrated how the MVC architecture allowed functionality to be added without changing every component.
15. What are the equivalence classes that need to be tested for the Double It button?
There were only two equivalence classes that needed to be tested: doubling an empty stack and doubling a non-empty 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.
And after clicking the "Double It" button.
17. What is the singleton design pattern? What is an example of its use in StackStripes? Why is it needed?
The singleton design pattern restricts the class to having only a single instantiation. For all users to interact with the same stack, this method is required. The stack in the StackStripes system is defined as a singleton by declaring the constructor as private and defining a single instance variable was static.
18. Some of the StackStripes tests exercise code on the "server side", while others exercise code on the "client" side. Which test classes exercise code on the "server", and which exercise code on the "client"? How does Emma deal with this to create appropriate coverage data?
The tests in TestStackActionBean are run on the server while the tests in TestStackModel run on the client. Emma can collect coverage data from both classes of JUnit test cases, but it cannot collect the data on the server until Tomcat is shutdown. That is why the emma.build.xml file shuts down the Tomcat server.
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 Tomcat is currently running on the local machine and that it has the correct login/password.
tomcat.undeploy - deletes StackStripes from the Tomcat server.
compile – compiles the StackStripes system.
war – builds the war directory structure to be deployed on the Tomcat server.
tomcat.deploy – deploys the previously created war file to the Tomcat server.
junit.tool – runs all JUnit tests.
junit.report – creates the JUnit report files.
junit – Runs both the junit.tool and junit.report targets.
26.StackStripesExtension
The distribution is available
Here
This was a simple exercise in learning the technology that will be used in later projects.
Installing Tomcat
I found this rather easy. I simply downloaded it, unzipped it, read some of the documentation to make sure I had everything correct, and ran it. I was able to connect to http://localhost:8080 right away without any problems.
Installing Stripes
Another rather easy task, as it simply involved downloading files and placing them in correct directories. After placing the stripes-examples.war file in the webapps directory, I was able to connect to http://localhost:8080/stripes-examples without any problems.
Installing StackStripes
Now this task was a bit more tricky. I was able to get it downloaded and deployed on Tomcat rather quickly, but came across some problems with getting all of the build.xml files to work correctly. I would always get a fail on verify because emma would not run properly. However, after reading the discussion boards about emma, I simply ran junit first and ran tomcat from the stackstripes project directory. After doing this, everything worked fine.
Improving coverage
When I first looked at the TestActionBean.java file, I was rather confused. It seemed that it was quite complicated to run tests on the server side of the project. However, after reading some more documentation and playing around with some of the code, I managed to get a good grasp on it. It appeared that the two methods that were not tested were the pop method in StackActionBean and the iterator in StackModel. I added test for these two methods and a error check for popping an empty stack to achieve 100% coverage in all areas.
The Double It button
It was surprisingly easy to create the "Double It" button and functionality. I did, however, have one strange problem with concurrency. There are some concurrency issues when iterating over a stack and pushing new elements on it at the same time. To overcome this, my doubleIt method first copies the entire stack to a temporary location then pushes the new members onto the original stack. This prevents concurrency problems with the iterator.
I also added one additional test of this method to keep emma coverage at 100%.
Conclusions
Overall this was a pretty straightforward task that allowed me to learn some of the technology we will need in the future. I like the simplicity of Stripes and the ease of adding new components. I think I am now ready to do more complex work with this technology.
Here
This was a simple exercise in learning the technology that will be used in later projects.
Installing Tomcat
I found this rather easy. I simply downloaded it, unzipped it, read some of the documentation to make sure I had everything correct, and ran it. I was able to connect to http://localhost:8080 right away without any problems.
Installing Stripes
Another rather easy task, as it simply involved downloading files and placing them in correct directories. After placing the stripes-examples.war file in the webapps directory, I was able to connect to http://localhost:8080/stripes-examples without any problems.
Installing StackStripes
Now this task was a bit more tricky. I was able to get it downloaded and deployed on Tomcat rather quickly, but came across some problems with getting all of the build.xml files to work correctly. I would always get a fail on verify because emma would not run properly. However, after reading the discussion boards about emma, I simply ran junit first and ran tomcat from the stackstripes project directory. After doing this, everything worked fine.
Improving coverage
When I first looked at the TestActionBean.java file, I was rather confused. It seemed that it was quite complicated to run tests on the server side of the project. However, after reading some more documentation and playing around with some of the code, I managed to get a good grasp on it. It appeared that the two methods that were not tested were the pop method in StackActionBean and the iterator in StackModel. I added test for these two methods and a error check for popping an empty stack to achieve 100% coverage in all areas.
The Double It button
It was surprisingly easy to create the "Double It" button and functionality. I did, however, have one strange problem with concurrency. There are some concurrency issues when iterating over a stack and pushing new elements on it at the same time. To overcome this, my doubleIt method first copies the entire stack to a temporary location then pushes the new members onto the original stack. This prevents concurrency problems with the iterator.
I also added one additional test of this method to keep emma coverage at 100%.
Conclusions
Overall this was a pretty straightforward task that allowed me to learn some of the technology we will need in the future. I like the simplicity of Stripes and the ease of adding new components. I think I am now ready to do more complex work with this technology.
Monday, October 22, 2007
21.MyISERN-1.2
Distribution of system available Here
Project home page is Here
All tasks were completed.
Difficulties
There were numerous difficulties in this section of the project. At first glance, I thought it would be rather easy, yet it turned out to be quite challenging. The annoyances of many of the components made getting the final project working quite difficult.
At our first meeting, we began discussing the UI and possible cases we needed to consider that might happen. It turned out that there were so many strange cases that could occur that the UI and underlying error checking system had to be quite complex. There were so many cases to consider and messages to give the user that just the UI because quite monstrous.
Once we had a partially working system, I began playing around with some of the data and trying to run as many cases as I could. At this point I realized how unforgiving JAXB and XML can be. Several times in this process the JAXB marshalling methods corrupted the XML files. It turns out that the JAXB Marshaller will sometimes write a format that will cause the Unmarshaller to crash with an exception. Our error checking mechanisms within the system had to be very robust to ensure this type of problem never occurs.
The testing of this system was a real problem. Since so many components of the additions in 1.2 rely on user interaction from System.in, I was unable to write many JUNIT test cases. Much of my testing was done by simply using the system and trying to break it. Entering the data turned out to be an exercise in breaking the system as well. On several occasions the system created corrupt XML files after I had entered a rather large amount of data, revealing a new bug. The SVN revert option was quite handy.
Group Organization
As we had done for our earlier version, myself and my teammate Shaoxuan Zhang met at the library for a long hacking session. After this 3 hour meeting on Thursday, we had most of the system complete. After that, we simply stayed in contact with email and Skype. It turned out quite well, since most of the data entry and debugging was difficult to work on as a team.
Future thoughts
At this point, the program is already becoming very large and somewhat difficult to manage. I think the incremental development we have been doing with 1.0, 1.1, and 1.2 made the design process difficult. Now that we have a more clear idea of how the entire final system will be, we can design a much more efficient system. There are many components in our current system that may not be used in the future. The slimming down of the system will make it much less buggy and more easily manageable in the future.
Lessons Learned
JAXB can be a pain, especially since the Marshaller and Unmarshaller do not behave the same when errors are present. I also learned the importance of early and complete design to keep the final system manageable. Finally, I gained some more experience with eclipse and the debugging features it provides.
Project home page is Here
All tasks were completed.
Difficulties
There were numerous difficulties in this section of the project. At first glance, I thought it would be rather easy, yet it turned out to be quite challenging. The annoyances of many of the components made getting the final project working quite difficult.
At our first meeting, we began discussing the UI and possible cases we needed to consider that might happen. It turned out that there were so many strange cases that could occur that the UI and underlying error checking system had to be quite complex. There were so many cases to consider and messages to give the user that just the UI because quite monstrous.
Once we had a partially working system, I began playing around with some of the data and trying to run as many cases as I could. At this point I realized how unforgiving JAXB and XML can be. Several times in this process the JAXB marshalling methods corrupted the XML files. It turns out that the JAXB Marshaller will sometimes write a format that will cause the Unmarshaller to crash with an exception. Our error checking mechanisms within the system had to be very robust to ensure this type of problem never occurs.
The testing of this system was a real problem. Since so many components of the additions in 1.2 rely on user interaction from System.in, I was unable to write many JUNIT test cases. Much of my testing was done by simply using the system and trying to break it. Entering the data turned out to be an exercise in breaking the system as well. On several occasions the system created corrupt XML files after I had entered a rather large amount of data, revealing a new bug. The SVN revert option was quite handy.
Group Organization
As we had done for our earlier version, myself and my teammate Shaoxuan Zhang met at the library for a long hacking session. After this 3 hour meeting on Thursday, we had most of the system complete. After that, we simply stayed in contact with email and Skype. It turned out quite well, since most of the data entry and debugging was difficult to work on as a team.
Future thoughts
At this point, the program is already becoming very large and somewhat difficult to manage. I think the incremental development we have been doing with 1.0, 1.1, and 1.2 made the design process difficult. Now that we have a more clear idea of how the entire final system will be, we can design a much more efficient system. There are many components in our current system that may not be used in the future. The slimming down of the system will make it much less buggy and more easily manageable in the future.
Lessons Learned
JAXB can be a pain, especially since the Marshaller and Unmarshaller do not behave the same when errors are present. I also learned the importance of early and complete design to keep the final system manageable. Finally, I gained some more experience with eclipse and the debugging features it provides.
19.UseCaseSpecification
Our use case wiki pages are available Here.
At first we were a little bit confused as to the particular format wanted. Most of the information available on the web about use cases involves stick figures and bubbles. Very few even mention UI mock-ups. Most pages show are very rigid templates, for example Here.
After realizing what we needed to do, we first created the use case for a simple log in. After that, we decided to come up with the "home page" that contains all of the features of the system. From there, we simply made a use case for each link from the home page (each has one specific function).
When I first pulled up Gimp and started working hard trying to make the pages look nice, I realized the aesthetics are unimportant. The objective is to outline the functionality, not the look of the final UI. In the end I threw away my complex diagrams and made very simple, functional diagrams.
At first we were a little bit confused as to the particular format wanted. Most of the information available on the web about use cases involves stick figures and bubbles. Very few even mention UI mock-ups. Most pages show are very rigid templates, for example Here.
After realizing what we needed to do, we first created the use case for a simple log in. After that, we decided to come up with the "home page" that contains all of the features of the system. From there, we simply made a use case for each link from the home page (each has one specific function).
When I first pulled up Gimp and started working hard trying to make the pages look nice, I realized the aesthetics are unimportant. The objective is to outline the functionality, not the look of the final UI. In the end I threw away my complex diagrams and made very simple, functional diagrams.
Wednesday, October 17, 2007
22.MyISERN-1.1.Review
Author: Chiao-Fen Zielinski-Liu
Installation
I was easily able to download and use the system. The UserGuide provided is quite straightforward and it was a simple task to get the system running. I was able to immediately run all of the queries through the commands of the form
java -jar myisern.jar
Loading the project into eclipse, however, was not quite as easy. Once imported, I got many errors from the build path. Since this always happens, I knew what environment variables to load to get the system working. The DevelopersGuide, however, does not clearly outline the required variables to import the system into eclipse. Overall it was rather easy to get all aspects of the system installed and running properly.
Code Format and Conventions
When I first looked at the source code for this project, I was rather surprised and pleased by the small number of classes and only one package. Some versions of this system can quickly become monstrously large. Most of the code fit the conventions rather well, however I did see some areas with some minor documentation and naming issues:
Test Cases
The test cases are, overall, rather extensive. The basic functionality of almost every unit is separately tested well, though I was confused to find all the tests in the same file (except for one that was in MyIsernXml.java). The majority of the testing seemed to be of the parser "MyIsernPrinter" class.
Black Box
Many of the units were tested for their specific I/O. For example, various input strings were tested on the MyIsernPrinter class and the return code was tested. However, specific end-to-end I/O black box tests were somewhat lacking. From a black box perspective, a test of the I/O relationship over the entire system can be useful.
White Box
Quite a lot of white box testing was done in this system. Emma shows the coverage to be over 90%. All the modules were tested for many different values. The details of the TablePrinter and MyIsernPrinter classes were especially well tested. However, from a white box perspective, exception testing was missing.
Testing for exceptions can be very important when analyzing the structure of the system. Rather than having the tests just throw the exception away, it can be helpful to test when an exception should be thrown and when they should not be.
Break Da Buggah
This system was quite difficult to break. I behaved quite well with nearly any input. Most of the problems I was able to find were simply unclear error messages and unexpected features.
For example, when running the system with no arguments a rather nice (though unexpected) thing occurs. Windows appear containing the contents of each table. While this functionality is nice, the documentation is rather unspecific about it and the requirements do not mention it. Some of the error messages are also quite unspecific and general.
After lots of trying, I did manage to get the system to behave unexpectedly. When running the following query:
-listOrganizations -collaborationLevelEquals 99999999999999999999
The following is output:
Print job was not successful
A check for values over the maximum integer size could fix this problem.
Summary and Lessons Learned
Overall this system is quite simple and concise. It handles many unexpected values rather well, delivers the data correctly, and even has some nice additional features. However, there are some places where the structure could be improved. Some of the functionality is rather rigidly implemented that may make future enhancement of the system difficult. For example, the class used to parse the command line may be very difficult to later expand. It uses a rather complex "code" type of system with many if statements that may be problematic in future development.
From this system I learned about the JFrame utility, which seems like a really nice tool for displaying various objects to the user. I think it may come in handy in future projects. I also saw some places where my own system could be improved, for example the handling of very unexpected input values.
Installation
I was easily able to download and use the system. The UserGuide provided is quite straightforward and it was a simple task to get the system running. I was able to immediately run all of the queries through the commands of the form
java -jar myisern.jar
Loading the project into eclipse, however, was not quite as easy. Once imported, I got many errors from the build path. Since this always happens, I knew what environment variables to load to get the system working. The DevelopersGuide, however, does not clearly outline the required variables to import the system into eclipse. Overall it was rather easy to get all aspects of the system installed and running properly.
Code Format and Conventions
When I first looked at the source code for this project, I was rather surprised and pleased by the small number of classes and only one package. Some versions of this system can quickly become monstrously large. Most of the code fit the conventions rather well, however I did see some areas with some minor documentation and naming issues:
| File | Lines | Violation | Comments |
| TestMyIsernXmlLoader.java | 18 | N/A | Author and comment unedited since example |
| PrinterData.java | 120,140,160,... | EJS-33 | Whitespace or moving comments may make reading easier |
| MyIsernPrinter.java | 16 | EJS-7 | White space needed between methods |
Test Cases
The test cases are, overall, rather extensive. The basic functionality of almost every unit is separately tested well, though I was confused to find all the tests in the same file (except for one that was in MyIsernXml.java). The majority of the testing seemed to be of the parser "MyIsernPrinter" class.
Black Box
Many of the units were tested for their specific I/O. For example, various input strings were tested on the MyIsernPrinter class and the return code was tested. However, specific end-to-end I/O black box tests were somewhat lacking. From a black box perspective, a test of the I/O relationship over the entire system can be useful.
White Box
Quite a lot of white box testing was done in this system. Emma shows the coverage to be over 90%. All the modules were tested for many different values. The details of the TablePrinter and MyIsernPrinter classes were especially well tested. However, from a white box perspective, exception testing was missing.
Testing for exceptions can be very important when analyzing the structure of the system. Rather than having the tests just throw the exception away, it can be helpful to test when an exception should be thrown and when they should not be.
Break Da Buggah
This system was quite difficult to break. I behaved quite well with nearly any input. Most of the problems I was able to find were simply unclear error messages and unexpected features.
For example, when running the system with no arguments a rather nice (though unexpected) thing occurs. Windows appear containing the contents of each table. While this functionality is nice, the documentation is rather unspecific about it and the requirements do not mention it. Some of the error messages are also quite unspecific and general.
After lots of trying, I did manage to get the system to behave unexpectedly. When running the following query:
-listOrganizations -collaborationLevelEquals 99999999999999999999
The following is output:
Print job was not successful
A check for values over the maximum integer size could fix this problem.
Summary and Lessons Learned
Overall this system is quite simple and concise. It handles many unexpected values rather well, delivers the data correctly, and even has some nice additional features. However, there are some places where the structure could be improved. Some of the functionality is rather rigidly implemented that may make future enhancement of the system difficult. For example, the class used to parse the command line may be very difficult to later expand. It uses a rather complex "code" type of system with many if statements that may be problematic in future development.
From this system I learned about the JFrame utility, which seems like a really nice tool for displaying various objects to the user. I think it may come in handy in future projects. I also saw some places where my own system could be improved, for example the handling of very unexpected input values.
Monday, October 15, 2007
18.MyISERN-1.1
Project download and wiki pages available at:
http://code.google.com/p/myisern-1-ivory/
We completed all tasks assigned to us.
Difficulties
In this section of the assignment, our project grew a great deal. Our structure may be overly complicated and is becoming much more difficult to manage. However, it deals with the problem quite well and has been tested enough that I have confidence it will be quite difficult to break.
One difficulty was the command-line parser. I first considered this to be one of the easiest components, but with some confusion and trying to get enum to work, it because rather annoying. Overall the project went quite smoothly and we completed all tasks without too much trouble.
Teamwork
In this phase we worked well together. Early on we defined all of the issues and components needed so we could more easily break up the work. On Thursday we met at the library and in a few hours were able to design and implement most of the system. After that we kept in contact with Skype and email. I think the issue driven design works very well.
Lessons learned
There were several times in this assignment when I realized how much more comfortable I am becoming with Java and the tools we are using. I can see I am also becoming much better are creating test cases. Just the experience of continually working on this project is teaching me a lot about software development.
I also learned how valuable a project outline is. The issue feature on Google projects provided my team with a way to easily outline the project and efficiently divide up work. I will definitely use this type of method in future group efforts if possible
http://code.google.com/p/myisern-1-ivory/
We completed all tasks assigned to us.
Difficulties
In this section of the assignment, our project grew a great deal. Our structure may be overly complicated and is becoming much more difficult to manage. However, it deals with the problem quite well and has been tested enough that I have confidence it will be quite difficult to break.
One difficulty was the command-line parser. I first considered this to be one of the easiest components, but with some confusion and trying to get enum to work, it because rather annoying. Overall the project went quite smoothly and we completed all tasks without too much trouble.
Teamwork
In this phase we worked well together. Early on we defined all of the issues and components needed so we could more easily break up the work. On Thursday we met at the library and in a few hours were able to design and implement most of the system. After that we kept in contact with Skype and email. I think the issue driven design works very well.
Lessons learned
There were several times in this assignment when I realized how much more comfortable I am becoming with Java and the tools we are using. I can see I am also becoming much better are creating test cases. Just the experience of continually working on this project is teaching me a lot about software development.
I also learned how valuable a project outline is. The issue feature on Google projects provided my team with a way to easily outline the project and efficiently divide up work. I will definitely use this type of method in future group efforts if possible
Wednesday, October 10, 2007
16.MyIsernReview
Author of reviewed code: Shaoxuan Zhang
Introduction
This was a very interesting exercise for me, as the person who's code I reviewed was my group member. Therefore, the code I reviewed is, at least partially, my own. This essentially provided me with an opportunity to look at my own product and try to critique it.
Installation review
Although I already had this entire project on my computer, I tried to download it and run it as though I had never done so before. Since there was no .jar file contained in the download package, I ran it by importing it into eclipse.
I was able to easily download the file from the link provided on Shaoxuan Zhang's blog entry. It was a simple task to import the project into eclipse and run it. I had no problems installing and running this software. It passed the verify.build.xml test without and errors. At this point I have no problems with the project.
Code format and conventions review
This was an interesting task, as I had previously read and worked on the code I was trying to review. Going over this code again just focusing on code format gave me a different outlook on the code. Despite my best efforts, however, I was only able to find one problem. A bit more white space between methods would have made the code slightly easier to read. My table of convention violations is only
Test case review
This was a particularly difficult area for me to critique, since it was my job to test the code. I tried to look at my own code with a critical eye and think of what was lacking in my own test cases.
Black box perspective
From a black box perspective, this was a difficult program to test. The requirements were just that the output be a series of tables containing the data from the XML files. There was no specification as to the format of the tables. Therefore, creating general test cases that considered the output of the entire system was nearly impossible.
Despite this, a test that parsed the output tables and compared them with expected values was missing.
White box perspective
This are was quite thoroughly tested. There were many tests for boundary conditions and illegal values. There were 8 separate tests for exceptions, as seen from the output of running JUNIT. Looking at the output from emma, there is only one section of code that was not tested, and that was the exception handing within of ExamplePrinter, the class that contained the main function. This section of code would only run if there was something wrong with any of the xml files used by main(). However, since the file names are hard coded, I see no way of testing this section of code. I could find no other missing tests from a white box perspective.
Break da buggah
It took me quite a long time to break this code, but I was able to find a problem. If the XML file is of an incorrect format, the program does not always behave correctly. For example, if an element is repeated twice with two different values, only the second will be displayed. For example, I edited collaborations.example.xml by adding an additional < Description> element, such as:
< Description>
A graduate student at the University of Hawaii spent the summer working in the University of Maryland research group.
</Description>
< Description>
This is a second description that does not belong here.
</Description>
This invalid XML format is not caught by the system and the output table contains
Summary and Lessons Learned
I got a fresh new perspective on my own project, and I think I did a fairly good job. I think Shaoxuan Zhang and I did a good job on the structure, design, implementation, and testing of the project. Perhaps the only thing I would change is to add some more complete black box tests.
I tried to critique my own code fairly, but I think it is impossible when you already know so much about it. It is much harder to critique and break your own code.
Introduction
This was a very interesting exercise for me, as the person who's code I reviewed was my group member. Therefore, the code I reviewed is, at least partially, my own. This essentially provided me with an opportunity to look at my own product and try to critique it.
Installation review
Although I already had this entire project on my computer, I tried to download it and run it as though I had never done so before. Since there was no .jar file contained in the download package, I ran it by importing it into eclipse.
I was able to easily download the file from the link provided on Shaoxuan Zhang's blog entry. It was a simple task to import the project into eclipse and run it. I had no problems installing and running this software. It passed the verify.build.xml test without and errors. At this point I have no problems with the project.
Code format and conventions review
This was an interesting task, as I had previously read and worked on the code I was trying to review. Going over this code again just focusing on code format gave me a different outlook on the code. Despite my best efforts, however, I was only able to find one problem. A bit more white space between methods would have made the code slightly easier to read. My table of convention violations is only
| File | Lines | Violation | Comments |
| ExamplePrinter.java, TablePrinter.java, ... | 12,10,... | EJS-7 | White space needed between methods |
Test case review
This was a particularly difficult area for me to critique, since it was my job to test the code. I tried to look at my own code with a critical eye and think of what was lacking in my own test cases.
Black box perspective
From a black box perspective, this was a difficult program to test. The requirements were just that the output be a series of tables containing the data from the XML files. There was no specification as to the format of the tables. Therefore, creating general test cases that considered the output of the entire system was nearly impossible.
Despite this, a test that parsed the output tables and compared them with expected values was missing.
White box perspective
This are was quite thoroughly tested. There were many tests for boundary conditions and illegal values. There were 8 separate tests for exceptions, as seen from the output of running JUNIT. Looking at the output from emma, there is only one section of code that was not tested, and that was the exception handing within of ExamplePrinter, the class that contained the main function. This section of code would only run if there was something wrong with any of the xml files used by main(). However, since the file names are hard coded, I see no way of testing this section of code. I could find no other missing tests from a white box perspective.
Break da buggah
It took me quite a long time to break this code, but I was able to find a problem. If the XML file is of an incorrect format, the program does not always behave correctly. For example, if an element is repeated twice with two different values, only the second will be displayed. For example, I edited collaborations.example.xml by adding an additional < Description> element, such as:
< Description>
A graduate student at the University of Hawaii spent the summer working in the University of Maryland research group.
</Description>
< Description>
This is a second description that does not belong here.
</Description>
This invalid XML format is not caught by the system and the output table contains
...--------------------------------------------------
...| Years | Description |
...--------------------------------------------------
...| 2005 | This is a second description that does |
...| 2006 | not belong here. |
...--------------------------------------------------
Summary and Lessons Learned
I got a fresh new perspective on my own project, and I think I did a fairly good job. I think Shaoxuan Zhang and I did a good job on the structure, design, implementation, and testing of the project. Perhaps the only thing I would change is to add some more complete black box tests.
I tried to critique my own code fairly, but I think it is impossible when you already know so much about it. It is much harder to critique and break your own code.
Monday, October 8, 2007
15.MyISERN-1.0
Group Ivory distribution available
HERE
Group Ivory Team: Shaoxuan Zhang, Ben Karsin
Lessons about JAXB:
The example given to us for this project was a great help. It provided many of the necessary functionality of JAXB. Without the example to show us the many complicated classes and methods of JAXB, this project would have been extremely difficult.
While adapting the sample code to meet our project, however, I learned quite a lot about JAXB.
XML
I was able to quickly understand the structure of the XML documents. I was expecting them to be much more complicated. Once we understood the structure of the documents and what needed to be done with them, we were able to work on the rather tedious task of creating the structure and implementation of this project.
Major Issues
One of the major issues we had was creating a nice table format. There was no specification in the assignment for a desired format, so I spent quite a bit of time trying to come up with an optimal solution. I turned out, however, that my partner was able to design a very nice looking table that is able to work well with different sizes and numbers of entries.
During this project both my teammate and I because quite frustrated with findbugs. Some of the errors given were unnecessary, annoying to overcome. For example, it tends to complain about
if (a != b) {
...
}
else {
...
}
This is really an insignificant problem but can become quite annoying. We also had some rather annoying little problems with javadocs giving errors if package.html is not of an exact format.
Overall, the majority of the issues we faced were not very large, but added up to be quite an annoyance. We eventually overcame them all and have a quite nice and stable project.
Teamwork
On the first day after the project was assigned, we decided to meet at the library. Upon meeting, however, we decided that it was an unnecessary waste of time to meet every day in person, so we decided to just use email, phone, and Skype to communicate regularly. The technology helped us communicate, but the project is fundamentally difficult to divide. We both began by reading the given documentation and tutorials, and began designing separately. Shaoxuan came up with a working program before me, so we decided to use his. He completed the design and implementation of the core of the project, while I was responsible for the testing, documentation, and other various small tasks needed to finish the project.
In the future, I think we should schedule specific IM or Skype meetings at a specific time each day, as the delay of email can be inefficient. I hope that future projects are more divisible and we are able to partition the work. We ended up getting the task done rather well, but I think if we were able to better divide the work, our time would have been used much more efficiently.
HERE
Group Ivory Team: Shaoxuan Zhang, Ben Karsin
Lessons about JAXB:
The example given to us for this project was a great help. It provided many of the necessary functionality of JAXB. Without the example to show us the many complicated classes and methods of JAXB, this project would have been extremely difficult.
While adapting the sample code to meet our project, however, I learned quite a lot about JAXB.
XML
I was able to quickly understand the structure of the XML documents. I was expecting them to be much more complicated. Once we understood the structure of the documents and what needed to be done with them, we were able to work on the rather tedious task of creating the structure and implementation of this project.
Major Issues
One of the major issues we had was creating a nice table format. There was no specification in the assignment for a desired format, so I spent quite a bit of time trying to come up with an optimal solution. I turned out, however, that my partner was able to design a very nice looking table that is able to work well with different sizes and numbers of entries.
During this project both my teammate and I because quite frustrated with findbugs. Some of the errors given were unnecessary, annoying to overcome. For example, it tends to complain about
if (a != b) {
...
}
else {
...
}
This is really an insignificant problem but can become quite annoying. We also had some rather annoying little problems with javadocs giving errors if package.html is not of an exact format.
Overall, the majority of the issues we faced were not very large, but added up to be quite an annoyance. We eventually overcame them all and have a quite nice and stable project.
Teamwork
On the first day after the project was assigned, we decided to meet at the library. Upon meeting, however, we decided that it was an unnecessary waste of time to meet every day in person, so we decided to just use email, phone, and Skype to communicate regularly. The technology helped us communicate, but the project is fundamentally difficult to divide. We both began by reading the given documentation and tutorials, and began designing separately. Shaoxuan came up with a working program before me, so we decided to use his. He completed the design and implementation of the core of the project, while I was responsible for the testing, documentation, and other various small tasks needed to finish the project.
In the future, I think we should schedule specific IM or Skype meetings at a specific time each day, as the delay of email can be inefficient. I hope that future projects are more divisible and we are able to partition the work. We ended up getting the task done rather well, but I think if we were able to better divide the work, our time would have been used much more efficiently.
14.CM.Practice
All three tasks were completed.
Installation:
Downloading and installing TortoiseSVN was very easy and only took a few minutes. It did, however, take me a little while to get used to the interface for this program. Once I played around with the interface, however, I found it very easy to retrieve, commit, and update SVN projets.
Once I installed TortoiseSVN, i downloaded the stack project, added a period to one of the javadoc sentences, and committed it. This was a rather fast and easy task.
Problems Encountered:
I ran into only a few problems during this small practice. Most of them were caused by the rather confusing interface at Google project hosting. Sometimes it was difficult to find certain options or menus on the website.
The biggest problem I had was setting up the automatic email notification for the -svn group. The text boxes to input the email addresses to send notification to were in an unexpected area. I had to keep slightly changing my project and re-committing it. I eventually figured it out and was able to get the notification on my Google group.
Lessons Learned:
I learned to use SVN. It is quite a useful tool and I am very glad that I now know how to use it and how to host projects. This assignment was a very easy introduction to some very useful and powerful software.
Installation:
Downloading and installing TortoiseSVN was very easy and only took a few minutes. It did, however, take me a little while to get used to the interface for this program. Once I played around with the interface, however, I found it very easy to retrieve, commit, and update SVN projets.
Once I installed TortoiseSVN, i downloaded the stack project, added a period to one of the javadoc sentences, and committed it. This was a rather fast and easy task.
Problems Encountered:
I ran into only a few problems during this small practice. Most of them were caused by the rather confusing interface at Google project hosting. Sometimes it was difficult to find certain options or menus on the website.
The biggest problem I had was setting up the automatic email notification for the -svn group. The text boxes to input the email addresses to send notification to were in an unexpected area. I had to keep slightly changing my project and re-committing it. I eventually figured it out and was able to get the notification on my Google group.
Lessons Learned:
I learned to use SVN. It is quite a useful tool and I am very glad that I now know how to use it and how to host projects. This assignment was a very easy introduction to some very useful and powerful software.
Monday, October 1, 2007
12.WebSpiderReview
Author of package under review: Edward Kim
Introduction
When I first began reviewing this code, I was quite surprised by the lack of support classes and methods. The entire program is contained within a single class and has only 3 methods. However, when looking closer, it is quite concise and seems to accomplish the tasks. There are not many tests, but they provide good coverage. I think this is a case where more testing is needed to produce a stable program.
Installation
It was quite simple to run download and run the package from Edward Kim. The zip file contained everything I needed to run all of the tools. I simply opened my command line and ran all of the necessary files.
I used ant to run all of the provided xml build files. The output data from the junit tests were quite extensive, but I was able to run all of the tools without any errors. For simplicity of testing, it would be nice to display a simple pass or fail for each of the junit tests. I was also able to create the jar file using dist.build.xml without any problems.
I then ran the command
java -jar webspider-{classmate}.jar -totallinks http://www.hackystat.org 100
The results were that 3211 links were found. It seemed to run this task correctly.
Code Format and Conventions
Upon opening the source file, I immediately noticed that the example file was used and the additional features were added. While it is nice to use this as a foundation, it is important to remember to change the header comments and add detailed comments about added features.
Test Case Review
There were few test cases provided for this application. The file TestWebSpider.java contained a few tests that ran the application with several different settings. Some of the tests took a long time to execute and produced excessive output because the program was run over a website with a link depth of 100. Cases could be tested much faster and cleaner with more, smaller tests.
Black Box Perspective
There was no testing of abnormal I/O combinations. Only one test was run that verified correct output. Test of each method should be done from this perspective to ensure proper execution for a wide range of input. For black box testing, the addition of tests done over a controlled set of web links would be very useful. I would add tests something similar to Randy Cox's test website, available at
http://www2.hawaii.edu/~randycox/11.WebSpider/test/main.htm
In addition, it would be helpful to test each method separately and compare the output. Tests should be done over the method mostPopular() with different lists of Strings being passed (including an empty list and a very long list). Likewise, tests could be done over the crawl() and getNumLinks() methods with different combinations of input. The resulting tests should have their results compared to the "expected" results.
White Box Perspective
Coverage was very well tested. Emma reported that coverage was well over 90%. While all the code was tested in some way, exceptions were not tested for, and abnormal cases were not considered. At the very least some tests where exceptions should be thrown are needed. Boundary conditions are also not tested, and in some cases unhandled exceptions will result. For example, if a null is given as input to one of the methods.
Some tests that should be added include testing passing null values to the methods. An example of this would be sending the mostPopular() method a null value instead of a list.
Break da buggah
To break this program, I simply began trying strange input. I first used the control website provided above to ensure it gave correct output. It passed these tests. I then tried simply providing not enough input. The command was
java -jar webspider-eykim.jar -totallinks
The result was
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 2
at edu.hawaii.webspider.WebSpiderExample.main(WebSpiderExample.java:112)
There are problems with catching erroneous I/O that could be easily fixed. Additional testing could have revealed these errors.
Lessons Learned
Doing this type of critical review, I see many errors that I made myself. For example, I had quite inadequate testing in my version of this same program. In breaking this program, I see that I should write much more extensive tests for my own future program. Black box testing, specifically, tends to be under emphasized. Catching cases where strange input can break your program is very important. You never know what the user will do with your program.
Reading this code also showed me how simply and concisely this program could be done. My version had several additional classes and many complex algorithms and data structures. This version, however, was done quite cleanly with only a few short methods. It shows me that I should spend more time on program design rather then jumping strait into coding.
Introduction
When I first began reviewing this code, I was quite surprised by the lack of support classes and methods. The entire program is contained within a single class and has only 3 methods. However, when looking closer, it is quite concise and seems to accomplish the tasks. There are not many tests, but they provide good coverage. I think this is a case where more testing is needed to produce a stable program.
Installation
It was quite simple to run download and run the package from Edward Kim. The zip file contained everything I needed to run all of the tools. I simply opened my command line and ran all of the necessary files.
I used ant to run all of the provided xml build files. The output data from the junit tests were quite extensive, but I was able to run all of the tools without any errors. For simplicity of testing, it would be nice to display a simple pass or fail for each of the junit tests. I was also able to create the jar file using dist.build.xml without any problems.
I then ran the command
java -jar webspider-{classmate}.jar -totallinks http://www.hackystat.org 100
The results were that 3211 links were found. It seemed to run this task correctly.
Code Format and Conventions
Upon opening the source file, I immediately noticed that the example file was used and the additional features were added. While it is nice to use this as a foundation, it is important to remember to change the header comments and add detailed comments about added features.
| File | Lines | Violation | Comments |
| WebSpiderExample.java | 24,26,83 | EJS-13 | All letters of URL are capitalized. |
| WebSpiderExample.java | 24,25,26 | EJS-39 | Global variables not documented. |
| WebSpiderExample.java | 36,138,213 | EJS-56 | No pre/most conditions. |
| WebSpiderExample.java | 63,66,163 | EJS-9 | Variables names wc and resp not clear. |
| WebSpiderExample.java, TestWebSpider.java | N/A | EJS-40,41 | No Summary of files/package |
Test Case Review
There were few test cases provided for this application. The file TestWebSpider.java contained a few tests that ran the application with several different settings. Some of the tests took a long time to execute and produced excessive output because the program was run over a website with a link depth of 100. Cases could be tested much faster and cleaner with more, smaller tests.
Black Box Perspective
There was no testing of abnormal I/O combinations. Only one test was run that verified correct output. Test of each method should be done from this perspective to ensure proper execution for a wide range of input. For black box testing, the addition of tests done over a controlled set of web links would be very useful. I would add tests something similar to Randy Cox's test website, available at
http://www2.hawaii.edu/~randycox/11.WebSpider/test/main.htm
In addition, it would be helpful to test each method separately and compare the output. Tests should be done over the method mostPopular() with different lists of Strings being passed (including an empty list and a very long list). Likewise, tests could be done over the crawl() and getNumLinks() methods with different combinations of input. The resulting tests should have their results compared to the "expected" results.
White Box Perspective
Coverage was very well tested. Emma reported that coverage was well over 90%. While all the code was tested in some way, exceptions were not tested for, and abnormal cases were not considered. At the very least some tests where exceptions should be thrown are needed. Boundary conditions are also not tested, and in some cases unhandled exceptions will result. For example, if a null is given as input to one of the methods.
Some tests that should be added include testing passing null values to the methods. An example of this would be sending the mostPopular() method a null value instead of a list.
Break da buggah
To break this program, I simply began trying strange input. I first used the control website provided above to ensure it gave correct output. It passed these tests. I then tried simply providing not enough input. The command was
java -jar webspider-eykim.jar -totallinks
The result was
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 2
at edu.hawaii.webspider.WebSpiderExample.main(WebSpiderExample.java:112)
There are problems with catching erroneous I/O that could be easily fixed. Additional testing could have revealed these errors.
Lessons Learned
Doing this type of critical review, I see many errors that I made myself. For example, I had quite inadequate testing in my version of this same program. In breaking this program, I see that I should write much more extensive tests for my own future program. Black box testing, specifically, tends to be under emphasized. Catching cases where strange input can break your program is very important. You never know what the user will do with your program.
Reading this code also showed me how simply and concisely this program could be done. My version had several additional classes and many complex algorithms and data structures. This version, however, was done quite cleanly with only a few short methods. It shows me that I should spend more time on program design rather then jumping strait into coding.
Monday, September 24, 2007
11.WebSpider
Download available Here
Summary
At first glance, this seemed like a rather simple program. Once I began working, however, that perception changed. Despite the setbacks, I accomplished all 3 tasks. I did not attempt the extra credit.
Task 1:
The importance of program design and planning was very important in this stage. The later tasks would rely heavily on how this task was implemented. As such, I spent quite a lot of time trying to come up with a good design. Despite my efforts, however, my design was not able to smoothly incorporate the required features for Tasks 2 and 3.
Task 2:
I completely redesigned my program from Task 1. I added a new class and a TreeMap to hold the required information about the most popular link. It became clear during these tasks that emma and coverage driven testing are quite uselss. Even with nearly 100% coverage, very few errors were found and much time was wasted trying to get the coverage to 100%. In the future I will focus more on writing "good" unit tests rather then very specific ones that get more coverage.
Task 3:
The logger system was very easy to use. I only had to add a few lines of code and it was working fine. The only problem I had was getting the javac compiler to recognize the Hackystat logger. I was only able to test it in eclipse. Please note that the .jar file contains a version with the logger commented out. To test the logger, please recompile the source.
Conclusions
Good tests can be very helpful, but bad ones can be a waste of time. The amount of time I wasted on emma would have been must better used writing more effective tests. Next time I plan on spending less time with emma and more time with just junit.
Summary
At first glance, this seemed like a rather simple program. Once I began working, however, that perception changed. Despite the setbacks, I accomplished all 3 tasks. I did not attempt the extra credit.
Task 1:
The importance of program design and planning was very important in this stage. The later tasks would rely heavily on how this task was implemented. As such, I spent quite a lot of time trying to come up with a good design. Despite my efforts, however, my design was not able to smoothly incorporate the required features for Tasks 2 and 3.
Task 2:
I completely redesigned my program from Task 1. I added a new class and a TreeMap to hold the required information about the most popular link. It became clear during these tasks that emma and coverage driven testing are quite uselss. Even with nearly 100% coverage, very few errors were found and much time was wasted trying to get the coverage to 100%. In the future I will focus more on writing "good" unit tests rather then very specific ones that get more coverage.
Task 3:
The logger system was very easy to use. I only had to add a few lines of code and it was working fine. The only problem I had was getting the javac compiler to recognize the Hackystat logger. I was only able to test it in eclipse. Please note that the .jar file contains a version with the logger commented out. To test the logger, please recompile the source.
Conclusions
Good tests can be very helpful, but bad ones can be a waste of time. The amount of time I wasted on emma would have been must better used writing more effective tests. Next time I plan on spending less time with emma and more time with just junit.
Monday, September 17, 2007
10.Stack
Download zip file Here
Task Overview
I was able to complete all five tasks successfully. I came across several problems during this assignment, all of which I was able to overcome.
The process of downloading and installing ant, all of the tools, and setting all the environment variables was rather simple. The instructions were straightforward and I was easily able to get my version of the Stack project could pass the "verify" script.
The most difficult part of this project, for me, was creating the javancss.build.xml file. I have quite a bit of HTML experience but I have never used XML. I had several problems with the path variables required by JavaNCSS. However, after going over the other build files provided and looking at the samples given on the JavaNCSS Website, I was able to accomplish this task.
The final task involved running emma and increasing the coverage to 100% by writing additional test cases. I really liked this tool. It provided very clear information and can make it much easier to write meaningful test cases.
Conclusions
Some of theses tools may be very useful in the development of software projects. However, I think they are all not necessary. The most useful, I feel, are CheckStyle, FindBugs, PMD, and emma. SCLC and JavaNCSS both provide similar information, yet JavaNCSS provides a little bit more (Cyclomatic Complexity Number, etc.). I do not see the information provided by these two tools as being very useful in most software development projects. All the other tools, however, were very helpful and I could see using them in the future. They may even help me break my "bad" habit of putting opening braces on their own lines.
Task Overview
I was able to complete all five tasks successfully. I came across several problems during this assignment, all of which I was able to overcome.
The process of downloading and installing ant, all of the tools, and setting all the environment variables was rather simple. The instructions were straightforward and I was easily able to get my version of the Stack project could pass the "verify" script.
The most difficult part of this project, for me, was creating the javancss.build.xml file. I have quite a bit of HTML experience but I have never used XML. I had several problems with the path variables required by JavaNCSS. However, after going over the other build files provided and looking at the samples given on the JavaNCSS Website, I was able to accomplish this task.
The final task involved running emma and increasing the coverage to 100% by writing additional test cases. I really liked this tool. It provided very clear information and can make it much easier to write meaningful test cases.
Conclusions
Some of theses tools may be very useful in the development of software projects. However, I think they are all not necessary. The most useful, I feel, are CheckStyle, FindBugs, PMD, and emma. SCLC and JavaNCSS both provide similar information, yet JavaNCSS provides a little bit more (Cyclomatic Complexity Number, etc.). I do not see the information provided by these two tools as being very useful in most software development projects. All the other tools, however, were very helpful and I could see using them in the future. They may even help me break my "bad" habit of putting opening braces on their own lines.
Tuesday, September 4, 2007
08.CodeRulerRedux
The newest version of my CodeRuler bot can be found
Here
After cleaning up my code to fit the Java conventions, I carefully read the review of my bot. There were several areas that the reviewer felt I could improve my bot. I considered every suggestion and tried to improve my strategy.
The first area I tried to improve was the knight AI. The reviewer mentioned that fleeing when faced with a stronger enemy may not be the best approach. I realized that, while dying needlessly should be avoided, knights should try to weaken the enemy forces until they are on the verge of death. I, therefore, added a condition that only allows knights to flee if they are under half health.
Another area that needed attention was the peasant AI. They covered ground very well, avoided enemy knights, claimed land quite efficiently. The problem was that they would get stuck after a certain point. I tried solving this problem in many different ways. First, I tried taking every square on the map into consideration while scoring, thus preventing equal scoring of all directions. This caused a timeout immediately. I then tried the same strategy, evaluating only every 5 squares. This prevented them from moving within 5 squares of the walls. I ended up staying with my previously strategy, as the peasants would eventually claim the entire board. I left this attempted strategy in the source code (commented out).
I added one final tweak that helps increase my score. Once I control 70 peasants, all castles should create knights. Since knights are worth more points then peasants in the final score, this can increase your score slightly when you have completely wiped out the enemy. It does not matter in a close game, but in a complete victory it will increase your score.
From this revision of my Code Ruler, I realized that many of my coding habits do not follow the convention. I will try to break all of my bad coding habits. Certain things (like giving an opening bracket its own line) I will may always prefer, but I can now try to follow a more universally accepted standard.
Here
After cleaning up my code to fit the Java conventions, I carefully read the review of my bot. There were several areas that the reviewer felt I could improve my bot. I considered every suggestion and tried to improve my strategy.
The first area I tried to improve was the knight AI. The reviewer mentioned that fleeing when faced with a stronger enemy may not be the best approach. I realized that, while dying needlessly should be avoided, knights should try to weaken the enemy forces until they are on the verge of death. I, therefore, added a condition that only allows knights to flee if they are under half health.
Another area that needed attention was the peasant AI. They covered ground very well, avoided enemy knights, claimed land quite efficiently. The problem was that they would get stuck after a certain point. I tried solving this problem in many different ways. First, I tried taking every square on the map into consideration while scoring, thus preventing equal scoring of all directions. This caused a timeout immediately. I then tried the same strategy, evaluating only every 5 squares. This prevented them from moving within 5 squares of the walls. I ended up staying with my previously strategy, as the peasants would eventually claim the entire board. I left this attempted strategy in the source code (commented out).
I added one final tweak that helps increase my score. Once I control 70 peasants, all castles should create knights. Since knights are worth more points then peasants in the final score, this can increase your score slightly when you have completely wiped out the enemy. It does not matter in a close game, but in a complete victory it will increase your score.
From this revision of my Code Ruler, I realized that many of my coding habits do not follow the convention. I will try to break all of my bad coding habits. Certain things (like giving an opening bracket its own line) I will may always prefer, but I can now try to follow a more universally accepted standard.
Friday, August 31, 2007
Review of CodeRuler lauramat-lisachen
The first thing I noticed when I opened up CodeRuler lauramat-lisachen was its simplicity and clarity. This was some of the easiest to understand code I had ever read. Within a couple of minutes I understood the entire strategy and implementation.
The code was constructed in a very clean way and it followed the conventions from "The Elements of Java Style" quite closely. Most of the convention violations were in the sections code that were taken from our sample CodeRuler. Overall the code was very neat and concise.
I was very surprised by the simplicity of the strategy used by lauramat-lisachen. The most complex aspect involved sending individual knights to do certain things and use the remaining knights in a pack. This was an interesting strategy that worked quite well for capturing castles. I may incorporate a similar strategy into my own CodeRuler and see how well it works.
Despite the simplicity of the code, the bot performs pretty well against the samples. I think, however, that adding a slightly more complex AI to the peasants will help. Random peasant movements do not claim an optimal amount of land and allow enemy knights to easily capture them. With this slight addition the bot will be quite formidable.
The few convention violations I managed to find are listed in the following table.
Overall I could not find many violations. I am sure the table of violations for my code will be much longer. This is a nice example of simple, clean code that easy to read. I am interested to see it with a nice peasant AI.
The code was constructed in a very clean way and it followed the conventions from "The Elements of Java Style" quite closely. Most of the convention violations were in the sections code that were taken from our sample CodeRuler. Overall the code was very neat and concise.
I was very surprised by the simplicity of the strategy used by lauramat-lisachen. The most complex aspect involved sending individual knights to do certain things and use the remaining knights in a pack. This was an interesting strategy that worked quite well for capturing castles. I may incorporate a similar strategy into my own CodeRuler and see how well it works.
Despite the simplicity of the code, the bot performs pretty well against the samples. I think, however, that adding a slightly more complex AI to the peasants will help. Random peasant movements do not claim an optimal amount of land and allow enemy knights to easily capture them. With this slight addition the bot will be quite formidable.
The few convention violations I managed to find are listed in the following table.
| File | Lines | Violation | Comments |
| MyRuler.java | 6, 121 | EJS-34&50 | Use of "This is" in comments |
| MyRuler.java | 14 | EJS-39 | Undocumented member variable |
| MyRuler.java | 14,129,130 | EJS-9 | r, np, and dir not meaningful names. |
| MyRuler.java | 45,125 | In Class | Line over 100 characters long |
| MyRuler.java | 118,146 | EJS-56 | No pre/post conditions |
| MyRuler.java | 42,118,146 | EJS-55 | No examples on usage in comments. |
Overall I could not find many violations. I am sure the table of violations for my code will be much longer. This is a nice example of simple, clean code that easy to read. I am interested to see it with a nice peasant AI.
Wednesday, August 29, 2007
Code Ruler Results
Our objective was to design and code a bot for Code Ruler. The strategy I decided to use involved a commonly used AI technique where scores are given for various conditions and moves are decided to achieve the highest score. Many specifics are used for scoring including proximity to enemies and allies. Although the 0.5 second per turn timer limited my look-ahead capabilities, the bot performs quite well. The details of my implementation are available in the javadoc generated from my code. The zip containing my source file and javadocs is available Here.
The scores for the test runs versus the sample bots are as follows:
Game 1: bkarsin VS Split Us
bkarsin wins 823 to 60
Game 2: bkarsin VS Gang Up
bkarsin wins 780 to 172
Game 3: bkarsin VS Migrate
bkarsin wins 831 to 0
Game 4: 4 team free for all!
bkarsin: 1112
Smart Split Up: 120
Capture Castle: 112
Gang Up: 56
The rest of my runs are available in the javadocs.
It is clear from these results that my bot performs rather well when faced with these very simple samples. Hopefully it will do well in the tournament as well.
What I Learned:
Since I have previously done some AI work and enjoy it, I got to practice some of those skills. I had never heard of CodeRuler prior to this class so I had to learn all the rules and strategies. I enjoyed the designing the program and strategy for this project. Any practice with games and code is always useful.
I became much more comfortable with Eclipse and Java just in this exercise. This was a good refresher for Java syntax. My first time using javadocs took a little while but I now see how to use it and how useful it can be. I think my code is much more readable and well structured because of this simple tool.
The scores for the test runs versus the sample bots are as follows:
Game 1: bkarsin VS Split Us
bkarsin wins 823 to 60
Game 2: bkarsin VS Gang Up
bkarsin wins 780 to 172
Game 3: bkarsin VS Migrate
bkarsin wins 831 to 0
Game 4: 4 team free for all!
bkarsin: 1112
Smart Split Up: 120
Capture Castle: 112
Gang Up: 56
The rest of my runs are available in the javadocs.
It is clear from these results that my bot performs rather well when faced with these very simple samples. Hopefully it will do well in the tournament as well.
What I Learned:
Since I have previously done some AI work and enjoy it, I got to practice some of those skills. I had never heard of CodeRuler prior to this class so I had to learn all the rules and strategies. I enjoyed the designing the program and strategy for this project. Any practice with games and code is always useful.
I became much more comfortable with Eclipse and Java just in this exercise. This was a good refresher for Java syntax. My first time using javadocs took a little while but I now see how to use it and how useful it can be. I think my code is much more readable and well structured because of this simple tool.
Sunday, August 26, 2007
Assignment 2: OSS Experience
For this assignment we were to find an open-source Java program, install it, use it, and rate it based on The Three Prime Directives.
The program I chose is a rather complex 3D modeling and rendering tool called Art of Illusion.
Sourceforge Download URL: http://sourceforge.net/projects/aoi.
Website: http://www.artofillusion.org.
Objectives of this program: Art of Illusion is an extensive 3D modeling and rendering program. It enables users to create and manipulate 3D models. Support for advanced users includes creating plugins and scripts.
Prime Directive 1:
This system does, indeed, accomplish a useful task. Users can create anything from the simplest 3D models to very detailed and beautiful 3D images and animations. Users can draw out their shapes with many tools, add textures, define materials, and even animate their models. I think the fact that the system is open-source and well maintained allows for constant feedback and input users.
Prime Directive 2:
Art of Illusion was very simple to install and run. There are versions available for Windows, Mac, and Linux. The only requirement to run the downloaded executable is that JRE (Java Runtime Environment) be installed. The Art of Illusion homepage contains detailed installation instructions. I was able to download and run Art of Illusion within 2 minutes.
There is a great deal of user-end documentation available both for download and on the website. I followed one of the many tutorials and was able to create a rather nice (yet simple) image in 30 minutes:
Prime Directive 3:
Being an open-source, community supported system, Art of Illusion provides a large amount of documentation for the advanced user and developer. This system provides support for user created plugins and scripts to be incorporated into the system. Detailed instructions on the use of the Art of Illusion plugin API are available on the website. By simply placing a jar file into the plugin directory, a developer can introduce many new features and capabilities.
Overall I think Art of Illusion is a very well written, maintained, and documented system. In the future I may continue to use it for 3D modeling and rendering.
The program I chose is a rather complex 3D modeling and rendering tool called Art of Illusion.
Sourceforge Download URL: http://sourceforge.net/projects/aoi.
Website: http://www.artofillusion.org.
Objectives of this program: Art of Illusion is an extensive 3D modeling and rendering program. It enables users to create and manipulate 3D models. Support for advanced users includes creating plugins and scripts.
Prime Directive 1:
This system does, indeed, accomplish a useful task. Users can create anything from the simplest 3D models to very detailed and beautiful 3D images and animations. Users can draw out their shapes with many tools, add textures, define materials, and even animate their models. I think the fact that the system is open-source and well maintained allows for constant feedback and input users.
Prime Directive 2:
Art of Illusion was very simple to install and run. There are versions available for Windows, Mac, and Linux. The only requirement to run the downloaded executable is that JRE (Java Runtime Environment) be installed. The Art of Illusion homepage contains detailed installation instructions. I was able to download and run Art of Illusion within 2 minutes.
There is a great deal of user-end documentation available both for download and on the website. I followed one of the many tutorials and was able to create a rather nice (yet simple) image in 30 minutes:
Prime Directive 3:
Being an open-source, community supported system, Art of Illusion provides a large amount of documentation for the advanced user and developer. This system provides support for user created plugins and scripts to be incorporated into the system. Detailed instructions on the use of the Art of Illusion plugin API are available on the website. By simply placing a jar file into the plugin directory, a developer can introduce many new features and capabilities.
Overall I think Art of Illusion is a very well written, maintained, and documented system. In the future I may continue to use it for 3D modeling and rendering.
Friday, August 24, 2007
Program 1: FizzBuzz
The objective of the first program of this course was quite simple. The program simply had to output every integer from 1 to 100, replacing multiples of 3 with "Fizz", multiples of 5 with "Buzz", and multiples of 3 and 5 with FizzBuzz.
Once I downloaded and opened eclipse (approx. 20min download and 2min unzip), it took very little time to get this program running correctly.
10:05pm - Started new project and began by opening one of my old Java programs to refresh myself on all of the basic syntax (it has been over a year since I've written any java.)
10:19pm - Finished program. It is running correctly and Eclipse was rather easy to use for a program this simple. Here is the very simple and short code:
public class FizzBuz {
public static void main(String [] args)
{
int i;
for(i=1; i<=100; i++)
{
if(i%3==0 && i%5==0)
{
System.out.println("FizzBuzz");
}
else if(i%5==0)
System.out.println("Buzz");
else if(i%3==0)
System.out.println("Fizz");
else
System.out.println(i);
}
}
}
The only Java coding I have previously done was with Notepad (sorry to admit). Even in this sort amount of time I can see many nice features in Eclipse. I particularly like the method listing when you type out a class (like Visual Studios). I will continue to play around with it to get used to some of the features of Eclipse.
Once I downloaded and opened eclipse (approx. 20min download and 2min unzip), it took very little time to get this program running correctly.
10:05pm - Started new project and began by opening one of my old Java programs to refresh myself on all of the basic syntax (it has been over a year since I've written any java.)
10:19pm - Finished program. It is running correctly and Eclipse was rather easy to use for a program this simple. Here is the very simple and short code:
public class FizzBuz {
public static void main(String [] args)
{
int i;
for(i=1; i<=100; i++)
{
if(i%3==0 && i%5==0)
{
System.out.println("FizzBuzz");
}
else if(i%5==0)
System.out.println("Buzz");
else if(i%3==0)
System.out.println("Fizz");
else
System.out.println(i);
}
}
}
The only Java coding I have previously done was with Notepad (sorry to admit). Even in this sort amount of time I can see many nice features in Eclipse. I particularly like the method listing when you type out a class (like Visual Studios). I will continue to play around with it to get used to some of the features of Eclipse.
Subscribe to:
Posts (Atom)