And I Told Them I Implemented Surferpedia

The front-end of the system.



Surferpedia. A name that makes ICS 314 students tremble in fear. Throughout this semester, a constant between all the different modules was the reoccurrence of implementing new concepts to the ever-growing Surferpedia system. The course continually evolved but the only certain thing (other than death and taxes) was Surferpedia making an appearance. So it would make sense that the final project for this course would involve Surferpedia in some way.




The requirements for this phase are not anything that I have experience in this course yet. For one, it was a collaborative effort that needed to follow a plan and offer incremental releases; something that I would assume emulates a "real" . For the purpose of this project, I was partnered withand used his system.



Visit the projects page for more information .



MILESTONE 1.0



Since this project required a planning phase, my partner and I created a quick plan on the day that we were assigned the project. However, due to scheduling conflicts and other circumstances, this was the only time spent on the planning for the system. All issues were generated on this meeting and set to their specified milestones. On paper, the plan was set in such a way that the amount of implementation required went up with each milestone which, in hindsight, should have been spread out more evenly.



The ER Diagram for this project.



The key implementation for Milestone 1.0 was setting up a backend for Surferpedia since it was still using in-program data structures to stores its non-persistent data. Nothing too challenging since it was something I had done a lot but I had to work out some quirks in the system to conform to the ER diagram for this implementation.



MILESTONE 2.0



With a backing database in place, it was time to do some of the cool new things like adding a much needed search widget into the system. However, this is where I ran into my first (of many) issues during this implementation. The search widget itself is a basic inline form consisting of a text box (for search term), two drop-down menus (for type and country) and a submit button. The front-end was easy to make since has numerous templates for form creation. However, the trouble came with the search results.



Pagination example.



As specified by the project requirements, the search results must be paginated so that 15 results are displayed per page. The pages can be accessed by clicking on pagination links on the bottom of the search result page. , which is used to communicate with the MySQL backend, provides a rather easy-to-use method to implement pagination for queries but it did not cross my mind to do it that way. However, I did not have the insight to use it since I tried to use own pagination module which, as it turns out, does not work in Play 2.0. With that falling through, I tried a brute force method of passing a List of Surfers between the search page but that ended up not working out too well (while ruining a weekend in the process). I finally got pagination to work using a combination of the PagingList of EBean along with the pagination list from Twitter Bootstrap.



MILESTONE 3.0



The only things I worked on for this phase was the implementation of a user personal page, the favorite function and test cases for components that I added. The personal page was just an extension of the existing surfer page though I wanted to try something different with the layout since the user's do not have much in the way of information. I used panels to try and get a clean interface to display both the ratings and favorites created by the user which turned out alright.



User personal page.



The favorite function itself was also rather simple since it required no form back end and has two simple states that circumvent the need for rigorous testing (though I still put a few checks to be sure in the corresponding database class and Scala template). The relationship was similar to the system I implemented so that served as a nice template to work off of.



The meat of the issues came from test cases which was tested using and . Since my partner was working on the rating system at the same time, I had to save test cases involving the Surfer's for last which was fine since I was stuck with figuring out the test cases for the other functions of the system. One of the main issues was a ElementNotVisible exception which was thrown when trying to click on the Login link in the navigation bar. I became rather perplexed when I could click on the Surferpedia header and submit button for the search widget but not the Login link. What ultimately fixed it was a change of themes from the standard BootStrap theme to a theme. Everything else worked as expected except for the testing of rating which (due to implementation reasons) is rendered invisible to Fluenlenium and cannot be tested. This is caused by a input:hidden type for our rating form.



COLLABORATION/PLANNING



Communication is an important aspect for developing anything with other people. Throughout its entirety, this project was done mostly asynchronously with main line of communication (other than a few minutes of discussion when we saw each other in class) was email. I have done this style before in other projects which did not end well and this was no different. It became difficult to gauge progression since we just could not find a time to do a Google Hangout or talk outside of class face-to-face. The lack of communication caused a bunch of issues in terms of merging conflicts and who is going to do what (which also ties into the strength of our plan). A single hour-long session to hammer out a plan was not enough for the scope of this project and we needed to have more discussion about the progression of the system and who is assigned to what tasks. However, we were able to overcome the issues and complete the project.



Overall, this project was quite difficult mainly due to the lack of communication between me and my partner. This is not a uncommon occurrence when doing asynchronous development since feedback can be hard to come by. I am starting to think the way I communicate with people needs a lot of work since this is not the first time it has happened. I realize that I may be quite overbearing when it comes to communicating ideas (take this blog post's verbosity as an example) which can either rub people the wrong way or out right annoy them. It is something I need to work on since collaboration is a key part of software development. To end on a positive note, even with all the issues and conflicts, this project was a great learning experience and am satisfied with the end result.



Visit the projects page for more information .
Full Post