A26: Model Implementation

This week, we focused our attention on another critically important part of any web application; persistent data. Up to this point, our applications relied on in-memory repositories, which were great because they were easy to work with and debug, however, as soon as that application stopped running, the data was gone. Implementing a persistent back-end, MySQL in our case, solves this problem.

In this weeks WODs, we learned how to implement a MySQL backend into both local and deployed applications. Complete descriptions of the WODs can be found on the ICS314 website here.

WOD ModelImplementation-1: DigitsMySQL

Goal: Learn how to implement back-end persistence for our web apps using MySQL and EBean.

Prior to attempting this WOD, I read through all of the assigned reading. Despite this preparation, I still found this exercise extremely difficult. In fact, I would say that this was perhaps the most difficult WODs assigned this semester. I was not able to complete the exercise on my first attempt and DNF’d after an hour and 30 minutes. The following are a few of the reasons I think this exercise was so difficult:

1. During my first attempt, I didn’t have a very good understanding of the functions of annotations and how they affect the creation and structure of the database tables. I also didn’t understand how to designate a relationship between two different entity instances.
2. There doesn’t seem to be a way to debug the app as you’re building it. In previous WODs, we were able to write a little bit of code then refresh the browser to test that the application still works. When implementing the database backend, one has to set the whole thing up first (import the right classes, annotate the appropriate objects and fields, and update the implicated methods) before testing can occur.

Immediately after failing to complete the exercise, I watched Dr. Johnson’s solution and took notes on his implementation and explanation of his approach (I did the same thing during the Authentication and Authorization WOD and found it very helpful in completing both the at home and in class exercises). I repeated the WOD and was able to complete in Av time of 1 hour and 7 minutes. Later that night, I decided to test my retention of what I had learned and repeated this WOD. I finished my third attempt in Rx time of 46 minutes and 27 seconds.

WOD ModelImplementation-2: DigitsCloudBees

Goal: Learn how to deploy a MySQL-backed Play application to CloudBees.

Compared to the previous WOD, this exercise was a breeze. Not only did Dr. Johnson provide us with hints, but we previously deployed a MySQL backed application in assignment A25. Since this WOD was a review of a process we’ve already done, I was able to complete it in Rx time of 22 minutes and 22 seconds on my first attempt.

Although the last couple of assignments have been difficult, I feel that with the skills we’ve acquired (such as authentication and authorization and persistent data) we now have all the tools we need to create effective web applications.

A25: Learning and Using MySQL

Goal: Learn how to install MySQL and a MySQL client.

Installing MySQL was a painless process. Dr. Johnson provided clear and easy to follow instructions and if that wasn’t enough, MySQL provides great documentation. After installing the program and preferences pane, we were instructed to set admin credentials. To do this, we needed to invoke the mysql command which I was not initially able to do. After a few minutes of Googling, I was able to find an article that detailed the process of adding the program path to my environment variable so the mysql command could be invoked from any directory. After making this change, I had no problems accessing the database and setting credentials.

The rest of this WOD was fairly easy since most of it consisted of copying and pasting code from the instructions to the terminal. However, it was nice to see, first hand, that creating databases, adding tables, and manipulating data is very easy to do.

Deploying the application to Cloudbees and setting up the database was also fairly simple since it was just a matter of following instructions. I did have some trouble obtaining my database credentials from Cloudbees. After a few minutes of digging, I realized that although I named my application “play-mysql”, the database instance was named “play_mysql_tg0u”. After correcting the terminal command to include the appropriate name, I was able to obtain the credential information and make required changes to get the application running.

Although this was a simple exercise, I learned a lot and I feel that it was a good introduction to using MySQL.

A24: Model Design

This was a strange week for ICS341 students. For the first time this semester, there was no programming component to this weeks WODs. Each exercise focused on analyzing textual descriptions of problems and deriving Entity-Relationship diagrams of these situations. The scenarios presented included managing inventory in a warehouse, reservations in a library, and vehicle rentals at a car rental company. More details about each scenario can be found on the ICS314 website here.

Practice WOD ModelDesign-1: Warehouse

Goal: Using Lucid Charts, create an appropriate Entity-Relationship Diagram by analyzing the warehouse example given in chapter 7 of the Play for Java textbook.

Prior to attempting this exercise, I read through all the required reading including chapter 7 of the “Play for Java” text. A great deal of this chapter is spend exploring the warehouse example, and as a result, I found creating the ERD fairly simple. Also, using Lucid Charts is intuitive and takes very little time to learn. I was able to complete this WOD in Av time of 10 minutes and 42 seconds. The majority of this time was spent determining the appropriate “crows-foot” notation to use to describe the relationship between entity types.

Entity-Relationship Diagram – Warehouse

Practice WOD ModelDesign-2: Library

Goal: Using Lucid Charts, create an appropriate Entity-Relationship Diagram by analyzing the library scenario described by the instructor.

Like the previous WOD, I found this exercise fairly easy to complete and finished in Rx time of 10 minutes, 55 seconds. My solution differs slightly from Dr. Johnson’s, but only in the fields captured in the entity type. Generally, the entity types and relationships are the same.

Entity-Relationship Diagram – Library

Practice WOD ModelDesign-3: CarRental

Goal: Using Lucid Charts, create an appropriate Entity-Relationship Diagram by analyzing the car rental situation described by the instructor.

Again, like the previous two exercises, I found this WOD fairly easy and was able to finish in Av time of 15 minutes, 4 seconds. Unlike the previous exercise, my solution didn’t share the same structure as Dr. Johnson’s solution. For example, whereas Dr. Johnson combined both cars and trucks into a single “vehicle” entity, I separated them as two different entity types. Also, my reservation entity is not associated with a vehicle directly but rather through the office entity. Although my design is different from Dr. Johnson’s, I think it addresses all of the requirements, however, it is difficult to know for sure without implementing the design.

Entity-Relationship Diagram – Car Rental

Based on this weeks WODs, I feel that part of the difficultly in creating ERDs stems from the fact that these problem sets are open to interpretation and that what I think may be important to include in a design, may actually not be that important (i.e. separating cars from trucks Vs creating a single ‘vehicle’ entity). Luckily the scenarios presented in this weeks WODs were pretty straight forward and easy to understand. Going forward, I would like to do more of these types of problems on my own to develop this skill so I won’t have to rely on luck.

A23: Authentication and Authorization

This week, we studied 2 important features that help to control and protect your data, user Authentication and Authorization. Our WOD exercises focused mainly on implementing these features into our Digits application.

A complete description of the WODs can be found here.

WOD 1 – DigitsLogin

Goal: Add a login page to the Digits system so that only an authenticated user can access the list of contacts.

Prior to attempting this WOD, I watched Dr. Johnson’s lecture on the material and studied the example application, however, I still found this exercise challenging. What made it difficult was the number of additions and changes to the code needed to implement this functionality.

I attempted to rewrite most of the code from memory during my first attempt at this WOD and finished in DNF time of 45 minutes and 56 seconds. After watching Dr. Johnson’s solution, I reattempted the WOD, this time copying code over from the example application into my own and completed in 19 minutes, 16 seconds. Although this qualified as Rx time, I still felt that I didn’t understand the material and process well enough to remember how to implement authentication in an app even a few hours from then so I decided to re-watch Dr. Johnson’s solution, and take notes on the process. I attempt this WOD a third time, referring to my notes, and completed in Rx time of 17 minutes, 21 seconds.

WOD 2 – Multiuser

Goal: Modify the application so each contact is associated with a single user then when displaying a list of contacts, only print those associated with the current user.

My first attempt at this WOD went fairly well and I was able to implement the requirements in Sd time of 19 minutes, 57 seconds. In order to implement this functionality, I updated my Contact model to include an “owner” field that stored the email address of the user adding that contact. Then, when looping through the list of contacts in the Index.scala.html file, only those contacts whose owner was the same as the current user would be printed. While writing the code, I didn’t spend much time thinking about the design; my goal was to just finish the assignment. However, while watching Dr. Johnson implement his solution which utilized a hashmap of hashmaps, I realized that my design was horribly inefficient (especially as the number of contacts in the database grows).

I decided to repeat the WOD, this time implementing Dr. Johnson’s solution and DNF’d with a time of 23 minutes and 28 seconds. The reason I failed to complete this attempt was because I noticed a bug in the implementation and spent some time correcting it. The bug occurs when attempting to add contacts to the database. In Dr. Johnson’s solution, the id assigned by the database is calculated off of the hashmap of users, not the hashmap of the contacts. The way I fixed this was by first checking if a users exists in the database and if not, adding that user to the hashmap of users, then calculating the id value off of the hashmap for that user. After resolving this, I decided to do the WOD once more and this time, I finished it in Av time of 12 minutes, 45 seconds.

WOD 3 – Cloud Authentication

Goal: Incorporate the use of environment variables to avoid including authentication credentials into source code.

I found this WOD very difficult to complete because there was little information given on the use of environment variables and I wasn’t very successful at finding any helpful information online. I spent approximately 45 minutes trying to implement this function before giving up (DNF). After watching Dr. Johnson’s solution, it turns out that this isn’t very difficult to implement. The hardest part of this WOD was figuring out how to add environment variables to my system (since my .profile file didn’t exist) and assigning the environment variable values to a variables in my code. Once this was set up, implementing the rest of the WOD, as well as deploying the app to Couldbees and setting environment variables there, was simple. I was able to complete this WOD in Av time of 34 minutes, 31 seconds.

In everything we do, the ability to control and protect data is extremely important and our web apps are no exception. After this weeks lesson, we are now able to incorporate this measure of security into the programs we build and there is no doubt in my mind that this skill will be considered valuable in future personal, and professional, applications.

Textbook Mania

Last weekend, we were assigned our most involved and complex assignment to date, Textbook Mania. The purpose of this application is to serve as a place ICS students can go to either buy or sell textbooks directly to or from other students. For a complete description of the assignment, click here.

The assignment was released on Friday, November 1st, at approximately 5:45pm and was due by 8pm on Sunday. We were assigned a partner with whom to collaborate. My partner was Evan Komiyama.

I anticipated having a very busy weekend, therefore, my goal was to get as much of the assignment done on Friday night as possible. I began working as soon as the assignment was released. I took approximately 30 minutes to read through the assignment, map out each component (listing required fields, validation requirements, etc) and diagram how I thought all the components interacted with each other. I also started a Google Hangout with my partner hoping his intention was also to start work on the project immediately. He wasn’t available, so I decided to just start building the basic pieces of the application, the Student and Textbook models, since the Buy and Sell Offers were dependent on these objects.

I didn’t think it was very difficult to implement the Student model or the Student database and associated CRUD functions since this object was very similar to models we’ve implemented in our Surferpedia and Digits applications. It took approximately 2 hours to build these objects and their associated forms.

After committing these changes to the repo on Github, I began working on the Textbook models. Shortly thereafter, Evan logged in to Google hangout. I directed him to the repo and explained what had already been built. We discussed the assignment and how we thought it should be executed and decided that I would continue to work on the Textbook model and he would implement the Buy and Sell Offer objects as well as the match page.

It took a little longer to complete the Textbook model than the Student model because of the added requirement of retrieving the textbook cover art from Amazon based off of the ISBN number. Initially, I didn’t realize that only the 10 digit form of the ISBN retrieves the image but after discovering this to be the case, I included a rule in the validation module to ensure users can only enter the 10 digit form.

By mid-day Saturday, Evan had committed fully functional Buy and Sell offer models and later that evening completed the match page. With the majority of the project complete, we shifted our attention to improving the look and feel of the site, writing the help page and README file, as well as cleaning up some checkstyle errors in the code. By Sunday afternoon, we were both satisfied with the site and deployed it to Couldbees, which can be viewed here!

Our Textbook Mania application.

Although there were a lot of parts to this application, I didn’t think writing the code to implement the functionality was difficult since we’ve done similar work in previous assignments. I think what made this project difficult was that there was a lot of code to be written in what felt like very little time. Luckily, Evan was a great partner to work with. He met the deadlines we set for our group which left us with plenty of time to go back and review our work prior to submitting. He was open to my suggestions and also offered help when I needed it and together, I think, we created a pretty cool site!