Pages

Friday, January 28, 2011

Berkeley Database Katas

Overview
For this task we continued working with Restlet and Wicket, but we added a persistent database into the mix this time. In the previous set of katas, the database we used was not persistent and the contacts would be wiped out when the program was quit. To maintain persistency in our system, we decided to use the embedded database system Berkeley DB. Because Berkeley DB is embedded, the database is stored within our contact system allowing our contacts to be persisted unlike our previous system.

For the first half of the exercise, we got practice using the secondary key functionality of Berkeley DB. For the first task we added a secondary timestamp key, which is calculated when adding a new contact to the database. Once we implemented the secondary key, we added functionality for get-timestamp which allows a user to request a contact by their timestamp, and get-range which allows users to request a group of contacts by supplying a range of timestamps. For the second task, we designed a system that consists of three parts: a Wicket web application client, a Restlet based server, and a persistent/embedded database using Berkeley DB. The Wicket webpage is a web based client which allows users to add and retrieve contacts by interfacing with the Restlet based server. The server, in turn, communicates with and performs actions on our embedded Berkeley database.

Berkeley Database Katas
These katas were pretty similar to the previous Restlet katas we did. These Berkeley DB katas actually used a combination of skills we learned while doing the first two sets of katas. We combined the Wicket web application from the first set of Katas, and the idea of a database from the second set of katas. The only difference was that the database used in these exercises was a persistent database while the one used in the previous assignment was not.
  • Kata 1: For this Kata, you will first implement a secondary key for Contacts that consists of a timestamp represented as a long value. Also implement get-timestamp and get-range functions for client use. Get-timestamp should allow the user to request a contact by its timestamp and get-range should return a group of contacts given a range of timestamps.
    Completed: Yes
    Time Spent: 1 hour 45 minutes

    Summary: This was fairly easy, it just required looking a the Berkeley DB API and examining the pre-existing code for the primary key in our system. Adding and calculating the timestamp was pretty straight-forward, I would say that the most difficult part was adding the get-range functionality, but when looking through the API I was able to find a section on grabbing ranges of keys. Writing the unit test probably took equally as long as completing the task.

  • Kata 2: Create a client-server system for managing contacts that Provides a Wicket client which consist of a single page, and allows the user to store a contact given its info, and retrieve a contact given its unique ID. The Wicket client code should invoke an underlying Restlet-based module to send a request to a ContactDB server to put or get data. The system should aslo provide a Restlet and BerkeleyDB server. The server should accept and process requests using Restlet, and use BerkeleyDB to persist the Contacts.
    Completed: Yes
    Time Spent: 5 hours 20 minutes

    Summary: The hardest part of this for me was probably conceptualizing how everything would interact with each other. After about an hour of studying how the pieces would fit together I was able to get started, and everything went pretty smooth for the most part. The only issue I ran into was trying to fix a bug with adding contacts through the Wicket web interface. I kept looking over the code thinking that everything should be working, and I couldn't figure out why it wasn't. Eventually I realized that I was passing the parameters, to create an instance of a Contact object, in the incorrect order. I guess it was just another lesson learned though. If you pay attention and do things carefully the first time, you can save yourself hours on trying to fix minor bugs.

    Another issue I ran into was having a static field in my WicketWebApp class. PMD was giving me an error saying that that the class had static variables which was unsafe. I believe it was unsafe because the variables were shared by all users accessing the web application. I solved the issue by adding sessions to the Wicket application. By adding sessions, multiple users can now access the web app which modifies one universal database.
Deliverables

Saturday, January 22, 2011

Restlet Katas Part II

Overview
This is only my second experience with Restlet, but I am getting more used to it, slowly but surely. I feel like this second exercise has given me much more insight about how Restlet works. The whole framework seems to be very client/server oriented and as a result I've been getting a lot of practice studying and programming the relationship between a client and server. Also, I'm actually starting to enjoy programming with Restlet as it uses Java which makes everything pretty straight forward and when I run into a problem I can always find the solution because there are so many resources for Java programming.

For this task we were asked to modify a pre-made Restlet project which allows for the storage, retrieval, and deletion of contacts using the put, get, and delete. There were three katas which ranged in difficulty: adding a new resource which would get all contacts in the system, adding support for get-all and delete-all, and finally adding a new parameter to the Contact class. In the following section I will go over my experiences with completing each kata.

Restlet Contact Service Katas
These additional katas were designed to help us learn a bit more about the Restlet framework and after completing these katas I feel that I am slowly getting more and more familiar with Restlet.
  • Kata 5: Modify the system to support a new resource called "contacts" and its associated URL: http:///contactservice/contacts. This resource only supports the GET operation and when it is invoked, it returns an XML representation of all of the contacts in the system.
    Completed: Yes
    Time Spent: 2 hours 10 minutes

    Summary: I think this kata took the longest because I had to actually sit down and study the code to figure out what each part did, before I could successfully finish it. Initially I tried to do the kata without studying the code, this ended up with me finishing it, but sloppily. After running an ant verify I realized how sloppily I had done this kata, so I went back and restructured my code from scratch. The second time around I had a much better idea of what I was doing and I finished it rather quickly. The hardest part for me was figuring out how to determine the host programmatically, after a long time searching I finally figured out I could use the following line:

         String host = getRequest().getRootRef().toString();

    After solving that, I ran into the issue of figuring out how to output the data in XML format; after studying the code for a few minutes I figured it out fairly easily.

  • Kata 6: Now that you have a contacts resource, extend the command line client to support a "get-all" and "delete-all" operation.
    Completed: Yes
    Time Spent: 1 hour 35 minutes

    Summary: I had a pretty good idea how to do this when starting the kata, though things didn't go as smoothly as I had planned. The first time I tried to complete this kata, I kept getting a NoClassDef error. I tried searching for a solution, but no matter what I tried I couldn't figure out why I was getting the error. I started from scratch a second time and made sure to test every little milestone of the kata I completed. Doing so helped me finish the kata without issue, like the first time.

  • Kata 7: Add a telephone number to the Contact resource, which only supports numbers and dashes.
    Completed: Yes
    Time Spent: 1 hour

    Summary: I actually completed this kata first, because it was the easiest of the three katas. Solving this kata was fairly easy, as we just had to add a new parameter to the Contact class. It was just a matter of looking at how the other parameters of the Contact class were used throughout the system, and just modifying the code to support the extra "phone" parameter. The hardest part of this kata was figuring out how to set the error status, if the phone number the user entered had something other than numbers and dashes. Checking for the numbers and dashes was simple using a regular expression, but I couldn't set the response using the piece of code:

         getResponse().setStatus(Status.CLIENT_ERROR_NOT_ACCEPTABLE);

    After trying to get this working unsuccessfully I consulted with my professor, and I felt really foolish when I realized it was because I was performing the validation in the wrong file. I was suppose to do the check in the ContactResource.java file, but instead I was doing it in the ContactClient.java file. After I moved the check to the proper file everything worked as expected.
Deliverables

Tuesday, January 18, 2011

Restlet Katas

Overview
This is the first time that I have ever worked with Restlet, which is web framework for Java that specializes in computer-computer interaction. As of right now, I still don't know too much about it and I'm not sure how we would use this in a larger project. For me there was quite a bit of a steep learning curve, as I was not able to find many examples of the code actually in use (mainly for the basic http authentication kata). Though, it seemed the longer that I worked with it the more familiar it became; hopefully as the semester progresses it will become easier to use.

Restlet Katas
By completing these Katas we were able to see a little of what Restlet does. We were able to set up a restlet web server that can authenticate the client and then spit out date and time to the user.
  • Kata 1: Add three new resources called "hour", "minute" and "second" which return the current hour, minute and second.
    Completed: Yes
    Time Spent: 35 minutes

    Summary: This exercise was pretty straight forward as I just copied the existing "month" resource and then proceeded to look up Java's Calendar API, to get the appropriate method name for the hour, minute, and second.

  • Kata 2: Setup logging by making restlet read in a logging.properties file.
    Completed: Yes
    Time Spent: 1 hour 45 minutes

    Summary: This took quite a bit longer than the first kata as the documentation wasn't very specific. Finding the bit of code to put in our server to make restlet read the properties file was easy, but finding the code to put inside of the properties file took much longer. I tried putting a few different things in the properties file which didn't work, after searching for about an hour I eventually found the correct settings for the file.

  • Kata 3: Authenticate requests with basic HTTP authentication.
    Completed: Yes
    Time Spent: 2 hours 35 minutes

    Summary: This took a really long time to figure out due to the restlet documentation not being very good. I searched for the proper code for about 2 hours trying many different pieces of code which I found; nothing seemed to work. At one point I had it authenticating, but still showing the data on the page before you type in your username and password. Eventually I found a good example of how to authenticate on StackOverflow, which can be seen here.

  • Kata 4: For this Kata, create a new client for the DateService server that is a web application using Wicket rather than a command line application.
    Completed: Yes
    Time Spent: 3 hours 25 minutes

    Summary: The biggest problem I ran into was that I was unable to get Jetty to work with Eclipse. I added jetty to the build.xml file for Ant, but regardless Eclipse would not recognize the jetty imports in my Jetty.java file even though they were in the lib directory of the project. I tried numerous ways of trying to import the Jetty libraries, eventually I realized I had to add the new Jetty jar files to Eclipse's build path for the project. After nearly three hours of frustration and making no progress, I finally was able to move on and work on the actual Wicket programing. The programing I had to do in Wicket was very simple: I just had to make a simple getResource method that calls on the Dateserver to request the resource. Even though this kata took me the longest to complete, it wasn't the hardest, both the logging and authentication katas were more difficult.
Deliverables