# App Academy Diary, Week Four

Originally published: 2013-10-07
Canonical URL: /2013/Oct/app-academy-diary-week-four/

_Monday 7 October 2013—_ The main part of SedentaryRecord went pretty smoothly. I like my one-liner implementation of the `has_many_through` association better than the instructions' suggestion of writing a whole new query template; the TA Patrick pointed out that my version is inefficient (firing off two queries rather than one), but instead of writing the query-saving long version right away, I decided to try implementing validations first (one of the suggested extension ideas). That didn't go well at _all_; I spent a lot of time ineffectually hacking away at the problem but didn't even come up with anything worth committing!

_Wednesday 9 October 2013—_ I did poorly on the assessment yesterday. There were eight SQL queries to write; the first five were trivial, but I bombed the last three because [I'm a moron](http://zackmdavis.net/blog/2013/08/im-a-moron/) and didn't remember that the keyword for filtering aggregations was HAVING. I worked with _William Ott_ on an ice-cream finder (which uses Google Maps APIs to print out directions to nearby ice-cream) and a Twitter client. Of course, it simply wouldn't do to write an ice-cream finder without using it to find ice-cream, so after class we took one of our program's suggestions and bought ice-cream at the Häagen-Dazs in the mall on Market and Fifth. Today I worked with _David A._; we learned about routers and controllers.

[![Our Cat for Rent]({static}/images/our_cat_for_rent-129x300.png)]({static}/images/our_cat_for_rent.png){: .alignleft }

_Thursday 10 October 2013—_ Dear reader, suppose [yet](http://zackmdavis.net/blog/2013/09/app-academy-diary-week-two/#sunday) [again](http://zackmdavis.net/blog/2013/09/app-academy-diary-week-three/#saturday) that you're working on the great American dog-sharing site—_loser!_ Sharing dogs is _so_ last week; you should have predicted that by now, everyone who's anyone would be renting cats instead. That's why today _Dean Yang_ and I used our prodigious knowledge of not just models, but also both views _and_ controllers, to make a mock cat-rental site! It's like this: say you visit the URL for the page that displays all the cats. Your browser issues an HTTP GET request, which is handled by the Rails router: an instance of the `CatsController` is spawned, and its `index` method is called, which puts an array of `Cat` objects (instantiated by the ActiveRecord ORM from their representations in the database) in an instance variable, which is then made available to a process that uses a template to decide how to express the information about the cats in HTML, which is then sent back to your browser. Similar stuff happens to let you make a new cat, or edit an existing cat.

_Sunday 13 October 2013—_ On Friday I worked with _Nathan Holland_ [again](http://zackmdavis.net/blog/2013/09/app-academy-diary-week-two/#wednesday); we added users and authentication to the cat-rental site! It's like this: in the app/config directory of the source repository there lives a file named _routes.rb_, which which tells Rails what to do with requests! Like, _routes.rb_ contains a line that says "`get 'login', :to => 'sessions#new'`", which means that if someone issues an HTTP GET request to /login at our application's domain, that what happens next is determined by the `new` method in the `SessionsController`. As it happens, all that does is send back the log-in form generated from the template at app/views/sessions/new.html.erb. When the user submits the form, a POST request is issued to /login, which gets routed to the `create` method in the `SessionsController`! That does a few things. First, it tries to find the user in the database using the supplied credentials (username and hash-of-password). If that doesn't work, it shovels a friendly incorrect-username-or-password message onto `flash[:errors]` and renders the log-in page again (including the message from the `flash` hash). But if the user _was_ found, then it logs them in by setting their session token, storing their current-user status in an instance variable, shoveling a friendly "Logged in from #{location}" message onto `flash[:messages]` (the user's location can be determined using their IP and the [Geocoder gem](http://www.rubygeocoder.com/)), and redirecting to the page with all the cats!

Having accomplished this feat, Nathan and I spent a lot of time trying to push the application to [Heroku](https://www.heroku.com/) so that we could test things like how to handle a user being logged in on several devices at once, but Heroku dislikes SQLite, and various attempts at troubleshooting the issue all failed horribly.