Tuesday, November 30, 2010

Wicket Katas

A code kata is an exercise in programming which helps hone your skills in through practice and repetition.  I completed 11 different Wicket katas by making small changes to existing Wicket systems.  These katas are thoroughly defined at 31.WicketKatas.

Example 01:
Kata 1A:  The task was to display a timestamp one week in the future.  This took about 20 minutes to complete.  Instead of using a Date class, I used to a Calendar class because it supported the addition of days to the current time.

Kata 1B:  The task was to add a button that refreshed the timestamp when clicked.  This took about 20 minutes to complete.  I added a form that refreshed the page and consequently the time displayed.

Kata 1C:  The task was to have Wicket run in "Deployment" instead of "Production" mode.  This took about 2 minutes to complete.  I simply looked up the appropriate method and added its 3 lines of code into ExampleApplication class.

Kata 1A and 1B
Example 02:
Kata 2A:  The task was to add a link to a page that embedded a locally saved image.  This took about 1 hour to complete.  The difficulty was in figuring out the correct path to the image.

Kata 2B:  The task was to add a button that made all text bold, italic, or normal in a linear order.  This task was the most difficult and took about 5 hours to complete.  First, all text and links in the html file were made into components so that they could be modified by Wicket.  Then depending on the current state, the text was changed to reflect the appropriate behavior such as adding <b> and <\b> to make it bold.  Finally, the method setEscapeModelStrings was set to false so that Wicket did not escape '<' and '>' characters.

Kata 2B
Example 03:
Kata 3A:  The task was to add a link to a page that embedded a locally saved image.  This took about 10 minutes to complete.  It was very similar to 2A with the exception that I had to create a separate package for the image page.

Kata 3A
Example 04:
Kata 4A:  The task was to add a new cheese called "Velveeta" with a cost of $0.25/lb.  This took about 10 minutes to complete.  The most time-consuming part was finding the class file that contained the collection of cheeses.

Kata 4B:  The task was to add an additional "country" field to the checkout page.  This took about 15 minutes to complete.  The most difficult part was tracking down the changes had to be made in different class and html files.

Kata 4A
Example 06:
Kata 6A:  The task was to remove the blue columns on the website.  This took about 15 minutes to complete. I simply had to track down the showgrid option in the css file and delete it.

Kata 6B:  The task was to place the image underneath the form instead of to the right.  This took about 5 minutes to complete.  I did this by removing the <div> <\div> tags in the html file.

Kata 6C:  The task was to have the application run in deployment or production mode depending on the "deployment" status in a configuration file.  This took about 1.5 hours to complete.  The difficulty was in figuring out the correct path of the configuration file and testing to see that it worked.

Kata 6B
These Wicket katas were very useful in transitioning to a new framework.  I learned how to add forms, buttons, images, and much more by modifying existing systems.  These exercises also reinforced how Wicket components interact with hypertext markup language.

My modifications are available for download below:

Example 01
Example 02
Example 03
Example 04
Example 06

Thursday, November 18, 2010

Apache Wicket

Apache Wicket is a Java web application framework that bridges the mismatch between stateless HTTP and stateful server-side programming in Java.  Its goal is to be easy, reusable, non-intrusive, safe, and scalable.  Large companies like IBM, VeriSign, Amazon, and SAS have already joined the Wicket community for large, scalable front-end websites or internal projects with a high degree of UI complexity.

My involvement with Wicket is geared toward learning a framework that will enable me to build rich and interactive webpages for the 2011 Solar Decathlon competition.  My initial experience with Wicket was parallel to learning a completely new language.  I would be taking a giant leap into the unknown, but it would be a pivotal point in learning how to create useful real-world applications.  This leap was made much easier with the guidance of ics-wicket-examples.

An interactive web page made with HTML, Java, Wicket, CSS, and Google Visualizations.

My task was to develop a simple but interactive webpage that enabled users to modify the parameters of the  GoogleOMeter seen above.  First, Wicket is used to pull user input values from the webpage into Java.  Second, Java is used to process and edit the chart's parameters with the user's input values.  Finally, the chart is updated and displayed with its new URL.

The key to Wicket was knowing that components in HTML and Java are linked together by a common identifier.  Once this was understood, the next and most difficult step was interpreting user input and responding with appropriate output.  The difficulty was in part due to Wicket's new libraries and API.

From this experience, I learned that the career of a web application developer is not easy.  Jumping from framework to framework is time-consuming and frustrating, but there are tools like Wicket that ease the pain by helping developers create modular components that can be reused between projects.

My Wicket project is available here.

Solar Decathlon Design

Building on the the last three blog entries, my task for this week was to design a web-based interface for the solar house's home management system.  Balsamiq provided a free copy of their wireframing tool to aid me in this task.

The initial design process was extremely difficult because it was a first in designing a web-based user interface.  The first round of designs were a failure because I did not have a good grasp on what constituted a great web design.  After receiving feedback, some key elements were ironed out.  The most important element was to accompany each data visualization with an interpretation and offer a way for the user to respond.

A subsequent round of design brought an improvement to the user interface, but it still lacked the most important element described above.  For the third round of design, I was assigned to work in a team of four (Team 3) and to practice issue driven project management.

2nd round of design.
3rd round of design.

As seen above, the quality of the aquaponics page improved in each round of design.  Users are now able to see statistics easily, have the system recommend a course of action, and respond accordingly to the situation.  We took the best ideas from each team member's design and combined them to make a higher quality page.  Individual members' previous designs are available here.

With the bulk of our pages complete, the final steps were to create the homepage, iron out any glaring inconsistencies between our team members' work, and then link everything together in preparation for the presentation.

Thursday, November 11, 2010

Issue Driven Design Project Management

For the third round of the Solar Decathlon design, I was assigned to work in a team of four (Team 3) and to practice issue driven project management.  Issue driven project management describes a project management technique that is based on creating many small tasks (or issues) that require only a day or two to complete.  These tasks are divided equally among project members and the goal is to create a more comprehensive solution for the Solar Decathalon home management system.

In Google Project Hosting, issues are first created and then given both an owner and a status.
Generally, the progressions of issues are New > Accepted > Started > Done > Fixed.
Working in teams produced the best results because it allowed us to spend more time on each page since the workload for each individual person was lessened.  The first problem my team encountered was deciding on a standard template.  This issue blocked us for several days until we all agreed on the template.  From there, we incorporated all the feedback we were given into our third round of designs.  To ensure that requirements were met and consistency was maintained, I created a checklist that each page should adhere.

Although issue driven project management may have had a lot of overhead in the beginning (via meetings and time spent to standardize our designs), I think it was worth it because we were able to achieve a much higher level of quality in a shorter amount of time.  We always knew what we had to do and what other project members were doing, and thus, this made us more efficient in working together.