Will Chen

Having completed Hack Reactor in December 2014 - I've decided that now is a good time as any to write a review. Initially I wanted to hold off writing a review because I was skeptical if I "really" learned that much and wanted to see if I would be well-prepared working as a software engineer in the real world. I just started a new job as a front-end software engineer at OpenTable a couple of weeks ago and I can honestly say that Hack Reactor was as good of a preparation as I could have hoped for.

One of the best parts about Hack Reactor is that it not only teaches you very practical skills (e.g. using Git, Grunt, and various other command-line tools) but it also helps you develop a working foundation on CS (e.g. data structure and algorithms). Like many others have pointed out, the curriculum is well-designed and you will be surrounded by motivated classmates (many of mine had worked as professional software engineers prior to Hack Reactor, and I ended up learning many things from these classmates among others).

I'll be honest, there were definitely a few bumps along the road: the internet connection went down and was unreliable for a while, some of the lectures were personally not very helpful for me, and in my opinion there's too much structure in some places (e.g. requiring students to be on-site at all times, strictly enforcing 9AM attendance after staying late coding the night before).  

Overall though, it feels nitpicky to complain. Before I went to Hack Reactor, I was working in a totally different industry as a management consultant and had a tiny bit of programming experience. After graduating, I was able to find a job in about a month and feel confident about picking up new skills as I develop as a software engineer. I know Hack Reactor always talks about this idea of "learning how to learn" and it sounds cliche but it's so true. At the end of the day, web development is evolving so quickly, the real value of Hack Reactor is not that you learn the latest MVC frameworks such as Backbone.js and Angular.js (and they are), but it's the ability to pick up a new framework, tool, or language on your own because you've been doing that non-stop at Hack Reactor for three months.

If you enjoy programming and want to make a career out of it, I can't think of a better or faster way than Hack Reactor.

So I decided to somewhat impulsively start blogging using Post Haven after using Ghost hosted on my Microsoft Azure VM.

The three selling points were the clean user interface that Post Haven comes with, the fact that the posts will permanently stay online even if I discontinue paying, and that I'm too lazy to properly backup my Ghost database which is stored in a little sqlite file.

I'd like to going forward blog about these topics:
- how to solve specific issues with scaling Web applications such as testing, i18n, and more
- reviews on various web technologies particularly Javascript libraries
- links and reviews on good articles, talks, and books that I read about software engineering

I am a software engineer working at OpenTable. My focus is on developing full-stack Javascript web applications using technologies such as Angular.js and Node.js. Previously, I worked as a consultant at Deloitte advising organizations on operations and IT strategy. I studied software engineering at Hack Reactor and received a B.A. from University of California, Berkeley.

Backbone is a popular Javascript library that provides an MV* framework.

The three main types of objects in Backbone are:

1. Models - Objects that includes data and behavior/interactivity related to that specific data
2. Views - The visual representation of a model at a particular time through a DOM node (which may include children DOM nodes
3. Collection - An array-like container that holds multiple models. Typically you will use a container to hold multiple instances of the same model class.

Guidelines on using Backbone:

General

• Backbone depends heavily on its eventing system which allows the developer to decouple different modules of the web app

Views

• The visual representation of a model through a DOM node
• Views can only be binded to one model or collection at most
• The view is only responsible for a few things:
  • Rendering its binded model / collection as a DOM element
  • Listening to DOM events (e.g. clicking a button) and invoking a method on its binded model
  • Listening to Backbone events from its associated model/collection
• Views have a tree-like relationship with other views. While each view will only have one parent view (e.g. an AppView might instantiate a SectionView which renders a DOM node that fits into AppView's DOM node)
• The properties template and render are conventions in Backbone, however are not necessary
• If a view is not binded to a model or collection and is not rendering dynamic content, it is worth examining whether the view should exist. can the static content be included in a parent view or just in the DOM as regular HTML?

Models

• Models do not have a relationship with their view. While views have a property such as this.modelor this.collection, models cannot directly (or at least should not) directly access to their views

Collection

• Collections cannot hold attributes. They do not have the get or set methods, unlike models.

Events

• You can listen to multiple events in a single listener by listing multiple events with a space in between. For example, if you wanted the listener to invoke its callback function whenever a collection added or removed a model, you could create a listener like this.collection.on('add change', callbackFunction, context)
• Backbone's event system was designed to mimic the DOM event system but there are some differences. One of them is that the DOM event system passes in a special type of DOM event object into the callback function.

State-less HTTP and the Reason for Cookies

Cookies are commonly used but also commonly misunderstood. They allow servers to instruct clients to store specific information, such as session ID or token. Cookies were created to address a deliberate aspect of HTTP, which is it's explicit design goal of being state-less. In theory, because HTTP is state-less, if a hundred different users, accessed a given URL, they should all receive the same information.

While this provides an enormous benefit in many (if not most cases) because there is a predictability of what a user will get when they access a URL. For example, you could search something on Google and copy that URL and give it to your friend, and in theory s/he would see the same search results.

In the early days of the Web, software engineers began to realize this state-less aspect of HTTP made it challenging to enable users to shop online. Without keeping track of whether a user is logged in or not, everytime a user would want to add an item to their shopping cart, they would need to re-login. Clearly there needed to be a better solution to this.

Cookies were created to address this issue by allowing users to send a user-specific ID with each request so that the server would know to respond with the correct user's information.

A Brief Authentication Example Using Session ID

To explain how cookies, session ID, and authentication works in Node.js and Express.js. Let's use a hypothetical to-do web app.

When you open up Chrome and log into the web app, the server creates a session object that has a session ID property that's a unique string. The server then instructs in the response that your browser should store this session ID as a cookie on your computer. Typically cookies that store session ID are set to expire as soon as the session ends (i.e. when you exit out of Chrome). While the server sends you the session ID, it will not send the entire session object and will modify the session object by storing information such as username, date accessed, and etc.

Now that you are logged in and have a cookie with a unique session ID, whenever you go to a new page on the web app, your browser sends a request header that includes a cookie property, which is a string that includes the session ID. The cookie property on the request header is parsed by the server and the session ID is matched to a session object using a key-value store (e.g. Javascript object).

On the matched session object, the user's ID, and session information (such as last products visited) can be accessed.

Additional resources:

• Express-Session node module
• OWASP Session Management Cheat Sheet
• JSON Web Token (JWT) - Popular alternative to using cookies