We decided to go with a mobile first approach for Pawprint and the time finally came last week to get the Pawprint mobile app into the hands of testers (if you are interested in joining our beta, please sign up at http://getpawprint.com/).
The brave and/or reckless would submit to the app store directly but we are testing out all our processes and ironing out bugs first. This means learning and wrestling with the Play Store and the App Store beta processes – no simple task I assure you. This blog post is NOT a step-by-step tutorial (there are a million out there) but rather a guide on how to sail smoothly through this process by following the right tutorials and how to avoid some common pitfalls. This will serve you best before you start the process at all so you have a clean slate.
Deploying Play Store
A reader reached out to me about my experience at Hack Reactor and I thought I’d share them as a Q&A with you all. Please feel free to ask additional questions in the comments!
11/3/14 update: More questions and answers added!
Q: How did you like the learning experience at HR? I can only imagine how tough it is working 12+ hours daily for 12 weeks. What was the most challenging part of your experience at HR?
A: It’s tough to keep the hours, they advise that you shut down all other parts of your life except sleep and working out which I definitely agree with. The focus is what allows you to accomplish so much in such a short period of time. Paul Graham of YC wrote a great post about the importance of not context switching too much. Additionally, the support system here is amazing. There are plenty of resources around (the hacker in residents, industry professionals, alum, a senior class) and the fact that your peers are all so dedicated makes it easier to keep pushing.
Quick tip: It’s important to learn the process of learning to code rather than brute memorization, this will save a lot of time and make you a better programmer in the long run. Continue reading
Week 6 was the start of the “apprenticeship” program aka projects and the start of the job search. To kick it off, we had a 2 day solo hackathon where everyone chose their own project to hack on for 2 days. The goal was to “finish something, finish anything” and the project served as a reality check for what each person was able to accomplish in a 2 day sprint.
Here is the final product, click the image or go to http://collegeroi.emilydee.com/ to interact with the chart.
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
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
How to use Node:
- Installation: do not use brew install node (some weird stuff happens, consider yourself warned), instead use nvm (Node version manager) or follow these instructions
- 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.
- 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.
- 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
- 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.
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
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:
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
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