Our second 201 project was to create a pizza shop. Not just any pizza shop, but Pizza 3001 – A cheese odyssey from the future. I’m not making that up.
At the start of the week, this was an introduction to javascript object literals – lots of them. Copy and paste, change a value, copy and paste, change a value, rinse, repeat. But in just a few days, we went from object literals to constructors and working on the prototype – and from static, predefined data to user-provided dynamic data. Hundreds of lines of manually defined javascript became, well, a lot fewer lines and a whole lot more functionality. It’s almost like they wanted us to learn exactly how valuable constructors are. Answer: Very.
- Day 1 product requirements
- Day 2 product requirements
- Day 3 product requirements
- Day 4 product requirements
As you can imagine from the rapid change in how we were writing code, the product requirements kept changing – a lot – and this was both to introduce us to new and different concepts on a daily basis – sometimes more than once daily – but also to get used to the idea of refactoring code. Sometimes that felt more like “deleting and starting over,” rather than “refactoring,” but details, details…
The project culminated in a finished Pizza Odyssey that consists of two pages, the site homepage and an internal sales data page. The public homepage is mostly static and the sales-data page takes user input from a form to generate sales data for every hour a given store is open.
For my project, the number of pizzas sold across all branches is added and stored in local storage; if you fill in at least one location’s worth of data on sales-data.html, the index.html will accurately reflect that count after refreshing. That wasn’t technically a requirement but one of the TAs said I could try to figure it out as a stretch goal, so I did. I got lucky; javascript localstorage makes storing key:value pairs simple and I needed to store a single key:value pair. For anything more complicated – well, we didn’t go into JSON.stringify() and JSON.parse() until the next week.
The important lesson there – and one I ran into at my old job so many times – was figuring out a specific use case and doing something successfully once is great, but until you know the rules behind that particular function or code, you don’t really know that function or code. That said, I’m pretty sure the TA knew that in advance. 😉
The pizza odyssey:
- http://peterbreen.github.io/pizza-odyssey/index.html
- http://peterbreen.github.io/pizza-odyssey/sales-data.html
Fill in a location and number of sales on sales-data and you should see the following behavior:
- A table is generated below the input form with your pizza store and deliveries.
- each hour is individually calculated between provided values even though input is for 3-hour time blocks.
- Filling in a second store’s worth of data will result in a second table being appended below the first; this can be repeated to the limit of your patience or RAM, presumably
- Drivers needed assumes one driver can deliver up to 3 pizzas per hour, therefore:
- even if there is only one delivery per hour a driver is still required to deliver it
- if there are zero deliveries it will return “no driver recommended” instead of 0.
- Total pizzas sold should be reflected on index.html (after refreshing – sorry, no AJAX here)
The main weakness here is error-checking; there’s some in there but for this project getting it to function and assuming users would put in numbers was the primary goal. Not always an assumption you can make in the real world, but it makes learning concepts a lot easier.