HR Week 5: Authentication, Deployment and Angular

And we’re live! Week 5 we learned about authentication, deployment and Angular – which allowed us to deploy some full stack apps. Sadly, this was our final sprint week, but we’ll be working on some cool projects after this.

What we covered this week:

Sprint 1: Authentication

Passwords and encryption The problem of authentication is how do you verify someone’s identity so that you only show them the things that they are allowed to see? This is a pretty tough problem and hackers are getting better at cracking passwords everyday. The thing to note here is that any password can be calculated by brute force so the way to create security is to make brute force prohibitive. That means making it so difficult to figure out the password that it isn’t worth it for the hacker. The most common way to do encryption today is to use a salted hash. A popular library for incorporated salted hashes into your app is bcrypt (utilizes the blowfish cipher, this encryption method is the new hotness AND its open sourced), check out the node module for it here. Keep in mind that this method of encryption is probably going to be outdated in the next year or two! Continue reading

HR Week 4: Servers & Databases

This week we started adding “backend” magic to our applications. I’m specifically using the word magic because things got a bit mystical when we started working with certain libraries and frameworks. The instructors at Hack Reactor often say part of being a software engineer is knowing when to “ignore the complexity” so you can avoid rabbit holes and focus on the goal in mind. That was an especially important principal this week.

What we covered this week:

Sprint 1: Servers and Node

In this sprint, we used Node to build a custom back-end. Node is an open-sourced platform that makes it easy to build scalable networking applications because it uses asynchronous, non-blocking I/O. The key here is it offers asynchronous abilities on top of Javascript, a synchronous language, and in practice gives you the ability to write a full stack application in Javascript.

To understand why this is awesome, you should first explore the Javascript event loop. All Javascript code is synchronous and blocking – meaning line 5 of your code won’t run until line 4 is finished, however long that takes. In asynchronous code, your application can run a line of code, do something else while that code runs; you can also attach more code to be run when the first line is finished, this is called a callback.

How to use Node:

  1. Installation: do not use brew install node (some weird stuff happens, consider yourself warned), instead use nvm (Node version manager) or follow these instructions
  2. Get packages: npm (Node’s package manager) is incredibly rich and very well supported. One of the benefits of using Node is the community, you can find a package for almost anything. In addition to that, npm helps you manage your dependencies so you don’t have to deal with things like virtual machines.
  3. Use packages: Node uses the CommonJS pattern for including packages. Simply use the syntax var _ = require(‘underscore’); to include packages in your apps (replace ‘_’ with the variable name you want to use and ‘underscore’ with the package name.
  4. Node command line tools: npm installs all packages locally to your app by default. There are many command line tools written in node (ex. nodemon), these must be installed globally using the -g flag.
  5. Debugging: type node debug <file> and it will open up a node chrome developer like tool (if you console.log there it will log it in the terminal because its happening on a new server)

Note: Node is currently in a pre-version 1.0 release, despite that it is being utilized by big players like Paypal and Uber – in short, a signal that it is pretty awesome.

More tools! Express is an application on top of Node that makes Node much easier to write. If you google for how to do things in Node, most of the responses you’ll find will pertain to Node with express. From our experiences in class, I definitely recommend using express and not bare Node in most cases. Here is a quick intro to express and all of its magic.

Continue reading

HR Week 3: Browser Apps, Intro to MVC and CoffeeScript

In week 3, we got a little farther past the basics and started working with frameworks and servers. Our sprints looked a lot more like usable apps! We built a simple chat app and a music player.

What we covered this week:

Sprint 1: Browser Apps, jQuery and AJAX

Setup
When creating an app on the browser, a few additional things come into play, one of which is package management. Unless you build everything yourself, your app will need libraries and its operation will depend on specific versions. To avoid “dependency hell” (where updating a library for your new app breaks an old one etc.) use a package manager. Package managers are used to install, upgrade, configure and remove dependencies (aka the external libraries/modules your code can’t run without). There are a number of these out there and most have a specific purpose. Below are some popular ones:

  • Homebrew – the mac package manager, primarily used to install global executables on your mac
  • npm: aka “node package manager”, used for server side dependencies
  • Bower – a front-end package manager, used for client side dependencies

Note: both npm and Bower will not only install packages in your project, but also create a file in your project if you use the –save flag. This file makes it easy for any collaborator to download all the necessary packages to their machine.

Rendering what the user sees
Rendering is anytime you go from one representation of something to another (generally a string) using a system. Here’s what happens when a webpage is rendered:

Continue reading

HR Week 2: Classes, Algorithms and D3

In week 2 we expanded on instantiation patterns to creating classes, got our hands dirty with algorithms and started using an open sourced charting library (d3). We are settling into a regulated pace where each week is broken down to 3 sprints. Each sprint covers an overarching theme and is tied to a project that we execute in pairs. In addition to sprints, we start off every morning with toy problems (these are typically common interview questions) and we start off every week with a self-assessment. These are a lot of fun and have been great for tracking personal progress even though we don’t get graded.

What we covered this week:

Sprint 1: Subclassing

A class is any construct that can produce a fleet of similar instances–objects that conform to the same interface. @mracus

Classes are blue prints from which objects are created. In addition to that, classes can be used to create hierarchies where a subclass inherits properties from a parent class. Kind of like biological classification: a polar bear shares all of the properties of a mammal plus additional properties of its own. This can be done using the techniques described in last week’s post. There is large debate in the JavaScript community on using prototypal versus pseudoclassical instantiation. By nature, JS is a prototype language (where relationships are created through delegation) but because people attributed JS to Java, the writers were pressured into creating a mask for JS to make it look more like Java, a class-based language. Thus pseudoclassical was born and to date, remains the industry standard. More on what prototype vs pseudoclassical instantiation is here and a visual representation here. Important note on pseudoclassical: This style utilizes the keyword “this”. You cannot assign anything to it because JS does this internally, but you can use it to reference a context in your code. Here are the 2 most important rules to keep in mind when you use or see “this”:

The keyword this generally refers to the object to the left of the dot AT CALL TIME of the function referencing ‘this’. The keyword ‘’this’ can’t possibly mean anything until the function it appears within is running. @mracus

Continue reading