The Semester in Review

Reflecting upon this semester, I can confidently say that I’ve learned more in this class than in most others. Five months ago, I had no experience in web development. Today, I can build a decent web application in just a few days.

We’ve come a long way since the first Internet Browser History project. Using HTML5 and CSS3, this project had us create a single, static webpage displaying the logo and a brief history of three common web browsers. The page was simple but the exercise was effective in illustrating just how easily web content could be created using these technologies.

One of our first projects: Browser History

As the semester progressed, this project evolved. The next iteration involved using Twitter Bootstrap, a collection of formatting tools. With Twitter Bootstrap, incorporating visually interesting components like wells, and image carousels required just a few lines of code. Twitter Bootstrap also supports responsive design, an increasingly critical utility in today’s web environment. With responsive design, the layout of a page is automatically adjusted to fit the size of the display it is being viewed on. This feature became an integral part of every subsequent project.

Digits: A database of contacts

The last major piece of technology we studied was Play, a web application framework. With Play, we were able to call Java methods to serve dynamically generated content to users. We built several applications on this framework including a database of contacts and a database of surfers. Initially, these databases were stored as an in-memory repository which only lasted as long as the application was running. We later learned how to implement a persistent database backend in MySQL. For all of the advantages these technologies offer, there are some disadvantages. For example, the Play framework requires some programming in Scala which can be a challenge if you don’t have that background. Also, it is difficult to find documentation on Play and the text we used, Play for Java by Leroux, was still in draft form which made it difficult to read.

As with anything new, there is a learning curve and these technologies are no exception. The only way to learn it is to practice. Fortunately, there was a lot of practice to be had in this class in the form of WODS – high intensity, short duration exercises. With each new concept, there was surely a WOD to follow.

Typical WOD format

There were essentially two different kinds of WODs, at home WODs and in class WODs and while identical in format, emphasized two completely different, but equally important, aspects of software engineering. Homework WODs were often quite challenging and while timed, the emphasis was on learning the material and gaining technical fluency. Often times, the homework WODs were preceded with instructions to peruse the supplied resources. Solutions were also provided which helped to either confirm that our method of solving the problem was correct or lead us in the right direction if we were going astray. We were encouraged, and sometimes instructed, to repeat the WOD multiple times. With each attempt, we became more efficient and effective at using the technology.

By completing the homework WODs, we were preparing for the in class WODs. Although the tasks assigned as in class WODs were typically easier than those assigned as homework, the in class WODs were significantly more stressful because of the time constraints. Homework WODs were also timed but we were always able to repeat a WOD for a better time if we chose to do so. This was not the case with in class WODs; we had one shot to do well and that put a lot of pressure on us to perform.

Programming under pressure isn’t something that has ever been addressed in previous classes so at the beginning of this semester, these challenges always triggered feelings of worry and anxiety, regardless of how well I had prepared. And at first, it was difficult to not be flustered by the requirements or distracted by the timer. I also struggled with allocating enough time to test my programs after they were built. But as the semester progressed, I got better at being able to focus on the task at hand in these high stress situations. These in class WODs definitely helped me to become more comfortable and confident when programming under pressure.

Occasionally, WODs required students to work together in groups emphasizing yet another important aspect of software engineering and development – collaboration. Collaboration occurred in several different ways including face to face meetings, communication via email and via Google Hangouts. In my experience, on-line communication was the most convenient and efficient method of collaboration. For example, while working on the final Surferpedia project, my partner and I would email each other updates on our progress or other pertinent information we thought the other might want to know. Also, If we were stuck and wanted help debugging code, we would set up a time to meet on Google Hangouts where we would share a screen and debug/communicate together in real time.

There are some situations, however, where face to face collaboration could be better than online collaboration. During the planning phase of our Surferpedia project, my partner was unable to be physically present in class so we mapped the entire project out via Google Hangouts. While I feel that we did a good job of identifying and assigning tasks, I feel that the discussion was limited due to the fact that our conversation was via chat. I think being together in person, brain storming, and talking through ideas would have been a better approach but maybe I’m just old fashioned.

Once my partner and I decided on a set of issues and laid them out on a timeline, we needed a place to document it to ensure that we remained on task and on time. Github provides an excellent tool for this purpose. Each of our tasks became github issues. Each issue was assigned to either me or my partner and associated with a milestone. Milestones were closed once all of its associated issues had been resolved. Due dates were assigned to each milestone ensuring we kept to our timeline. It was helpful to see exactly what I was assigned to complete and encouraging as I got to check each issue off of my list. Although our issues changed slightly throughout the implementation of this project, githubs issues system easily accommodated these changes. This tool was instrumental in keeping us organized and on time.

Throughout the development of this application, my partner and I were careful to be mindful of Checkstyle warnings and errors; resolving any as soon as we could. This was done largely out of habit (neither of us liked seeing the little red x’s indicating errors) but by adding javadoc comments, avoiding magic numbers and adhering to standard coding conventions, we were ensuring the quality of our application. And while these things may seem minor, they can mean a world of difference to someone modifying our code later or to a future employer who may value thorough documentation and clean code.

Ensuring quality with tests

Another tool we used to ensure quality in our application was JUnit and Fluentlenium. At first, our team experienced some difficulty when executing the tests but after that bug was fixed, testing became easy. Initially, I felt that writing tests into this application was overkill since it is small enough to test all functions manually. Later I realized that the best time to implement testing is at the beginning of the project or while the application is still small. The reason for this is because if a test were to fail, debugging a small app is easier than debugging a massive one. Also, if tests are implemented from the start, then they can be routinely executed as the program expands, exposing potential flaws and helping us to build a higher quality application.

This has been, without a doubt, a very productive semester. I’ve learned a lot about software engineering and about what it means to be a good software engineer. As a result, I’m now able to identify my weaknesses as a developer. For example, when collaborating I am sometimes uncomfortable with the fact that my success depends partly on the actions of someone else. I think that continuing to participate in group projects will help me to realize that my colleagues are, hopefully, just as committed to the groups success as I am. I’ve also realized that it is extremely important to be an active member of the computer science/technology community, which I am not. However, I’ve already taken the first steps to correct this by creating accounts with Linked In and Tech Hui.

Im confident that what I’ve learned this semester will be helpful for the rest of my academic and professional career.

Final Exam: Surferpedia

We’ve finally made it to the end of the semester and what better way to finish up than to complete development on a project we’ve been working on since the beginning, Surferpedia. The goal of this WOD was simple, take everything we’ve learned this semester and wrap it up into a single application. Complete details of the assignment requirements can be found on the ICS314 website here.

As I read through the assignment requirements, a feeling of dread slowly came over me. This was going to be a massive assignment. Luckily, I would not have to go at it alone as this was going to be a collaborative assignment. I was fortunate enough to have been paired with Eva Shek. We’ve worked together on an in-class WOD once before and, in my opinion, we made a good team.

Planning with Github Issues and Milestones

Before we did anything else, we were instructed to read through the requirements and break them down into smaller, manageable tasks. These tasks were then separated into three groups. When all of the tasks in a group were completed, we would consider that phase of development complete, and issue a release.

Mapping out our development plan in this way was critical in ensuring that both Eva and I knew what we were responsible for completing and by when. Over the course of the project, some tasks were changed, others were added and others deleted. Had our development plan been done on paper, we would have had an extremely difficult time keeping track of these tasks and timelines, especially since Eva and I rarely worked together in person. However, like many other challenges associated with collaborative development, Github offers tools to aid developers overcome these obstacles. Each of the tasks Eva and I identified became Github issues. Each issue was associated with a Milestone. Milestones was designated as complete when all associated issues were closed. Github’s Issues and Milestones tool gave us a single, central place to store our development plan and timeline. It was instrumental in our completing this assignment on time.

Github Issues and Milestones

Development

Once we had decided on our issues and due dates, it was time to develop. Both Eva and I were initially assigned 9 issues to complete but over the course of the project that number slowly increased. Most issues were tiny and relatively easy to do; others were a little more challenging.

My first task was to bring the Surferpedia application up to date. Luckily, the only component that needed to be added was the tracking of updates and I was able to implement this quite quickly.

My second task was to update the Surfer model to connect to a MySQL backend. My goal was to implement this functionality as quickly as possible since almost every other function in the application relied on the Surfer data being available. Since we had just finished the section on implementing persistent data, the process was still fresh in my mind and I was able to implement this function quickly too.

The most challenging task I was assigned was the building of our “Name The Surfer” game, one of our cool new features. In the game, a randomly chosen picture of a surfer is displayed along with the names of 4 other randomly chosen surfers belonging to the same gender. The user is asked to correctly identify the surfer. After making a selection, a modal informs the user that they are either right or wrong and the number of wins or losses is incremented as appropriate. The most difficult part of implementing this function was figuring out how to display the correct modal and how to set up the page so the answer was not part of the option links.

Cool New Feature: Name The Surfer!

The rest of the development went smoothly. Eva and I met on Google Hangouts many times and helped each other implement parts of the project like pagination on the search results page and the “Active” or “Deleted” status on the Profile page (our other cool new feature).

Another Cool New Feature: User Profiles!

Testing

There was a lot of discussion on the ICS314 Google Group forum regarding testing. Several people in our class reported that they were consistently experiencing an error having to do with hidden elements that would cause their test to fail. A couple of suggestions were offered in the forum as ways to resolve this error. The first was to click on the nav-bar button before clicking on any link contained in the nav-bar. The second was to use the FIREFOX webdriver. I decided to use the first approach for two reason. The first because I had already implemented the majority of my tests using this method by the time the second suggestion was made. The second, because using the FIREFOX webdriver requires an installation of Firefox, which i don’t currently have on my machine.

Once the issue with the hidden elements was resolved, writing the test cases was simple. We wrote a battery of tests to challenge most, if not all, functions of our application. To our delight, they all passed.

Release

Once all the issues were complete and we were satisfied with our tests, it was time to deploy the application to Cloudbees. Since the structure of our database changed since our last deployment to include new tables (page_view and user_info), I needed to use Sequel Pro to make these changes in the online database. I had forgotten how to accomplish this so referred to Dr. Johnson’s Play-example-mysql example for a refresher.

See the deployed app here.
Or go to my portfolio project page for more information.

Reflection

At the beginning of this semester, I expected that in this class we would be building the same old, boring Java programs that one would interact with via the command line. However, the programs we’ve built this semester have been any thing but boring. We’ve created some amazing web applications this semester and with Eva’s help, this Surferpedia project is the latest and greatest one yet.

A27: Testing Our Applications

This week, our WOD focused on the extremely important topic of testing. This was one of the most difficult WODs of the semester. I spent more time on this one exercise than on most other WODs. A complete description of the WOD can be found on the ICS314 website here.

Testing-1: DigitsTest

Goal: Add a set of simple tests to the Digits application.

My first attempt at implementing test cases did not go well at all. I worked for about an hour and a half and made almost no progress. Since I had already exceeded the DNF time of 60 minutes, I decided to watch Dr. Johnson’s solution then try the WOD again. Like other difficult WODs, I took notes on Dr. Johnson’s implementation as I watched the lecture then referred to these notes during each subsequent attempt. I thought Dr. Johnson’s solution was clear and easy to understand and I felt confident that I would be able to successfully implement similar tests in my application with little difficulty. This was not the case. At first, I attempted to write the test cases from memory and based off of my understanding of the material; some tests passed but most failed and I didn’t understand why. After about an hour, I resorted to copying Dr. Johnson’s code verbatim and the tests still failed! Frustrated, I called it quits after about 2.5 hours of work (obviously another DNF).

As I was thinking about the WOD the following day, I realized that my implementation of the digits application differed from Dr. Johnson’s implementation in one major way; I purposely secured the index method of the Application controller class so unauthenticated users would be redirected to the login page. During my first two attempts at this WOD, I noticed that this was causing issues with the indexPage.isAt() function and decided that during my third attempt at this WOD, I would change the index method so it was not secured before implementing any of the tests. Making this change was fairly easy and only took a few minutes to complete. I then began implementing the tests and much to my delight, the tests were passing and I was able to complete this attempt in Rx time of 30 minutes and 39 seconds.

I think that throughout this semester, testing has unfortunately been rushed and/or inadequate. Now that we have the tools to automate testing, we can be more mindful when building our applications to make testing easier. For example, assigning an id to each element on a page you may want to test and assigning unique titles to each page. Although this was a challenging WOD, it was important to learn since testing is a critical component of any quality product.