avicii’s pizza

This is my latest code review project. The coding program I am going through, Epicodus, is modeled after a software development company rather than a school. That means that instead of lectures and classes and homework, the emphasis is heavily on time with hands on the keyboard. Each day we pair up with a different peer and “pair code”—work through a coding exercise together, switching off typing code and proofreading for errors. Every Friday, we work alone on a project from 8am to 5pm, and we are not given the prompt ahead of time.

Screenshot of “Avicii’s Pizza” webapp.

This week’s challenge was to build a website that allows the user to customize a pizza and be returned a price for that pizza. I ended up building something a little more complicated than that, and that was one of two big mistakes I made that led to this being a more difficult project than other Friday code reviews. 

This week we added object constructors and prototype methods to our JavaScript toolkit. At my level of understanding right now, objects and methods are the heart of object oriented programming languages (like JavaScript, and many others). An object is constructed, and the object bounces around various functions as they are triggered by the user. 

I’ve been making really good progress, and that good progress led to my other big mistake this week. On Wednesday I worked with another student that came into the program from an IT background and together we blazed through the learning exercises we had for that day. That gave me a false sense of mastery over the material, and I ended up spending time helping a student in my team this week that was running behind on the material. What I didn’t realize (and what I might have caught if I had continued going through the extended practice projects) is that I didn’t quite internalize a particular strategy used to loop through objects stored in other objects. That strategy would turn out to be essential to finishing this project. 

Photo of planning notebook.

I started out by sketching my vision in a notebook. I struggled last week with coding according to test-driven development principles, writing incremental tests for my code before writing it. I had an idea that making a list of functions to write might help me not get distracted by xyz questions when I was working on abc. That turned out to be a good idea, but I also ended up sketching out a system that was a lot bigger than I was asked to make. I read through the specs too quickly and I wasn’t aware that I was extending every feature. I also came up with the Avicii’s Pizza pun, putting together Avicii, the late EDM artist that I greatly liked, and Ameci’s Pizza, a SoCal chain that had a restaurant in my hometown. Although nobody in Portland is going to get the pun—and, honestly, maybe not people in SoCal either—it made me laugh every time, and I was looking forward to adding styling and theming as the project got closer to being done.

I worked steadily, building the business logic in test driven steps throughout the morning. By the time lunch rolled around, I had built all of the functions that I sketched out in my list. When I got back from lunch, there was something off about the code I had written. I started to understand that while I had all of my functions written to add pizzas to an order, the way that I had assigned IDs made it impossible to reliably delete pizzas from the order and add new ones. I realized that I had not totally understood the strategy we were taught to do that, and I had to go back to lesson texts to catch myself up. This derailed me for an hour and a half. Even after rewriting, I wasn’t able to get the user interface code I wrote next to work as expected. Once I saw that it was unlikely that I would finish the project on time, it took a lot of wind out of my sails. 

At the end of Friday, I turned in my project as-is, and I was in a pretty stinky mood. I was stuck getting the project over the finish line, but I knew I was close and couldn’t stomach editing down the code that I wrote into something that was simpler but would pass. I came back to the code later that night and made a breakthrough (it was a classic JavaScript mistake—using a `]` when it should have been a `)` ). I went to bed knowing that the functionality of the site was there, and I knew I could put in an hour or two on Saturday and get the project themed and polished the way that I wanted to.

That work was a joy. I figured out how to apply a background gradient in CSS code, which, when combined with lightly-opaque background tiles around the content boxes, got to an EDM theme feeling with barely any additional styling beyond the default Bootstrap theme. I cracked myself up putting together the photo of Avicii with a Super Mario Brothers mustache. The Easter egg that took the most time to implement was adding the chiptune cover of “Wake Me Up.” The implementation of that feature was really satisfying to me: a 1px by 1px tiny YouTube player hidden inside the button that plays when you click it.  

Another chiptune Avicii cover, my other option for pizza parlor theme song.

I have a lot of ideas for getting back on track next time. I got a good reminder that the implementation of a feature may work with one set of features but break if you add more. I also took something from my pairing experience this week: I don’t ever want to railroad my partner or leave them behind, but in order to get the most out of the experience for myself, I also have to work at my own pace in order to explore the extended learning opportunities and projects. This upcoming week we are adding automated testing, package managers, and a full development environment, and all of these tools are new to me. I’m looking forward to this week getting more difficult. 

View the code for this project on Github.

mr. roboger

Screenshot of the JavaScript webapp I created.

This is my latest code review project. The coding program I am going through, Epicodus, is modeled after a software development company rather than a school. That means that instead of lectures and classes and homework, the emphasis is heavily on time with hands on the keyboard. Each day we pair up with a different peer and “pair code”—work through a coding exercise together, switching off typing code and proofreading for errors. Every Friday, we work alone on a project from 8am to 5pm, and we are not given the prompt ahead of time.

This prompt was called Mr. Roboger’s Neighborhood. The challenge was to take a number from user input, and return to that user all the numbers from 0 to the user input number, with some numbers substituted with words based on the presence of certain digits in the numbers. 

This code review project came after a week of learning about creating arrays in JavaScript, manipulating those arrays, and creating looped functions through arrays. The curriculum always includes skills that are relevant to working in the software industry but are a little outside of core coding skills. This week that involved writing plain-English tests for each step of our code writing process in order to prepare us for adding automated code testing to our projects in a few weeks. I found it really frustrating to stick to that focused, incremental way of working. If I have to code a, b, and c, I generally code most of a before going on to b, writing a very specific part of c, then coming back to finish a, which broke b, etc. I can feel that once I get used to the mental discipline of working in test-driven steps, I will start making rapid progress and spending less time tracking down spelling and syntax errors in my code.   

Completing the actual project went really smoothly for me. On Friday morning, I read over the specs for the project, then walked over to the kitchen to make a French press. While I was staring at the water, waiting for it to boil, the basic path toward completing the project just bubbled up from my subconscious. When it came time to actually write it, it turned out to take way more individual steps to manipulate the input than I first anticipated. I also really struggled to keep my work adhering to the test-driven development principles. I made a lot of progress in the morning, and just before lunch I realized I hadn’t documented any tests and had to try and fill in testing for code I already wrote. 

I had the most fun stying the page in the afternoon, after I got the functionality of the project working. I knew right away that I wanted to evoke an old-school monochrome green monitor. I first tried to align the page the way I wanted using the Bootstrap framework that we use as a starting place for most of our projects, but that wasn’t working for me and I ended up styling the whole page in custom CSS. I wanted to transform a picture of Mr. Rogers into green monochrome, but that ended up being a little beyond my skill. I was playing around with the image in GIMP and more or less stumbled across the color distorting effect that made it to the final project. It reminded me of both old school computers and was also a little psychedelic, so I couldn’t resist including it. I also had a lot of fun using the voice reader feature built into most modern browsers. That took the last hour and a half of the day. It wasn’t necessary and using that API was way outside my grasp, but the emotional payoff when it started speaking was the high point of the day.

I’m excited for what’s coming next time. This week we learned how to create our own JavaScript object constructors and prototypes, and if I had learned that technique my code for this project could have been much smaller. I also can’t wait to get skilled enough to understand how, exactly, to manipulate the screen reader to use different voices, pitches, and reading speeds. 

If you’d like to view the code for this project, it lives in this Github repository.