My Second App

Mod 2 at Flatiron is all about frameworks: support software for creating web apps. After being introduced to the Model-View-Controller (MVC) domain model, we spent several days learning Sinatra. When they decided we’d had enough of that (the UN Human Rights Council might’ve intervened), they introduced us to Ruby on Rails. So the final project was to be a web app built on an MVC domain in Rails. Projects had to have at least one many-to-many relationship and at least two forms.

My friend Alex and I decided to create Movie Night Voting Booth, where a group of users can submit movies and then vote them up or down. Presumably, the highest-voted movie is watched.

Our instructors introduced us to the concept of Minimum Viable Product, the absolute bottom-level app that meets the deliverables. We wanted to be able to create a user, the user can enter a movie title, the movie could be voted on, and then the votes could be tallied.

We turned that out in about four hours. (Thanks Rails.) It was ugly. The user interface was the cutting edge of 1997. But it worked.

So we started thinking of ways to make it look like a real web app.

I come from the days of the dumb static website, but that doesn’t cut it anymore; everything has to be customized and personalized. You want the app to know who you are.

Alex and I knew we wanted to keep track of what user submitted what movie, and we wanted to limit votes to one up- or downvote per user per movie, to prevent spamming. We also wanted to implement an admin role for users, someone who could delete movies and decide when the voting was done.

So that was the User class settled. How were we to populate the Movie class? The MVP version had users typing in names, but I knew there had to be another way.

To get from a user inputting words to search, to parameters that can make an instance of the Movie class, there were many steps.

This glosses over the many hours of tears and screams, cursing the inventor of JSON and all his children, and what I’m sure is the beginning of a very exciting ulcer in three to seven years, as well as the palpable relief when I was clued in to the eval function. eval takes a JSON object, escaped characters and all, and turns it into a regular Ruby hash object. It is a handy trick, and one I’m sure to forget in four weeks when I next need it. (Part of my writing all this down is to help remind me of this very thing.)

So that was the backend code, more or less: the logic for restricting votes (one vote per user per movie) was pretty straightforward. Returning the vote tally wasn’t a hard problem either, it just took some custom routing and writing a couple of methods.

But just because the backend’s done, doesn’t mean you’re done.

CSS sucks. I know it’s better than the alternative, but dang, CSS, you’re annoying and hard. I’ve had to work with CSS just enough to know that I care very little about the difference between an em and a px, and that having to think too long about selector specificity makes me mildly nauseous.

In the MVP version of Movie Night Voting Booth, I used radio buttons in the form for voting. They worked, and I could have lived with it, but really I imagined hitting a button to upvote, preferably with a big green arrow on it.

When creating the project, I was a bit of a doofus and managed to create it all inside a top-level folder, so the file structure ended up looking like this:

If you’ve used Git before, though, you know there are also hidden files that normally you don’t have to worry about. One particularly useful one is .gitignore, which sets up a blacklist of directories where changes to files won’t stage them for commits, places like /tmp or /log.

So guess what happens when you’re a doofus who reorganizes your project structure and manages to delete your .gitignore file! You get 2,000 changes staged for committing. (This is not an exaggeration.) Guess what happens when your doofusness intensifies and you push all those changes onto your branch! Git does what you tell it to, and now your remote branch on GitHub has all the changes. ALL THE CHANGES. Everybody ready for the fun part? Guess what happens when you try to merge this branch with master? There are merge conflicts. Two thousand of them. Each of which must be resolved to merge the changes you actually made into the master.

I am not good at Git. This is obvious. If I was much better with Git, I could have resolved this problem without deleting my branch on GitHub and rm -rf-ing my project file on my computer, then re-cloning the master branch. If I was just a little bit better with Git, I wouldn’t have deleted my .gitignore file.

Don’t be like me. Be smart. Don’t delete your .gitignore file. Here endeth the lesson.

Related posts:

All girls blush when they pass a guy they fancy, and it is a true fact! Women love to dress up for men in order to impress them but they often forget that it’s not in the eyes always. Men just not…

La receta Corned Beef And Cabbage With Irish Mustard Sauce podría satisfacer su antojo europeo en alrededor de 4 horas y 30 minutos. Este plato principal tiene 829 calorías, 51 g de proteína y 49 g…

Didier Lombard and several ex-managers have recently been sentenced to a 15,000 euro fine and a year of imprisonment for “institutional and moral harassment” regarding the way they had managed change…