Kristen Faulkner

Today we used Javascript to build Asteroids, which is a game where asteroids float around the screen and you have to shoot at them using an arrow. 

We learned a lot of new things today, such as how to access the .arguments method on a function. In Javascript, unlike other languages, a user can pass in as many arguments as they want into a function, and even though the function won't use them all, it will still store them in an array-like object that is accessible by calling FunctionName.arguments. This is very useful for binding, currying, and callbacks.

Another thing we learned today is how to implement prototypal inheritance using Javascript. Because Javascript does not have real Classes the way Ruby does, objects in Javascript are just functions. In order to make a class "inherit" from another, we have to create an intermediary Surrogate class and set the subclass.prototype to an instance of the Surrogate class. This allows the subclass to inherit all the methods from the superclass without being able to alter the superclass itself. 

We also learned about currying, which is when you call a function by passing in one parameter at a time. For example, instead of writing f(a,b,c,d), you would write f(a)(b)(c)(d).

Today we implemented tests using RSpec and Capybera. Good developers use TDD (test driven development) while they are building their apps in order to make sure that their app performs all the functionality it is supposed to (and catches all the edge cases). We use Capybara to simulate the way that a user would interact with our app: clicking buttons, visiting links, submitting forms, etc. Capybara is an example of Behavior-Driven Development (BDD) because it tests based on a user's behavior, not the internal structure of the app.

Capybara is also a great way to conduct integration testing: making sure that the app works as a whole and that all the pieces connect in the right way. This is the opposite of a unit test, which tests one piece of the app in isolation. Capybara lets you conduct several browser actions in sequence, letting you test the same part of your app in different ways.

For example, you could write a test that expects to see a welcome screen on the index page if a user isn't signed in. You could write another test that 1) signs in a user and 2) expects to see their username on the index page. You could write another test that 1) creates a user, 2) logs out that user, and 3) expects to be redirected to the index page, which tells them they have been logged out...you get the picture. Integration testing tests features that use many pieces of the application.

The opposite of integration testing is model testing. Model testing, also known as unit testing,  tests the various components of our application in relative isolation. 

In the real world, unless you're working on a huge app, integration tests tend to be more prevalent than unit tests.

Today we had our assessment on OAuth. Its amazing to think that we did in 1 hour today what took us a full 2 days to build just a week ago.

We spent the afternoon finishing up RailsLite and FriendsCircles. We read about polymorphism, which is when a model can belong to more than one other model. We also learned about inverse_of, which has to be added to has_many/has_one/belongs_to associations.

Inverse_of's job is to let objects know that they're associated to one another. It is implemented like this:

class User < ActiveRecord::Base has_many :addresses, :inverse_of => :user end

Today we implemented a lot of the functionality of rails. We used WEBrick and set up our own Controller Base and then implemented template rendering, parsed our parameters from querystring and regular expressions, and rendered a session. We finished off with routing. 

We also learned about mass assignment. Mass assignment is when you write Model.new(:attr1 => :val1, :attr2 => :val2). It is most commonly used with forms.

Today we did a solo project called MusicApp which gave us more practice with OAuth. In the app, users can sign in and create new bands, which have albums, which have tracks, which have lyrics. The user can then visit different urls that correspond to each album, band, or song. 

Mostly, it was the same material as 99Cats, except that we had only one day to complete the project instead of 2 days, and we didn't have any partners this time. On Wednesday, we will be expected to implement a similar website in < 2 hours for the assessment, so we just need to get comfortable doing the exercises over and over. 

Today we continued to work on 99Cats. Primarily, we focused on sessions, authentication, and cookies. 

As of now, users can sign up for the site with a username and password, upload their cats, submit rental requests, and accept rental requests from other users. User also have an account page where they can see all their current listings, rentals, approvals, and cats.

Before implementing user accounts, we first had to understand how cookies work. Cookies are little packets of information that are sent with each http request and store data about a user's browser session. The information can be stored in instance variables and used to reference a particular user's information. This is particularly useful since http requests don't talk to each other and local variables die after each http request. To solve this problem, we create a session key each time a user signs in, and we use the session key to reference their cats and account information.

Today we implemented 99cats, a website where users can upload their cats to rent out.  We learned how to use html tags, make tables, submit forms, and pass user inputs as parameters for actions. In Rails, people often talk about "MVC" which stands for Model, View, and Controller. Theses are the three different files that needed to be created to make web applications.

Today was our second day working with Rails, and we built a blogger that allowed users to create contacts, share their contacts with other users, see where they had shared contacts, and post comments to other users' accounts. We learned about creating RESTful applications, which means that an application's resources/actions should all follow CRUD syntax (Create, Read, Update, Delete). CRUD actions are the 4 ways a database interacts with the server, and following CRUD conventions (as opposed to making custom actions) makes applications much cleaner.

Today we coded by ourselves and built our own lite version of ActiveRecord. Afterwards I gained a better understanding of how Active Record works and how Active Record is translated into SQL.  We used define_method to create our own version of attr_accessor. We did this by using instance_variable_get and instance_variable_set to create attr_reader and attr_writer methods. We also wrote getter and setter methods for the table_name. 

We created a SQL object and wrote our own versions of ::all, ::find, #update, #save, and #insert to interact with the database. We stored all our variables in a hash rather than as instance variables. 

Since Active Record automatically creates intelligent default names for classes and models, we also wrote methods that populated names in a similar manner. 

Today we used Active Record to implement Polls, a project in which users can ask create polls with questions and responses. 

We learned about Active Record relations, and how the contents of a Relation are not fetched until needed. In programming, this is known as laziness, and it can save running time because queries are not evaluated until they are necessary to be used. 

We also discussed the "N+1" problem, which occurs when you make a "__.each" call to a query. Each time you make a query to the database, it takes up memory, so it is better to fetch all the contents at once, cache the result in memory, and then iterate through the results that way. Active Records provides an :includes method which makes it easy to do this. 

Today we learned how to use Active Record, which is a Ruby language for interacting with Databases. ActiveRecord is a type of ORM, which stands for object relational mapping. ORMtranslates between SQL records and Ruby objects. As an ORM, ActiveRecord creates a Ruby object for each row in our SQL table. It accomplishes this by requiring a model class for each table in the database. Each row in a table represents a model of the instance class. For example, a “Cars” table (model) would contain rows of “cars” (instances of the model class) and each row (instance) would represent a “car”. 

With ActiveRecord, when we query items from our Database, they are returned as Ruby objects that can easily be manipulated and worked with. We can easily use *find, *count, *where, and other commands directly in our queries because our queries interact with objects. 

Today we wrote a basic version of Quora using SQLite3, Heredocs, database queries, Object instances, and more.

We first created a database with tables for users, questions, replies, followers, and likes. We then populated the tables and set up all the query methods to receive data from the tables. 

We learned about Singleton classes and why they are so important in SQL. Singleton classes allow us to store only one copy of the database, which is helpful because it ensures that we don't accidentally create different instances of the database and have multiple versions floating around. It also ensures that we don't have multiple queries all trying to update different implementations of the database. 

We used SQLite3 this morning to implement our SQL commands. SQLite3 is a software that processes SQL commands. Unlike other implementations of SQL, SQLite3 doesn't require a server. This makes the set-up very simple and fast, but SQLite3 does not scale well with larger data sets. 

This morning we learned how to write heredocs, which are multi-line SQL strings that can be embedded inside Ruby code. There are two different ways to implement heredocs: 1) the first is to set a variable to the SQL string such and call the variable later, such as

query = <<-SQL SELECT * FROM posts JOIN comments ON comments.post_id = posts.id SQL db.execute(query)

The second way is to call db.execute above the SQL code like below. Doing this ensures that the <<-SQL part is replaced by the SQL string below it. 

We started off today by taking assessment02. It was a game of Crazy Eights in which we had to implement some play_card methods, and I think it went well.

Afterwards we began studying SQL, which is a language for querying, manipulating, and receiving information from databases. We used SQLZoo to learn the basics such as SELECT (item) FROM (table) WHERE (condition). Later in the day we learned more complicated queries such as JOIN for joining multiple databases together, GROUP BY to change how we arrange our data, UPDATE to update a database, CREATE create one, and some other calls as well.

We also learned nested queries, which are when we call a query inside another larger query. Nesting allows us to use the result of the inner query as a parameter for the larger query. It was similar to nesting in Ruby, which we are familiar with.

When implementing a nested query, it is sometimes necessary to rename each query result (version of the table) with a different name so the queries don't get mixed up when they call the same table in different contexts.