Red Bull a programmers drink

DueDates 2.0 is the continuation to our open source program; from a small command prompt program to a now fully integrated, user friendly, web graphical interface.

In this version of the DueDates program, our original groups were broken up and placed into new groups, but instead of a two person group we were either placed into a group of 3-4 people. With a much larger group the tasks would be evenly distributed to each member, supplying each member with less of a work load. The group I was included in is Team Ahinahina, which consisted of John Ly, Philip Lau, and Scheller Sanchez. Each of us took up task to meet the requirements for this new version of DueDates.

Processing the Task

We, team ahinahina, met a couple of times during the first week to discuss which group members would do what for the program. At first we took the program lightly, thinking that since the group is much large that tasks would be done sooner and the progress to completion would be reached before schedule. During the first week, we tried to get as much done before the Thanksgiving break. After the break we, on the second week, realized we haven’t got much done and the dead line was drawing closer. So I tried to organize as much time for all of us to meet at Sin Claire Library, even if it meant late at night.

During the second week, everyday that went by a requirement was getting done. Also with all of us there we paired program or, asked and offered a fellow group member for help on a task. This method of pair programming helped a lot, with all of us operating like each wheels on a car; when one wheel was stuck, the whole car was stuck.

So close, but yet so far

We reach completion of the program, or so we thought. After reviewing the requirements we received from our professor, which to me acted as our client, we saw that we missed two of the requirements. One was the requirement for a user to be able to sort the list of books by title, which is very similar to sorting the list by the library location. The second requirement was alerting the user of a due book depending on the amount of days inputted.

During testing another dilemma occurred. This third problem was the “within” option, which gives the ability for a user to filter out books depending on the amount of days it was due. The function was implemented to the program, but being new to Java Wicket, we would need more time to fully integrate it dynamically to the program.

Problems on the test

On the process of building the program, we didn’t think about testing so much. With the deadline hangover our heads, the idea of having testing coverage wasn’t our biggest concern and mostly focusing on getting the program up and running was. When we did get to it, we had some problems; for instance when I uploaded a proper test class to the project page, the Hudson serve would show that it failed. Though, the test class would pass on each member’s computers. This problem occurred due to the fact we were not sure of the test accounts that we used, if they were also on the Hudson server.

Conversion to 2.O Wicket Style

The conversion of switching to wicket was fairly moderate on my part. The 1.2 version of DueDates was supplied by John, a previous member of team yellow. The program was pretty straight forward; I just had to do some work around of the original program to compensate for the integration of Wicket into the program. Using wicket was a really cool experience, on how it bridges java over to web programming. I would love to further learn more of its capabilities, such as the Ajax mixing of it and how it would handle flash web programming.

An Eye Opener

This experience was a real eye opener for me on the last week of the project. After looking at code for almost 20 plus hours on a Saturday, being juiced up on red bull, and having a total amount of 47.9 hours, according to the HackyStat sensor; like what John said in his blog, “I’m over due for some sleep”. Being reassigned to a new group this late in the semester was fairly hard on my part, having to get use to a new people's work habits and time management. Also in how fast i can understand a new program structure; good thing John was available to answer my questions, him being one of the original programmers to the version of DueDates we used. I hope the others gained more knowledge from this than I did though, I know our professor has his reasons for doing this random grouping assignment. One reason that caught my eye was, preparing us for the real software industry. Comparing my experience from working for Star Degree, I would have to at times randomly work with new people or have to work on programming code that was written by someone else. So these two experiences are alike in many ways. Generally this has been a good, full of red bull, experience.

Screen Shots

The display page

The alerts page....the page i spent most of my time on

Red Bull gives you wings....my stats are flyin'

Links

DueDates-Ahinahina Project Page
User Guide
Developer Guide

Downloads
DueDates.jar
DueDates distribution
DueDates 2.0 API Java docs

Learning How To Wicket Good

This week we are preparing to launch the DueDates program on a worldwide basis over the internet. For that to happen, all the programmers in the class will learn how to use Wicket, which combines java programming with an html web interface. We will discover how to integrate wicket with our professor’s stack program.


Problems everyone has them
Implementing wicket was a big deal for me, never doing any actual web programming in my past experiences. Programming the wicket part of the stack would have been very difficult if we never have been supplied with any examples from our professor. The examples helped a lot in setting up stack with wicket, like on what to create and what steps to take. Everything was going smoothly for me; all the parts on the java side were working fine, until I had to implement a web table that can store the elements of the stack.


This was a problem I had, creating a somewhat dynamic table for the stack elements. I went over and over on the contents from the Wicket in Action book; I found something’s that could have worked, but didn’t really make sense to me. So I looked over the internet for tips, and didn’t find anything. So I just settled for the bare minimum and displayed the stack on a single row of the table.


Also another problem I had was for errors, such as trying to remove an element from the stack when it is already empty. I couldn’t really approach this problem, since I committed most of my time trying to solve the table of elements problem. I had an idea of creating a label and having it display when ever the error occurred, but there just wasn’t enough time to implement that idea into the program.


The Experience
I was not able to finish the full requirements set by our professor. There is no one or thing to blame really; I just had poor time management during this assignment. Although I got a lot of the assignment, wicket is a very good tool for implementing a web interface for java programs. It was easy to pick up and see all the patterns of how it works, such as establishing ids for things that will appear in the html file from the java file. I learned also another on going lesson from this, “Have Better Time Management”.


My Stack Wicket DownLoad

Power and Responsiblity

This week we continue to upgrade our, team-silver, DueDates project. For version 1.2, we will be adding the new feature of sending the results to either an email or straight to the console and to check the user’s account for live updates from the library’s website. We split the task evenly, Ronn being responsible for the email feature and I was responsible for the update check feature. Even though it was a simple upgrade we met on a regular basis, just like on our previous improvements of the program.

You've got Mail
The new email feature is possible by integrating an open source java program called JavaMail. This new open source program, JavaMail, requires the user to supply not only an email address but also the email’s SMTP server. For email’s that require an authentication for the SMTP server, JavaMail has the option of authenticating, but that was the hard part. Most email providers require that the program authenticate the server being used, which made this problematic for finding an email we can use to test. Luckily my work place, University of Hawaii Star Degree, uses Microsoft Exchange as the email provider, which made it possible to use my email from there as a test dummy.

Updates Anyone?
The one part of the project I was responsible for was having the project check for updates of the user’s library account. This was possible by using java’s TimerTask and Timer, which are already included in the Java package you needed to download for the use of the program. Checking for updates requires the user to provide an amount of time of when to check the site, the time was calculated in milliseconds in a day. It was necessary for me to break out some of my old math skills, which I haven’t used in a long time, to calculate the right amount of intervals to enter and provide a formula for our users on how to calculate their own intervals of time.

Damn FindBugs
We had some problems in this version of DueDates, the small problem was finding an email address for testing the email feature and the big problem was integrating the update check feature with our program. Well the email problem was easily solved, which I mentioned earlier; but the update check, on how we integrated this feature with our program, was getting an error when doing a FindBugs check. FindBugs, a quality assurance tool, didn’t like how we were passing the original user’s input to the TimerTask. After a day of attempting to restructure the project for this new integration; what I thought was so confusing and causing me to run around in circles, was simply solved by just cloning the user’s inputs. Who would have thought that the solution was something so simple? Once these dilemmas were resolved, we are finally ready for the release of version 1.2.

Be Responsible
This new version of the program can either be very useful or a good way to pull an office prank. It is useful because, you can check for updates and at the same time receive emails of those updates. Also it can be a good tool for pulling pranks by spamming a co-worker or co-workers in an office, spamming them with meaningless things and having it being from anyone you want it to be. I thought about playing with this tool to pull an office prank, but declined. It just made me realize how much power we, software engineers, have with all our modern technology. “With great power there must also come great responsibility” – Stan Lee.

DueDates v1.2
User Guide

Take 2 of these and call me in the morning

Checking into the ICU
This week we checked our project, DueDates, into the Intensive Care Unit (ICU). This ICU is similar to what a hospital’s ICU is just like, just with no beeping sounds all over the room. It checks the vitals signs, but instead of heart rate or blood pressure, it checks on complexity, coverage testing, coupling, churn, code issues, size, development time, commits, builds, and test. The ICU for program projects checks the trends on those vital signs and displays it on a graph, showing if there is an increase or decrease in vitals.

To have the ICU project monitor you’ll have to install it into your own computer and also become a member of the online monitor. The actual monitor on both your own computer and the online monitor are called HackyStat. The installation on your computer, is a plug-in for the Eclipse IDE.

Dilemmas checking in
When I installed the monitor onto my own computer, the installation went smoothly. The main problem I had was altering a system environment variable, which is needed to connect your local computer to the online monitor. After an aggravating night of trying to fix what was wrong with setting the environment variable, I sought the help of my professor on the next day. After just a simple glimpse of my environment setup, he spotted the problem. The problem was just a simple misspelling, instead of spelling it as “ARGS” I spelt it as “AGRS”; big difference right? Getting past that small dilemma, I was able to complete the whole installation. Then i was able to see the vitals of the patient.


Current Patient Vitals

The Diagnoses
This program vital monitor, HackyStat, is really awesome, makes me feel like a doctor. Well not just like any doctor, more like Frankenstein; mostly because we actually created the patient, the program. Following the HackyStat installation, I see that the patient’s vitals are stable but cane be improved. To improve the stats we need to give further testing, instead of lots of exercise and a balanced diet for a regular human. Before we do the testing though, team-silver has to take the patient to the operating room.

Need an Upgrade?

Upgrading a program can always be fun or troublesome, depending on how you look at it and the amount of work involved. The silver team, Ronn and I, were given the chance to add some new features and do other improvements to our DueDates program. Also we were able to make some corrections that we over looked in version 1.0, with help from the results that we received from our peers before and during the 1.1 upgrade.

New Features
The new specifications of the 1.1 version of DueDates was to add in the “sort” feature, which enables the user to sort the rented books by either its due date or by the location where it was rented from. Also another feature was the “within” function; which was to calculate, when given a number, the books that are due within that range of days. These new additions were not so hard to implement into the program. When designing the initial version, we always kept in mind that we wanted to make it easy to further upgrade the program somewhere in the near future.
The Process
Before adding the new specification to our program, we wanted to make some changes to the system’s structure. In the first version, we both wanted to use a XML repository to store the libraries; which would serve something like a table of libraries, with each library as a row in the table. So we took this opportunity to integrate the XML repository to this new version. We both sought out and looked online for guides on how to do this process, I for one was excited to see how this could be done. After searching for a day, we found some very good articles and instructions on how to add XML into our program. Also during the search we found an open source program, Argparser by John E. Lloyd, which would make the inclusion of the new specifications easier to add into the program.

Adding in the two new features, the XML repository and the Argparser, took some time. When we included the Argparser at first we incorporated the source files; but that cause so much errors, some were easy to fix and some were mind bending. After hours of error solving we just simply decided to just add the Argparser jar file into system’s library, making it still apart of the program just not with the all the errors. In the addition of the XML repository, this was very interesting on how it stores the libraries. With this, both users and developers of the program are able add in a library of their choice.

With the new features added on, we were able to now add in the new specifications. Integrating the “sort” function was simply done, due to how our system was created, we just had to make minor changes to file that involved such a function. Also with the “within” function of the program, it went the same way; because both functions were related to the same files that need to be changed. Adding these functions as options for the users of the program was easily included, due to the Argparser we recently added.

Troublesome
With all upgrades, minor or major, there will always be problems. The dilemmas we encountered in upgrading, was adding in the Argparser. When we initially added the source files, we got so many errors. Like mentioned earlier, some were easy and some were hard; but it seemed that when we fixed one error 5 more would appear. We then resolved that issue by not including the source files, but using the program’s jar file. Another problem we had was the QA (Quality Assurance) tool, PMD. The errors we received from this the tool was such a bother. It caused us to go back into our implementation and revise some changes we did to this new version of DueDates. I know it has its reasons for giving us those errors, but PMD (Pretty Much Depressing) can be troublesome.

Keep Moving Forward
This advancement in our program went by smoothly, giving the amount of time we had and the amount of work we had to do. We met as much as we could in the process of upgrading the program, meeting every other day; but once we finished a large chunk of the work we met via Skype. We also divided the amount of work evenly and also helped each other when ever one of use hit a brick wall. With great team work, we were able to conqueror the battle of upgrading.


I didn’t make as much commits to the Google Project page, fearing of the Hudson checks would give us rainy days. Hudson was like an extra professor checking our work. Overall this was another good experience for our futures, working in a team as a team. Also using new programs and integrating other program languages to our system was educational. As I mentioned before we originally thought of further upgrades to the program, which is the reason for its structure. So all we can do now is to “Keep Moving Forward” –Meet the Robinsons, hopefully advancing with a Graphics User Interface.


Links:
Argparser by John E. Lloyd

The reView

We, Ronn and I, had the honor of receiving a review from both Tyler and Scheller, team gold. They both looked over all the specified aspects of our project. Both had very encouraging, interesting, and insightful inputs about how our project turned out.

Receiving New Aspects
We received many praises from both reviewers, which was very encouraging. Both liked how organized our project was, splitting the program into packages. Tyler mentioned how he liked the use of integrating XML, another programming language, into our project. Also he liked how our Google Project page had a professional sense to it. Scheller gave us a good idea on users that rent out more than just books, such as video rentals from the library. This idea will be developed in future versions of the project.

They both also spotted things we over looked in the progress of the project. Scheller pointed out on our program not working with versions lower than Java 1.6, a computer run time environment need to run certain program. Tyler saw that we did not include Quality Assurance tools in our developers guide. He also cited that a user should not need to set an system environment variable on their system in order to use the program, and he had a nice quick solution to the problem which was to include all required libraries the program uses in the IDE’s (Integrated Development Environment) project class path.

The Offering
Ronn and I also had privilege to review another group project; which is the group of John Ly and John Zhou, team yellow. I saw that team yellow is still in development stages of some new features of the program, features such as sorting books by either due date or library. Also that they could reduce the size of they’re program, due to redundant logical use of code. We, both my partner and I, gave some tips on how to reduce the size of the program, as well as a structural improvement for future development. They’re program worked to the bare minimum without any errors, which to me is still good.

The Google View
Using Google’s Project Hosting is getting easier the more I use it. The further use of Google’s Wiki syntax for creating issues; I’m beginning to get the hang of things. Also thanks to other classmates, I learned of new short cuts when things don’t appear like how I want them to. For instance when making a numbered list, when published for public view it appears that each item on the list is number 1 and not in decreasing order. Also our professor showed us a tip on being more organized on having people review our code; instead of searching through our code for comments, we can just refer back to an issue dealing with what the comment is about on our code which displays the comment easily.

Summing It Up
After looking over both reviews, I see that we still have more improvements to do to the program. Having an outsider’s aspect on our program was very helpful; having them point out things we did not see or thought about. I also hope on concluding my review of team yellow, that they take our comments open minded. Criticism, reviews, or call it what you want; in creating a product there is always room for more improvements, no matter how perfect it may appear.

Keeping an Open Mind

Just when we thought it was over, we had to look over more code. There wasn’t much time to rest, after a long and learning experience of creating an open source program. Our professor didn’t want us to take our eye off the ball, so he wanted for us to look over other group’s projects.

Giving

After examining other project code files, I see that everyone has some similar and different ideas in approaching the same problems. Some of the ideas I saw will possibly help in improving my group’s program, and I’m pretty sure other groups that reviewed our project will get some ideas too. It’s like Christmas, a time to give and take, as well as to share. Another thing I got from evaluating other projects was when suggesting on handling a problem, it was like a suggestion to me as well.

Recieving and The Google Experience

Using Google’s reviewing tool was a good learning experience. At first it seemed simple to use, just double clicking on lines I saw interesting enough to comment on. Although when I was finished with all my comments on a single file and clicked on save for each of the comments; a “publish your comments” link should have appeared at the right hand side of the screen, but it was nowhere to be found. So I thought I had lost all my input, then I clicked to go back to the previous page and then clicked to go back into the same file and all of a sudden the “publish your comments” link was there. Once I clicked on the link I was able to see all the comments I made for that file, the sad thing was that I had to repeat this process for every file I reviewed.

When it was time to see what others commented for my group project, it was actually frustrating for me to view the comments. I would go to a file that was commented on, for some reason no comments would appear anywhere. I explore and looked over and over everything that made any sense to enable me to see the comments from others, but couldn’t find anything. So I remembered Philip, a classmate that reviewed the project code, sent an email to me with a link to what he commented on. I followed the link and “BADA BING” the comments appeared, both his and others.

Not Narrow Minded

The comments we received was not much, but very valuable. Some of the comments pointed out issues we over looked, others were praises for good ideas on how to handle problems other people encountered. This experience was not at all degrading; we took every idea for improvement with an open mind. In our next opportunity of looking over other projects, I would be better prepared on using Google Project Hosting in the code commenting area. Also to give more detailed comments and offer more ideas, hoping they will be open minded as well.

When is the DueDate???

Intro

This is an open source group project which will develop a program named DueDates. Its purpose is to log onto a library website without the use of a web browser. You will then need to provide a login and password for the library website. Once logged into the site, the program will display a list of books that you have checked out and their due dates.

Download DueDates.jar

Process

The process of creating this program was not too tricky. With our professor giving us a description of what I possibly should do, we knew what we wanted it to achieve. We wanted the basics of the program to be able to connect to a library website, log on to your account, and display a list of books you barrowed from the site. With that in mind, we also thought of making the program able to other libraries around the world, so that anyone in the world can use it.
We split the program up into different class files, that way we can be more organized, and just combining them into one package. Another reason for making different classes was if someone else where to make improvements to the program, they would know which file to enhance. The different classes that make up our program are: User, Library, UserLibraryInfo, and DueDates, which is the front end of the program. There are other minor classes which these four classes are derived from and they are: IUser, ILibrary, and IUserLibraryInfo. with everything separated and organized, future enhancements will not be a hard possibility.


Problems that Occurred and Solutions

We ran into some problems during the initial building of the program, the first of our problems was with importing external tools into our project. The problem with importing external tools was solved by communicating with other people in our class. A previous lab partner of mine, John, suggested to me that our project was not bringing in the Httpunit tool and instructed on how to import it into the project. Once that problem was fixed we proceed to develop our copy of DueDates. Just when we thought we were home free, suddenly our testing of the program was not working. After hours of gruesome tracing and looking at lines of code. I abruptly tried to import our files into a previous DueDates project our professor gave us, and it worked. The test completed and we were able to continue with the development.

Just when we thought it was smooth sailing from there on, our EMMA tool was not completing its coverage of our program. We decided that this problem can wait and proceed to fixing other minor problems. Later it was time to try to fix the EMMA problem; after a few hours of thinking of what it could be, Ron notified me that we need to make a test class in order for EMMA to complete its coverage and display its results. Creating that test class and running at least one test fixed the EMMA problem. Our other problems occurred during the running of the quality assurance tools, such as Check Style and PMD, but those errors were quickly resolved. The problems we faced, at the time seemed so big, but the answer to them was so small.

Working on this project we took a bigger step in to the world of Google Project Hosting. Learning how to use the different syntax of the wiki page was very troublesome. The user guide did not help so much and possible correction to the syntax I made, I had to commit the file to the project page to see the results; which cause a large number of commits. Another problem I had with the project page was when I accidentally made a commit and did not put anything on the log. There should be an option to go to the page and edit the log entry, depending if you were the one that made the commit.

The Future

A possible improvement for future development would be to create a user-interface. During our outsource testing; some of the users did not know how to get to a command prompt screen, which prevented them from using actually using the program. Also with a developed user-interface, we plan to also hold more than just the two libraries that are stored in the program, keeping mind that this program would be used for people from around the world. With the way we designed our program, I think future developments won’t be too complicated.


Thoughts

Creating an open source program is a tough and time consuming process, even though our professor provided us with the direction and foundation of the project. Despite the rough road to completion, I learned a lot from this experience. First of all, this being a group project, having a very dedicated and intelligent partner was really helpful. We met almost every day since the project was first assigned all the way to its completion. It was a good experience programming with someone on this open source project. When one of use was stuck in a problem, the other would find a way to solve the problem. Solving big or small problems with someone watching my back, has increased my liking for peer programming.


Also another thing that I valuably learned was how to handle problems, not taking so much time to look for a way to fix it. Take other routes to completion, moving around that problem and get back to it later, presuming that the problem won’t affect the rest of the development. Also not to burn yourself out on looking for a solution, take it as a sign to step away from the computer and relax your mind. Remember a big problem can always be solved by doing something so small.

Exploring the TortoiseSVN's shell with a friend

Goal
I will be continuing to explore the use of Google Project Hosting, but this time I will be member of another person’s Google Project page and he will be made a member of mine.

Making a Friend
Initially we, me and my partner Vincent Leung, added each other as members to our respective Google Hosting pages. Once we were members of each other’s page, we will be able to download, make changes, and upload files back onto the page. During our lecture class time, we spent most of it setting up our pages and learning on how to thoroughly use TortoiseSVN. Class was over, so we just exchanged emails in a way to contact each other.

When Vincent was able to upload his project files to his page, I proceeded to download it. I could have easy downloaded each individual code, but I that would take longer. So I made a folder in my local hard drive, to store Vincent’s project files, and then used the ‘checkout’ option on TortoiseSVN. Using that option, I was able to direct download his entire project all at once.

After setting up his project in Eclipse, using the Ant command line shell I tried verifying his project. I got and error and a failure in the JUnit check. When I got all the errors and failures that occurred during the Ant verification corrected, everything went smoothly. Committing, or uploading, the files that were modified back onto his project page, was easily done through TortoiseSVN.

Conclusion of Exploration
This encounter of using an SVN program with a Project Hosting page further shows me the simplicity of group programming. To me the most useful part of these tools was logging or describing the what is different in the version you committed using the log of TortoiseSVN and utilizing the "Changes" tab in the Google Project page, which shows the exact line that was changed and compares the current version to a previous version of the project. The only crack in the shell, problem, I can see is if the programmer that commits the version you are currently working on doesn’t give any good description of why or what changes they made, which can cause you to rollback to later versions or retrace steps.

My pet Tortoise named SVN

The Goal

Become familiar with SVN, a subversion control system, and familiar with using Google Project Hosting, with its tasks and procedures.


Download the Program


First I had to download an SVN program software, our professor recommended TortoiseSVN for windows users. TortoiseSVN is an automated revision control, version control, and source control manager.

TortoiseSVN version 1.5.3

The Process

Creating a Google project site was rather moderately simple. I first started by going to the Google code page; then proceeding to the Project Hosting page, from there I started a new project. After reviewed the notes from Prof. Johnson, I started to fill in the text boxes with the required information from his example.

Once the project page was created, I continued to setup TortoiseSVN on my local computer to upload files to the project page. At this point I would have had a rather difficult time getting things to work, but luckily my professor had some very good instructions on the setup. When using the “checkout” option with TortoiseSVN on the folder that contains the files to be uploaded, you must make certain that the link is an https web URL for the project repository. This is because, if you use a normal http web URL you can only view and make local changes, but not commit the changed file to the project repository. From there I was able to commit my copy of the stack program.

Another thing I created was a new Google group; this group will serve as a place for discussion that relates to my project page. Each discussion topic is made each time a version of the project is created from the project page.

Testing how TortoiseSVN with Google Project Hosting worked, I made some javadoc changes to one of the files that were committed to my project page earlier. After the changes were made, I committed the file with a brief description of what I did. It then created a new version of the project in the project page, and also took into account of what specific file was changed and what was different from the previous version of the project.

Thoughts

Using TortoiseSVN combined with Google Project Hosting is a really good experience for me; I see that it’s useful for creating open source projects or just simple group class projects, using these combined project tools will make processing and control easy. It was also awesome seeing the Project Hosting page and the Group Discuss page were both linked to each other, after making the right settings. The most astonishing thing for me was seeing how all this works, the process of multiple programmers and logs taken with each version. The funny thing is that there was nothing lame or boring about this tortoise, but I do wonder how hard it’ shell is.

Two heads are better than One: Peer programming

Working on a project with another programmer sitting right beside me was not a new experience. I originally started programming at a computer lab, where there was a large amount of people using a computer and every computer was placed next to each other in rows. So as I would program, my classmate would program on the computer next to mine. We were assigned to work individually, but when either one of us were stuck on a problem we would turn to each other for advice. This was my first encounter of peer programming.

Programming with another person, to me, is one of the most effective tools in programming. I had the honor to work with a classmate of mine, John Ancheta, in our ICS 413 class. Our task for the first half was to have the Emma quality assurance tool have 100% coverage on a pre-implemented Stack program. We both took turns implementing on my laptop, and it was good having another set of eyes watching what I did. After completing the first half of our in class work, we then planned on how to create bug, but yet maintaining the coverage of a 100%.

John had the idea of rewriting what a method returned when tested. We both carefully thought it through and saw that it worked as we hoped for. We wanted to see if we expected the toString method located in the Stack class would return the list of elements, when rewritten to “this.element.size()” instead of “this.element”. (Note disregard the quotation marks.) As predicted, the coverage of the program was 100%, but failed in our JUnit test of the new “toString” method.

After noticing how Emma can get a result of full coverage and JUnit can have errors. I see that this as a disadvantage, even though one had good results and the other bad results. From this experience though, the advantage was having another head to help think and share their knowledge; also to write proper test cases and what to expect.


Stack implementation

Reflections on Coverage and Testing

I will explore more into using testing tools; Emma 2.0.5312 and JUnit 4.5, both are quality assurance tools as well. The main tool I will be using is Emma, to see how well each classes, methods, blocks, and lines of code is covered and tested in a Stack program. Then from the results of Emma, I will then use JUnit to test any of errors I received from the Emma tool.

Initially I ran the same Stack implementation through other quality assurance tools; checkstyle, pmd, junit, and findbugs. From those tools I have repaired any errors I received. Now using the Emma tool, I see from the console screen that not all the methods, lines, and blocks were covered to a 100%. So I further went to the coverage.html file to see precisely what was not covered. A few methods from the original build were not tested, which caused the coverage to be about 78%. After writing some proper Junit test cases on untested methods, I got the coverage to 100%.

Using JUnit and Emma is a new experience for me; I’ve been use to writing generic print out statements as my test cases in the past. Seeing the results from Emma, I observe how easy it is to find out what methods were not tested and covered. I also noticed that, it is helpful running tests with JUnit. It was very helpful for me in examining the use of these two tools; for future use in projects, especially large scale projects.

Here is my copy of the Stack implementation with proper test cases.

Ant Lab

For this assignment we were to use some automated Quality Assurance (Q.A.) tools on a previous group assignment, CodeRuler. Some of the Q.A. tools the class is using are checkstyle, pmd, and findbugs. After processing the CodeRuler code using the Q.A. tools and seeing the results, we were given the task of comparing those results with the results we got from our peers in another previous assignment.

Checkstyle showed most of the same results our classmates caught. A lot of the errors both caught were formatting errors, the use of 4 character indentations and exceeding 100 characters. One error that checkstyle found that our classmates did not find was some white spaces not preceding a squiggly bracket. The pmd results illustrated 2 types of errors that our peers did not find. The errors were to avoid using implementation types, ArrayList, but to use the interface instead, also to avoid using Avoid if (x != y) ..; else. The last Q.A. program was findbugs, which it did not find any errors at all.

Comparing all the results of the Q.A. programs to our peers, I see that there are some formatting errors that a human can miss that an automated program can find. Some of the recommended solutions that were suggested by pmd were good, but would increase the length of lines of the MyRuler code. Also the Q.A. programs could not discover some logical improvements, a peer saw that two methods were structurally the same and could have been combined to reduce methods. Another error our peer found was the use of single character variable representation. The use of Q.A. programs and manual reviewing both have their advantages and disadvantages, but I see that Q.A.s can pick up errors that a manual check might miss and that manual checks find logical and structural errors that Q.A.s won’t come across.

Stack

This assignment is intended to introduce us to the use of automated Quality Assurance (Q.A.) coding analysis tools. Some of the tools we will be using are pmd, checkstyle, findbugs, and junit. These will help show us potential development problems and solutions when implementing a program. All the Q.A. tools will be used by another tool called Ant, to initialize the checks. Ant is a java based open source tool that helps programmers build and create packages for distribution of the program. We were given the objective to use these tools on a prewritten program, Stack, by our professor.

Task 1

The first task was to install these tools into my computer and setting system environments to make them accessible for other programs to use. Then to use Ant command lines initialize the Q.A. tools on the Stack program.

Downloading the Q.A. tools and installing them into a subfolder in the C drive was no problem. A dilemma I had was setting the environment variables. When browsing through a few of the manuals I got rather confused, setting the variables in the XML files or setting them in the computers system environment variables. This setback was clarified by Clayton, a classmate, during our class’s Ant Lab. He showed me what I did wrong and a temporary solution to a problem with running the Ant command lines in my computer’s command prompt. Later Ronn, another classmate of mine, saw and explained that I set the environment variables to only being of local use to my account alone and not making them used by the whole computer itself. Once that problem was solved I was able to use the command lines and see all the problems that the Q.A. tools found in the Stack program.

Task 2 and 3

For this task we have to duplicate the Stack program, but with some changes to the build.xml file and to rename the top level folder. Also for this task we had run Ant with the Q.A. tools to find the problems within the code and this time to solve those problems. Running the command lines to initiate the checks for errors was easy, since it was done in the previous task. Some of the solutions to the errors were given by the Q.A. tools, such as making a variable final and using method within a class. The other solutions were not as clear as others, such as use of the fail tag, this was because I was not familiar in using that tag. For errors such as those, I searched through Google on solutions, which were very helpful.

Once all those errors were fixed I ran the verify command line, which stopped once it came to checking for errors using EMMA and prevented the program from being built. I saw that I have not installed the Q.A. tool EMMA, but once I did the verify command ran smoothly with no fails. I could have avoided this error by editing the verify.build.xml file by erasing the importing EMMA and altering the task of compiling with EMMA. The dist.build.xml was the last file to run with Ant, which packaged the entire project into a zip file and named it according to how it was designated in the build file.

Impression of Ant

Using Ant was not new to me, in a previous class we had the chance of using something similar, Make. The difference I saw between the two was that Ant, along with the Q.A. tools, picked up on errors and gave possible solutions. Ant is a very useful tool and can see that why it is best used for big projects and also using it for open source programs.


My distribution results of Stack

CodeRuler Review

West and Shum’s Code Ruler game strategy is very good. I like how they split their offense into two groups, one attacking enemy knights and the other to capture the enemy’s castle. Also taking into account if the group that is assigned to attack the knights first is dead, the other team will set its next priority to enemy knights after it was taking enemy castles. The approach they used for the peasants is very well thought out, having them occupy available land then looking to the occupy land that belongs to the enemy. They’re overall plan for the assignment was superbly designed.

Comment Overview
The use of comment content was very well used, making parts of the code easier to understand. Also using end closing brace comments when they had a complex nested control structure, which made it unproblematic to follow.

Javadocs
Their javadocs gave a good complete description of the program. It gave good details to understand what each method's function is in the game and also what the parameters are that’s being passed in.

Logic and Structure
The method logic was good throughout the code, but the attack() method could have been named better to show how the function is described in the javadoc. Since the attack() method was to tell the knights to move aggressively, and also they had another method which was to tell the knights to attack.

The class structure was well designed, most of the main function of the knights, peasants, and castle was organized well. They first split the knights into the 2 groups then having them move to a specific manner, then calling the oderPeasants() method for the peasant movement, and lastly controlling how much knights or peasants to produce.

Coding Format

File	Lines	Violation	Comment
MyRuler.java	9, 86, 87, *	ICS-SE0Eclipse-2	more than 100 characters in a line
MyRuler.java	231	EJS p.24	Method naming convention

Conclusion
The goal of this assignment was to review another person’s code, based on the Java coding and documentation standards. After examining West and Shum’s code, I see that they followed the standards pretty well. Doing this, they made it uncomplicated to understand what each portion of their code was performing. Following these standard is very useful and would make open source programming easier for all programmers.

Lessons learned from CodeRuler

Description

Code ruler is a java game project open to all java programmers, for competitive real-time competition. It is based on a medieval theme having knights, peasants and a castle. The objective of the game is to occupy as much land as possible, capture your opponent’s knights or peasants, and castle. You can win by eliminating your enemy or by having a higher score. The programmer must write code to control the knights to capture enemy units and castles. Also to instruct your peasants to obtain an abundant amount of land for resource value, this will be attributed to your score at the end. With resources, the programmer will decide how many knight or peasant the castle will produce. Using a good strategy commanding your units, the programmer can attain victory.

Programmers

Ronn Reeves
Robin Raqueno

Strategy

We took two approaches in our strategy for the code ruler game: eradicate our enemy’s economy and at the same time increase our economy.

First we had our knights capture the enemy’s castle, that way we disrupt their production flow. If the enemy were to acquire another castle, our knights would be directed to that castle and ordered to capture it as well. Then, with no more castles to capture, our knights would turn their attention towards the enemy’s peasants. The knights would then be directed to capture whatever peasants that are left at that point of the game. Lastly the knights will capture the remaining knights.

The next idea we had was for the peasant’s movement to cover as much land as possible, so that we rapidly increase our resources for more production of knights or peasants. We had them move in box pattern. Once a border of the map was hit by any peasant, all of the peasants would proceed in uniformed different direction. Also we had the peasants avoid be captured by an enemy knight, by checking two spaces ahead. If that space was occupied by an enemy knight, then the peasant would go in an opposite direction from that enemy knight.

Results

Test	Our Team	Migrate Ruler
1	694	6
2	676	14
3	652	2
		Gang Up Ruler
1	516	232
2	586	133
3	525	233
		Split Up Ruler
1	439	359
2	479	354
3	529	234

Download

Click here to download our version of myRuler.java and the javadoc files

Conclusion

Using eclipse is still very new to me, but I can see that it has a lot of pros than cons. Such as, changing a variable used throughout the file. The user just has to refactor the name at the top, where it is initialized. This is a java IDE that is very useful and I can see myself using for future projects.

Working with a fellow programmer was a very good experience. My project partner, Ron, was open to many suggestions and ideas on how to build our strategy. The only problems with working with another person is having conflicted schedules, but we discussed the project as much as possible through Skype or meeting in person.

Overall this entire project has been very educational. Seeing how well we can work with others in the same field, using a new tool, and working on an open source program. The difficulties of programmers working on the same project and not being in the same room; communication between programmers is must to succeed in finishing a project. Also working with an open source project, commenting code must be at a good level. The process of working on this project has been fun and enlightening.

Open Source Software

Open Source Software: Home Sweet 3D
Description: Sweet Home 3D is an interior design Java application for quickly choosing and placing furniture on a house 2D plan drawn by the end-user, with a final 3D preview.

URL: http://sourceforge.net/projects/sweethome3d/#item3rd-1

Primary Directive 1: Sweet Home 3D is available for the Windows, Linux, and OS X operating systems. Once installed the program’s user-interface is very easy to use, having a list of items on the side panel to just drop into the work space for designing a room. The program also includes a help menu, which helps the user for more complicated projects, such as designing a household. The best part of the program is the 3D panel, which shows the user a first-hand image of how the design would appear in real life. This program is a very useful tool to any home owner or to any person wanting to decorate a room.

Primary Directive 2: The program is packaged into a setup.exe file, which automatically sets up everything for the user. It requires JRE 1.6, but is already included in the package, having no need for a separate download. The program itself did not come with any installation instruction. The only file that was required to be downloaded was a setup.exe file, which makes it very easy for a user to install.

Primary Directive 3: Home Sweet 3D’s source package is a separate download from the setup.exe file. Within the source package are the files to modify if wanting to make improvements or to fix errors in the program. From a software-developers view, the descriptions contained in the files are very helpful in determining its functionality. The coding is very clean and the comments made are very clean. The files packaged are also very organized. The folders and files are named precisely to what its function to the program is, making it straightforward to what file to modify.

Purpose: The purpose of this assignment is to create a java application that counts from 1 to 100. The number is then tested to check if is divisible by 3, 5, or 3 and 5, which will print out Fizz, Buzz, or FizzBuzz (in respective order) instead of the number.

Problems: The main problem I had for this assignment was getting used to using the program Eclipse. This being my first time to use it, I had problems starting a new java project, and then also making the java class file. Once I got those issues out of the way, the main problem was compiling and running the application for testing.

Solution: The way I overcame the problems I listed above was just too simply use the built-in tutorial. I used the simple tutorial on building a “Hello World” project, which guided me to everything I needed.

Conclusion: The assignment took me about 18 minutes to implement, including the time to figure out how to use Eclipse. After using the program, I see now that it’s a very good useful tool in code implantation. I’ve always heard of people using Eclipse, but never bothered to use it, I’ve always used Jcreator, Textpad, or even Notepad. Eclipse is similar to Jcreator, both being able to start java project and automatically put in the ending squiggly brackets for you. The difference I’ve seen so far, between the two is that Eclipse notifies you of a syntax error right away, before running the application.

Code:

public class FizzBuzz {

 // This Method will print Fizz, Buzz, or FizzBuzz depending on the integer
 public static void printFB(int 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);
  } 
 }

 // Main to test the method printFB
 public static void main(String[] args) {

  //Test Cases
  System.out.println("Test Cases");
  printFB(53);
  printFB(5);
  printFB(21);
  printFB(15);
  printFB(0);
  printFB(1);
  System.out.println();

  // For Loop from 1 to 100
  for(int i = 1; i <= 100; i++){ 
   printFB(i); 
  }

 }
}