Final Project Mockup: Notify Hawai’i

When I registered for this class at the beginning of the semester, I expected two things: 1) that this course would require a lot of hard work and 2) that we would most likely be building a fully functional web application by the end of the semester. At the time, I had no idea what I was going to build for the final project but I did know that whatever it was, I wanted it to be useful.

For the last several months, this project was placed on the “back-burner” in my mind and every-so-often I would think of potential web applications to pursue. I eventually landed on an idea that I thought was not only cool but useful and doable too.

Notify Hawai’i

Notify Hawaii Homepage

I’ve decided to implement a notification system for services based in Hawaii. Here is a brief description of how I envision the application will work:

Users will be required to create accounts and provide their email and/or phone number. They will then be able to set up specific triggers that will send them notifications by email or text message. These are a few sample triggers that will be built into the application:

• At a specified time, send me an email with the title and links to the current Honolulu Star Advertiser breaking news articles
• At another specified time, text me if my commute home is going to take more than 30 minutes
• Send me a text messages if my bus is running early/late
• Send me an email if a new Craigslist post matches some parameters (e.g. Apartment for rent, in Manoa, dog friendly, less than $x, etc)
• Email me if a new blog post is added to a specified WordPress site

For some of these tasks, I’ll rely on 3rd party APIs (Google Maps to estimate commute time, TheBus Web Services API to assess bus schedules) and utilize the Jaunt Web Scraper and Automation tool for the others.

Available Services

I am working on this application alone. While I am disappointed that I will not have the opportunity to work with and learn from another student, I do look forward to having full control over the implementation of the application. However, there is a lot of work to be done and I am concerned that I may not be able to accomplish everything that I wish to achieve.

Looking back at my experience building the mockup application (which can be found here), I’ve come to realize that I had no clear direction while working on the app. In my mind, I had an idea of what I wanted the user interface to look like but nothing was concrete until the code had been written. Going forward, I think I would greatly benefit by having a clear and defined set of goals to guide my progress through each milestone. Fortunately, Github already has an Issue tracking tool for this purpose.

This is just the tip of the iceberg and there is still a lot of work to be done on this project. But I believe that this application, if implemented correctly, can be amazingly cool and useful for all users.

Application Design: MVC and Play

Model view controller (or MVC) is a popular and useful software design pattern aimed to help developers separate the internal representation of data from its presentation. In a typical application there are three fundamental components:

1. the Model which is the internal representation of the data
2. the View which is the interface in which users interact with the data and
3. the Controller which are the actions that can be performed on the data model

This week, we focused our attention on applying this design pattern to application created using the Play Framework.

E41: Digits Mockup Results
The goal of the first WOD was simple, create a non-functional mockup of the contacts database web application we call Digits. Since there was no functionality to implement, this WOD exercised our skills using Twitter Bootstrap more than any other technology we’ve used this semester. There are only two pages to the Digits application; a home page that displays a table of current contacts and a ‘New Contact’ page that displays a form used to add new contacts to the database. Since I don’t have the Bootstrap table and form tags memorized, I had to refer to the documentation. In a previous exercise, I bookmarked all of the main sections of the bootstrap reference material which allowed me to quickly find and access the tags I needed to complete this WOD. I attempted this WOD twice with the following results:

• 1st attempt: 24:51 Av
• 2nd attempt: 16:52 Rx

E42: Digits Form Results
In the second WOD we enhanced our Digits app by adding partial functionality to the new contacts form. Now when the Add button is clicked, the contents of the form are printed to the console. Prior to attempting this WOD, we were instructed to watch a screencast previewing the process of adding functional forms to a Play application. While watching the screencast, I took detailed notes on the structure and syntax of the additions so that I could refer to it while working on the WOD. This preparation allowed me to complete both of my attempts at this WOD in Rx time:

• 1st attempt: 16:15 Rx
• 2nd attempt: 11:21 Rx

E43: Digits Form Validation Results
In the third WOD, we extended the functionality of our web app even further by adding data validation capabilities to the new contact form. With data validation, we are able to ensure that the user doesn’t leave required fields blank or that submitted responses follow a specified format. Play makes the process of validating user input surprisingly easy – simply implement the validate method to identify validation errors and annotate the form controls with the appropriate html/bootstrap tags when errors exist. During my first attempt at this WOD, I mistakenly imported the wrong ValidationError package and spent a few minutes troubleshooting the errors this caused. However, I was still able to complete all attempts at this WOD in Rx time:

• 1st attempt: 15:52 Rx
• 2nd attempt: 8:34 Rx

E44: Digits Model Results
The goal of the fourth WOD was to implement an in-memory repository for storing contacts entered by the user and allow the application to dynamically display all the contacts in the database. Implementing the in-memory repo was fairly straightforward as was revising the scala.html files to dynamically generate content, however, I still DNF’d on my first attempt at this WOD. Although I was able to add and retrieve contacts from the repository, I was unable to get the Application test to pass successfully. Only after spending a significant amount of time scouring my code for the bug (and being unsuccessful at finding it) did I think to do a clean compile of the code and re-execute the test. To my surprise (and disappointment that I didn’t think to try this earlier), the test passed. I repeated the WOD twice after this initial attempt and achieved Rx time on both attempts.

• 1st attempt: 32:31 DNF
• 2nd attempt: 12:28 Rx
• 3rd attempt: 12:57 Rx

E45: Digits CRUD Results
The fifth and final WOD took the digits app one step further and provided the user with update capabilities. There are a lot of steps associated with implementing this function, fortunately Dr. Johnson outlined these steps in a screencast we were instructed to watch before tackling the WOD. Although I took notes and referred to these notes while performing the exercise, I still DNF’d on my first attempt due to an error in the way I assigned ids to contacts in the repository. After realizing my mistake, I repeated the WOD twice and achieved Av and Rx time.

• 1st attempt: 42:58 DNF
• 2nd attempt: 22:23 Av
• 3rd attempt: 11:29 Rx

Conclusion
There are many benefits to using and abiding by the MVC design patterns including simplified application development and robust code. However, like many of the technologies we’ve used this semester, the learning curve is steep. But if I learned anything from this series of WODs it’s that by practicing and incrementally adding complexity to practice exercises, even tasks that initially seem complex can become simple.

Web Application Frameworks

This week we began working with the Play web application framework. Frameworks aim to alleviate overhead associated with web application development by providing libraries for common tasks such as database access and user authorization and authentication. Since the developer no longer has to build these functions from scratch, he can focus on implementing the things that really make the app stand out.

But we must learn to walk before we can run and our WODs reflected this.

The first WOD was a simple exercise that had us create a new Play project from scratch, import it into IntelliJ and ensure that it passed all QA tests (i.e. checkstyle, application and integration tests). We were given very clear instructions on how to accomplish these tasks and because of this, I was able to complete my first and only attempt at this WOD in Rx time of 9 minutes and 54 seconds.

The second WOD was a little more interesting than the first. Using this Play Framework template provided by Dr. Johnson, we were instructed to recreate our ‘A history of browsers’ webpage from a previous WOD. Since the HTML and CSS code was already written, we could focus on the simple, yet crucial, details of the framework (like removing views, routes and controllers) and getting a general sense of how to structure apps in this environment. Since I’ve used the Play framework in the past, this WOD was a review of material I already knew therefore, I was able to finish my first attempt in less than 14 minutes qualifying as Rx time. I repeated the WOD twice after watching Dr. Johnson’s solution and completed my second attempt in 7:50 and my third in 9:02.

The third WOD was like the second in that we recreated a project from a prior WOD, however, this exercise was more difficult since it consisted of multiple pages. For a beginner, adding pages to a Play application is a non-trivial task.  Each new page requires its own view file in the Views directory, action method in the Application.java controller file and a defined mapping in the routes file. Initially, it can be difficult to remember how all of these parts fit together in the entire framework but with practice, it becomes routine. Again, since I’ve worked with Play in the past, these exercises were more of a review and I was able to complete my first attempt in 13:03 and my second in 13:55, both qualifying as Rx time.

Like the two WODs before it, the fourth and final WOD was a revisit of a previous project in which we were to recreate the Kamanu Composites website in the Play framework environment. This was a fairly easy WOD to complete since the HTML and CSS code could be copied out of the previous project and because it didn’t require adding new views or modifying routes. I finished my first attempt in Rx time of 11 minutes and 40 seconds and my second attempt in 10 minutes, 31 seconds.

Although the learning curve is steep, using web application frameworks can provide huge benefits. By promoting code reuse, frameworks boost developer efficiency and productivity. By enforcing structure, projects become clearer and more organized. These are just a few of the many reasons learning to use a web application framework is well worth the time and the effort.

UI Frameworks: Twitter Bootstrap

This week we continued our study of basic UI design with the exploration of Twitter Bootstrap, a front-end framework used to create websites and webapps that dynamically formats content based on the size of the display on which it is being viewed. This versatility allows programmers to implement and maintain a single UI codebase for all users on all platforms (i.e. mobile phones, tables, laptops, desktops, etc). Although mobile phones and tables offer less screen real estate and processing power than laptops and desktops, it is still important to serve up the best looking, most functional page possible despite these restrictions. A common approach (known as the mobile-first approach) is to design for these mobile devices first then scale up for larger displays. This week our WODs focused on redesigning three websites using Twitter Bootstrap and the mobile-first approach.

In the first WOD we were required to revise our “A history of browsers” webpage using Twitter Bootstrap to create a modern, responsive layout. The format of the goal page was relatively simple; a single block at the top of the page containing the introduction paragraph and below that three separate columns, one for each of the three browsers. Despite the simplicity of this exercise, I DNF’d on my first attempt after having spent more than 40 minutes trying to get the formatting just right. At first, the first two columns appeared on the same row and the third overflowed onto the next row. After I managed to get them all on the same row, the spacing between columns was too narrow and columns appeared pushed up next to each other. After watching Dr. Johnson’s solution, I realized my error and immediately repeated the WOD. I completed my second attempt in Rx time of 8 minutes and 3 seconds and my third in 8 minutes and 6 seconds.

The second WOD had us recreate the Kamanu Composites website, again using Twitter Bootstrap to provide a responsive design. Like the previous WOD, the format of this page was relatively simple; a navigation bar across the top, under that an image spanning the width of the screen and finally a simple footer with the tagline “We build canoes.” Having used Twitter Bootstrap before, I was confident that I would be able to complete this WOD in Rx time however, my initial attempt took slightly over 1 hour to complete. I struggled to correctly position the logo in the nav-bar and found it difficult to prevent the links from collapsing into two rows when resizing the browser. Throughout the solution screencast, Dr. Johnson frequently used Chrome’s developer tools to inspect elements of the page and guide his implementation. During my second and third attempts at this WOD, I relied more heavily on these tools to guide my design and completed both in Rx time of 18:37 and 16:50, respectively.

In the final WOD we gave the Castle High School homepage a modern, mobile-first, make-over. The requirements of this WOD were similar to that of those that came before it so I was actually able to complete my first attempt in Sd time of 41 minutes and 12 seconds. Since I cannot pinpoint any one task that consumed the majority of this time, I attribute it to the fact that I hadn’t yet achieved fluency and so my implementation decisions and actions were slow and inefficient. But like everything else, practice makes perfect and I was able to improve my time by 21 minutes during my second attempt (achieving Rx time of 20:30) and by 23 minutes during my third (again achieving Rx time of 18:36).

With approximately 60% of American adults owning a smartphone, the mobile-first approach to design is more crucial now than ever before. There is no doubt in my mind that the skills we’re learning now will be useful in the future.