Pat Wey patwey

let vs. let!

let is a lazy-loaded memoized helper method, meaning that it won't be evaluated until the first time it's called.

let! forces the method's evaluation before each example

described_class

The first argument to the outermost example group:

HTTP Status Codes

2xx Success

200 OK

The request has succeeded
Routes:
- GET index
- GET show

201 Created

Steps

Create app, skipping TestUnit and specifying a Postgres db: $ rails new app_name -T --database=postgresql
Update the Gemfile: Gemfile:
```
gem 'haml'
gem 'haml-rails'
```

Socket.io .send vs .emit

.send

Sender:

socket.send('my channel name', { my message data })

Reciever:

##PROTIP: README Love

READMEs are AWESOME. They are one of the best things you can add to a repo, (other than quality code), to make it look professional.

####Things that make a README great:

A link to the production site on heroku
A screenshot (or a few) of what the app does (This is especially important if you don't have the production app up and running yet)
Directions on how to clone or fork the repo and run it locally (explain it like you're explaining things to a totally new programmer)

From: Recursion

Do you pronounce 'babel' in the same way?

Yes. Of course. Always.

Follow Up Question: Will you now?

Yes.

From: Mary Rose Cook Live Codes Space Invaders

What is one approach you can take from this Mary's code and implement in your project?

Torie and I liked her use of a "Keyboarder," and have since abstracted the event listeners for keyups and keydowns into a Keyboarder object in our project.

We also continued this method of organization throughout our code whenever possible. Asking questions like "should our Slime handle the creation of keyup event listeners?" helped us to delegate responsibilites more effectively.

From: Writing Testable Javascript

Consider the four responsibilities that Rebecca lists for client side code

Did any of the responsibilities that she lists surprise you?

I think the one I've considered least in my past projects was application state, so that was the most surprising.

Do you feel like you mentally split your client side code in IdeaBox and other past projects into these responsibilities?

My personal project at the end of module 3 did not split up these responsibilities at all. I had code that would hit the Github API and deal with presentation & interaction all in the same function. I actually did consider the state of my app at one point in the project, so that dropping an Issue in the same column it was already in would not fire off an API call.

From: Node.js, Require and Exports and Organize Your Code with RequireJS

In the context of Node, what is a `module`?

Modules are small components of an application that serve a specific purpose.

	What are some of the balances and trade offs between different sorting algoritms?

	Stability
	- stable sorts maintain the relative order of items with equal "values"
	- important, obviously, if you value the relative order of your input
	- e.g. merge sort, insertion sort

	Runtime Analysis
	- represents complexity in terms of time (Big-O analysis)
	- trade-off: some faster algorithms require more space, so choosing a slower one might make sense where space is limited