Category Archives: All

Kale With Friends Milestone 4

Kale With Friends

The end of the semester is quickly approaching and Kale With Friends is almost complete. Unfortunately, a teammate was having health issues, so we had to cut a part of our project out involving Google Maps. Fortunately, our professor gave us a good idea to resolve this problem by simply leveraging Google Map’s hotlink feature to their Maps site. For the other parts of the website, our professor provided us with some insight on how to improve the views of our application, such as providing additional information for markets and allow users to quickly find where they are.

Issues

The first primary issue I worked on was to allow users to select a market on the Available Now page. This was easily fixed by providing a dropdown menu to allow a user to select a specific market. After clicking the market, the page reloads to only show farmers that are attending the market. By having this type of implementation, consumers are now able to easily view the market’s farmers and their produce if they were currently physically at the farmer’s market.

The second issue(#1 and #2) I worked on was to write tests for the code. Unfortunately during the development process of Kale With Friends, testing the application became a second priority. To remedy this problem, I wrote the tests for the accessing the various pages of our website.

The third issue was pointed out by our professor where our links for the feeds were going to wrong farmer. Apparently there was a bug in the code that caused the link to always default to another farmer because it was missing a parameter. The missing parameter was fixed and the link reaches the correct farmer. A small issue was that navigation bar was also not being highlighted for the dashboard page. That was also fixed by changing the page title to the correct id.

The fourth issue(#1 and #2) is fixing a bug caused by displaying the markets on the farmer’s dashboard and the farmer’s edit page. I had to rewrite a portion of the HTML code to display the model correctly as a string. In addition to displaying the markets, I also changed the edit farmer’s page to display checkboxes for markets as having a text fields for markets was quite unwieldy.

The fifth issue involved updating the Wiki to become more robust. Spent some time to update the descriptions and moved the sections around in the User Guide and Development Guide.

Conclusion

In conclusion, we have a working www.kalewithfriends.us at the end of the semester. Working on this project was quite fun and stressful as deadlines were always quick. In particular, moving from the mockup database to using Postgres was the biggest challenge as we had to remodel our application. There are still some improvements we can work on over the summer in our spare time but as project that only had around a month to implement, I believe we were quite successful. If you are interested in contributing to the project, here is the link to the GitHub repository and the link to our release.

Advertisements

Kale With Friends Milestone 3 Update

Since finishing the module on data modeling, my software engineering class did not assign a new module and wanted everyone to work at full speed on finishing the project. Kale With Friends has been coming along nicely as we got good feedback from the class on how to improve the website. However, we did encounter minor hiccups along the way as we were working on the project.

Database Implementation

One of the key requirements for milestone 3 is that we use a persistent database in our application. Changing from the mockup database to a persistent database proved to be nontrivial. A major problem we encountered was that we did not design our models correctly for the MVC design paradigm. Some of our models were subclasses of each other and this caused a problem when trying to have our classes be extended with Model from play.db.ebean to support PostgreSQL. Since Java does not support classes with multiple super classes, we had to redesign the model infrastructure of our application. Ultimately, we combined subclasses into a single class/model so it can be implemented as a single entity for Model. We also had to rewrite many of our models’ methods since certain classes disappeared due to being merged.

Redesigning Pages

Redesigned page.

Redesigned page.

Besides implemented the database, we also spent some time redesigning our webpages so they are more functional and easier to access. In particular, I focused on the page that displayed fresh ingredients for users to buy. Previously, this page was a simple table that contains the produce a user can buy and their price. A table layout is extremely poor for this type of information since it is hard to navigate effectively. With feedback from class, I redesigned the page to use a tile based system so a buyer can quickly find what they want by just looking at pictures. In addition, having a number for quantity was also meaningless for the buyer because the buyer wants to know quickly if something is available, not how much the farmer has in stock. To solve this problem, I implemented a simple bar type meter using Font Awesome to represent how much quantity the farmer has in stock. This allows the buyer to look at the meter and quickly tell if the farmer is low on inventory.

Future Work

We still have much to work on for this project as some parts of our application are broken or unimplemented yet. Such features include easy searching for farmers or ingredients. I would also like to load more recipes into the database so our meal planner page can provide more detailed information on what can be made with recipes on hand.

Data Modeling – ER Diagrams

For this past week, my software engineering class covered data design modeling. Fortunately, I have encountered this topic before during my undergraduate career in a database class. Data design modeling is the idea of making relationships between different entities for describing data. Known as the Entity-Relationship (ER) diagram, software developers are able to use this information to implement the model into a relational database. To test our capability of designing ER diagrams, my software engineering class provided two WODs to do.

WOD 1 Library Data Model

ERD-Library

First try at Library ER diagram.

The first WOD (link) involves creating an ER diagram that can be used in a library to keep track of borrowers, reservations, books, and loans. To implement the ER diagram, our professor instructs us to use a Google Drive plug-in called LucidCharts. LucidCharts is an application that allows creation of flow charts, tables, floor plans, circuit diagrams, and many more. In addition, it is also intuitive to use as creating a flow chart is as simple as click and dragging the shapes.

Being familiarized with LucidCharts after a experimenting for a few minutes, I attempted my first try at the WOD. Since I have not done ER diagrams in years, I had some struggles at first when trying to conceptualize the problem. First, I initially thought that each individual book should be its on entity. However, spending some time thinking made me realize that I should instead have an entity for each copy of a book for a unique book title. This made creating the entity for loans and reservations a lot simpler because I no longer had to keep track of the copy number for each individual book. My first try at this WOD, got me a time of 15 minutes. Since I was still rusty with ER diagrams, I attempted the WOD again the next day and I got my time down to 9 minutes.

ERD-Library2

Second try at Library ER diagram.

 

WOD 2 Car Rental Model

ERD-CarRental

Car Rental ER diagram.

The second WOD (link) is similar to the first WOD, but we are instead designing for a vehicle rental company. The car rental company needs to keep track of offices in cities, vehicles, customers, rentals of vehicles, and reservation for vehicles. When I was designing this ER diagram, I actually ran into a problem of how to uniquely identify different vehicles. At first, I had a field called vehicleID for each vehicle, but I felt this was too arbitrary. However, I realized this vehicleID is the same as a license’s plate number a moment later. Laughing at my own foolishness for a little bit, I continued work on this ER diagram and was able to finish in 11 minutes.

Conclusion

This week was a good review on basic database concepts of ER diagrams. I quite enjoyed the WODs as I was able to use my previous experiences from my undergraduate database class to design the ER diagrams. I also gave myself a pat on the back for being able to remember the concepts from a class that I took years ago. Hopefully my past experiences will make the next module on implementing databases somewhat painless compared to learning about web development.

Kale With Friends Milestone 1 Update

Today I will be giving an update on our group’s Kale With Friends project. The previous project update a few weeks ago consisted of a simple design mockup for the website. Currently, our project is coming along nicely with some features of our website already implemented.

Our goal for milestone 1 is to allow a user to find a recipe given a list of ingredients the farmer’s were selling. Imagine if you were at a farmer’s market and you are interested in what the farmers were selling. You bring up Kale With Friends and navigate to the page that notifies you what each farmer has in stock. Looking at the list, you can already imagine what you may want to cook tonight for dinner. However, you don’t feel like eating that dish today. Luckily, Kale With Friends is able to inform you of several recipes that are availiable given the ingredients the farmer’s sell. Finding a recipe you like, you go to the appropriate stall to buy whatever ingredients you need for tonight.

The above is a simple scenario of what we want milestone 1 to accomplish. In the future, we plan to add user reviews of farmers, user reviews of recipes, and also perhaps provide real time updates as a farmer’s market is in progress.

Progress Review

Working with my group so far has not been too problematic. The most common issue appears to be that we sometimes push code that has not been fixed with CheckStyle or not formatted correctly. Fortunately, we usually realize our errors almost immediately when we check our code on GitHub. Another issue that I found personally was that I realized I am terrible at creating good branch names. When creating a branch, I would call it whatever I wanted to work on. However, when I started working in that branch, I found out that I had to implement another feature of the website before I could work on what I wanted to work on. This caused my branch name to be named incorrectly because I implemented a different feature than what I initially wanted. The branch names actually caused a minor confusion within my group because they would do a pull on the branch thinking I implemented that specific branch feature when I did not code that feature yet. Fortunately, my group members weren’t too upset with my poor branch names when I told them which branch contained the actual implemented features.

If you want to know more about our project, here is the link to our GitHub repository and our project website, Kale With Friends.

Future work

While we encountered minor issues with the workflow for the project, we are still coming along nicely in creating Kale With Friends. Although, we still have to improve our communication within the group. To remedy this, we recently started a chatroom in Slack so we can quickly give updates to each other. I also need to improve on my ability to create branch names so they are descriptive for the feature I want to implement in that branch. All in all, I foresee the project to be completed on time when we reach the end of the school semester.

Templates and Testing in Play

Continuing to master the Play framework, this week we will talk about implementing templates and testing. We last left off Play with making a Digits application that can handle simple creation, reading, and updating of contacts. While the core functionality of the application does exist, the code can still be improved. For example, there is some repeat code for creating form fields in the HTML files. Having this section of repeat code is bad coding practice and should be replaced with a template.

WOD 1 Digits Test

The first WOD (link) is to remove the default integration testing and replace it with FluentLenium and HTMLUnit tests.  FluentLenium is an assertion framework that assists in testing with the Page Object design pattern. HTMLUnit is a library that provides a simulation for the browser. By combining these two libraries, we can write test cases that are more “realistic” and interface with the frontend of the application instead of the backend.

To do this WOD, my professor provided a demo Play application that introduces how to use the libraries effectively. By providing this demo, performing this WOD was not as difficult as I thought because most of the code I had to write could just be done by modifying the sample code from the demo.  I think the only issue I had with this WOD was that I was unfamiliar with the FluentLenium syntax for creating assertions. For example, the correct way for writing assertions is to write assertThat(pageSource()).contains(firstName) and not assertThat(pageSource().contains(firstName)). Overall, my time to finish this WOD was 29 minutes.

WOD 2 Digits Text Template

The second WOD (link) is to refactor the form fields in our NewContact page to use Scala templates to help reduce the clutter. Again, my professor provided another demo Play application that uses Scala templates in its pages. Refactoring the code was a simple matter of rewriting the HTML code using the template and filling in the required fields. My time to finish this WOD was a quick 10 minutes.

WOD 3 Digits Selection

The third WOD (link) involves using a Scala template to create a select field in our NewContact page. This select field will allow the user to choose the type of phone number (homework, mobile, or work) for each contact. Since a new field is being introduced, we also had to update the controller, models, and tests in the application. What I found difficult with this WOD was that it combined almost everything that we learned so far in creating the field. When writing the code, I had moments of being “lost” in what I was trying to do because many things had to be changed at once in order to support the new field. For example, updating the ContactFormData also requires updating the Contact model to support the new field. Since the Contact model was changed, I also had to update the controller to support it. Because everything was interconnected, making a small mistake (such as a typo) can cause repercussions in the other areas. Finding and fixing the mistake sometimes made me forget what I was trying to do in the first place. This experience taught me that I should do everything procedurally so I can have a trail I can backtrack to in case something goes wrong. Performing this WOD took me about 38 minutes to complete.

WOD 4 Digits Custom Template

The fourth WOD (link) involves creating a custom template that contains the telephone number and telephone type fields. Creating our own template was not a difficult task since it only involved modifying the previous template code. My time to finish this WOD was 12 minutes.

WOD 5 Digits Init

The last WOD (link) for this week is to initialize the application with some prior data. Play has a nifty global class we can write to initialize some data on start up. Play’s example on their website was easy to understand and I was able to implement what was needed quite quickly. The only problem I encountered was that I accidentally imported the wrong Play class through IntelliJ’s auto-import feature when overriding the onStart() method. My first try at the WOD took me 16 minutes while my second try took me 10 minutes.

Conclusion

Digits Repository

 

This week had a lot of material to cover since we wrote new test cases, introduced Scala templates, and introduced a new field. While I feel that this week wasn’t as difficult as the previous week, the amount of material that we covered was significantly higher. Especially with the third WOD since it involved everything that I knew about Play. I definitely need more practice in Play since our project for the class involves integrating everything that we learned.

Kale with Friends Project Mockup

Like any other graduate level class, my software engineering class requires a class project to be completed by the end of the semester. Having no idea what to do yet, I was scrambling around as a headless chicken looking for a project. Fortunately, my class had a meeting one day to pitch ideas and form groups. Listening to all the others got my head thinking and I was able to pitch an idea of making a food application. Amy, William, and Bryant listened to my idea and we all liked it. From here, we were able to easily form a group.

While we had a core idea of making a food application that involves a social networking and recipes, we talked with our professor to see if we could improve it. Our professor had an ingenious idea of involving not just consumers of food, but also the producers (farmers) that can provide groceries for consumers to buy. A great example our professor provided was eating kale. Say a person wanted the best Kale dish and looks up a recipe from a friend’s cookbook. From the cookbook, the web application is then able to tell the user what and where to buy ingredients for the best Kale dish. The application will then notify the user with nearby local markets where he/she can buy the ingredients. By taking this idea even further, our application can also schedule meals for a week and let the user know what he/she can make or buy from the market.

 Planning Phase

Motivated with our project idea, we decided to immediately meet together the next day to begin our project mockup. We had to decide what information we wanted to include, what pages to create, how information relates to each other, and overall application structure. We spent around an hour and a half to determine what we wanted the web application to feel like. By the end of the discussion, the whiteboard in the graduate lounge became mess of all our diagrams and idea maps. We were also able to come up with the great name of “Kale with Friends.”

Splitting the work became pretty obvious in our project because we had two core components in the application: the social aspect and food/recipe database aspect. We were able to quickly assign work to the four of us to make the mockup of the project.

Mockup

The Profile Page.

All of our group’s code is hosted on GitHub and we decided to make the mockup using Play to improve our Play skills. While creating the pages in Play was not hard, the only minor issue I noticed was that some of my group’s code was not conforming to the class coding standards and tests failed. Luckily, IntelliJ’s features made editing the code and fixing the tests extremely easy. Besides this minor issue, I have no problems working with my group in actual coding work.

Future Work and Conclusion

I personally think my group is off to a good start with our project because we have a clear idea and what we want to accomplish with our project. We could probably improve a little bit more in a workflow by having our code comply with the coding standards. Another way I think we can improve our workflow is to be able to talk to each other using a live messenger client instead of E-mail. I personally like using messaging clients more than E-mail when communicating because it is mostly synchronous. However, we do meet in person so perhaps a messaging client isn’t required.

Overall, our personalities also mesh pretty well with each other and we are able to kick off ideas back and forth between each other. Honestly, we were all laughing when we came up with “Kale with Friends” as our project title so I believe I’ll have a great time with this project.

MVC in Play

diagrams_mvcToday’s blog is an update on my learning progress of the Play framework from last week. We last left off with building several simple websites in Play. While last week focused primarily on porting an existing website to the Play framework, this week will focus on creating a website from scratch to support web applications.

To create a website using Play, one has to understand the MVC (model-view-controller) design paradigm. Models are data objects that web applications use to store information while views are what the users will see when accessing a specific webpage. The controller is what ties the models and views together by modifying both the models and views depending on the user’s action. By combining these three concepts together, the MVC design paradigm allows developers to partition their web applications into distinct parts and allow for easy changes to the application.

WOD 1 Digits Mockup

The first WOD (link) is similar to last week’s WODs where we had to create a simple website with multiple pages. This website will be used to store contact information of people. The website will contain two pages, a contact page that lists all the contacts and a new contact page that allows the user to add a contact. Note that there is no functionality for any of the pages yet. My first try at the WOD took me 25 minutes to finish and did not encounter much difficulty.

WOD 2 Digits Form

The second WOD (link) involves taking the new contact page we created and adding functionality to the forms. By adding functionality to the form, the web application will actually be able to read user input and print them out to the command prompt. To do this, we had to edit the form fields in the views with some Scala code to tell the controller that there will be user input. My difficulty with this WOD was trying to remember the Scala syntax to do what was needed. The first attempt at this WOD took 22 minutes and my second attempt took me 20 minutes. I think I was unable to achieve significant improvement was because I still had difficulty remembering all the Scala code. Knowing this, I started making a small list of Scala code so I can remind myself what the syntax should look like.

WOD 3 Digits Form Validation

The third WOD (link) makes changes to the forms so they can validate user input. This means that the web application will check the fields for empty strings or incorrect formatting when the user adds a contact. Doing this WOD was relatively easy as the only thing that was needed was to write “if” statements to check for errors on specific fields and update the controller. If an error was found, the web application will notify the user what was wrong with their input. Bootstrap provides a good example on how to embed the error notifications into the field so doing this was a relatively simple task. I was able to finish this WOD at around 18 minutes.

WOD 4 Digits Model

The fourth WOD (link) requires model to be created so the contacts the user inputs can actually be displayed back to the user. To enable this functionality, we had to create a model for the contacts and a mockup contacts database. After creating the models, all the corresponding controllers needed to be updated to allow model creation. While creating the needed functionality is not difficult, most of my troubles were still in writing Scala code since I am still unfamiliar with the syntax. The time required for me to finish this WOD was about 25 minutes.

WOD 5 Digits CRUD (Create Read Update Delete)

The last WOD (link) for this week is to complete the functionality of the models and allow the user to edit and update contacts after the contacts have been inserted into the database. Since updating a contact reuses the “new contact” page, we had to utilize ID fields to be able to pre-fill data on the page. The way this works is that each contact within the database has a unique ID. If a user wanted to insert a new contact to the database, a new ID will be created for this contact. This means that the “new contact” page will check an ID parameter every time the page is loaded to see if data needs to be pre-filled.  My attempt at this WOD took me around 24 minutes to finish.

Conclusion

I think the only major difficulty with this week’s WODs was trying to remember Scala syntax. For example, Scala uses brackets “[ ]” for parameter fields (Who does this?! Brackets are for arrays!). Another minor issue might be that I still don’t know all of Play’s built-in methods for the controllers and I have to look them up. Since I had experience with the MVC design paradigm, I knew what was required to perform the needed functionality. The problem was that I simply struggled with a new language. Hopefully this problem will slowly resolve itself as I work more within the Play framework and redo some more of these WODs.