Wicket Katas

The assignment-of-the-week over my all-too-short thanksgiving weekend was to complete 11 "Wicket Katas."  Each "Kata" consisted of making a small change to an existing set of project files.  Additionally, we were supposed to time ourselves on how long we took to complete each Kata. 

The goal of "<Tech> Katas" in general is to gain expertise in a particular technology (in this case Wicket).  While I have some issue with the use of the word "Kata" in this situation, I must say that they were rather enjoyable to figure out, and I feel like I learned a lot of valuable Wicket concepts.  <Tech> Katas are excellent exercises for learning basic concepts in a new language, and I would definitely consider using them to teach others. 

I ended up working with two classmates to complete the assignment, which worked out well, as we all started out on different Katas, and helped each other whenever we got stuck.  It ended up being a small superiority contest, but it was all in good fun. 

The Katas:
http://code.google.com/p/wicketkatasglb/wiki/Katas

Kata 1A
~10 mins
I finished this in class, not too difficult.

Kata 1B
The rest of the class period...(~50 mins)
This one was a pain.  My environment wasn't configured correctly, and it took forever to finally figure out that I should have ran "ant build" first...  I should point out that the actual coding only took about 20 mins to complete.  The rest of the time was spent wrestling with Eclipse.

Kata 1C
~2 mins
Trivial.  Copied a block of code into my application class.

Kata 2A
~60 mins.
This was a little bit odd.  I actually did Kata 3A first, and tried copying my code into this project...it didn't work.  It turns out that my approach was too sophisticated for the implementation.  I had to get one of my friends to help me.  Honestly, I thought this one was a pointless repeat of  3A.

Kata 2B
~90 mins.
Originally, I had a single page with dynamic tags at the beginning and end of the page so that I could simply change the tags based on the current situation.  Didn't work.  I struggled for an hour trying to get my method calls to work with Wicket's framework.  In the end I just created three separate pages and linked them together.

Kata 3A
~30 mins
Not too bad, I had to look up how to do this on Google.  At one point the system was changing the variable name for my image from "image.jpg" to "image_en_.jpg" or something similar.  I eventually figured it out.

Kata 4A
~10 mins
Easy peasy.  Just follow the example and copy paste.

Kata 4B
~45 mins
Seemed simple enough...then I realized there was more going on that I was comprehending.  The program mysteriously told me i needed a get() method.  I stared it down for a good twenty minutes before phoning a friend.  As it turns out I needed to update the Address object...  I must say, the Cheeser program is really cool.

Kata 6A
~15 mins
Looked shockingly difficult.  The first place I looked was in the CSS files.  I tried deleting bits of code, but that didn't do anything.  Then I looked in the .html files and found what I was looking for. 

Kata 6B
~5 mins
Trivial after doing 6A.  I went straight to the FormPage.html file, saw the table structure, and moved the Wicket tag.

Kata 6C
Unfinished
This one sounded scary.  I read up on Java Properties, but couldn't figure it out...  (By this time I'm feeling totally burnt out, and willing to make do with 10/11).

Total Time:
~317 mins (approx 5 hrs).

There's about two hours of hidden time in there that was allocated to getting the system to pass quality assurance, uploading files, and writing this blog.

Our professor estimated that it would take 11hours to finish all 11 Katas, and he probably would have been right if I didn't have group members to ask for help.

Original Examples:
http://code.google.com/p/ics-wicket-examples/

The Katas:
http://code.google.com/p/wicketkatasglb/wiki/Katas

My Implementations:
http://code.google.com/p/wicketkatasglb/downloads/list (Individual Examples)
http://wicketkatasglb.googlecode.com/files/glb_Wicket_Katas.zip (All Examples)

Wicket Development

http://www2.hawaii.edu/~gburgess/wicket-example06-1.1.1118.zip
Wicket for those who don't know, is a back end hookup between the "stateless HTML and state-driven Java".  Basically, its the missing link (aside from applets) between Java and web pages.  One of the assignments for my Software Development class was to create a page that took in user input and generated a Google Visualization based on the input.  This was actually a pretty neat assignment, as it wasn't too much of a stretch to understand the Wicket code, and the result was a really cool program. The program works by taking in user inputs and using them to generate a URL for Google Visualizations, and then refreshing the image with the new URL.  Google Visualizations uses data passed by the URL to generate charts in real time. 

When I realized what was going on, I had a moment of shock, awe, and inspiration.  This is the kind of thing that makes programmers giggle and squeal for joy (or cackle).  Wicket seems like a pretty neat little framework as it extends my ability to program out onto the web.  While its true that applets can be embedded into web pages, this framework lets Java out of the box, and lets it frolic across the web.

I must admit, I was a bit shocked at the number of files that are necessary to run a single application, but they're all fairly short, and the connections between them are fairly straight forward.  The only real stumper that i came across was the WicketTester class.  It was pretty badly documented, and I wasn't sure what kind of path syntax it looks for, so my test case was pretty lame.  But I'm fairly impressed by the simplicity of Wicket, I was able to pick it up and run though a neat sample with ease.
http://www2.hawaii.edu/~gburgess/wicket-example06-1.1.1118.zip

The Design Process

For the past week my group has been working to revamp our mockup and finish implementing some missing functionalities.  It's been tough to come up with new material, as it seems that we've explored most every option.  At the same time, anything that we do come up with has to endure a barrage of design-oriented questions: Is it simple? functional? isn't that similar to x,y, and z? are you sure we can actually implement that?

It seems that our ideas got hung up on one of the professor's prerequisites:

Don't show the user any data they can't respond to. 

This statement alone culled out about 60% of the ideas we were able to brainstorm out over the past two weeks.  It's difficult to rationalize not presenting the user with relevant data simply because they can't act on it.  Case in point: the newspaper.  While users won't do much about a wild fire killing thousands of dingo-babies every hour, it's still interesting to read about.  If someone offered me a way to monitor Internet traffic levels over time, why wouldn't I be interested?  Despite my inability to affect the data in any significant way, it's still cool to have.  Anyway, this restricted us to visualizing only the data that users can respond to (which isn't much in a house that takes care of its self. 

Our "Design Process" consisted of a chat or two over Ventrilo, numerous in person talks, phone calls and Instant Messages.  Because we all know each other, we keep in contact almost daily, so all it took to breach the subject  was "So... about the house...".  Initially we sat down for about two hours and figured out the key systems that we wanted to implement, and then we dived up the work.  There was a fairly constant back and forth flow of proposing new ideas and asking for feedback.  Our resident artist thew together a template for all of our pages that contained main menu links embedded in a great-looking frame.  After that we went our separate ways and produced a pretty neat site if i do say so myself. 

We tried to keep the main pages simple, where users were shown some nice pictures with colorful text and links that took them to more detailed pages.  We also tried to translate our metrics into something more relevant for the user.  One of the best ideas (which we took from another group) was to use money as a way of expressing energy/water use.  We also tried to include "wizards" or "smart features" wherever we could.  These would allow users to set a budget for energy use (in dollar terms), and then the wizards would tell the user how long they can run the A/C or how hot their showers can be and still remain within budget. This allows users to interact with the system and overtime, get a feel for how much money (and therefore energy) a hot shower or an hour of air conditioning uses up. 

Our group felt a little limited by the Mockups program, as its sketchy lines and jagged edges took away from the sleek and elegant design we were going for.  In the end, there was a great deal of photoshoppery that was done, and a lot of our design elements were imported as image overlays. 

Issue Driven Project Management

Following up on the user stories assignment, we were tasked with creating mock-ups using Balsamiq Mockups to wire frame our ideas.  After liberal criticism, we were then put into groups of three and instructed to come up with the best system possible.  The goal was to experience software development as a team, as well as to utilize Issue-Driven Project Management (IDPM).  To prevent clobbering updates, the class used Subversion along with Google Project Hosting to keep a working repository.  see http://code.google.com/p/solar-decathlon-teamhawaii-2/source/browse/

For the uninformed, IDPM is a style of Project Management where changes/updates are targeted towards fixing errors posted by users or other developers.  Basically, its a way for developers to track issues, and ensure constant feedback.  In the scope of our project, this meant using Google's built in issue-tracking system to issue "tickets" or assign jobs.  Then, whenever we uploaded something to the repository, comments in our commit summaries would point to the issues that the changes addressed.

Overall the experience of working with a team was quite positive.  Our group ended up divvying up most of the page content between two people, and giving most of the design elements to one team member who had a remarkably good interface.  Working with a team really pushed me to try and get things done early, as I knew there were other people counting on me.  I foud that one of the best things to do when faced with team situations is to work with close friends.  First off, you can avoid the initial akwardness of getting to know each other.  Second, by being close friends, everyone respects eachother's ideas, but at the same time, its fine to poke fun at someone's idea.  In my case, I felt like our group was better able to assign tasks as we knew eachother's strong points and interests.  Ultimantely, I feel like we took the best aspects of our separate projects and melded them together better than the other teams. 

As far as the IDPM, I can't say that it was of much use.  This project is probably too small to realize the potential (which I admit, does exist) of IDPM.  It felt like a chore to have to create an issue and close it in order to make changes to a page.  I can see how it might benefit larger organizations where different teams might be pointing out errors and asking another team to fix something, but as it stands, this project really didn't benefit from it.