ICS 499: 499 The End

Introduction
I am thankful for being able to participate in ICS 499. For a three credit course we need to spend at least 9 hours of study time or in the case of ICS 414 coding time. Much of my study time during the semester was spent developing code for Devcathlon. I estimate I average at least 20 hours on coding, blogging, and meeting with the Devcathlon team. So it was nice to have ICS 499 to apply the extra work hours.

What did 499 do for me
Each week I had to do a summary of what I learned and developed in ICS 414. There were weeks where I had no idea in what to write about. So ICS 499 forced me to think about what new skill did I add to my software engineering tool belt? Or what did I discover about software development that will make me a better programmer? Over the course of the semester I tackled and got tackled by various areas of software development in ICS 414/499 which included HTML, CSS, Wicket, Hashmaps, group work, and Devcathlon. I used HTML and CSS to implement the Scoreboard in Devcathlon. Using a hashmap I can keep track all types of data from Hackystat. With Wicket I can build dynamic webpages using Java. Group development taught a lot about myself and how I should interact with the less than perfect teammate. Devcathlon gave my practical experience with code development.

Conclusion
Did ICS 499 make me a better programmer? Absolutely, I feel I know a little more about software engineering than the previous semester. When employers ask me about my programming experience I can always say my ICS 414/499 blog is quite detailed as it talks what I have developed in the last year. If a student asks me which classes he or she should take in the Spring without hesitation I will tell them ICS 414 with 499. ICS 414 gives you the knowledge and 499 reinforces everything that is learned.

Devcathlon Critique

Introduction
The user testing phase of Devcathlon is under way and is going through an evaluation from all team members. Devcathlon is a working system that needs a database which will be implemented this Summer. There are several issues that will be addressed in the next build which includes more unit tests.

Issues
There is an understanding that all systems in its infancy are not perfect. Devcathlon has many issues which seem to be mainly cosmetic and not affecting the functionality. The list is an overview of the May 9 build.

• Teams: The only issue with Teams is when a user accepts an invitation he or she becomes a member of all created teams.
  There should be only 4 members in this team.
  
• Matches
  • Matches tab: Something should display in the Match Details panel.
  • Matches Manage tab: Something should display in the Match configuration panel.
• Scoreboard
  • The matches panel(left panel) needs to be paginated *already done*.
  • The Event panel needs to be paginated *already done*.
  • The Teams List should display names not emails, that function is part of the implementation not sure what is wrong.
  • Display the date of an invoked Event in Events panel *done, date needs formatting*.

The Review
To critique system I asked Peter Rodrigues an ICS graduate 2007 to examine Devcathlon. To checkout the system, Google's Chrome on a Dell was used. Naturally Devcathlon is not intuitive each section had to be explained. Peter liked the overall design thought it was clean. One major error we found while doing the review was in the match details panel when clicking on the headers a NullPointerException popped up. The panel with the NullPointerException.

Other minor issues we stumbled accross.

• Not all user IDs (email addys) are clickable, the page below is from the Browse Profile.
  
• Matches Manage page should display something
  
• Peter did not like the dynamic panels because the user name at the bottom of the page moves and is distracting.
  
• Its difficult to understand the layout in the Matches panel(the list of matches). It is not clear what one needs to do within the page. What does the user do with this page?

Top Five Lessons Learned from ICS 414

1. Patience in team development - Cannot expect perfection when developing code with a group of five or more. All users must be strongly encouraged to constantly communicate with each other. Get all developers to write daily emails about their progress and implementations.
2. HTML and CSS - First time using CSS for a real project took some adjusting but finally figured it out. I found CSS to be useful and easy to manage.
3. More Wicket - I wonder if Wicket will catch on? I hope so, it would be a shame to throw away everything I learned. I complained about Wicket in previous blogs which was more out of frustration because I am a novice with the framework.
4. More Java - Got more practice implementing code in Java. Got to use Hashmaps and Hashsets in production code. It was interesting to see how Java interacted with different languages and frameworks.
5. Presentation of a System - A lot of preparation needs to go into a presentation before showing it off to management. It can get uncomfortable when explaining a section of the project that is either incomplete or not working. Nothing like blank or angry stares from the boss to make you sweat.

Conclusion
Developing Devcathlon was frustrating yet fruitful I got to work on a system that will be used for ICS 413 in Fall 2009. I believe my software development skills are much sharper. I feel more confident and less fear when working with code. I hope the students in ICS 413 have fun with Devcathlon.

ICS 499: The ICS 414 Experience

Introduction
The semester is coming to a close and Devcathlon is in beta-testing mode. Devcathlon is not the subject of this week's blog but what was learned while developing the system. The experience of putting together a medium size system like Devcathlon was both fruitful and frustrating.

Web Design
Prior to ICS 414 my web design skills were limited to modifying html script for a page. With Devcathlon I had to tackle html, css, and Wicket to design the Scoreboard. The process of developing the Scoreboard page was a lot of trial and error. My main source of information for coding the board was the internet w3 schools provided a lot of help with css scripting. For the future I plan on taking a graphic design or art class to improve my design skills. I think the Scoreboard is rather plain and could use a little more flair.

Wicket
The more I work with Wicket the more I find it to be a frustrating framework. I am having trouble wrapping my brain around the concepts in Wicket. Much of my annoyance is with the structure of Wicket, the nesting methods and too much going on in the constructor. However, Wicket does its job in making dynamic webpages. Wicket is not a widely accepted framework, yet. I think over time more developers will find Wicket to be more powerful than Javascript to make webpages dynamic.

Teamwork
While developing Devcathlon I learned something interesting about teamwork in the software engineering world. The lack of team cohesion can kill a project. Not communicating can kill a project. Not working daily will definitely kill a project. The team should feel fortunate Professor Johnson understands the perils of developing a project with 8 individuals. A real client would be intolerant of teamwork issues. The real trick for a project lead or manager is unifying the team. I admit, I was playing the "lone ranger" with the Scoreboard. I was frustrated with how the team was devolving and consumed with the board design. In the future, instead of shutting myself off from everyone else because no one else wants to play together figure out a way to get people to play nicely together.

Conclusion
ICS 414 is a tremendous learning experience and I will encourage all Computer Science students to take the plunge. Despite my frustrations with teamwork I can say my coding skills have improved plus I learned a little web design using html and css. I hope I can parlay the skills I learned in ICS 413 and 414 into a career. Oh, yeah I plan on going for my SCJP over the summer.

ICS 499: Milestone 6.1 and Work Improvements

Introduction
The team was given a reprieve for Milestone 5 and was given an extension for Milestone 6 which I am calling 6.1. The Scoreboard has progressed quite nicely and is ready for display. Got into a jam with the sorting of a Map. Quite a productive week for the Devcathlon project.

Scoreboard
The Scoreboard is fully functional and takes live data via the Initialization class.

• All active matches
• All users in a match
• Match scores, events, and comments

There are some cosmetic issues that need to be address with the headers in the events panel and scores next to names. I think the Scoreboard is about 90 percent complete.

Sorting a Map
The last major hurdle of the scoreboard was to implement a top performers panel. The panel displays the top point getters of a match. To associate scores to users I employed a map to store the points. Now it makes no sense to display points arbitrarily the tallies should be in descending order. But sorting values from a Map is not a simple task. A magical method to sort a Map does not exist in the API. I had employ a TreeSet to sort the values and then used points as a keys to associate a user to a score.

    List userScores = new ArrayList(userScoreMap.values());
    TreeSet sortedSet = new TreeSet(userScores);

    Object[] scoreArray = sortedSet.toArray();
    
    List scores = new ArrayList();
    
    int size = sortedSet.size();
    
    for (int i = size - 1; i >= 0; i--) {
      scores.add((Integer) scoreArray[i]);
    }

The code is not pretty and it maybe prone to buginess. I will be working on improving the Map sorting algorithm in the next Milestone to conjure something more elegant.

Group Improvement
Up until last Monday April 20th the group was limping along in fact there were issues with presenting Milestone 5. After going through group therapy with Professor Johnson which, I felt was beneficial for everyone. I saw improvements in all facets of development: communication, coding, and team morale. I feel like that I am part of a team and Devcathlon will be completed by the end of the semester.

ICS 499: Milestone5 and Playing Nicely with Others

Introduction
Devcathlon is currently at Milestone 5. My responsibilities continue with the Scoreboard and added the match invitations to help out. I took on the leadership of the Match and Scoreboard team. Although, I am not sure if the group needs three chiefs. I think one leader is sufficient at this point, with only three weeks left in the semester. The group needs to be working together and hearing one voice. Not three different opinions which stifles productivity.

The Scoreboard
The Scoreboard now takes in real data showing the details of a chosen match. Right now the system is set up for two teams to compete. Eventually, Devcathlon will allow more than two teams to play each other. Of course this means the Scoreboard will need to go through a redesign to accommodate three groups or more. The team lists still needs to have members linking back to their profile. Also the Events details needs headings to make the panel easier to read.

Group Work
I have learned a lot about group development this semester. Throughout my professional life I have been a participant in a team where success was dependent on communication and working as a unit. Without cohesion and dialogue the team cannot meet its goals. Members maybe doing redundant work or a task requires multiple bodies for completion. Furthermore, the unit cannot work efficiently if two or three members are not performing the tasks needed to get the job done. The team will get stuck in the mud and cannot meet its deadline.

ICS 499: Data in the Scoreboard

Introduction
This week's milestone requires us to implement real data into Devcathlon.

Digging for Match Data
I initially took on the task of implementing the Initialization class which is used to create data to test Devcathlon. However, I encountered a set of issues that prevented from finishing the application.

• Could not connect with the host (Sensorbase).
• Did not have data to work with (User data).

Not being able to connect to the sensorbase was not too bad there were ways to workaround that issue. Not having the data was the bigger problem because the system needs information for it to work. Once the group figured out a direction which included sharing data: names, emails, and passwords. It should be noted the passwords are retrieved locally and not accessible to the public.

Retrieving data for display.
A lot of the implementation in Devcathlon is the digging for data. Every aspect of the system has data: matches, teams, users, and events its our job to pull out the info for display. Retrieval is fairly simple, Hackystat and Devcathlon APIs have the needed methods for extraction. The interesting part of the development has been the display of information using Wicket. Throughout Devcathlon the info needs to be presented as a link using the snippet.

 
        item.add(new Link("MatchLink") {
          private static final long serialVersionUID = 1L;

          /** Upon clicking this link, go to Match page */
          @Override
          public void onClick() {
            try {
              setResponsePage(new MatchDetailPage(mItem));
            }
            catch (Exception e) {
              // if there is an exception error
              e.printStackTrace();
            }
          }
        });

The code sets a Match name as a link and directs to the match detail page.

Page Layout with CSS
One of the challenges I have been encountering with the development is the layout design of the scoreboard. To the dismay of some of my teammates I have been using Devcathlon as an opportunity to learn html and css. The process has been painful at time however, I am learning about inheritance and how changing one value in one page can affect the layout in a different page.

Conclusion
The group got hit pretty hard with Milestone 3 due to a lack of sufficient progress. I think Milestone 4 will be an improvement and I think we built pretty neat system thus far.

ICS 499: Match Building

Introduction
This week's iteration of Devcathlon required a lot of thought and research. The scoreboard went through another design in order to fill up screen space and reorganize the layout. Encountered issues with memory in Findbugs and building a Match to start testing the system.

Scoreboard
The scoreboard seems to be a hot topic within the group as it consumed our attention at the beginning of the week. Everyone decided to go with the design on the left. The new layout is simple and makes good use of screen space as you can see very little white in the background. Anthony Du came up with great idea of using Panels to implement a modular approach to the scoreboard. So each piece can be refreshed at according to whatever interval the administrator chooses. However, the Matches section, because it tracks all ongoing matches will be updated every 60 seconds.


Matches
One of the difficulties I am having is creating a Match. Part of the problem with Match creation is with the instantiation of a project. To create a project in Hackystat.

• A user must receive and accept an invitation.
• Must have access to Hackystat server for the SensorbaseClient.
• The project must have an owner.

There is a lot involved in creating a Match that requires another day of tinkering. The alternative would be to implement a custom Project class that does not require the Sensorbase Client.

ICS 499: Scoreboard building

Introduction
The Devcathlon implementation continues and will consume my blog until May. I have taken charge of Decathlon's Scoreboard and the design is going slower than I expected. My knowledge with html and css design is limited but is getting stronger with the development of Devcathlon.

The Scoreboard
The scoreboard UI is simple in design, not too many elements that take up the screen. The left third of the page contains overall Devcathlon information.

• On going match scores.
• Links to Match breakdown(to be added later).
• Team information.
  • List of team members.

The rest page of the page contains the details of a chosen match. Within the Match Details page one can see the breakdown of a match.

• Time remaining in match
• Team picture
• Team name
• Team score
• Telemetry chart
• Team win-loss record(to be added later)

The telemetry chart will be most ambitious part of the design. Because I am not sure how to access the data from Hackystat without having to login with every refresh of the scoreboard. I may need to design my own chart utilizing the sensor data. For those unfamiliar with Hackystat. The telemetry chart is a visual representation of the collected Hackystat sensordata. The sensor data includes development time, build and commit counts, coverage, etc. The hope is have a tab menu where a user can view a telemetry chart for dev time, commits, builds, and coverage.

The Next Step
The next phase or milestone of the development is to implement functionality to the scoreboard.

• An invoked Event will put points on the board.
• Display ongoing matches in the Match Scoreboard with current scores.

There is a lot that needs to be done to have a working prototype by April 20. So I will be working continuously until the Scoreboard is fully functioning.

ICS 499: Dreamweaver and Devcathlon

Introduction
As a member of Devcathlon's Matches and Scoreboard design team I am taking on the scoreboard portion of the development. To aid with the implementation I decided to use Dreamweaver because I thought it would be easier to deal with the graphics involved with the scoreboard. Also, I thought it would be helpful to my future career to have experience using a tool like Dreamweaver.

Using Dreamweaver
When the team got the specifications I had played with Dreamweaver for about a hour. So my Dreamweaver experience is extremely limited and my hope for quickly coming up with a decent scoreboard design was dashed.
I chose Dreamweaver because the graphic intensive of the scoreboard and I know the program is quite powerful when working with image heavy pages. My ultimate goal is for the Devcathlon score to look like a sport's scoreboard. Just about everything on the Yahoo scoreboard is dynamic and I would love for Devcathlon to have the same function.

With Dreamweaver I can build a page.

• With tabbed menus.
• Set the background color black.
• Set the font color white.
• Set the positioning for just about everything on the page through css.

The nice thing about Dreamweaver is not having to hand code the style sheet. Through an interface I can add or edit CSS properties. The CSS interface is a handy thing to have especially if there was a forgotten element or if the style sheet is loaded with code. Conclusion
I like Dreamweaver I think its a powerful tool and is quite handy in building web pages. However, there is a learning curve and takes a few days to come up with decent results.

Devcathlon: Dreamweaver and Wicket

Introduction
The team is working on the full development of Devcathlon. Thus far, the developers have been taking baby steps getting acquainted with the framework for Hackystat and Wicket.

The Development
I am working on the Matches and Scoreboard team which includes.

• John Ancheta
• Robin Raqueno
• John Zhou

With Robin I am working on the scoreboard task of the design. John A and John Z are working on the Matches part of the development. The leadership decided to complete the UI first which makes sense. Because in order to implement the back-end of Devcathlon Wicket needs to be able to communicate with html script.

Coding Tasks as of Wednesday March 16

• Started the scoreboard UI implementation.
• Started the scoreboard Wicket implementation.
• Added the Hall of Fame page to the system.

Non Development Tasks

• Team meeting on March 21.

The team should be meeting more often to eliminate more issues from the board much of the communication is through chat and email.

Commits and DevTime
Dev time
Commits

Owned and Closed Issues

• Added Hall of Fame page *closed*
• Display Matches
• Display Current Score
• Build scoreboard UI

The goal with the scoreboard UI is to achieve a scoreboard that is cool and visually pleasing, thanks to Yahoo for the idea. Dreamweaver
I am using Dreamweaver to develop the scoreboard UI and the design has been slow going. I have not had the time to fully explore Dreamweaver so it has been a lot of design for a hour research for two hours. But I am learning quickly and managed to implement a skeleton of the scoreboard UI. I will talk about the learning and using of Dreamweaver in ICS 499 blog.

Conclusion
I am having a slow start with the development due to my issues with Dreamweaver however, I am confident that I can bang something concrete by the end of the week.

ICS 499: Wicket

Introduction
This week the Devcathlon team got reacquainted with Wicket. The assignment was to add and modify menu bars to make the page dynamic. Wicket is a nifty framework that works hand in hand with Java to develop web applications. As neat as Wicket may seem, it does have a dark underbelly that makes development somewhat unpleasant.

Wicket and Java
After spending a week working with the assignment I see the strength of Wicket and how nice it works with Java. With Wicket I was able to make changes to the menu tabs without having to adjust every html tag. Part of the assignment had us working with html files. Its a pain in the butt having to edit all files containing html scripts its tedious and boring. Using Wicket reduces the repetition that comes with html tag.

Wicket Issues
Over the week as I developed the menu tabs I noticed the structure and syntax in Wicket to be strange. It is difficult keep track the difference between a Model, Component, and Property. I do have the Wicket In Action book but when searching for needed information under 5 minutes a book is not helpful. For example, while implementing the tab highlight I had trouble trying to figure out if I should use SimpleAttributeModifier or AttributeModifier. The documentation never made clear why the SimpleAttributeModifier should be instead of the AttributeModifier. By the Wicket documentation needs a lot of work. For a framework I found the Wicket API to be poorly written and lacking in detail for much of the methods. One should not be afraid of using Wicket because of I have mentioned. The Wicket framework works quite well, having implemented the DueDates system.

Conclusion
The learning curve for Wicket is quite steep I would spend a lot of time familiarizing oneself about Models and Properties. A book would be really helpful with the learning process however, I do not want to be one that says one book is better than the other.

Working with Menu Tabs, Wicket, and CSS

Introduction
A huge element to the Devcathlon system is its dynamic pieces. Because ICS 414 is Java-centric, the team is using the Wicket framework to develop the web segment of Devcathlon. The class was given an exercise to highlight menu tabs using css, html, and wicket.

Code
I have a limited background working with css and html. With this assignment I am getting a lot of hands on experience with setting up links and adjusting the page's layout.

<ul id="subnav-3">
      <li><a href="test-submenu5.html">submenu5</a></li>
      <li><a href="test-submenu6.html" class="active">submenu6</a></li>
      <li><a href="test-submenu7.html">submenu7</a></li>
    </ul>

add(new Link("SubMenu6Link") {
      private static final long serialVersionUID = 1L;

      /** Upon clicking this link, go to FormPage. */
      @Override
      public void onClick() {
        setResponsePage(new SubMenu6Page());
      }
    });
...

With Wicket and a small addition of script on the html side I added three sub-menus to Menu 3.

• Add three links via html.
• Add three new sub-menu links via Wicket.
• Clicking on a sub-menu tab will link to the selected page.
• css handles the tabs' construction.

The code is redundant so don't worry if you feel you are missing something. If you have not worked with Wicket before it does take some time to get acquainted with the code's syntax and structure.

The page's header "Example 05" had to be reduced from h1 to h3. However, by decreasing the size of the header the layout of the sub-menus gets altered. So the sub-menu positioning in css needs to be adjusted.

body.section-1 #menu ul#subnav-1, 
body.section-2 #menu ul#subnav-2,
body.section-3 #menu ul#subnav-3,
body.section-4 #menu ul#subnav-4 {
 display : inline;
 left : 10px;
 position : absolute;
 top : 66px;  <--- To adjust the positioning of the sub-menus, I had to play with the numbers. 
}

Ten sub-menus had to be added to menu 3 which was not a difficult task. It should be noted Wicket has issues with having 10 or menus. Eclipse was complaining about something with the code. I had commented out the code for sub-menu 14 to see if I had implemented the first nine sub-menus correctly. After removing the comments from sub-menu 14 everything seem to work fine and could not figure out what changed so I left the code in its current state.

The most difficult part of the assignment is highlighting a menu tab that is active. Anytime there is a menu with sub-menus its difficult to tell which menu is working. So when a tab is chosen the name is embolden to highlight the working page. Making additions to the code is fairly simple with html and css.

#menu a.active {
  font-weight : bold;
}

<ul id="menu">
  <li id="nav-1"><a href="test-menu1.html">menu1</a></li>
  <li id="nav-2"><a href="test-menu2.html" class="active">menu2</a>
  <li id="nav-3"><a href="test-menu3.html">menu3</a>
</ul>

Conclusion
Making changes to a web page using only html and css can be time consuming and tedious. By spending some time learning the Wicket framework editing a web page will be much less of hassle.

Updated Version
Daniel's version of the menu bars.

Task 5
The code for adding sub-menus 5,6, and 7.

      <ul id="menu">
        <li id="nav-1"><a wicket:id="Menu1Link" href="#">Menu1</a></li>
        <li id="nav-2"><a wicket:id="Menu2Link" href="#">Menu2</a>
          <ul id="subnav-1">
            <li><a wicket:id="SubMenu1Link" href="#">SubMenu1</a></li>
          <ul id="subnav-2">
            <li><a wicket:id="SubMenu2Link" href="#">SubMenu2</a></li>  
          </ul>
          </ul>
          
        </li>     
        <li id="nav-3"><a wicket:id="Menu3Link" href="#">Menu3</a> 
          <ul id="subnav-3">
            <li><a wicket:id="SubMenu5Link" href="#">SubMenu5</a></li>
          <ul id="subnav-4">
            <li><a wicket:id="SubMenu6Link" href="#">SubMenu6</a></li>
          <ul id="subnav-5">
            <li><a wicket:id="SubMenu7Link" href="#">SubMenu7</a></li>



body.section-1 #menu li#nav-1 a, 
body.section-2 #menu li#nav-2 a,
body.section-3 #menu li#nav-3 a,
body.section-4 #menu li#nav-4 a {
 background : White;
 border-bottom : 1px solid White;
 color : #3366CC;
        cursor : default;
}

#menu #subnav-1,
#menu #subnav-2,
#menu #subnav-3,
#menu #subnav-4,
#menu #subnav-5  {
 display : none;
 width: 90%;
}

body.section-2 #menu ul#subnav-1,
body.section-3 #menu ul#subnav-3  {
  display : inline;
  left : 10px;
  position : absolute;
  top : 66px;
}

body.section-2 #menu ul#subnav-2,
body.section-3 #menu ul#subnav-4,
body.section-3 #menu ul#subnav-5  {
  display : inline;
  left : 88px;
  position : absolute;
  top : 0px;
}

body.section-2 #menu ul#subnav-1 a, 
body.section-2 #menu ul#subnav-2 a,
body.section-3 #menu ul#subnav-3 a,
body.section-3 #menu ul#subnav-4 a,
body.section-3 #menu ul#subnav-5 a {
 background : White;
 border : none;
 border-left : 1px solid #3366CC;
 color : #3366CC;
 line-height : 10px;
 margin-right : 4px;
 padding : 5px 10px 5px 10px;
 text-decoration : none;
        cursor : default;
}

Task 6 & 7
Code for adding 10 sub-menus to menu 3.

<li id="nav-3"><a wicket:id="Menu3Link" href="#">Menu3</a> 
          <ul id="subnav-3">
            <li><a wicket:id="SubMenu5Link" href="#">SubMenu5</a></li>
          <ul id="subnav-4">
            <li><a wicket:id="SubMenu6Link" href="#">SubMenu6</a></li>
          <ul id="subnav-5">
            <li><a wicket:id="SubMenu7Link" href="#">SubMenu7</a></li>
          <ul id="subnav-6">  
            <li><a wicket:id="SubMenu8Link" href="#">SubMenu8</a></li>
          <ul id="subnav-7"> 
            <li><a wicket:id="SubMenu9Link" href="#">SubMenu9</a></li>
          <ul id="subnav-8"> 
            <li><a wicket:id="SubMenu10Link" href="#">SubMenu10</a></li>
          <ul id="subnav-9">
            <li><a wicket:id="SubMenu11Link" href="#">SubMenu11</a></li>
          <ul id="subnav-10"> 
            <li><a wicket:id="SubMenu12Link" href="#">SubMenu12</a></li>
          <ul id="subnav-11"> 
            <li><a wicket:id="SubMenu13Link" href="#">SubMenu13</a></li>
          <ul id="subnav-12">
            <li><a wicket:id="SubMenu14Link" href="#">SubMenu14</a></li>
          </ul>
          </ul>
          </ul>
          </ul>
          </ul>
          </ul>
          </ul>
          </ul>
          </ul>
          </ul>

//Java code snippet
add(new Link("SubMenu14Link") {
      private static final long serialVersionUID = 1L;

      /** Upon clicking this link, go to FormPage. */
      @Override
      public void onClick() {
        setResponsePage(new SubMenu14Page());
      }
    });

In the css file menu.css, I added 7 more subnav tags to deal with the new submenu tabs.

Task 8
Thanks to John Ly for solving for this little nugget. I would have never have thought of using 'get("Menu1Link")' to add an attribute to the link tag.

public Menu1Page() {
   
   add(new WebMarkupContainer("body") { 
     private static final long serialVersionUID = 1L;
     @Override
     public boolean isTransparentResolver() { 
       return true; 
       } 
     @Override
     protected void onComponentTag(ComponentTag tag) { 
       tag.put("class","section-1");
     }
   });
   
   get("Menu1Link").add(new SimpleAttributeModifier("class", "active"));
  }

The above code calls on the active tag in menu.css to make a given tab bold anytime a user clicks on it.

Developing an Event: Commit Often

Introduction
The Devcathlon team gets to play with real Events this week. The implemented Events are the scoring mechanisms in Devcathlon. I was given the CommitOften Event, which was a tricky little nugget to crack.

Commit Often
The Commit Often event tracks the ratio of DevEvents to a commit. Any change made to source code is a DevEvent and is sent as SensorData. Commit Often scores the Event by doing the following.

• Look back at a given time and retrieve DevEvent data.
• Capture and store a file name in an ADT.
• Keep a running count of each occurance of the file name.
• If a Commit was made within 10 DevEvents a score of 0 is returned.
• If a Commit has not occured in more than 10 and less than 20 DevEvents a score of -10 is returned.
• If a Commit has not occured in more than 19 DevEvents a score of -20 is returned.

The idea of Commit Often is to get developers to not spend too much time on writing code and regularly making commits. So everyone involved with the project has an opportunity to work on the code.

Digging for DevEvents
The fun part of Hackystat is digging for data. In order to get extract DevEvents a little trial and error is required. I spent about a day trying to display the data from the DevEvent. However, with the implementation, the trouble I experienced was not with the API rather it was the time at which the unit test was creating DevEvents. I was passing into the makeDevTimeData method the current time thus, the DevEvents had a timestamp that is one hour ahead. Below is the correct the code snippet which creates DevEvents oneHour backwards.

int oneHour = 60;
    XMLGregorianCalendar developTime = Tstamp.incrementMinutes(Tstamp.makeTimestamp(), -oneHour);
    
    this.makeDevTimeData(owner, project, developTime, 100);

The problem with the DevEvents being created one hour ahead is the CommitOften implementation does a check one hour backwards. You can see the problem I was having with not being able to retrieve DevEvent data. The application cannot retrieve information that is not present. So I wasted a day trying to fix what was not broken. I wonder if professional developers encounter this phenomena?

Conclusion
It is nice to get my hands dirty working with a new API, troubleshooting, and resolving code issues. I have to wonder if my implementation is correct even though my unit test passes all of its tests. The team will see when the Events are actually invoked.

ICS 499: Healthcare Software and Devcathlon development

Introduction
Last week the 414 team was given real Devcathlon Events to implement. I am starting send out my resume to employers and noticed that hospitals have a need for software developers. I have no idea what health care applications look like and since I am applying to a hospital I figure I should find out what is being developed.

Health Care Applications
I know the health care system requires the storage and retrieval of patient information. So a background in databases is important and I feel confident I can apply what I learned in ICS 321(databases).
The program on the right appears to be a diagnosis application developed using the .NET framework. After doing a Google search on health care software I found a lot of companies like using .NET for application building. I suppose I should be learning the .NET framework in the near future. Without having seen source code for a health care computer application I am not sure what to expect but I am sure the programs use the same structure and syntax as any other piece of software.

Event Development
I was assigned the Commit Often Event this week. Developing the application was a little easier compared to coding the Starter Event. I could have finished the assignment a lot sooner had I applied the unit test properly. I had set the time for the makeDevTimeData method to run forward. The DevTimeData needs to be created with time set backwards. Because Commit Often has a requirement to look back one hour and look for DevTime/Commit data. I got to implement a HashSet and HashTable where the HashSet collects file names and the HashTable track the number of occurrences of a DevEvent/filename. John Ancheta implemented an overridden makeDevTimeData method allowing it to take in a file name as an argument. I was able to assure CommitOften.java was able to read more than one file.

Development Rundown

• Monday-Saturday, 3/2 - 3/7
  • Implemented CommitOften and TestCommitOften. I think I lost over 50 points for not making commits within the given number of DevEvents. However, I made up some ground by performing unit tests and verifying before making every commit. I estimate my score to be 15 points.
    
    
• Sunday 3/8: Blog work.

Engineering the Event pt II

Introduction
The class got a reprieve and got an extension on Event development. After a disastrous start, the team struggled with the Hackystat framework, which led to more review and an extra nudge to get everyone to work extra hard.

Working with the Framework
Professor Johnson mentioned in class the difficulty with working with a new framework and how he spends numerous hours reviewing documentation and tinkering with code. I was quite relieved to hear a seasoned computing expert to talk about their learning curve when learning something new. The team was given a week to go through the DailyProjectDataClient documentation and write code using the API. The challenging aspect of the assignment was not the task but trying to figure out how everything fits together. At this point in our college careers we should be able to work with a new framework in a fair amount of time. In my case I was not aggressive with writing the code and assumed that I could bang out the event in a day or two. However, it took me 4 days of actual coding to complete the assignment.
Over the course of the 4 days I hacked away trying to figure out.

• How to extract members and dev time using DevTimeDailyProjectData.
• How the bonus points get calculated.
• How a HashMap works, I used only once in an assignment for 311.
• Why didn't start on this assignment sooner.

I did complain to Professor Johnson about the Hackystat documentation being difficult to research. Because the Sensorbase, Utilities, and DailyProjectClient Javadocs are not in one document or linked together. It can be a bit of a pain if you are in the section Tstamp and you need information on DailyProjectClient API.

Digging for Data
For the event No MIAs I had to dig for data: development time and user information. I spent about a day and half using print statements to find the right code combination to extract what was needed to get the application moving.

for (int i = 0, j = timePeriod; i < timePeriod ; i++, j--) {
      try {
        DevTimeDailyProjectData devTimeDpd = 
          dpdClient.getDevTime(owner, projectName, Tstamp.incrementDays(currentTime, -j));
        
        for (MemberData dataRef : devTimeDpd.getMemberData()) {
          String user = dataRef.getMemberUri().substring(38);
          this.devTimeMap.put(user, dataRef.getDevTime().intValue());
          devTimeSum = this.devTimeMap.get(user);
          devTimeSum += devTimeSum;
        }
      }

Some notes about the code.

• Need to iterate over a given number of days. The parameters for the assignment is 3 days.
• A DevTimeDailyProjectData instance is needed to extract member data. The DevTimeDailyProjectData object is initialized by getDevTime from DailyProjectDataClient class.
• Loop through the member data, retrieve the user name, and dev time.
• Store the information into a HashMap for easy access.
• Sum up the scores.

Probably the most important snippet from NoMias.java because it retrieves the data necessary to assess if developers are spending time coding.

Conclusion
Wish I took a more aggressive approach to developing the event. I probably could have finished the assignment on time. I felt working with a new framework was challenging but not impossible. I am hopeful that I can learn other frameworks in the near future and perhaps make software engineering a career.

ICS 499: Hackystat framework and Scoreboard design

Introduction
This week was a bit of a whirlwind for me as I was learning and working with a new framework to develop events in Devcathlon. Because of time constraint I had little time to work on the Scoreboard for Devcathlon.

Hackystat Framework
The class got a reprieve with the assignment event developing seems the learning curve with the framework was steeper than originally thought. I was able to climb that hill and complete the No MIAs event.

The SensorBaseClient and DailyProjectDataClient classes are vital to access data processed by Hackystat. The DailyProjectDataClient allows a programmer to peek into Hackystat data so one can develop events. Some of the data that can be located within Hackystat.

• Development time
• Build data
• User data
  • User name
  • User email
• Commit data
• Coverage data

The fun part about working with new frameworks like the DailyProjectDataClient is trying to figure out how the information is formatted. For the No MIAs event I spent several hours examining the dev time and user name data. Because I needed to know how to set the subString method for the user name which is extracted from the Member URI. The user name is needed to keep track of the user's development time. I implemented a HashMap to store the user's name and their dev time. Through the HashMap I can track if the user put in code time or not. Using the data in the HashMap the event can be scored accordingly based on the development time.

The Scoreboard
I wanted to spent sometime working on the scoreboard for Devcathlon. Unfortunately, because my time was used to develop NoMias and TestNoMias. I did not have a chance to work on the scoreboard. Hopefully, I will have more time in the upcoming week to build a rough draft.

Development Activity

• Monday 2/23
  • Worked NoMias and TestNoMias, misinterpreted the specifications of the Event, need to fix the code and test.
  • Research using
• Tuesday 2/24
  • Worked on NoMias and TestNoMias, used the wrong class SensorbaseClient. Should use DailyProjectDataClient class to get dev time data.
• Wednesday 2/25
  • Worked on NoMias and TestNoMias, used a lot of print statements to check how the dev time and member data is accessed.
• Thursday 2/26
  • Worked on NoMias and TestNoMias, spent time working on the scoring the event.
• Friday 2/27
  • Completed NoMias, TestNoMias, and ICS 414 blog.
• Saturday 2/28
  • Fixed NoMias, cleaned up code, and added three methods to reduce clutter.
  • Worked on Devcathlon scoreboard and blog.
• Sunday 3/1
  • Complete ICS 499 blog
  • Worked on Devcathlon scoreboard.

Devcathlon: Event Implementation

Introduction
In order for scores to occur in Devcathlon an Event must be invoked by the activity of a development team. To get a feel for implementing an actual Event the team is enacting Starter Events.

Engineering the Event
My Starter Event for the week is called No MIAs which tracks the development activity of members within a team. The system is checked every 24 hours for programming activity.

• If a member of a team has not made alterations to the code within 72 hours his or her team loses 10 points.
• If all members of a team has not developed within 72 hours his or her team loses 20 points.

The point of the event is to assure everyone on the team is carrying their fair share of the project load.

Implementing this part of the system is difficult because there is a steep learning curve with coding a new framework. The complexity of the development is in finding the right combination of code to get the No MIA event to work properly. Invoking No MIAs will do the following.

• Iterate through a list of team members.
  • Using the foreach is like learning to play golf, you're not always going to hit it straight but when you do its quite satisfying.
• Check for every team member's development time against a 72 hour time period.
  • To do the time check do a calculation using the current time and the member's dev time.
• Set up a XMLGregorianCalendar instance for comparisons using the Tstamp class.

Another piece which is causing me much grief is the configuration.example.xml file. If I cannot get the script to work I will not be able execute the unit test. <DevcathlonConfiguration> Hackystat webserver stuff... <EventConfigurations> other code... </EventConfiguration> <EventConfiguration event="No MIAs"> <WakeupInterval minutes="1440"/> <BaseScoreWeight weight="1"/> <Properties> <Property key="OneMember" value="-10"/> <Property key="AllMembers" value="-20"/> <Property key="ThreeDays" value="4320"/> </Properties> </EventConfiguration> </EventConfigurations> </DevcathlonConfiguration> According to the stack dump the OneMember property cannot be found, I do not understand because the getProperty method takes in the oneMemberKey String, which holds the "OneMember" property.

public NoMias() throws EventException {
    super(eventName);
    try {
      this.oneMember = Integer.parseInt(configManager.getProperty(eventName, oneMemberKey));
      this.allMembers = Integer.parseInt(configManager.getProperty(eventName, allMembersKey));
      this.threeDays = Integer.parseInt(configManager.getProperty(eventName, threeDayKey));
    }

Not sure how to resolve issue at this point because I can't locate the cause of the failure.

Edited on February 25, 2009
Found what was causing the error with the unit test. I improperly set up the properties for the configuration.example.xml file. Now I can move on with the unit test.

    configManager.addProperty(eventName, "OneMember", String.valueOf(oneMember));
    configManager.addProperty(eventName, "AllMembers", String.valueOf(allMembers));
    configManager.addProperty(eventName, "ThreeDays", String.valueOf(threeDays));

Screencasts
The screencasts are great! When I was going over the Hackystat API for this assignment I was using the screencast to review content that needed clarification. If students are sadly mistaken if they think they can miss class because the lecture will be available online. Professor Johnson enjoys giving quickie quizzes instead of taking attendance.

Conclusion
Good and challenging assignment, I need another day to finish this assignment, also I need to solve the issue with the property key from the configuration.example.xml file. Once I fix the problem I can perform the unit test and clear the Event from the issue board.

ICS 499: Devcathlon Event implementation and Scoreboard design

Introduction
For the week of February 16 to 22, ICS 414 continues with the development of Devcathlon, get exposure to Yahoo YUI and JavaScript for working with dynamic pages.

Event Building
The team is getting an introduction to Event building this week and developing Starter Events which will eventually turn into actual Devcathlon Events. To help the team with the development of the Events. Professor Johnson created helper classes to get the team acquainted with developing Event code. I think the code for the Events is straightforward, nothing overly complicated, just a matter of sitting down and working with the API.

For NoMias, the class needs to retrieve the following data.

• Track down the project, team, and team owner.
• Within the team data, iterate through each team member, and extract the development time.
• Retrieve the current time and compare it against each member's dev time.
• If a member has not coded within 24 hours deduct 10 points from his or her team. If a member has not coded within 72 hours deduct 20 points from team his or her team.

Seems fairly easy the only hard part that I see is to extract each team member's development time data.

Scoreboard Design
I think Devcathlon should have a cool scoreboard something that looks like Yahoo's GameChannel which tracks live sporting events. To design something like the image on the right requires the learning of Yahoo YUI and AJAX. In order to accomplish the cool scoreboard I am going to take on Yahoo YUI and AJAX so Devcathlon players will have something groovy to track their scores.

The scoreboard should have been part of the mockup phase however, I unsure if it was something that could be coded. After researching Yahoo YUI I feel confident that it is something that could be implemented into Devcathlon and look forward to challenge.

My interest of Yahoo YUI was sparked by Robin Raqueno who was working on the progress bar for Devcathlon. I wanted to know how to get dynamic elements functioning in Devcathlon. I have yet to implement code using Yahoo YUI because I am going through the Starter Event development. I hope to get something up and running next week. During my research I found several advantages of Yahoo YUI.

• Open source.
• Portability across most web browsers.
• Well documented.

Development
For the past two blogs I used a table to show the time I spent working on elements for ICS 414 and 499. In this week's blog I will do a daily summary of topics I researched and coded. That way Professor Johnson can get a better feel for what I am doing with my time rather than just posting my development hours.

• Monday 2/16
  • Edited ICS 499 blog to make it presentable. Worked on Hackystat implementation assignment, should have made a stronger effort having difficulty sorting through the API.
• Tuesday 2/17
  • Worked on ICS 414 blog and Hackystat implementation assignment. Got Task1 to work however, running out of time to get Task2 to operate.
• Wednesday 2/18
  • Start work on Event implementation assignment: logged myself into Hackystat for the Devcathlon project and took ownership of the "No MIA" event.
  • Start ICS 499 blog, within the process of writing the blog I am also learning more html by working with dates and lists.
  • Started research on Yahoo YUI.
• Thursday 2/19
  • Continue work on the Event Implementation assignment: Researching KeepTheCoverageHigh and TestKeepTheCoverageHigh, starting to code NoMias and TestNoMias.
  • Continue research on Yahoo YUI.
• Friday 2/20
  • Continue work on the Event Implementation assignment: Researching KeepTheCoverageHigh and TestKeepTheCoverageHigh, continue coding NoMias, added more properties to the configurationexample.xml.
• Saturday 2/21
  • Continue work on NoMias and TestNoMias, its slow going, trying to fully understand what each method is doing.
  • Continue work on ICS 414 and 499 blogs.
• Sunday 2/22
  • Continue work on NoMias and TestNoMias.
  • Continue work on ICS 499 blog.

Devcathlon: Interfacing the System to Hackystat

Introduction
Devcathlon is still in its shell state the development cannot move forward without a mechanism to track scoring. Devcathlon must be integrated with the Hackystat system in order for points to be distributed.

The Code
Task1

Working with Hackystat
In Devcathlon, the point system is dictated by events performed by software developers. Scores are earned or taken away when a programmer performs an action within the events list. To track a developer's efforts Devcathlon must have an interface that connects with Hackystat. The Hackystat system is well documented and contains several APIs to help retrieve data.

Implementing the APIs is the easy part trying to figure out where to find the class or method was the difficult part. Hackystat has numerous classes that I am unfamiliar with and required many hours of research to understand how each component works.

    String host = "http://dasha.ics.hawaii.edu:9876/sensorbase";
    
    SensorBaseClient.isHost(host);
    
    //to login
    SensorShellProperties sensorProperties= new SensorShellProperties();
    String userId = sensorProperties.getSensorBaseUser();
    String userPassword = sensorProperties.getSensorBasePassword();
    
    //need a client
    SensorBaseClient sensorClient = new SensorBaseClient(host, userId, userPassword);
    
    sensorClient.authenticate();

The above code sets up application for logging into the system. Notice the sensorProperties object which accesses a .properties file which holds user information. Eliminating the need to hard code data into the program.

    MultiDayProjectSummary summaryIndex = 
      sensorClient.getMonthProjectSummary(userId, myProject, 2008, 11);

The code sets up a MultiDayProjectSummary object and takes in a summary of data from November 2008.

  logged in...

  01-Nov-2008 0
  02-Nov-2008 0
  03-Nov-2008 0
  04-Nov-2008 110
  05-Nov-2008 87
  06-Nov-2008 0

A snapshot of the output from HackystatOne.java.

Screencasts
Professor Johnson added a new feature to class lectures utilizing a program that records his desktop and webcam at the same time. The a few nice things about using screencasts for lecture purposes.

• Nothing in the lecture will be missed.
• The lecture can be reviewed at a later date.
• No need to bother the professor about items in the lecture.

There maybe a downside to using the screencast for lecturing but I think the benefits outweigh the negatives.

Conclusions
The APIs for the Hackystat system will be useful when the team starts to develop the Devcathlon Events. All of the necessary classes and packages will be at our finger tips to collect Hackystat sensor data. The sensor data is the lifeblood of Devcathlon the information from Hackystat will be used for the all important scoring mechanism. Without the point system, Devcathlon will be one boring game.

ICS499: Collecting Raw Hackystat Data

Introduction
In order for Devcathlon to be an entertaining game actions of a player and/or team needs to have a score kept. In order to have an accumulation or loss of points Devcathlon needs to receive data from Hackystat. The Hackystat system has a series of Java APIs that helps with the retrieval of raw Hackystat data.

Devcathlon and Hackystat Data
A key component to Devcathlon and probably the whole point to the game is the collection of Hackystat sensor data. Hackystat data is the key mechanism for the automated events in Devcathlon. Through the Hackystat system, software engineering elements such as development time, committing clean build, and keeping coverage high will be tracked for scoring purposes. The Devcathlon development team will build an interface to retrieve sensor data and use the info to tracks scores of Devcathlon Events.

To assist the team Hackystat has a series of APIs to help build the interface. The Hackystat-sensorbase contains numerous classes that when implemented will collect sensor data. As an assignment I need to collect data from a specific date and display the number of times sensor data was sent for each day. I found everything I needed for the assignment in the Sensorbase and Sensor Utilities APIs. I found the APIs flexible where I could get a on handle dates, type of sensor data, and just about anything else within the Hackystat System.

As of this writing I am still working on the code and have only snippets to show. Also, the code is not very exciting its just a main method with a bunch of invocations to collect data.

  SensorBaseClient sensorClient = new SensorBaseClient(host, userId, userPassword);
  sensorClient.authenticate();
  
  String myProject = "Default";
  
  String firstDate = "30-Nov-2008";
  
  XMLGregorianCalendar endTime = Tstamp.makeTimestamp(Day.getInstance(firstDate));
  XMLGregorianCalendar startTime = Tstamp.incrementDays(endTime, -2);

  SensorDataIndex sensorIndex = 
      sensorClient.getProjectSensorData(userId, myProject, startTime, endTime);

The above code logs into the Hackystat system and calls on a date and project.

My only gripe with the Hackystat APIs is sorting through all of the classes. I was a little impatient with having to track down what I needed to know. For example, while researching the Tstamp class I wanted to know if I could pass in a Date instance as an argument. Instead I found another a class called Day which required more research. Of course I found what I needed and was able to retrive the date from Hackystat. I guess its part of the learning process of working with a new API and/or system.

Development Time

	Feb 10	Feb 11	Feb 12	Feb 13	Feb 14	Feb 15	Feb 16
Research Time	0.5	1.0	1.5	1.5	1.0	1.0	0.0
Code Time	n/a	0.5	1.0	0.0	1.0	3.0	2.0
Blog Time	0.5	0.5	1.0	0.5	0.5	2.5	1.0

Conclusion
Learning a new API takes time to do the research and experiment with the code. I remember an instructor telling me that the actual writing of code is only 10% of the development process. The latest assignment is a good example of research time outweighing coding time.

Devcathlon: System Recommendation My 2 Cents

Introduction
The mockup portion of Devcathlon is completed the system thus far has gone through peer reviews. UI recommendations will be made by everyone in the class and we will then proceed to the implementation of the code.

The System so far
Devcathlon is a mere shell right now made up of CSS and HTML script. So from a functionality the system does not do anything significant except link to other pages. The class was divided into three groups with each team responsible for creating their own mockup. All three teams have chosen a social networking type of apperance that should be familiar to anyone who has a Myspace or Facebook page.
Each team came up with good ideas and cool features for the game.

• Mockup4: Anthony Du, John Ly, Robin Raqueno laid out a decent badge system and a neat solution to showing a player's score and team information which I will talk about in my recommendations.

• Mockup5: Aric West, John Zhou, Scheller Sanchez nice scoreboard.

• Mockup6: John Ancheta, Daniel Arakaki, Phillip Lau came up a cool level scheme employing a military type system where players earn their "stripes" from earning so many badges. I will recommend a different type promotion system where moving up in level will require point production. Mockup6 team also designed a game adminstration element for Devcathlon called Game Master where an administrator can control the scoring mechanism, badge and level promotion or demotion.
  

My Recommendations
Devcathlon should move ahead and implement the system with the social network appearance. The design will appeal to a large audience and the class seems to have embraced the layout. The implementation from mockup6 which integrates Hackystat ProjectBrowser with Devcathlon is a clever approach in keeping the two systems tightly bound. However, building Devcathlon into Hackystat will be a process which requires a lot of time and thought. The team is restricted by the time aspect with twelve weeks left in the semester. The team should implement the following items from the mockups.

• The badge hierarchy and drop down design from mockup4 with some modifications to the drop down design to make it more intuitive for the player.

• The military style level system and game master from mockup6. Using a points methodology for players to get promoted in level should be considered.

• The gallery and scoreboard from mockup5 with modifications done to the gallery and scoreboard for organizational purposes.
  

Whats Next
Implementation of Java code and communications: email and Twitter. The class used Wicket to tie Java and HTML together I expect to use Wicket again for Devcathlon.

Expected issues
I am concerned with how we are going to get the data from Hackystat to communicate with Devcathlon. Another thorn in my side is JavaMail because we do not have a dedicated SMTP server we are going to have issues with sending messages out. Aside from my concerns I think we have good group this semester and Devcathlon will be a entertaining and interesting system.

Devcathlon: Review of Mockup6

Introduction
the mockup6 team is : John Ancheta, Daniel Arakaki, and Phillip Lau we did two designs one that follows mockup2 and a new design that integrates the Hackystat ProjectBrowser see on the left and Devcathlon. However, I will only talk about the mockup system Professor Johnson was hesitant with moving forward with the integrated system because of issues with interfacing with the Hackystat server.

The Mockup
The click ratio to perform a task seems to be in the 2 t0 3 click range. The pages could use more information because not everything in Devcathlon is intuitive. Although a well thought out design should make all pages and functions intuitive. If a page requires scrolling all it takes the user is one click to reach the bottom half of the page. The only problem would be the player profile but that page may not make it into the build. There was an effort to keep the design as consistent as possible. However, because there were 3 different developers there is slight deviation with each page but the overall look is uniform. The input mechanisms do not work, I guess the consensus was since this was a mockup the data forms did not need to function.

Strengths and Weaknesses
Badge and level hierarchy makes sense, should give the players a reason to have fun with the system. I can see players getting into the level system where they will work hard to get their next rank. There could be some bragging going on where developers will start showing their "stripes". I think with a little bit of work with the format the player profile page could be cool and fun for the players. The displaying of the badge and levels will be like a Myspace page.

Even the project manager or professor can get in on the fun with the Game Master function. The person in charge of development will be able get into the action by promoting or demoting developers and taking or giving away badges. I think the awarding of badge and levels still needs to worked out and there be a consensus as to how players get their rewards. In my opinion level promotion is based on points and at the discretion of the Game Master. The badges should be awarded based on achievement and again at the discretion of the Game Master.


The Gallery (seen on the left) was a left over mockup2 but it looks cluttered and unorganized not sure if we should implement it or make a modification. Because I think a scoreboard can do same function but with the scoreboard we should keep things tidy until the user decides to open up graphs and logs. For the scoreboard we should use mockup4's design because our design (seen below) seems rather plain in comparison.

Conclusion
I thought our group did some good work I was paticualrly impressed with John's idea of integrating Hackystat with Devcathlon. However, complications with integration nixed that idea but I think Professor Johnson should investigate integration of Devcathlon and Hackystat for a future project. So kudos to John with all his hard work with his integration idea and to Phillip for the design of the badges/levels.

Devcatlon: Review of mockup5

Introduction
This a review of mockup5: Aric West, John Zhou, and Scheller Sanchez who did the same thing as mockup4 and mockup6, took mockup2's system and modified the interface adding their levels and badges.

The Mockup
The tabs for mockup5 link to almost all of the necessary pages. Could not find a link to their levels page and it had to be opened outside of the interface.


Navigating through mockup5 was easy and did not require too many clicks to move from one page to the next. With exception to the player registration and Gallery all other pages make good use of the screen with a couple of pages requiring one click to page down. Most of the pages are fit well in the aesthetic sense. The organization of the mockup5's layout does not deviate each page fits and makes sense. The structure is similar to the systems in mockup4 and mockup6 so the user interface does make sense and has an order which is not confusing. Like the input mechanisms in mockup4 and mockup6 none of the forms in mockup5 take in data. Because there is no database I am guessing all of the groups chose to not have functional forms.

Strengths and Weaknesses
I do not see anything that is particular outstanding out in mockup5's system when compared to other user interfaces built by the other teams. However there are several items I think should be included into Devcathlon. There is a run down score of matches similar to a scoreboard from a sports website(seen on the left). With a little more work in making the text more readable by giving it a little more "pop" I think this will be a fine addition to Devcathlon. With regards to the levels it is not as interesting as the level system proposed by mockup4 and mockup6.

While the cat badges are cute(seen below), in my opinion I'm not sure if it will be appealing to the average player. Seeing how the majority of students in the department are guys.


Conclusion
The pages look similar to the mockup2 system and it seems like nothing new was added to the mockup.

Devcathlon: Review of mockup4

Introduction
This is a review of mockup4 the team Anthony Du, John Ly, and Robin Raqueno who did some cool things with their portion of the user interface for Devcathlon.

The Mockup
It looks like all of the teams chose the current look of the webpage. The design is similar to the player profile page for XBox's online system.


The user should have no problem navigating around mockup4's system. There are tabs that link all the pages together so there is no need to hit the back button.
One issue I have is with some of the navigation tabs like the My Profile tab which also contains a drop down menu. I understand the placement of the menu because Edit Profile, My Teams, My Matches fall into the My Profile category. However, the combination of a navigation tab and drop down list may confuse the user. One possible solution would be to create another tab/menu. Team Mockup4 did a really nice job with some of the additional features with their design. However, certain features may not be intuitive and will probably require a user to go searching for a desired task or information.


For example the My Teams page serves as a listing that points out which teams the player is participating in, listing teammates, team name, and scores. Team mockup4 added a nice feature where a user clicks on the gray bar and reveals the team's information.

Overall mockup4 makes decent use of screen space although the player profile page requires 3 clicks to reach the end of the page. After reviewing all the mockups it seems no one made changes to the profile page and maybe eliminated as we enter the build phase. The architecture laid out by mockup4 makes sense and is intuitive however, the system was borrowed from mockup2 so the layout was already in place. None of the input mechanisms work, nothing happens to data after typing it in and submitting. However, none of the other mockups had working input forms.

Strengths and Weaknesses
The badge system was well thought out it uses a point scoring system to award players. I especially the Larry O'Brien trophy from the NBA. I think most players of Devcathlon will identify with the badges. With mockup4 new badges will not be displayed until a player has enough points to earn the achievement. I thought the drop down menus for team pages was cool and a nice way to present the information. I would like to see an icon that points out the menu drops down. Because in its current state the reveal is not intuitive. Mockup4's architecture is well laid out all of the links are organized. I think we should go ahead, use their design, and add the other pieces to their system. Certain pages like the team information page could use more information to guide the user.


The level hierarchy page needs a little information however, I doubt we will implement the level system into Devcathlon. Because there is a sensitivity issue with the design and it maybe insulting to other professions.

The My Profile navigation tab needs to broken up because it seems confusing in my opinion. It could cause a user to miss click and navigate to the wrong page.

Conclusion
Anthony Du, John Ly, and Robin Raqueno did nice work on mockup4. The team should go and implement mockup4's badge system and drop down menu for the team information. In fact we should figure out what other pages could use a reveal.