Wiki and Grillber

Dominic Zenon
Oct 23, 2016 · 5 min read

October 23, 2016

Since the last posting our class has learned how to use Flask and Apache with Python and Postgres. Without a doubt, week 5 and 6 have been a struggle for me but with time and repetition I am becoming more comfortable with everything I learn. Flask is a micro web framework built in python that allows us to create websites using its default Jinja2 template. Our first assignment was to take our phonebook app, which we originally constructed to run through the terminal and run it on our local server using flask with css styling and all. The phonebook app lets you add, edit and delete phone/email contacts. Our second assignment was to create a 90’s wiki where anyone can create, edit and view the pages. Extra features were added as well. The user must be logged into their account in order to edit pages but they don’t need to be logged in to view pages. Wiki linkify makes all CamelCase words (DigitalCrafts, HomeBrew, etc) links to their pages. Markdown was also implemented into the edit pages allowing users to use special syntax to edit the pages. My full code can be viewed on Github.

The Wiki exercise helped prepare us for our first group project. We split up into teams of 4 and had to come up with an application that utilized everything we learned. Our team, named Apollo13, decided to make an application that allowed people to rent high end grills called Grillber (As of writing this, our team has worked on this for a week and is not finished). We first built our database in Postico. To keep it simple, our app makes the customer pick up the grill instead of having to figure out the logistics of a delivery system. The user can view the site and see what grills are available based on the day clicked on in the calendar. After this point the user must create an account and login to go further. When the user is logged in, it welcomes them by name.

At this point the user can place an order. We have 3 grill sizes. All the grills in the database have names. We only have 6 grills that can be rented on a specific day in the database. A(standard, large, and xxl) and B(standard, large, and xxl). Its status can be seen whether its rented or not.

The grill id is linked to the day the user clicked on the calendar.

We set a specific user, the owner, to render an account page that is different than all of the other users. The owner can view all of the grills that are rented to users and can apply/cancel grill reservations.

Autumn and I mainly did the front end and my other two teammates the backend. Our team was very good at collaborating and we constantly regrouped breaking everything down into post-its by priority. I didn’t feel like creating a website from scratch especially since we only had a week to come up with a solid MVP (minimum viable product). I found a free template to use with all the built in css and javascript, but quickly realized how bad of an idea that was. It had what seemed like miles of code which became a nightmare to edit. I had to find almost everything using the chrome console or ctrl-f in Atom. Some of the biggest hurdles were the navigation bar, calendar and forms. Trying to edit the navbar or use it in other html pages other than main page would constantly stop something else from working. A lot of this was because we needed bootstrap and a jquery plugins for the calendar and forms but that would override the the css in the downloaded template. We decided to make our own navbar for the other pages and styled it as closely as possible to the main page. We placed this navbar in the layout.html to be extended to all pages except the index (main page).

My teacher Toby also gave me and Autumn a very helping debugging technique called Test Case Simplification to find why something stopped working correctly. This is especially useful when you have no idea where to start searching for the bug and don’t have a hypothesis. You need the working version (hopefully saved on github or somewhere else) of the file. You then start deleting large parts of the code using the binary search method (going to the middle and deleting half continuously). Keep deleting until the working version stops working and find the exact point where it happens. You should now be able to spot the error. You can now put the fix in the original non-working version. This technique was used to find out why our website’s gradual scroll down stopped working, which was caused by the use of an <a> over a <span>. Unfortunately it only fixed it while viewing it in the browser locally and nowhere else so I still need to go back and figure out why.

We used github to upload and merge our files, which quickly became a real pain because we constantly had merge conflicts. Hours of time was lost redoing sections because sections of code were missing in the master branch.

I think this is an accurate representation of what our group thought about using git.

The initial process of setting up Apache in the terminal is long and confusing. I still don’t understand the whole process very well. Apache is a popular web server software utilized by a huge portion of websites on the internet. I set up an Amazon Web Services account and am using EC2 to run Grillber and its PostgreSQL database.

I’m not sure if we will have much more time to allocate toward Grillber, but for a first group project I am very happy with how it turned out.

Dominic Zenon

Written by