git is a version control system that allows you to keep track of all the changes you make to your code, writing and anything text. Instead of saving the current state of your files, git saves the changes you make to files.
Imagine you create a file called “my_file.txt” and later this to your git history.
This change will look like this.
`— /dev/null` means this was created out of nowhere (a new file)
`+++ b/my_file.txt` is the name of your new file
Platforms to host git projects:
Github, Bitbucket, GitLab
Step by step
Create an account
Create a repository
Create a new git repo on your local machine
git status – to check your status
Direct your local repo to track a git url (your new repo)
Commit your changes
git add <file_name>- to add the files
git commit – to track a change
Add your commit message (“yay first commit”)
Push
Git has a ton of gotchas that can trip up a beginner:
Our team at Hack Reactor is building a web framework in Rust and for the first day, we took a step back and had a one day hackathon to get sped up. Naturally I wanted to benchmark calculators and that afternoon I tested Rust against Python and Javascript. Results below.
Black Scholes Merton
Introduced in 1973, in a paper entitled, “The Pricing of Options and Corporate Liabilities,” the professors put forth a derivatives pricing model that led to the Nobel Prize in Economics. This pricing formula gives a theoretical estimate of the price of European call and put options and makes many assumptions to achieve this. I am using this as a fair way to compare the three languages.
Why Rust?
Rust is a systems programming language that runs blazingly fast, prevents almost all crashes and eliminates data races. It features pattern matching, closures and type inference while providing guaranteed memory safety and optional garbage collection. But most importantly… its blazingly fast.
Benchmarks
Python has been increasingly gaining in popularity in Finance for the benefit of developers. Its got amazing statistics libraries and its nice to read. After testing 1M iterations of Rust, it handedly beat Python by 26.87% with each operation taking 3.57 seconds to calculate Black Scholes. If speed is your concern but you still want high level functionality, check out Rust!
Javascript
7.22222 seconds
Python
4.88832 seconds
Rust
3.57484 seconds
*Rust and Python are run with no optimizations. and Javascript was run in console. Node was much faster and the optimized versions are much faster Code is here
Imagine you’re playing Mario Kart on a four person split screen. There are four Yoshis on the screen for each player. How many Yoshis should we model?
The obvious answer is four: there are four Yoshis on the screen, so there must be four Yoshis. The problem is that this answer misses something important, and fails to answer a critical question: what if there were no Yoshis on anyone’s screen right now? Does that mean there should be zero Yoshis? No, of course not, Yoshi can fall behind in the race and should still exist.
The real answer is there is only one Yoshi – one source of truth that dictates where Yoshi is, how fast he’s going, what items he has, and what he’s about to do. Fundamentally, all this means is that Yoshi exists separate from his representation to the user. We can organize our code to represent this by grouping our data about Yoshi in a single location.
Mario Kart on Super Nintendo
Models as the source of truth
Models are used to encapsulate data. A Model stores data properties and serves as the ultimate reference in other parts of our game. In our example Yoshi, Mario, Bowser are all Models – they have a single state and source of truth that’s associated with them. With this distinction we avoid searching for information on multiple Yoshis or creating logic to determine which copy of Yoshi is the most updated version of our racer.
Models are isolated from the code that displays the screen to the user so while Yoshi may turn a corner and disappear from the screen, our game logic continues figuring out how fast and far Yoshi has gone. We decide what to show users through building Views.
Views as Lakitu
Imagine all the Lakitus filming the race
Views decide what to show the user. Each View is associated with a model, and decides exactly how that model should be shown on screen. We wouldn’t want to just show the user all the stats about Yoshi, we want to make it a cute green dinosaur in a cart that you can see and aim at – View’s make that happen.
You can have lots of Views for a single model. For instance, even though there’s one Yoshi there’s actually up to four Views associated with him! In regards to Views, four is actually the right answer. Our Model for Yoshi has only one location and one speed, but our View shows him in four different places on each screen and renders him going in different directions depending on where you
If we began to store information about Yoshi in the graphic, we run the risk of creating data inconsistent with our original source of truth. What if there are multiple Yoshi graphics? By separating the storage of data from the representation of data we ensure that all players see the same Yoshi.
Events as a Blue Shell
When Bowser grabs a blue shell and throws it, this is a global event that every racer wants to know about. A smart group of Views will have event listeners on its respective Models. Smart Views can listen to events from the Model such as a ‘change’ or ‘add’ event. As our Models pass these event notifications to our Views, the screen responds by showing the player a blue shell rushing towards first place.
Our method of drawing data becomes increasingly more important as we add online players to the race from Mario Karts game servers. Having one source of data ensures that every player has a uniform experience. As there is only one Yoshi, there should only be one tweet, wall post and chat message that our Views are listening to.
Libraries and Frameworks
Concise code lends itself to become more reusable and testable. Our clear sense of separation and organization allows us to write modular code that is focused on clearly defined tasks. Every library and framework implements this differently and it will take some exploring to find the right fit.
The keyword `this` is a difficult javascript topic that has been debated and pondered over for centuries – more or less. Its meaning is ambiguous at first glance mainly because what the keyword `this` refers to changes depend on where it is called. Here we explore some of the various ways in which this will be changed throughout your use and we will use the NBA as the backdrop to the conversation. * Feel free to open your console in Chrome and follow along with the examples. The global scope is the NBA. If we open up our console in Chrome and type this, Chromes returns back the window object – or the NBA in our context. The same occurs with console.log(this).
Free Floating Functions belong to the NBA
function whoIsThis(){
console.log(this);
}
whoIsThis(); // returns current context;
When we call a free floating function like this, the keyword `this` is assigned to the context in which its called. If we type whoIsThis() in our console, `this` refers to the our global window scope. If we tried this in server side code, the keyword this refers to an internal node.js object.
Players and Methods use this Lets create Kevin Durant. Kevin has a method that references our whoIsThis function from above.
If a function is invoked as a method of a player/object the keyword `this` now refers to the player. Type `kevinDurant.findOutWhoIsThis()` in the console and the function returns the object! Remember, keyword `this` is set at run time. Using the same whoIsThis function above, `this` is now Kevin Durant and not the NBA.
Steal moves with Apply and Call Lets create a function to shoot 3 pointers
var shoot3PT = function() {
if (this.shoot3pct === undefined) {
return "Error: NBA has no 3pt percentage";
}
if (Math.random() > this.shoot3pct) {
return "3 points for "+ this.jersey +"!";
} else {
return "Shot missed, try again!";
}
}
Try calling `shoot3PT()` in the console. Error! The first argument of the apply or call functions will set the context of the function. Since KD has a shoot3pct property, we will simulate a three point shot by Durant with these functions.
shoot3PT.apply(kevinDurant)
// or shoot3PT.call(kevinDurant)
// both simulate a 3 pointer
Nightmare mode: Remember we can always refer to `shoot3PT` as a method on Kevin Durant. Imagine another player, say Stephen Curry, wants to also use that function. We could use `apply` to set the context to him.
kevinDurant.shoot3PT = shoot3PT
stephenCurry = {
this.shoot3pct: 0.99,
this.jersey: "Curry"
}
// Here we call apply on a method
// from another Player object!
kevinDurant.shoot3PT.apply(stephenCurry)
Stephen Curry is the context for the shoot3PT function because of apply. Think of the possibilities –
We can simulate an entire basketball game with Javascript!
Stay tuned: next week we will explore the Game of Thrones edition.
The event was billed as the largest hackathon on the West Coast and is the only one I know of that lasted both Friday and Saturday night. 36 hours of coding and the list of suggested items included, at the top, a laptop and a sleeping bag. At first I was hesitant to sign up for the waiting list because it seemed to be geared towards students so I sent the organizer an email.
LA Hacks ended Sunday and the very next morning was my first day at Hack Reactor, an intensive three month Javascript focused school in the heart of San Francisco. A couple minutes later I received an email from the founder of the event, Hadar, that read, “Sure, come! It’ll be really fun and you’ll learn a lot.”
This is the very reason I love the community around hackathons. Coding is what matters. For most, the event is about learning, creating, and working as a team in a caffeine fueled hyper productive environment. A fellow Hack Reactor student and I took the official bus from UC Berkeley and to our surprise half the students had never been to a hackathon and a third had never coded but wanted to spend the weekend learning.
It was a freaking blast! We listened to talks from founders and developers, met students from all over the country, and slept in the bleachers at Pauley Pavilion. We learned about Node, Express and Azure for serving our app, the Passport npm module for user authentication, Firebase and Go Instant for data storage and Web Speech API voice recognition which we used to create chatrooms by speaking the word “create”. Sunday was dedicated to presentations and it was awesome to show off our app and see the other hacks.
Facial recognition software
Robotic arm controlled by Leap Motion
the workspace
As weekend came to a close, Sam Alton took the stage as the keynote speaker and said, “There are two people in this world. There are those who create. And those who don’t.”
I believe we all create in our own ways. We create space ships, bridges, music, books, paintings, vaccines, charities, relationships, companies, communities, families, encouragement, excitement, craft beer and we contribute the most when we do.
“Keep Building”
His talk ended with one message, “keep building,” and I feel blessed that now at Hack Reactor I am surrounded by incredibly bright people who all want to do just that, build.
