Final Implementation - DueDates

Throughout the semester, we have been working on this DueDates Project. I just started out as a command line program that incorporated screen scraping using Java and HTTPUnit. The next thing you know, its a full-on web application that uses all functionality that we programmed throughout the semester. If you step back and take a look at the bigger picture, the process was actually quite intriguing. After going through semester after semester, writing programs and running them through a command line, it was "satisfying" seeing them come to life on a web browser. I think this was actually the most fun I had in regards to a project-type assignment.

We were able to finish all core requirements with no real problems. I think the key to getting to this state was to have started early and tackle obstacles quickly. The night the assignment was assigned, I went ahead and got the wicket files and configuration setup with a basic CSS layout, with the ability to fetch due dates and output them into the screen. The others were glad to have the framework for the system. The only thing that they had to get through was the learning the code of my previous DueDates system, DueDate-Blue. We initially voted on which system we were going to adopt, so after the choose, I had to run through the way the classes were coupled and what not. I believe our work flow as a group, was great. We originally appointed a "leader", which happened to be John Ancheta. I personally think that he did a good job handling scheduled Google chat sessions, calendar trajectory, task distribution, basically trying to keep the group afloat and on the same level.

Some aspects of working on this 2.0 version were easier, in a sense that the functionality of the system was already implemented; The hard part was learning techniques and logic that wicket programmers use. Since my group member, Yasu Kaneshige had a good deal of CSS practice, he did take over the visual design aspect of the system. Anthony Du and I tried to tackle the extra credit requirement. The use of Derby and connection drops gave me a huge headache; it was frustrating because I did have it functionally working the first night, then after doing pmd and findbug fixes, the connection would drop. I guess the fact that I had to try and learn it in 2 days played a role also. I would love to try and implement another project with a database back end.

After all is said and done, this project was great. Aside from the errors from the hacky-stat setup, and the downtime from Thanksgiving weekend, I didn't find anything to be much of a bother or setback. If there was one thing that I could change, is when we made the jump from 1 partner to 3 partners: the ability to keep your existing partner and join a pair. I really think the end product of all project would have significantly increased.

My First Java Web App

After years of learning to programming as an undergraduate, we finally get to see it "come to life" on the big screen! Well, a webpage... but anywho, this pretty cool looking at a a dynamic website that is java powered. I have a stronger background in PHP/MySql development and light experience with ColdFusion so I have a good amount of knowledge when it comes to dynamic web page elements and html.

The assignment this week was to revisit the Stack and implement a web interface for it. A stack is a generic data structure a stack is an abstract data type and data structure based on the principle of Last In First Out (LIFO). With a stack, you can add, retain, and remove data. Use the interface below to visually see the behavior of a stack data structure. Really simple concept, so the brainstorming was easy. 3 options presented to the user: Push, Pop, and Clear.

The tools introduced to us this time around is Wicket, Jetty, and Slf4J. With a combination of these tools and a little bit of imagination, you can have yourself a Java Web App! As a structure for the assignment, Professor Johnson provided us with wicket examples.

I did take a little time to create css div and changed the general appearance of my site. Here is a screen shot:














In the last remaining weeks, I look forward to dealing more with Java web apps and converting our DueDates project into something great.

Download stack-wicket-erinjuneilkim.zip

More DueDates!

Whats new?

So this weeks task was to add email and "wakeup" functionality to our project. If a user uses -email argument, the results of program is emailed to the given email address versus just printed in the terminal. This makes printing and referencing back to items remarkably easier. The "wakeup" function gives the user the ability to just have they system sleep for a certain amount of time, then "wakeup" and run the program. Now at frist, this sounds kind of useless or seem like spam messaging, but when paired with the -within arg, its actually a handy reminder tool. Invoking something like:

-email youremail@do.main mail.hawaii.edu -wakeup 1 -within 1

will run the system once a day and email you if you have something due the next day! The concept is cool and a lot more practicality to our system.

Implementation

Got our first taste of javamail! Easy to use after a couple of examples. I have had some previous experience with Sendmail so it wasn't that hard to grasp any of the concepts. Unfortunately, we did run into complications when it came to running it on the Eclipse IDE vs Terminal. After spending some time debugging and class discussions, we found that we had to import the mail.jar file into the actual Java IDE Directory. Everything was running as expected after that.

Within was handled by my partner, Arthur. The concept was basically a cronjob, so it was just manipulation and use of the Timer class. He finished this implementation fairly quickly with no real hassles.

What now?

The tasks given to us were fairly easy to get going; the only problems we really ran into were jar file complications. Aside from the class meeting together, we didn't meet make and effort to meet outside of class this week. Though, we did have daily messenger conversations to communicate our ideas to each other. It worked out well. In comparison to the previous upgrade implementation, I found it to be on the same level of difficulty. When taking a step back and reflecting on the project, I find it pretty cool on how we are slowing adding functionality to the system and ultimately make it what we want. This upcoming week, we will start to look at web apps and see how we can somehow integrate that into our system. Pretty exciting!

Software ICU???

ICU?

So the general idea behind a standard intensive care unit (ICU) is to check for vital sign regularity. Everything in the "norm" (adjusted depending on illness and severity) will look and sound normal; when someone is about to die, then the machine goes crazy. Brilliant idea in the medical field. Now, how in the world do you hook up virtual software to an ICU? The idea was great! It pretty much takes out the hassle of running tools every single day and the entire process is automated! Another cool tool add to the software engineering arsenal.

Here is a sample screenshot of the output






In our case vital signs are found at the top of the columns. The only term that seemed foreign to me was "Churn", which basically means the measured amount of code line change.

Arthur and I have successfully finished the assignment meeting all requirements. The entire class did have a run-in with the failed ant -f hudson.build.xml. After a huge online class discussion, we resolved the issue by adding a UserMaps.xml to our home sensor-bin directory.

Currently, our project is lacking in the coverage column. The main issue is that we have an entire class, DueDates.java, which meets 0% coverage. Arthur and I are currently coming up with a way to properly test it. Other than this, we have pretty satisfactory "vital" signs for our project.

DueDates -- Revisited

The 2nd part of our original assignment was quite interesting. Compared to the previous assignment, this had a little more head scratching and brainstorming, which is great! 75% of the code wasn't done for us which left room for different approaches and logic models across the various groups in the class. The code review that just took place was great insight on how other groups approached the assignment. Since I have a little more experience in programming with scripting languages, php and perl, screen scraping and string manipulation is something that I toy around with a lot. I did feel that a good portion of the assignment had to deal with date comparison; I also had a good lesson in how Java handles string/date differentiation. Luckily, Arthur and I were successful in implementing all the requirements to the assignment. The Hudson service was also introduced to us this time around. Incredible tool. I found it to be a great help because of its ability to automatically build the system every time there is a commit and sends email if the build contained and error. This takes out the frustration of tracking down the last person to commit and troubleshooting code. Upon completion and a code review done by DueDates-Purple, my partner Arthur went ahead and restructured the system by making a separate "library" package. A great improvement for modularity and robustness.

Arthur and I spent almost everyday talking about the project over AIM chat client but meet face to face on some occasions. Most of our ideas were effectively communicated to each other and ambiguity was non existent. A huge part of our communication was through Mac OS X Leopards iChat client were we could speak and look at each others screen to troubleshoot code. Again, the tasks were split based on the issue log that we updated on GoogleCode. We committed code almost everyday at least once a day, tackling issue after issue. There isn't anything I would really change as far as the process of how Arthur and I get things done. we

The next time around, I think it would be great if we could actually work with more members. Pair programming is something that I have practiced over the past years, but working on a system with a bigger team would be great. I do predict that this would be harder because we would all have to meet on our free time to communicate effectively. Since everyone is on the go and will probably have conflicting schedules, perhaps a group based message board would help? Chat rooms?

The Code Review. Part 2

What review?

Hmm... This past week we were given updated tasks to further enhance our system. Review process again worked two ways. From the looks of it DueDates-Green has not done any work since their first review. I just stopped reviewing their code after my first couple of comments. Thats when I noticed no progression was made after thier first submission. Professor Johnson mentioned that they are away for a trip, still I feel that it is unfortunate to miss out on growth and improvement on your system that you are going to work on for the rest of the semester!

Feedback

As usual, the feed back was great. Our system has evolved in a huge way, and this time, 85% of our code isn't programmed for us! We had a lot of implementation to do. One of the biggest changes was in our logic. We created an entirely new class for borrowed objects which we felt was a great object-oriented approach to solve the problem of adding multiple libraries, which ultimately makes the program more robust. The comments that were received from DueDates-Purple were somewhat helpful. The complements on the User guid and Developer Guides ensured us that we are heading in the right direction to make them as clear as possible. We did revamp our project home to be much more visually pleasing, got a couple of comments about or previous version. I think its great to hear that people find your program to be great and they will look into adapting our logic/code into their system. And of course their other recommendations will be taken into consideration.

In the end
I'm just glad that the party that wasn't here was the one that we were to review. It would just be unfair for someone to scratch someone's back and have it be unreciprocated; in this case, DueDates-Orange. Maybe next time, if there was a group that didn't make the effort to progress, they could be skipped over in that weeks review? This would ensure that no one will be left behind for those who are making an effort.

Code Reviews: Pros/Cons

Overview

This past week we were given our first crack at a review for our classmates DueDates Software system. Some were good, some were bad... The thing is, we were previously given a bootstrap of the software, so about 80% of the programming was done for us! The programming portion of the assignment was really simple, just simple arg handling in the main(). I feel that the real exercise of the assignment was to make use of all of the techniques and tool that learned the first half of the semester and execute something useful. The review process is nice and quick, thanks to Google Code Project hosting. The tasks/issues, commit logs, and source change logs make this a peice of cake.

Pros

Reading other people's code opens a whole new insight on things: coding styles, logic, and feedback on our own code. I find reading code that makes sense to be a treat, a lot harder to find these days. The feedback we get on your code is great, another form of constructive crisitism! Funny how this is the first time someone has ever told me to use the Scanner class vs Buffered Reader (Something I learned back in 04'). I feel that we need more peer code review in software development; I find it to be a big help when it comes to improving the quality of my code.

Cons

Its really a disappointment when you are reviewing code that is supposed to be "completed" and there are just signs of "last minute effort" all over the code. There was a group that didn't even check if the table being retrieved was the table of interest. Also comments like "Author: Philip Johnson" and "Assume the first table is the one we need. Not true in general." were ignored. The amount of time spent on the project is really reflected on the amount of time that was put into it.

DueDates

Overview

I felt that this was our first "real" software engineering task. After learning the tools, standards, and practices, I finally got a chance to put these skills into use. I felt that the majority of the assignment was to exercise our ability to incorporate the use of Google Code, Subversion, HTTPUnit, and Java. I took on this portion of the project with my partner Arthur Shum. We met approximately 4 times during the course of this week, but spoke daily over a messenger service. Luckily, our communication was great and we easily got our ideas across to each other. Was the purpose of this project successful? Definitely. There were some ups and down, but overall: a great experience.

Breakdown

Google Code makes project hosting simple yet intricate. I found it really easy to throw in issues, classify them, then work on them. The fact that its all listed and easy to refer back to makes project organization really effective. One thing that I found intriguing is that the commit logs can easily reference a certain issue by just typing "Issue #". Wikipages! Great way to put up documentation pages. We threw up a User and Developer Documentation that is easy to follow to guide you through the hassles of figuring things out yourself.

HTTPUnit is great. I have had my share of "screen scraping" using PHP CURL module and getFileContents() function. Since PHP is more of a scripting language, I was more used to ripping apart the HTML by searching for keywords and tags and extracting information that way. HTTPUnit pretty much takes all that and does the work for you. I was blown away by the built in functions that were available, such as the getTableStartingWith, getCellAsText, and getFormWithName functions. I may even convert to doing all future "screen scraping" in Java because of this! Good stuff.

Once again Subversion made it really easy to work with a partner and program on the same files. This ties in with Google Code and the use of commit logs to track changes. It became really routine to run ant -f verify.build.xml before and after every commit, which is extremely good practice. This does lead into one annoying PMD error that I will talk about later on.

I have been programming with PERL and PHP for the past 5 months and to jump back into Java was a little strange for me, especially when it came to small trivial things like string matching/manipulation and the use of regular expressions. Java is a really powerful language and has so much to offer, I just felt like it was too much of a "step up" for these simple tasks. I guess the syntax of these scripting languages have taken its toll on me. I guess the best practice is to keep using Java and be aware of its different approaches and methods.

Issues

Now, the bad. This really irritating PMD error was persistent throughout the week and had something to do with a "Singleton" class. The only way than we could fix this was to throw in a public void method that wasn't static. Another issue I had with this project is the use of Wiki Markup. I can't believe that there is no < br / > equivalent in WikiMarkup! I found my self pulling my hair out, trying to make certain images on their own line without making it a bullet; I still don't know if this is possible.


Conclusion

I am real fortunate that we got through the assignment with no big headaches. Of course, this is due to the use of these tools that were available to us. I could not imagine trying to do this over a system where you must mentally keep track of an issues list or consistently emailing source code to one another only to find that there are conflicting lines of code that are incompatible. I also learned that effective communication is a huge factor in working together, which included prioritizing and distributing work evenly across group members to ensure a fair work flow. I look forward to advancing thing project with even more group members and functionality added to it.

Configuration Management

Google Code and Subversion

The idea of having a controlled systems where multiple people can access the same code, make changes and continue to work as a whole is genius. Now there are multiple ways to handle this:

• Revision Control System (RCS) - open source, unix based, involves "locking" of files
  
• Concurrent Versions Systems (CVS) - uses RCS as backend for version control and adds configuration management support. Allows multiple developers to checkout the same file, but merge confilcts. "optimistic locking"
• Subversion (SVN) - back-end repository is a database, versions are not file-based, but repository-wide, "directory" based tags and branches, arbitrary metadata.

In our approach, we are using Subversion, mainly because it has the most benfts when compared to the others and code.google also makes this easy for us.

Obtaining someone else's

Since I'm using a Mac for the class, the Subversion client I was to download and install is called SmartSVN 4. Amazingly, it has a really nice GUI, the setup was incredibly easy, and I found my self connected to the repository in minutes. After taking on the task to download the stack-johnson repository files, using the SmartSVN was like 2nd nature. Distinguishing recently changed files and committing files with message was a peice of cake. It is amazing how a tool like this could be this easy to use.


Creating my own

After creating my own code space on google code, I used SmartSVN to help create a new repository locally and remotely off of my recent stack project. After running ant -f verify.build.xml, initially I had trouble when it came to selected which files I was to upload. The file hierarchy that Google Code makes it easy to double check and ensure that the right files were committed.

Conclusion

I found all of the tasks to be easy to do once you figure out how to use your SVN client. The hardest thing to do is to configure the client and have it link to your repository. I could see myself using SVN/CVS in a group projects where multitude of members are making changes to important files. Paired with efficiency and functionality, SVN can easily save a lot of headaches and time.

Emma & JUnit

"EMMA is an open-source toolkit for measuring and reporting Java code coverage. EMMA distinguishes itself from other tools by going after a unique feature combination: support for large-scale enterprise software development while keeping individual developer's work fast and iterative."-- Taken from EMMA

I am real fortunate to have learned to use EMMA with JUnit test cases. I found the software to export a great html interface and easy-to-navigate pages with clear and concise visual representations of what functions and lines were hit and not. This feeds to the approach of "test driven development". The key is not to develop test cases that is geared for coverage, but to deveplop good test design which will yeild 100% coverage. I can easily see how a novice programmer using EMMA will just write test cases to obtain 100% coverage under the EMMA output. According to the paper "How to Misuse Code Coverage", written by Brian Marick, he gives the following tips:

• Think of what the feature in the interface that condition corresponds to.
• Rethink how you should have tested that feature. Don't worry about how to satisfy the coverage condition, or think too muhc about other missed coverage conditions in the same feature.
• Run the new tests and recheck coverage. You should expect to satisfy the missed coverage conditions in the feature, even tho you didn't specifically target them.
• Repeat for the other features

The bottom line is: don't give into the urge to satisfy the '100%', as tempting as it is, don't design test cases that way.

Unfortunately, that is easier said than done. I found myself looking at which functions I didn't cover, then just writing test function which uses assertSame to see if they work. Then I took a step back, but double-thinking it, I since the detail of the missed lines were so small there really was no other way to do it.

Recently we were given the task to modify code that satisfies the 100% coverage but have it fail test cases, just to prove that having 100% will never be sufficient. I was confused to how I would actually implement something like that... I initially took a wrong approach and modified JUnit test cases, then took a different route and had the data structure mess with the cases instead. Successfully that was correct and was quite easy to accomplish. The idea is that the cases assume the best, but don't expect a the unexpected. The functionality is right, but only to a certain extent.

Source:

100% Coverage, 0 Failures

100% Coverage, >3 Failures

Ant.Lab

Goal

The goal of this in-class exercise is to help you get oriented to the build system standards for this class, and the use of Checkstyle, PMD, and FindBugs to improve the quality of your Java systems. .

Automated Quality Assurance vs. Manual Quality Assurance

After reading John's review of my CodeRuler assignment, I found most of his points to be valid and equitable. We did miss some key points as far as Javadoc format and content, simplifying if-else statements and function calls and some formatting errors. If I were to go and fixed the issues that John picked out, I would take an estimated 5-10 minutes on styling issues, and perhaps another 15-45 minutes with redesign and implementation. On the flip-side, when running an automated QA, seriously amazed by how much the human eye can miss! 500+ Checkstyle errors/warnings alone. This is a serious efficiency improvement, mainly because it literally took seconds to generate this huge list, each with this own reasoning, and explanation.

When considering actually sitting down and taking the time to fixing some of these (extremely) minor errors, the time-cost factor comes into play. After running eclipse formatter through each of the files downloaded from IBM, it dramatically reduced the amount of Checkstyle errors across the classes. PMD produced about 30 of priority 1 & 3 errors throughout the project, all which seem very easy to fix. These findings are definitely something that a human eye will not catch verbatim.

Conclusion

I'll conclude by saying by saying that the Automated QA is worth the integrity and quality of your project. It will be a time consuming process, but the caliber of your code will be at best. It is easy to spot hard work when you see it. The last thing you want to be judged on are your flaws.

Ant - Stack

Objective

• The Ant build system
• Open source Java automated quality assurance tools (FindBugs, Checkstyle, PMD)
• The course standards for build system structure and packaging.

I was first exposed to Ant through my internship last year. Initially, I was confused; there was too much unknown functionality and processes that took place during an Ant run-time. I was told that Ant is like a Make in C, simple enough right? I took a look at the .xml files and tried to trace through them; I was completely boggled by the syntax and functionality. After visiting the .xml files in class and tracing them step-by-step, the ambiguity has slightly cleared up. Ant was made to speed up the production, implementation, testing, and development of software. Another benefit of Ant is that it helps with the migration of software from one platform to another. The evidence is relevant, I'm assured that this tool is a powerful tool and will be implemented in my future Java software productions.

Installation

If I could sum it up in one word: Easy. I decided to tackle this class on my Macbook Pro; this is the first time I'm using OS X as the operating system of choice in a Java Development Environment. Class variables are very easy to setup through terminal. I felt that the entire installation process was drag and drop, defining paths, then command line tests.

Stack

Now the stack project that was easy to setup and install. I used Terminal to utilize and execute the tools: checkstyle, findbugs, javadoc, junit, and pmd. I found all of the tool extremely easy to use and fixing errors were as clear as black and white. I was surprised how everything was visually easy to naviagate through with the help of self-producing .html files with links to warnings, erorrs, and solutions.

Components

• Checkstyle has a huge impact on the aesthetics of your code, this will dramatically prepare your code on a visual level. This really takes eclipse's built in "formater" to the next level.
  
• Hands down, my experience with Findbugs has been incredible. Throughout my college career, I was bombarded with typical error lines like "syntax error on like 144 near ' ". I was blown away by the descriptions and recommended fixes that Findbugs produces. It really takes the strain away from formulating error fixes.
• PMD is a very cool tool that handles error and messages with priority levels. This tool finds possible bugs through empty statements, dead code, suboptimal code, overcomplicated expressions, and duplicate code.
  

Review Process

After invoking the ant targets, and having them produce the corresponding html files, it was just a matter of command-tabbing between eclipse, terminal, and Firefox. I found myself just fixing errors and cycling through the three. It was elegant, yet troublesome. if the entire process could be done in 1 window or application, I feel that this would have been much more efficient. The actual error correcting was a peice of cake though, mainly becuase the tools tell you what to do. "Use this instead of this, line x." "Needs a white space after '{' " As far as this assignment goes, it really easy to use Ant, and adapt to the process of fixing errors.

stack-erinjuneilkim-6.0.923.zip

CodeRuller Review

Objective

• to provide you with practice in identifying violations of our Java coding and documentation standards
• to give you a chance to look at another person"s CodeRuler implementation
  

Overview

I was assigned to tackle the code done by the 'lau-sanchez' group. After downloading, compiling, and running the application, I was able to test it against several of the prebuilt AI that came with the application. The Ruler was actually implemented surprisingly well, after testing it against multiple opponents, they won all their battles. The in class demonstration against the Smart Split and the Gang Up was successful as it made a come back and won the game! Even the programmer, Phillip Lau, was surprised that they won.

Dissecting the written code was somewhat of a different story. First, looking at someone else's code, you want to feel that you can pick it up and have it be at a level of consistency where you don't have to pull your hairs out to figure out what is going on. Fortunately, this code was easy to read through and follow in the aspect of: class use and structure, function calls, and strategy of this Ruler. Even the logic of each method preformed the tasks with noticeable efficiency. On the contrary, I could note that there was almost no uniformity in the JavaDoc of the different functions throughout the class. Problems vary from having extra indentation spaces, made up "@tag" names, capitalization, and extra tailing asterisks(*). Inconsistency was prevalent throughout the functions as well, there was one function with almost no indentation across for-if nested loop, while other for-loops had a three-space indentation. Many would agree that this just really reduces the readability of the code, luckily they are really easy fixes.

Below are the specifics with respect to the ICS Java coding standards and the Elements of Java Style rules.

Lines noted with an asterisk(*) represents more lines that what has been stated.

File	Lines	Violation	Comments
MyRuler.java	*	ICS-SE-Java-1	Code is not within the package hierarchy "edu.hawaii"
MyRuler.java	4	ICS-SE-Java-2	Do not use the wild card "*" in pimport statements
MyRuler.java	7,8,9,*	ICS-SE-Java-6	Made up JavaDoc statements? (@date, @course, etc...)
MyRuler.java	11,15	ICS-SE-Java-6	Supposed to be one continuous JavaDoc statement
MyRuler.java	15,16,17,*	ICS-SE-Java-6	Indentation is incorrect and extra (*) in the closing comment
MyRuler.java	42,54	ICS-SE-Java-6	No JavaDoc
MyRuler.java	83,87,90	ICS-SE-Eclipse-2	Spacing is at 3 instead of 2
MyRuler.java	96,97,98,*	ICS-SE-Eclipse-2	No indentation here
MyRuler.java	101,102	EJS-2	Use curly brackets for clarity and readability
MyRuler.java	111,133,142,*	ICS-SE-Java-6	Capitalize the beginning of these sentences
MyRuler.java	159	EJS-9	There is no indication of what 25 and 3 represent and why they are used
MyRuler.java	86,117,124	EJS-7	Space between the close parenthesis and open curly bracket

A majority of this list could have been avoided if they took the 2 seconds to have eclipse format the code...

Conclusion

Its not always an easy task to pick up someone else's code and trace it,(no brainer). When a programmer formulates ideas and flowcharts in their brain, most of the ideas are convoluted when it translates from a thought to text on a computer screen. The coding standards/conventions have helped ease the pain over the years. After the encountering the problems and difficulties in this assignments, I feel that these constraints are imperative to the coding society, even if it takes something as stupid of a rule as "Use meaningful names." to be published in a book. Saves us a lot of time, and ultimately-- money.

CodeRuler

Objective

Taken from assignments page:

• Become more familiar with the Eclipse IDE.
• Begin to understand the complexities of working effectively with other people on a software project.
• Have some fun!

What is CodeRuler?

Taken from the IBM Site:
"The game has a simple premise: You are the imperial ruler of your very own medieval kingdom. Your peasants and knights depend on your brilliant strategic thinking, agile adaptability, and superior Java programming skill to survive, increase, and prosper. Your objective as a player is to write Java code that simulates this ruler. The gaming simulator pits your ruler against up to six opponents' rulers (or the included sample rulers) and determines the winner."

For this assignment, I have collaborated with my partner, Daniel Arakaki. The scope of this program was somewhat small, so implementing a single class together was a little tight. We did find an elegant solution tho: we decided on one person to handle the peasants and another to handle the knights; since it takes both units to strategically win the game. Daniel was actually a really good partner; he had a significant amount of strategy and implementation ready a week prior to the deadline. Our only form of communication was through email, and yet, speedy replies and effective communication was in play. On the contrary, I do think that the assignment could have been handled individually, which could have taken away the stress and worry about your teammates end of the bargain.

Strategy

Things to keep in mind:

• Peasants who can claim and work the land.
• Knights who can fight battles and capture other rulers' peasants, knights, or castles.
• A castle that can create more knights and peasants. The more land you have, the faster it creates them.

The strategy really is two part: Peasants and Knights.

Peasants
As far as peasants go, there isn't really much that they can do. Move and claim. How in the world do you come up with a strategy for such a brainless class? Initially looking at IBM's Code sample, I noticed the way that they randomly assigned directions for each of the peasants. I stopped and pondered if there is a better way. Maybe to migrate as a pact? Disperse? or optimize the random movement? I decided to take the last approach and restrict the peasants movement to reduce the amount of moves a peasant makes in its own claimed territory; making wiser directional choices will help increase the amount of land claimed in a smaller time frame.

Knights
I feel that knights have a lot to do with if you are going to win the game or not. Who do you attack first, the peasants? Other knights? Go strait for the castle? Daniel was the mastermind behind this one. Daniel went ahead and implemented a peasants > castle > knights precedence, which is somewhat effective in some cases.

Conclusion

As far as the Eclipse IDE experience, its only beginning to grow on me in a positive way. Some of the experiences include: the easy importing of jar files, import statements, auto-JavaDoc filling and generating, easy indentation edit, cascading function/variable name changes, I mean the list just goes on. I'm just excited to see what else it has in store for me.

As I took a look at the programming aspect of the assignment , I found the the way the classes were structured and coded were perfectly. The inheritance hierarchy made the object easy to interact with each other, as they held similar properties and functions that weaved this game together. Here is an illustrated example (taken from the IBM Site):



As you can see, shared functions through the IObject interface lace the individual instances of peasants, knights, and castles. The IObject coupled with the World.java class/functions make room for easy programming. Which brings me to my next point. A speed bump that I encounted in this assignment was to actually strategically think of how the best way to "rule the territory" was. Long story short, the coding is much easier than coming up with some type of strategy, but at the end of the day, I can easily say that this was a fun and engaging assignment.

Results

Our Score on the left, Computer on the right

v. migrate
508 - 14
582 - 16
390 - 4

v. gang up
135 - 436
140 - 433
182 - 399

v. split up
120 - 405
136 - 392
116 - 417


Source

JavaDoc

Open Source Software Engineering

Overview

OSS?
This journey to have download, install, and use a Java-based open source system was quite... difficult. First being new to sourceforge, my initial impression of the service was overwhelming. The site consisted of: millions of projects, billions of downloads, varying categories, and ability to create your own project just to name a few. Then the question of OSS (Open Source Systems) come into play. Why are we even concerned with using OSS? Well, after reading up on it, long story short: The OSS development approach has helped produce reliable, high quality software quickly and inexpensively. Onto the experience.

The Install
The open source projects on sourceforge are very extensive in functionality, usability, compatibility, and amount of dependencies required. After browsing categories and filtering "Programming Language: Java", I found my self going through program after program, looking at supported (OS) operating systems, the amount of dependencies I had to install, check if the dependencies were compatible with my OS, most even required a back end database then they expected you to already have installed. Luckily, after an adequate amount of time searching for something plausible, I can across Arcus, https://sourceforge.net/projects/arcus/ .

Taken from the Arcus site:
"The main features of Arcus are

• 3D display of the cube, including animated rotations and layer turns.
• Besides solving the cube (that is, from any pattern getting to the state with one color on each side), Arcus is able to get from any pattern to any other goal pattern, which is a more general task.
• 3D Pattern Editor to specify the goal pattern.
• Pattern Store to gather and store pretty patterns.
• Keeping track of each turn, allowing the user to bidirectionally walk through the cube's history.
• Easily configurable Look and Feel, colors, mouse behavior, etc. Most of the changes take effect immediately."

Two files to work with:
- arcus-0.3.2-source.tar.gz
- arcus-0.3.2.jar

The .jar file is the actual application. In the .tar.gz file you'll find the source code, as well as the readme, makefile, change log, etc. I used the eclipse environment to create a new Java project, imported all the .java files with the accommodating packages/directories. Headache isn't over yet, error galore... Luckily Eclipse finds the causes of these errors and recommends solutions with a single click. I found that the main cause of errors were package name/declarations and my file hierarchy. I guess the way that eclipse imports them, isn't complementary to the import statements. I successfully fixed all the errors across the java files, unfortunately, they were still filled with warnings... The project was successfully able to compile, but upon execution, I hit an "Exception in thread "AWT-EventQueue-0" java.lang.ExceptionInInitializerError". The application failed to execute after that.

The Three Prime Directives for OSS Engineering
01. The system successfully accomplishes a useful task.
02. An external user can successfully install and use the system.
03. An external developer can successfully understand and enhance the system.

I actually found this application to be very useful. Its great for people who don't know the trick to actually completing the Rubik's Cube puzzle! Keep in mind that it doesn't give out tips or instructions, mainly because the functionality of the application is to analyze the algorithm used to solve the cube. The website does give out instruction for compilation, though I guess it takes a little bit more configuration for Eclipse. I'm still fairly new to errors pertaining applets and such, troubleshooting them would take a considerable amount of time. The user interface is excellent and the ability to rotate the cube, go step by step, see a rotation log, etc makes this visually pleasant. The Java classes are easy to follow and the methods/variable are logically sensible. The underbelly of the program lives in the algorithm of the Rubik's Cube. By all means an external developer can enhance the outcome. The other classes mainly pertain to the gui's, models, etc.

Conclusion
In conclusion, I am walking away with more appreciation for the difficulties involved with achieving the Three Prime Directives of Java-based Open Source Software Engineering. Even with a simpler project such as Arcus, such tasks are more than trivial and require more troubleshooting and thinking. I would imagine for a bigger project, even getting the dependencies correctly installed and configured would take a substantial amount of time.

Objective
FizzBuzz program should print out all of the numbers from 1 to 100, one per line, except that when the number is a multiple of 3, you print "Fizz", when a multiple of 5, you print "Buzz", and when a multiple of both 3 and 5, you print "FizzBuzz".


Observations
First off, development with an IDE such as Eclipse paired with JUnit has had a significant impact in the process of writing even a simple program such as FizzBuzz.  Due to the simplicity  of the program, I would be tempted to just open a text editor, write a quick 15 line program and be done with.  I was pleased to say that I did find a huge amount of convenience with Eclipse and find my self considering this IDE as an essential to Java programming.  Since the underlying point to this environment is to utilize a vast array of tools, I can only welcome them with open arms.  Bring it on.

One of the initial obstacles that I had to overcome was the way that JUnit actually works.  Even the import statements, classes, and functions all had their individual differences from a traditional Java program.  The ability to formulate a test driven design using JUnit takes a little bit of getting used to...  Since I taught my self to "debug" code using print statements in key pivot points, this was actually a comfortable change.  I did find this link to accommodate with this learning curve.

Since the timer officially started when I opened up Eclipse, the total time spent racked up to about 45 minutes.  The majority of my time was spent developing the syntax-correct test cases and reading up on JUnit.  The FizzBuzz.java took a measly 2-3 minutes to write.  

FizzBuzz.java

public class FizzBuzz {
 public static void main(String[] args) {
  for (int i = 1; i < 101; i++){
   System.out.println(getString(i));
  }
 }

 public static String getString(int i){
  if((i % 3 == 0) && (i % 5 == 0)){
   return "FizzBuzz";
  } else if (i % 3 == 0){
   return "Fizz";
  } else if (i % 5 == 0){
   return "Buzz";
  } else {
   return String.valueOf(i);
  }
 }
}

TestFizzBuzz.java

import junit.framework.TestCase;


public class TestFizzBuzz extends TestCase{
 public void testNumber(){
   assertEquals("Test 0", "FizzBuzz", FizzBuzz.getString(0));
   assertEquals("Test 1", "1", FizzBuzz.getString(1));
   assertEquals("Test 3", "Fizz", FizzBuzz.getString(3));
   assertEquals("Test 5", "Buzz", FizzBuzz.getString(5));
   assertEquals("Test 15", "FizzBuzz", FizzBuzz.getString(15));
   assertEquals("Test 100", "Buzz", FizzBuzz.getString(100));  
 }

}