Monkeypatch Chronicles

Took the exam in the morning. Passed. Finished off the snake game, and moved into the spaghetti of callbacks that would become my dream journal app. 

It's quite pleasing, with all sorts of nice CSS effects. The back-end, however, is a bit of a mess. I've got a mass of asynchronous functions that depend on callbacks to populate the page elements.

For my first time working with AJAX, it was an ok effort. You can add, remove, and edit dreams on the fly while remaining on the same page. When you add a dream via the form, it's saved to the database and the dream panel populates with your new dream without refreshing the page. Likewise, you can select a dream to edit from the dreams panel, and it'll populate the dream details in the form. The interface is pretty slick, with friendly hover states and lots of attention to detail. 

Finished off the Tic Tac Toe, and about 3/4 of the way done with a browser-side snake game. Learned about closures in Javascript, and how functions carry a scope object in which they can refer to attributes on the function that called them. Makes for some powerful ways of manipulating local variables bundled higher up in the call stack.

Javascript has three basic ways of calling functions, and in each of those ways the state of self (this) is different. It is possible to explicitly set the 'this' binding by way of bind, or by using closures (assigning 'this' to a local variable 'that' at higher level and calling 'that.whatever' in lower level to access the state of the upper level function.

The basic types, however, are these:

global-style ('this' is window)

function hello( ) { THIS } hello( );

THIS = window

method-style ('this' is object)

var dog = {   name: "Fido",   bark: function( ) { THIS } } dog.bark( );

THIS = dog

class-style ('this' is object created from constructor function)

var Dog = function (name ) {   this.name = name; }

Dog.prototype.bark = function( ) { THIS };

dog = new Dog( ); dog.bark( );

this = Dog THIS= dog

The brunt of today's work, however, was in the evening's review of advanced Rails architectural concepts. As earlier in the week, we spent a ton of time really getting into the nitty-gritty of how Rails interprets nontrivial requests from a form, routes it to the controller along with the params, and how the associations, validations, and custom macro-generated constructor methods in the model parse the params to save and update records in the database.

We ran though drills and whiteboard exercises with each other to really drive the understanding. I can now make forms just as fluidly in HTML and ERB as with Rails' provided form helpers. I can read off a params hash like a second tongue. I know my way around active record associations, aware of which attributes are implicitly defined, and can wield and break them as desired. I can make forms that create nested objects and froms that invoke joins between existing objects. I can break down ActiveRecord queries into their SQL. I can create methods myself directly in the models if I don't feel like using the macros.

JQuery is like Javascript's hipper cousin. It's from the same lineage, yet infinitely more slick. Of course one's general purpose and the other is for DOM manipulation, but you can't help but compare the two. Today we built graphical web browser games Towers of Hanoi and Tic Tac Toe.

My partner Luke and I completed Towers of Hanoi by about the middle of the day, but we spent another two hours making it more object-oriented and debugging the resulting errors. With a little over an hour left for Tic Tac Toe, we started making it object-oriented from the get-go. Progress went fairly quickly on it and the game was almost finished by 6pm.

Today we jumped into Javascript. We re-implemented a bunch of our first-week's Ruby exercises in Javascript. It was unpleasant at first to do make way without Ruby's conveniences. We build our for loops by hand, worried about a misplaced semicolon or var declaration, and did all we could to prevent ourselves from sliding into the more natural snake_case naming conventions. But, as we went along, my partner Mark and I got into the groove of it. We wielded prototypes, lambda-like anonymous functions, and nested for loops like old pros.

As promised, today was the second half of our exploration into the heart of Rails. Building on our foundation of a baby ActiveRecord, we worked up a mimic of Rails' routing mechanism. Now, normally, Rails is built on Rack, which interfaces with whichever server we choose to connect. For our project we built directly from the Webrick server, which is commonly used in our development environment.

3rd straight day of solo work. This whole week has been building variations of Rails projects, so today was a nice change, as we did something a bit more technical. Our old friend meta-programming returned for the day, and it was a welcome sight. The task was to build an itty-bitty ActiveRecord. Exactly two weeks ago, as we were getting up to speed on SQL, we had built a our own ORM, but it was domain-specific and not reusable. Today, we were challenged to build a small framework that could be used to map data of any type from the database into Rails.

250,000. That's how many lines of code ActiveRecord encompasses. Far be it for us to judge, but after completing today's project, that does seem a bit excessive. In 250 lines, I was able to implement the following features:

attribute_setters

belongs_to association

has_many association

has_one_through association

find record

all records

where (search records by single or multiple criteria)

save (with update & create, as appropriate)

This was a more advanced form of meta-programming than I had attempted before, having had my dalliances with it all throughout the week as I tried to spruce up my individual projects. When we reached the has_one_through feature, I really appreciated the step-by-step curation of the materials. Up to that point I had ironed out the framework, more or less, on my own.

Solo project today. Normally we get to work alone only on Fridays, but Ned is gifting us several days of alone time this week during the Rails section to ensure that we drive the concepts home. I built an app that authenticates users, and allows them to get newspaper subscriptions. An admin user can create and edit the newspapers and tack on subscription plans on the newspaper when they create it. Users can edit only their own profiles, and must sign in before getting any meaningful access.

I used Bootstrap, like I've been doing for the past few days, and have gotten the site to look pretty good. I'm using more Bootstrap classes than in previous days, and putting more weight in typography. Making clean, default styles, with some tweaking is becoming almost automatic. My display helpers for generating login toggle and flash alert HTML elements, are evolving too, it seems, and come out quicker and more concise.

My notable takeaway for the day was getting comfortable using the debugger within the Rails server. With the power to peek at params, I felt that I had gained a level of independence from asking the TAs for help. If I  had a problem, I worked my way down the stack trace, poked and prodded suspect variables, and managed to fix every issue on my own.

Today, we set about to build a clone of Y Combinator's Hacker News. My partner, Eric, and I started from the bottom, and spent a good deal of time setting up some complex associations on the models. It was not a very agile way of going about things, I guess, as our approach had pretty much set the architecture in stone. Most of the complexity came in trying to model the relationship between nested comments. We ended up going with an ancestors table that joined the comments table on itself. Our comment model was a beast. Here's what it looked like:

  attr_accessible :article_id, :author_id, :body, :parent_comment_id

  validates :body, :author_id, :presence => true

  belongs_to :article, :inverse_of => :comments

  belongs_to :user

  belongs_to :parent_comment, :class_name => "Comment"

  has_many :child_comments, :class_name => "Comment", :foreign_key => :parent_comment_id

  has_many :comment_ancestors, :class_name => "CommentAncestry", :foreign_key => :descendant_id

  has_many :comment_descendants, :class_name => "CommentAncestry", :foreign_key => :ancestor_id

  has_many :ancestors, :through => :comment_ancestors

  has_many :descendants, :through => :comment_descendants

Crazy, huh? After that travail we proceeded to build the controllers, bake in authentication, and finally work on the views, with our first-ever implementation of nested forms. I introduced Eric to Twitter Bootstrap towards the end of the day, and we immediately made the site much prettier. I stayed a good bit of time after class completing the views, adding in validations, and refining the look.

Today we worked with cookies, authentication, and sessions. It was hard going for a lot of the class, me included. Not sure what it is about client-side storage that got us snagged, but the TAs were run ragged as each pair pulled them in.

My partner Mark and I muddled through a lot of our app, trying to build out a web store with users, orders, products, and a shopping cart stored in the session hash that could be manipulated only by logged-in users.

We kept coding what we could, but, with such a high demand for hand-holding from some of the other pairs, we didn't get enough time with the TAs to validate our direction and complete the project. We'll keep revisiting these concepts over the course of the week, so I'm not worried, but it nags me that we didn't finish.

Solo day today. I made an app that allows teams of users to allocate projects and mark down completed items. It's fancier than my last couple of Rails apps. I've been incorporating all sorts of recently learned things like nested routes, local variables passed in partials, dynamically generated tab titles, styling with Bootstrap, flash notices on validation errors and successful transactions, and, my favorite, metaprogramming.

So here's the thing, Rails form helpers are great-- but they fail woefully when it comes to check boxes. In some cases a single check box suffices, and Rails has accounted for those cases (albeit in a clunky fashion). Many times, though, you'll want a whole bunch of check boxes all relating to a single entity, say friends to add to a group message. Rails forces you into a lot of legwork to implement this.

What I was looking for was a check box field. Since Rails didn't have a form helper for that I created my own. But first, let's look at what Rails would have made me do without my helper.

First you have to wrap the check box tag in an iterative loop to get at the object you'll be using to make it. You have to manually pass the check box name, infer the check box value from the object's id, do an expression to set default checked status, and build up an id for the checkbox. Then you lop on a label to match to each check box, and once you're out of the loop, add in a hidden sentinel field to ensure that the values are updated

Assume that we're in the users/edit view with @user object passed as a variable from the UsersController. The name of the model is User.

<% User.friends.all do |friend| %>   <%= check_box_tag (     "user[friend_ids][ ]",     friend.id,     @user.friend_ids.include?(friend.id),     id: "user_friend_id_#{friend_id}"   ) %>   <%= label_tag "user_friend_id_#{friend_id}", "friend.name %> <% end %> <%= hidden_field_tag 

Yowch. That's some tedious code. With my helper it condenses down to:

<%= check_box_field :user, Friend, :name %>

Man, time flew by this week. I've been really enjoying working with Rails as we step into more and more complex stuff. My partner Steven I and hit the ground running as soon as we pulled up the project. We popped out the models and migrations with all associations in about 30 minutes.

Then the requirements changed!

This is not unusual. Throughout the day, as we work, the lesson plan is being updated in real-time. Whether it's clearer requirements, or more interesting problems, or bonus assignments, there's aways a healthy chance that the project instructions page will look different when you refresh it.

In this case, we were making a music app, which was initially tracking artists, bands, singles, and recordings (one single may have many recordings). After being setting up the back-end entirely and being well satisfied with ourselves, we refreshed the instructions page. And, BAM, it was time to recycle our work. We considered, for the briefest moment, starting from scratch, but we didn't put much heart in that. The new requirements were close enough to try to hack and meld them into our existing framework.

Now we were set to be tracking artists, bands, albums, songs, and tracks. With some carefully checked migrations and some thoroughly nit-picked model associations, we did what had to be done and brought our back-end up to spec. I found the experience educational. Would not be surprised at all if the instructors intentionally did not announce that they had switched the requirements-- how else are we supposed to learn how to work with migrations to fix your database schema if we're not thrown for a loop then and again?

Over the course of the day, the project instructions grew at a rapid pace. The scope must have doubled or tripled by the end of it, with all the bonus stages. With the way my partner and I approached the project, we actually ended up crossing several of the plateaus before they were ensconced as official bonus assignments.

One of the really great things I used today for the first time were nested routes. These gave me the power to pass attributes from one page to another in a RESTful fashion with hardly any effort. These came in handy when when one of our views would be called upon to update the model of a different type of entity, say a Band page that allows you to create a new Album (and ensure that  the newly created album  is associated with the band).

Another interesting topic we handled was the mystery behind check boxes. Of all the form objects in Rails, check boxes are the least straightforward. To make Rails treat a set of checkboxes as part of a single entity, we need to pass an array on a hash in the checkbox name attribute. However, we also need to safeguard that that hash gets picked up in case all check boxes are unchecked. The mechanism for that is to set a hidden field with an empty array to act as the sentinel. Pretty hacky stuff, but it was the best Rails could come up with when reconciling the limitations of HTML.

Finishing up most of the bonus stages, I left class at a reasonable hour to play my customary Thursday basketball. Had a good round of gritty, hard-fought games. I played hard like I always do. In the last game, a 3 on 3, I took an overly ambitious shot when we were down by 6 with only 3 more points for the other team to win.

It was a no-look hook, which I make sometimes, but not often enough to justify in critical game-time situations. It felt right at the time. One of my teammates called me out for taking such a shitty shot, for not caring enough to take a good look at the basket, and, flustered, he lagged on his defense. Wham! The other team scored.

I didn't change my strategy, didn't get angry, and pushed my indignation for another time. My teammate didn't know me well enough to know that I care all the time. I kept doing what I do, grabbed every rebound, set solid picks, made outlet passes. On every play, I worked like a beast to get my teammates into good spots, to close in on help defense, to box out for every board. We scored every remaining point in that game, and I had a hand in creating each of those buckets.

Today we did two projects to get acquainted with Rails' top layer of controllers, routes, views, layouts, and assets. My partner Ian and I breezed through the first project, as we had both done it before. As we were just following step-by-step instructions from a Jumpstart Labs tutorial to build a Blogger app, I don't feel either of us gained much more from that particular project than a refresher of familiar haunts.

Interestingly, after honing our chops these last few weeks, we were spotting several poor design decisions in the tutorial itself. For example, in one of the models the tutorial was querying an entire Tag record, when just the name attribute would have sufficed. Also, we were slightly disappointed at how much hand-holding the tutorial did with authentication. Not to worry though, we'll have all the authentication we can handle when we roll our own over the weekend, as we run through Hartl's Rails Tutorial. 

The second project, however, was more challenging. With an hour and a half left in the day, we began building a Rails application to allow people to lend and rent cats, because why not? It took us a good 50 minutes to implement the back-end, not super fast, but we executed the architecture to be smooth like butter. Three tables. Perfectly normalized, with flawless associations appropriately aliased on the following entities: cat owners, cat renters, cats, and rental agreements. Validations both at the model and database level, and indexes on all important fields for faster querying.

To get the aliasing to behave, we had to buck Rails conventions and explicitly configure ActiveRecord to be more descriptive of our domain. Even though we had one users table, the real entities were cat owners and cat renters. To model our custom associations, we told ActiveRecord precisely which foreign keys and tables we were looking for. The act of making ActiveRecord play nice sharpened our own understanding of the relationships between all the entities.

We worked some on the front-end too. The instructors had us implement HTML forms by hand. Sure, we know that Rails has plenty of form helpers, and, to go even further, there's a gem SimpleForm to make form creation even easier. Having us do it by hand was intentional, and a recurring pattern in the course. Our lead instructor, Ned, recounted his own practice, in a statement that will stay with me:

Always know things one level deeper than the level you normally work with on a day-to-day basis

Today we took a serious dip into Rails' ActiveRecord. Yesterday we had learned enough to muddle around a bit. Today, we've been harnessing the kinds of features and patterns we'll implementing throughout our careers.

Some of the key things we worked with today were scopes, class helper methods to observe the "Law of Demeter", includes to cut down on excessive querying, validations (including custom ones), indexing, and  model association aliasing to link our code semantically to a domain.

Rails is smart and will try to connect things for us. It'll guess at correct foreign keys, and will look at table columns to dynamically generate finder methods. A beginner can be lulled into a sense of complacency and spend a long time never straying from the default conventions. This is bad. A very, very bad, no good sort of thing.

So, we've finally made it to the point a lot of us have been waiting for. Today we did our first Rails project. It's a URL Shortener that runs from the console and makes use of a tidy database and ActiveRecord. My partner Mark and I spent a bunch of time up front crafting the database to ensure that all the data was normalized.

We came up with tables for users, links, short urls, long urls, comments, tags, and taggings (a join table to map the many-to-many relationship between tags and links). Pretty good foresight on our part, as more than a few pairs muddled up in their architecture before the instructors set them straight. Heck, even we had to do a little modification, breaking our original links table out into separate tables for long urls and short urls. 

On Rails, after 3 weeks of anticipation, we got our feet wet with Rake migrations, gemsets, ActiveRecord dynamic helpers, ActiveRecord selectors, attr_accessible macros, relationship mapping macros, and navigating around parts of a Rails project's general file structure.

I made a baby on Friday. A little tyke who looks suspiciously like Active Record, though he’s missing a few key features like finder methods generated from table relationships, friendly database migrations, and attr_accessible macros. Other than that, a perfectly healthy, though highly specialized, ORM framework. As it was a solo project, I can claim full parentage.

Built his guy from scratch, forming its bones in a database schema, seeding it with a speedy seed file, and linking each table to an object model. Inside each model, like a sinewy tissue, I’ve woven in a bunch of attributes to represent columns and methods to invoke database queries. The end result is my very own Object Relational Mapping framework which can be used for interacting with a database of chefs, restaurants, critics, and reviews. You can add and save records and run a collection of simple and complex queries with baked-in methods. 

Building an ORM of our own twice, first on Thursday, then on Friday, is serving as great preparation to understanding how Active Record works. When we start Active Record and Rails on Monday, we’ll already be familiar with the general flavor of the magic under the hood.

Also did some meta-programming over the weekend as a bonus, making a parent Model class from which each of the other table-linked classes inherit. By grouping the initializers and common methods like find_by_id together in the Model class, we tighten up the code by a lot.

When dealing with metaprogramming the most important thing, it seems, is to culture a firm understanding of what object “self” is referring to at any given time. I’m not there yet intuitively. But I’ll get there soon enough, with practice.

I've mentioned before how ugly I find SQL. It wouldn't be far from the truth to call it a pig of a language. Today we put a dress on it and painted it with a coat of lipstick. How, you may ask. Well first, we made classes to model each table in the database. Then, by clothing the raw SQL queries in warm, toasty HEREDOCs and wedging them into methods on the model classes, we made the queries more bearable-- cute little painted oinkers rather than fat, sloppy hogs.

Today I worked with Ian, and we did a great job. We were one of the few pairs to complete the entire assignment before official class end at 6pm. Our working style was fairly balanced, with each of us doing a similar amount of driving and navigating. It was low pressure, and we got some good laughs from our seed data, which we engineered to populate the users table with characters from "The Big Lebowski". It was quite fortunate that we chose that movie, because the multiple Lebowskis allowed us to test our search_by_name queries properly.

Another helping of broccoli today-- after two days of RSpec, today's fill of SQL was no more pleasant. It's a week of finding small virtues, in which we make inroads into the lesser-loved parts of programming: testing and database queries. The last three days have not been as enjoyable as other topics in the course, but I know it's essential learning. There's immense value in becoming familiar with the building blocks of reliable programs via RSpec test coverage and in developing a deep understanding of Rails ActiveRecord internals via SQL.

Much of the day was spent  completing the exercises on SQLZoo. I allowed my partner to tackle the majority of them so he could get practice. I mostly provided validation, with the occasional correction. As the queries got tougher in the second half of the day, I started taking on more of a solving role. By the end, there were problems that were legitimately stumping me, and my partner and I had to think pretty hard to get through them. Subqueries upon subqueries on multiple joins makes for some hairy queries. We labored through, but, man, it was draining. We felt like we were fighting the SQL language rather than prodding for solutions.