Once you skim the books and acquire as much as possible from them you can start programming.
The way I teach is by using examples and real projects. I believe that is the best way to learn. I recommend picking a problem you have and creating a software solution for it. If you picked the Learn Python the hard way book to start you can create basic API’s and create very simple solutions for it. If you want it can be a terminal application as well but the most important thing is to use what you write so you get the feel for bugs, fix them, add features, etc.
Once you’re done with the reading above and you can answer simple questions like:
What is a variable?
What is a function?
What are APIs?
What is a network request?
you can start learning JavaScipt. I’ve written a comprehensive guide on how to JS like Infinum does here.
Getting a job at Infinum as a Junior
We employ juniors all the time and they probably know as much as you do (if you read all of the books above). I won’t give you the interview questions since they are specific to you and your knowledge but as a helpful guide look at the questions below and see if you can answer them. If you can you’re good to go!
Pick one sorting algorithm and explain it.
What is a database?
Pick one design pattern and describe it. How would you implement
it in JS?
A note: views expressed here are mine and mine only. In no way this represents Infinum, but it does affect the way I teach at Infinum Academy. I take great pride in that. If you don’t agree with me – that’s fine and I would like to hear you out. Tweet at me, or email me :). The end goal is to help people.
If you’re gonna stop reading now and comment anywhere – comment on this statement: “start with anything.” You can start with either of them or even something else (my first JS project was Backbone.js). Teach your self the basics of the language and learn to avoid the pitfalls of endless Twitter/Hackernews/Reddit debates “my framework is better than yours”.
Importance of having a stable base
When you pick a framework to work with you undoubtedly pick a community too. You’ll probably want to follow people working on the same tool as well, maybe even listen to a podcast, subscribe to a newsletter. What you are doing is fine, really! – but understand that you are entering a huge echo chamber.
What you are also doing is perpetuating the self-generated discussions how your tools are the easiest to learn (OMG just look at how I can make a component with zero boilerplate), or even how performant your language is (0.545345ns first paint!!! #perf). What also happens inevitably is commenting on how your tools are the best! And again – all of this is normal!
But(!), you’re also never learning about other tools and what they do good or even better. And this is really bad – for you and for your community.
There is a time and a place to worry about performance and boilerplate – but that time is not when you’re just starting out.
I’m really proud of two of my past students, now colleagues and friends. Both of them started with React, but now are proficient and working with Angular and Backbone respectively. If they spent time discussing and going back and forth between frameworks, or even (and this hurts me to write) listened to influencers preaching a framework other than what they chose and then kept switching they would not be where they are now. And I’m glad to say that they are both very respected members of the JS team.
To a junior dev
Whatever you start with is fine. Also, it’s fine to start with a framework that has the cutest logo (the only reason I started learning GO). Just stick with it to the end and you’ll be able to pick up any framework that you wish later. Stop focusing on why JSX sucks, or why vuex is a terrible choice for beginners.
For those just learning to code now- remember when you were learning to drive? You had to think about everything constantly- but eventually the car became an extension of yourself. That’s how it will be. You will eventually have muscle memory built into many tasks. Stick with it.— Sarah Drasner (@sarah_edo) April 3, 2018
Spend that time building and learning so one day you’ll be able to pass that knowledge onto another person. And maybe, just maybe, we can focus more on our end users and our products a bit more instead of angry tweeting about webpack vs. fusebox, angular vs. react, …
Not so long ago I was also one of the people defending my choice over other. I was wrong and I’m making sure to make an effort now to invest time into understanding what the base should be. At the end of the day it’s just a tool; you can use one but don’t be one.
I have a getting started guide written over at Infinum’s blog. It still is what I think a good starting point is, and what I’ll recommend if you ask me. This blog post doesn’t change how I feel about the one published on Infinum’s blog, and vice versa.
Point of this document is to get you up and running. We will explain the basics of how PGP works, setup on MacOS/*nix systems, encrypting/decrypting data, and the process of signing and verifying messages.
Please note that once this document is more than a year old you will need to recheck all of the things mentioned here.
Last edited: 09/02/2017
There are a few ways you can setup PGP on your computer, some will include a wider set of tools, and others will cover only the basics. You might want to have a look at Keybase.io, OpenPGP, or GPG suite. Today we will focus on gnupg – it will provide all the needed tools in a compact form.
MacOS brew install gpg2
on other systems install the latest version of gnupg
You need to define a pin entry application. Do the following after installing gpg2:
Importing keys is also really easy. Let’s presume that the key we saw before is saved in the file called andrei.asc.
gpg --import andrei.asc
Each key should be signed. When generating your key, you sign it by default. After exchanging keys with someone you might want to sign theirs and upload it to a key server (more on that later). You can sign their key like this:
gpg --edit-key email@example.com sign save
Be sure to sign their key only if you trust the source where you received it from. Usual places would be other people servers (like this one), Facebook, etc.
Uploading to key servers
Keys are usually uploaded to a key server for others to get and upload. You can upload yours and other people keys. If you signed their key When uploading it, you are making that public.
Substitute F611EAEFA07D5401 with either your key ID or your friend keys ID.
In this example I used pgp.mit.edu. You can use it or any other key server. Note that you can also use Keybase, but the upload procedure will differ. Also, now you can host your public key on Facebook as well – add it here.
When you encrypt a file you need to add all of the recipients or else no-one will be able to open it. If you do not add your self you will not be able to open it.
gpg -e -r firstname.lastname@example.org my-file.txt
You can now send my-file.asc via email or Slack. More recipients can be added by adding -r <email> as many times you need.
If you got a file that is intended for you you can decrypt it using the following command:
gpg -d my-file.asc
And, provided that you have the correct private key you can now read the contents.
If for some reason you need/wish to provide proof that it’s really you who have sent the message you can sign any file following this commands:
gpg --clearsign <file>
this will create a file with the same filename but the extension will be asc. This file can be distributed around. It’s contents are in plain text but it contains the info about who signed the message and if the message was changed in any way. Your message might look something like: