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
Week 1 went lightning fast! It feels as if we’ve covered an entire semester of a college CS program already. For the next few weeks, I’ll post all the topics we covered at Hack Reactor and go into depth on one that I find particularly interesting and important. No deep dive this time around due to the unique density of this week.
What we covered this week:
How to succeed at HR, pair programming effectively, what’s it like to be a developer Setting up your dev environment & shortcuts to make you more efficient (details on each of these topics to come in future posts)
- Recursion: A function that calls on itself, see below for a brief definiton. Here is a great example.
A task can be solved recursively if, after a little bit of the processing is completed, the remainder of the problem has a structure that remains equivalent to the original problem.” @mracus, Head HR Instructor
- Scopes and Closures: A scope is the context of a variable and a closure is a type of scope. More on that here – pay extra attention to problems that may arise from JS’s funny way of variable and function ‘hoisting’.
- Underbar: This was pre-course work we did in preparation for HR and reviewed in our first week (very good for people looking to apply to HR). This is an exercise in rebuilding and understanding what goes on under the hood of the popular JS library Underscore. For finance/non-technical folks, I would think about this as rebuilding some of Excel’s functions such as sumifs and vlookup.
- Function binding, call and apply: these are all ways you can invoke a function. Use bind(function, context) to guarantee that a function will always be invoked in the context listed. Use call when you want to pass in arguments to a function and you know how many arguments you have. If you don’t know, pass in an array of arguments (of any length) and use apply – a way to remember: “A is for array AND apply” @epic_science
Learn to code! Because apparently programming is now so cool that parents want it to be a their baby’s first language
Step 1: Fundamentals of CS
I started by jumping into lots of online tutorials that promised to be the easy, quick way to learn programming. It was a complete waste of time and none of it made sense until I took the time to learn some basics about CS. There are many MOOCs out there that from elite universities and many different languages that can help you do this. I personally took and recommend Stanford’s CS106a: Introduction to Computer Science because the professor is hilarious and keeps you engaged but any intro class from a university will serve this purpose. Don’t spend too much time picking the language to learn in (I made this mistake and let me tell you, it matters very very little), you just need to know universal principles – what is a method, what is a class, how do I use if loops?
Note: if you choose the class above, it is now available as a Udemy course but I recommend going through the link above, downloading all the handouts and assignments, and following the syllabus. I made myself finish this in 3 months and treated it like night school afterwork – otherwise I don’t think I would’ve ever gotten through it.