Preliminaries of the Devcathlon

This week, our class was split into three groups to initialize the development of the Devcathlon.  For this first stage of the development, each group was given the chance to create a mockup of the how the user-interface would look for the Devcathlon. 

My group, consisting of Schellar Sanchez and John Ancheta, took many different approaches when going through of what a user of the Devcathlon might see.  Schellar and I used a possible page similar to Myspace for the user’s profile.  John also thought of using Yahoo Games way of creating matches between teams.  We all put our ideas together and came to terms of what the interface will be, dividing the pages to each member.

One of the pages I was charged with developing was the Team’s Page.  I thought of some ways to do this page, looking at how Myspace and Facebook designed their group pages and what options they gave to members of a group as examples. 

Each group also put the Devcathlon events to the test for this assignment, where we would rate ourselves.  The events we used for this round of the Devcathlon can be seen in this table:

Event	Points
Commit early	19
Commit regularly	19
Don't wait until the last minute	-5
Collective ownership	5
Provide issue ID in commit message	-1
Every member has an open issue	-3 (total)
Team meeting	20

Since no programming was involved, not all the events of the Devcathlon were put to practice on this round.  We came up with a total of 40 points, which isn't so bad.

Seeing that we got a head start with 20 points for an early commit, I sure hope we won.  Points wise, I think we won; but in the design walk-through of the site, maybe we have something other teams might like or might have missed.  In web designing, I noticed that a lot of the “wow” features comes from the CSS part of the webpage.  Unfortunately none of us in the group are web page programmers, but I say we did a descent job in designing the web pages.  

A new view to Game Designing

Intoducing the Devcathlon

This semester, yours truly, will be continuing the journey into software engineering by taking the next level, which is ICS 414.  I will be participating in the development of the devcathlon, which is inspired by the decathlon.  Unlike the decathlon, the devcathlon will involve software developers and there will be no physical event involved.  Though, the devcathlon will be very much similar to its original counterpart the decathlon; it will have events that developers can participate in.  Software developers partaking in an event by entering, either individual or team, projects.

The development of the project will earn points by events, such as: the number of commits you do to the repository, having a high coverage, keeping complexity of the program low, and many more.  All these can help you gain points or possibly have you lose points, in either an individual or team event.  This will be possible by the use of Hackystat and its sensors, which monitors the project entered to the devcathlon. 

Right now the devcathlon is still in its design phase, but I’m looking forward to taking part in the progress of this semester project. 

 

Gaining wisdom

 In an effort to understand on how to design the devcathlon, I did some readings on effective game designing.  I first found an article containing pieces out of Richard Rouse III’s Game Design: Theory & Practices, which focuses on the elements of game play.  The articles talks about how game designers are expected to instinctively know what makes a game really good, like a sixth sense of that person.  Also that, designers should use holistic methods in devising puzzles or other problems that a player must solve in order to progress into the game.   One idea that I found interesting was to not have the game be linear, having the player became apart of the design of the game’s story; such as, taking a number of different routes to get from point A to point B.  Using the non-linear idea will make the player not feel enclosed to just one way of playing, that way he or she would not become bored of the game. 

Another interesting article by Ernest Adams, entitled Simplification, he discusses how inexperience designers aim to include realism into a game.  An example would be, including air factor and gravity in an airplane simulator game.  Adding such realistic features, make the game complicated, having the player that isn’t a real life pilot not want to play.  He then mentions that designers should include such possible features at the beginning of the game’s design, later removing them and possibly adding back in; taking into account the load it may cause on the tools used to play and make the game. 

I also read a few other articles, another by Ernest Adams, called “Bad Game Designers, No Twinkie”.  He lists a number of characteristics that have not been thought out well in games, both old and new.  Another piece I found was an excerpt of the first chapter of Richard Rouse III’s Game Design: Theory & Practices.  In this chapter he converses on the subject of what players want out of a game.  The last article I read, by David Harlow, was Games as an Educational Tool.  In this, the author talks about how games could be a very useful tool to share some education through some parts of the game.  An example of this would be, using a player’s math skills to unlock a treasure chest.  He then lists things that designers should remember when designing educational games, such as keeping the player motivated to play. 

A better grasp of designing

After reading many articles on effective game designing, I now have a better grasp on how to construct the devcathlon.  Such as, keeping the user interface simple; we wouldn’t want a new player to have so much trouble just to find out his daily event score.  Also another is to find a way to motivate a player, at times competition brings the best out of people or it can also bring out the worse.  Hopefully all the programmers that participate have good sportsmanship.  Lastly is to not drift away from it being an educational tool, but still being fun to play.  

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