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!
Sessions Encrypted passwords are great for verification but what about when the user navigates between pages of your app? Do you make them login each time or do you assume that it’s the right person? The tool for this is to use session tokens. A session token is a unique identifier that is sent from the server to the client to identify the current session. Browsers store these in cookies and automatically send them to the server each time you make a request to the server. As a programmer, you only need to worry about generating tokens from the server. You’ll have the ability to determine how long a session lasts (banks use something around 10 minutes, email services are probably 2 weeks). Sessions and password hashing used to be a big pain for developers to implement but now there are plenty of middleware niceties that will bootstrap you to success. Check out this tutorial for doing auth and sessions in express (node).
Sprint 2: Deployment
Time to go live on the web! Push the go button. Just kidding, it is way harder than that to deploy your app – and it is a huge pain to set up. The code we’ve been writing was in the “development” environment. Deploying code to a “production” environment means running it on a remote computer that is available to the internet. Also, development code is meant to be modularized and easy to read, whereas production code should be fast and compact. Here are some common gotchas that you’ll have to patch before you can fly on the web:
Inability to scale because of unconscious design: your code worked when you were banging around on your computer, but what if 10 people try to access your server at the same time?
Hardcoded assumptions: certain variables in your app will need to be hidden (API keys, passwords and other private things) and certain variables will change once your code is hosted on a server (port number and paths); you’ll have to set environmental variables on your your server and make sure all your file paths are relative
Failure to design a debuggable app: sometimes things work on your computer but not on a server – if you didn’t build in error handling in your app, it can take you hours (maybe days) to figure out all the weirdness
Lack of deployment automation and testing: there are many many steps to pushing code online (compressing code for speed, testing for bugs so it your app doesn’t break as soon it is live etc.) use a build tool
Build Tools and Deployment Tasks Build tools automate repetitive tasks such as…
- Minification: minification removes all the unnecessary spaces in your code and compresses your variable names by swapping them out for letters – thus saving space and increasing load time (example:
var robotNoise = 'beep boop' --> var a='beep boop'coverts 28 characters to 17)
- Testing: it is good practice to run your tests before each deployment (or even after each change)
- Linting: linting catches syntax errors in your code, consider this another test to make sure your code is clean
Many of these tasks are optional but they will significantly increase your quality of code and productivity. I think and take you from newbie dev to a mature dev. The two most popular build tools at the moment are Gulp and Grunt (Grunt has been around for longer meaning it has more packages but Gulp’s syntax is making slightly favored amongst the dev community). Follow this tutorial for Grunt and this for Gulp.
Sprint 3: Angular
Angular is an MV* open sourced framework maintained by Google and the community. It uses a very opinionated approach which makes it easy to build single page applications (SPAs render an index.html page then do all templating and routing on in the front-end rather than the server). The tradeoff is that it is less flexible than frameworks like Backbone. The coolest thing about Angular is 2 way binding: the model automatically updates the view and the view automatically updates the model using built in listeners so you don’t have to worry about it. The downside is Angular is relatively new and testing is a bit tricky. If you run into a problem it may be difficult to get help or you may have to wait a while for feature requests. Learn how to use Angular through this beginner’s tutorial from ng-newsletter or through these video tutorials from egghead.io (tip: start from page 10 of the videos and go backwards).
…and that ends the first half of Hack Reactor! We’ve learned a lot of material but the most valuable part of this half was building a strong foundation and getting to the point of independence. At this point, I feel comfortable that I will be able to learn other concepts and new frameworks/languages by reading the docs or doing self study; prior to Hack Reactor that would have been a huge struggle. Onwards to putting all this knowledge to use!