Devcathlon 1st Milestone: Mockups

Premise:
I'll be expressing my feelings for this first increment of Devcathlon and the status of the project. The difference between this entry and my past entries regarding Devcathlon is that this time we are really going full speed on this application. My colleagues and I only have a span of 6 weeks left to accomplish what would seem like a prototype for Devcathlon 1.0. Here, I will also list my workings on the profile management section and my experiences being a co-coordinator for this project.

Devcathlon Project Hierarchy:
Each section consists of 4 members, including a designated team leader.
User & Team Management - user profile and team management sections.
Matches & Scoreboard - team matches and scoreboard management sections.

TeamUT - User and Team Management:
Since Wednesday, I was assigned as project leader of the user profile and team management sections for our web application. The profile management section will be responsible for providing personal and account details of a user. This section contains the user's home page, when they first sign in, easy links to edit personal and profile information, upload an image (avatar) and ways to manage teams and view related matches.
Planning and accomplishments...
Since we were placed in groups of four, I decided to split my team in half and assign each to either the user or team management section. Scheller Sanchez and I were responsible for the user profile management section. While John Ly and Philip Lau were assigned to the team management portion. I devised a shared Google doc that serves as a task summary of all involving elements for our user and team management. Of course our tasks and issues will be managed through Google's issue tracker, but this gives a hard copy evidence of our work. It's also backed with version control and makes for a very beneficial asset to our team collaboration.
Here's a quick summary of each individual's tasks taken from Google's issue tracker:

Profile Management (../hackystat/devcathlon/ui/page/profile)
Anthony Du:
Profile menu (started) ~mockup completed in r399
Profile submenu links (done) ~ completed in r391
Profile submenus: manage and browse (started)
Scheller Sanchez:
Added wicket ids for profile menu page (started)
Profile submenu: commentary (accepted)

Team Management (../hackstat/devcathlon/ui/page/team)
Phillip Lau:
Initial Team Main menu (done)
Initial Team Browse page (done)
Populate Team Main (new)
Populate Team Browse (new)
John Ly:
Add mockup of manage team submenu (done)
add mockup of teams invitations submenu (done)
implement creating team form (accepted)
implement team invitation (accepted)

We met up twice within the first week, the first day and eventually once on Friday. We also met online on several occasions and had two official group chat sessions involving everyone. This proved to be quite beneficial for keeping team members in check, draw new ideas, express opinions, concerns and debug issues. Conducting these meetings weren't difficult and everyone was very willing to cooperate from the start. I gave my team members lots of flexibility, due to everyone's personal schedules in order to work on their parts. I also sent out frequent reminders of opened issues and chat sessions going on. This team from the start seemed to be very self-motivated and easy going. I had a great time contributing all I can to my team members, as well as reciprocating that relationship through this learning process.

ICU does not see me...
One of my team members notified me that Hackystat wasn't picking up on my data telemetry through sensorbase. This is quite unfortunate and I needed to attend to the matter quickly, except it seemed that Eclipse's Preference menu had gotten rid of the Hackystat Sensor. This totally got me confused. So I attempted to reinstall the plugin by copying the jar from the hackystat.sensor.eclipse folder to the eclipse/plugins directory, but nothing worked. Hopefully I'll resolve this before our next increment. As of right now, I'm coding anonymously for Devcathlon...

Loose design process...
I know that we've all been here before with designing a mockup for a website on a text editor, or paper and pencil. This process should indeed be very quick and fast with all sketches being simple and straight to the point. What I've noticed so far in this project is that we've been stressing too much about the placement of things, rather than the functional aspects of our web application. Of course a web application's looks are 90% of the user's experience, but we haven't had a decent amount of time spent on the class design itself. I might be a bit harsh, since this is our "first milestone," but some people are really missing the point on what needs to get done. Generally stated, sometimes "less is more." So I think in our first increment, we should follow a semi-"loose" design in our mockups. Since a lot of these form elements are dynamic and can be changed ever so often, they need not to be overworked into our mockups. For example, a simple div tag can serve as a placeholder for an image or any other element. As for those elements that contain multiples, they can be done once and left alone. We don't need to exercise the fact that we can copy and paste with our mouse, instead seeing that one row is working is quite sufficient enough.

Concerns...
Wicket is still fairly new to most people and I don't know how much REAL experience anyone has had with it yet, but it shows very much in this application that we really need to start reading up on the basics of building a Wicket application. I'm pretty sure that we can code in Java, but can we code in Wicket? Wicket has only received 3 books published and they all have great introductions. I would recommend "Wicket In Action" as a great resource to building and deploying Wicket applications. The first and foremost understanding of Wicket's framework would be highly beneficial. We must understand the MVC structure and how Wicket distinguishes itself from other frameworks through separation of views and code. This separation greatly helps us focus on our programming without having to deal with heavy html markup. I would like to see that we plan out a class design of what needs to be implemented without Wicket first. For example, the UserProfile.java and not the UserProfilePage.java/html. Next we can focus on attaching these abstractions to our page components.

Conclusion:
In this first increment, we were mostly concerned about the markup html of Devcathlon. I hope this experience has given us all sufficient time in experimenting with the possibilities of using CSS in html and incorporating simple label elements through Wicket. There will be more interesting things to come when our team starts to dive into the workings of Devcathlon. Hopefully all of our previous preparations will help this applicaion flourish into success.

CSS - Wicket Menu bars

Premise: To get re-acquainted with Wicket and CSS, and to become familiar with an implementation of menu bars for the Devcathlon project.
To follow along with this entry, I'm assuming that you are familiar with Wicket. You may checkout a read-only copy of ics-wicket-example-5 from here. There you will also find previous introductory examples to Wicket and various easy to access links to required libraries for Wicket.

Dissecting CSS of "menu.css"
1. Set list item tab as active:

body.section-1 #menu li#nav-1 a, ... { background: white; ... }

2. Hide inactive sub navigation links:

#menu #subnav-1 { display: none; ... }

3. Left-justified unordered sub navigation list:

body.section-1 #menu ul#subnav-1 { display: inline ... }

4. Set sub navigation list tab as active:

body.section-1 #menu ul#subnav-1 a { background: white; border: none ... }

Add new entries to the Wicket menu bar
BasePage.java:
1. Create third menu and include 10 more sub menus beneath it.

add(new Link("Menu3Link") { public void onClick() { setResponsePage(new Menu3Page())}});

2. Add sub menu links

add(new Link("SubMenu5Link") { public void onClick() { setResponsePage(new SubMenu5Link())}});

Modifying CSS attributes via Wicket
One of my collegues from class suggested using a "get" resource request to retrieve the resource link, then modifying its CSS class attribute with the following code:

get("menuLink").add(new SimpleAttributeModifier("attribute", "value"));

This code does exactly what its intended to do, but after looking over the Wicket 1.3.x API's, I found this interesting bold text in all caps, "THIS METHOD IS NOT PART OF THE WICKET PUBLIC API. DO NOT USE IT. " This was to address the "get" method which is documented here. So I did a quick Google search and came across this posting which, if applied, should have the same effect. Here's the code if it were applied to this CSS experiment in file Menu1Page.java

... WebMarkupContainer menuLink = new WebMarketContainer("Menu1Link");
menuLink.add(new AttributeModifier("class", new Model("selected")));
addOrReplace(menuLink); ...

Note: Entire code segments are included within the distribution file below.

Conclusion: Although this experiment was fairly short, the CSS and Wicket refresher will be duly noted.

Distribution file: wicket-example05-1.0.318.zip

[ICS 499] Planning

Premise:
This entry is a continuation of the long awaited plan of what my thoughts are on building my custom BMXNet component in Java. I took forth this project to provide higher-level interoperability between serviced applications for RPMS’s electronic health records system. I will review the facts regarding the tools and intention of this project, but further details regarding the background of IHS's RPMS can be found in my previous post, here.

A quick re-interation:
Why use BMXNet? Just a refresher, BMXNet is a subset of tools provided by RPMS that enables .NET applications to exchange data via standard ADO.Net data tables. At this point in time RPMS only supports Windows applications written in the .Net 2.0 framework. My goal is to expand this by adding other supportive data providers across multiple platform environments for RPMS to communicate with.

Requirements:
* Installation of InterSystem's Cache on a Windows operating system.
* Net 2.0 framework.
* BMXNet20.dll – handles the conversion between BMXNet to the .Net framework.

Tools:
* Eclipse IDE ~3.4
* Microsoft Visual Studio

The Plan:
Finding a home...
The crowd approval of a project is somewhat difficult to obtain but it isn't hard to include a new project within the neighborhood of other potentials.
Create an open source project using Google's project hosting.
* Place an introduction and produce a good subset of examples supporting the proposal.
* Mention about involving companies or schools.
* Licensing: Since this project is somewhat in its dwarf stages, I'll attach an ordinary GPL to it. Perhaps in the future we will do a dual licensing and reciprocal term.
Benefits of using Google’s project hosting:
* Supports version control, easy navigation or browsing of code, connects well with other Google components, such as Google’s discussion groups, etc.
Other source code management (SCM) option(s):
* What about Github? Due to Git’s full-repository cloning, fast and easy branching and merging of repos, more software developers are seeking it out as an alternative SCM to Subversion. Github combines the goodness of a powerful SCM and ships with the abundance of collaborative software (Campfire & Lighthouse) to help developers stay focus and aware of their community involvements.

Putting BMXNet on the chopping block…
BMXNet details:
Below are three different ways to retrieve data from [M]umps FileMan utility. Each will be the focus of my application as I recreate these components using Java.

  Custom Remote Procedure Calls (RPC’s) returned from BMXNet’s M utilities. RPC routines in M are categorized into two record schemas, minimal and full.
  Schema Record Structure
  Minimal Schema - contains enough information in the RPC for a read-only ADO.Net Data Table.
  Full Schema – contains sufficient metadata for a fully updatable Data Table via BMXNet ADO SS.
  Record Delimiters
  Field separations with ‘^’
  ASCII 30 for End-Of-Record (EOR) & ASCII 31 for End-Of-File (EOF).
  All schema structures are stored in the BMX ADO SCHEMA file.
  SQL-like calls. Rather than having to create custom RPC’s in the M language, BMXNet supports quick retrieval of any read-only DataTable easily through familiar SQL statements.  
  BMX ADO SS.
Simplifies calls by generalizing RPC routines written in M
  Generates an updatable DataTable

Understand Java and RPMS's Networking capabilities:
Java is the first major programming language to be built from the ground up with networking in mind. It has built-in supportive classes to enable Java applications with networking capabilities to easily communicate across the Internet. This task pertains to the first phase of this project and is certainly a vital prerequisite for this application. I'll be focusing on the first phase within the next day or two. Here's a quick outline of what's to come:

Phase I: Communication
* Create a simple Java client to test connecting to Cache's RPMS server environment.
- Use basic TCP/IP socket connections
- Test sending and retrieving data packets
* Accomplish bi-directional relationship

Phase II: Building Custom RPCs
* Learn to create custom RPCs from RPMS
* Learn to invoke custom RPCs from within my custom data provider in Java.

Phase III: Provide SQL support
* Learn about Java Persistence API

Phase IV: Creating Updatable Data Tables
...TBD

Devcathlon Event Implementation

Premise:
This past week I teamed up with one of my colleagues to implement an event for our semester project, called Devcathlon. We were in charge of developing the CollectiveOwnership event which entails the following:
Reward developers for ensuring that most files are worked on by multiple developers for a certain number of time.

Process:
My colleague and I had very ample time to work on this event. Given the prior experience with working on our mock events, we were semi-comfortable with the Hackystat APIs. Fortunately enough we had a very distinct plan from day one and that was to finish early. A lot of the code was taken from the same context as our starter events. Eventually those same concepts, such as calling to the remote hosting server, retrieving data from the host, specifying sensor data types, and sending data to our test server became second nature to us. I also corrected myself during many instances while building this event. One of my main difficulties was understanding what was was being accepted by Hackystat as valid input and what was being spit back. I was a bit trapped by this and had to resort to some old debugging techniques that may seem out of style in today's standards, but worked out just fine for certain situations. In many of our preliminary test cases, we did various "System.out.println..." to see if the accepted values were generated correctly by our black box (Hackystat). Yes, I basically thought of Hackystat as a big "black box." Although the code is open source and can easily be read from Google's browsing tool, I was compelled to see how much can be inferred from the details of the Javadocs without digging through code manually. However, in one instance my colleague found a code section for determining a user's developing time by a simple class called DevTimeCounter. The name is quite obvious and it simply did what it needed to do flawlessly. This incredible, yet hard to find class simplified the code even further from what we had started out with. We also ran into a little difficulty in building test cases, so my colleague expanded the DevcathlonHelper class method for making dev time, by adding the ability to specify a file name the user or owner has been working on. This helper was a necessary change to the test helper methods and it greatly came in handy for what we needed to test out in our event.

Conclusion:
The experience was very rewarding, since I became more familiar with the Hackystat API and much more comfortable building Devcathlon events. Although we hit some road blocks along the way, they were minor and worth noting for future reference. Considering the rate at which we are going, we should be on our way with getting some kind of GUI for our application soon.