Musings of a JS Dev

Two and a half weeks ago we had to choose personal project ideas. In a fortunate / unfortunate event, there were not enough client projects to go around. Apparently, client projects were typically undersubscribed until our class. In any case, I was forced to go out on my own to come up with cool project ideas. I honestly didn't have a problem coming up with decent ideas. One was a dating app that focused on 'tonight'. Ever had a night when you got off work but you didn't quite feel like going home? This app would allow you in a tinder like fashion to find someone within a mile of you with the intention of grabbing a drink or going on a mini date. Another idea was a marketplace for social currency. The premise being that there are many celebrities out there that are paid tons of money for their social media influence. One such example is Kim Kardashian whom is reportedly paid upwards of $10,000 per tweet because she's so influential on Twitter. The app I was going to build would be a marketplace to facilitate and broaden this market into mobile channels. I had a handful of other ideas like a site where guys bid on a date with a girl (think pageants) and all the money goes to charity. Another was a cohort-based weight loss app where users could band together and set a group goal with a social contract on Facebook. The list goes on.

Even after having all these half-baked ideas I realized the night before we were supposed to kick-off the project that none of these were any good. The point of the personal project was to sharpen our technical skills and building a simple consumer based product wasn't the best way to accomplish that. I thought day and night over the weekend to come up with something more technical and finally Sunday night I had an idea. I had really enjoyed the week our team skipped Ruby to learn about Machine Learning and Python but we had still not covered everything. One of the areas I really want to dive into was recommendations. I peeked around at other Github repos and there was only one recommendation engine on Node to speak of and it was very poorly documented. This was it! Despite my better judgment, I decided to go with this, it was the right mixture of exciting, unknown and useful. I also knew that I could easily build a nice demo to show off the engine and practice my front-end skills.

My journey with the recommendation engine began with a little bit of anxiety. I had only been exposed to machine learning for a week and even at that could barely code much of anything. One of the lead instructors at Hack Reactor, Shawn, told me that at the start I could easily get lost in research so that I should start out by building. I followed his advice and it really helped me get a grasp of the scope of the project. First step was to create an NPM module. 30 minutes later, done. Raccoon 0.0.1 was born. The name Raccoon had come to me as a running joke with my girlfriend and also Zack at Hack Reactor who helped us all fall in love with this random song about a woman being terrified of a raccoon outside her car. I digress. After finishing the creation of a barebones module, I set out to build the recommendation engine.

Shit, I didn't know how! After hitting this minor roadblock I dove into the minimal amount of research to get started. It consisted of watching the Recommendation Engine portion of the Stanford online course on Machine Learning (which I didn't find that helpful) then I dove into the Programming Collective Intelligence book that I had seen as recommended on Quora. This book was a goldmine. All the algorithms were written in Python but it was a great first start. The small anxiety I had related to the project began to slow. After slaving away for a couple days I had coding a basic collaborative filtering engine in Python and ported over the algorithms to Javascript. Great! I'm done! Haha just kidding. The engine in fact worked great but it was not built to scale. Scalability in a recommendation engine is one of the important factors. The thing is that my current implementation was query-based meaning that the recommendations were being created when the user asked for them. Not only that, it used a brute force analysis of every users movie ratings against every other user. If this doesn't sound scalable to you, you're right. I spent the second half of the first week starting work on the demo app for the engine. By the end of the week I had finished a styleless demo which enabled a user to enter in their ratings, enter a name, hit a submit button, and finally receive a ranked list of recommendations. All was well, except I still knew that the solution wasn't something that people could use at any scale (probably not over 100-1000 users).

At the beginning of the second week I had a big decision to make, finish optimizing the current implementation of the engine or scrap it and build something better. I began look around at other top recommendation engines and stumbled upon a few on Github that had found a lot of popularity. One of them was called Recommendable by David Celis. It was easily the best documented and user-friendly of the bunch. Interestingly he used Redis to store the ratings and recommendations. At the time I knew nothing about the benefits of Redis and even less about how to implement it. That said, I knew that other top engines used it and that Twitter used it for extremely demanding read/write tasks like their Timeline feature. I had hit another crossroads. This is where Hack Reactor really came in handy. Not in the advice I got in the moment about how to handle this. But in the advice Marcus had hammered into us from the start about how we should not be afraid to dive into project we know nothing about. And also the mentality I've started to adopt of constantly taking the harder route with regard to coding. Because frankly, the harder problems you tackle, the faster you learn. Also, things often turn out to be simpler than you originally thought.

Wednesday of last week I made the final decision to implement the engine on Redis. My reasoning was that Redis was a much better fit for recommendations because it could read/write at lightning speed (40,000 ops/second) which would enable my engine to build the recommendations on the fly whenever new ratings came in, instead of building them when users queried them. The trek began by reaching out. I already knew a little bit about recommendations now but I didn't know how to build a successful module or useful engine. I looked at all the top recommendation engines on Github and reached out the creator of the top one, Recommendable. To my surprise, David was extremely receptive to my questions. He wrote back a page and half after my first email which I was very humbled by. Here I was a student just starting with Javascript and a senior developer who made the most popular recommendation engine on Github was taking an interest in what I was building. We shot emails back and forth over the latter half of the week and having his support really helped me work through a lot of the struggles of how to structure the app. I kept at it until 3am basically every day last week and by Saturday at 11:30pm, I finally had a full working implementation of the engine (with bugs of course). This week i've been focusing on making it a solid module for other developers to use which involves creating test cases, thorough documentation and an impressive demo app.

Like most things at Hack Reactor, this was an extremely rewarding experience. I felt completely lost and confused on two major occasions but was able to keep moving forward. This project has certainly helped me understand how to be a good programmer and to be autonomous. Thank you to anyone who helped me along the way. Namely the Hack Reactor staff, students and David Celis.

And of course, here are the links to the repos and the demo:

Github of the engine: https://github.com/guymorita/recommendationRaccoon

Github of the demo app: https://github.com/guymorita/Mosaic-Films---Recommendation-Engine-Demo

URL of demo app: http://mosaic.nodejitsu.com

On wednesday the class was finally introduced to Meteor. Meteor is one of the fastest rising frameworks on the market and for good reason. After having slugged through Backbone, it was a huge breathe of fresh air to use a framework that finally felt like it gave us something. Meteor is known as a language that prescribes a lot because built into the framework are lots of philosophies and paradigms that others don't have. By the end of the first day of the sprint my pair, Al, and I had already finished our game. I'll do a brief demo at the end of the post.

Meteor offers a ton of the box:

Fast latency - The screen updates the second a user takes an action. Even if that action should have taken a couple seconds to write to a database. It is able to do this because it replicates much of the server database locally, so the user is able to interact with the app as if the data was stored on the local machine.

Instant page updates - The client is constantly listening to changes server-side so when any change is made, those changes are pushed to the client. This is very evident when you make an app that involves multiple people.

Complete full-stack integration out of the box - With meteor, you can literally write a full-stack app with solid logic and usability, and publish it to meteor.com within an hour, no questions asked. It is that simple. It gives you full access to mongodb without the pain of installing it or writing complex queries. It gives developers tons of publish, subscribe and session functions to create more complex logic.

Meteor is the first framework I've learned that felt painless. Any time Al or I got stuck, we could unstick ourselves within 5-10 minutes. It was pretty painless programming. I know I might be going a little overboard and I realize that it's definitely not the right tool for most problems, but I have to say that I'm a big fan of meteor. In terms of prototyping in Javascript, nothing else can come close. If you don't believe me, check it out for yourself. With even a basic knowledge of Javascript, you could make any of these apps in under an hour: http://www.meteor.com/examples/leaderboard .

Here is our app. It's called Ruins. We started off the project wants to test out Meteor's strengths. We knew we wanted to make a game and one Meteor is notorious for it's ability to instantly render all the actions that occur on the server-side. Looking at some past projects, we came up with the idea of a map game where users would have to guess where a location was. We were off. The core of the was to have a bunch of rare, mysterious locations as the goal and for users to click around trying to find it or get clues from where others were clicking. Having meteor as a framework as a huge nice to have given that we were trying to finish a game in a day. With meteor we didn't have to worry about any backend logic, most it was all taken care of for us. For the maps we looked into some libraries and decided to go with Leaflet because of it's strong features, documentation and integration into Meteor. To make the game feel even more interactive, we wanted it to be such that when you touched a place on the map, you would place a dot of your color on that spot. That way users could constantly see what other people were clicking on and could see their scores in real-time.

Sometimes we have an itch that needs to be scratched. For someone that's new to coding, this happens quite a lot. There are an unlimited number of languages, libraries, frameworks and problems to solve within coding. But alas you can't learn them all. Machine learning has been a completely opaque field to me and thus always one of great curiosity. Like much of programming, it's one of those fields that I cornered as something that only PhD's have any knowledge of and mere mortals need not bother trying. One of the things Hack Reactor has taught me is that technical problems are just like any other, they can be solved. The learning curve or expertise necessary to master different areas might vary, but everything can be solved. In this post, I'd like to walk you through our experience exploring machine learning as beginners and the basics of how to apply it.

What is Machine Learning?

Two weeks ago I was looking for ways to integrate machine learning into the program at Hack Reactor. I stumbled upon a Machine Learning coding challenge that was being put on by Quora and sent a simple email to the students at H/R that night. To my surprise, by the next day there were over 14 emails that had bounced around in the thread. Team Bitshift was then born at H/R. The team is comprised of some very gifted people at H/R that I'm extremely happy to work with. The problem that we're trying to solve we don't even know yet but we know it's going applying machine learning algorithm to a problem that Quora experiences at their company. Machine learning in this context is basically when you program a methodology or an approach into a program that assists in predicting some type of outcome. A simple use case is predicting home prices. How would you do it? There are dozens of variables you could look at, for instance: square feet, neighborhood, number of rooms, number of bathrooms, age, etc. How would you weight them all? Obviously all the factors play a little bit of an impact but how would you go from a table with all of these factors to being able to predict the price of one of them? This is a great instance where machine learning could almost certainly add value. On a high level, machine learning would be able to scrap through the data of 100,000's of houses in the area of interests and find the relevant weights and subtleties in the data that have the highest relevance to the price of a home.

Our Machine Learning (ML) Workflow:

Understanding the business problem:

ML starts with a question you're trying to answer. It doesn't have to have a specific metric that you're trying to drive, but it's essential that before you even start munging around the data, that you have some questions. How can we best predict the price of Y? What are the relationships between all of these pieces of data? How could I predict the customer lifetime value of a user? Once you have a solid idea on the problem you're trying to answer, you can move on.

Creating an approach:

The ML approach heavily depends on the data available and the question at hand. With only these two variables, the approach can vary widely. You will start by hypothesizing on which features are important are important to the model and how their relationships might be shaped. After you have a few concrete hypotheses, you move to exploring and visualizing the data in some way to get more clues as what variables are effecting the dependent variable and which model might be set to use. In terms of models, on the very low end, if the data set is really simple like a single table with 3 columns of numerical data, it might be viable to use linear regression. In another case, when there are 15+ columns, millions of rows and there is no intuitive relationship between any of the independent and dependent variables, much more sophisticated algorithms will likely need to be used.

Pre-processing the Data in Python + Pandas:

This is where we start to dig into the data. Often times, the data will not be "clean" enough for the algorithms to work with so you have to clean it. This can mean many things like filling in blank values with the mean, removing letters from a string, removing special characters, normalizing data, hashing data, etc. The goal of pre-processing is to have clean data that can then be fed into the models so that they can operate as efficiently as possible.

Exploratory Analysis:

Exploration is where we visualize the data to try to look at in from new perspectives. Depending on the problem, it can be really hard to come to conclusions by merely staring at a table. Visualizations offer you the ability to compare 2-3 different variables at the same time and to see their relative differences based on space. You can also test your data set for kurtosis, correlation and skewness. The goal here is to try to find trends in the data that might adversely effect modeling/fit of the algorithm. Having giant outliers in the data for instance might lead to the model over fitting for behavior that isn't relatively important model. You might also be able to see if there is positive, negative, weak or no correlation between your variables.

Classification and Regression in R:

R is another language that's used for data analysis. One of the secret weapons that we received from Bill, one of the senior Hack Reactor students, is a tool called Rattle. Rattle basically offers a graphical interface to R so that we could more easily test our models. The models are the algorithms that we train to try to map our data. There are dozens of them and each has their own unique strongpoints. One of the ones that really caught our interest at the start was the random forest algorithm. The random forest basically takes tons of subsets of your data, known as random subspaces and does multivariate regressions on them. One subspace might be 2x4 chunk of the dataset while the whole set is 8 by 100.  A standard number of subspaces is 500 to give you an idea of the magnitude. As the algorithm iterates through the 500, it is learning from itself. It is constantly comparing the subspace to the dependent variable and figuring out how to lower its cost function.

Regression and Ranking with Python:

After we did the basics of testing out models in R, it was time for us to scale it up with a more robust program. For this we chose Python which is a language similar to Ruby but built very well for data analysis. To clean the data as mentioned above we used the Pandas library which has all the tools necessary to slice, fill, replace and manipulate the data in any way you would want. After cleaning the data, we had to break it out into 3 separate groups. The training set, validation set and test set. The training set is where you pair your ML algorithm with the input and expected output. If you're doing supervised learning (like predicting a value or outcome), the model already knows what the dependent or target variable should be. Once you train the model, the validation set is used to 'tune' your model. You apply the model to the validation set to see how well fit your model is to new data. You might see for instance that the model is under fit like in the example of the linear line. The data is indicating the regression should be more curved and yet the model is linear. The opposite would be over fitting where you might fit every single case of the training data, but when applied to new data, it completely fails like in the example to the right. The answer is 'tuning' your algorithm so that it fits the training and validation data well. Also, every time you test the model against the validation data, you randomize the data set for example 70% might be the training data and 15% for validation. The last 15% is for the test set which is what you use to estimate the accuracy of the algorithm. You do this after you've done all the tuning and you want to see the final output on new data.

Our progress thus far:

The seven of us started this journey with no experience and wild ambition. We knew absolutely no python, R or workflow on machine learning and over half a week we've turned our collective mind into something pretty awesome. Our first problem that we started working on was an introductory problem from Kaggle, http://www.kaggle.com/c/titanic-gettingStarted. The problem is predicting who on the Titanic survived and died based on a set of training data that we were given. After doing our basic regression in excel, we quickly moved to python and had what we thought was a very accurate answer. Our first answer turned out to be horribly bad. We placed around 5,000 out of 6,000 entries and had a lower score than we would've had if we said that all the women survived and all the men died. We learned from this by cleaning the data more and applying a more rigorous SVM algorithm which got us to the top 1,000. Ranking above a typical gender, class and ticket price based model. Our last feat (2 hours ago) was doing Quora's previous machine learning challenge. On this we spent a lot of time munging through the data on Pandas before finally comparing results on a decision tree, random forest, support vector machine, neural network and a boost algorithm. We saw mediocre results until starting getting deep into the data to find outliers, normalize the data and dimensionally reduce our features. Our final outcome was getting what Quora would have considered 5th place on the last competition with our score.

For our last sprint, we took our first dive into databases. I've had a little bit of experience with MySQL, phpMyAdmin and ActiveRecord in Rails, so going in wasn't too hard conceptually. We started by learning how databases worked in comparison to the native file system in Node.js. Databases basically serve to answer many of the problems that came from writing to a single common file. Such as multiple users writing to the same file, having to read the whole file to find the content you want, etc. Databases offer a level of abstraction to the developer so that they can store tons of data, get to it quickly and write concurrently.

SQL (including postgresSQL, Oracle SQL, MySQL) is basically the database you have when you add all the features. This of course comes at a cost of speed and scalability. Relational databases are also notoriously bad at handling larges amount of graph type data in which the schema frequently changes. Like social networks.  For example, Twitter moved away from SQL around 50,000 users because lookups became too expensive. Imagine simply finding the tweets from all your followers. In terms of time complexity, this was O(n^2) meaning that for every new user/follower, it costed them double that in lookup time. MongoDB and many other NoSQL databases were built with the main benefits being that they could scale faster/wider than standard SQL solutions. MongoDB is schema-less, it is instead document oriented. There are no tables which you have to join columns together like has been standard in SQL for ages. With Mongo you are able to shard your data as you scale, which means that as your database gets too large for one machine you can easily spread to more.

Time to dive into code. Our goal for this sprint was to swap our the Node.js file system for several different databases. As you can see with SQL, before you every dream about writing your data to the database, you have to very thoughtfully create  schema. This is basically the organization plan for your database. I say thoughtful, because any changes you want to make in the future will become orders of magnitude more painful to change as you go. It's essential that you think of how the relationships of the data should be organized. SQL's syntax is also quite painful. One of the groups in our class tried create the functionality of checking a userID, checking a roomID, and creating a new message all with one query. It ended up containing over 20 operators and they manage to make it work after three solid hours of debugging. Hence, I think it's generally best to keep the queries as simple as possible and abstract the logic to another language such as Javascript. The syntax is declarative meaning that you specify what you want to happen, never how. Needless to say it can be a pain to work through the syntax, but it overall it still makes sense.

MySQL Schema

CREATE DATABASE chat; USE chat; CREATE TABLE rooms ( id INT NOT NULL AUTO_INCREMENT primary key, name varchar(30) ); CREATE TABLE users ( id INT NOT NULL AUTO_INCREMENT primary key, username varchar(30) ); CREATE TABLE messages ( id INT NOT NULL AUTO_INCREMENT primary key, content varchar(140), created timestamp default now(), user_id INT NOT NULL, room_id INT NOT NULL, FOREIGN KEY (user_id) REFERENCES users(id), FOREIGN KEY (room_id) REFERENCES rooms(id) ); CREATE TABLE friends ( id INT NOT NULL AUTO_INCREMENT primary key, user_id INT NOT NULL, user_id2 INT NOT NULL, FOREIGN KEY (user_id) REFERENCES users(id), FOREIGN KEY (user_id2) REFERENCES users(id) );

MySQL Server with RAW SQL Queries

var mysql = require('mysql'); var dbConnection = mysql.createConnection({ user: "root", password: "root", database: "chat", port: 8889 }); exports.newMessage = function(content, username, roomname){ exports.getRoomID(roomname, function(roomid){ exports.getUserID(username, function(userid){ dbConnection.query("insert into messages (content, user_id, room_id) values ('"+content+"', "+userid+", "+roomid+")", function(err){ }); }); }); }; exports.getUserID = function(username, callback){ dbConnection.query("select id from users where username='"+username+"'", function(err, rows, fields){ if (rows[0]){ callback(rows[0]['id']); } else { exports.createUser(username, callback); } }); }; exports.createUser = function(username, callback){ dbConnection.query("insert into users (username) values ('"+username+"')", function(err, results){ exports.getUserID(username, callback); }); }; exports.getRoomID = function(roomname, callback){ dbConnection.query("select id from rooms where name='"+roomname+"'", function(err, rows, fields){ if (rows[0]){ callback(rows[0]['id']); } else { exports.createRoom(roomname, callback); } }); }; exports.createRoom = function(roomname, callback){ dbConnection.query("insert into rooms (name) values ('"+roomname+"')", function(err, result){ exports.getRoomID(roomname, callback); }); }; exports.getMessages = function(roomname, callback){ exports.getRoomID(roomname, function(roomid){ dbConnection.query('SELECT m.content, u.username FROM messages m, users u WHERE m.user_id = u.id AND m.room_id = '+roomid+';', function(err, results){ callback(results); }); }); };

Next up was working with an ORM. This stands for object-relational mapping which basically means it bring an object orientation to a language. In this case, giving a functional language to SQL. Now, instead of having to declare everything you want in each statement, you can create instance variables of any class and apply methods to them just like Javascript. Also, no more schema file! While you still have to map out the relationships like in any SQL database, ORM's take away some of the pain that comes with doing all the wiring yourself. As you can see, after introducing the ORM we were able to cut our code in half.

MySQL Server with ORM Queries and No Schema

var Sequelize = require("sequelize"); var sequelize = new Sequelize("chat2", "root", "root", { host: 'localhost', port: 8889 }); var User = sequelize.define('User', { user_name: Sequelize.STRING }), Room = sequelize.define('Room', { room_name: Sequelize.STRING }), Message = sequelize.define('Message', { content: Sequelize.STRING }); Room.hasMany(Message, {as: 'roomMessages'}); User.hasMany(Message, {as: 'userMessages'}); Message.belongsTo(Room); Message.belongsTo(User); exports.newMessage = function(content, username, roomname){ Message.sync().success(function(){ exports.findOrCreateRoom(roomname, function(roomid){ exports.findOrCreateUser(username, function(userid){ var newMessage = Message.build({content: content, UserId: userid, RoomId: roomid}); newMessage.save().success(function(){ console.log('message saved', content); }); }); }); }); }; exports.findOrCreateUser = function(username, callback){ User.sync().success(function(){ var newUser = User.findOrCreate({user_name: username}).success(function(user, created){ callback(user.values.id); }); }); }; exports.findOrCreateRoom = function(roomname, callback){ Room.sync().success(function(){ var newRoom = Room.findOrCreate({room_name: roomname}).success(function(room, created){ callback(room.values.id); }); }); }; exports.getMessages = function(roomname, callback){ exports.findOrCreateRoom(roomname, function(roomid){ Message.sync().success(function(){ Message.findAll( { where:{RoomId: roomid}, include: [User] }).success(function(msgs){ callback(msgs); }); }); }); };

Last was MongoDB. To be fair, this was my first time playing with Mongo and I went for the easiest implementation possible. Something equally as short could have been done with an ORM if I had structured the schema in a single table. Mongo was extremely simple to get up and running. It worked just as advertising, it's a store of documents. All you do is tell it what to store, and it gives it a unique hash-type ID and stores it (without telling you). I'm still unsure as to how drastic the performance improvement is with Mongo, especially given that you have to scan all your files to do lookups (unless you add secondary indices). As you can see with Mongo, the syntax is very simple to understand. You simply open the db, open the collection (table) and insert your data. Later when you want it back, you just open the db, open the collection, and do collection.find() to retrieve whatever data you want. Simple as that, no schema, no relationships, no painful syntax.

MongoDB Server with No Schema and No Joins

Without a doubt, one of the most impactful things at Hack Reactor has been the teachings from our lectures. Especially at the beginning. This was due largely to our main instructor Marcus. Honestly, his attitude towards teaching and care for the students is one of the main things that sold me on Hack Reactor in the first place. In this post, I'd like to walk you through some of the things I think set Hack Reactor apart in terms of teaching style, culture, expectations of students, etc.

Expectations

From the the start of Hack Reactor it was clear that they expected a lot from us. To get into the program there were two technical interviews and a chat client assignment. After being accepted there was about 50+ hours of pre-work to do before the program. This is honestly starting to be the norm for a lot of intensive coding programs. What's different about Hack Reactor is that when you arrive your first day you realize many of the students are already part way through a CS degree, flew through the prework and that the first two weeks you take a deep dive into data structures and algorithms. If you aren't extremely solid on the fundamentals when you start, you will quickly be buried by the work thrown on to you. They expect a ton out of the students and that is one of the things I like most about being here.

Pair programming

Pair programming is one of the best ways for a beginner to learn how to program and learn how to vocalize code. It's basically when two people sit at a computer with two screens and two keyboards that are attached to the same computer. They work through the code as a team, with one person being the "navigator" and the other person the "driver". The navigator is the person that decides what to do. If the either of the people are like "Ooo I know what to do", rather than take the keyboard and do it, they suggest to navigate so that they can speak the code to someone else and the other person (driver) can practice doing it. The driver is the person that has the keyboard and codes. Each person takes turns swapping between driving and navigating.

My experiences with pairing have been largely positive. It really helps to practice working on problems with someone. Getting stuck isn't as frustrating when you have someone else to work on a problem with you. Generally when you pair, both people have a notion of who knows more about what to do. When this is the case, the 'better' pair is able to practice navigating more and explaining their reasoning. I've frequently had situations where I thought I knew something very well but when it came down to explain it, I realized my understanding was foggier than I initially thought. This can also be one of the challenges of pairing is that when someone has a weaker intuition of what to do, it can lead to both of you constantly jumping into rabbit holes and diving into tangents that don't solve the problem. This is why I've tried to embrace a more inductive way problem solving and debugging. I'll explain what I mean. A deductive way of debugging is where you might run into a bug and then frantically trial/error every possible solution you have in your mind. For small problems this might be enough; however, with bigger problems you can end up spending an hour or two spinning your tires and still not have any idea what the problem is. The inductive way to solving is to go back to the point where you know exactly how the code works and you know it's functioning. You then step through the code one line/block at a time with a debugger and find the point where things aren't behaving as they should. Next, make a hypothesis on what you think is the root cause and a potential fix. Test out the fix and see what happened. Wash, rinse repeat.

The other side of pairing is also helpful but it has drawbacks all the same. When you are the 'weaker' pair it feels better because you fly through the problem easier and you're able to get an explanation from your pair about how they're approaching the problem. The downside is that you don't hit the same roadblocks that you would've alone and that effectively means that you also skip a lot of the learnings that you should've had. For this reason and many others, we're always encouraged to pair with people who have similar abilities to us.

Mentality

Coding can be extremely frustrating. When you're in an environment such as this it's easy to feel discouraged or feel like an idiot because your peers are constantly one step ahead of you. One of the things that's been drilled into our heads is that good software engineering doesn't mean that you know everything. Rather that you are comfortable understanding that you don't know everything and you can move forward quickly. You are also comfortable with just interacting with the interfaces of libraries/frameworks and not having to understand the inner-workings of everything.

Autonomy

When we all started at Hack Reactor, their mandate was to make sure that no student 'grinded' on a problem for more than 5 minutes. Grinding is where you are stuck on a problem and are burning a lot of mental energy to figure it out. Hack Reactor offers tons of resources to make sure that we can get 'unstuck' immediately. However, as we progress as developers their goal is for us to become autonomous. Autonomy in coding is where you are able to unstick yourself through whatever effective means necessary. This might mean talking to a senior engineer, but it likely means debugging, stack overflow or reading the documentation.

Lowest delta

Lowest delta is the idea that rather than code 50+ lines and check in your code, you should do it much more iteratively. This is better both for debugging and for keeping track of working versions of your code. Aiming for the lowest delta means doing the smallest amount of code necessary for a noticeable improvement in the program. Doing as little as possible to improve the app, testing it to make sure it works, then checking it in.

Toy problems

Backbone.js

The last sprint we did this week was building our third app in Backbone.js. Backbone is a library that acts a lot like a lightweight model view controller. I say light because Backbone isn’t as prescriptive as a heavier framework like Rails. It requires you to do all the wiring yourself, but it provides a structure that enables you more than directs you.

Our goal for the app was to build a Blackjack app. We were given a shell of an app to work with that already had about 4 views and 4 models. This was enough to provide us a function to create a shuffled deck and to hand out cards. We then had to make the functionality for hitting, standing, betting, etc. The first day of this project was somewhat frustrating because we were still getting used to Backbone and Coffeescript. It’s quite painful when you grind on a problem for an hour and half when you know that the problem is one line. After getting the basic requirements to work the first day, we broke off the second day to cover more ground. I built out the betting features and my pair built out the CSS styles for the cards. I’m actually pretty happy with our result. Check it out here! Some of my biggest lessons from this project were that I needed to learn how to better communicate my ideas in code and that whenever debugging, it’s essential to use an inductive solving process. This means that you’re starting from a point where you know things are working and you inch your way through the code, learning/testing each piece until you find the root cause. Often in code the shining red light will just be a symptom of the problem that you’re trying to solve. By inductively reasoning through the problem you almost always save a lot of hours of debugging. The opposite is when you get stuck, trial/error every possibility that comes to your mind and end up burning through an hour of debugging and still not having a clue what is wrong.

Another huge benefit of Backbone is all the built in event listener functionality. Models and views are able to 'listen' in on events from each other and can take actions based on those events. In this game, there are many events that fire off based on user behavior (clicking bet, hit, stand) and functions that fire whenever those behaviors are meant, such as the rendering of particular views.

The last piece of functionality I liked was the flow of the models and views. This was my first experience wiring an MVC from scratch and it was really nice to be able to customize where to direct each model and view. I know that other frameworks tend to be more prescriptive in terms of forcing an approach on you but Backbone gives a lot of flexibility there.

Coffeescript

This task wasn’t too hard on it’s own, but in addition we had to do it in a new language (albeit a close one), Coffeescript or CS for short. CS compiles directly to JS. It was made as an answer to a lot of the complaints people have about Javascript. JS can be a confusing language to learn because it has a lot of odd syntax, classes that don’t work intuitively, declared variables/ explicit returns and a bunch of other stuff. Coffeescript takes away a lot of this. It implicitly returns, implies variable declaration, gets rid of a lot of the ugly syntax that JS comes with and takes away the entire .prototype layer. However, despite it making things ‘simpler’, I also found I was making more syntax errors simply because I didn’t know the language. 

Here is the app if you’d like to play around with it. It’s not quite finished but it’s to a point that I’m happy to show it.

PPG Casino - Blackjack

http://bit.ly/12lDWO8

one of the things I've struggled with since its introduction is 'this'. 'this' is Javascript's convention for context. the best way to explain it is to show some examples:

if we open up our console and type:

var shout = function(name){ alert(name); }

then we execute the command with shout('greg'), the browser will execute an alert that says the name greg. but what happens if we were writing the function from within an object. and we wanted to alert that objects name. for example:

var alice = { name: 'alice', shout: function(){ alert(name); } }

if we execute the command alice.shout(), alice's name will not be shouted because when we call alert(name), name doesn't refer to anything. this is where we need the 'this' keyword which sets the context of the variable we're calling to alice. while we are within the scope of the alice object, 'this' will refer to alice. so if we call alert(this.name), this reference alice as the object and it will look for the 'name' property of alice.

now for a more complicated example. how would you write a function that would remember the initial context that it was passed? for example a bind function that when passed an object and a function, it would create a new 'bound' version of the function that would always remember the context it was originally set in. second, how would you write it so that you could write func.bind(obj). here is a crude version of how it could work. first we would set our function and our object. in this case, we'll have it be shout and alice. next we write our binding function using the Function.prototype because we're adding a function that we want propagated to all Function instances. Also remember that in Javascript, functions are also object and have a prototype all the same.

we could write it like this:

Function.prototype.bind = function(obj){ return function(){ this.call(obj); }; }

this way when, we create our new 'bound' function like var boundShout = shout.bind(alice), we should be able to call boundShout() and hear it shout alice's name right? wrong. even though we may have thought 'this' was referring to the function when we created it, all the matters is the context of this at call time. what is this means is that it doesn't matter that in the function we thought 'this' referred to shout. the golden rule of javascript is that it's what is left of the dot at call time that determines the context of 'this'. and when we call boundShout(), what is left of the dot? there is no dot. the context is therefore, 'window' which is the main browser object for the tab that's open. to fix our function, we need to save the old context of this during the construction of the function itself. we can set this to a variable, and instead of referencing 'this' at call time, we can reference the saved context, 'that'. here's the code:

Function.prototype.bind = function(obj){ var that = this; return function(){ that.call(obj); }; }

always remember the golden rule of 'this': 'this' refers to the object to the left of the dot AT CALL TIME of the function.

alert('hello') // this === window

Last Saturday, my pair and I built an awesome game in D3. It was one of the most exhilarating experiences I've had at Hack Reactor. A little reminiscent of doing Mega Startup Weekend in the mobile gaming track almost a year ago.

Tuhin and I started our two day sprint with 4 repos for the assignment. This means literally working on 4 small projects in the span of two days. Marcus wasn't kidding when he said we probably wouldn't get to the end because even at a glance it looked like each project would take 4-8 hours. The first was on html/css layout which we decided to move on from after the part (replicating Google pixel by pixel).

We decided to move to the next part mainly because we were so excited about the library. D3 is actually one of the reasons I got excited about Javascript in the first place. D3 is a visualization library that allows you to bring your Javascript into a 2D/3D animated space. Here are some great examples: https://github.com/mbostock/d3/wiki/Gallery. Notice how a lot of these visualizations are less than 50-100 lines. D3 brings together SVG (vector-based graphics), CSS, html and selectors/animations that feel like jQuery.

The initial assignment was to recreate this game. http://latentflip.com/LearningD3/collider/. It looked daunting at the beginning but after looking at the code it became easier to break it into smaller chunks. The main thing I realized after playing the assigned game is that the game sucked! There was really no underlying game design besides avoid dots. Also no sense of progression. Tuhin and I immediately saw an opportunity for improvement. Given these features as a rough shell of a game, how could we make this fun? Before we dove too far into the code, we began debating possible features. Some of the ones that came to mind were:

Capture flags that randomly popped up around the screen.

King of the hill - you only get points while you stand in certain zones that appear randomly.

Eating some of the dots.

Growing as you eat more dots.

After we brainstormed a bit, we also came to the conclusion that given time constraints and good game design, we should probably limit the feature set to the top 2. I really wanted to the game to start out easy. Any user should be able to grasp the concept in the first 10 seconds or after they lose without instruction. I also wanted to the game to progress in difficultly as the game went on. Also, unlike the assigned game, I didn't want it to feel like a constant cluster duck. All these things considered, we finally came to the idea of eating pink dots and avoiding blue ones. Simple game design right? The user would start out with one pink dot on the screen and no enemies. After eating one, one pink dot and one blue dot would appear. All the dots move around constantly so as you eat more pink dots and more blue dots appear, it gets harder and harder. By the time you've eaten 20 pink dots, there are 20 blue dots flying around the screen for you to avoid!

Translating this to code was difficult but not the hardest assignment we'd had. I think part of that is thanks to my pair. He had a very good eye for when something wasn't making sense and that we should just read the documentation. The more I code the more I realize how often times debugging through the process of trial/error or deductively isn't always the best way. I'm finding it more and more valuable to get exact definitions from documentation and using the debugger to inductively finding the cause of issues.

The hard parts about grasping the D3 library at first were the primary functions it uses to stage data and to render it. It D3 workflow basically goes like this:

Create a d3 object and append it to a point on the DOM. Set key attributes like height/width etc. Declare any special methods that need to be applied to the entire D3 object.

Decide how you're data flow is going to work. D3 works on the paradigm of data entering, updating and exiting.

.data(data) - the data function is applied to the svg.selectAll(DOM elements you want to interact with). When it's called it compares itself to the number of nodes that are currently rendered on the DOM and from that comparison it decides how many nodes need to be entered or exited. .data() does not deal with the data itself, rather just the number of elements/nodes. This is one of the hardest parts to understand at the start. It doesn't care what data you feed it, just the amount.

.enter() - is a method applied after .data() and it informs what you want to do with the extra nodes that are being create. for instance, if there were 20 live nodes on the DOM when .data() is called on with 25 elements, .enter() now knows that it needs to create 5 new nodes. The code you write after .enter() tells the app what to do with those 5 new nodes.

.exit() - is also applied after .data() and like enter is what you do with the nodes that were in excess. often it is just a .remove() command which removes them from the DOM.

That is the gist of D3. In our game we had a setInterval to update the dots entering/exiting and to move them a around. And a second setInterval to run constant collision detection on the dots.

After dedicated probably 10 solid hours to our game, it was ready by 6pm on Saturday. We were super excited to finally get it into people hands and happily people got hooked. One of the students was locked in for 30 minutes trying to break the record (which is now 33). Try it out for yourself! Happy gaming!

http://bit.ly/13hmNep

Last week on day 9 (Wednesday), I paired with Hao to work on n-queens. n-queens is an algorithm problem that has a very visible application. The goal is basically to figure out on a chess board size n, with n queens, how many possible arrangements are there such that no queens can attack each other. This is a pretty simple task with rooks because you can quickly come to the first solution by aligning them all diagonally; however, queens have the added property of being able to attack diagonal. n-queens now becomes a very interesting problem because the type/number of solutions are less and less intuitive. Take this example for instance:

It works right? No queens are able to attack each other. But at the same time, it doesn't come across as a very systematic or intuitive answer. Now imagine that there are 92 of these solutions for 8 queens on an 8x8 board and a decent algorithm can find them all in less than 0.002 seconds. Cool right?

When we were first handed this assignment I was very intimidated by the problem just because conceptually it sounded hard to fathom. However as we started diving deeper into the problem, it became apparent that it could easily be solved with a recursive function. We made it even easier by solving for rooks first.

Solving for rooks is very simple both conceptually and with code. If we're solving for 2 rooks on a 2x2, we can start by notating the board with a,b as columns and 1,2 as rows. If we place our first rook in the upper left, (a,2) it closes off our ability to put anything at the upper right (b,2) and the lower left (a,1) because the first rook can attack both those positions. The second rook is then only able to be placed at the lower right, (b,1). That is one solution. If we clear the board and test out the next position in the first row (2), then we would place our first rook on (b,2). Similarly, this blocks the second rook from the upper left position and the lower right. The second rook can only go on (a,1). This leaves us with 2 solutions for a n-rooks, n=2 problem. If we look at this with larger and larger boards, the math then works out to be n factorial. For a 3x3 there are 3x2x1 = 6 solutions. For a 4x4, 4x3x2x1 = 24 solutions. Etc. This makes very simple and intuitive sense.

When Hao and I got to how to write an algorithm to solve this problem, the thought process basically went like this. After a rook is placed we are no longer able to put another rook on the same column or row because they will be able to attack each other. This means that as soon as we place a rook in a position that it's safe, we can then look to placing the next rook in a different row, and not in the same column. Because of the simple logic of this problem and because each row we were basically going to use the same rules, we decided using a recursive function was the best way to solve it.

We started by creating a function to check the rows. This is the function that we would initially call and it would recurse through all the rows until it ran through all it's options. Within this function, we created a for loop that would place a rook. Immediately after it places a rook, we run a set of checker functions to see if that rook is in the danger zone (able to be attacked by other rooks), if so, we removed the rook and it continues on the for loop. However, if the piece we put down isn't in danger it does one of two things. First it checks if it is at the last row, if then runs our recursive function on the next row. If it is on the last row and it successfully placed the last piece, this i means that it found a solution! In this case, we up a counter, switch off the piece and our function continues in this loop. The magic behind the recursion that is that runs through all the possible options of on the board. It it's most basic and naive solution, the function systematically goes through every single arrangement that would make reasonable sense (no rooks on the same row) and outputs the number of times it find an arrangement that doesn't flag the checker functions.

The problem got a lot more interesting when we switched to queens and started to make optimizations. Initially we were going through every combination of queens and running a checker function that iterated through every row/column/major diagonal/minor diagonal to see if there were conflicts. While this makes sense to do, it's a very expensive process because as n increases our algorithm gets slower by n^2 (because for each additional piece there are geometrically more checks to run).

When we were writing our initial algorithm I had placed the recursion in the right spot by having the queens recurse down the rows. However, I had naively made an additional recursion for the columns as well. The better solution had a for loop nested in the recursion which gave it all the logic necessary to iterate through all of the columns. My solutions was much more clumsy and ended up costing lots of complications later. I had my first experience scraping code that was very close to working but buggy in favorite of just taking a new approach.

This is where we found that we needed to optimize our algorithm to run in constant time. Constant time basically means that every time we place a piece we don't need to run for loops over row/column/diagonal. Instead, we can quickly call an object (constant time) that already has a record of whether there were conflicts. Instead of using checker functions, we constantly keep record of all the conflicts that exist on the board. We segmented this into columns (no two queens can we in the same column), major diagonal (no two queens can be on the same diagonal on the upper-left to lower-right axis) and minor diagonal. It became immediately clear how much faster this new method would be for our algorithm. The checker method strategy resulted in being able to find 14,200 solutions to a n-queens with n=12, and it took about 266 seconds. With the new algorithm based on constant time, we brought this time to 0.172 seconds. This is an improvement of about 1,500x.

I missed last Saturday because I was at EDC in Vegas. One of the craziest and tightest weekends I've had in a while. I definitely don't regret it though because I got to hang out and party with some of my best friends from around the states and hong kong. I flew out at 12pm (midnight) on Friday and got back at 8am on Monday. Literally got 1 hour of sleep before trying to tackle a 12-14 hour session of Hack Reactor. I absolutely do not recommend doing this.

Today we mostly worked on a problem called the blinky dancers. On a high level our task was to refactor a currently working app that create blinky dots on a screen and change it from being functional JS to pseudoclassical. Apparently to be taken as a serious JS coder you have to an expert as pseudoclassical coding. This is unfortunately because it still seems so sloppy and unintuitive. But then again, as my friend Tuhin said, it just raises the barriers to entry for others to learn JS. Which is at present, one of the rising stars in the world of development languages.

Since I'm not going to be at class tomorrow, today is the last day to work on data structures with my pair Kyle. We have been killing it the last couple days and are farther ahead than most the class. Our goal is to get to the red-black tree data structure which is basically a self balancing tree. I've gotten more and more interested in data structures the more we work with them. Each one has its own idea use case. Its own set of features, benefits and costs. For example a red-black tree is great for a large data set of seemingly random numbers. Once all the values are added to the tree, the red-black would have no problem quickly getting to an individual number after working through a few branches. An array in this case would be one of the worst implementations. For an array, it would have to check every value one by one until it found the one you wanted. We would say that an array would cost 'n' being the number of elements in the array. Whereas for example in a balanced binary tree, you could work through 1M numbers in just 20 steps. Pretty amazing right??

Our lecture today was on hash tables. My pair and I already completed this assignment yesterday and it was interesting to see most of our assumptions and research validated. A hash table is now a common feature in most languages, including javascript. It enables a user to store key value pairs instead of just values. In an array you can just store values which are all paired to a consecutive index. This can be an unideal way of storing data, especially if you need to insert/delete information from the array constantly. A hash table enables a user to quickly lookup a value based on a key. For instance, key === john's coat, value === blue. With arrays, there aren't very effective means of storing 1,000's of these. However with a hash table you basically create a large blank array, create a "hash" machine that creates a seemingly random number (hash) that will create the same value each time if given the same string. This then becomes the value in the array. Now, whenever you want to find your key value pair, you just enter in the key in the hash machine and it gives you the correct element on the array. The object stored within this value is the key/value pair. Or multiple depending on how you implement it.

Today we had our first assessment. I honestly expected to do pretty well on it and was surprised when the answers didn't come faster to my brain. I think I understood most everything conceptually but just couldn't execute in such a short time period. This has helped me realize how I really need to strength my fundamentals to be ready for the rest of the course. I'm planning redoing all of underbar and the recursion pieces as well. Also making flashcards for all the core concepts. I really don't want to get behind.

Our lecture this morning was on Git. Despite having watched half a dozen videos on git, github and HR's process for git, it is still confusing. It's a version control software that is done completely through the console. It's not hard in theory, but in practice it's controlling hundreds of issues on dozens of branches through a command. It gets messy pretty quick if you don't know the exact commands to type.

Today was the first day departing from review. I felt reasonably confident about the review material so I was really excited to be moving on.

We began the day by learning how pair properly. The previous two days we had been running blind with how to pair and had got to feel some of the frustrations. Often if one pair is farther ahead than the other it may cause the person farther ahead to get frustrated. With thoughts like, "I could just do this myself or he/she is slowing me down". I had sort of got this feeling before and it didn't feel good. We learned that pairing is one of the best exercises you can do when learning how to code. Pairing is when you have two people on the same computer, looking at two monitors with two keyboard/mice. At any one time only one person has their hands on a keyboard. They are called the driver. It is their job to write all the code. The other person is the navigator, it is there job to determine what to code. The driver should not go off and just start coding if he/she already knows what to do. Rather, whoever has the idea should say, "hey i've got an idea! let me navigate". The point of the exercise is to both learn how to communicate your ideas effectively and to learn to code. Both of which are essential skills in getting hired as a software engineer. Other tips we got were:

Don't pair with the same person more than twice in three sprints. This is to make sure that you get practice with a lot of different people who likely will have different communication styles.

During sprint reflection, have a feedback session with your pair. Invite them to be as candid as possible. Give them feedback that is clear, actionable, compassionate and honest.

Make sure that you're splitting the driving/navigating up 50/50. If it is weighted to one side it should be heavy on the weaker pair.

After learning how to pair more effectively I think the whole class had a sigh of relief. We had all faced challenges when trying to communicate with our pair and this was our definitive answer. I was a lot more excited to go about pairing with these new techniques in mind.

The next lecture was on abstraction. Abstraction is an interface, system or object that when interacted with corresponds to the properties and behaviors of some other system. The example that Marcus gave was a steering wheel to a car. Abstraction takes away complexity so that we can interface with something simple. We don't care about the wires and tubes in the car, just that they interfaces work so that we can drive from point a to point b.

After that we reviewed object oriented programming and got a peak into how it originated. We learned that before object-oriented programming (OOP), to keep track of user data, a person would just create an array for each property to track. For example userName, userAge, and userLocation. One index value would correspond to the same user across three arrays. This is obviously a very confusing way to keep track of users and it would be very clumsy to navigate around. Object-oriented programming was basically the you could bundle data together and give behaviors to the collections of data. Instead of having functions act on all the data, give unique functions(methods) to subsets/collections of the data.

Our finished up the day with the main course. For the next 4 days we are going to be mostly focused on data structures. This is a topic I've been super excited about, partly because one of my friends who is a software engineer said that one of the most important pieces of knowledge for interviewees to know is algorithms and data structures. We got to learn about the two basic structures which are a queue and a stack. A queue basically works like a deli line or a mail room. The first thing in is the first thing out. As accounting would would say, FIFO. A stack is more similar to a stack of papers waiting to be graded. The last one on is the first one off the pile. Aka, LIFO.

Our assignment for this two-day sprint is to do both of these data structures in a functional way, functional-shared way, prototypal and pseudoclassical. This was we get to learn about a lot of the underpinning that go into inheritance in Javascript. As with everything in Javascript it seems to be more confusing than it has to be. That said, I still feel strongly that Javascript has some huge benefits that just waiting to show their face once we get through all the crap.

I paired up with Kyle today who was very solid. He's already part way through a computer science degree and already had a handle on data structures. We were able to move at much more rapid pace. Interestingly we added more complexity than was necessary on simple implementation of the queue problem. We accidentally built it as a linked list. A linked list is basically a data structure where instead of every item sitting in an array or a giant object, they are all individual nodes that all have references to each other. A queue is kept to keep track of the first and last items and each individual node references the 'next' node so that you can remove/add them one by one. It was really interesting to see how else data structures could be organized and I'm excited to be able to compare the speeds of each.

Day 2 was just as intense as Day 1. This is the last day of reviewing the prework and our task is to finish the Underbar assignment. Underbar is basically all the default functions for iterating through arrays that we usually take for granted. Examples: .map, .each, .reduce, .reject, .every, .once, .any, etc. I partnered up with a new partner for this one. It was difficult at first mainly because I we were so similar. We both were somewhat stubborn in our approaches. Often we would both have an idea of how a function should be created, we couldn't verbalize it that well and we'd end up having to just take the keyboard to show how to do it. This is obviously not the point of pair programming. Over the course of our pairing, we worked out better solutions. I got better at writing sudo code to explain the high level ideas. We gained more trust in each other. And we started to come to agreement on smaller pieces of the function as opposed to how the entire thing should written.

Next we dove into wtf 'this' means in Javascript. Honestly it was pretty confusing at first. Javascript seems like a language that was not thought through very well. Apparently as the story goes, an engineer at Netscape made the language in a week. When he tried to push it to the new Netscape release, one of the heads there said it needed to look more like Java to get widespread adoption. So they added a bunch of Java like syntax and voila, Javascript was born out of Oak. 'this' in Javascript basically refers to the object left of the dot AT CALL TIME of the function referencing 'this'. It is a way to refer to the object referencing whatever you are calling. But there is a bunch of added complexity and nuance. If you just call console.log(this) then it would return window because there is nothing left of the dot.

Underbar was great practice in how to create basic iterations and callbacks. I had a tendency to want to apply a for loop to everything but my pair helped me to stretch my abilities more to use the functions we had created on each other. For instance, using _.reduce to solve _.every, etc.

Today was completely exhausting but at the same time it was everything I was looking for.

When we came into Hack Reactor today, there was a ninja assassin ice breaker waiting for us at the table. Everyone had their name written on a folded piece of paper. Inside the fold was the name of someone else. The goal of the game was to try and find that person, wink at them (assassinating them from the game) then take their paper and assassinate new targets. It was a fun way to meet new people throughout the day.

The caliber of students let into Hack Reactor was very high. Students are very sharp and motivated towards an end goal. The majority want to be full-time developers which I myself am also thinking of.

When it got time for class to start (9am), a gong went off and students were instructed to get to the main lecture area. We started off with yet another ice breaker which was even more hilarious. It was basically a big rock, paper, scissors tournament where everyone paired up to play. The loser would have to then become the victor's cheerleader for the remainder of the game. I lost early, so I just ended up cheering for my friend, then he lost. By the end, it was a mob of 20 people cheering for one side and 20 on the other.

Then got to coding. The class is organized into 2-day sprints. The first day of a sprint will have a prompt, demo and followup. Next we'll dive into pairs to try and solve the problem briefly to get a handle on it. Then after we've tried our hands at it, we get a more complete lecture. Next we get into pairs again to work out the problem. After dinner and another event/lecture, we are done for the day. On the second day of the sprint, we work on finishing up the problem, working out (yes at the gym), seeing the solution, doing extra credit, then lastly cleaning up our code.

It's really awesome to see Marcus (our lead instructor) teach. He definitely knows his stuff inside and out and is excellent at explaining concepts. He continually goes between physically analogies and very clean coding explanations, I think this will be crucial as we get to harder concepts. We also get to learn a lot about style when coding in JS.

One part I found particularly interesting was how to more effectively debug. Previously I was just putting console.log() commands throughout my code where I wanted to watch a variable or expression. He showed us how to use Google Chrome Developer Tools to basically break to code right before the point of error. We could also conditionally fire the debug statement once error conditions were met. Once in the console, we could tell Chrome which expressions to watch and step through them to watch their values change line by line. Really cool. stuff.

Another interesting thing we learned more about was scope. I was kind of surprised to see that when he nested a function, cloned the function, then cloned the clone, the two clones would start behaving differently. Even though they were just clones.

For this first sprint, we are redoing the hardest parts of the pre-work in 2 days. It's crazy that something that originally took me 15+ hours now only took me an hour to do. I guess some of the repetition is paying off.

My pair, Peter, and I solved two recursion problems today. One was rebuilding the JSON.stringify function which basically takes various types of JS objects and converts them into a string so that they can be universally passed to other languages. The other was the getElementsByClassName function in JS. This basically takes an input of classNames and returns all the nodes in the DOM that have that class. Both functions sound rather simply in theory, but implementing them with recursion was initially very difficult. Recursion itself was a bit hard to pick up at the start, but I think overtime it will become as familiar as a for loop.

My pair and I finished really early so we got back to assassinating some of our targets. Muahahaha check out all my victims!!