Ruby (Every) Day

We celebrated our final day of pairing (and the JavaScript curriculum), by making a simple chatroom server in Node. Matt and I made a "badass" themed chatroom, complete with nigh unreadable gothic font on the h1 and dark, brooding CSS. Needless to say, it was fun.

I remember struggling a bit with making a basic server in Rails, but yesterday's exercise with Node flowed much more smoothly. We ventured into some pretty cool territory, dealing with concepts like single and multi threading, sockets, and the differences between synchronous and asynchronous code.

Over the past few days we've been working on our first meaty backbone project, a clone of the organization app Trello. The point of this project was to really dig into a full project with Rails backend and a Backbone client side MVC. Also, we got to make it look all spiffy with Bootstrap. This was for me one of the most frustrating projects of the course, but also one of the most valuable. Here's why: struggling with code you don't understand makes you understand it.

When I began the project on Friday, I still had a fairly incomplete picture of Backbone in my mind. I knew most of the main pieces, but I certainly didn't have any level of fluency with the framework. Because of this, I kept things simple. Write models, views, and the router, and some basic templates to render the information. When it came to nesting information about things like lists in the board template, I would just iterate over the collection and insert the desired attribute values into the template. Nice and easy to understand.

The problem with this approach reared its head when I got one level deeper, to cards. Cards live inside lists, which live inside boards. Now what do I do? Do I go back into the board template and begin iterating through cards inside the list loop? It became clear that I had to extend the Backbone view class and make a composite view to contain subviews.

This was a very, very frustrating refactor. I spend the bulk of my weekend re-writing most of the project to utilize this new class, and it was slow going. I hit lots of conceptual walls (often having to go around them rather than through), but after completing the updates I have a much better understanding of this solution. And of Backbone in general, too.

Yee and I had a most excellent time today Bootstrapping MopBeat, an app for selling 24th century cleaning products to Hipsters. Bonus feature: a search bar that auto-populates, but only with US State names. The uses of this feature are so obvious that I don't need to go into detail here ;)

Bootstrap really is amazing. Professional-looking style for your elements in minutes. I can't wait to get acquainted with the framework and churn out some awesome looking sites.

Building off yesterday's introduction to Backbone and an extensive video series by Ned, today we build an RSS app. This allowed us to dabble in modeling relations on the client-side with Backbone.

On the backend, we use ActiveRecord associations to relate objects.

class Feed :destroy ... end

With Backbone, relationships are established between models by writing a function on one model that creates a collection.

entries: function () { if (!this.get('entries')) { var feedEntries = new NewReader.Collections.FeedEntries([], { feed: this }); this.set({ entries: feedEntries }); } return this.get('entries'); }

Sidenote - My brain has been steeping in JavaScript for the past week, so I keep trying to put semicolons at the end of ruby lines.

Another neat thing we learned about are "zombie views,"

photo credit: https://coderwall.com/p/jrnuiw

...or Backbone views to which listeners are still attached. Because the listeners are still waiting for the appropriate trigger events to render the view, these wayward views cannot be garbage collected. This memory leak can lead to reduced performance as more and more renders for the zombie view stack up over time.

The solution is to write a _swapView method:

_swapView: function (view) { this._currentView && this._currentView.remove(); this._currentView = view; this.$rootEl.html(view.render().$el); }

Today was the first official day of Backbone.js instruction, although we had a torrent of readings and videos over the weekend as primers. At first look, the Backbone library seems like a lot of material. Built on top of Underscore.js, Backbone allows us to easily write and organize client-side MVC. After only one day of working with it, I've realized how awesome the library is, and how powerful it can be when combined with the jQuery we've already learned.

Our intro project for Backbone was a journaling app. We started with a simple structure - a post model, a router with a link to the index root, and an index view. From this basic skeleton we built up the full CRUD set of RESTful resources.

We implemented my favorite feature of the mini-app at the very end of the project. Instead of one single div element, we split our ERB template into a sidebar and the main page. We then rendered our Backbone index EJS template as a sidebar, and our individual posts as the main page. Because of Backbone and the underling AJAX, clicks on index links replaced the main div of the DOM with the requested post. It really felt like a web app.

This is our last full week of instruction, and it began with some great news: we won't be losing any more students to attrition. Everyone performed brilliantly on the JavaScript assessment, and now we're on to Backbone.js, a JS library for implementing client-side MVC (MVP, MV*?).

Our project for the day was a photo app - uploading and tagging - fairly straightforward. Armed with our knowledge of Rails, it would be easy to bang out some models, controllers, and views, a set of RESTful routes, and a nice simple HTML form to collect the photo information. But now, with AJAX and JQuery thrown into the mix, our goal was a page that could create database entries, and then display that data without having to refresh.

The JavaScript that we wrote wasn't quite Backbone... more like a precursor. A few weeks back we had a project in which we made a Polling app, but we didn't have the luxury of using ActiveRecord. Instead, we had to write tons of embedded SQL queries to fetch our data. The point of the exercise was basically to see how much boilerplate AR saves you. Our Photo app project had the same goal - make it clear how nice the Backbone library is.

First, the cool part about today... we made retro dayglo JQuery Tic-Tac-Toe!

Alright, now that's out of the way. This week has honestly been pretty tough. I'm not sure why, either. App Academy's pace has been near breakneck for most of the past six weeks, but the JavaScript curriculum in particular has been doggedly resisting my attempts to comprehend it. The general concepts aren't necessarily difficult, and in fact I can explain most of them in english quite well. What I'm lacking is a good solid grasp of the syntax. My brain can think the solutions, but my fingertips fail to implement.

Awesomeness. Today we made a JavaScript browser version of the game Asteroids. Even awesomer? This version of the game made by a former App Academy student. The project was really fun, and also a great way of solidifying many of the JavaScript concepts from this week.

Day two of the JavaScript curriculum, and we're moving pretty fast. The pace makes sense, since we already know a good deal of Ruby. JavaScript has some pretty major differences though, especially in its handling of functions and overall design patterns. One of those design patterns, callbacks, was a major part of our work for the day. And we very nearly ended up in callback hell.

In Ruby you can have one method call another, accept a return value, and continue on. JavaScript callbacks, on the other hand, cannot return values back to the function that called them.

Trying to implement a basic Towers of Hanoi game today, we ended up trying to use callbacks in a Ruby-ish way. One function would prompt the player for input, and then pass that input to a callback function. But then we tried to have those callbacks return booleans for the original prompt to use. We called Ned over, and he informed us that we were entering "Callback Hell," a development spiral where you add copious callbacks in an attempt to fix broken code.

Concepts of the Day

JavaScript

Syntax: semicolons, var, return

Closures, IIFEs, function-level scoping

Passing in functions to other function calls (whaaat?)

Reinforcing fundamentals

Recursion, recursion, recursion, base case!

Object orientation

The curriculum is dead. Long live the curriculum. We've moved from Ruby to JavaScript, and while adjusting to the new language has been bumpy, I'm actually quite enjoying it. The (many) idiosyncrasies of JS are well documented, meaning that most gotchas can be avoided by reading up. However, there are still a few weirdnesses that tripped me up today, like concat not modifying the original array.

Concepts of the Day

Behavior Driven Development and Capybara

Polymorphic associations

Concerns

Sticking it out

Yesterday's project was an exercise in not getting discouraged. That, and reverse engineering problems.

We were tasked with writing a goal organization app that modeled users, goals, and comments. Not too difficult to wrap one's brain around. However, this project stipulated that we use Capybara to build top-level tests and adhere to the work cycle of behavior-driven development. Write some tests for a feature, run the failing tests, then implement the feature to pass them. Red, green, refactor.

This was all well and good for the authentication unit tests. Then we moved on to the feature tests like clicking links and filling out forms. Enter FactoryGirl. She walked into our lives with a confident stride and glint in her eye that was immediately appealing.

"Don't worry about lengthy spec_helper methods," she coyly suggested. "I can do all of that work for you."

So, succumbing to her charms, we threw some FactoryGirl test objects into our feature specs... and everything broke. Uniqueness validation errors everywhere. We spent the afternoon manually clearing our the test database and trying to debug the tests. Never got close to finishing the project.

It was Friday, time to cut our losses and move on to socializing and self-congratulations for a hard week, right? Wrong! Time to down a Rockstar lemonade, grab a box of cheez-its, and finish that shit!

At Will's suggestion, I included the database cleaner gem, and learned how to configure it to wipe the test DB between individual tests and also after the full suite.

There are only ever two Sith, a master and an apprentice... and their names are Patience Becker IV and Augustina Quigley. Fierce names. Names that would strike fear into any citizen of the Galactic Republic. Of course these names are Fake(r), and were used to demo Test Driven Development in Rails, using the FactoryGirl and Faker gems.

I really do enjoy the mental image of a Sith Lord named Patience Becker with force lightening radiating from her fingertips.

"Lord Becker, we've located the rebel base..."

TDD is an interesting beast. I'm still working on mastering the syntax of RSpec and Capybara, so writing my tests is far from fluid. But I can totally see how the red, green, refactor work cycle would be enjoyable. Writing tests sets up the expected functionality and lets you work towards a short-term goal. Then, when you have those tests passing, you can refactor and be assured that the behavior of the code is the same. (And if you break something then you'll know right away.)

Auth

I've written a simple auth so many times now that I was dreaming about it last night in my (heavily fragmented) sleep. I suppose that's the whole point of intensive practice though. Get to the point where you can literally do it in your sleep.

Make a User model that validates a username, password_digest, and session token.

In this model, write methods for encrypting a password to a hash, comparing a hashed password with inputted plain text, and setting the user's token.

Make a users controller with CRUD actions.

Make a sessions controller with CRUD actions.

In the application controller, or in a helper method module, make methods for the following:

sign in a user (set the user's token to session token)

sign out a user (reset the user's token, blank out session token)

return the current user

require a user

Make routes for the user and session creation pages.

Make some other models and routes to link to.

Make views so controllers have something to render.

Profit $$$$$$

Rails seems almost magical when you're starting out. ActiveRecord's customized find methods, routes that are generated simply by the word resources ... wizardry. But today we went a level deeper into how Rails works, by creating our own minimal version.

I found this project to be really fun. ActiveRecord Lite had a tendency to be mind-bending because of the required metaprogramming. There were a few challenges like that today, but on the whole I think Rails Lite was gentler. The hardest part was tackling nested hashes in params. I opted for an iterative design, although it will be fun to try and refactor using a recursive solution.

Learning some of the tricks and strategies that Rails employs was pretty neat, and it definitely helped me get a better grasp of the development framework. Tinkering is a great way to understand how something works. Break some code and see what the console outputs. It's like using RNA silencing to make fruit flies grow crazy appendages.

Some of the most interesting topics from today:

redirects work by changing the status and header of a url

binding() really is kind of magical

Ohhhh, and the forwardable trick that Jeff showed me today. This is pretty badass.

Instead of writing methods like:

def [](key) @cookie[key] end

You can use Forwardable module like so:

class FooBar extend Forwardable def_delegators :@variable, :[], :[]= # ... end

One month in already: we've learned so much so quickly, and the time has just evaporated. Though the fact that time is moving at c strikes me as a good sign. I can spend 12 hours a day reading/writing code and not get bored. That makes me feel good about my future career.

It's week 5 now, and we're smack dab in the middle of Rails. The heart of rails. Beginning early last week, we have made some kind of Rails app every day. At first this was to practice and learn the various layers of the framework -- our first projects focused on the model layer, then we moved up to controllers and finally views. In the past couple of projects we've put it all together, making full applications complete with user authentication and authorization.

Auth. A fascinating concept but at the moment an odious term. Each student will be expected to write a full (though basic) app, complete with authentication, in one hour by the end of the week. Bootcamp for sure.

Did you know that web cookies were invented in 1994? It's pretty bonkers to think that the commercial internet is only around 20 years old.

We got our taste of cookies (both literally and figuratively) today. The project was to finish 99 Cats, a feline-themed clone of the bargain fashion site 99 Dresses. By introducing us to controllers, views, and user authentication, 99 Cats rounded out our basic understanding of rails. We now know enough to make full Rails apps.

Concepts

Cookies

Sessions

CSRF and the Authenticity Token

Validation and the Flash

User Authentication!

I think one of the coolest topics from today was how passwords are handled and stored. Keeping plain text passwords in the database is clearly a bad idea. Instead passwords are encrypted using a Ruby implementation of the bcrypt function. This generates a hash that stores the cost factor, salt, and cipher text. (Mmmmm, salted hash.) When a user tries to log in with a password, bcrypt retrieves the salt and cost factor. It then encrypts the plain text string of the newly entered password — if the encrypted text matches the cipher text, the passwords match!