[GSoC09] Devcathlon & GSoC

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

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

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

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

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...

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

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)

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

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

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

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:

1. 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.
   
2. 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.
   
3. 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.
   
4. 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.
   
5. 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

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!

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

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...

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...

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

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.