Anthony on Software

[GSoC09] Devcathlon & GSoC

2009-08-24T04:22:00.000-07:00

Reflecting on GSoC
The summer has ended for most of us and I'm glad to say that lots of progress has been made since my last entry. Devcathlon has given me lots of ups and downs in the past week. After successfully building the system with a persistent layer using Hibernate, many items such as the UI and game functionality still needed to be dealt with. Although not all objectives were accomplished in the last iteration of Devcathlon, I did have a chance to touch face with many of the issues that will need to be resolved in the next upcoming release of Devcathlon. They seem minor but can sometimes prove to be quite tedious and lots of code digging. This summer's venture has been the most time consuming, yet an overall rewarding experience. I felt that this program has given me greater insight into what development is in a larger based environment. The project at times could get very lonesome, though I did find ways to get motivated again. Many long afternoons and late nights have given me a real appreciation for time. During the last week of GSoC, I granted myself "time" to dedicate myself to the last moments of Devcathlon for this summer. It was difficult since my coding was usually compressed into one weekend which consisted of two days and a lot of distractions. The difficulty of clearing my mind from one project to the other proved to push me to my limitations. Something had to give; so I gave my last focus this summer to Devcathlon (I know it should have been my first and foremost focus). I know that it's too late to turn back the clock, but I've learned a valuable lesson and something about myself along the way.
Devcathlon's beginnings
The starting of Devcathlon was a very hodgepodge of wicked Wicket fun. People were still getting used to the framework's concept of MVC and Wicket's flexibility and support of components. The building blocks of Devcathlon centered around exploring these new grounds. I felt that this Summer was to pay homage to what I've learned from using Wicket and my previous encounters with other frameworks. I did incorporate changes to the workings of the profile and team sections, but others were left out due to time constraints. Using models is a must in the MVC framework. And using them correctly shows that you really know your stuff. I had to spending many moments re-reading the chapter on models and detachable models. They are very important in the development process and I wished it had been used more frequently in Devcathlon's 1.0 release. Also reusing views and controller functions ensure that you are also being DRY. I could see that some of those concepts were being injected late into Devcathlon, but others were still very traditional. I honestly saved what I could, and some were forgiven.
Working with Devcathlon
When getting along with an existing system (like Devcathlon) which had multiple people before you developing; you tend to see bits and pieces of the puzzle that fit together. Once you fit those pieces together then the next piece becomes a search. I felt that many of the things I didn't understand from the beginning was an inevitable search to find that missing link. After a while I got used to seeing the patterns people made in their code and what they would often do. I would also tend to have my opinions on certain paths people took when coding. I can't say that Devcathlon was entirely me, because it isn't. For this reason, it was difficult to make hasty changes to the code base. I wanted to respect the code done before me even though some things could have been done better and much more efficiently. I'll suggest some later, but the point is that Devcathlon had a personality to it as do any open source project out there. I've begun to notice how difficult it is for teams to collaborate and come to terms with what is standard.

Technical Review of Devcathlon (pre v2.0)
If you've got a class (model) then use it!
There are many instances when creating a form that I would see no models ever being used. Variables that can be easily referenced using the binding of an existing class model would have relieved the purpose of recreating them again in the form class.
Panels are great, but don't go overboard!
Following the DRY concept, one could really go overboard into drilling everything down to a label component is reusable and can be turned into a panel. Unfortunately this could lead to unnecessary growth of files which would make it much harder to manage. Just know that things can always be re-factored eventually after knowing that they are needed in more than one place.
Keep our styles clean yet explicit.
CSS files were all over the place and some still are and will need to be removed. A little helpful note on what the style pertains to would give nice clues as to where to find it in the markup. I found this to be difficult when certain styles were overriding others. Please make up you mind!

Find the project, here along with all the main updates: http://code.google.com/p/hackystat-ui-devcathlon/

Closing thoughts
The overall experience was quite a journey from start to finish. I had an absolute pleasant time, keeping my mind busy this Summer. Hopefully as school starts my mind will start to cool off... NOT! ;)
Also many thanks to my mentors who tried desparately to help motivate me and to keep me on track. Apologies to anyone I may have offended during the course of this Summer (I meant every word). And I wish the best of luck to future GSoCers.
Long live the code and tradition! Cheers!

[GSoC09] Overcoming a hurdle

2009-08-12T01:48:00.000-07:00

If you were wondering why I haven't been blogging lately, then it's because I hit a "wall." I thought after taking the first few blocks off I would be free of trouble, another layer gets built, but only stronger and thicker than the last. I have to say that this project, in addition to this summer's workload has had a profound impact on my performance as a programmer. I've essentially realized my limits and as usual would draw insight from these experiences.
So I cleared my head this past week and started to extract what I had done on the branch copy (for db development) and slowly transitioned to the main interface in the trunk of our repository.

Below are some notes for myself and to future developers of Devcathlon:
Issues building a DB with a pre-existing system designed by multiple users:
These are the issues I ran into with Devcathlon that seemed to really give me the most problems.
The integrity of our DB:
There were many places in the application where (when we would test) that checks were made by the DB and not by the application before hand. This was mainly due to how DevcathlonTestHelper was built, to create and immediate delete a record, without concerning itself with other dependent constraints. In some instances, this would occur while testing team resignations which required two teams with a user being the team owner of one team and a member of the other. So by deleting one of the teams, this would cause a constraint error which is totally valid but not handled by our initial test helpers. Modifications were needed in this area.
*A special note on a test db: It would be beneficial to setup a Devcathlon test db for creating and dropping tables while developing in Devcathlon. This would keep your tests cleaner and ensures the integrity of all records.
In addition to changes to the DevcathlonTestHelper, the DevcathlonConfiguration needed to be initialized for all events defined in the configuration.xml file. This was needed in order for all event subclasses to properly map with the abstract event class upon declaring any particular event. Errors would occur when an event was not initialized by the ConfigurationManager.
The other problem relied on the fact that certain classes needed to be mapped (mirrored) that were originally built via JAXB. I.e.: The Project JAXB generated class needed to be mirrored in Devcathlon and renamed as TeamProject for persistence.

Thankfully seeing the "BUILD SUCCESSFUL" message (noted @ 5:45am this morning) appear after running 'ant -f verify...,' I finally felt a large weight lifted off of me. I'm now happy to know that the DB is settled and I'll be able to sleep better tonight.

This week:
Test events and single matches (08/19-20)
Work on UI improvements (08/19-21)
Clean-up old wicket panels (08/19-21)
Documentation: Installation & Issue notes (08/22)

[GSoC09] Devcathlon UI and other random thoughts

2009-07-12T22:20:00.000-07:00

Past week:
This week was more targeted in testing and running Devcathlon's game events. I got a chance to look over a few of the events as well as make improvements to the user interface. I honestly had more fun with the UI, since it gave me the chance to be creative. Also this past week was mostly angled towards packaging for GSoC's mid-term release.

UI Improvements:
The first time you visit Devcathlon, you are presented a functional, yet not very pleasing UI that included a conglomerate of panels and links that semi-worked correctly. I decided that if I needed to start somewhere, then it had to be this very initial page. From here, I devised a new scoreboard, that updates frequently as the visitor sits back and watches things change on screen. It's more dynamic, much more intuitive and incredibly fun to look at.
In the process of creating this component, there are some things that were notably noted for future reference and eventually documented.
Dependencies:
Wicket's date-time package extension requires a tool called, Joda. It took a while to figure out the reason why the page could not initialize when coding a date-time picker with the following:


private final Date date = new Date();
...
DateTextField dateTextField = new DateTextField("dateTextField", new PropertyModel(this, "date"), new StyleDateConverter("-S", true));
...
form.add(dateTextField);
dateTextField.add(new DatePicker());
...

Igor was quick to notify someone else with the similar problem by concluding that it would be easier to use a project management tool, called Maven. It's probably the most reasonable thing to do in the future since Wicket projects are now more geared towards using this to properly manage project builds, documentation and resolving dependencies. However, Devcathlon is quite comfortable now in just using Ant as a building tool. Ant serves to be flexible and less standardized than Maven, yet Maven does enforce good practices in folder structures and offers other great project organizations.
** (07-2009) UPDATE - All projects for Hackystat will be switched to integrating with IVY soon.**

This week:
- Resolve issues with mapping JAXB classes via HyperJAXB. (Complete DB)
- Setup and install Devcathlon to public (test) server
- Test game events and pull live data
- Incorporate new UI

Other notes:
Since other tools were needed to properly build the project through our continuous integration, via Hudson, I didn't want to risk failing a build. I'm keeping things in-house with my mentors until Monday when we set up a proper test server where I could install exactly what I need and want on it. Currently testing will be done by one user (myself) and eventually by my fellow Hackystat GSoCers.
I also mentioned earlier last week about switching to Netbeans 6.7, but my project mentor, Philip suggested that I should stick with Eclipse since we currently only have one sensor that supports Eclipse. On that note, this would make for a great plugin idea for Netbeans to support sending Hackystat sensor data via the IDE. Hopefully someone with the time could venture this avenue.

[GSoC09] Closing into Devcathlon v2.0

2009-07-03T00:47:00.000-07:00

Premise:
In this blog entry, I'll point out the improvements and near completion of Devcathlon v2.0. I know that mid-term evaluations are coming up for GSoC, so I'll need this week to concentrate on the core features. The things I hope to accomplish from now on are almost purely aesthetic, along with minor tweaks to the functionality here and there. I must apologize for my absence last week due to some personal health issues.

Hibernate and me:
For the last two weeks, I've been working on the database through the use of Hibernate. I got a chance to encounter some pretty neat, hidden surprises along the way; one of which deals with performance issues, due to the fact that Hibernate is so "lazy." Hibernate uses this to preserve memory space by not loading the entire objects from the database, but rather proxies at run-time instead. So I ran into some Lazy initialization errors that seemed very annoying at the time. For simplicity, I decided to lift the burden by just disabling this feature on certain mapped entities. However, I did take the precaution to apply some fetching strategies (join rather than a select) for an implicit get() or load() data retrieval. Overall the database is coming along, I did have some questions about class entities that require mappings, such as generated classes from JAXB, Project.class. This is required by most of the other class models (Team and Match), and I'm wondering if the class would need to be moved out as a User defined Type (by extension of Hibernate's UserType) or a custom subclass. Since this is a generated Java class from XML, I'm afraid to take either steps. Considering the time I have left, and mid-term evaluations are right around the corner, I've decided to move onto the UI goodness.

The Good Stuff:
I went back to some elements of our first designs of Devcathlon and took the time to rethink about certain areas. Everything is starting to come into perspective, as far as the design goes and we will be seeing some evidence of this in the following 2.0 release. Below is a list of in-progress features being worked on:
Key features:
Search engine (browse for entities: User/Profile, Team, Match)
Calendar selection
Improved Scoreboard main page - total revamp with live updated listings
CSS improvements to inherited Panels and Base pages.

Trying something new:
At the mist of an update, my Eclipse IDE went a-wal. It just stopped liking itself, or rather hating me... I had difficulty with start-ups, error messages would pop-up saying NoClassDef, and editors could not open up anymore. I got frustrated with trying to remedy this problem, since it has happened before. I like Eclipse and all, but It has given me a history of some disappointment. I can't blame it entirely, since I know that most of this is due to the fact that I install other third-party vendors (plugins) in Eclipse. This is the reason why I made my recent move over to using NetBeans 6.7. In all honesty, Eclipse is perfect for a lot of situations but it calls for other resources that might not be perfectly integrated with itself natively. On the other hand, NetBeans almost feels a lot like developing on an enterprise IDE, like MS Visual Studios, etc. It has all the languages I develop in on a daily basis built-in, offers additional services like connecting to databases, creating custom web services, and most importantly it's still FREE.
As for racking up dev-time, I'll have to resort to using Hackystat's Tickertape UI for now.

Conclusion:
In the final mid-term week of GSoC, I'll attempt to update the documentation, make improvements to the UI and ready the package off to my mentors. It's been quite a ride and I hope this project satisfies a need to many developers and project managers.

[GSoC09] Hibernate + Devcathlon

2009-06-22T13:47:00.001-07:00

Premise:
This past weekend I had the chance to dive into implementing Devcathlon's database back-end (Derby) by using Hibernate. I, unfortunately ran into some issues while applying these changes. They seem very pin-pointed since changes were recently made using Hibernate, but there were other confounding factors that hindered a smooth application. After last week's implementation, I was sure that the issue seemed small and easily doable. However the common, 1001 timeout error (which occurs during a Devcathlon's call out to Hackystat's SensorBaseClient) proved to be more of a challenge than I thought. In this entry I'll describe the issues I ran into, and the many solutions leading up to resolving this problem. I'll also mention about next week's goals and a timeline for Devcathlon's first milestone deliverable.

What was the issue?
SensorBaseClient 1001 timeout error - This happens due to the increase complexity of the application and heavy call loads out to Hackystat's SensorBaseClient server. This occurred while running the JUnit test cases against recent modifications while applying Hibernate. Another possible problem may arise due to the increase size of the application, which causes an overload memory usage on the contained JVM's heap size.

Resolving the issue:
I went through dismantling many of the previous code implementations. It wasn't awful, though I felt that changing the current state of the application was too obtrusive. I was prone to just keeping my changes reserved to just my additions. Any modifications to the actual code base would need to be reasonably thought out. So the (temporary) remedy for this matter happened to reside in modifying the DevcathlonTestHelper class. The error mostly occurs while trying to make multiple calls out to the SensorBase, along with calling out to Hibernate. The calls to Hibernate happens to stall (exactly at the same spots) and the connection to the SensorBaseClient apparently times out. I tried various ways to remedy the problem, a few of which that were clearly suggested by Johnson in this videocasting. If you ever run into this error, I would suggest to first watch that video and try out each solution, if all else fails then it's safe to assume that the problem must be you! The work around was applied yesterday, and I was thrilled that the build finally passed verify. The code has been unloaded to SVN and I would like some kind of code review from my mentors.
Changes for this past week.
r903 & r904

Next week's work load:
Just a reiteration, the primary goal at this point is to clearly implement a DB for Devcathlon. Considering how much I've endured this past week, It'll hopefully support a faster development time, now identifying those issues. Along with finishing the database, I will get the ball rolling next week for the user interface.
The first delivery date will be within two weeks from now, which will include a solid database implementation using Hibernate (with all/any kinks worked out), UI improvements mentioned in earlier blog posts and suggestions made by peers, and finally a mailing system using JavaMail. Look out for the official beta release of Devcathlon v2.0 on July 6, 2009.

[GSoC] Derby race to the finish...

2009-06-12T08:14:00.000-07:00

Purpose
In my last posting, I mentioned about ditching BDB for Apache Derby DB as Devcathlon's database back-end. I'm glad to say that that was a reasonable choice and most likely a better one in the long run. For this entry, I'll mention about my progress with the application and what I have in store for the next few weeks.

Starting out...
At first I decided to create the database using traditional SQL dialects for building the tables necessary for Devcathon. Below is the necessary Derby configurations and the resulting db schema.

Derby configuration:
Installed and included an environment variable for Derby.
Created DevcathlonDerbyClient.java class (within the same directory of Devcathlon's Jetty-server Start class). The class includes the connection details and initialization of Devcathlon's database. It was implemented using Derby's included JDBC client driver, ClientDriver class. Next I included the client driver for the start of Devcathlon's application in Start.java. Then I started Derby's Network Server, (ran startNetworkServer[sh|bat]) on port 1527. The application fired fine, and Devcathlon was able to communicate successfully with its database.

SQL DB Schema 'Devcathlon':
The full schema file can be found, here. This includes my quick implementation of Devcathlon's database schema for the following tables: Profile, Team, Project, Match and Event.
For convenience, the file is read in by the DevcathlonDerbyClient driver, then parsed and finally executed to initialize the database.

After spending some time reading up on ORMs, I decided to give it a try. I last mentioned about ORMs in my last few postings; this week was the real test and eventual implementation of an ORM, called Hibernate. I had a few other choices for a JPA + EJB standards (OpenJPA), but I think that Hibernate makes for an advanced extension to these APIs. Considering the immense support (online tutorial/manual) and popularity (in forums), I was able to get up and running with Hibernate within less than an hour.

Hibernate-Devcathlon configuration:
I downloaded the distribution (v3.3.1) and extracted it into to my local namespace. I also included an environment variable that links to the root directory of Hibernate, called HIBERNATE_HOME. Next, I modified the Ant build.xml to include Hibernate's required jars for compilation. Then I created a Hibernate configuration file, called hibernate.cfg.xml. The configuration file defines the SessionFactory settings, which includes the database connection(s), hibernate.cfg.xml files, pool connectivity, and debug options. Below is one possible rendering of an hibernate.cfg.xml file for Devcathlon. *Note that Devcathlon will default to looking for this configuration file under the ~/.hackystat/devcathlon/db/hibernate/hibernate.cfg.xml. This is intended so that system administrators can define their own configurations that may require a different database, or whatever is most optimal to their settings.


<hibernate-configuration>
<session-factory>
<property name="hibernate.connection.driver_class">org.apache.derby.jdbc.ClientDriver</property>
<property name="hibernate.connection.url">jdbc:derby://localhost:1527/devcathlonDB;create=true</property>
<property name="hibernate.default_schema">Devcathlon</property>

<property name="connection.pool_size">1</property>
<!-- SQL dialect -->
<property name="hibernate.dialect">org.hibernate.dialect.DerbyDialect</property>

<property name="current_session_context_class">thread</property>

<property name="cache.provider_class">org.hibernate.cache.NoCacheProvider</property>

<property name="show_sql">true</property>

<property name="hbm2ddl.auto">create-drop</property>
</session-factory>
</hibernate-configuration>

Loading this configuration file, required a basic HibernateUtil.java class to handle creating thread-safe, session-per-request SessionFactory. This class is intended to handle initializing one global session, providing pool connections for less overhead on the database, and closing a session. Most importantly, this will be the main communication between our data objects and Devcathlon's database. *Note on property, "hbm2ddl.auto" will be switched to a value of "create-drop" for testing purposes only. On an actual production server, this configuration file should just include a "create" value (without the quotes) for permanence.

Since I started out with building the db schema manually, it really benefited in creating the relational mappings for Hibernate. I could have gone with Hibernate's bottom-up approach by reverse engineering the process to get generated (Java annotated) mappings, but I wanted to see how close my schema was compared to the Hibernate's interpretation of Devcathlon's related classes, and mainly since all the Java persistent classes (ordinary POJOs) have already been built. Thus this is more of a top-down strategy that requires developers to build these relational mappings first, and finally have Hibernate auto-generate and apply its interpreted database schema.

Structural pattern to defining and applying relations:
Define the relational mapping of a persistent class entity, ex: User, Profile, Team, etc.
Add these relational mappings (*.hbm.xml) to the session configuration, by simply adding them programmatically in HibernateUtil.java.
All *.hbm.xml relations-per-entity will reside next to their declared entities and within the same folder.

Creating first relational mappings:
For initial testing purposes, I applied my first relational mappings for the User-Profile class models. The two class models have a one-to-one relation, or simply explained: A User has-one Profile and a Profile belongs-to a User. For a technical explanation, a Profile model would contain the primary key constraint, which 'references' the User model. The relationship will be represented as a bi-directional relationship, for equal referencing by both models.
Below is one way of creating the relational mappings through Hibernate. I could have also followed JPA standards and included some supportive Annotations, but that would eventually become too obstrusive (adding annotations) and more work (removing annotations) if we ever decide to use another ORM. Plus, using these xml configuration files is simple and easy to interpret.

Defining the user.hbm.xml:


<hibernate-mapping package="org.hackystat.devcathlon.engine.user">
<class name="User" table="ACCOUNT">
<id name="id" column="USER_ID">
<generator class="native"/>
</id>
<property name="username" type="string">
<column name="USERNAME"
length="16"
not-null="true"
unique="true"/>
</property>
<property name="email" type="string">
<column name="EMAIL"
 length="20"
 not-null="true"
 unique="true"/>
</property>
<one-to-one name="profile"/>
<property name="password" type="string"/>
<property name="firstName" type="string"/>
<property name="lastName" type="string"/>
</class>
</hibernate-mapping>

Defining the profile.hbm.xml:


<hibernate-mapping package="org.hackystat.devcathlon.engine.profile">
<class name="Profile" table="PROFILE">
<id name="id" column="USER_ID">
<generator class="foreign">
<param name="property">user
</generator>
</id>
<one-to-one name="user" constrained="true"/>
<set name="emailAddresses" table="PROFILE_EMAIL_ADDR">
<key column="PROFILE_ID"/>
<element type="string" column="EMAIL_ADDR"/>
</set>
<property name="screenName" type="string"/>
<property name="firstName" type="string"/>
<property name="lastName" type="string"/>
<property name="bioInfo" type="text"/>
<property name="gender" type="string"/>
<property name="avatar" type="string"/>
</class>
</hibernate-mapping>

Applying the db store:
Since Devcathlon's folder architecture is quite organized, and well thought out for future implementations of a database in mind. It was almost an effortless job on my part, considering that all I needed to do was send a create, read/load, update or delete to Derby's database. Each CRUD function was beautifully built and implemented within each entity's engine manager. So rather than storing everything in the Devcathlon session store, everything gets applied to Hibernate's SessionFactory. Below is a usage template for applying this SessionFactory:

[User | Profile | Team | Match]Manager class:
public function foo() {
...
Session session = HibernateUtil.getSessionFactory();
session.beginTransaction();
// regular java program logic, here
// create the query to communicate with our database.
session.createQuery("..."); //DML statements
session.getTransaction().commit();
...
}

Running JUnit tests.
I ran into some issues recently after running JUnit tests with my implementation, caused a SensorBaseClient timeout 1001 error. The error only occurs while running 'testNoData' for the very first test Event implementation (TestBestCoverage). It's not an intermittent issue, rather I know exactly where it's bombing out. However, I couldn't understand why the SensorBaseClient would timeout after my committed SQL transactions. The transaction that seems to be causing the problem resides in deleting Hackystat-Devcathlon test users defined in the unit test. It might have something to do with deleting a non-existing row and returning an unhandled Warning from Derby. Anyhow, I'll try to dig something up from the db log files and hopefully resolve this situation soon.

Code:
All source code changes for this milestone can be found, here.

The code distribution for this implementation can be retrieved with SVN. This distribution is a branch of the current trunk distribution, which will be merged onto later.

svn checkout \
https://hackystat-ui-devcathlon.googlecode.com/svn/branches/devcathlon-derbydb \
 hackystat-ui-devcathlon-derbydb --username <your-user-name>

or
svn checkout \
http://hackystat-ui-devcathlon.googlecode.com/svn/branches/devcathlon-derbydb \
 hackystat-ui-devcathlon-derbydb

Plans...
Finish building database schema and get started on UI improvements. Here are some thoughts on UI improvements:
- Search query for User-profiles, teams and matches (browse pages)
- Add a 'challenge' button for each opposing team profile page. This button will trigger an appendTeam method for appending teams for a new match. The user then navigates over to the Match page to see 'pending' match creations with all teams selected from visiting each team profile page. A user is limited to one pending list per session, and will be able to either accept the new pending match creation, or discard it for an entirely new form.

[GSoC09] Further DB Investigations and Vision updates

2009-06-07T13:55:00.000-07:00

Purpose
This entry will be a brief progress report about what I've done thus far. Currently, I have no new discoveries except for coming to terms with using some kind of database. I've also put out a wiki document for Devcathlon's vision, here (in progress).
Thinking about what's best...
During the past week I did some further investigations and decided to revisit Derby's RDBMS. A comment from my last posting, by Austin Ito made me realize the potential flaw to using a non-SQL embedded database. Considering the long-term effects of using a non-SQL DB would likely attribute to less flexibility and portability of a DB system. Especially if future developers of Devcathlon decide on porting its DB to another enterprise DB, this could be a very painstaking and undocumented process. Austin also mentioned about using an ORM, and I might also consider implementing Hibernate. I've been doing a lot of investigative work (mostly reading) on the topic of ORM's and so far I've noted on some benefits. By definition an object/relational mapping supports full object modeling, including the composition, inheritance, polymorphism and peristence. ORM's, like Hibernate are totally transparent (persistent layer), since ordinary classes do not require any special base class or interface implementations. Its also vendor independent, because it abstracts the underlying SQL database and similar SQL dialects out of the application. Although capabilities of a database may differ between systems, you can expect building a more cross-platform application using ORM.
Plans for this week...
Finish Vision document to include technical review and goals for Devcathlon v2.0.
Continue implementing Derby DB and read up on Hibernate. Hibernate and ORM's itself is still a new topic for me, and I'll be interested to hear about any other comments that attribute to using this persistence framework with Derby DB.

[GSoC09] DB tryouts (Derby & BDB)

2009-05-21T02:12:00.001-07:00

Premise
In this entry, I'll describe my experience in installing, configuring and applying of both database management systems, including Apache Derby and Oracle (SleepyCat) Berkeley DB.

Background Info
Derby
Derby is one of Apache's many successful entities known in the community of Java developers. It is a Java-based, embedded, JDBC driven SQL database. It also includes a client and Network Database server for client/server implementations.
Berkeley DB (BDB)
SleepyCat's Berkeley DB is Oracle's attempt at a fully embedded non-SQL database, including no ad hoc queries, but many quick indexing remedies for querying records. It's targeted for application environments that want to quickly implement an object-relational database management system with very little footprint and less dependent on DB administration. It has everything that you would expect of a database system and promises optimal solutions to retrieval and transactional operations.

Installation & Configuration
*Both platforms require some form of JRE ~v1.5 or above.
Derby
The retrieval and installation process of Derby was easy, simply download the tar/zip file, extract it to the location you want, then update your environment variables to include DERBY_HOME, and add a path to the executables (DERBY_HOME/bin). more
BDB
The download and installation process of BDB wasn't difficult either. It only required an additional environment variable (JE_HOME) pointing to the path of the downloaded package. more

Comparison
Derby
Derby provides an internal interactive SQL scripting tool, called 'ij' used to connect to an existing database, or create a new database. Coding in Derby is very SQL scripting heavy and it requires a planned out schema. Loading and connecting to Derby DB is simple, you just load the appropriate embedded or client driver (depending on your application). You can also pass ad hoc queries, basic SQL statements for creating, updating, or deleting (all fundamental CRUD). Derby is a great RDBMS for settings that require ad hoc queries, and for optimal access to SQL databases.
BDB
BDB is a whole different approach, in that it implements a Java DB without the need of SQL. This object-relational database approach offers more direct interactions of object based models. Actually BDB is stored by object values, rather than by traditional object reference which models similar benefits from EJB persistance APIs. Programming in BDB is quite intuitive and requires that you have strong knowledge in manipulating Java objects via understanding of Java APIs, especially with the Java Collections framework (since this applies to 'Cursor ' iterations through records stored in BDB). I have to agree, in theory with BDB's storage and indexing approach, since it does provide a low cache way of retrieving raw data and instantiating objects seem seamless. I wonder how BDB memory caching features perform once it goes against more storage data input. If I do decide to use BDB, I hope that I won't need to roll out my own solution for tuning the cache. Of course, this over bloating of memory depends solely with the complexity of the application and my usage of BDB. After coding a little in BDB, I also noticed some similarities to Hibernate since they have similar implementations using EJB and Java's Persistence APIs. Although BDB isn't a standard with most developers, since its approach to an embedded database requires no SQL seems unorthodox; I feel that its structural aspect and its targeted purpose of increasing performance in object relational coding feels much more natural.

The Verdict
At this point in time, I'm falling towards using BDB since the solution is quite simple and unobtrusive to the network environment setting. It will require less configuration on the administrative side, yet it gives more control over the configuration directly through the application itself. The other reason is that the class file structure is already in good standing for a BDB implementation. There will be no need for creating a client driver connection or bringing up a Network Server, as I previously planned on doing by using Derby.

The 'Vision' Document (unofficial)
The vision hasn't changed much since my first entry about Devcathlon. We are still pushing for a workable application that can be used by developers as an interactive assessment tool to better software project environments. At the moment no changes have been made to the current code base, rather more planning and testing have occured locally for assurance. Right now, deciding on a preferable DB is the question at hand. Considering my research and tests, I would recomend using BDB as a possible DB implementation for Devcathlon. The DB implementation is pretty much a way of incorporating a persistent back-end for Devcathlon. I've yet to apply any specifics on future improvements, but I feel the need to get most of the targeted functions to work first in Devcathlon v1.0.

Plans
I'll need some time to develop a 'spike solution' of BDB with our current implementation of Devcathlon. This shouldn't be difficult considering that most of our models built in Wicket for Devcathlon are neatly separate object entities, so it makes for a perfect setting for using BDB.
I'll also be revising my vision document, since little has been put into making this a 'viral' record.
Also, since I'll be revising the application many times over, the use of a review (summary) at this time will not be committed until after a DB solution for Devcathlon is released.
*Notes on development environment: Since the project code base is housed via Google's Project Host, I've decided that we should create a branch for our DB solution. In addition to our branch, we should have a live development box that mimicks a production environment for shared consistency and remote testing.

[GSoC09-Devcathlon] Tentative Plans

2009-05-21T02:12:00.000-07:00

Welcome to GSoC
Hello, GSoC!
I'm glad to announce my induction to Google's 2009 Summer of Code. This is a belated entry about my pre-dated acceptance back in April. I've yet to talk much about it, but it's never too late. This series will be targeted for people interested in the progress of Devcathlon and my personal experiences along the way. Each title in this series will be prefixed with "[GSoC09...]" as a convenient indication to you, myself and to my fellow, GSoC mentors. In this entry I'll refresh about the project Devcathlon and outline my plans for this summer.

About Devcathlon
Devcathlon is a web application to help better software engineering practices and to assist in improving project management settings. Devcathlon was a three month project started by 8 students and 1 professor from the University of Hawaii at Manoa. This project is intended to simulate a software engineering environment along with the benefits of a game. If you're looking for a place to compete with other software development teams, or to see where you stand as a developer, then Devcathlon is the place to be. The motivation behind this project was spawned from the possibility of creating a fun and easy to use game, targeted towards software developers who feel the need for a competitive edge or want to be recognized by their community of peers. Besides having to see where you rank amongst your colleagues, this application also looks to help improve the ethics and recommended practices of an ideal software development environment. Devcathlon encourages continuous development procedures that should come second nature to most developers, such as commit early and often, separate but equal ownership, and test before you drive.

Below are my summer plans and related responsibilities for this year's GSoC.
Summer outline
1. Fix any discrepancies on the Devcathlon v1.0 release.
2. Design Database schema

Build relational model using a DBMS (MySQL, SQL Server, or the critically acclaimed Apache's Derby)

3. Future enhancements for Devcathlon v2.0.

Integrate Wicket with Spring's application framework and Java-based persistent object-relational model framework, called Hibernate. Apply questions about using such a framework, like What is AOP? DAO? DI & IoC? How does applying a multi-tiered or layered application benefit from traditional coding styles in its robustness, simplicity, etc.?

So far, I've done some investigations about Apache's Derby and played around with it during my spare time. In my next posting I'll describe my experiences using Derby as a possible (embedded) persistent database for a simple Wicket application. Next week I'll attempt at designing the database schema for Devcathlon along with resolving any problems with Devcathlon v1.0. Hopefully, I'll also put out an official Devcathlon code review sometime during the course of the week.

[ICS 499] It's Only the Beginning

2009-05-15T00:34:00.000-07:00

This semester was surely an exciting roller coaster ride full of many bent turns, unexpected loops, and some worthwhile air time. The goal of this project was to gain minimal insight into electronic health record systems (EHR), and to explore the possibilities of developing an open source component to enable greater extensibility and interoperability for development platforms. It turned out that a big competitor in the medical health record industry, Medsphere had developed just that tool for creating a Java-based linker solution, called OVID (OpenVistA Interface Domain). The OVID project is still very young, yet they've pushed through great lengths recently to have it on a fully open repository. Medsphere also released a front-end patient record dashboard along with OVID, which was built using OpenLaszlo, called lzVistA. After realizing the potential of building such a dynamic front-end GUI using such expressive component based and XML driven-development of RIA's, I started looking for alternative RIA's that could help shape my own patient dashboard. This began the exploration of finding the right RIA that I'm most comfortable with. After giving OpenLaszlo a try, I thought to myself, "Yes, I'm impressed." Then I realized the hassle of not having a dedicated IDE for editing and building OpenLaszlo applications. This led me back to the road, where I would eventually reunite with my all time favorite Flash platform. It's been a long time since the Macromedia days, and Adobe's done a great job in marketing the trend of Flash now being used on practically every browser. Adobe is also well caught up with the open source community, since they recently released a full open source version of their XML/MXML development language kit, called Flex. Flex serves as an innovative way of producing web-based applications in a much more rich and multi-platform environment. In my recent discoveries, I mentioned that Flex provides many different ways to capture and retrieve data via data services, such as web services, HTTP and remote objects (including server-based Java objects). Flex is also accompanied by an IDE built on Eclipse, called Flex Builder. This makes for an easy migration, since I'm able to switch between developing environments with ease.
It's interesting as to how large the scope of the project has become since the introduction of OVID. I'm now hoping to build a web-based EHR client using Flex and Java's back-end server connection to OpenVistA via OVID. I'm glad to say that this has been a progressive project, including the immense time spent on getting used to Flex's component-based development, and refreshing my skills in the new ActionScript v3.0. The experience was well worth it, but I've yet to close this road permanently. I'm simply putting this project on hold in promises that I'll be able to continue down this path with more added time and consistency. I'm still actively supportive in the project and I've taken the necessary steps in order to keep up-to-date. Since OVID isn't a perfected system yet, I hope to give my helping hands on their development team. This would mean that MUMPS is back to haunt me again, but at least I'll have Java to accompany me along the way. As far as this semester goes, I'm probably more satisfied with what I've learned rather than what I've produced. Along with understanding how to self-manage myself, I've also learned to become more engaging as a programmer. This has opened me up to the possibilities of how many things still need to be invented, or needs improvement in this world. I'm thrilled to know that I'm stuck somewhere in between having thought of something with the right resources to do it, and realizing the proximity of a real-life product.

Devcathlon Evaluation

2009-05-10T23:09:00.000-07:00

Premise:
Devcathlon has been a three month project intended to simulate a software engineering environment in hopes to improve development team practices, and to promote overall project health. In this entry, I'll evaluate the application through my personal perspective as a developer, along with the evaluations of outside testers. I'll also mention about my experiences in building this project, and the future of this application.

A programmer's perspective:
The journey through markup...
Most of my development time was spent on building the profile section of Devcathlon. It wasn't difficult, but there's still room for lots of improvement. I kept this first version of Devcathlon's profile page simple, in order to focus on the teams, matches and scoreboard pages. Devcathlon underwent through many physical and functional changes since its first conceptual designs. We started out with basic HTML mock-ups which looked and felt very web 2.0-ish; considering that it had some Javascript, some signs of pagination and an array of CSS layouts. By separating ourselves into three separate teams of three, we were able to generate some very inspirational designs and structures that would eventually be inherited into the "final" product. Although some design elements were put away as future enhancements, due to being labeled as aesthetic gains rather than functional gains, we did provide, in this version, an intuitive, yet simple user experience. The gains of taking this conservative approach would rather benefit ourselves in the long-run, since we built a strong foundation of our application and left plenty of room for advance UI's to take place later. Of course, we've only scratch the surface of Wicket's abilities to render some "pretty," and dynamic markup, but I'll see to it in our future implementation that we have an eye-candy application. At this point, I'm very pleased with what we have, as far as the look and feel goes. The application has a conformed look and layout; we made good use of our CSS to standardize our information in reusable "panels," and we also preserved colors and fonts similar to Hackystat's UI. I'm willing to put energy during this summer to make improvements in this area by incorporating more AJAX-y alternatives to necessary parts of the web application.
Functionality in design...
Below is a list of my likes and dislikes, and some possible way of improving each portion of the web application. I'll also mention the difficulties and challenges in making these sections possible.

Front page review:

The front page contains a basic login and password form, along with a preview version of our scoreboard. Although, this idea of putting the scoreboard on the front page came late in the game, we found it useful to help advertise the current status of our application with regards to providing evidence of user traffic and ratings. The front-page version of the scoreboard is not all that different from the actual scoreboard, except that some links are not featured unless you have logged in with an account. The gray panels and use of reusable components makes the composition of this page very useful in context, by providing information on match events, teams events and individual player's scoring. A future improvement would be to provide a live scoring data provider that would emulate statistics on the fly through 5 minute increments or whenever it spots a new change in the system. This would be beneficial by reducing the number of whole-page refreshes and enhancing the user experience by providing a persistent way of retrieving data.

Profile page review:

The profile page went through minimal amounts of change due to its limited usages other than finding out more about the player participating in the game. Although, the profile page makes for very little use, I've come to find that there are many ways of approaching this section. I looked around on mostly social networking sites, including TechHui, Facebook and Twitter to gain some inspiration and possible commonalities. I narrowed down some details of a user profile to only include, the user's first and last name, location, contact number, email address and biographical information. The only required field is the email address, since it serves the purpose of your login name and our source of sending out game match invitations and updates. The main profile page also replicates information regarding a listing of user's team affiliates and current team events. The profile page successfully makes use of the qualified standard gray panels, and a simple-to-read 3-column layout. The profile section also includes "manage" and "browse" sub-pages. The Profile Manage section gives the player the ability to make changes to their profile information. The only ability that it lacks at this point is a way to add additional social networking aliases, modifiy email address, and the choice of choosing a different profile avatar. The addition of other social networking aliases is as simple as creating a textfield. At this point, there is no "right" way of changing a user's email address since the user's account information is dependent on it as an identifier in the system. Hopefully in future enhancements, we'll incorporate an interface to attribute to this feature of changing a user's email, and getting a email notification of the account being modified. Of course to preserve the integrity of our system, we'll need to require a primary email address to send that account modification. Another neat enhancement would be to enable a user the ability to modify their avatar on the system by providing a local image upload. This would require a persistent storage location on our public servers and a limited file size.

Team page review:

The team management section is in itself very functional and simple to use. The team creation process is straightforward, users will not have very much difficultly in getting the hang of things here. I could only point out certain enhancements rather than any noticeable flaws in this section. Although, the co-creator of this section did indicate in the issues listing about a potential "weakness" to the user-to-team invitations handling. This may be a confounding factor that needs to be addressed in the next implementation stages of Devcathlon, but as for now, it sits deep under the covers.

Match page review:

The match management section gives a listing of all involving team matches. It gives you the ability to create, update and destroy matches. The only disadvantage is through the ease of finding an existing match. There is no mechanism to browse for matches, but it would help to supply a way to immediately find a match rather than scrolling through a large column listing. Maybe we can incorporate similar pages implemented by the user profile and team management sections. This would require two additional pages, called "Match Browse" and "Match Profile." The match browse page will include a table listing all matches, and on each row a link to its respected match profile page.

Scoreboard page review:

The scoreboard page includes a listing of all matches, team line-ups and their respective members, match events, comments, and top developers for that match. This page did a good job of portaying that information in a clear way. My only problem is that it would be difficult to display multiple team match line-ups, where matches can consist of more than one participating team. The Hall of Fame page is included as a scoreboard sub-page that gives an overview listing of wins, losses, points accumulated per match, and most valuable players. I only wished that this page had more visual references rather than just plain-old text and links.

Top 5 lessons learned:

Time management - Time is the quintessential factor in everyone's life. I found it difficult in many cases, but had to ground myself to accepting the fact that I do have issues in this area. I have learned through this experience to be patient and better plan out ahead of what needs to get done. This holds a large part in my leadership skills too, since managing other people calls for good planning and time management skills.
Leadership skills - I think that I've become a better person from being given the title of a "leader." In many ways, it has improved my outlook of managing a small team in such a large setting. At first I was somewhat doubtful that I could accomplish it, but I eventual grew out of the fear and simply started to care. I started to care for the project and its respected team members. This helped bring me closer to the individuals in my team as well as other project members.
Control - I think that controlling that programmer's ego is a must in a large project setting. It's very different from critiquing your own work as oppose to being able to endure criticism from others. I've learned to respect others opinions to find a common solution. Eventually once you've set aside your ego, you'll notice a difference in the mood that you bring to the atmosphere. I learned to control that atmosphere through just being lightly assertive, but straight to the point.
Collaboration - Collaborating with my team members weren't very difficult, but it had some confounding factors such as its frequency and effectiveness. The effective route is to meet as often as possible. It's very simply stated, but it turned out to work in our situation with a group of eight people. We also incorporated pair programming as a way to keep each individual on their toes.
Forgive and forget - Sometimes you just gotta forgive and forget. Its difficult already that this project posed a challenge for many of us, but adding to that tension could have led to some adverse effects. I'm glad that this group had that notion of forgiveness. It was quite evident during those milestones that just did not work out as we planned. We would rarely hold personal grudges towards another individual. It was sometimes nice to just talk about it rather than tuning out the whole problem.

Reflecting...
Now, for some people, this is the time to put up their hardhats and salute to a good year of eventful meetings, to staying up late coding, and to enduring all those emails with the subject line starting with "[Devcathlon] ..." I'm not sure about others, but I'll sure be missing that feeling of being needed for a project and looking forward to just doing something the next day. This project brought in a mixed set of individuals with different skills and backgrounds, but with one common goal of making this project the best it could be. I could not have asked more from these group of highly talented people. Their dedication and hard work has paid off, and I hope that everyone takes something from this into their own personal endeavors in life. I know that I'll take this experience and be able to apply what I've learned into any setting. The time we sacrificed; those bloody hours at the keyboard; those late nights sipping on energy drinks, and those times when all you could think about was "Devcathlon" will now become a memory. Even as unfortunate as that may sound to a few, it has made a profound impact on what I see in a large team setting. The beginnings were difficult, but over time we progressed from novices to experts in our own way. This experience has challenged myself and others mentally and somewhat physically. This project has given me ways to express myself more freely than I usually do in any other class related setting. It has taught me to be ethical, respectful, resourceful and passionate about goals. It has also taught me to become a better person by encouraging me to open up to all sorts of people. I'll honestly miss that energy, and all those who made this project what it is today. I hope to find that same spark during my attempt at enhancing this project for this year's Google Summer of Code. I'm sorry that not all original members of the team will be participating, but I am grateful for their respectful input and support. Good luck to everyone, and thanks for all the hard work!

[ICS 499] Java + Flex Hybrid

2009-05-01T17:27:00.001-07:00

Premise:
In this blog entry, I'll discuss my experiences of hybridizing Java, Actionscript, and Flex into forming what could possibly be a perfect ingredient for success. Well not absolute success, since I will not be building anything in this entry, but it will leave you with some ideas that could work in your setting. I'll also mention the ease of migrating between Java and Actionscript, and give you some insight into the possible technologies that surround Flex.

Contextual definitions:
Flex - front-end client-server application
Java - back-end object oriented language for building an enterprise server for channeling data
Actionscript - object oriented and script-base language used to construct logic in controlling our Flex client application.

Actionscript & Java:
Actionscript is an object oriented, free form, functional language used to build logic into creating Flash rendered content. The language follows the standards of ECMAScript and recently, in version 3.0 has been enhanced to support E4X for ease of processing XML.
Java is an object oriented language that has been widely accepted for its cross-platform, and strong emphasis in creating server-side technologies.
ActionScript 3 is different from Java when it comes to properties, dynamic behavior, and some very convenient aspects of functional programming. However, the move between Java to Actionscript was not all that difficult and it makes for a beneficial switch once you get the hang of things.
If you need a quick comparison chart between Java & Actionscript, then check out this posting.

Java & Flex:
Java and Flex provides the perfect marriage between two things that just mix well. One, you have a strong server-side back-end and two, a simple, near real-time data rendering front-end with very high refresh rates on large data sets and almost 100% deployable on any browser.
How it all fits together?
Figure 1.
Figure 1: http://learn.adobe.com/wiki/display/Flex/Flex+and+Java

A successful marriage calls for good communication:
Flex's ability to communicate with a Java EE back-end using HTTP or SOAP-based Web services is highly useful, but you're not limited to those communication approaches.
Adobe provides an open source alternative, called Blaze DS -- a server based Java remoting and web messaging technology that enables developers to easily connect to back-end distributed data and push data in real-time to Flex and Adobe's Air application front-ends. BlazeDS lets you use Java Messaging Service JMS for communicating through XML-based transactions and allows you to use object remoting with Java. BlazeDS also adds potential performance benefits because it uses the binary AMF3 format for faster communication than is normally experienced with XML.

Conclusion:
Sorry to leave you with such limited content. I'm just excited now to test out the logic and theory, in order to get one step closer into hybridizing Java with Flex. In my next posting, I'll be concluding my research into a report that summarizes what I've accomplished and my experiences during the course of this study.

Resources:
Java & Actionscript 3 (Part 1)
Java & Actionscript 3 (Part 2)
Java & Flex Integration (Part 1)
Java & Flex Integration (Part 2)

[ICS 499] My tour de Flex!

2009-04-27T15:31:00.000-07:00

Premise:
Considering the commotion about OpenLaszlo and all things RIA, I decided this week to also speak about my experiences with trying out Flex 3. Flex is an open source Flash development framework designed from the ground up to facilitate the creation of Rich Internet Applications (RIAs) on the Flash platform (Flash 9). The Flex 3 SDK framework utilizes a mixture of a custom XML format called "MXML" and the OOP language, called ActionScript (3). ActionScript 3 is required in the recent release of the Flex 3 platform, as well as the Flash 9 platform.
In this blog entry I'll walk through my experiences developing in Flex by building a fun looking authentication application form.

Tools and requirements:

Java Runtime Environment
Flex 3 SDK
Flex Builder (IDE) - The Eclipse-based IDE for the creation of Flash RIAs. Not only does the presence of an IDE significantly aid in the creation of Flex applications, but Flex Builder also has a design view and a code view, each with its own benefits, further improving ease-of-use and application development workflow. The only downfall is a hefty price after the 60-day trial of using the product. Of course you could either pay the fee, or switch to a light weight editor, such as vim, emacs, textpad, notepad, etc..
Flash 9

Optional Tools and Mentions:

Flex Charting: Aset of charting and graphing components, capable of generating Excel-style data representations, to aid in the visualization of data through Flex RIAs.
Live Cycle Data Services (LCDS): Aserver-side application that expedites the speed of data synchronization between your middleware and your Flex application SWF (formerly, Flex Data Services).

All of the latest Flex related downloads can be found here.

So instead of starting out with the usual "Hello World!" application, I'll just start diving into the fun stuff and we'll go from there. I'll first build a simple version of the Login form, and then we'll apply Flex magic to create a more exciting user experience. All elements below were built using Flex Builder's. I would recommend snagging a copy for yourself, but you can always resort to using any text-editor of your choosing.

Applying the basic Flex Framework:
LogMeIn.mxml:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute">

</mx:Application>

This code is the basic container for all your components and the basis of any Flex application. Flex Builder should also generate two important files in order to make this internet application work: first the embedded LogMeIn.swf and second, the LogMeIn.html itself. Run this in your favorite browser (Firefox for me) and you should see a blue-green colored background that fills the entire page.

Building the basic Login in form:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" horizontalAlign="center" verticalAlign="middle">
  <mx:Panel id="loginPanel" width="309" height="182" title="Login Form" horizontalAlign="center" verticalAlign="middle">
    <mx:Form verticalCenter="true">
      <mx:FormItem required="true" label="Username" width="215">
        <mx:TextInput id="loginTI"/>
      </mx:FormItem>
      <mx:FormItem required="true" label="Password" width="215">
        <mx:TextInput id="passwordTI" displayAsPassword="true"/>
      </mx:FormItem>
      <mx:FormItem horizontalAlign="right" width="215">
        <mx:Button id="loginButton" label="Login" click=""/>
      </mx:FormItem>
    </mx:Form>
  </mx:Panel>
</mx:Application>

Here, we have a basic form with a submit button contained within a labeled panel. It's starting to look good so far, but nothing exactly works yet. Lets add some functionality to this component.

Adding some authentication logic:

  
<mx:Script>
  <![CDATA[
    import mx.controls.Alert;

    private function login():void {
      if (loginTI.text == "admin" && passwordTI.text == "admin") {
        Alert.show("Hurray!", "Login Message");
      }
      else {
        Alert.show("Incorrect login and password combination.", "Login Error");
      }
    }
  ]]>
</mx:Script>

For an incorrect login info...
And a successful login message...
Now that sure is one sexy Alert message, much better than those generated by Javascript's alert prompts. I'm somewhat impressed with this so far, but the interface can be improved to test out the power of Flex's physics engine. We can make the UI much more intuitive and surprisingly different from anything else. From here on, I'll be mimicking code produced by Doug Mccune, a fellow Flex developer.
The rest of the code is beyond the scope of this blog entry and will be featured as a download. I replaced the original form components within the panel to what was indicated in Doug's demo. Also the modified text input labels are enclosed in a "PhysicsContainer" class in order to provide that feeling of falling and manipulable objects.


<panel ... >
  <containers:PhysicsContainer id="canvas" width="100%" height="100%">
  <!-- Original login form -->
  ...
  <flexlib:PromptingTextInput id="loginTI" prompt="username" x="50" y="35"/>
  <flexlib:PromptingTextInput id="passwordTI" prompt="password" x="50" y="75" displayAsPassword="true"/>
  <mx:Button label="Login" x="158" y="115" click="login()"  />
  </containers:PhysicsContainer>
</panel>

When a person attempts to login with the wrong credentials, then the components would fall from their initial position due to some applied physics. These components are also draggable objects that can be manipulated and oriented however way you want.

Overall, these RIA platforms, including Flex have proven to be the next step in building a more interactive and responsive application for simple or complicated web interfaces. Flex, for instance, is an open source framework. This means that Adobe builds a bunch of "stuff" into the structure, which you can utilize in your applications seemlessly. What makes Flex so special is that it makes things incredibly easy to assemble through its component based framework—far, far easier than authoring custom applications in the Flash authoring tools presented in Adobe's Flash Professional. Flex comes with these essential UI components (Text input, labels, buttons, etc.), as well as additional ones to assist in laying out content. Flex also makes it incredibly simple to create your own custom components out of these components and has robust CSS support, making it quite easy to style your applications and even consume the same CSS files that you might use elsewhere on your website. And of course, it's easily portable. Just see for your self below.
This week's plans...
Flex is on my good side this week, so I'll be spending some time testing a prototype interface with OVID's VistA connector. My next blog entry will further expose the technology that Flex has to offer, with regards to its support for many data source providers, including HTTPService, WebServices and Remote Objects.

Just for fun, here's the embedded app for you to play with. It sure looks like another Flash application, but it's built using Flex!

Resources:
Learn Flex in a week
Adobe AIR application: Tour de Flex
Featured download: LogMeIn.zip

[ICS 499] OpenLaszlo...simply wow

2009-04-11T17:00:00.000-07:00

It looks and feels like Flash, but its not necessarily that. OpenLaszlo is a Rich Internet Application (RIA) platform targeted for building desktop-like web applications. Its component based syntax for declarative programming provides an array of supported outputs, such as Flash, and recently, DHTML. In this entry, I'll give what seems to be a very clear cut example of a simple OLZ application.

Please note that this application is a derivative of Adam Wolff's screencast for OpenLaszlo 4 programming.

Defining and porting our data...
Laszlo follows the strong standard XPath data-binding API's, as well as components to facilitate communication with the back-end. XML is used as the standard representation format of every LZX application file. Any data source that negotiates with Laszlo applications are quite capable of generating XML dynamically. Such sources may include: JavaServer Pages, Servlets, Microsoft Active Server Pages, ColdFusion pages, CGI applications, PHP scripts, etc. To keep things simple for this example, I'll provide the raw XML file for my LZX application.

Here's my XML file, called places.xml:

<places>
<place street="750 Keeaumoku St" description="Walmart store"
name="Walmart" city="Honolulu, HI 96814"/>

<place street="1450 Ala Moana Blvd" description="Ala Moana Shopping Center"
name="Ala Moana Center" city="Honolulu, HI 96814"/>

<place street="1527 Keeaumoku St" description="Makiki District Park"
name="Makiki Park" city="Honolulu, HI 96822"/>
</places>

Creating an LZX application file:
Simply create a file and name it with the extension of ".lzx", then place the following inside it:

<canvas></canvas>

There you have it, your very first Laszlo application! I know it's not very impressive, but it only gets better.

Data source retrieval in LZX app:

<canvas>
<dataset src="places.xml" name="dsPlaces">
<window title="Places" width="200" height="250">
  <simplelayout/>
  <view>
    <text>
      <datapath xpath="dsPlaces:/places/place/@name" replication="lazy"/>
    </text>
  </view>
</window>
</canvas>

In this bit of code, I introduced a data set tag referencing to my local "places.xml" file, with a name tag of "dsPlaces." Next, "window" is a simple way of creating a draggable window panel with an optional fixed width and height. The window is the container object for our data set output. By following standard XPath for XML styled notation (/places/...), we can simply list all the names of places from the xml file. Also a special note on "lazy" replication: It simply is built into the OLZ runtime and acts as a catalyst for retrieving data faster and efficiently (similar to Google Maps rendering).

<canvas>
<dataset src="places.xml" name="dsPlaces">
<window name="main" title="Places" width="200" height="250" resizable="true">
  <simplelayout/>
  <view>
    <text onmouseover="this.setBGColor(0xDDDDFF)"
             onmouseout="this.setBGColor(null)>
      <datapath xpath="dsPlaces:/places/place/@name" replication="lazy"/>
      <handler name="onClick">
        details.datapath.setFromPointer(this.datapath)
      <handler>
    </text>
  </view>
  <scrollbar/>
</window>
<window name="details" title="$path{'@name'}" x="${main.x + main.width}" width="400" height="250">
  <datapath/&gt
  <text datapath="@description" fontsize="14" width="100%" multiline="true"/>
</window>
</canvas>

Added a little OLZ syntactic sugar for Javascript to allow mouse over effects to the text data.
Created a handler for when a user clicks on a data text --the data set that was clicked on would sync with the details window.

Defining your own window class:

<canvas>
<dataset src="places.xml" name="dsPlaces">
<window name="main" title="Places" width="200" height="250" resizable="true">
<simplelayout/>
 <view>
   <text onmouseover="this.setBGColor(0xDDDDFF)"
            onmouseout="this.setBGColor(null)>
     <datapath xpath="dsPlaces:/places/place/@name" replication="lazy"/>
     <handler name="onClick">
       var details = new detailswindow(canvas);
       details.datapath.setFromPointer(this.datapath);
     <handler>
   </text>
 </view>
<scrollbar/>
</window>
<class name="detailswindow" extends="window" title="$path{'@name'}"
   x="${main.x + main.width}" width="400" height="250" closeable="true">
 <datapath/&gt
 <method name="close">
    putAway.doStart();
 </method>
 <animatorgroup name="putAway" process="sequential" duration='300' start="false">
   <animator attribute="height" to="50"/><animator attribute="y" to="-50"/>
 </animatorgroup>
 <text datapath="@description" fontsize="14" width="100%" multiline="true"/>
</class>
</canvas>

Added extensible window class, called "detailswindow."
Demonstrated a named method handler for closing a window (animator).

Marketing this app by embedding a Google map via the GoogleMaps API:

<canvas>
<href="htmlview.lzx"/>
<dataset src="places.xml" name="dsPlaces">
<window name="main" title="Places" width="200" height="250" resizable="true">
  <simplelayout/>
  <view>
    <text onmouseover="this.setBGColor(0xDDDDFF)"
             onmouseout="this.setBGColor(null)>
      <datapath xpath="dsPlaces:/places/place/@name" replication="lazy"/>
      <handler name="onClick">
        var details = new detailswindow(canvas);
        details.datapath.setFromPointer(this.datapath);
      <handler>
    </text>
  </view>
  <scrollbar/>
</window>
<class name="detailswindow" extends="window" title="$path{'@name'}"
     x="${main.x + main.width}" width="400" height="250" closeable="true">
  <datapath/&gt
  <method name="close">
    putAway.doStart();
  </method>
  <animatorgroup name="putAway" process="sequential" duration='300' start="false">
    <animator attribute="height" to="50"/><animator attribute="y" to="-50"/>
  </animatorgroup>
  <text datapath="@description" fontsize="14" width="100%" multiline="true"/>
  <handler name="ondata">
    var fullAddress = datapath.xpathQuery('@street');
    fullAddress += ", " + datapath.xpathQuery('@city');
    map.setSrc("map.html?addr=" + fullAddress);
  </hander>
  <htmlview name="map" width="100%"/>
</class>
</canvas>

Here's a sample of an htmlview.lzx:

<canvas>
<window width="600" height="600" resizable="true" oninit="this.htmlview.setSrc('http://maps.google.com')">
<html name="htmlview" xoffset="8" yoffset="25" widthoffset="-20" heightoffset="-45"
oninit="this.bringToFront()"/>
</window>
</canvas>

This displays a map beneath the selected address of interest.

So as you can see, OpenLaszlo gives new meaning to web "mashups" by inherently being able to consume all sorts of data sources. RIAs do a very good job at utilizing an intuitive standard, like XML to bring many of these hierarchical components to life. Tomorrow, I plan on testing out yet another RIA platform, which went open source back in 2007, known as Adobe's Flex.

[ICS 499] Setting up shop...

2009-04-11T14:35:00.000-07:00

My fellow colleague and I began configuring our working server this past weekend for the OVID project. Just to reiterate from my previous post, OpenVistA Interface Domain (OVID) is a Medsphere project that interfaces a layer for communication between applications and OpenVistA data. We checked out a copy on both of our machines without a hitch. The code builds successfully on both Eclipse and Netbeans, though some of the jar classes are meant to run correctly on Java 1.5.x -- class build number should be '49'. We were planning this week to speak to two other people regarding the configuration and setup of our environment. One person being a long-time Medsphere associate, Andy Pardue, and the other a head developer of the lzVistA project, Wally Cash. Although communication was a bit limited due to the Easter weekend, we were still able to get Apache's Tomcat running, OpenLaszlo installed, and the OVID code to build.

Here are some notes for the upcoming releases of the OVID project from Medsphere. I'm excited to see that they're planning on putting out a central codebase repository. It'll be interesting to see which route they'll take as a choice of their SCM system. Hopefully if we get in contact with Andy Pardue, then we'll have some say in the matter of its open release to the public.

Create a comprehensive set of acceptance tests. Right now, our tests are spread out and not validated. Having these tests will allow us to quickly add new classes while validating current functionality.
Refactor the connection logic to make it easy to choose between RPCBroker and VistaLink. RIght now, we are reliant on VistaLink. RPCBroker would be a better choice for some platforms.
Refactor the FM logic to enable richer queries.
We're readying the codebase to be placed in an online repository to make it easier to collaborate.

I'll be spending some time looking over examples on developing in OpenLaszlo, along with putting up the sample Patient Dashboard on our web server. In my opinion, I think we are getting off on the right foot, and it seems that it's the perfect time to hop into this project early on during its development stages. Hopefully with enough support from the community, especially from those who may benefit from this cause, we should indeed witness a strong push into the spotlight.

[ICS 499] OVID is checking in...

2009-04-08T03:00:00.000-07:00

In recent news, Medsphere released an open source tool set, called OpenVistA Interface Domain (OVID) which equips developers with tools for messaging with OpenVistA (OV) data. To my surprise, it had basically achieved all that I had hoped for for my BMXNet conversion to Java. This release enables developers the ability to communicate with OpenVistA data through either Remote Procedure Calls (RPC) or directly through FileMan (FM) calls by way of constructed Java bindings. Since this piece of the puzzle has finally made its way into the open source community for medical health record software systems, developers are now relieved of many cross-cutting concerns regarding support for multi-data providers, OS platform support and web-based integrations. Members of this project team have taken it to the next level by demonstrating a web application comprised of intricate web services (built in Java). Their demo release is packaged with this Web Service Definition Lanaguage (WSDL) driven application (Patient Dashboard, a.k.a. lzDashboard) made entirely in OpenLaszlo (OLZ). OLZ is an event-driven, object-oriented programming language for creating dynamic, data-driven applications. OLZ serves as one good candidate for building formal interfaces that access real patient health record databases. Since information management is a vital essence in the distribution and viewing of patient records, seeking for these resourceful tools will hold greater value and support to the community of users.
New plan...
So rather than going with my original plan of rebuilding this exact tool layer, I've decided to consume this resource by including it in a live source code management environment. Obviously, Medsphere isn't absolutely there with providing a central repository due to strict litigation and licensing. However, their open source awareness is pretty much their lively hood. Medsphere has gone through many changes recently and some of which have had an enormous impact on myself and others. They recently updated their website which now looks very much like a Web2.0 site, and are now participants of the popular social networking service, called Twitter. As for the rest, they are still considered the high-end advocates of health and technology related informatics. So, I've decided, with granted permissions from Medsphere associates (Ben Mehling) to allow me to migrate OVID to some suggested SCM (Google Projects or Github). I'm not sure about when the planning will take place, but in the mean time I'll be trying out the OVID library classes and possibly implementing my own extensions or participate in the continuation of Medsphere's OLZ application, called lzVistA. I'll elaborate more on the Rich Internet Application (RIA), lzVistA in a later post.

Devcathlon 1st Milestone: Mockups

2009-03-22T20:41:00.000-07:00

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

2009-03-16T02:27:00.001-07:00

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

2009-03-12T13:44:00.000-07:00

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

2009-03-09T11:11:00.000-07:00

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.

Hackystat Programming 101

2009-02-18T09:03:00.000-08:00

Purpose:

In this blog entry I'll describe my experiences working with Hackystat services and building my first Hackystat program.

Installation:

The installation of the Hackystat services and sensor binaries were fairly straightforward, given the aid of the Hackystat wiki pages and Professor Johnson's very helpful screencasts. All links and provided show notes for the screencasts can be found here.

Building my very first Hackystat App:

The following are two code snippets taken from my first Hackystat driven application which returns back the number of instances for each day of the given month and year, and my test-driven application for determining the max number of instances in a given month:

public class HackyProg1 {

/* Constants */
public static final String SENSORBASE_URL = "http://dasha.ics.hawaii.edu:9876/sensorbase";
public static final String PROJECT_NAME = "Default";

/**
* @param args
* @throws Exception
*/
public static void main(String[] args) throws Exception {
boolean isHost = SensorBaseClient.isHost(SENSORBASE_URL);
System.out.println("Try to contact host is: " + isHost);
SensorShellProperties properties = new SensorShellProperties();
String user = properties.getSensorBaseUser();
String password = properties.getSensorBasePassword();
System.out.println("U/P: " + user + "/****");

/* Check to see if the user is registered with provided host */
boolean isValidUser = SensorBaseClient.isRegistered(SENSORBASE_URL, user, password);
System.out.println("Check to see if this user is valid: " + isValidUser);

/* SensorBaseClient simulates a client instance */
SensorBaseClient client = new SensorBaseClient(SENSORBASE_URL, user, password);
/* Authenticate sensor base client instance */
client.authenticate(); // Is valid if returns client instance back.

/* Display the number of instances per day of the given month and year. Finally give the total # of instances for that month. */
int totalInstances = 0;
for (ProjectSummary projectSummary : client.getMonthProjectSummary(user, PROJECT_NAME, 2008, 11).getProjectSummary()) {
  for (SensorDataSummary dataSummary : projectSummary.getSensorDataSummaries().getSensorDataSummary()) {
    System.out.println(String.format("%s - %s : %s instances", projectSummary.getStartTime(), projectSummary.getEndTime(), dataSummary.getNumInstances()));
    totalInstances += dataSummary.getNumInstances().intValue();
  }
}
System.out.println("Total instances for the month: " + totalInstances);
System.out.println("--END--");
}

}

This was my attempt at determining the max day of instances for a given year and month. Unfortunately I ran into an issue specifying the project for a user given raw sets of data. Because of this, the test application is incomplete.


public class MaxMonth {
private String host, user, password, project;

public MaxMonth(String host, String user, String password, String project) {
 this.host = host;
 this.user = user;
 this.password = password;
 this.project = project;
}

public SensorBaseClient loginUser() throws Exception {
 /* Check to see if the user is registered with provided host */
 boolean isValidUser = SensorBaseClient.isRegistered(host, user, password);
 System.out.println("Check to see if this user is valid: " + isValidUser);

 /* SensorBaseClient simulates a client instance */
 SensorBaseClient client = new SensorBaseClient(host, user, password);
 /* Authenticate sensor base client instance */
 return client.authenticate(); // Is valid if returns client instance back.
}

/**
* Returns the day containing the the maximum number of sensor data instance give the month and year.
* @param m - month
* @param y - year
* @return
* @throws Exception
*/
public int getMaxMonth(int month, int year) throws Exception {
 int maxDay = 1; // 1-31
 SensorBaseClient client = loginUser();
 int totalInstances = 0;
 for (ProjectSummary projectSummary : client.getMonthProjectSummary(user, project, year, month).getProjectSummary()) {
   for (SensorDataSummary dataSummary : projectSummary.getSensorDataSummaries().getSensorDataSummary()) {
     System.out.println(String.format("%s - %s : %s instances", projectSummary.getStartTime(), projectSummary.getEndTime(), dataSummary.getNumInstances()));
     totalInstances += dataSummary.getNumInstances().intValue();
   }
 }
 return totalInstances;
}
}

public class TestMaxMonth {
/* SensorBase test instance 'overwrites' SensorBase properties */

/* Test server host name */
private String host = "";
private String user = "anthony@hackystat.org";
private SensorBaseClient client = null;

@Before
public void setUp() throws Exception {
 Server server = Server.newTestInstance();
 host = server.getHostName();
 /* Registration test will do the following:
  * Create the user and not send an email
  * Set the password equal to the user name.
  * */
 SensorBaseClient.registerUser(host, user);
 assertTrue("Testing registration", SensorBaseClient.isRegistered(host, user, user));
 /* Test will fail if JAVA MAIL is NOT installed properly */

 /* Authenticate newly created user client with test sensorbase server */
 client = new SensorBaseClient(host, user, user);
 client.authenticate();
 /* Send data from client to host with new user */
 /* Setting raw sensor data fields */
 SensorData data = new SensorData();
 data.setOwner(user);
 XMLGregorianCalendar tstamp = Tstamp.makeTimestamp();
 tstamp.setDay(3);
 tstamp.setYear(2008);
 tstamp.setMonth(2);
 data.setTimestamp(tstamp);
 data.setResource("/Users/hackystattest/TestHackystat.java");
 data.setSensorDataType("Build");
 data.addProperty("TypeOfBuild", "Development");
 data.setTool("Eclipse");
 client.putSensorData(data);
 tstamp = Tstamp.incrementHours(tstamp, 1);
 data.setTimestamp(tstamp);
 client.putSensorData(data);

 tstamp.setDay(15);
 data.setTimestamp(tstamp);
 client.putSensorData(data);
 tstamp = Tstamp.incrementHours(tstamp, 1);
 data.setTimestamp(tstamp);
 client.putSensorData(data);
 tstamp = Tstamp.incrementHours(tstamp, 1);
 data.setTimestamp(tstamp);
 client.putSensorData(data);

 tstamp.setDay(20);
 data.setTimestamp(tstamp);
 data.setSensorDataType(null);
 client.putSensorData(data);

 /* Return data given user and timestamp */
 SensorData returnedData = client.getSensorData(user, tstamp);
 assertEquals("Testing returned data", tstamp, returnedData.getTimestamp());
}
@After
public void tearDown() throws Exception {
 /* Delete the user */
 client.deleteSensorData(user);
 client.deleteUser(user);
 assertFalse("Testing deletion", SensorBaseClient.isRegistered(host, user, user));
}

@Test
public void testGetMaxMonth() throws Exception {
 int numInstances = client.getSensorDataIndex(user).getSensorDataRef().size();
 assertEquals("Testing number of sensor data instances", 6, numInstances);

 String project = "Default";
 MaxMonth maxMonth = new MaxMonth(host, user, user, project);
//    assertEquals("Testing getMaxMonth", 6, maxMonth.getMaxMonth(3,2008));
}
}

Overall, I still have very much to learn about using the provided Hackystat API's. Hopefully in the course of a few more days, I'll gain a better grasp on resolving my earlier issues.

ICS 499 - BMXNET, the next step

2009-02-05T10:59:00.000-08:00

Purpose:

The purpose of this proposal is to gain minimal insight into electronic health record systems (EHR), and to explore the possibilities of developing an open source component to enable greater extensibility and interoperability for development platforms.

Introduction:

The Indian Health Service (IHS) is an organization under the U.S. Department of Health & Human Services (HHS) that provides health care services for American Indians and Alaskan Natives through federal IHS, tribal, urban-operated facilities and programs. The scope of its health care services have expanded into over 500 health care facilities composed of hospitals, health centers, school health centers, health stations, satellite clinics, and Alaskan village clinics. IHS and the U.S. Department of Veteran Affairs (VA) are long time collaborators in the tradition of health information and technology advance sharing. In 1984, IHS picked up on the VA's very own "VistA" medical health information software (not to be confused with Windows Vista) and renamed their version of the system to "Resource and Patient Management System" (RPMS). RPMS is one of the most notable and successful adaptations of VistA health information systems. RPMS is a decentralized, conglomerate application composed of 60 plus applications fitted to work independently or in unison. The software modules can be broken up into three main categories: 1) Practice management applications that consist of patient registration, billing, scheduling, etc., 2) Clinical applications that directly support health care planning, delivery, management, and research, and 3) Infrastructure applications that consists of the management, development and communication tools of RPMS. Our main focus will be on the infrastructure of RPMS by utilizing the tools associated with it, including VA's Kernel package manager system, and the all important VA's FileMan as RPMS's database management system.

Problem:
Currently hospitals and clinics pay millions (in Hawaii $20-50 million) just to implement a commercial enterprise medical health record software. What can we do to reduce the cost and increase support for our hospital clients? Also, developing GUI tools for medical health record systems require prior knowledge of old languages like MUMPS or clunky looking GUI's for reporting patient data built in Delphi. How can we increase the support and ease the pain for future developers planning to write Electronic Health Record systems (EHR) but have to adapt to decades of tradition?

Solution and Goal:

Amongst the various tools and applications written for RPMS, there is one with the sole purpose to communicate to a level of .Net supportive applications. This component is called BMXNET. BMXNET is a .Net specialty tool that provides disconnected row set technology for linking .Net applications with RPMS. This built in library gives the ability to communicate with RPMS by simple query statements (SQL data definition language) to access patient records and returns them in a familiar .Net data structure. So with that fact in mind, why don't we build a component that utilizes BMXNET to support multiple runtime engines such as Mono and Java. By doing this we will improve the interoperability of development platforms and give developers a greater range of environments to develop GUIs for EHR systems. Simply, no more looking at dirty, old 60's code written MUMPS. Let's eliminate the thousand lines of code that you know can be done better in another language more comfortable to you as a developer and meets todays expectations of Object Oriented Programming. This will also save hospitals millions in costs for purchasing the EHR software (plus tech support) and hopefully create a more aware community of open source developers for bettering the health care industry.

The next step:

In the past week, I've had the chance to dive into two documents regarding the setup and running of BMXNet. These user, technical/developer guides can be found directly from IHS's home site here. The user guide helps first time developers new to BMXNET get started in using the classes of ADO.NET and integrate them with BMXNET (now .NET 2.0 framework supportive) technologies, while the technical guide gives the infrastructure of BMXNET. I will begin within the next few days by rolling out a test/development server for installs of RPMS and GT.M's compiler for the standard M (MUMPS) language. Hopefully by then I'll be able to communicate from a .NET application (written in C#) to RPMS via BMXNET. The next steps will be to figure out a way to translate these exchangeable commands to be consumed by another runtime engine besides C# and the .NET environment platform (the conversion and eventual goal). At this point, Mono seems to be the easiest but we can't rule out that its fully .NET compatible since it merely provides a portal for Windows .NET applications to be ran in Linux.

Devcathlon Code Reviews

2009-02-04T14:45:00.000-08:00

Premise:

In this blog entry I'll be reviewing three code bases (including my own) for the mock up implementation of our game project, called Devcathlon. In the following reviews, I will pin-point the good and the bad of each code base and hopefully that will give certain insight into future designs for this project. Although not all issues will be addressed, I will certainly mention ones from my experiences in building these mock ups and my understanding of the game.

The Reviews:

I will try to section off each review with the following outline:

Functionality and Features:

Can the user login?
Does the user have the ability to create or edit form elements, such as personal, team or team member information?
Is there a way to create event matches between two or more teams?
Is it possible to make record of or reputable proof of pair programming?
Are the points properly assessed and clear?

Aesthetics:

Did they embed useful technologies, such as Javascript, CSS or XML? (also including external widgets or libraries)
Are the points nicely displayed and easy to the human eye?
Does the user interface (UI) make effective use of screen real estate?
Does the user interface provide a logical structure? Is the organization consistent from page to page, or do different pages have completely different layout.

Ease and seamless:

Does the user interface enable the user to accomplish common Devcathlon tasks efficiently? How many "clicks" does it take to accomplish common tasks? Is the information you need to accomplish a task available on the screen?

Do the data input mechanisms facilitate correct entry? For example, if a date is required, does the UI provide a calendar widget, or does it require the user to type the date in as text?

Overall summation:

Does all the above information give the website cohesive enjoyment of a game? Also, does the website leave room for possibilities outside of its initial domain?

Mock up 4:

Mock up 4 was certainly a round up of many things experimental. It worked out like a sandbox for possible fun changes and re-works of existing features. I, along with two other members had a personal involvement in this implementation of Devcathlon's mock up 4. We based our implementation off of the unique design employed by one of our members' previous mock ups. This initial mock up had everything needed, including drop-down menus and an overall social network-like feel for design. In many aspects, the implementation in its "mock up" stages felt almost like a real world web 2.0 website.

Functionality and Features:

Mock up 4 has all the features expected for any website. It has a login and sign up page, home page for introductions, and help pages for hints and usages. It also strengthens its features by utilizing its fully expandable drop-down menus, making it easier to navigate through the site and finding its subsequent pages. Along with signing up for an account with the website, this mock up enables reusable forms for creating/editing a user's personal, team, project or match information. Upon logging into the site with proper authentication fields (login and password), the user is presented a welcome screen and their common functions, including links to the user's public/private profile, a team, match creation page, match invites, self-report requests, and site-wide announcements beneath it all. The public/private profile page provides an abundant set of information about a user and their involvements in teams, projects, and matches. This profile page is the center of every Devcathlon user's life. It provides information on the user's standing (system wide rank), recent achievements and matches, currently associated teams and ability to post/reply to comments underneath. To the right of all of that, the user is given email notifications in a personal inbox. This functionality of an inbox is still debatable amongst other designers, but it is a feature that has no bounds for possibilities. The only reason to include a personal inbox for Devcathlon is to provide convenience to the user, but hinders the fact that the information is repetitive and can sometimes be annoying if a person sees it both in their email and upon logging in. Also, beneath that is a list of the possible actions the user can take for interacting with Devcathlon (similar to the welcome page: create team, match, self report, etc.). The forms are in fact very reusable and encompasses the full gist of user interaction within Devcathlon. So it is important to get these forms to seem quick and convenient for the user. All the action links mentioned early will be representing in a form field-set fashion. For the team creation page, a user is able to search for existing teams, other members and projects. The parameters for the team creation page includes all relevant text to get the user started, including the team name, team type (appropriating members relations by organization, friends, etc.), team project definition, and an about section. Although this page needs more work in functionality, the intent is quite clear that we would want a dynamic page rendering both a search for existing teams, members and projects, and the ability to create a fresh new team on-the-fly. The match creation page also provides a comprehensive coverage of all required inputs for creating a match. It intelligently populates a drop-down of options including all your team and project involvements. There is a section to invite teams, but it doesn't follow the organizational structure of rendering a search for existing teams. In actuality it has a text area box for text input separating each team name with a semicolon. I feel that this is a bit ineffective and inconsistent with the team creation page which included the search. Other parameters for the match include the time period of the match (start and end dates), minimal score settings for commits, builds, and test coverage (which can be expanded for more customizable settings). Self-report request is another debatable matter that needs further nurturing for full acceptability in our game. However, in mock up 4, we dealt with this problem by asking the user to provide a brief description and picture for proof of the project being worked on. A neat product of this is that you can challenge other teams for self-reporting, as well as submit your own for pending assessments. This idea still needs valuable time to test in order to resolve issues involving point assignments and ethic values (the integrity of the feature to no be used to ones advantage through malicious means). The last action is for accepting or declining match offerings. This accept/decline match page provides a quick summary of the match for the team member who chooses to "accept" or "decline." Now, moving along the top navigation bar, a user is also able browse Devcathlon user profiles. This is another iteration of the technique in utilizing some kind of search for our persistent display of records. This will provide better "coverage" in linking our site together by means of relations and/or associations. Each page, including the gallery, match, team, or hall of fame features areas for knowledgeable information of awarded/deducted points of a team and its members.

Aesthetics:

Admittedly, this is the most acceptable looking Devcathlon mock up from our first initial mock ups. It is evidently so, since the mock ups here on after utilize this very same CSS and navigation bar. Initially, the first thing they will see is the site's initial home page (public view). This page provides information regarding the motivation of our site and link to forms for account authentication (log in) or sign up. At this stage, the public view is quite elementary and not very elaborate in design. The layout simply has a header, a logo area, navigation bar, main content, and footer for notes. The public view also limits the information and access to certain pages of the site.

When the user signs into the website, the first thing they will notice as they hover their mouse over the navigation bar is the very responsive drop-down menus and sub-menus. The chromed-like tabs have a significant depth as you hover over it, and makes for a fairly readable and fun user interaction. The font settings are also readable and it makes some use of titling, large or small text, and bullet-points. Links are also distinguishable by underlining the link text as you hover your mouse over it. The color scheme somewhat conforms to the Hackystat look with a few tid-bits here and there. Each page uses up the real estate fairly well, by populating information where it is needed or centering the content through divs. When you navigate over to the "My Team" page, you'll notice the compactness of all teams related to the logged in user. As you hover over a team, the element is highlighted, indicating some user interaction and implying a click-able object on the page. When the user clicks on the tab it expands out listing quick information about the team and team members. The magic behind this features lies in the classes written in Javascript by Adobe's Spry Framework. This JS includes the timed effects for the collapse and expansion of each tabbed panel. The motivation behind this is to increase user focus in interaction, save real estate, and to minimize users from scrolling up and down a page too excessively.

As you navigate further, following the clickable links you will notice again the usage of this collapse and expand feature for displaying multi-formed information that's nested per person, team, and match. You might think, what if the tab panels get to be too long and excessive themselves? Yes this could happen, thus we will propose a simple anchor system for referencing page content elements (like chapters in a book). This will enable users to jump back and forth between sections of a page.

On the match page, there is a nice fight-card line-up for players to easily compare teams in a match. The only flaw behind this is the possibility of having lots and lots of teams per match. Because of this, the real estate of our page will grow out of the scope of the content and will most likely make it harder for users to navigate or compare.

Also, the rows of each table have hover interactions indicated by color changes as the user passes over the top of it.

Ease and seamless:

The overall navigation is fairly self-explanatory. Links are easily distinguishable with underlines, borders, and color highlights as the mouse hovers over the text/object. The effectiveness of each page is quite seamless and comforting for any first-time user visiting the page. Information is linked wherever the sub-pages are needed and can be previewed using the collapse/expand feature of the tabbed panels. When the user commits to viewing a certain page (eg: team or match) then there is a separate page for it as well, thus giving the content of each page enough air to breath within its subject matter.

Overall summation:

I think it is safe to say that this, and all the other mock ups have intentional room for expansion. The difficulty in saying that is in the consequence of not knowing exactly which path to take for expansion. There are multiple routes to consider and they might not all lead to extraordinary UI's.

**Please note that a lot of the analysis in the first mock up will carry similar descriptions in both mock ups 5 and 6. Thus they will be shorter, and will only expresses dissimilar features from the first.

Mock up 5:

Functionality and Features:

When browsing over to the "My Matches" page under "My Profile" there is a clear list of all matches associated to the user. The listing also indicated which match is currently marked "active" or "complete." After clicking on a match for extended details, you'll also notice a nifty table showing all recent points. On the same page, if you click on "see details" then it will display a history of all points between each team in the match. It also gives a time stamp of each event and its corresponding points gained or deducted.
Aesthetics:

All lot of the CSS and page layouts were fairly similar to the previous mock up.

Ease and seamless:

The links were very clear and simple to follow.
Overall summation:

The history of points received for each match and team is a great feature and must be incorporated in a similar fashion for our future Devcathlon game.

Mock up 6:
Functionality and Features:

Mock up 6 employs a very strict set of levels for player achievements. The level definitions follow a military standard of badge ranks.

Another unique feature lies in the "My Matches" page. This page includes history listings with weekly reports of team accumulated points. This could prove to be a better way than simply listing a full history and time stamp of each consecutive event in one long table. We could break things up in the weeks and months depending on the elapse of the project and its total project life span.

Overall summation:

Mock up 6 also made an attempt to explore the possibilities of integrating Devcathlon with Hackystat. This idea seems great, yet it takes away the pure independence of this game. By placing Devcathlon as just a tab in Hackystat, then we are confined within the territories of Hackystat. On the flip side, the concept of using the data records of Hackystat should be supported for our application. I think that by reusing the account information supplied in Hackystat, we can possibly pre-populate the team and project definitions automatically for our Devcathlon players.

UI Suggestions:
Provided the three mock ups, I will make some recommendations regarding the design and function of Devcathlon. I will base my design off of my own Mock up 4. All of my previous comments will still apply. The only thing that still bothers me is the fact that pair programming is in all difficult to track due to consequent ethics of the game. To solve this issue of pair programming, I would like to implement a system of discussions per code event or issue. This will be recorded by our google discussion board (created for Devcathlon projects or teams) and assessed either amongst group members or members of another team. So by following good programming practices, every programmer is required to code on part of a particular issue or task. If the user confines to those guidelines as they are assigned to them by the team, then the user is considered "on task," otherwise "not on task" (for point deductions). Other than the issue raised about pair programming, the design patterns in Mock up 4 makes for a good starting point for our future implementations regarding UI's. One thing that lacked from Mock up 4 was a system for levels. We had an idea of using human evolution as a way to advance or mature a player, but it has hidden implications that might offend a few people. Because of this concern, I would consider Mock up 6's standard for leveling a player through military ranks. It sounds more formal, yet it gets to the point and seems to feel more natural. Another neat detail given in Mock up 6 is the way of sectioning timed events by months, weeks, and days. This way, we can store and retrieve our data records more easily in these timed archives. The idea is very similar to how Blogger organizes each blog post by month, year and/or by subject.

Conclusion:

I'm still tempted to say that the overall enjoyment of the game is still up in the air, since there are still little interactions between players and possibly gameplay. Plus, this observation is only from my perspective of creating these mock ups. Perhaps, getting into the game and actually experiencing the behavior of each functional feature will give better rise to the actual game as oppose to just pure speculation.

Resources:

Mock up code bases: http://code.google.com/p/hackystat-ui-devcathlon/

Monitor code changes: http://code.google.com/p/hackystat-ui-devcathlon/source/list

Devcathlon Mockup Part 2

2009-02-04T05:59:00.001-08:00

Premise:
In continuation of the previous two blog entries regarding Devcathlon, I will again review my experiences and concerns in this second part iteration of Devcathlon's mock up site. I will also briefly mention additions to our events list, the concept of "badges", and levels.

Designer <=> Developer:
This is my second iteration of mocking up the interface design for Devcathlon's site. I noticed that the first mock up proved to be a challenge since it used to be easier to just pass the design stuff over to a professional designer, and not have to worry about it. This kept the designing and coding schema separate and provided production boosts (through specialization) for the overall project. However, in these past two mock ups I was able to wear both hats of being a developer and designer. First and foremost, CSS is a prevalent skill. I say this with confidence, because any markup text in this day and age requires the usage of CSS. Do whatever you can to muster the basics of elements, tags, descendants, etc. CSS will be heavily used in your HTML and it's a proven to simplify a lot of styling out of your markup (keeping HTML basically what its good for, which is rendering text and links). I think the terms of a "developer" or "designer" can be interchanged and used similarly in certain situations. Considering the objective, problem or solution, either a designer or developer will look at it in terms that are not all that distinct. When a programmer programs, he or she technically has to "design" themes from real world entities that can be classified as classes (in OOP languages today). Even though when the programmer thinks that he's "programming," in fact, he's actually designing before even writing a single line of code. On the other side of the coin, designers are faced with the fact of creating something usable, appealing to a user, and seem less. So, designers simply create GUIs in the front-end of the spectrum, yet they transmit some work flow details of a user. The work flow of a user is the interesting part of being a designer. At the stage of getting the "look" down, a designer must also take into consideration for the "feel" of what they are building (eg: buttons, links, forms, etc.). These interactions are crucial and play a large part in the functionality and behavior of a site.

"Eventful" Additions:
My team and I came up with two other simple events regarding the basic units of building and coverage. A team member can build to success or failure depending on circumstances of frequency and trend relations. If a person builds frequently, and does so over a certain period of time without significant changes to the code, then that person gets penalized for "unnecessary building" (vice-versa). The other concept deals with the almighty relation between writing test code and coverage. Instead of just looking for an increase or decrease in the level or percent of coverage, we will also include the relational trend of the graph. Some relational dependencies to this event include: early test cases and incremental coverage gains. The trend (provided by Hackystat) should help in determining early built test cases for basic class or method functionality. From there on, we detect any fragments of change in coverage (gains or loss). If the user continues following the good practice of writing his tests before integrating the app any further (test driven development), then he'll benefit in the long run of the game. As for those who don't change much in coverage and remain stagnant throughout will suffer penalties.
The concept of "badges" is not a new topic, but it has been highly mentioned when dealing with determining valuable players in the game or team. Badges are awards (almost like mini trophies) given out to individual players who achieve certain number of plus points.
Another concept was the idea of "levels" for a player or team to achieve a certain number of points to advance. A player or team can advance to levels through a system of recognized achievements. Just to add some kicks and giggles, we followed the concept of human evolution with imposed implications of software engineering as the end point of the time line.

The code and other resource materials can be found here: http://code.google.com/p/hackystat-ui-devcathlon/

Devcathlon site mockup

2009-01-26T02:06:00.000-08:00

Overview:
This past week my group and I were tasked with mocking up the general features of our game, called Devcathlon. To learn more about Devcathlon, please read the blog post prior to this one or head on over to http://code.google.com/p/hackystat-ui-devcathlon/.

Planning:
Generally, I approached the mock up of Devcathlon like any other website. The parts that go into a website are apparent and can be easily modeled by notable ones like Google, Blogger, or Facebook. It seems to be a must, in today's standards of Web 2.0 to have Ajax functionality and dynamic webpage access and retrieval. Unfortunately, our mockup didn't express those characteristics physically, but the idea is still quite enforced. I thought of the application as more of a social website. So the basis of this application is very much that, it had to be socially adept and capable of growing. Users should be able to communicate with others in a personal or public matter depending on what the situation calls for. Designing the structure of the site wasn't very specific, but it had to be standardized. We simply broke the site into two parts, the public and private domains. The public section of our site is a simple "tour" for any outside user who is willing or just curious to explore our site without a direct account. Of course, for any alien who comes near our site, we restrict them access to certain elements or retract any links that only should be seen by registered users.

Site work flow:

* Public user enters site's home page. He or she is prompted for a login/password.
* User enters a valid login/password, then gets redirected to his or her's profile page.
* The logged in user is able to edit their profile as they please, add/remove/update teams and matches.
* Registered user could also search and associate with existing teams or matches.
* Every user is provided a personal and public profile.
* When a match is declared then it is marked as a user event and should message the user under their recent activities.
* When a user gets prompted by an administrator, then that information is displayed under notifications.

Besides dealing with site administrative tasks, such as creating a user account and modifying profile settings, we also focused on important questions dealing with how the game should work. One idea that I posed (as mentioned in my previous entry) is to possess every user/player the ability to create stories/tasks for themselves as the project/game progresses to a goal/objective. Creating these special “stories” is another way of saying a developer creates an issue on an issue tracking system (Google Project Hosting). Upon generating these stories, other players can either interact or discuss (Google’s issue discussion groups) about a particular subject and trade off ideas through post entries. This way players will interact with other players and thus resolve some obtainable “mini” goals. Mini goals can also be known as a milestones or phases in a project development (stages or levels in games) that give players awarded advances and points for their achievement. All of these aspects are simply ideas, but we have yet to encounter the facts of reality in creating such a world for them to exist in. Hopefully in our next increment of this project, we will dive into those concerns in more detail.

Conclusion:

Mocking an entire website from scratch is particularly difficult since website designers need to anticipate every move. Every form built was either doodled out or envisioned multiple times before getting it right. Most likely changes will be made after the mock up, so I wouldn’t be surprise that we would keep or discard certain elements from the current design. Unfortunately, the only regret I had during this process of mocking was the lack of “mock tools.” I wish we had more open source mock-supported development tools for web development. Maybe they won’t reach the same standards such as high competing tools from Adobe’s Creative Suite, but we need to start somewhere to ease the process.

What's in a game?

2009-01-17T12:45:00.000-08:00

Overview:
In this brief blog entry, I'll explain the concepts of game designing and utilize these tactics to enable a better understanding of my new venture into a project called Devcathlon.

About Devcathlon
Devcathlon is a computer game designed to help improve software development and developers while rating the health of their project. The players include the developers, tech managers, etc, game pieces include the code, quality assurance (QA) tools, etc. Continuous integration is a software engineering practice to help teams speed up their implementation and expected delivery date by providing automation of redundant tasks (such as building code, QA builds, maintaining a code repository, etc.). The concept of the game is derived from a collection of continuous integration practices that should be second nature to most software engineers/developers. The goal of this game is to provide an educational way of keeping a developer on task with such practices. Once the developer sees that the game is not just a way of racking up points and envelop in certain bragging rights, but it also fuels the notion that you are really just competing with yourselves. The self-improvement of an individual will contribute to the overall success and health of a project.

So far, we understand the motivation of the game we are trying to create, but we have yet to capture the attention of what a game really is and how to go about from creating a successful one.

Designing a game
What's in a game? What is the effective game design? The methodology behind the creation of a game is undoubtedly its high standards in the designing process. Let's first define the meaning of a game and the essence of a computer game. A game is basically a contest of rules designed to have multiple players making strategic decisions to achieve a specific outcome (winning). In computer games, the definition is not all that different, it is a software program in which one or more players make decisions through the control of game objects and resources, in pursuit of a goal. The make-ups of a game is fairly simple, yet the complexities lie in the makings of the game. Every computer game consists of players that interact with or against each other to obtain or reach an objective/goal. The players provide a variety in a game. Each player has a personality and it shows as they make decisions in the game. Another resource that's prevalent in this game is the game objects. Game objects or resources are the tools that equip a player in the game. These objects are either given or obtained as the process of the game continues. Every game needs an obtainable goal and objectives leading up the climatic conclusion of a game. The interesting part about the goal of our project is that it is fairly non-aesthetic, very virtual, because it is meant to educate a developer and his team. That is the higher logic of our goal, yet it sets apart from the "mini" goals needed to achieve a higher standing in the game. In a competitive thinking process, you are trying to out think your opponents, and gain an edge in winning the game. In our situation, getting an edge is a matter of how motivated you are to keep up with tasks relating to your development environment. Some questions would be: Is the user doing daily builds like he should?, or Did he make his 1 of three commits for the week?, etc. Is it possible to have a competitive edge in our game without tiring the player? Can we relieve a team by rewarding them for good behavior? In every good game, there is a matter of aptitude decision making on the part of the player. They make decisions to either square against a demon from hell or choose to run away and find shelter to level up. These questions are posed to the player and in relation to the outcome of the game. How will decision making be incorporated with our game? What will we need to give developers a crux in the game where they would have to choose routes? Another matter is the dealing of balance in a game. For example as players play the game, they are ranked on the games scoring report, and from that we rank #1 as the winner of the game. But in our situation ranks are not set, in that I mean there will be times when other development teams who play Devcathlon will have a succeeding or lost for one day. So to say that balance is in the game, then we have achieve at least that much in the process of effective game designing. The other hot topic goal of gaming is the feeling that the player feels mentally "immersed" in the game. Every successful game gives us that feeling of importance for a character and its relation to its environment. As players become more involved to the grounds of what they are trying to achieve, then the soul purpose of the game becomes more apparent.

Conclusion:
When it comes to creating a game then every detailed manner has to be addressed clearly and reasonably. The design process is a key aspect in developing a coherent game. The pieces and the overall concept or objective is primary to when drawing an audience of players. Once a developer has a product concept in mind, the next part is to involve drilling into the details of each subset piece of the game, then analyzing how each piece will integrate with each other as a whole.

Open issues and ideas for Devcathlon
One of my main concerns is regarding the blind processing of pair programming. How will this issue be dealt with? We can probably create options for pair programming and delegate points depending on the difficulty of tasks (changes via code base) and number of participating members. Another interesting topic not mentioned heavily above is the concept of artificial intelligence. Possibly in a more stylized situation will we need such a component where the computer itself will challenge our players rather than just having our players go against themselves. However, one situation would be to supply a "tutorial" of Devcathlon to simulate a good, bad, and okay development project environment given a default sample program event. The process will detail the scoring and correct moves to be successful in the scoring high in the game. Player interaction with other players are somewhat limited to the design of Devcathlon. Possibly communication is dealt with elsewhere from the system, but there is no good way of knowing that. One way to solve this is to have conversational story boards, where each developer is required to write a "story" before hand, to describe his/her intention in a very technical manner (using bullets etc.). Each story will be in conjunction of a task (provided by issue tracking). For every story there is a twist, given exceptions where the story teller doesn't know the ending. So another team member jumps into provide a more complete "ending" to the story. These interactions will be mapped out via issues and marked as "dependent on" another issue number. We can score a project on their effectiveness of communicating with each other and issue management! Of course, this is only a very rough draft of what's to come. Hopefully when our development team gets into the nuts and bolts of this project, only then will we know exactly what is effective or not.

Resources:
http://code.google.com/p/hackystat-ui-devcathlon/wiki/References

Other resources:
The Art of Computer Game Design by: Chris Crawford
http://tinyurl.com/dmug

This online book explains the artistry of creating a game. Although the time period of which this book was written seems old, I have to still consider this a good starting point for any game developer or gamer to grasp. The thing that drew my attention the most was that it provided history about the evolution of gaming and the growth of the gaming industry and users. He starts out giving a good two chapters worth of information about what a game really is and different gaming genres. The author also speaks about the future of gaming and its implications on our world's society. He also addresses many predictions that are very true in our community today. The book also describes the game design sequence which lays out a general sense of what computer game developers can do. The author merely presents his generalizations and habits as suggestions rather than a strict set of processes which readers will find very coping.

A Primer for the Design Process, Part 1
http://gamasutra.com/features/20000630/huntsman_01.htm

This interesting, yet incomplete article dives into the concerns of gaming and the market as to inter-relating things. It follows a more business approach for real world game developers, and makes you pose questions prior to implementing your game. The article serves as a simple planner for effective game designing in the pre-production stages.

Gamasutra
http://gamasutra.com/

Good place to learn and contribute the gaming community.

Java Game Development
http://www.gamedev.net/reference/programming/features/javagame1/

Describes the technical details of creating a full-fledged game using Java as the platform for development.

GameDev.net
http://www.gamedev.net

Is yet another great place to attribute the philosophy of game designing and further education of games.

DueDates 2.0 Wicket App

2008-11-24T02:25:00.000-08:00

Premise:
We've been working on the project DueDates since the early month of October. Since then I've had my eye set to get to this stage of our application. I'm excited to say the least that this application has just achieved status as a genuine web application. In this 2.0 release of DueDates, it has been re-factored many times, re-designed for expandability, and fixed to interact more effectively. I'll explain the process that brought us to this point in our application and what features you'll find different from previous increments of DueDates.

Project's page: DueDates-polu
Group Members:
John Ancheta,
Anthony Du,
Yasu Kaneshige,
Erin Kim

Process:
I sometimes have to remind myself that the process is just as (or even sometimes more) important than the end result. It is especially applicable in group projects such as these. I'm proud to say that this time around I was grouped with some very strong and talented individuals. By being surrounded with this kind of environment, I felt that the knowledge sharing was much more of a solid ritual rather than an obligation. It was easy to get in touch with one another and no one felt left out. Everyone had an equal set of tasks, and we frequently spoke outside of class about the project. I also felt a sense of security, since we started very early on in this project. It felt great since the project had fresh new faces and ideas regarding the application. It was easier to communicate our ideas and worries effectively since we chatted on Google talk and Gmail (thank you Google!). So we often sat around the camp fire and discussed about which tasks needed to be done and accomplished, and for which days they needed to be integrated. We followed the concept of working fast to get things done to achieve functionality, and save room for later enhancements. I have to admit that we didn't follow the agile approach of Test-Driven Development, but eventually our testing and coverage caught up to us. It was inevitable that testing was a key aspect, but we kept it in the shadows for awhile since we were predicting a quick end-time for this application. Practically the first week was pushing to finish all required tasks needed for this web app. We did so, since we all wanted an enjoyable Thanksgiving holiday. As the days progress, there on after we kept on improving the look and feel of the application, little by little we also added new features and stripped out unnecessary pieces to enable a more defined product.

Setting goals:
One of our group members made a very nice calendar describing our jobs during the span of two weeks. This made it easier to see what we had planned ahead of time and what things were tasked to who. The breakdown of the project was very clear. Each set of tasks were derived from these milestones:
R1) Support an XML configuration file.
R2) Basic DueDates functionality
R3) Basic DueDates functionality w/ CSS.
R4) Provide sorting
R5) Filtering
R6) Email Alerts
Since we have an even group of 4, it was easier to just have two pairs working on a couple of milestones. Although the pairs were established, we still looked to each others skills to accomplish certain tasks that were related. I had the pleasure to work on R1, R2, & R4. Possibly the coolest thing out of this whole project is just the idea of building a web application using Wicket. Initially we imported a previous project DueDates-blue-v1.2 as our base code, but many aspects in the design needed to change in order to suit the needs of building a Wicket application. More things needed to be added, but basic functions enabling the features were pretty much solid. It was safe to say that we almost had everything needed to finish this application. We simply needed to provide a GUI for what we had previously built in DueDates-v1.2! The online Wicket example apps and Wicket API was a good place to absorb knowledge and derive simple practices for common tasks. I enjoyed looking at the API as a resource guide to understanding the structure and formation of components/models/markup. Soon after assimilating the facts and concepts, the transition from novice Wicket developer to intermediate Wicket developer was easy.

Layout:

Index page - contains the user login prompt.
Home page - contains the listings and the core purpose of the application.
Alerts Preference page - contains a set of options to enable a user to set alert processes.

Features:

Currently we support user authentication in a localized setting for users. In later enhancements, we will start looking into creating a database back-end using Derby's Embedded/Network Server engines which will require the user to register upon first visiting the page.
Support libraries, including: University of Hawaii @ Manoa Library & Hawaii State Library.
Customizable alerts and options to filter results of due dates listing. Background processing is another topic that would enhance our alert system.
Capable of retrieving and updating multiple libraries at once.
Easy navigation links.

ICU of our project:
I can't rule out that our project was properly assessed by Hackystat. We each had problems with it not sensing our data, or not reading our number of commits, builds, etc. Overall, the data does somewhat describeseach individual's participation in a fairly accurate manner. Currently it's the closest thing we have to gain statistical evidence about the health of a project and its affecting members.

Conclusion:
Everyday meant progress, someone was either working on the css, the html simultaneously, or spicing up a functionality for a page. We each had a hand in the making of this application. I'm very proud to say that I could be a part of it. Although we didn't successfully pull off the database back-end or background-processing, I hope that we'll revisit them sometime in the near future. As for now, the application is in good shape for general use.

Resources:
DueDates Project Page: http://code.google.com/p/duedates-polu/
User's guide: http://code.google.com/p/duedates-polu/wiki/UsersGuideWiki
Developer's guide: http://code.google.com/p/duedates-polu/wiki/DeveloperGuide

Other Resources:
Hackystat Project Page: http://code.google.com/p/hackystat/
Apache's Derby Home Page: http://db.apache.org/derby/

Stack on Wicket

2008-11-21T14:38:00.000-08:00

Premise:
The purpose of this entry is to explain my experiences on creating my very first wicket web application written in Java. Wicket is a web framework written in Java and its sole purpose is to create web applications. More information regarding wicket and the tools I used to deploy my application can be found below:

Apache's Wicket Framework WICKET
Tools and dependencies:
JETTY
SL4J

Stack-wicket:
My very first wicket application is very similar to my earlier blog entries about stack. This application proved to be a good starting point to get to know Wicket's framework. I started out by creating a Wicket Form, and made the subsequent labels, an input field and submit buttons (push, pop, and clear), and results table to layout my application. After successfully starting the Jetty server and running the application through the browser, then my next step was to add functionality to the buttons I had previously created. Before adding the functions to the buttons, I created a session class to handle multiple user's by keeping a copy of the user's stack and variables (input field) in a session. Next comes the easy part, adding functionality to the buttons by creating anonymous ("on-the-fly") classes. I never knew there was a name for on-the-fly classes that really comes in handle when you need to just tweak a few override methods (onSubmit()) without having to create a new subclass.
Issues:
Upon creating this application, I ran into a few bumps and annoyances. One thing that bothered me the most was configuring my environment to support wicket and its subsequent dependencies (.classpath, build.xml). A lot of these issues were minor, but it's quite detrimental in a sophisticated application like this. Other than configuration issues, I also had ones that involved coding. Many of the coding issues were reported back from running "ant -f verify.build.xml," one of which involved serializing the Stack class. This, along with a few other modifications were made to the Stack class. After trickling down and resolving all errors from FindBugs and PMD (they're best buddies), I was able to pass verify and run the application successfully.
Download Distribution:
The copy of my distribution of stack-wicket can be found here.

Conclusion:
Overall the application was quite self-explanatory. You create a stack and you have only a few options to operate a stack (push, pop or clear). The knowledge I gained from this experience was basically figuring out a good work-flow for creating web applications using Wicket. I now have a better understanding, along with a process of thinking when creating these kinds of applications. It's something to get used to, and the concept can be easily assimilated into other similar web frameworks.

ICS Industry Day '08

2008-11-20T21:00:00.000-08:00

Today I had the pleasure to catch the last hour of a presentation given by Concentris. I came out of the presentation feeling very impressed about the concept of "meshing." Especially in the military environment and infrastructure, concepts like these are extremely useful in creating applications like video surveillance, intricate sensors, unmanned ground vehicles (bots), VoIP communications, IED response and avoidance, and lots more. The presenter was also reaching out for higher end programmers, such as front-end web developers. I thought, "well yes I have some experience in that... but do I really wanna stick to just doing that for the rest of my career, after just being exposed to all those other possibilities? No, of course not!" So one of the greatest things taken from this experience was my pure sense of escapism from my usual norm. I felt that after being here with my colleagues that I need to diversify myself and branch out to other topics that are foreign to me. Data security and networking have always lingered on the tip of tongues of many of my work associates, and I'm beginning to see its importance in my being an ICS student to know these things. I also had the pleasure to meet with some people from Referentia. Referentia was glad to speak with me first. They couldn't help but see a young face and wanting to talk to them. I'm used to the gesture, given being at job fairs like these, you are forced to shake hands and become engaged. I did that exactly, but it was less hectic since the hallway wasn't heavily packed. Unfortunately I didn't have the chance to witness their presentation, but they were quite informative in giving me a brief talk about what they do and what possibilities they hold within their company. I spoke with one of their interns, who has been working for them for about two years. Come to find out, the intern is actually an Electrical Engineering major but started working on many software-related things. He explained a lot of the tools used in his development environment that matched exactly to tools enforced in my ICS 413 class. It was incredible to see how things like quality assurance tools and continuous software development tools were being applied to real world applications. The main thing I took from this experience was the goals and expectations of companies. I wanted to get to know the skillset neccessary to obtain jobs similar or just like these. Of course, these job descriptions don't scare me since they do also offer internships which prove to be a great way to gain valuable experiences in the work field. I also experienced the notion that diversity in the field of ICS is a must, to gain full knowledge of areas supportive in real life applications. I'll be sure to carry on these experiences into my continuation as a student and future computer scientist.

DueDates: ICU downtime (postponed v1.2 release)

2008-11-17T13:39:00.000-08:00

Premise:
This entry is to describe the efforts put out to releasing our next iteration of DueDates. Unfortunately this entry will be a sad one, since we have not yet released the entry and that things currently suffering from issues.
The ol' time constraint came back to bite us...
This will be a very short entry regarding my experiences this past week of working on DueDates. I will assure you that it was not a pleasant one. Considering the time constraints and last minute changes to arrive to an "elegant" solution. I took the time yesterday to work on refactoring my custom class parser called Argument. The plan went well in separating the options and options with parameters. By separating the two and making them extensible, I made them into separate classes. This made it easier to keep track of options with parameters since now the parameters are contained within a list of the option. I also refactored the LibraryParser class since I felt that it was too overbloated with things and it went against the name of the class being a called "parser". So I stripped it down into two separate classes, one being called DueDatesParser which dealt with argument parsing (extends from Argument abstract class) and the other being called LibraryManager which handled the manipulation of options being passed from DueDatesParser (sort and within functions, etc.).
PMD vs. FindBugs
After testing this fine on my local machine, it was finally time to build the stuff through ant -f verify.build.xml. It came to my attention how much things can break when you think you've got a solid idea going. My utter frustration was over how PMD and FindBugs would not come to an agreement when it came down to overriding equals & hashcode methods. I have a superclass, Option and a subclass of OptionParam. Option implements the comparable interface thus forcing me to override methods of equals and hashcode. In FindBugs, it would complain about the equals and hashcode methods not being overridden in the subclass. So I defined the two methods and just called its super methods (eg: super.equals(obj)). Now when I run ant verify again, it doesn't pass PMD, since PMD is now complaining about "UselessOverridingMethod."
Currently the project is at a halt and I will need to attend to this matter with my partner to resolve this issue. Hopefully we'll get something out and running by the end of today. Newly awaited features such as "-console", "-email" and "-wakeup" are still going to be featured on this next release. However we'll need the time now to resolve these issues first. Sorry for the inconvenience of this release and thank you for your patience.

DueDates on HackyStat

2008-11-07T11:58:00.000-08:00

Premise:
After the release of our DueDates v1.1 project, we've been sitting back while waiting to see how our implementation is being tested and used. So far we haven't had any responses (weren't expecting them), but we will be graded for it as a class project. The purpose of this week's blog entry is to detail my experiences working up to using a software auditing system started by a professor and a group of alumni, called HackyStat. I took the time this week to explore its features and understand its impact in continuous development. HackyStat is truly optimized to help you and your team members better the "health" and quality of your product.

Setup:
Setting up the "ICU" program called HackyStat wasn't such a difficult task. I could understand that it might be more of a challenge for newcomers getting used to using quality assurance tools, but at this point we've surpassed those tasks. Most of my efforts were directed towards getting to know what each of the product's dependencies did. I was also more interested in knowing how it was put together. Yet this blog entry is about my experience using the product, so I won't digress any further from the topic. For long time Eclipse users, Hackystat provides a workable plugin suited to cope with settings in Eclipse. This neat looking .jar file (provided from the project's home page) contains the necessary module to easily install HackStat onto your local machine. Once you install the plugin on Eclipse, navigate over to the server hosting HackyStat. Once you are there, register as a member, verify your email and eventually log in to host your project. HackyStat project browser is the home for all the projects you may have hosted on the live server. You may take advantage of the numerous tools used to assess your project's health, and assists in understanding your project's level of efficiency or defficiency. In many ways it could show the path or direction your team is heading. This notion of knowing what your project looks like underneath a microscope has made me more cautious (but not too cautious) to the details of my enviroment. Of course, this tool does a good job at pin pointing the areas your project lacks and what areas it is excelling at, but it still needs that extra human element to interpret the data coming back. After getting through installing all sensor on your machine and successfully building and sending data to the HackyStat sensor server, what's left for you to do? It is up to your team members to address those issues to better the weak links or connecting factors relating to your project's health.

Experience:
I have yet to explore all the neat features of HackyStat, but in my short experience, I could see the potential of the product. In some ways, HackyStat seems to have this ghostly feel to it. I sometimes feel like I'm being watched, well of course I am, but it creeps me out more knowing that these sensors are constantly doing updates about my progress and assessing my activities. This may be intrusive and a violation of my privacy, but if its intensions are to assess the project as a whole, then my contribution as a programmer and team member of this project is necessary. HackyStat as a whole is a good project assessment tool, used primarily as an "ICU" monitor for your hosted projects. However, HackyStat doesn't assess the matters of the team members individually. As a whole the team members make up the team, but areas that are beyond the reach of HackyStat's sensors are not accounted for. I'm prone to say that these factors can and will inhibit dangers and warnings to the health of your project. You should use HackyStat as an indicator to pick out these flaws and to fix them within the confines of your project group.

DueDates Project (Part 3)

2008-11-03T11:48:00.000-08:00

Premise:
Surprise! We just released our DueDates-v1.1 this morning. The project has had numerous breakdowns and rebuilds since its first code release last month. In many ways we've accomplished some new features and have enhanced a few old features. I'll explain some of the changes (including self changes) and some of the difficulties that we endured during the past two weeks to release this third increment of our implementation of DueDates.

Re-design and Enhancements:
After the first two increments of this project, I've come realize how much planning and thought is needed to get a good, concise and obtainable goal. In my last posting, I mentioned about using a MS Visio-like diagramming tool, called OmniGraffle (only for macs) which assisted me in my planning and development. Likewise, I would like to emphasize how much help this tool, along with all the quality assurance tools, such as JUnit, CheckStyles, and EMMA has helped us in the continuation of our development for this project. This is almost like a thank you note to those building tools which automated the process of that us humans lack naturally. In some ways it has influenced me to program more diligently and carefully. Here's a quick rundown of the changes in design and class structure, and how it has impact the project outlook as a whole.
So I sat down one day to quickly draw out the current stages of our application. It was nothing fancy just a lot of holes to fill in and extra spaces that weren't needed. It was easy to say that a rework would be the easiest. Meaning I could say that working from a clean slate would help clear the pallete of confusion, but I knew from the back of my head that not everything will go as plan if I didn't approach the problem the right way. So I put aside all old tactics and really, in a sense, reworked the way I processed a problem. I thought more about the small steps I needed to take (not too long of course). Every step had its kinks to be worked out and every event thereafter was followed by a branch in another direction. I was more concerned by the path of the project rather than succeeding at the next step. This methodology I built myself gave me some room for errors, but also enhanced my skills in reasoning. "Have I made the right choice to place this method here, or is it better to not have it at all." Sometimes the best solution is not the solution. I felt almost like a sculpture, breaking down the pieces of clay, smoothening the edges, molding the sides, and continuously deciding and critiquing. Finally a masterpiece starts to unravel, and something that I've envisioned in my head comes to life. Following this notion of obtaining what is necessary and discarding what is useless has resulted in our new design. In this new design, I focused mostly on the command line arguments because it serves as our vessel to communicate to our users and it is the most prone to errors. I felt that without this interface being perfect/semi-effective then we would have no functional application. We've extracted more abstract classes, made use of more subclasses, and made room for other possibilities for future developers. The thing I'm most proud of is the Argument abstract class. What brought on this simple abstraction was its wide generalization in other systems. I've seen arguments in Linux/Unix or even Windows DOS that work the same way via terminal/command prompt. I broke down arguments (user input) into three essential categories: 1) options, 2) options with parameters, & 3) and essentially parameters. The creation of this class has spawned off numerous "parser" classes that utilize the same idea. This gives more room for future developers to create their own interpretation of an argument parser and make it work for themselves. I'm almost confident to say that, 80 % of the dedicated features for this project can be found in our LibraryParser class. The LibraryParser (which extends from Argument) holds most of the essential makeup of our functions. Some other enhancements worth mention are the new options: "-sort" and "-within". To get a better grasp of these two options, I would recommend visiting our project page, here. There you'll find links to our user and developer guides. Hopefully you'll find the project useful and interesting. However, I would be more happy to see developers voice their opinions toward the details of some classes and how they can improve/extract. If a developer comes out saying, "Oh this looks useful, maybe I might be able to use this for my app." then I've somewhat served my duty as a open source developer. Also, I believe this passing of knowledge is beneficial for everyone and shouldn't be confined. Although there might be mistakes, those mistakes are much more beneficial by learning from them.

Reflection:
During this third part of our DueDates project, I've helped myself revitalize my process of development and in turn, given a better insight on how I code as a programmer. I've never in my past 2 years as a ICS student realize the beauty of coding. The marriage of art and coding has made me become more open minded to the possibilities of a joyous application. Of course to balance the experience, I've also stumbled upon some mishaps and fluctuations in my coding path, but that has only enhanced the fun in it. Again the past few weeks developing on this project has been very rewarding for myself and the team. I've become more adept to develop using Google's Project Hosting site (SVN), quality assurance tools, and coding in teams. Hopefully, sometime in the future I'll aspire to newer projects that challenge me (in this kind of level) as an ICS student and developer.

DueDates Project Review (Part 2)

2008-11-01T18:54:00.000-07:00

Premise:
In this third increment of our DueDates project, we've been given the chance once again to review and get reviewed by our fellow colleagues for this application. Along the way I'll also explain about my experiences gained from this review and during this past week.

GPH Review:
We've managed to, at this point, do everything through Google's Project Hosting (GPH) site. Again, Google has given us the tools to code effectively in a real world environment setting. If you navigate over to the source of any project (that's hosted by GPH) there will be a new featured link next to the "search trunk" called "Request code review." The new feature makes it easy to request a code review amongst your team members or outside code reviewers. You are able to note a description of the review, branch path, marked issue status, and labels.
Overall the reviews from team duedates-red were positive and fairly short. There were still a few things we needed to provide to accompany our code, such as our wiki's. We've managed to well document our code in JavaDocs but have yet to utilize the GPH's homepage and wiki's features. Hopefully by the end of this review, we'll have a better and more concise explaination of our project on our project's homepage.

A positive experience:
In this third increment of our Duedates implementation, we've gotten a chance to better understand the structure and hierarchy of our program. Though it was difficult to grasp a clear plan in the beginning, we began to see the path lit up as the programming process progressed. It became much more beneficial to use programs beyond the use of Eclipse and quality assurance tools. Personally, I resorted to using a modeled approach to plan out our class structure. If anyone owns a mac or just wants to learn more about mac software, then I would recommend something called OmniGraffle. It is almost like Microsoft's Visio, but for the mac. After experiencing this newfound tool, I've come to realize the power of organizing my ideas, in a sense, on "paper". The program also gave me the ability to quickly implement an idea, and if i decide that the idea blows or doesn't live up to the overall design, then I could simply discard it and update my program in the same matter. This helped me develop a sense of awareness of the project's path and direction and it even provided me a clearer perspective in coordinating myself in a project like this. It also coerced me to program in a TDD fashion. Speaking of TDD, I became very TDD this past weekend. I actually got reacquainted with two very familiar friends, JUnit and EMMA. Yes, can you believe it? I actually used EMMA! EMMA proved to be very helpful in cases where I needed to better sculpt the usefulness of some functionality. Maybe a statement that wasn't being tested via JUnit, really turns out to be unnecessary for the overall application. I questioned that to myself when I had a low percent coverage. Could this mean i could do just the same amount of work with less code and more coverage. Well in some cases, yes! You can pick out certain things that can't be detected by other QA tools, because EMMA forces you to review those statements you think are needed to test the overall application. If you look deeper, then you'll see that maybe sometimes it's best to not even have that subject there in the first place. JUnit on the otherhand would not tell you that you need a test case for missing arguments. So the marriage of JUnit and Emma makes a good team in assuring better quality and sensible units of code.

Conclusion:
After taking this time to review other projects and assessing our own, I have gained new knowledge in the process of developing in a test driven environment. I have also gained the ability to strengthen my overall model (class) organization and program structure.

DueDates Project Review

2008-10-23T23:24:00.000-07:00

Premise: In this posting, I’ll continue from last week’s first iteration of our class project called DueDates. This week I was tasked to evaluate three DueDates project groups and also receive seven reviews of my implementation of the same project. Again I’ll be using Google’s Project Hosting site as my primary source code versioning and issue tracking system tool.
Setup for Review: So how do I put out a package to the world for developers to critique and annotate my work without interfering with my main code-line? Well, SVN provides a concept of creating snapshots of your production line code, called “tags”. Tags are meant for production version-labeled releases of a project. It provides a workable copy of the file-system at a certain point in time of your project. This can be easily done by the commands below. *Note that this would be exactly what a reviewer needs to do prior to evaluating your work. *Also to get the BASE_URL, you may try using the command: svn info - displays the details of the current svn repo. Or svn info | grep URL for just the base url.

svn copy BASE_URL/trunk BASE_URL/tags/review_release
-m “Tagging a review release of main line”

My Review Process: Google’s Project Hosting review tools provide developers the essentials to annotate and evaluate project source code in an effective and efficient manner. It gives reviewer’s, who must first be members of the project, the ability to leave comments within the actual project source file. When the source file is finalized and the reviewer is satisfied by their comments, then they can easily publish those results to the project. After the comments are published, the owners of the project are notified by email(s) of those comments. This definitely made my job as a reviewer better, since I’ll be able to optimize my time to focus on reviewing the project code, and it gives the owners of the project immediate feedback.
Reflecting on Results: During this review process I’ve gained insight into how to improve my code as well as learn the mistakes that I’ve made throughout the course of my implementation. In many ways, I could say “I approached it all wrong,” but by the indication of some feedback, I was also doing something right. Documentation was the main thing I knew that would have to be sacrificed due to our time constraints. Therefore, people were totally oblivious as to what my project expected as an input and output. The project was a total black box, in the front, middle and back. Since I did not pay close attention to my audience, it was difficult for people (both users and developers) to use or expand my system. However, I’m glad to say that there were some people who reached out to support. It was evidently helpful and gratifying to us both. During this process, I also found a way to “switch” between production lines. The reason for this was that I needed to repair the broken tag distribution for review. Before doing this, I sent out a mass email detailing the reasons. Here are the commands to switch between the trunk and tags (it also goes the same for any directory layout that you build through SVN):

svn switch BASE_URL/tags/review_release

Pretty nifty, huh? Indeed, I thought so too. After I got done making changes to the review_release version, I quickly switched back to the trunk's main code line to continue coding on the trunk. I was surprised to notice one reviewer who really felt inspired by my implementation of an error logger (ErrorLogger.java). My first intent for this class was to just parse out the command line arguments, but it became something more along the lines of a stack dump error logging tool. It currently parses out the arguments, separates them by [args] => [options - prefixed with a hyphen] [parameters - non-hyphen parameters (actual values)]. Options are pre-populated with somewhat of a unix/linux inspired command, "-v" or "-verbose". The final feature was the ol' error handling messages (friendly or verbose) depending on the passed options. Overall there were lots of small details that needed to be worked out of the beta stages of this increment. My goal from this point on is to sculpt out the essentials of the application, make it more abstract or general, and extended upon new ideas.

A lesson learned: I wanted to express this on my last posting but it was difficult to express matters under certain time constraints. I’ll start off by mentioning about what went wrong in my group’s implementation and then how we are currently going about to improving ourselves for future increments. I would like to tag this project during this point in time, called “death by email”. My group partner and I only had one official meet outside of class during the first week of working on this project. In my opinion it was horrifying to communicate with someone for the first time and barely knowing them. We both made the mistake by not getting to know each other better outside of class. Due to this slight alienation, we caused each other to have flawed predictions of one another. These preconceptions proved to be inaccurate and misleading. It was very difficult to see whether or not a team member was having a hard time with the project or if they were suffering from other external issues. During the course of this project, I learned that you are only as strong as your weakest link. Apparently we both had strengths and weaknesses. If we had communicated better straight from the get-go, and came together to pick at our flaws, then the project would have turned out better as a whole. My project group member and I have been taking the time out of our busy schedules to do regular fact-to-face meetings that last at least 30 minutes long. We’ve started to put this into practice rather than having to deal with just emailing each other progress reports. Hopefully we’ll be better off in our next increment, this coming week.

DueDates Project (Part 1)

2008-10-15T19:30:00.000-07:00

Premise:
I have been tasked this past week to assist in the creation of a project called DueDates. DueDates is currently a program that enables a user the ability to check the status of items they may have borrowed from one or more library systems. It is meant to generalize the interface between the user and their list of items, whether they be books, bills, tasks and etc. For this project, I will be accompanied by the following tools and source code: Google's Project Hosting, SVN, Eclipse, HTTPUnit, and sample code, DueDatesBootstrap.zip

Process:
The hardest part in any project is the process. I found it difficult at first to plan out a reasonable and consistent plan. Many times a plan might backfire or doesn't go as you'd expect, but after a few moments of reading up on the project's needs and wants, I finally came to conclude some possible project enhancements:
User Interface:
End-users are left with a couple of command line options that makes too many assumptions as to what is required by them. Another problem was that the resulting error dumps (Java Exceptions) were being outputted in a very cryptic manner. To solve this, we could suppress the messages and also provide an extra parameter to display other misc stack dumps for developers.
Functionality:
The sample code, DueDatesBootstrap only provides sufficient code to initialize, connect and grab responses over the network to a fixed number of supported library systems. We could provide general library system templates, and pass required parameters to them. This might not solve all internal problems, such as HTTP parsing, but it will provide a step in the right direction.

Execution:
Setup:
Even some practices needed to be re-iterated. I found myself needing to take the time just to refresh on the syntax of SVN. I keep getting this notion that I need to do a "svn import", but that's only when I'm locally hosting my SVN repositories. Google's Project Hosting site skips one step in the common "svn import" and "svn checkout" process that I'm used to. Another minor problem was knowing which folder(s) needed to be included on revision. In most common development environments, only the source, custom libraries and configuration files are worthy of inclusion to the repository.
Plan:
The first thing I noticed about the initial DueDateBoostrap program was its lack of "friendly" error handling. It occurred to me that possibly building an ErrorLogger for this system would be most beneficial not only for this project but also for others. My goal from here on was simple, build an error logger that simply takes in at least one (supported) option and deal with auditing the errors. Although my approach is simple, it does the job with a few left out features. This error logging system lacks the ability to audit with level of warning types. In future enhancements I would like to incorporate a more sophisticated level system that weighs the severity of an error/exception.

Conclusion:
I enjoyed taking the time to get my hands on a new project again. Here I can step back and think about new ideas that I have yet to explore and hopefully, along the way make changes to better the application as a whole. Its always important to know that there are some ideas that work for certain situations and some ideas that work for others. I have learned from the past that large projects like these amounts to the overall effort and not only the ability of one individual. I believe that in this high collaborative society, esp. for software engineers, that we are only as strong as our weakest link. Learning to accept the fact that you are not the lone programmer these days will better you for the actual development setting. The setting is ever changing, people come and go, while many of us still have to learn to adapt rapidly. This project proved to be quite a learning experience for both me and my team member.

Stack on Google's Project Hosting + SVN (Part 2)

2008-10-08T02:16:00.001-07:00

Premise:
In this posting I will attempt to build upon where I left off from my previous entry regarding SVN and Google's Project Hosting (GPH). My experience portrayed here will both reflect the ease and comfortableness of using SVN in a group oriented setting.

Experience:
My project is currently being hosted by Google's Project Hosting and all members of the project have SVN command privileges to add, delete, or commit changes. Likewise, I could also do a checkout of someone else's project using the same command ("svn checkout...") under "Source" tab in GPH. If I've been given membership to this person's main code line, then I'll also have full write access to their master repository. This means that the changes I make locally will reflect on the live repository once I perform a "svn commit -m...". I will attempt this very concept on a group member's project. After checking out the source from the member's repository, I am given a local copy of the project. Before attempting to run the program or make any changes of my own, I ran "Ant" to assure the code that I've just checked in, integrates well without error. If errors do occur, then I'll either have to notify the discussion group or make the changes myself.
Currently the project appears to be at a solid state without any conflicts or obvious errors. The actual error didn't occur until I used Eclipse and Ant simultaneously to execute tests and run verifications. It turns out that the given build.xml file provided by this project conflicts with Eclipse's class build directory path. Eclipse assumes ownership over a folder while Ant secretly writes to that directly after each build. Eclipse complains by throwing a "ClassNotFoundException". The easiest way to fix this is to create a folder in the project directory called "bin" and modify the default classpath in Eclipse to point to this directory. You can make this slight modification in Eclipse by going to "Project>Properties", under "Source" tab and change "Default output folder". At this stage, the current changes I make here are done locally and will not yet affect the main code line until I've committed. Now I will verify if my changes work for this issue by simply replicating the steps which brought on the error. Once everything seems to work with both Ant and Eclipse, then it should be safe to commit my changes. But before committing my changes, I'll first do an "svn update" to see if the project has changed since the time I was working on my fixes. This should be done before and after every commit to ensure that your code integrates well with other project member's code and to relieve later efforts of having to resolve more difficult conflicts.
Systematic procedures to keep integrity of code in-sync with master repository:

svn update - brings your current local copy up-to-date with the current revision

If conflicts need to be merged, then resolve these problems before continuing on.

Make your changes on your local machine
Run Ant's build tools to verify your code changes.
svn update
svn status - to see if the files you've modified are correctly marked with 'M'
svn commit -m "some informative message about the changes" - post changes to master codeline
Continue the process again.

Other tidbits:
You can run the command, "svn log" to view the history of revisions made on the current project. Notice the last revision is listed first and its corresponding comments regarding the changes are made right below it. Also note that the optional commands like "svn log", "svn diff -r M:N filename", or etc. can be done easily on GPH's site. Its much more convenient and easy to read compared to using terminal. In my opinion, the most useful operation is svn's diff command. GPH provides a complete visual, including a side-by-side view of both files under different revisions. I only wish that GPH had a feature to produce patches along with having the ability to do diff's. Patches would be pretty useful for situations when you do not have full control over the master repository. So rolling out your own set of "diff" changes to fix a general project issue would be useful when you need to send it to a user group or mailing list to explain about your changes. From there your patches can be determined by the owners or other members, as to whether or not your patch should be applied to the main system. GPH solves the problem of communicating with members of the group project (via Google Groups), but does not make it easy for current members of the project to apply these patches/changes.

Conclusion:
Subversion is a code-management repository that enables you to keep your source code stored on a remote server (in this case Google's Project Hosting Server) that can be accessed by multiple members/users. Subversion makes collaborating with multiple users a breeze because users can checkout copies of the source code to their local machines, make edits, and then send the changes back to the SVN server. At that point, team members can update their local copies with all the team's changes. SVN manages the changes made to each file so that you aren't automatically overwriting your co-worker's work! Even if you are the sole developer, storing your project source under Subversion is a great way to keep a remote "backup" of your code in case your development machine is compromised or if you fall victim to a situation resulting in data loss.

Stack on Google's Project Hosting + SVN

2008-10-07T17:04:00.000-07:00

Premise:
The purpose of this post is to experience the process of building your own source code management system by using both a live server (Google's Project Hosting) and Subversion (SVN). Source code management enables project teams to effectively share and collaborate with each other while keeping track of their development process. A part of the construction process consists of using good foundation practice tools, such as SVN to help ease the pain of manual code tracking and tasking.

Setup:
1. Install Subversion
You'll need to have a copy of Subversion installed on your local machine. If you're running Mac OSX or Linux/Unix, then that'll be all you'll need. You can simply download the binaries/source straight from Subversion's site, here. Otherwise, If you're a Windows user, then I would recommend installing the latest version of CollabNet's TortoiseSVN. TortoiseSVN is an easy to use GUI version of SVN for Windows that can be interfaced (in version control) to support any filesystem item (files, folders, etc). Although the subsequent steps follow the basis of a Linux based platform, the process of login in and setting up the first checkout, add, commit, and update are conceptually the same.
2. Create a Google Project
Google's Project Hosting (GPH) is a service which enables team-project members to collaborate in an effective development environment. GPH provides project workspaces with easy to use UI member controls, issue tracking, mailing group lists (via Google groups), and most importantly Subversion. Although you are not restricted to use Google's Project Hosting, I would recommend it if you want to quickly get something up and running for your co-workers or the world to see. If your intentions are to use some other advanced remote server, then you'll have to look elsewhere for that. I'm simply portraying the use of one possible solution. If you'd rather take another approach, then here are some of my recommendations on how to approach the same level of likeness to Google's: 1) Get and install Subversion, 2) Install Apache on your server, 3) Configure Subversion to work with SSL and Apache, and 4) Install Trac - issue/task management software. The more detailed instructions can be found here.
3. Initialize: Revision 1
To get started with GPH, you're required to obtain/already own a Google account (as with anything from Google). Next, redirect yourself to GPH's site here and click on "create a new project." This will instantly create a project and provide you the necessary parameters needed to describe your project. Once all the forms are out of the way, navigate over to the "Source" tab. Here, you'll be presented by Google's nicely suggested commands to run SVN. You could now just copy and paste the following into a terminal window.
"svn checkout https://stack-anthonydu.googlecode.com/svn/trunk/ stack-anthonydu --username anthony.m.du"
Quick explanation of these commands:

"svn checkout" - pulls the SVN tree structure (svn>(tags)/(branches)/(trunk)) from the specified server. This will only need to be done once.
"https://.../svn/trunk/" - url of source code. It can be a remote or local server
"stack-anthonydu" - project folder name
"--username anthony.m.du" - google account username for server access.

Once you hit return, the GPH server will verify your credentials with a pre-generated key. You may generate a new one or use the one pre-generated key under the "googlecode.com password" link. After you successfully checkout, SVN will display a message noting your very first revision. This marks the end of possibly the hardest part of setting up your repository.
4. Adding & Committing files
Now switch to your project directory. Notice that their is a hidden ".svn" folder in your directory which stores information about the current state of your repository. The next logical step is to add files to your main code line. Use "svn status" to see which files have not yet been added or added but not yet committed. The files that have been added will be prefixed with the letter 'A', and one's that have not been added will be prefixed with '?'. Unfortunately there is no easy way to recursively add all files and subdirectories using a terminal/command line. You might think that a simple svn add * would do the trick, but this command is NOT recursive. So I looked around for a quick and dirty script that will simply add all newly, non-committed files to svn. Here's the script in its most rawest form: "svn status | grep "^\?" | awk '{print $2}' | xargs svn add"
I have made this into a command of my own to simply be called anywhere called "svnadd." This can be done by saving the one-liner script into a file and storing it into the "/usr/bin/" directory (only under Unix/Linux platforms).
For a list of commands provided by svn, you may simply type "svn help". Now that you've made changes to your repository by adding files, the next step is to commit your changes to the main repository. This can be simply done with the command "svn commit", followed by a meaningful message describing the changes you've made. In this initial process, you can name it along the lines of "project initialization."
Transmitting file data .............................................
Committed revision 2.
This marks the end of Revision 2.

I have applied these instructions to my first GPH, called "stack-anthonydu" (same project from previous blog posts). This project can be accessed, viewed/downloaded, but not modified by public users. The master repository goes unchanged unless you own or are a member of the project. Here is a link to my stack-anthonydu in all its glory.

Conclusion:
I learned that version control should be part of your daily-standard arsenal. After this brief introduction to configuring and getting a feel for Subversion commands, I was quick to appreciate its vast potential for sharing and publishing source code. In my next blog post I'll further explain my experiences using my newly committed stack project.

Stack Overflow - Programmer's Q & A Haven

2008-10-01T23:45:00.000-07:00

What is Stack Overflow?
Stack Overflow is a web application written by collaborative programmers for programmers with programming questions. The site initially requires nothing when you first visit, but to be able to gain further editing privileges, then you must sign-in using a new or existing OpenID account. OpenID is a one-stop sign-in or sign-up account used to help ease the pain of remembering login names for different sites. Upon successfully registering for the site, you’ll be immediately given the ability to edit your personal account info, easily search for a question or answer (either by tags or textual search), and post questions or answers. Soon, after you make your first post, moderators, or users who have gained high reputation will rate the prevalence of your post given the appropriateness and popularity. You’ll be given points depending on these factors, which then will correspond to your abilities on the site. If you gain higher status in your reputation, then the site awards you the ability to edit yours and other’s posts almost like a wiki. At times you might feel that Stack Overflow is giving you a hard time, but it does it for good reasons. The most popular attraction of this site is its strict rules on postings. Since posters must stay on topic, the site’s reputation and purpose gets further established in the community. The simplicity and specificity gives Stack Overflow a name in the community of programmers as a “programming FAQ” site, rather than a sub-category amongst other contending search topics. Also, it helps eliminate the trouble of irrelevant or duplicate questions. In my opinion, this proves to be a good strategy than most other social networking sites that deal with a conglomerate set of topics, like Digg or SlashDot. Its unique moderation and rating system makes it an ideal example for newer social networking sites to follow.

What were my Stack Overflow experiences?
Stack Overflow is a "programmer's haven" for Q & A's. I have posted one question regarding the goods and bads of using more than one level nesting in Ruby on Rails. Hopefully, the question will get picked up by the community and I'll get an answer that will suit my needs.
Here's a direct link to the question: http://stackoverflow.com/questions/164520/to-nest-or-not-to-nest

Overall, I think the service will be a good addition for programmer related sites. I've definitely given this a good rating on my StumbleUpon and bookmarked it for future visits.

Stack + Emma + JUnit

2008-09-29T22:06:00.000-07:00

Premise:
In this experiment I'll take a look at testing techniques and programming coverage using both JUnit and Emma. All programs in this experiment will be edited and tested using Eclipse with built-in integration of JUnit's plugin. Emma is an open source Java coverage tool that integrates well with Ant. I will be running Emma and building my subsequent tests from command prompt (using Ant), while making changes that reflect improving coverage in Eclipse. The program below is the remanence of my previous "Stack" post. I will be using the Stack program as the basis of running my unit tests.

Improving Coverage:
The goal of this experiment is to improve code line coverage. Emma makes this very easy to accomplish by using a few commands from my previous setup of Ant. After executing the following build command: "ant -f emma.build.xml," Emma conveniently gives quantified metrics for class, method, block and line converage. Emma is also nice enough to provide an html (emma/coverage.html) summary describing the covered, partially covered and uncovered code line executions. It also indicates the file and highlights each line with a neat color scheme: green - fully covered, yellow - partially covered and red - uncovered.
Initial Emma Coverage Metrics:

class: 100% (3/3)
method: 73% (8/11)
block: 69% (65/94)
line: 75% (15/20)

Analysis of uncovered lines are specified by filename, percentage of coverage and methods containing non-executed code lines:

ClearStack.java, (50%), getTop() & isEmpty()
Stack.java, (79%), toString() & top()

I proceeded to first improve the most trivial test cases indicated by Emma for files Stack.java and ClearStack.java. I was able to raise the line-level coverage to 99.8%. However, I was stuck at a partially uncovered item in the isEmpty() method of the ClearStack class. In this case Emma has no further input other than to say that this is a line that needs more tests. It took me a while to notice that the isEmpty method needed to thoroughly be tested for both true and false cases, when initially I only had one. This minimal unit test boosted my line-level status to 100% and thus achieving what looks to be good code, right? Unfortunately, I was drawn to notice a couple flawed attributes that adhere from my tests and the confluence of using Emma as a fully trustworthy tool. Although my first intentions of this experiment is to improve code coverage, I've also come to realize Emma's vita flaw that could potentially separate good testers from the bad. I've also notice how Emma's tricks the programmer into thinking about only achieving code coverage, rather than helping the coder gain greater insight into their code analysis. Even at 100% coverage, my tests are not completely tested in terms of its context. For example, one unit test required that I needed to test the toString() method in the Stack class. In my TestStack class, I did the toString() method test by simply asserting the expected output while having prior knowledge of what toString() must express.
Here's my test case: assertEquals("Testing stack toString", "[Stack []]", stack.toString());
I found that this test builds upon the assumption that stack.elements works. I needed to conclude to myself that this statement truely executes without flaw, so I tested the List's toString method.
2nd test case: assertEquals("Testing list toString", "[]", stack.elements.toString());
It turns out that my curiousity only led me to remember that Collections have a default format of outputing elements in a form of an array-like string, enclosed with square-brackets. The point of this assertion was to distinguish the mindset of good and bad testers. Good being the ones who take it a further step by objectively analyzing the hidden points being made by their program, and bad ones who leave after the 100% coverage which may or may not be truely 100% valid.
Overall, Emma is still a great tool that should be used continuously in pre-development to production stages. However, I would not recommend using Emma in the middle of a project, unless the task is minimally affected by the program as a whole.

Here's a link to the final Stack code: stack-anthony.m.du-6.0.930.zip

Conclusion:
I learned the importance of building my programs using some sort of coverage tool. Although, coverage tools evidently determines if our code is tested for certain conditions, it limits us from determining the thorough aspects of what our program is truly expressing in terms of context. Upon questioning the effectiveness of converage tools, such as Emma, I've come to realize that there is no better tool than human analysis. Sure we can ease the pain of manually checking whether or not our code is executing like it should, but we must also take into account for its lack of human ingenuity and influence. Since we wrote the program using our own patterns and processes, we should also rely on our instinct when it comes to assessing our own work. I feel that the usage of Emma should go hand-in-hand in the beginning stages of developing test cases. Again, the concept of incremental programming should be exercised for assuring the quality of your code. As for future use, I would recommend using the integrated plugin called: EclEmma for Eclipse. It works very much like Emma. It also gives visual highlights of what code has been tested or "covered," as well as the usual quantified metrics provided after every build.

Automated vs Manual QA (CodeRuler)

2008-09-24T08:08:00.000-07:00

Overview:
Simply compare the validity of human QA and automated QA tools on previous CodeRuler project.

Running Ant + CodeRuler:
QA Tool: QA Violation (Comments)

CheckStyle: Line Type Javadoc comment is missing an @author tag. (JavaDoc issue)
CheckStyle: Line contains a tab character. (Format issue)
CheckStyle: Unused @param tag for 'int'. (Logic issue)
CheckStyle: Expected @param tag for ‘x’ or ‘y’ (Logic issue)
CheckStyle: Line is longer than 100 characters. (Format issue)
CheckStyle: Type Javadoc comment is missing an @author tag. (JavaDoc issue)
CheckStyle: 'static' modifier out of order with the JLS suggestions. (Logic issue)
CheckStyle: Missing a Javadoc comment. (JavaDoc issue)
CheckStyle: '}' should be alone on a line. (Format issue)
CheckStyle: First sentence should end with a period. (Format issue)
**CheckStyle errors: 101152 errors across 10 files

PMD: Avoid if (x != y) ..; else ..;
PMD: Avoid unnecessary comparisons in boolean expressions
PMD: Private field 'castle' could be made final; it is only initialized in the declaration or constructor.
PMD: Avoid using if statements without curly braces
PMD: Avoid using implementation types like 'ArrayList'; use the interface instead
PMD: Substitute calls to size() == 0 (or size() != 0) with calls to isEmpty()
PMD: These nested if statements could be combined
PMD: Document empty constructor
PMD: An empty method in an abstract class should be abstract instead
PMD: Return an empty array rather than null.
PMD: Document empty method
PMD: All methods are static. Consider using Singleton instead. Alternatively, you could add a private constructor or make the class abstract to silence this warning.
PMD: Return an empty array rather than null.
**PMD errors: 60 errors across 3 files

FindBugs: 439 lines of code analyzed, in 11 classes, in 2 packages.
**FindBugs errors: 0 errors and 0 warnings!

Conclusion:
Obviously, this would have been a nightmare without some kind of automated tool system for checking styles and coding rules. Upon receiving the numerous style errors, these QA tools give a descriptive audit of exactly when and where each error occurs. Using QA tools helps our code exist in one or many standards depending on the situation. After seeing what a mess things could be when we go against the standard, I'm now leaning more toward coding in a much safer and higher quality standard environment.

Software Quality Assurance

2008-09-19T11:05:00.000-07:00

Overview:
Quality Assurance (QA) of code is the basis of source code analysis development. The quintessential part of distributing your code with high quality production standards is that it ensures a good product (reliable, maintainable, and manageable) and enables other organizations to easily pickup your software.

System Requirements:

Java: JDK 1.4 or higher
OS: Windows, Linux, Unix, or Mac OS X

QA Tools:

Ant - "Anther Neat Tool" used to assist programmers in scripting custom automated build process similar to that of "make" for C/C++.
CheckStyle - used to help ensure that your Java code adheres to a set of coding standards. (static analysis)
PMD - used to enforce certain coding rules. (static analysis)
FindBugs - is another static analysis tool that examines your class or JAR files looking for potential problems by matching your bytecodes against a list of bug patterns.
JUnit - used to incrementally assert test conditions/statements that presumably matches an expected outcome.

Installation:
The installation process is quite simple once you get the hang of it. Below is a quick walk through of installing the above QA tools on both Mac OS X/Linux platforms:

Mac OS X (Unix) / Linux Users:
** the instructions below can also be tailored for Linux users too, but just with slight differences.

Fortunately for mac users, Java and Ant come pre-installed with the latest version of Mac OS X (10.5.4). All I ended up doing was export the path variables (JAVA_HOME & ANT_HOME) to point to the installed locations on the system. *If you need to install it manually, then you can consult to instructions here.

$ cd
$ emacs .profile
edit file by adding the following:
export JAVA_HOME="/Library/Java/Home"
export ANT_HOME="/usr/share/ant"
save and close the file
$ source .profile
you can also check to see if your environment variables have been added by typing:
$ env

Once you get the hang of just installing one tool, the rest follow the same methodology for both Unix and Linux platforms. Below is a generalized version of installing and updating the environment variables

Download and extract: qa_tool (e.g. checkstyle, pmd, findbugs, etc.)
$ cd downloads/
$ wget qa_tool_url
$ unzip qa_tool_version.zip -d /usr/local
Update environment variables
$ cd
emacs .profile
add the following env variables
export QA_TOOL_HOME="/usr/local/qa_tool"
save and close file
$ source .profile

Stack + QA:
The program called stack will help us test our newly installed QA tools.
Setup project:

Download project source code here: stack.zip
Extract source project into development directory (workspace in Eclipse)
Open Eclipse and select File>Import, General>Existing Projects into Workspace, select root directory by browsing to where the stack source was extracted, and click on Finish.
Right-click on stack project, Refactor>Rename>stack-(username)
Edit build.xml file by renaming the project name to match "stack-(username)"

Running Ant + QA tools:
At the command prompt/terminal, switch to the location of your stack project folder and run the following Ant commands:

ant clean compile
ant -f checkstyle.build.xml
ant -f dist.build.xml
ant -f findbugs.build.xml
ant -f javadoc.build.xml
ant -f junit.build.xml
ant -f pmd.build.xml
ant -f verify.build.xml

The last statement should render a BUILD FAILED plus something similar:
:stack-anthony.m.du directory
$ ant -f verify.build.xml
Buildfile: verify.build.xml

clean:
[delete] Deleting directory /Users/admin/Develop/java/stack-anthony.m.du/build

compile:
[mkdir] Created dir: /Users/admin/Develop/java/stack-anthony.m.du/build/classes
[javac] Compiling 5 source files to /Users/admin/Develop/java/stack-anthony.m.du/build/classes

junit.tool:
[mkdir] Created dir: /Users/admin/Develop/java/stack-anthony.m.du/build/junit
[junit] Running edu.hawaii.stack.TestClearStack
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.071 sec
[junit] Running edu.hawaii.stack.TestStack
[junit] Tests run: 2, Failures: 1, Errors: 0, Time elapsed: 0.031 sec

BUILD FAILED
/Users/admin/Develop/java/stack-anthony.m.du/junit.build.xml:18: Test edu.hawaii.stack.TestStack failed

Stack + QA tool fixes:
**description of errors can be found in build directory under tool directory subfolder in html format.
JUnit errors:

junit.framework.AssertionFailedError: Testing stack top of three expected same:<3> was not:<1>
at edu.hawaii.stack.TestStack.testNormalOperation(TestStack.java:37)

**edited top() logic in file: Stack.java

Checkstyle errors:
[checkstyle] /Users/admin/Develop/java/stack-anthony.m.du/src/edu/hawaii/stack/Stack.java:52: Expected an @return tag.
[checkstyle] /Users/admin/Develop/java/stack-anthony.m.du/src/edu/hawaii/stack/Stack.java:79:3: '{' should be on the previous line.

**made fixes to those minor style checks in file: Stack.java

PMD errors:
5 total:
Private field 'one' could be made final; it is only initialized in the declaration
... again for both 'two' and 'three'
**added final to all three declaration statements in file: TestClearStack.java

Avoid using implementation types like 'ArrayList'; use the interface instead
**replaced with List interface declaration in file: Stack.java

Consider simply returning the value vs storing it in local variable 'obj'
**replaced with returning top value instead of storing in file: Stack.java

FindBugs errors:
Method new edu.hawaii.stack.TestClearStack() invokes inefficient new Integer(int) constructor; use Integer.valueOf(int) instead
Method new edu.hawaii.stack.TestStack() invokes inefficient new Integer(int) constructor; use Integer.valueOf(int) instead
**replaced declaration with "Integer.valueOf(int)" in file: TestClearStack.java & TestStack.java

Final Stack + Ant Run:
amd:stack-anthony.m.du admin$ ant -f verify.build.xml
Buildfile: verify.build.xml

clean:
[delete] Deleting directory /Users/admin/Develop/java/stack-anthony.m.du/build

compile:
[mkdir] Created dir: /Users/admin/Develop/java/stack-anthony.m.du/build/classes
[javac] Compiling 5 source files to /Users/admin/Develop/java/stack-anthony.m.du/build/classes

junit.tool:
[mkdir] Created dir: /Users/admin/Develop/java/stack-anthony.m.du/build/junit
[junit] Running edu.hawaii.stack.TestClearStack
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.105 sec
[junit] Running edu.hawaii.stack.TestStack
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.015 sec

checkstyle.tool:
[mkdir] Created dir: /Users/admin/Develop/java/stack-anthony.m.du/build/checkstyle
[checkstyle] Running Checkstyle 5.0-beta01 on 5 files

pmd.tool:
[mkdir] Created dir: /Users/admin/Develop/java/stack-anthony.m.du/build/pmd
[echo] PMD found ${pmd.failure.count} problem(s).

findbugs.tool:
[mkdir] Created dir: /Users/admin/Develop/java/stack-anthony.m.du/build/findbugs
[findbugs] Executing findbugs from ant task
[findbugs] Running FindBugs...
[findbugs] Error: The path /usr/share/findbugs-1.3.5/plugin does not seem to be a directory!
[findbugs] No FindBugs plugins could be loaded
[findbugs] Output saved to /Users/admin/Develop/java/stack-anthony.m.du/build/findbugs/findbugs.xml

emma.tool:
[mkdir] Created dir: /Users/admin/Develop/java/stack-anthony.m.du/build/emma
[instr] processing instrumentation path ...
[instr] instrumentation path processed in 90 ms
[instr] [3 class(es) instrumented, 0 resource(s) copied]
[instr] metadata merged into [/Users/admin/Develop/java/stack-anthony.m.du/build/emma/metadata.emma] {in 2 ms}
[junit] Running edu.hawaii.stack.TestClearStack
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.261 sec
[junit] Output:
[junit] EMMA: collecting runtime coverage data ...
[junit]
[junit] Running edu.hawaii.stack.TestStack
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.254 sec
[junit] Output:
[junit] EMMA: collecting runtime coverage data ...
[junit]
[report] processing input files ...
[report] 2 file(s) read and merged in 7 ms
[report] writing [xml] report to [/Users/admin/Develop/java/stack-anthony.m.du/build/emma/coverage.xml] ...
[report] writing [html] report to [/Users/admin/Develop/java/stack-anthony.m.du/build/emma/coverage.html] ...
[delete] Deleting directory /Users/admin/Develop/java/stack-anthony.m.du/build/classes

emma.echo:
[xslt] Processing /Users/admin/Develop/java/stack-anthony.m.du/build/emma/coverage.xml to /Users/admin/Develop/java/stack-anthony.m.du/build/emma/coverage.brief.txt
[xslt] Loading stylesheet /Users/admin/Develop/java/stack-anthony.m.du/lib/emma/echo.emma.xsl
[concat] Emma Coverage summary
[concat] class: 100% (3/3)
[concat] method: 73% (8/11)
[concat] block: 69% (65/94)
[concat] line: 75% (15/20)

verify:

BUILD SUCCESSFUL
Total time: 7 seconds

**Here's a link to the new build: stack-anthony.m.du-6.0.921.zip

Conclusion:
I learned that functional software products must also have high quality attributes to pass being labeled a legitimate software product. Besides meeting your company's functional requirements, your software must also verify with quality assurance guidelines. In doing so, software products will be more reliable, maintainable, manageable and even distributed in a timely matter with functionality. In another exploration, I would like to find ways to quantify the quality assurance of source code. The elements of benchmarking your QA is most likely related to process aspects and operations. Perhaps, we could benchmark the number of errors or unsuccessful builds using Ant or some other tool.

CodeRuler Review

2008-09-12T13:08:00.000-07:00

First look:

I was assigned to review Daniel and Erin's CodeRuler implementation. In the first trial their ruler outperformed against the migrate ruler by a large margin. Unfortunately they weren't too successful against either smart-splitter or gang-up rulers. In both trials (smart and gang) their ruler performed the same way by killing all enemy peasants before capturing its castle. But by the time they captured the enemy's castle, their first castle gets occupied by knights of the opposing team. While they attempt to re-capture their first castle, no peasants are being produced in their second castle. The opposing ruler keeps producing knights after every turn, thus covering and protecting its castle. Their ruler consistantly battles the knights, but unsuccessfully captures back their first castle. For every battle lost between their knights and the opposing team, the enemy gains battle points and they lose precious points from not claiming land. Although the end result is not fully desired, there is much to learn from this implementation.

Review:

Besides what the CodeRuler strategy implies, this review is based on the creators' coding style and class logic structure.

JavaDocs:

The provided JavaDocs for this MyRuler is quite clear and concise. The method summary is descriptive and easy to follow. You can almost get the gist of what each method is intended to do without looking at any code. However, I would like to see a better introduction to their MyRuler class by describing more of their strategy rather than listing the resulting trial matches.

Class logic and structure:

The overall class structure is simple and easy to follow. Each method provides a readable description that matches the code segments. Method references are nicely encapsulated and broken down into smaller reusable routines. I found it much easier to read each function due to the fact that this group followed good naming conventions. As for the effectiveness of their code, I would have to disagree with one routine called: buildUnits (line # 231). I found this method to be less effective in the process of replicating more peasants at each captured castle. This method stops the production of peasants when the team has only one aquired castle. Due to this limitation, other methods relating to the movement of peasants, such as: optimizePeasantMove (line #413) was wasted during gameplay.

Coding style:

Below are some minor code style violations within the MyRuler class. Most of these errors can be set to fix automatically (format) or easily avoided the next time around.

File	Lines	Violations	Comments
MyRuler	93-94, 100-101, 143-144, *	EJS - 5, ICS-SE-Eclipse-2	opening brace should be at end of the line that introduced the block.
MyRuler	87, 88, 175, *	ICS-SE-Eclipse-2	Some lines exceed the 100 column max limit.
MyRuler	155, 159, 177, *	EJS – 7	Increase white spaces by placing them between keywords (if, for, while, switch) and parenthesis or braces to better readability of code.
MyRuler	4	ICS-SE-Java-2	Must explicitly specify each class import rather than using a wildcard “*”.
MyRuler	130, 133, 146, *	ICS-SE-Java-10	Needs to pluralize names of collection objects.
MyRuler	96, 117, 168, *	EJS - 49	Omit subject in method description to reduce redundancy.

Final thoughts:

After reviewing the coding style and class structure of this CodeRuler implementation, I learned that documenting your code is just as hard as implementing it. Maybe a better approach to programming would be to self document first and then extract code statements and method functions from that as you build the application. The all important methodologies of "Top-Down" programming would be an essential skill to practice for even the simplest of classes or methods. This should be applied also to the way we program and document our work. Overall, Daniel and Erin did a good job and I hope they take away as much from this as I did.

Here's a link back to each member's blog. There you can also find a link to their source code.

Lessons learned from Code Ruler

2008-09-07T23:37:00.000-07:00

Overview: CodeRuler is a Java programming game based on the Eclipse IDE. It is intended for testing skills in Java programming as well as strategic reasoning. The basic idea of the game is to capture other opponents' castles and claim the most land resources. In doing so, the player with the highest score wins the game!

MyRuler Group Members:

Strategy Outline:

Break knights and peasants into smaller groups with specific objectives.

InsideCastleGuards

they will stay and move around inside the castle.
they will capture any opponent knight inside the castle.

OutsideCastleGuards

they will attempt to capture any knight that moves too close to the castle.
they will roam around the castle area capturing opponents peasants.
they are the first line of defense against opponent knights.

KnightCastleInvaders

they will attempt to capture opponents' castle.
they will attempt capture of opponents' peasants that they encounter, but they will not chase them.
they will avoid contact with opponents' knights.

LandCapturePeasants

they will attempt to capture unoccupied land and opponents' land.
they will attempt to avoid capture from opponents' knight.

KnightDistractionPeasants

they will attempt to get opponents' knight to chase them, leading the opponents' knight away from the castle.

Sample Game Results:

	MyRuler vs Migrate	MyRuler vs Gang-up	MyRuler vs Split-up
1	503-36	455-117	412-182
2	540-32	455-140	513-119
3	462-40	370-156	466-234

Lessons learned:

Eclipse became a good companion for this project. I consider it an all-purpose IDE and has well lived up to its expectations for all backgrounds of developers. The built-in JavaDocs generator has proven to give ease and painless professional documentation.
Java still surprises me with its wealth of runtime exceptions. Here's one that I found annoying and difficult to fix: "ConcurrentModificationException" - impermissible for one thread to modify a Collection while another thread is iterating over it.
I learned that large projects such as this requires a large amount of effort from each person. It was difficult to have long continuous meetings due to our conflicting schedules, but we found other ways (email or online-chat) to communicate efficiently.

Improvements:

My first recommendation for future projects that require the service of more than just one person would be to use some kind of source code version control like SVN or GIT. It seems cleaner to do it under version control rather than passing back and forth document copies through email, which requires you or your team member to patch-up manually. I also would recommend a task tracker such as Edgewall's Trac for project management software. A handy project or task management software (preferably open source) would be helpful for keeping track of project goals, tasks and progress.

Reflection:

I enjoyed taking the time to experience programming this Java based strategy game. It proved to be well worth my time and a great learning experience for myself and my group members.

CodeRuler source: du-okada-ancheta.zip

Sun's GlassFish: Application Server Review

2008-09-01T12:03:00.000-07:00

Overview:
GlassFish is an opensource project held under a dual-license agreement by both CDDL & Apache's GPL licenses. It is an application server meant to service in deploying web applications. GlassFish is now certified and included by Java Enterprise Edition v5 (SDK). GlassFish provides enterprise quality features including support for high scalability of applications, robust clustering and advanced administration w/ GUI interface for management. The project also has a large growing community of developers/users and solid documentation/API (quick-start tutorials, roadmaps & architecture documents).
Since its 2005 release, GlassFish has gained monumental support for both independent and commercial distributions. In recent news, GlassFish will be announcing its v3 release. It claims to have made numerous improvements including, simplified Web 2.0 style applications, better optimization for version specific Java applications, and a useful notifiable update center for GlassFish's new components. Currently, you can try out GlassFish v3 under Technology Preview 2 (TP2) and test it out on your local machine. WARNING: As noted on the Tech Preview site, the code is still in its raw experimental stages and should not be used to deploy production applications.

Satisfying Prime Directives:
PD#1 (Useful functionality): GlassFish provides an open source referential implementation for developing high quality enterprise applications. Its support for Java EE v5 enables developers and companies to integrate with ease and to deploy business standard applications. The administration section is fully featured with a strong sense of security and management. I found that logging into the Admin Console to be very easy to configure and use. The Admin Console features tools that provide you a great deal of control over your serviced application(s). Admin Console also provides common administrator tasks through a straightforward web-interface which include: 1) Easy enable/disable applications, 2) service logs on applications currently running, 3) configurable Java Database Connectivity (JDBC) - module for wide range of database support and 4) many server side settings. GlassFish also provides scalable clustering techniques for rendering multiple in-memory state sessions. Although a great feature, I will need more time to find a better/suitable comparative data for cluster instances and its impact on scalability.

PD#2 (Ease of Installation & Deployment): GlassFish has a number of resources including the very straightforward quickstart guide here. The quickstart guide helps you verify your server needs, gives you instructional steps into deploying your first web application, and using the administrative tools. I tested GlassFish on Eclipse v3.4 (on mac osx 10.5.4) using these instructions for installing the application server as a plugin and deploying my first Java EE application. There are also other supportive IDE's that make it just as easy to install GlassFish (as a plugin) and can be found here. As for deploying my first Java EE application, I also found this great screencast created by a fellow Sun developer named Arun Gupta. The screencast has a bit of an audio glitch, but I found myself just turning the volume down and mimicking his actions.

PD#3 (Accessbility for Future Enhancements): GlassFish's popularity has grown since Sun released its Binary (.jar) in 2005, where countless number of people in the millions tried it for the first time. The project has up to date news, discussion boards/forums, and RSS supportive mailing lists. Although GlassFish's licence agreements are semi-proprietary, in that some of its components are given out as binaries rather than pure source code, the community of active developers are still able to contribute to the development future of the project. Again, GlassFish is under CDDL agreement which authorizes anyone to make changes, fix bugs, and contribute new features. You can visit this site for more information on CDDL and GPL licenses. I also found this wiki page useful for having a general overview of which components are under which licensing term.

Final Thoughts:
In my brief experience with GlassFish v2, I've found myself more aware of the possibilities and power of one application server. Considering that this was my very first application server written in Java and for Java EE applications, I will need to give it more tests to verify its specifications. I've also heard of other application server alternatives to GlassFish, such as JBoss, Apache's Tomcat and Geronimo. Its a good possibility that I will post a comparison chart displaying its pros and cons. But I'm actually more tempted to wait for the highly acclaimed release of v3 for GlassFish.
After seeing that open source communities are now driving the market of consumers by its free price and popularity, I wouldn't be so surprised that big companies like Microsoft will start to become more open source.

FizzBuzz (JUnit + Eclipse)

2008-08-26T13:31:00.000-07:00

Premise: Testing out JUnit's test case features on Eclipse.
Application: FizzBuzz
Description: Print out the numbers from 1-100 on each line. If a number is divisible by 3 then print out "Fizz", else if a number is divisible by 5 then print "Buzz", else if the number is divisible by both 3 and 5 then print "FizzBuzz", otherwise print the numeric value.

Why JUnit?
JUnit provides immediate feedback based on YOUR tests. It lets you have a taste of the pie rather than the whole thing all at once. JUnit provides safe and time saving software engineering practices for both small or large production software. And of course JUnit is FREE and included when you download Eclipse.

JUnit design procedures:
1. Create a JUnit Test Case in your current project folder. Your test case classes will extend from JUnit's TestCase object class. In here, you can utilize the following methods provided by TestCase: setUp() - to initialize test objects, tearDown() - to destroy test objects. Next, write your test case methods with their names prefixed with 'test'
2. Create a JUnit Test Suite in your existing project folder. Eclipse provides a convenient way to add test classes to your test suite upon creation. The test suite is intended to encapsulate all test classes provided in your project folder.
3. Implement the component/class for your project and test away! Remember that your program is validating itself with incremental test units, so start out with just a piece of your program and work your way up the chain.

---Source---
Test class: TestFizzBuzz.java
- Declare the object FizzBuzz to be tested and an integer as our test case input value.
- Create methods: setUp() initialize variables/objects & tearDown() destruction of variables/objects
- Implement test case method: testGetValue()

import junit.framework.TestCase;

public class TestFizzBuzz extends TestCase {
    //OBJECT/PRIMATIVE DATA DECLARATIONS
    private FizzBuzz fb; //object class being tested
    private int num; //test value

    //FIXTURES
    protected void setUp() {
        num = 3;
        fb = new FizzBuzz();
        fb.setNum(num);
    }
    protected void tearDown() {
        num = 0;
    }
    
    //TEST CASES (prefix method names with 'test')
    public void testGetValue() {
        if (num==3) {
            assertEquals("Fizz", fb.getValue());
        } else if (num==5) {
            assertEquals("Buzz", fb.getValue());
        } else if (num==15) {
            assertEquals("FizzBuzz", fb.getValue());
        }
    }
}

Test suite: AllTests.java
- Test all test case methods in class 'TestFizzBuzz'

import junit.framework.Test;
import junit.framework.TestSuite;

public class AllTests {

    public static Test suite() {
        TestSuite suite = new TestSuite("Test for default package");
        //$JUnit-BEGIN$
        suite.addTestSuite(TestFizzBuzz.class);
        //$JUnit-END$
        return suite;
    }
    
    public static void main(String[] args) {
        junit.textui.TestRunner.run(suite());
    }

}

Application: FizzBuzz.java
- Attempt to implement the getValue method
- Output the desired results

//FizzBuzz.class
public class FizzBuzz {
    //PRIMATIVE DATA
    private int num;
    
    //DEFAULT CONSTRUCTORS
    public FizzBuzz() {
    }
    public FizzBuzz(int n) { 
        num = n; 
    }

    //GETTERS/SETTERS
    public void setNum(int num) { 
        this.num = num; 
    }
    public int getNum() { 
        return num; 
    }
    
    //RETRIEVE CORRECT VALUE
    public String getValue() {
        if((num % 3 == 0) && (num % 5 == 0)) { 
            return "FizzBuzz"; 
        } else if (num % 3 == 0){
            return "Fizz";
        } else if (num % 5 == 0) {
            return "Buzz";
        } else {
            return Integer.toString(num);
        }
    }
    
    //MAIN METHOD
    public static void main(String[] args) {
        FizzBuzz fb = new FizzBuzz();
        for (int i=1; i<=100; i++) {
            fb.setNum(i);
            System.out.println(fb.getValue());
        }
    }
}

FizzBuzz app results:

1
2
Fizz
4
Buzz
Fizz
7
8
Fizz
Buzz
11
Fizz
13
14
FizzBuzz
16
17
Fizz
19
Buzz
Fizz
22
23
Fizz
Buzz
26
Fizz
28
29
FizzBuzz
31
32
Fizz
34
Buzz
Fizz
37
38
Fizz
Buzz
41
Fizz
43
44
FizzBuzz
46
47
Fizz
49
Buzz
Fizz
52
53
Fizz
Buzz
56
Fizz
58
59
FizzBuzz
61
62
Fizz
64
Buzz
Fizz
67
68
Fizz
Buzz
71
Fizz
73
74
FizzBuzz
76
77
Fizz
79
Buzz
Fizz
82
83
Fizz
Buzz
86
Fizz
88
89
FizzBuzz
91
92
Fizz
94
Buzz
Fizz
97
98
Fizz
Buzz

Conclusions:
The program took me about 15 minutes to accomplish. Having been equipped with the power of Eclipse and JUnit tool, I've been able to code with confidence. JUnit takes away the remedial debug breakpoints/backtrace of code (which requires that you make a mistake first), but rather helps you build from ground up with a solid assurance of functionality. It also helps prevent you from fixing a bug later down the line that may be too heavily nested in your code to find. In the essence of incremental programming, I would recommend further exploring the possibilities of JUnit in any aspect of development for Java.