A22: Cloud Deployment

Although this week was a pretty easy WOD week for ICS314 students, we learned some pretty important skills. We focused on deploying our Play applications to the cloud and making it available to anyone with an internet connection. We also learned how to incorporate the Twitter Bootstrap modal dialog component into our apps.

Complete descriptions of this weeks WODS are found at the ICS314 website, here.

WOD 1: DeploySurferpedia

Goal: Deploy the Surferpedia application to the cloud using CloudBees.

As instructed, prior to attempting this WOD, I watched Dr. Johnson’s screencast on deploying a Play application to Cloudbees. In his screencast, Dr. Johnson experienced an issue where initially, it looked as if his application had been successfully deployed but after a few minutes, the default “Hello World” application came back. During my attempt at this WOD, I experienced the same issue. I quickly re-deployed my application, just as Dr. Johnson did in the video, and this time it “stuck”. Although deploying the app didn’t work the first time around, because Dr. Johnson experienced an identical issue and resolved it in the screencast, I was able to complete this WOD in Rx time of 4 minutes, 28 seconds.

View my surferpedia app on Cloudbees here.

WOD 2: CustomDomainName

Goal: Buy a domain name and set it up to point to your running Surferpedia application on CloudBees.

Like the previous WOD, I watched Dr. Johnson screencast prior to attempting this WOD. The domain name I purchased is “surferpedia.co.uk.” Only after making the purchase did I realize that I should have purchased a name that I would be able to repurpose later. Either way, learning how to accomplish this task was worth the $7 spent. I didn’t experience any issues during my attempt to complete this exercise and was able to finish in Av time of 9 minutes and 15 seconds.

View my surferpedia app at my www.surferpedia.co.uk

WOD 3: ModalDialog

Confirm a users intent by adding a Twitter Bootstrap modal dialog triggered by a request to delete a surfer.

Before attempting this WOD, I studied the Twitter Bootstrap documentation on the modal dialog component and implemented this functionality in a branch of my contacts database. The Twitter Bootstrap documentation was straightforward and easy to understand; they also provide the code required to implement this feature so building this into my app wasn’t very difficult.

My first attempt at adding this functionality to my surferpedia app went well and I was able to complete the exercise in Rx time of 7 minutes, 43 seconds.

View my Starting Commit for Attempt 1 on Github here.
View my Ending Commit for Attempt 1 on Github here.

My second attempt at this WOD also went well, however, I took a little long this time around but still completed in Rx time of 8 minutes, 14 seconds.

View my Starting Commit for Attempt 1 on Github here.
View my Ending Commit for Attempt 1 on Github here.

Since the beginning of the semester, we’ve been learning how to build web applications. This week, we finally learned how to deploy these apps to the cloud and make them available to the world. For the first time in my college career, my programming work is no longer limited to the just the person grading it and thats pretty exciting!

A20: Dynamic Surferpedia

Overview

Goal: To consolidate all of the insights you have gained so far into dynamic web application development by converting your “static” Surferpedia web application into a dynamic one.

For a complete description of the project requirements, please see the assignment page here.

Collaboration

I collaborated with Jonathan Ortal on this project. We met on Google Hangouts twice for approximately 1.5 hours each time. I found it very helpful to be able to run my ideas past him and discuss my approach to solving the problems presented in this assignment.

Concerning the implementation of this application, we both agreed that although we used a long to represent the id value in the Digits application, the surfers slug value could be used for this purpose instead. We also discussed ideas on how to disable the slug field for an existing surfer in the database.

Implementation

Although I didn’t time myself, I would estimate that it took approximately 10 hours to complete this exercise. Since Dr. Johnson provided hints about the structure of his application and because our Digits database implemented similar functionality, I was able to build the 4 view files and implement all of the functional requirements (Create, Read, Update, and Delete) with relatively few issues and within 5 hours. I was actually surprised at how easy it was to dynamically build and populate the carousel and navbar using the scala for-loop described by Dr. Johnson in his Scala Template Tips page. The rest of the time was spent debugging the application and tinkering with the Scala syntax.

The most difficult problem I encountered was trying to devise a way to check for duplicate slugs in the database when creating a new surfer but not when editing an existing one (since the slug for an existing surfer will already be in the database). In our Digits application, new contacts were denoted with an id value of 0, however, since I was no longer using an id field, I had to come up with a different solution. I resolved this issue by adding a “status” field to my surfer class. The status of a surfer is set to “new” when instantiating a new surfer object and is set to “existing” when the surfer is added to the database. The database is checked for duplicate slugs only when a surfers status is “new”. This status field also aided in appropriately configuring the slug field which is set to “readonly” when a surfers status is “existing”.

Reflection

Although this application was challenging and time consuming, I enjoyed building it. I definitely have a better understanding of the structure of Play applications and how all the different parts interact with each other. I also enjoyed collaborating with Jonathan as his input helped me to create a better application.

Download my Surferpedia webapp here.

A19: Dynamic WebApps Part 2

This week, we continued development of our Contacts Database. We introduced scala templates into our projects, making it easier to incorporate fields like pull-down menus and radio buttons in our forms. Along with providing this functionality, templates also allow us to write cleaner, more efficient code.

More information on these templates and the complete description of this weeks WODs can be found on the ICS314 website, here.

WOD 1: DigitsTextTemplate

Goal: Refactor the Digits form template using the scala templates in play-example-form provided by Dr. Johnson.

Prior to beginning this WOD, I watched Dr. Johnson’s screencast on using scala templates to generate form controls using Twitter Bootstrap. I also downloaded and studied his example template to familiarize myself with the code and how it was being used. This preparation paid off as I was able to complete this WOD in Av time of 10 minutes, 51 seconds on my first, and only, attempt.

View my solution to this WOD here.

WOD 2: DigitsSelection

Goal: Add a “Telephone Type” pull-down menu to the New Contact form. Apply appropriate validation rules and display the telephone type in the list of contacts.

I would describe this WOD as complex, but not necessarily difficult; complex because there are a number of steps involved in implementing this functionality but because Dr. Johnson provides step-by-step instructions on how to accomplish this in the description of the exercise, it was actually pretty easy.

During my first attempt, I made the mistake of referring to the select box form field by the wrong name, as a result, the selected value was not being saved to the database. I spent nearly 45 minutes looking for this bug resulting in a DNF time of 1 hour and 38 minutes. I also experienced an import conflict since both the helper and bootstrap3 packages contain a select.scala.html file. To resolve this error, I renamed the Bootstrap3 file to selectBox.scala.html. It wasn’t until after watching Dr. Johnson’s solution that I learned that the better way to resolve this conflict is by explicitly calling the bootstrap3.select file. I immediately repeated this WOD and achieved Av time of 32 minutes, 14 seconds.

View my solution to this WOD here.

WOD 3: DigitsTelephone

Goal: Create a new Scala template specific to this application. This template should include both telephone and telephone type fields.

This was a relatively easy WOD to complete and I was able to achieve Av time of 25 minutes, 8 seconds on my first attempt. After watching Dr. Johnson solution, I repeated the exercise and finished in Rx time of 9 minutes, 34 seconds. One issue I noticed with the implementation of this template is that the “has-error” attribute may not be applied appropriately. For example, if a valid telephone number is entered along with an invalid telephone type, the telephone type form field isn’t highlighted in red upon submitting the form. This results from the fact that both form fields are a part of the same form-group div which is tagged with the “has-error” attribute only when telField.hasErrors evaluates to true; telTypeField.hasErrors is not evaluated. I was not able to apply the proper error format to the control without altering the layout.

Telephone type pull-down menu invalid entry formatting error.

View my solution to this WOD here.

WOD 4: DigitsInit

Goal: Initialize the database of contacts by using the onStart method of the Global class.

This WOD was also pretty easy to complete, although, I must admit that on my first attempt, I didn’t achieve the goal in the way directed in the instructions. I referred to the play-example-form template where the database is initialized with students by calling a static method in the Student.java class. I initialized the database with a static method in the ContactDB.java class. I completed this WOD in AV time of 9 minutes, 28 seconds.

I repeated this WOD after watching Dr. Johnson’s solution and realizing that I had initially implemented it incorrectly. This second time around, I created a Global class and invoked the onStart method to populate the database. I completed this exercise in Rx time of 6 minutes and 36 seconds.

View my solution to this WOD here.

Although these scala templates just add one more piece of code to an already complicated system, we’ve seen in these exercises that they are very useful. Using templates isn’t difficult and it simplifies the construction of forms and reduces redundant code.

A18: Dynamic WebApps

This was an exciting WOD week for ICS314 as this was our first attempt at creating Play web apps that are capable of interacting with users. We started with a simple, static mock up of a contacts database then incrementally added functionality until we eventually had an interactive application. Complete WOD details can be found at the ICS314 website here.

WOD 1: DigitsMockup

Goal: Create a mock-up “digits” Play application with the two following pages:
– A homepage that displays a static list of contact information
– A “New Contact” page which presents a non-functional form for entering new contact data.

I found this WOD relatively easy to complete since its primary focus was on format instead of function. In the past, we’ve created pages with similarly formatted headers and nav-bars so I was able to create these quickly. I did, however, spend a great amount of time reading through the Twitter Bootstrap documentation for the appropriate use and syntax of table and form classes as we haven’t yet incorporated these components into previous projects. After 37.5 minutes (Sd time), I was satisfied with the resulting application.

I repeated this WOD a day later, after having completed the following WODs, and finished in Rx time of 14 minutes, 27 seconds.

WOD 2: DigitsForm

Goal: Enable functionality of the digits form. Users enter first name, last name and telephone number into the form and upon clicking the Add button, will see their data printed to the Play console.

Although the Play for Java book discusses the topic of capturing and processing user input, I found their approach confusing and convoluted. Luckily, in one of his screencasts, Dr. Johnson presents a clearer alternative to accomplishing this task. Since the solution involves modifying and added several new files to the application, I was careful to take detailed notes as he stepped through the process. With these notes, I was able to finish this WOD in Av time of 24 minutes, 40 seconds.

I attempted this WOD a second time the following day and achieved Rx time of 16 minutes, 54 seconds.

WOD 3: DigitsFormValidation

Goal: Incorporate simple data validation into the digits form.

Like the previous topic, data validation is discussed in the Play for Java ebook and I was just as confused by their approach to this topic as the last. Where the authors approach involved applying attributes to variables and importing constraints, Dr. Johnson presented a way of validating data using java methods and a little bit of scala code to appropriately label/format Twitter Bootstrap components. Since the majority of the code written in this WOD was not very complicated java code, I was able to complete my first attempt in Rx time of 17 minutes, 21 seconds and my second attempt, also in Rx time of 13 minutes, 7 seconds.

WOD 4: DigitsModel

Goal: Provide dynamic output and a model for the Digits form data.

In my opinion, this was this week’s most challenging WOD. Implementing the dynamic output function was fairly easy as all it required was simply looping through a list of contacts, however, getting to the point where I had a list of contacts to pass to the output function was difficult. In order to achieve this, several new components needed to be built, including a Contact model and a Contact database, then these new components needed to be “wired up” to interact with existing modules and methods. At the time of my first attempt, I did not have a very good understanding of the purpose and function of each of these components, making building this application difficult. I spent a lot of time referring to my notes, the screencasts, and the Play for Java ebook and DNF’d on my first attempt with a time of 38 minutes, 46 seconds.

I repeated this WOD a day later, after studying the material, and although the concepts were still a little murky, finished in Av time of 20 minutes, 3 seconds.

WOD 5: DigitsCRUD

Goal: Modify the digits application to support CRUD, Create, Read, Update and Delete (excluding Delete).

In the previous WOD, I already had an application capable of creating and reading contacts so all I needed to implement in this WOD was a method to retrieve and edit a specified contact. In order to do this, I needed to assign each contact an unique id, change the implementation of my ContactDB to be able to associate this id with the appropriate contact and update the application controller to either display a new contact or an existing contact based on the id, among other things. I didn’t think accomplishing this task was too difficult and completed my first attempt in Sd time of 41 minutes and 27 seconds. I achieved Rx time of 25 minutes, 32 seconds on my second attempt a day later.

Throughout the course of this semester, I’ve come to understand that the most effective ways to learn the material is by repeatedly doing these WODs. This week, we learned how github, along with all the other functionality and convenience it already provides, can help us with this too. By setting up an initial program “stub” then creating branches off of it, we are able to efficiently repeat WODs with minimal effort. As the semester progresses, I can see this becoming an invaluable tool.

A17: Git and Github

This week, we focused our attention on tools and services developers often use when participating in group development. Tools like Git provide an effective way to implement a version control system while services like Google Hangouts and Github make communicating and collaborating easier than ever.

The following practice WODs had us using Git and Github to become familiar with could-based project hosting and version control while creating a pretty cool Play application. Complete descriptions of the WODs can be found on the ICS314 website here.

GitHub-1: GitHubPlayResponsiveKamanu

Goal: Publish our PlayResponsiveKamanu application to Github and configure the Readme file to include a screenshot of the app and the following sections: Overview, Installation, Usage, Credits. Also, set up an end-user home page using GitHub Pages.

Before attempting this WOD, I studied the material on git and github provided by Dr. Johnson and also completed the “Try Git” interactive tutorial by Code School. While this tutorial was helpful in learning the functions of Git, like pushing and pulling repositories and committing changes, etc, it wasn’t directly applicable to this WOD since it was designed to emulate executing commands from the command line and not from the desktop app.

Since I’m new to the application, I spent the first several minutes of my first attempt at this WOD familiarizing myself with the application interface. Before long, I had successfully cloned the online repo to my computer and added my PlayResponsiveKamanu files to the git directory. Importing the project into Eclipse and editing the README.md file went well and I didn’t experience any problems while doing so. Before I attempted to commit my changes, I noticed that over 300 files were listed as those that were going be committed including numerous .class, .cache and .xml files. I realized that I did not properly configure my .gitignore file and spent a few minutes correcting this. After my changes were committed, setting up the end-user home page was done with just a few clicks of the mouse. In all, I was able to complete this WOD in Sd time of 23 minutes and 6 seconds.

Over the next few days, I continued using the Github application becoming more familiar with the interface and decided to retry this WOD. The second time around I was able to complete it in Rx time of 10.5 minutes.

Interlude: Play-DropDown-carousel

Before continuing on to the second WOD, we were instructed to create a program that focused only on implementing two Twitter Bootstrap components that we have not yet used, a drop down menu and a carousel. These programs, whose purpose is to explore potential solutions to a focused problem, are known as “spike solutions”.

As a newbie to Bootstrap, I found the documentation confusing. I spent close to an hour attempting to implement a drop-down menu and although I ended up with something that resembled a drop-down menu, it wasn’t quite right. Luckily, the carousel wasn’t as difficult to implement. After watching Dr. Johnson build his “spike solution”, I realized that my implementation of the drop-down menu was incorrect. After making a few adjustment to my code, I had a working project that could be used as a template for the next WOD.

Initial implementation of the Twitter Bootstrap drop-down menu.

GitHub-2: Surferpedia

Goal: Using the Play-DropDown-carousel template, create a Multipage Play application and publish it to Github.

Upon reading the requirements for this WOD, I have to admit that I felt a little overwhelmed with the task. There are a lot of parts to this WOD, in fact, I’m quite sure that there are more parts to this WOD than any other we’ve done so far. However, once I started to build the application, I realized that everything we were doing to create this app had been done before; this WOD was a culmination of the concepts from all previous WODs and the Play-DropDown-carousel interlude we just completed. I was able to finish my first attempt at this WOD without experiencing any major issues in Av time of 44 minutes and 12 seconds. A few days later, I repeated this WOD and achieved Rx time of 25 minutes, 11 seconds.

A large part of this weeks WODs was dedicated to learning how to use Git and Github and whether you’re working from their webpage, using the desktop app, or running commands from the terminal, manipulating your files (pushing, pulling, forking, committing, etc) is extremely easy to do. Combining that user friendliness with the important services they also provide, and its easy to see why both are essential when working in group development environments.

A16: Surferpedia Sunday

The goal of this exercise was to connect with a classmate via Google Hangout and work together to add a new surfer to each others surferpedia project on Github. A complete description of the exercise can be found on the ICS314 website here.

Edgar Lau, my WOD partner, and I agreed to meet at 7pm. Connecting on Google Hangout is fairly simple as all it requires is your partners email address. Once connected, there are a plethora of features available to those participating in the hangout. Edgar and I chose to use the audio and chat features while working on this WOD, which results in the rather boring party window below…

Google Hangout Window – Audio and Chat

At first, Edgar wasn’t able to sync his local and online repositories. We considered using the screen sharing feature so I could help him to identify the problem, but since we are on different platforms, we decided that it probably wouldn’t have done much good. After a while, he managed to successfully sync his repositories and grant me access to his project.

I didn’t have any problems cloning Edgar’s project from the Github website to a local repository and after running the ‘clean’ and ‘eclipse’ commands from the terminal, I was able to import the project into Eclipse without issue.

Edgar’s code was clean, well structured and easy to modify so adding a new surfer wasn’t very difficult at all. The entire process took less than 10 minutes to complete. Then, with just a few clicks of my mouse from the desktop Github app, I committed my changes to Edgar’s Github repository. Before ending our meeting, we both verified that a new surfer had successfully been added to our projects.

This experience has taught me that without tools like Git and services like Github and Google Hangouts, synchronous collaboration would be extremely difficult to coordinate and accomplish. And because these tools make it so easy for people to connect and communicate in real time, even if miles apart, this method of collaboration is far more convenient and effective than same time, same place collaboration.

A15: Getting Started with Github

Overview

When several people are collaborating on a project, whether it be a simple document, manuscript, or software program, it is important that changes are coordinated and tracked so edits made by one person are not overwritten or lost when someone else makes a change. The managing of changes is known as version control. At the Blood Bank of Hawaii, Standard Operating Procedures (SOPs) are documents that change all the time. Currently, the Quality Department coordinates changes to SOPs in revision by multiple departments, basically serving as a manual method of version control.

When developing software, either alone or as a group, version control is essential. Git is way to implement version control in these situations.

Experience

Installing and configuring git on my computer was painless. Upon opening the application, a wizard walked me thorough the steps of connecting to my Github account. There are also great tutorials on the github website that explain how to create and fork repositories. These were done in the terminal but I’m sure theres a way to do it from within the Github application.

Nothing about the set up was difficult, although at first I was confused about where my local repositories were being saved and whether I could change the default location. However, after a few minutes of exploring, I was a able to configure the application to my liking.

My experience managing SOPs at the Blood Bank has taught me that version control can be cumbersome, but is very important. By providing a method of version control, Github provides a great service and I’m sure it will soon become an invaluable tool.

A14: Playing With Play

This week was our first introduction to Play, an open source web application framework. At first, Play seems like a very complicated piece of software to use. In his demo, Dr. Johnson had Play running in the terminal, was editing code in Eclipse and using Chrome to debug and view results. To be honest, it was intimidating. Luckily, there are a lot of resources available. The Play website provides installation instructions as well as sample applications to tinker with. The ebook “Play for Java” is also a great resource with lots of useful information and actually has you creating a sample database app within the first 3 chapters.

All WODS, as well as Dr. Johnson’s lectures on Play can be found at the ICS SE course website here.

WOD 1: Play-1: HelloMe

Goal: Create a new Play application then edit the files in Eclipse so the page generated by the app displays “Hello, Me!” in both the body and title of the page.

Before attempting this WOD, I read the first three chapters of the “Play for Java” ebook and perused the material and example applications on the Play website, so I felt confident that I would be able to complete this WOD in Rx or Av time. Within two minutes, I had successfully created the project and modified the files to display “Hello, Me!” in the body of the page but the title still read, “Welcome to Play 2.1”. After 10 minutes of tinkering, I finally found the appropriate line of code to edit in order to change the title of the page. In all, I took 12 minutes and 47 seconds to complete this WOD earning a DNF score.

Now knowing exactly what to modify to obtain the desired results, I immediately repeated this WOD and completed it in Rx time of 1 minute, 37 seconds.

WOD 2: Play-2: CleanHelloMe

Goal: Create a new Play application and open the project in Eclipse; enable Checkstyle and fix all errors. Then edit the application to generate a page containing only the words, “Hello, Me! I’m super clean!”

This WOD was very similar to the first, so editing the code to generate a page that read, “Hello, Me! I’m super clean!” took very little time. During my first attempt, however, I spent approximately 5 minutes looking for, and correcting, checkstyle errors. Most were simple formatting errors like missing line breaks at the end of files or trailing spaces after text. Others, like printing too many characters on a single line, prompted me to refer back to my resources to see what the recommended guidelines are. I completed my first attempt in SD time of 7 minutes, 8 seconds. Knowing that most of that time was spent researching errors, I decided to immediately repeat this WOD and completed it in Rx time of 1 minute, 55 seconds.

WOD 3: Play-3: PlayBootstrapBrowserHistory

Goal: Using the play-bootstrap-template provided by Dr. Johnson, recreate the BootstrapBrowserHistory page from assignment A13.

This was a relatively easy WOD to complete as most of the code was copied out of the BrowserHistory index page created in Assignment A13 and required little modification to display correctly. I stumbled a little with the formatting of the introduction paragraph but that was quickly resolved and I managed to complete this WOD in Rx time of 6 minutes, 48 seconds on my first attempt.

WOD 4: Play-4: MultiPagePlayBootstrapBrowserHistory

Goal: Using the play-bootstrap-template, create a new BootstrapBrowserHistory webpage where the history of each browser is located on its own page.

Like the previous WOD, most of the code used in this exercise had already been written in Assignment A13. Unlike the previous WOD, this exercise was not so easy as it was the first to require multiple pages. Adding a page to a project isn’t particularly difficult but to a beginner, it can be quite confusing since it is a multiple step procedure that is not very intuitive. Luckily, in one of his screencasts, Dr. Johnson describes the process of creating new pages in a Play application. In preparation of this WOD, I added several new pages to the play-bootstrap-template and because of that, was able to complete this WOD in Rx time of 16 minutes, 41 seconds on my first attempt.

WOD 5: Play-5: PlayResponsiveKamanu

Goal: Using the play-bootstrap-template, recreate the ResponsiveKamanu page from assignment A13.

Like WOD 3, PlayBootstrapBrowserHistory, I found this exercise relatively easy to complete. There were no additional pages to add and most of the code written to implement the bootstrap version of the Kamanu website could be reused in this project with very little editing. The one part of this exercise that could have caused a trip-up was deciding when to reference images using the “../images” versus the “@routes” notation but Dr. Johnson’s explanations were clear and it wasn’t really a problem. My first, and only, attempt at this WOD was completed in AV time of 12 minutes, 58 seconds.

While initially I thought Play was going to be difficult to learn and use, after having read the material and completed these exercises, it no longer seems so elusive. I’m excited to learn more and do more because it seems like a very powerful tool that can be used to create great pages.