Kevin SmithWeb Software Engineer

N-Queens, Algorithms, REST, and Ajax – Hack Reactor Week 2

inside Hack Reactor

Inside Hack Reactor


Week 2 at Hack Reactor has come to a close, but the frantic pace of learning continues. We kicked off week 2 by finishing up our Sub-Class and OOP sprint that involved making individual nodes “dance” on the page with any random behaviors we decided to give them. What we ended up with were fancy screen savers with objects that could interact with each other (and explode!). This led us to a discussion of particle systems, which sounds like something I want to devote some time to once this course is over.

We had another guest lecture at the beginning of the week regarding algorithms, complexity analysis, and ways to approach solving interview problems. Solving complex problems like this while under pressure is a skill I need to work on, but luckily there are a few great online resources to help build your skills. Some of my favorites that I’ve used so far are:
Project Euler
TopCoder Algorithm Tutorials

Our discussion of algorithms led us into our next project, and my favorite project of the week, called N-Queens. This goal of this project is to find how many ways n queen chess pieces can fit on an nxn chessboard without being able to attack each other. So, if you have a 4×4 chessboard, how many different ways can you fit 4 queen chess pieces on the board so that all 4 queens are safe from being attacked by the other queens? The answer for the 4×4 board is 2 different arrangements of queens. For a more in-depth explanation, check out the wikipedia entryfor the 8 queens solution.

Currently, the largest board that all solutions have been found for is a 26×26 board. At this time, 27×27 is too large of a solution to be handled by today’s computer processors with the current algorithms. However, some students in the senior Hack Reactor class are tackling this problem with an app called supercomputer.js that leverages many networked computers, each solving a small portion of the entire algorithm (similar to the Playstation 3 Folding@Home project out of Stanford).

We spent much of the first day building a JavaScript algorithm for finding single solutions to this problem, and testing it on small chess boards (less than 8×8). We ran through a series of tests written in Jasmine to ultimately come to an algorithm that would successfully find every solution for a given n. However, our first attempt was a brute-force solutions that used 2-dimensional arrays to build every possible configuration of n queens on the board. We then tested every one of these board layouts to determine if it was a valid arrangement where the queens couldn’t attack one another. The boards that passed our test were put into a results array, and then counted. This solutions was very inefficient and took a tremendous amount of computer processing power to complete. This first attempt could not find a solution to any n over 7, because the browser would time out before the JavaScript was done running.

Now that our algorithm was finding all of the correct solutions, it was time to optimize it so that we could find solutions to chess boards above 8×8. Our first optimization involved making our tests for evaluating correct boards more efficient. With these improvements, we were able to find all 92 solutions to n=8 in just over 20 seconds on a Mac mini. From there, we decided to trim down the number of chess boards our algorithm generated.

Instead of creating a large tree data structure of all possible solutions, we started checking early on in the board building process if the piece we just placed was in conflict. So, once we placed a queen on the first row, we knew no other queens could be placed on that row, thus moving on to second row right away. We also knew that the first queen placed on the second row cannot be placed in the same column as the piece on the first row, thus “pruning” our data tree of all possible iterations below that conflicting node. We also checked for diagonal conflicts before placing each piece. The result of this “pruning” was allowing our algorithm to find all solutions on an 8×8 board in about 2.5 seconds!

We were pretty excited about our 10x improvement in speed, but we decided to see if we could make it even faster. Up until this point we represented our solutions using 2-dimensional arrays, which take a lot of iterations to traverse all of the elements. We decided to represent our boards using a simple 1-dimensional array instead. For example, a 3×3 array normally looks like [[1,0,0],[0,1,0],[0,0,1], with the 1 representing a queen (not an actual solution obviously). Instead, we can represent this same array with [0,1,2] , with each index of the array representing a row, and the value of that index representing where in that row the queen is located. Once we implemented this new storage mechanism, our time for finding the n=8 solution was reduced to 49 milliseconds! It was very satisfying to see such huge speed gains from each improvement we made in our code. Here is our final JavaScript solution:

window.countNQueensSolutions = function(n){
  var startTime = new Date();
  if (n===0){return 1;} //0 queens fit on a 0x0 board 1 time
  var solutionCount = 0;
  var rNQueens = function(tempBoard){
    if(tempBoard.length === n){
      checkQueenSolution(tempBoard) && solutionCount++;
    for(var i = 0; i < n; i++){
      var boardCheck = tempBoard.concat(i);
      if (checkQueenSolution(boardCheck)){
      } else {
  var endTime = new Date();
  console.log('Number of solutions for ' + n + ' queens:', solutionCount, 'in', endTime - startTime, 'milliseconds');
  return solutionCount;

window.checkRookSolution = function(matrix) {
  return _.uniq(matrix).length !== matrix.length ? false : true;

window.checkQueenSolution = function(matrix) {
    return false;
  for(var i = 0; i < matrix.length; i++){
    for(var j = i+1; j < matrix.length; j++){
      if(i - j === matrix[i] - matrix[j] || i - j === -matrix[i] + matrix[j]){
        return false;
  return true;

The remainder of week 2 was spent learning about HTTP requests, REST, and how to use Ajax with the service from Parse. We lumped this all together to create a real-time chat room client that all of the Hack Reactor students could use. Once everyone was up and running with the chat client, we implemented features like preventing script attack hacks, creating friends lists, and allowing the user to create and join new chat rooms.

This week was intense, but the instructors are warning us about the start of week 3, which involves us diving into Backbone.js. I’m running through some Codeschool tutorials on Backbone right now to get prepared for next week!

Read more

Hack Reactor Week 1 in Review

Week number one at Hack Reactor is over, I had my first day off since moving to SF, and we’re back at it for week 2. The pace this first week was crazy, and I can’t believe how much material we covered in such a short amount of time. I found myself getting home most nights about 11pm this week, simply because there was so much material to digest and work out in my code.

I also finally got my bike shipped out to me, which has been so much better than taking public transportation everywhere. My ride to school in the morning is about 5 miles, and I have been able to find a route that has as few hills as possible because it’s a single speed bike. Getting some exercise in the morning really gets me brain working correctly for the day, and I’ve been much more alert since starting that routine.


After re-building our pre-course assignments, we dove head first into quite a few basic computer science lessons and how to implement them in JavaScript. We also had a guest talk from a former senior team lead  at Facebook, and I attended my first JavaScript meetup. Here is a run-down of the major topics we covered in just the first 6 days:

  • Git workflow and command line
  • JavaScript basics like functions, methods, callbacks, closures, objects and scope
  • Recursion and as an example we re-built the getElementByClassName native JS function
  • The debugger command and the process of finding errors with Chrome dev tools and the console
  • JavaScript prototype chains
  • jQuery basics – used to make a simple Twitter clone
  • JavaScript classes and shared methods with functional, functional shared, prototypal, and pseudoclassical instantiation
  • Test Driven Development with Jasmine and Mocha
  • Object Oriented Programming: isolation, modularity, loose coupling, makers, mixins, subclassing, etc.
  • JavaScript event systems
  • Data Structures: hash tables, linked lists, trees, binary trees, sets, and big O notation

Wow, that is a ton of material now that I have it all together in one place. We implemented all of these bullet points in different sprints and projects this first week. I just hope I can retain it all in the weeks to come.

We also got to see the personal project presentations of all the students in the senior class, which is 6 weeks ahead of us in the Hack Reactor course work. Some of the web apps that were presented were very impressive, and I can’t wait to start applying some of my new knowledge to a project of my own. There seemed to be a few students that tried to tackle a project that was too ambitious for the time they had to work on it, and as a result we had to sit through presentations of projects with limited or incomplete functionality. I talked with a few of the senior students and they stressed the importance of limiting the scope of your project to start, then adding more features as time permits. Seems like a good engineering code to live by, in general.

Some resources I came across this week:
Coderbyte – small JavaScript problems with timers and scoring to practice your skills. A lot of fun and a good boost when you some a problem quickly.
HTML5 Conference Slide Decks – One of the presenters at the meetup this week, Dan Lynch, has his deck here, but it looks like tons of interesting content. I want to check it out when I have more time.
Fancy.js – A mashup of underscore.js and functional.js. Love the poker-themed demo.

Read more

Online Learning with Code School and Treehouse

In preparation for my time at Hack Reactor, I spent about 2 months learning on my own through various channels, both online and off.  I began with some basic books covering the fundamentals of HTML, CSS, JavaScript, web design fundamentals, and web standards. Most of these books, despite their best efforts, were fairly uninspiring. I ended up referring to them only when I need to quickly reference a particular topic. Even then, I was able to find a better solution that was more specific to the topic at hand on websites like Stack Overflow. I knew I was missing out on some key curriculum around each of these subjects, and I went looking online for a better way to learn.

After an hour of research, I decided to sign up for a couple of video-based coding websites called Treehouse and Code School. I tried some sample videos on each site and decided they both had quite a bit to offer in terms of boosting my current skill set. However, despite being in the same vertical of online web development training, each site has its own strengths, and I decide to sign up for both. What follows is my experience on each site.


I started learning with Treehouse first because their site is geared towards absolute beginners that would like to learn how to build websites from scratch. I was already designing simple sites on my own, but I felt like starting at the beginning would help me to fill in some knowledge gaps surrounding the fundamentals.

The Treehouse approach is to present you with a series of short video lectures on a particular detailed topic (like CSS selectors). Between each, or every few videos there is a short quiz or a short interactive coding challenge to test your skills. There are also complete web projects, like designing a responsive website, that walk you through building the site while holding your hand along the way. With these project videos, it helps to write code while the video is playing on another screen.

Treehouse also has a few different ways to move through the curriculum. You can select a broad topic like Javascript Foundations, or you can join one of the many Learning Adventures like how to Become a Web Designer. These Leaning Adventures are roadmaps through the curriculum that group together all of the broader topics and puts them in a logical learning order. I chose to go through the Become a Web Developer Learning Adventure and was very pleased with the pace and the depth of videos on each topic.

Treehouse has a huge library of videos on many different topics, from front-end aesthetic design, to Ruby on Rails, to iOS development, to how to start a business.


Code School
I started learning at Code School after I had spent about a month on Treehouse. Their curriculum is more geared towards people with some prior web design experience that are looking to learn a new language or expand their knowledge of a more advanced topic. Code School is also the resource Hack Reactor recommended as a good way to prepare for their fast-paced software engineering curriculum.

Code School has courses on topics not covered at Treehouse like Git, jQuery, Coffee Script, Backbone.js, and Node.js. Their most extensive video library is a thorough introduction to Ruby and Rails, with 9 separate modules currently. The first course I tried was called Git Real, and it was the best learning tool I had found online regarding what Git does and how to use it. I have run through 3 other Git tutorials online, and Git Real was by far the most clear and easiest to learn of all of these options.

My next modules covered the basics of JavaScript and jQuery. These modules did a great job preparing me for both the Hack Reactor prep work and the projects we have completed thus far.

Code School features very in-depth video lessons and extensive interactive challenges that put your newly learned knowledge to the test. Each video is about 5-10 minutes in length, and once the video is complete you attempt to solve the presented problems as their software checks your progress each step of the way.

Comparison & Tips
I can honestly say I would sign up for both of these online schools again, and I have current subscriptions at both sites. If you are new to web development and looking to learn the basic fundamentals of CSS, HTML, and aesthetics, I would recommend Treehouse to start with. If you are already comfortable with building simple websites and looking to learn JavaScript (and JS frameworks) or Ruby, Code School is the best place to start.

Personally I preferred the Code School course layout of short videos with in-depth, interactive challenges directly following. The Code School interactive programming environment is superior to the similar tool on Treehouse, and Code School uses it to “get your hands dirty” after every single video. You need be more accountable to yourself when working through the Treehouse videos because their tests and challenges aren’t as demanding.

On Treehouse, I preferred their Learning Adventures to the way Code School presents its courses. Treehouse also has a larger quantity of videos to choose from, which is why they have different ways to go through them all. I also like the interactive projects on Treehouse that leave you with a completed website by the time you are done with all of the videos.

For both sites, I found it helpful to keep a notebook with extensive notes and examples on each topic. I am constantly referring to these notes, even 2 months after writing them. Writing something down seems to cement the knowledge in my brain, but it does add quite a bit of time to going through the videos. I was having to pause the videos a lot to make notes and write down examples. It’s a lot of work, but you will be glad you have those notes in the future.

We live in an amazing time where so much knowledge is so readily available on the internet. These video training websites are extremely inexpensive for the depth of knowledge they contain. For about $25 a month you can expand your skillset to include entire libraries of things you did not know last month. Combined with learning at your own pace in your own house, they are far superior to basic web design classes taught at traditional universities. I wanted to take what I learned on these sites to the next level of becoming a full-fledged web engineer, which led me to sign up for Hack Reactor.

Both Code School and Treehouse are adding new videos and lessons to their libraries every week, and I encourage you to try a sample video at each, and sign up for both! You can never go wrong with learning some new skills.

Code School
Code Academy – free, without videos

Read more

JavaScript Basics and the Keyword “this”

I just finished day 3 of Hack Reactor and thought I would go over some of the topics I’ve learned so far. I will not have much free time from here on out, but I want to get down all of the important ideas I learn every few days.

Our main instructor, Marcus, has spent much of the last two days going over the basic building block of JavaScript in great detail. I’ve been using some of these JS structures for about a month now, but it’s been great to learn more about each one, and how they relate to other elements. We spent quite a bit of time on objects and methods, along with data types.

Null vs. Undefined
The two value types that cause the most confusion where undefined and null. What I took away is:

null: The language has checked, and this does not exist.
undefined: The language does not know anything about the object you are asking about.

Here is a deeper explanation of null vs undefined on StackOverflow:

Ternary Operators
Another topic I learned a lot about that I had never seen before is JavaScript ternary operators. It is another way to succinctly express an if/else statement in just one line. The basic ternary operator framework:

test ? option1 : option2

Test is any boolean expression that will be true or false. Option1 is an expression that will be returned if the test is true, while option2 will be returned if the test is false.

The JS this keyword is often misunderstood, but is very useful when constructing objects and methods. Basically, the keyword “this” is bound dynamically to the object found to the left of the “.” at call time. There a a couple exceptions to this, but if you look to the left of the “.”, you can easily see what this will refer to. A quick example:

person = {
  location: ‘SF’,
  locate: function(){
person.locate(); //alerts “SF

In this example, it is plain to see how “this” inside of the method relates to the person object when the method was called on line 7.

The first major exception to watch out for with “this” is instances where there is no “.” before the function or method call. In this case, “this” refers to the global object, which is the window. The next exception is when it is called with the “new” keyword, in which case “this” will be undefined (ex. new person.located //alerts undefined). The third exception is when it is used in conjunction with .apply or .call, both which are specifically designed to bind a function to whatever argument they are passed.

We also spent the last couple days going over our pre-course projects and the refactored solutions to see the best methods for completing each assignment. It was very eye-opening to see an experienced programmer solve these problems in real time in just a few minutes, instead of the many, many hours it took me to complete each one. I now have something to strive for!

Read more

Hack Reactor: Day 1

I made it to SF on Wednesday with a couple of suitcases and my new MacBook Air, ready to kick off the 12 weeks of programmer development at Hack Reactor. Today was the first day of class, and I finally met all of the other fellow students I will be sharing this experience with. There are about 20 students in this April 2013 class of varying ages, but the majority are in their mid to late 20′s. Backgrounds range from finance, to front-end web development, to biology.

Most of the day today was spent going over policies and procedures (free breakfast every day!), along with the basic Git workflow for Hack Reactor projects. They really stressed the importance of committing your code in Git about every 10 lines you write, or every time you fix a bug or add functionality. These frequent commits will make it easy for our future co-workers to figure out what we did, along with the ability to roll back the code to very specific points of the development in case there are future bugs or conflicts.

We also went over pairing, which we will be doing for many of our learning sprints. This basically involves working with another student on the same computer that has two monitors, two keyboards, and two trackpads. Both monitors show the same screen, and only one person can be typing or controlling the pointer at any time. This forces one person to be driving (writing the code), while the other person navigates (tells them what to type). It will be interesting to see how pairing works out for the more complicated projects that are in our future.

Class went from 9am until just after 8pm today, which is the standard schedule. However, all of the instructors mentioned that many students will be staying later to finish up projects and have one-on-one sessions with the teachers. First day down!

Read more

Hack Reactor Prep Work

I spent the last few days visiting San Francisco to check out Hack Reactor in person, and to secure housing for the next three months. I was able to find a great place to live bordering the Presidio Park in Richmond, which should be a fairly easy bike ride downtown to Union Square and Hack Reactor. I also met a few of the Hack Reactor instructors in person. Marcus took the time to work with me one-on-one to answer some questions I had about the prep work, which was super cool of him to do.

The prep work for Hack Reactor is designed to bring all of the students up to speed on some building block topics we will be covering during our first week. It is designed to be completed over 2 weeks, with Skype check-ins along the way to monitor our progress and help us out with sections where we may be stuck. Over these weeks I easily spent 100 hours on research, online tutorials, and writing the code for each section. The three main projects are to be submitted via a GitHub pull request so that the instructors can go over our code with us.

The first major component of the prep work included an introduction to Git, the version control software used in most professional environments. It allows engineers to work on separate sections of the same code base at the same time, and then merge their changes together without conflicts (hopefully). I worked through a number of online tutorials, the most helpful of which was the Git Real course on Code School. This course really cemented in what Git was, and how to use it.

Next up was re-building the popular underscore.js library components using JavaScript. I learned about all kinds of basic JS programming structures like loops, functions, callbacks, arguments, and conditional statements. This was the section I most struggled with because some of the underscore components are quite tricky. If you’re not familiar with underscore.js, go check it out and run through the wiki. I guarantee it will save you tons of time versus writing these building-block components from scratch.

The next major component of the prep work was building a more advanced version of the Twitter clone I built for my entrance exam. This one is called Twittler, and it required quite a bit of jQuery DOM manipulation. I completed both of the Code School jQuery courses to become more familiar with how to use selectors, animations, and DOM insertion/deletion. You can check out the my final version of Twittler online, which uses randomly generated tweets from a javascript function.

The third component was a basic computer science module where we learned about recursion and how to use it in JavaScript. Once I wrapped my brain around what was involved with recursion, the actual assignment did not take too much time to complete. However, there is still much to learn about this topic and how to leverage it in more powerful ways.

I just got back to Utah, but I’m looking forward to being in SF next week!

Read more

Starting the Journey

On March 30th I found out my life would officially be changing course from my previous path. That was the day I heard from Hack Reactor about my acceptance into their very intense program for creating software engineers over the span of only 12 weeks.

Let’s back up to the end of November 2012. I had decided that I no longer wanted to pursue a sales or purchasing career at the company I had worked at for the last 4 years, My time there had been amazing, and I was given the opportunity to lean a lot of new skills by advancing through different departments. However, I was spending more and more of my free time building websites and adding new features to sites I had built over the last few years, and I had decided to become a web devloper/engineer.

After leaving SoftwareMedia, I focused 100% of my energy towards learning web development technologies, best practices, and basic design techniques. I bought books as entry-level primers, then moved on to video learning through sites like Team Treehouse. The curriculum at Treehouse is perfect for anyone looking to start building their first website right away. The guided projects hold your hand through the steps required to get your first site launched. You can then move onto building more complicated sites using responsive CSS, interactivity with JavaScript, and even using frameworks like Ruby on Rails.

My main learning environment for techniques outside of the books and online videos was trial and error with a site my wife and I had started in 2008 called Ski Town Restaurants. Using techniques I was learning for writing HTML, CSS, and PHP, I would decide to build a feature, spend a few hours on Google trying to figure out how to begin, then hacking away at the code until it worked.

I had also begun building websites for friends to put my newly learned skills into practice, and to force myself to problem-solve on the fly. This worked great to expand my knowledge further and to put into practice everything I was reading about online. You can check out Northwest Represents and the wedding website of Janine Reinhart to see what I’ve been working on the last couple of months. Both are fairly simple website based on a WordPress back end, but it was good to get experience with working with clients that have their own expectations and design requirements. It was also eye-opening to see what the feedback/revision cycle is like.

Learning online by yourself can definitely have its challenges. The shear size of all the information online about learning web development is especially daunting. It is hard to figure out what to focus on and what a good path through all of the material looks like. I started doing research around going back to a traditional university or maybe a web-specific four year program, but neither option was appealing because of the time commitment required.

I was listening to a podcast on the 5by5 network one day and they were interviewing a student from Dev Bootcamp, who was talking about their 10-week program for Ruby on Rails. I did some research, and realized that there were many other schools offering similar bootcamp-style learning experiences for learning how to program, in a variety of languages. I spent the next week filling out applications and doing Skype interviews for a few different schools, including: Dev Bootcamp, Hack Reactor, Launch Academy, and App Academy. The entrance process for Hack Reactor was especially tough, with an online application, a first Skype interview, followed by an online class, a technical interview, and finally a take-home JavaScript project.

The Hack Reactor entrance project was the first time I had written any real application in JavaScript, and it was a very tough undertaking. I spent about 30 hours on it over 3 days, which included tons of online research. The goal of the project was to re-create a basic Twitter feed using tweets generated by Parse, and accessed through their API. It was also my first  introduction to writing jQuery from scratch. I completed the project and submitted it to Hack Reactor, feeling good about what I had learned and about my chances of being accepted.

After hearing back from all of these schools, I ended up deciding to attend Hack Reactor. Their program of having class 6 days a week, 11 hours per day, for 12 weeks included way more classroom time than any of it’s competitors. My goal is to become as much of a full-stack developer as I can, and that means being to exposed to more than just Ruby and Rails like most of the other schools. Hack Reactor focuses on JavaScript to teach the basics of programming and computer science, and then branches out into Git, Backbone.js, Node.js, Ruby and Rails, jQuery, TDD with Jasmine, and much more. One of the founders of Hack Reactor, Shawn Drost, had a great post about the future of JavaScript and the goals of Hack Reactor, if you are interested in learning more:

I am heading to SF next week to check out some housing options, and then I’ll be going back on the 24th to get moved in before class starts on the 26th. This blog will chronicle my time at Hack Reactor, and all of the concepts I’ll be learning along the way.

Read more