31.WicketKatas

Overview Code katas are exercises in programming that help you to refine your skills.  The goal of this assignment is to: Improve your comfort level with Wicket by performing a number of small changes to existing Wicket systems. Each Kata involves a modification to one of the example systems in the ICS Wicket Examples project.   To start, I downloaded all the .zip distribution of all examples but example05 to your local system.  I edited the build.xml file so that the project name is no longer exampleNN, but rather exampleNN-kteichma. I then ran "verify.build.xml" using Eclipse. These example files were modified in the following ways: The Eleven Wicket Katas Example 01: Kata 1A:  Add a new line to the page that says, "In one week, the time will be <time>", where <time> is replaced by a timestamp one week later than the timestamp that now appears on the page. Kata 1B: Add a button to the page labelled "Refresh".  After pushing the button, the times update themselves. 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.  See this page for details.  This particular example was finished by my partner and I during our class period. It took about 40 minutes. Professor Johnson gave some nice hints on how to you the java Date constructor to make a date from a timestamp. I was able to review form usage in this particular kata and discover the development mode. Example 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. 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". Kata 2A was finished in class. Estimated time it taken to complete was around 40 minutes. I can't remember too much about this one other than it took us a while to figure out that there was an Image object we could use to add pictures stored on the system to the webpage. Kata 2B was a little harder, and I'm not quite pleased with the solution I implemented. I ended up making separate form pages for italicized and bold lettering. There is obviously a better way to do this, such has make bold and other style labels, but this was the only solution that occurred to me in my lack of time. Example 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. This particular example took about 10 minutes as it was very simular to example 2a. It was almost a no brainer as I was able to copy and paste most of the code used in kata 2A. Example 04: Kata 4A:  Add a new cheese called "Velveeta", which costs $0.25/lb. 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. This particular example took 40 minutes. I had some issues with this particular kata in that it took a while to figure out how the data was stored. It will be interesting to eventually see how this front end will end up working with DB back end. As of now, all of the entries are hard coded into the java source. Example 06: Record how long it took you to accomplish each of these katas. Kata 6A:  Get rid of the blue columns that appear when displaying the website. These are for development, not deployment purposes. Kata 6B:  Place the image underneath the form, not to the right. 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.   (Note that ~ means "the user's home directory", and that there is a System property in Java that provides this value.)  This property file should contain a line like the following: deployment = true In other words, it contains a property called "deployment" whose value is true if the Wicket application should run in deployment mode, otherwise the application should run in development mode (see Kata 1C). Your application should read in the properties file and set the System property wicket.configuration before starting up Wicket. The Jetty class is a convenient place to do this processing. Finally, your application should write out a message on startup indicating whether or not it found the file, and what the resulting configuration mode will be.  If the file is not found, or the property is not present in the file, then the application should run in development mode.  This particular example took me another 40 minutes. I still was not able to finish Kata 6C as I have been running out of time juggling ICS311 and ICS413 and ICS321 these past 2 days. Big projects all due at the same time. Kata 6A was a fairly easy change as turning off the grid doesn't require much. As for kata 6B,  this just required some basic knowledge on how grids work and making more area. Overall, I enjoyed the process of experimenting with Wicket and I look forward to using it more extensively in the future. However, I do recommend keeping our options open as http://oodt.jpl.nasa.gov/better-web-app.mov provided by Professor Chin in my 215 scripting class, shows that there are great alternatives out there. Here is a link to my distribution file

30.WicketChart

The Wicket Project we were assigned was to implement a one page web application that provides two components: 

1. A form that accepts a variety of parameters
2. Along with a submit button that when pressed, generates a GoogleOMeter visualization.  

To see what a GoogleOMeter is, go to http://imagecharteditor.appspot.com/, then click "Show full gallery", then scroll to the bottom.  The last three visualizations are GoogleOMeters. I ended up choosing the 3rd visualization

The form should allow the user to: 

• Set the start and end of the Y axis;
• Set the title
• Set the width
• Set the height
• Provide a data value for the pointer

The web application in general should:

• Use Wicket
• Use Blueprint CSS for layout
• Use the ICS 413 build system
• Provide at least one useful test case
• Employ sessions so that multiple users can generate charts independently

In terms of testing, I employed that the lower bound and upper bound values would have error checking to see if the user had inputted nonnumerical characters. Since extract a string from these text boxes via Double.parseDouble(), if there is, for example, a letter in the "Lower Bound" text box, this would cause an exception. My program catches this exception and immediately sets the values of all the bounds, lower, mean, and upper to zero. On the case that the user enters correct input, the "Mean" becomes the average of the lower and upper bounds. My JUnit test explicitly tests for this particular case of erroneous user input and verifies that the "Mean" value gets set to "0.0" to allow for the chart to still be created with safe values.

The overall experience of this assignment was quite good. The CSS grid style layout was fun to play and felt similar to other grid layouts used in other various programming language interface structures. See http://www.learncomputer.com/blueprint-css/ for reference on the CSS system we employ in our web application.


Using sessions and the ICS413 build system proved to be tedious, but nice once everything was working properly. Going through all the errors and satisfying what was generated by our style checkers (build.pmd.xml and build.checkstyle.xml) was a pain to say the least. It was almost as painful as porting the form provided by Professor Johnson's wicket-example06 into a single page to be viewed and interacted with by a user. It really forced me to read through the code and figure out how the wicket system works. However, the overall experience was a good exercise in problem solving and hard work. I look forward to working with Wicket in the future.

My distribution for this assignment can be found here.

27.DecathlonDesign3

The design aspect of the Solar Decathlon system was fairly difficult. With limited input from the lead management, we were left to guess what we thought would be relevant information to be displayed to a user. What do we think would be important to know? Where should the system's priorities lie? These were questions we had to consider while creating the balsamiq mockups. When our team met together to delegate what jobs we should do, I was assigned the Aquaponics and Lighting systems. These two features and the desired design will be explained in the following paragraphs.

Since the engineers had not given us specifications on each particular system, we all had to do a bit of research. For my particular case, it was necessary to research a bit about aquaponics and they key concepts surrounding it. I had to figure out what chemicals and attributes typically need to be monitored. I also had to decide upon what things a user realistically has control of. In the end, I made my best guess and hopefully it wasn't too far off the mark. I decided the picture visualization of the health of the fish and the plant would be a very straightforward indicator of the current status of that particular system.

In terms of the lighting system, it was hard not to reinvent the wheel. I tried to think of some new things that would be nice to set from the web interface. Color seemed to be an important feature of the LEDs explained to us by the engineers so I wanted to set up a way that the user could interact with such lights and set their respective colors. I ended up going with using an interface much like that found in adobe photoshop (almost exactly hah!).

I originally added to function to completely disallow certain lights to be enabled. However, I ended up revising this due to lack of creativity on my part. In our particular design, the user should be able to intuitively click areas of the house to light up key areas both inside and outside the house.

Both features, aquaponics & lighting, have the option to be automatically controlled by the house systems, or to be manually set by the user. Since the house should be self-sustaining, the system should have the option to promote this ideal as well.

Design is hard. Making good design decisions takes a lot of work and a lot of testing. In our case, my team and I simply consulted with each other on what would make for good features for our system. I believe we ended up taking an approach that was very similar to the "Apple" design concepts with the way we tried to make intuitive visualizations that any type of user could quickly understand. The KISS (Keep It Simple Stupid) approach was another concept we tried to keep in mind.

27.DecathlonDesign2

The process of issue driven design was a very interesting experience. Our job for stage 2 of the design process required that I, and two other classmates, team up to polish one of our designs. We had to learn how to work with one another and instigate good patterns of production. The trials and tribulations we faced were few, but significant. Overall the journey of teamwork and coordination proved to be successful, at least from my point of view. I hope the same was felt by my other teammates.


In terms of communication, I believe that my partners, Tony Gaskell and Gregory Burgess, and I performed quite well. We managed to contact each other through the America Online Internet Messaging service to ask for tips and insight on features that should be included in the mockups. We also coordinated a bit during class. Tony provided the layout knowledge as his design was selected by Professor Johnson for us to work on. We summarily delegated tasks to each other. I performed the design for the Aquaponics and Lighting systems of the house. Here is a link to our project's website : http://code.google.com/p/solar-decathlon-teamhawaii-2/

The hardest part of this assignment was methodically writing down each issue as they came to mind. I noticed that during the time I was designing, I was in a sort of a creative flow. I did not want to break the flow to write down each issue I came across and implemented. I feel like the act of writing would take me out of my zone and it would often take a while to get back into the zone. Perhaps with more practice, I will be able to self document these ideas as they come, but I found it quite hindering at this point in time.



In the end, I believe the whole process of this exercise was very useful. Setting tasks for oneself and accomplishing them in a timely manner is very conducive to a professional persona. Hopefully with more practice I will be able to show that I have predictable production as it seems like this type of issue driven development incorporates this. It should be noted that I feel like there are a few more things I would like to add to my systems, and I don't feel like they are ready for presentation at this point in time. They soon, however, will be ready.