#sinatra app

The most important thing I learned during the course of this Sinatra project was that waiting until I felt like writing this blog post and recording my video walkthrough just made me not want to do it even more. But, before I get into that:

The Basics

Here’s a link to the repo.

So the app allows people to recommend books to each other. I used my newly acquired (at the time) knowledge of sessions to build a very basic authentication system. I faced two particularly challenging issues while building my book recommendation app: The first was the fact that all objects of the User class could recommend books and be recipients of book recommendations. I ended up simplifying this by adding a “recommender_id” foreign key to my Recommendations table (which was the join table for my Users and Books tables). This way, the “user_id” of the recommendation would be that of the person whose page the book appeared on, but the recommender’s information was still stored and easily accessible. I also create custom setter and getter methods in the Recommendation class for recommender_id just so I could work with it as easily as I worked with my other Active Record objects.

The second issue was my utter inability to style forms. I ended up getting a bit more comfortable with Bootstrap while styling this app, but I still cannot figure out how to style forms the way I would like them. I ended up just centering all the forms. I’ve been trying to style the forms in my next project for the past three days so hopefully I have a breakthrough soon. (Also, the styling on my next project, is much, much, MUCH better so stay tuned for that blog post/video walkthrough.)

EDIT

The forms look totally fine in this app. I literally waited so long to record this video walkthrough and write this blog post that I forgot that I do know how to style forms. The styling issue that i had was that I wanted to display my books in a grid formation but couldn’t get the spacing right.

Reflections

The following is a guest post by Amanda Himmelstoss and originally appeared on her blog. Amanda is currently in the Ruby-003 class at The Flatiron School. You can follow her on Twitter here.

This weekend, I wrote a simple door buzzer app that requires authentication before execution. The point of this is to be able to buzz open our downstairs doors from anywhere (particularly useful when hosting airbnb guests). My boyfriend did all of the methanical work: we got a raspberry pi (which we turned into a server to host the app) and a relay to connect that to the door buzzer (there was sautering and wires involved; I just watched). Through that, it’s possible to trigger the buzzer from the command line of the raspberry pi. We (well, mostly my boyfriend; I, again, just really watched) wrote a simple C command to trigger the buzzer for 5 seconds, long enough for someone to get through both doors downstairs:

I ap­proached this pro­ject not ne­ces­sar­ily as a big chal­lenge, but as a way to drill in the skills we’ve been work­ing on this week into a cool, use­ful pro­ject. This is the second per­sonal pro­ject I’ve worked on dur­ing school, but one that was most re­ward­ing. To see all the com­pon­ents come to­gether to make something that is truly use­ful was super awe­some for me. I had been vaguely en­vi­sion­ing writ­ing a door buzzer app for quite some­time, but I didn’t have the skills yet to ac­com­plish that. It was an em­power­ing to real­ize I was at a point in my learn­ing where I could build something that 4 weeks ago, I wouldn’t have known how to even begin build­ing.

This was an ex­er­cise in Sinatra, Ruby, ERB/HTML, SQL­ite/Se­quel/mi­gra­tions, and gen­eral pro­ject or­gan­iz­a­tion. From scratch I had to set of the pro­gram en­vir­on­ment and config.​ru files, which I can al­ways use some prac­tice with. I won’t bore you with that part, but in­stead get to the meat of the ap­plic­a­tion.

I have only two mod­els in this ap­plic­a­tion: Buzzer and User.

Buzzer only knows how to do one thing right now, which is trig­ger the C com­mand that in turn trig­gers the buzzer it­self:

User is more ad­vanced, be­cause it in­ter­acts with the data­base, which I cre­ated with Se­quel and mi­gra­tion meth­ods. User could have used more ad­vanced au­then­tic­a­tion meth­ods, or even in­teg­rated the sinatra-au­then­tic­a­tion gem, but I thought it was best to keep it simple given the nature of the pro­ject.

The app re­quires you to log in in order to trig­ger the buzzer, but there’s no way to sign up to that. User­names and pass­words can only be entered manu­ally into the data­base. So there­fore, User’s only tasks are to know if in­puted user­names and pass­words cor­res­pond with that is in the data­base:

Like many of my classmates, I’m a bit in love with Sinatra. I know nothing else to compare it to, so it’s hard to give a solid argument why, but I love it for its simplicity and for its ability to teach me how websites are structured. BuzzerApp is rather simple, but it drives home web app structure for me, and gets the job done, which is great.

There are only three pages in the app: login, which authenticates the username and password input fields, success which lets you know you’re in, and failure, which lets you know you don’t have access. It’s simple for a reason: there’s no way for you to buzz in without entering a username and password, because a) there are no cookie sessions, and b) because an instance of Buzzer is only triggered through /login’s POST. The bulk of the app is within login:

Below are the pages rendered by the .erb templates, which could use some styling, although the cats obviously make up for that: