Berkeley DB Katas

After learning the REST for the last couple of weeks, we are now tackling the database persistency with the use of an open source called Berkeley DB. The last couple of Kata's that we did, data was temporarily stored in the program and then deleted after the program finished running. This week, we are learning database persistency, which stores the data permanently somewhere in the program just like a real database. Below are the Katas that we needed to do to get familiar with persistency.

TO DO: Kata 1: Timestamp as secondary index

The example system provides a single key for retrieval of a Contact: it's unique ID. For this Kata, we will first implement a secondary key for Contacts that consists of a timestamp represented as a long value. For example, (new Date()).getValue() returns the current time as a long value.  This timestamp could mean a variety of things in practice, such as the time the contact was created, or the contact's birthday, etc., but we won't worry about that for now. 

Write unit tests to make sure that your secondary index works correctly, and that in particular you can retrieve a set of Contacts whose timestamps fall within a specified range.  

Once implemented, extend the ContactClient system with two new commands:

• get-timestamp: returns the Contact with the given timestamp, if such a Contact exists.
• get-range: returns the set of Contacts with timestamps between two specified values. 

Note that all of the sensor data in the Solar Decathlon system will have timestamps associated with them, and a frequent operation on the database will be to retrieve the sensor data instances during a given time period, so this kata will help you understand how to do that.

RESULT: This Kata was very confusing at first specifically the relation that we need to use for the secondary index. We decided to chose ONE_TO_ONE. It took us about half an hour to decide on this. We first tried to use ONE_TO_MANY but it needs an array or collection to hold the key. This made the addition of secondary key a lot harder. Since I don't any experience with databases,  I over think this simple problem and cost me to consume more time finishing this Kata. It took me more than 2 hours to finish this Kata.

TO DO: Kata 2: Wicket, REST, and BerkeleyDB

Create a client-server system for managing contacts that:

1. Provides a Wicket client.  The wicket client should consist of a single page, and allow 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.
2. Provides a Restlet and BerkeleyDB server.  The server should accept and process requests using Restlet, and use BerkeleyDB to persist the Contacts.

Below is the diagram on how we suppose to accomplish this task.

RESULT: This Kata as expected is the hardest. This pretty much the combination of what we learned so far from the last semester to this current one. This is also the introduction on what we're going to be working on for the rest of the semester- the Home Management System for the Team Hawaii's house. Each system that we learned so far will be part of the web-based services:  user interface (Wicket), communication (Restlet), and persistent storage (BerkeleyDB). The way I looked at this Kata is in a more familiar way: Wicket is HTML, Restlet is PHP and Berkeley DB is SQL. The idea is similar where HTML display the UI and uses PHP to communicate to the SQL database, but the implementation are way different and a requires a lot more work. There are a lot of stuff going on on this Kata. I adapted the Wicket web interface from the REST I Kata, making sure that all necessary API's and programs were downloaded. We were also warned that we needed to use session for this Kata which made it a lot harder because we have to read and research to make this work. This Kata cost me about a day (8 hrs) and lots of research and head bumping on the table.

Download: Berkeley DB Katas

REST II

After struggling with the first set of REST Katas we have another sets to be completed. This time is about contacts also known as phone book. We are to manipulate add/edit code to accomplish the following Katas:

TO DO: Kata 5: Contacts resource

Modify the system to support a new resource called "contacts" and its associated URL: http://<host>/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.  To support the RESTful style of hypertextual links, your XML should look like the following:

<contacts>

  <contact>http://host/contactservice/contact/ID</contact>

  <contact>http://host/contactservice/contact/ID</contact>

</contacts>

Of course, we will substitute the actual <host> and actual <ID> for all <contact> elements in the returned XML.

Our system needs to programmatically determine the URL of the current host.  One way to do this is with code like the following inside your ServerResource method:

• new Reference(getReference(), "..").getTargetRef().toString()

We will also need to extend the createInboundRoot() method to support this new resource, and add a new package, class, and associated unit test.

RESULT: This is the hardest of all this part's Katas. I'm so confuse on how to do this. I didn't really know how to start implementing this task. With hours of research and help from other classmates I was able to accomplish this. The idea was to iterate through each contact and add it into the XML file. It took me about 4 to finish this Kata.

TO DO: Kata 6: Command line client manipulation of Contacts resource

Now that we have a contacts resource, extend the command line client to support a "get-all" and "delete-all" operation.  

The getall operation should invoke the GET contacts command to get the XML representation containing links to all the contacts, then extract the URL of each contact and perform a GET to retrieve its representation. Then print out the contact info associated with that URL (I.e. first name, last name, info). 

The delete-all operation should use the GET contacts command to get the XML representation containing links to all of the contacts, then extract the URLs, then call DELETE to delete them. 

RESULT: This wasn't bad to implement but it still took time to finish. Most of the time was used to research and try out some code that would work. The idea is to iterate to all the contacts in the XML and do either delete or get. There were a lot of resources that I found to do this but I had to tweak it to accomplish what I needed. It took me about 2 hours for this Kata.

TO DO: Kata 7: Add a telephone number to the Contact resource

Finally, extend the Contact resource to include a telephone number.  The telephone number must contain only numbers and the "-" character.  When clients do a PUT of a Contact representation in XML format, the server must check that the telephone number field has the correct format and set the Status field to indicate an error if the telephone number is incorrectly formatted. Write unit tests to check both valid and invalid PUTs of your enhanced Contact resource. 

RESULT: This is the easiest Kata. It was just a matter of adding all instance of phone number on all the modules. Although the easiest, it still took time to find the right place in the code to put the phone number. It me about 1 hour for this Kata.

DOWNLOAD: Restlet Katas II

REST

Classes just started which means a new semester of learning is coming. It didn't take that long before we actually dive deep into this learning experience. The first week of my class in Software Engineering focuses on REST and no, not that kind of rest, but Representation State Transfer. Wikipedia defines it as a style of software architecture for distributed hypermedia systems such as the World Wide Web. This is the first time that I've seen and heard of it and I'm sure most of the class too. We are learning REST to incorporate the project that we did last semester which is the front-end for the Team Hawaii's house's Home Management System. To be able to get familiarize with REST, we were ask to do some Katas.  Basically we have a DateClient and DateServer that we need to add/modify to be able to accomplish these Katas. Below are the 4 different Katas that we need to do.

TO DO : Kata 1: Time resources. Add three new resources called "hour", "minute" and "second" that return the current hour, minute and second.  

• Write unit tests for each of these resources and make sure they pass, and make sure you can run them both from within Eclipse and using Ant.  
• Make sure the DateClient system accepts these parameters. 
• Ensure that "ant -f verify.build.xml" passes with no errors.  

 RESULT: This is fairly easy. There's already a Day resources that exist that we need to copy and change part of it to retrieve/show hour, minute and second. It took me about 15 mins to finish this.

TO DO: Kata 2: Logging. By default, Restlet logs data about each request to the command line using the Java Logging API.  Read a tutorial (and/or google) to get familiar with the API, then do the following:

• define a ~/.dateservice/logging.properties file that enables the user to specify (among other things) that the logging information should go to a file, not the command line.
• tell the restlet-dateservice application to read and use the logging properties file in  ~/.dateservice/logging.properties

RESULT: This is a lot harder than the first one. Researching and reading tutorials took most of the time to accomplish this Kata. Some tutorial also varies and sometimes don't work on the current version or task that we needed to do. I have to create a property file inside a hidden folder in our home directory. I also needed to add a line inside the main method on the server to direct all logs into the same folder of the property file that I created. It took me about an hour to read tutorials and 30 minutes to actually code it. 

 

TO DO: Kata 3: Authentication. The current restlet-dateservice system performs no authentication.  Check the user guide (and/or google) for guidance, then implement HTTP Basic authentication for all the resources in the restlet-dateservice system.  To simplify things, all resources should be available as long as the requesting system uses HTTP Basic authentication and passes the username "guest" and password "pw". (You can hardcode that password into both the client and server sides of the system if you like.)

 

RESULT: Of course this is harder than the previous ones. I was able to find some tutorials online to help me accomplished this but none of them really are straight forward. I've tried different codes but none of them worked. I found this link that explained and showed the basic authentication in REST. It took me about 2 hours of searching and trying out tutorials and another 30 minutes to finish it once I found the tutorial that worked.

 

TO DO: Kata 4: Wicket. For this Kata, create a new client for the DateService server that is a web application using Wicket rather than a command line application.  The web application should bring up a single page with a single form that requests what aspect of the date (year, month, day, hour, minute second) the user desires. When the user submits the form, the web application uses Restlet to obtain the appropriate information from the DateService server, then presents the results to the user in the page.  

 

RESULT: To be honest, this Kata is the most I'm worried about. I wasn't able to figure this out. I tried couple solution like importing wicket in the build.xml file but no success. I'm currently still working on it, so the current distribution file for my program is incomplete. It took me about 3-4 hrs so far for this Kata.

Download: Restlet Katas