Wicket Katas

Overview
For this assignment we were given eleven different coding katas, for Wicket. A coding kata is a programming exercise, which through practice and repetition, will help you hone your skills. We were given eleven katas as Wicket programming exercises in hopes of helping us get a little more familiar with Wicket. Some of them were really easy while others were a bit more challenging, but doing these katas definitely helped me get more familiar with Wicket. I would definitely say that katas, in general, are good for helping someone get used to a new language, framework, or anything that they're new to. Repeating and practicing small exercises, at least from my experience, will help you get used to the new environment you're working in. I would say if you started with a few simple katas and then moved on to increasingly harder ones, you would probably have a firm understanding of whatever it was you were trying to learn. In the following section I will visit the eleven Wicket katas that we did in detail.

The Eleven Wicket Katas

• Exercise 01
  Kata 1A - Add a new line to the page that says, "In one week, the time will be ", where is replaced by a timestamp one week later than the timestamp that now appears on the page.
  • Finished: Yes
  • Time to complete: 10 minutes
  • Problems Encountered: The only problem I ran into for this kata was whether to use Date or Calendar for displaying the date. I couldn't figure out how to add time using Date, so I ended up using Calendar because it has an add method built in.
  Kata 1B - Add a button to the page labelled "Refresh". After pushing the button, the times update themselves.
  • Finished: Yes
  • Time to complete: 15 minutes
  • Problems Encountered: I had a problem with the buttons onSubmit method. I didn't realize that you have to override the onSubmit method.
  Kata 1C - Wicket, by default, runs in "Development" mode, but production systems should run in "Deployment" mode. Override the getConfigurationType() method so that Example01 now runs in Deployment mode.
  • Finished: Yes
  • Time to complete: 5 minutes
  • Problems Encountered: This kata was particularly easy; it just took a quick search to figure out how to change this setting.
• Exercise 02
  Kata 2A - Add an additional link on the home page that says, "Go to image page". Create this page, which should display an embedded image. This image should be G-rated. It should be in a .jpg file stored with the system, not retrieved from the web.
  • Finished: Yes
  • Time to complete: 1 hour
  • Problems Encountered: I got the image and link working properly within 5 minutes, but it took me an hour to figure out why the image wasn't rendering properly. After some help from other students I was able to fix the issue and get the image to render properly.
  Kata 2B - Add a button on the home page with the label, "Make font bold". After the user pushes it, all the text on the page should become bold, and the button label should change to "Make font italic". When the user pushes that button, all of the text should change to italic and the button label should change to "Make font normal". Pushing that button changes the text back to its original state and the button label should now say "Make font bold".
  • Finished: Yes
  • Time to complete: 25 minutes
  • Problems Encountered: Most of the time I spent on this kata was spent thinking of how I was going to program it. When I started programming it was pretty straight-forward and everything seemed to work smoothly.
• Exercise 03
  Kata 3A - Add a new tab called "Image" that takes the user to a page containing an embedded image (your choice, G-rated). It should be in a .jpg file stored with the system, not retrieved from the web.
  • Finished: Yes
  • Time to complete: 5 minutes
  • Problems Encountered: This kata was essentially the same as kata 2A so it was very easy to complete.
• Exercise 04
  Kata 4A - Add a new cheese called "Velveeta", which costs $0.25/lb.
  • Finished: Yes
  • Time to complete: 5 minutes
  • Problems Encountered: None, this was just a matter of adding a new item to the list of cheeses.
  Kata 4B - Add a "country" field to the billing address that appears when checking out. The country field should provide a drop-down menu with a selection of 5 countries.
  • Finished: Yes
  • Time to complete: 30 minutes
  • Problems Encountered: I didn't realize that I needed to modify the Address object at first, so I was only modifying the CheckoutPage java and html file. This caused errors to occur and it took me a while to figure out that I needed to modify the Address object and add in the country.
• Exercise 06
  Kata 6A - Get rid of the blue columns that appear when displaying the website. These are for development, not deployment purposes.
  • Finished: Yes
  • Time to complete: 2 minutes
  • Problems Encountered: No issues came up, I just had to change the style from "container showgrid" to "container".
  Kata 6B - Place the image underneath the form, not to the right.
  • Finished: Yes
  • Time to complete: 2 minutes
  • Problems Encountered: No issues, just had to make both the image and form divs used up the same amount of columns.
  Kata 6C - It is often convenient for web applications to consult a properties file when starting up in order to get configuration values. An easy way to do this is with the standard Java Properties mechanism. (See Java in a Nutshell for details on properties file manipulation.) For this Kata, modify your Example06 system to read in a file (if present) located in ~/.example06/configuration.properties.
  • Finished: Yes
  • Time to complete: 40 minutes
  • Problems Encountered: I just had to do some research on how to use Properties in Wicket, besides that everything was pretty straight forward.

Deliverables

• akinsey-wicket-example01
• akinsey-wicket-example02
• akinsey-wicket-example03
• akinsey-wicket-example04
• akinsey-wicket-example06

Wicket Chart Web Application

Overview
For this venture, we were given the task of creating a website with an interactive graph using Wicket and Google Visualization. Wicket is a Java based web application framework which basically allows you to use Java to create advanced web applications, and Google Visualization allows people to create dynamics graphs with all types of data. For this task we combined Wicket and Google Visualization to produce a webpage that allows you to modify the data values, ranges, and title of the graph displayed on the page.

Learning Wicket
As mentioned by the instructor of my Software Engineering class, Wicket has a very steep learning curve. Needless to say it wasn't easy to learn; even reading Wicket in Action, a book on Wicket, didn't fully prepare me for the actual programming aspect. At first glance, the code seemed quite overwhelming but after sitting down and actually studying the code I began to connect the pieces. In my opinion, frameworks like Wicket require hands on experience to actually learn how to use them.

To be completely honest, my general impression of Wicket is that it's excessively complicated to design what should be a really simple webpage. Take the page I designed for this assignment for example: it took me six java files and one html to create. If I were to create this same page in php, a web scripting language, it would take me a single php file and be immensely simpler. One thing I particularly liked about Wicket is the fact that you can use automated debugging tools such as checkstyle, findbugs, and pmd. Finally, like how I could used an automated building system like Ant to manage the entire project, as this greatly speeds up this development and distribution process.

The Web Application
As mentioned above the function of the web application is pretty straight forward: you can modify the form values on the left of the page and the changes will reflect on the chart displayed on the right. Below is a screen shot of the application to give everyone a better idea of what the application looks like:

Lessons Learned
Given the task, I learned that web application development is definitely not as easy as it seems. The process is definitely tedious, but life can be made easier by using tools such as ant, findbugs, checkstyle, and pmd. While doing this assignment, I was really just reassured about how necessary automated quality assurance tools are. I'm glad that I got some experience with Wicket in the process of doing this assignment, and I in the future it might be useful if I have to design a large web application.

Deliverables
My Wicket chart web application can be downloaded here:
http://www2.hawaii.edu/~akinsey/ics413/wicket-chart-akinsey-1.1.1117.zip

Solar Decathlon Project: Design

Overview
As mentioned in my last post, for this project we were given the task to design a mockup user interface for the home management system of Team Hawaii's Solar Decathlon house. Unlike the previous post, in this post I will go over the design aspect of the project. The overall approach we took was to design a system that anyone could simply pick up and use without much thought. As a result, we feel we have designed a pretty well rounded home management system that should cover most, if not all, bases.

Design
Like mentioned above, our goal was to design a system where the user doesn't have to put much thought into how it use it. We were trying to follow the Keep it simple, stupid! or KISS principle; this principle basically states that your design should be simple and straightforward. We tried to achieve this by designing a very basic and intuitive template and then used this template as a basis to design each of the pages for the home management system. The end result of our initial design, was a system that was pretty simple to understand and use:

After collaborating with my group members a few more times, we were able to come up with a final design that we felt was simple and very consistent throughout each of the pages. We went back and added a few finishing touches such as rounding corners, adjusting spacing, and aligning the pages with each other. Our last meeting was basically to polish our design and make sure all the pages were consistent with one another. The final design of the home management system can be found on our group's Google project hosting site. A few screenshots from our final design can be seen below:

As far as design, I actually learned some new things while designing the home management system. First, I learned that it's not such good practice to bombard the user with lots of data and charts. The second thing I learned was that it's important to put things in terms that the user will understand; don't use language that the average user won't understand. Finally, that it's better to put minimal information on a page than to make the user have to constantly scroll down.

Solar Decathlon Project: Working in Groups

Overview
For this project we were given the task to design a mockup user interface for the home management system of Team Hawaii's Solar Decathlon house. As a group, Noah Wooden, Kevin Leong, and I decided on which features we thought the home management system should implement and got to work on putting together a initial mockup to present to Team Hawaii. We collaborated using the issues system provided by Google project hosting.

Working in Groups
Working in groups for this project, was a fun and useful experience. Being assigned groups for this project gave us the chance to get to know each other a little better and I would also say that working in groups significantly sped up the design process. All we had to do was come to an agreement about who would work on each section.

Our group had four meetings:

• First Meeting: Introduce ourselves to each other, exchanged contact information, and outlined a very broad strategy on how we would approach the project.
• Second Meeting: Talked on the phone, examined each of our initial designs and picked what we liked from each, divvied up who would handle designing each page.
• Third Meeting: Met in class, briefly showed each other what we had been working on, made suggestions for changes on each other's pages.
• Fourth Meeting: Physically met with each other, hammered out each of the pages that we were suppose to design while getting feed back from each other. Meeting lasted about eight hours.

In my opinion the most useful meeting was probably the fourth, because we actually got to sit down with each other and give one to one feedback on each of the pages we were designing. That's not to say that the initial meetings were useless, as the second meeting was actually quite productive in the sense that we were able to decide on what features we liked and divided up the work between the three of us. The only thing I would change about our meeting process in the future, would be to split the fourth meeting into two meetings as it took quite some time.

Issue Driven Project Management
As mentioned above, we used Google project hosting's issues system to assign tasks to each of our group members. A screen shot of the issues system can be seen below:

I would say there were advantages and disadvantages to using the system. Using the issues system was definitely helpful for assigning specific tasks for each group member when we couldn't physically meet; this basically made each of us responsible for a task that we agreed to finish by a certain date. When we didn't physically meet this definitely helped speed up the design process, but when we did meet I would say that using the issues system slowed us down a bit. When we physically met we would vocally assign a page to each person as opposed to using the issues system. Even though we still assigned pages for each person to work on, I feel that we worked more as a group on each of our pages (e.g. giving each other feedback and tips). As a result, the issues system more of a hassle because we had to assign a task to each person when we were really working as a whole. When we met, I felt like we were just assigning issues because we had to and not because it was useful. In conclusion I would say that using the issues system was definitely advantageous when working separately, but when physically meeting it was more of a setback.