DEV Community: Alec DuBois

Algorithm Toolkit #1: Modulo

Alec DuBois — Fri, 04 Dec 2020 20:15:09 +0000

Welcome to the part of this blog where I write about things I either:

A) Wish I had known when I started programming
B) Am really grateful someone taught me when I started programming

Oh, who am I kidding? That's my entire blog.

Let's talk about number manipulation for algorithms. More specifically, let's talk about the modulo, or remainder operator. (Quick note here: these are different things, but not for the purposes of the use case described in this post)

MDN says it best:

The remainder operator (%) returns the remainder left over when one operand is divided by a second operand. It always takes the sign of the dividend.

So, 4 % 2 is 0, and 5 % 2 is 1.

Okay, we'll come back to that in a moment.

Let's say you're given a common algorithm: reverse digits.

The problem states that, given any integer as an argument, write an algorithm that returns the reverse of the digits of that integer. As an example, this algorithm, given 123, would return 321.

In JavaScript, you could achieve this using built-in methods:

Turn the number into a string
Turn the string into an array
Reverse the array with .reverse()
Turn the array back into a string
Turn that string back into a number

But this defeats the point of algorithms: the point here is to use a lightsaber, not a blaster: a civilized weapon for a more civilized age.

So! Let's avoid all of this data manipulation entirely and leave the number as a number.

To reverse the number, we need to be able to extract a single digit from the number at a time.

It turns out that, given x being any integer, x % 10 always returns the last digit of that number. To continue the exmaple, 123 % 10 returns 3. There's our last digit!

If you wanted to simulate "popping" the digit off the number, you could, for example:

Disclaimer: this code assumes a positive number

let x = 123;

while (x > 0) {
  // Here's our x % 10 operator, storing the last digit in r
  const r = x % 10;

  x = (x - r) / 10; // This is the important part

  // Use the remainder for something here
}

Pretty easy, right? Given that the remainder of x % 10 is the last digit of that number, you can then just subtract that remainder from the original number and divide by 10.

Given 123, one iteration would leave 12, then 1, and finally 1 - 1 / 10 is 0, which ends the loop.

You can use this any time you need to manipulate a number without converting it into a string! Try it out the next time you need to manipulate a number directly.

How Programming Changes the Way You Think

Alec DuBois — Fri, 23 Oct 2020 18:54:48 +0000

Programming changes the way you think.

Let me qualify that: programming has changed the way I think - and might have changed yours.

This isn't to say I know all the ways it's changed the way I think, though. I've had a hunch for a few weeks now that the brain action (that's a real thing, right?) of writing code has in turn reshaped the way I think in a more far-reaching way than at the keyboard, and this is that: a hunch I think is worth exploring out loud.

Every Detail Matters

Have you ever considered how you read? Do you skim? Do you read a single sentence, or devour lines at a time? Do you give pause at words you don't understand, or do you pick up meaning from context?

Check this out:

Aoccdrnig to a rscheearch at Cmabrigde Uinervtisy, it deosn’t mttaer in waht oredr the ltteers in a wrod are, the olny iprmoetnt tihng is taht the frist and lsat ltteer be at the rghit pclae. The rset can be a toatl mses and you can sitll raed it wouthit porbelm. Tihs is bcuseae the huamn mnid deos not raed ervey lteter by istlef, but the wrod as a wlohe.

This won't work in programming. Even though your brain can tell what's meant by cnost, it isn't const. One works - and the other doesn't.

Over time, I think this forces you to develop a different kind of thinking when reading: that of reading characters over words and sentences.

The same kind of required-detail constraint applies to higher-level thinking as well. When you're designing an application interface, you now need to consider a host of details that must work in specific and contextually correct ways - everything from the address of your calls to a server to what happens after it completes or fails.

Personally, since I've started learning to code, I've stopped losing my keys and wallet.

It Isn't Working? Good News!

Another candidate for this thought's title was big red bold THIS IS BAD text is actually my friend.

Seriously, before programming, when were errors a good thing, really? Sure, you either win or you learn or every failure is an opportunity and other thoughts like that I could write entire blog posts about, but when has feedback ever been so thorough and downright useful?

This is about more than reading errors, though. The simple act of programming is literally going from failure to failure until something works - and then breaking it again later and re-writing until it works a different way. Failure and making mistakes become your actual access to the end product.

At some point along the way, I've (mostly) stopped kicking myself for mistakes in other parts of my life and started dealing with - - forgive me for this - debugging them instead.

It's (Almost) Always My Fault

Have you ever found yourself thinking to yourself why isn't this working? (Don't you hate it when blog authors ask you rhetorical questions?) If you're like me, you've probably followed that with this (insert test/technology/external library here) isn't working.

Maybe this is just me, but no matter how much I know that the reason something isn't working is due to code I wrote, I always blame something else. Clearly Rails is doing something weird somewhere deep in the class inheritance tree, or this unit test has personally declared war on me and everything I hold dear.

You already know the punchline: it was (99% of the time) actually something I wrote that caused the bug.

I've gotten a bit better at short-circuiting this initial (freight) train of thought, but I find this one especially interesting because no matter how many times I've realized that I was actually the man behind the curtain, I'm still bent in this direction when something doesn't work.

This Is Not The End

^ What he said. The best part of exploring this is what's left to explore. I don't know what I'm going to learn next (just kidding, I do know: it's TypeScript), and not knowing is exciting.

Is there any way that programming has changed the way you think? Are squirrels secretly plotting their hostile takeover of society? Leave me a comment.

N + What? (Or: a brief introduction to n + 1 queries and how to avoid them)

Alec DuBois — Tue, 29 Sep 2020 05:17:46 +0000

Heads up: this is an extremely simplified introduction written for the perfect beginner.

For more on this topic, I recommend leaving an offering at your local altar to Google and whispering your question into the search bar. Quietly, though! Don't want the neighbors to hear.

Extra heads up: This tutorial uses Ruby on Rails and ActiveRecord to demonstrate the topic, but the general idea applies in a much wider context

Last heads up, I promise, please don't stop reading yet: notes for absolute beginners may appear throughout this article that look like this

Started GET "/tamers" for ::1 at 2020-09-28 21:42:35 -0700
   (0.6ms)  SELECT "schema_migrations"."version" FROM "schema_migrations" ORDER BY "schema_migrations"."version" ASC
Processing by TamersController#index as */*
  Tamer Load (0.7ms)  SELECT "tamers".* FROM "tamers"
  ↳ app/controllers/tamers_controller.rb:3:in `index'
  Monster Load (0.8ms)  SELECT "monsters".* FROM "monsters" INNER JOIN "monster_tamers" ON "monsters"."id" = "monster_tamers"."monster_id" WHERE "monster_tamers"."tamer_id" = $1  [["tamer_id", 11]]
  ↳ app/controllers/tamers_controller.rb:3:in `index'
  Monster Load (0.6ms)  SELECT "monsters".* FROM "monsters" INNER JOIN "monster_tamers" ON "monsters"."id" = "monster_tamers"."monster_id" WHERE "monster_tamers"."tamer_id" = $1  [["tamer_id", 12]]
  ↳ app/controllers/tamers_controller.rb:3:in `index'
  Monster Load (0.6ms)  SELECT "monsters".* FROM "monsters" INNER JOIN "monster_tamers" ON "monsters"."id" = "monster_tamers"."monster_id" WHERE "monster_tamers"."tamer_id" = $1  [["tamer_id", 13]]
  ↳ app/controllers/tamers_controller.rb:3:in `index'
  Monster Load (1.8ms)  SELECT "monsters".* FROM "monsters" INNER JOIN "monster_tamers" ON "monsters"."id" = "monster_tamers"."monster_id" WHERE "monster_tamers"."tamer_id" = $1  [["tamer_id", 14]]
  ↳ app/controllers/tamers_controller.rb:3:in `index'
  Monster Load (0.6ms)  SELECT "monsters".* FROM "monsters" INNER JOIN "monster_tamers" ON "monsters"."id" = "monster_tamers"."monster_id" WHERE "monster_tamers"."tamer_id" = $1  [["tamer_id", 15]]
  ↳ app/controllers/tamers_controller.rb:3:in `index'
  Monster Load (0.7ms)  SELECT "monsters".* FROM "monsters" INNER JOIN "monster_tamers" ON "monsters"."id" = "monster_tamers"."monster_id" WHERE "monster_tamers"."tamer_id" = $1  [["tamer_id", 16]]
  ↳ app/controllers/tamers_controller.rb:3:in `index'
  Monster Load (0.8ms)  SELECT "monsters".* FROM "monsters" INNER JOIN "monster_tamers" ON "monsters"."id" = "monster_tamers"."monster_id" WHERE "monster_tamers"."tamer_id" = $1  [["tamer_id", 17]]
  ↳ app/controllers/tamers_controller.rb:3:in `index'
Completed 200 OK in 80ms (Views: 60.0ms | ActiveRecord: 15.6ms | Allocations: 23215)

Whoa whoa whoa. Look at all those queries! Our tamers might only have a few monsters now, but what happens when they have 150? 893? This is only with a handful of Tamers, too!

This is an example of an n+1 query, where we have (1) query for the initial model plus (n) queries for its associations.

How To Avoid Them

We've looked at a bit of what a layer like ActiveRecord is doing under the hood: generating and executing queries to the database based on function calls written in another language - in this case, Ruby.

Let's look more closely at this action I'm asking it to perform:

def index
  render json: Tamer.all, include: [ :monsters ]
end

In this, I'm asking for all of the Tamers, then asking for each of those Tamer's monsters when I express include: [ :monsters ] further along in the line.

The problem is that my application doesn't have the astoundingly powerful predictive capacity I do as a human being. When I ask it to draw Tamer.all - and this is an oversimplification - it has absolutely no idea that I'm going to ask it for those Tamers' associated monsters a few characters later.

Let's try something else:

def index
  render json: Tamer.includes(:monsters).all, include: [ :monsters ]
end

See that .includes(:monsters)? That's telling the query generator - ActiveRecord in this case - that I want to draw Tamer.all, but include each of their associated monsters.

Here's the query that generates with three (3) Tamers:

Started GET "/tamers" for ::1 at 2020-09-28 21:54:02 -0700
   (5.0ms)  SELECT "schema_migrations"."version" FROM "schema_migrations" ORDER BY "schema_migrations"."version" ASC
Processing by TamersController#index as */*
  Tamer Load (0.6ms)  SELECT "tamers".* FROM "tamers"
  ↳ app/controllers/tamers_controller.rb:3:in `index'
  MonsterTamer Load (1.0ms)  SELECT "monster_tamers".* FROM "monster_tamers" WHERE "monster_tamers"."tamer_id" IN ($1, $2, $3)  [["tamer_id", 18], ["tamer_id", 19], ["tamer_id", 20]]
  ↳ app/controllers/tamers_controller.rb:3:in `index'
  Monster Load (0.5ms)  SELECT "monsters".* FROM "monsters" WHERE "monsters"."id" IN ($1, $2, $3)  [["id", 24], ["id", 25], ["id", 26]]
  ↳ app/controllers/tamers_controller.rb:3:in `index'
Completed 200 OK in 92ms (Views: 68.5ms | ActiveRecord: 13.6ms | Allocations: 18700)

Huh. That looks a lot lighter - it's only three queries!

Let's doubleplusone the number of Tamers to seven (7) and see what happens:

Started GET "/tamers" for ::1 at 2020-09-28 22:45:38 -0700
   (0.6ms)  SELECT "schema_migrations"."version" FROM "schema_migrations" ORDER BY "schema_migrations"."version" ASC
Processing by TamersController#index as */*
  Tamer Load (0.7ms)  SELECT "tamers".* FROM "tamers"
  ↳ app/controllers/tamers_controller.rb:3:in `index'
  MonsterTamer Load (1.0ms)  SELECT "monster_tamers".* FROM "monster_tamers" WHERE "monster_tamers"."tamer_id" IN ($1, $2, $3, $4, $5, $6, $7)  [["tamer_id", 24], ["tamer_id", 25], ["tamer_id", 26], ["tamer_id", 27], ["tamer_id", 28], ["tamer_id", 29], ["tamer_id", 30]]
  ↳ app/controllers/tamers_controller.rb:3:in `index'
  Monster Load (1.2ms)  SELECT "monsters".* FROM "monsters" WHERE "monsters"."id" IN ($1, $2, $3)  [["id", 30], ["id", 31], ["id", 32]]
  ↳ app/controllers/tamers_controller.rb:3:in `index'
Completed 200 OK in 72ms (Views: 50.6ms | ActiveRecord: 15.0ms | Allocations: 20559)

Hold up. That's the same amount of queries generated by half the number of records!

That's right. We've now solved for n + 1 queries for this model in our application, meaning that no matter how many records there are, the number of queries will never increase.

While for a small application with a handful of records and few concurrent users you may see absolutely no actual difference in performance, this represents a mathematically significant decrease in the time complexity (buzzword alert) of this action.

In Closing

There's no punchline; play with this the next time you find yourself drawing a resource out of a database and tell your barista tomorrow that you learned about n + 1 queries. (Probably don't do that last bit, actually)

Leave a comment if you think I left anything out, or if you want to tell me why Nutella is better than peanut butter.

Git Branches in Five Minutes

Alec DuBois — Tue, 08 Sep 2020 18:06:31 +0000

Let's talk about branches. We've touched on these very briefly in previous posts in this series, but let's look at them on their own. (And do it in five minutes!)

Hi: notes for absolute beginners may show up like this.

Overview

In Git, branches are used to isolate changes from the rest of the code base.

This way, you can keep the spaghetti code you're using to build a new feature or fix a bug to yourself until you're ready to merge it with the main code.

The master branch is typically considered the working branch, which means that any changes you make there may effect anyone - or anything - using the code. Not where you want to play around with a new feature!

Here we go:

Making a Branch

For the rest of this I'm going to assume you're using GitHub, but there are lots of other Git hosting services out there. Remember, Git and GitHub are two different things.

First, you need to create your repository and navigate there in your terminal.

You can see which branch you're currently in by doing:

git status

You should see something like:

On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean

If you don't, go back and make sure that your repository is pointed at the correct remote

Now, make a new branch by doing:

git checkout -b new-feature

Remember flags? -b is saying "make a new branch!

You should now see:

Switched to a new branch 'new-feature'

You've now created a new branch!

Now, make some changes. I'm just going to create a file called README.md.

You can create a new file with touch README.md in your terminal.

Now, do:
git add . and git commit -m "Adds README"
This adds everything in the current directory . and commits the changes. More here.

You should see:

[new-feature (root-commit) e18e06c] Adds README
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 README.md

Notice that the commit message went under the branch new-feature in the first line of that message.

Now, push to the remote branch:

git push origin new-feature

You'll see something like:

Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Writing objects: 100% (3/3), 216 bytes | 216.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To github.com:afteralec/git-blog.git
 * [new branch]      new-feature -> new-feature

Done! Pretty easy, right?

Pull requests

In a real project, you'd continue committing and pushing to your branch until your code was ready to see the light of day. (Or, at least, be merged with the main code of the project in the master branch!)

Typically, this is done using a pull request.

GitHub has a great walk-through on it here, but again, use whichever platform you've been using until now.

With GitHub, it's pretty easy:

Open the pull request from the repository's page. Click the pull requests tab at the top and then new pull request.
Follow the prompts and complete the form
Open the pull request!

In this example, as the repository owner, you'll be able to merge your own pull request - this isn't always the case!

For our purposes, go ahead and merge your changes.

Cleanup

From here, you have two options:

Delete your branch.
Merge the new master code into your branch.

For this, go ahead and delete the branch. Our new feature (the README file) has been added, and there's nothing else to do with it for now!

Back in your terminal (in the local repository) do:

git checkout master

Without the -b flag, this moves you around from branch to branch

and then:

git pull

This part's important - remember, you made changes in the new-feature branch, not the master branch, so this brings you back up-to-speed with the current master code.

You can also delete your branch locally!

To see your branches, do:

git branch

Flags again! You can add -r to see only the remote branches, and add -a- to see all branches.

Do:

git branch -D new-feature

You should see something like:

Deleted branch new-feature (was e18e06c).

This has been Git Branches in (Less Than?) Five Minutes.

If this helped you, you have something to add, or you or want to tell me why you think birds aren't real, leave a comment below.

A (Very) Simple Git Workflow

Alec DuBois — Mon, 24 Aug 2020 19:17:30 +0000

This is a quick on-the-court example of what a (very!) simple Git workflow might look like for two people working on a personal project together.

Hey: You might see notes for absolute beginners like this

Basics

Before you do anything, you need to create your Git repository. I wrote a tutorial on that here, but regardless of how you do this the rest of this tutorial assumes you've done this.

Next, find someone you want to build something with!

In setting up this workflow with your collaborator, you want to first define some rules. Here are some suggestions (don't worry if anything here doesn't make complete sense yet)

Only merge each other's pull requests
Always test your new code before opening the pull request
Always review your collaborator's code before merging the pull request

Bottom line is: establish some groundwork here and agree on how to handle any conflicts or updates to the procedure as you go. Working with humans is different than working with computers!

Adding a Collaborator

Now, add the person you're working with as a Collaborator.

Here's a quick run-down on how to do it on GitHub, but there are obviously other Git hosting services out there.

Just like in my previous tutorials on this, it's really not hard:

Navigate to the repository in GitHub
Click Settings, Manage Access, and Invite a Collaborator
You can send them an invitation by username, full name, or email address
Finally, have your new collaborator Accept your invitation by following the instructions in the invitation in their email

You're in business! Have your collaborator clone and then pull the remote repository into their local repository.

A Note on Branches

When working with someone else on a repository, it's extremely important to keep your main branch of code clean.

More on this later, but let's talk about branches for just a moment.

Let's say you're working on an application and you want to add tags to your posts. You start work on the code in your local repository, but now you have a problem: the other person on your project is also writing code. What if what you're doing starts to overlap?

This is part of what branches are for. As part of this workflow, you want to make sure that when you make any change to your code base, you don't push up to the master branch. Again, more on that in a moment.

Instead, make sure you're creating a branch each time you add a feature or make a change.

Common Pitfalls

Let's handle some common pitfalls in working with a collaborator on a project.

Scene: You're working on a killer new feature for your app. You need to change some of the basic structure of your app, but nothing major. Maybe you changed a custom property in the application's main stylesheet - no big deal, right?

You push your change up to the master branch of your application. Oops, your collaborator was using that custom property (or whatever structure you changed) in the features they built before. One angry phone call later, you're reversing some of your changes.

Pitfall: not using pull requests to merge new code. In this case, you'd want to let your collaborator review the code, and they would catch the breaking change you made.

Scene: You just fixed a gnarly bug in the comments section of your new app. You open the pull request and your collaborator merges it. You do git checkout master to head back to the master branch and start working on the next bug. No problem.

Uh oh. Problem. You didn't git pull to grab the changes you just made to the remote repository and copy them to the master branch on your local repository. If you branch from here, you'll wind up regressing the changes you just made.

Pitfall: not keeping your local master branch up-to-date. However you organize this is up to you, but you want to be aware of where your local master branch is against the remote master branch.

A (Very) Simple Workflow

Here it is:

You start making changes to your code while checked out into your master branch
You git checkout -b branch-name to create a branch
You finish making changes to your code (1 and 3 order is optional)
You git add ., git commit -m 'adds this feature' and git push
You open a pull request on GitHub and the other person reviews and merges it

Finally, to start over:

git checkout master to head back to your master branch and git pull to localize the changes you just made

That's literally it! Keep in mind this is a very basic example, but it could get you thinking on how to organize your workflow when it isn't just you working on a personal project.

If this helped you, if you think I'm completely wrong, or think ducks should be allowed to cross the street without being filmed without their consent, leave a comment below.

Creating a New Git Repository for the Absolute Beginner

Alec DuBois — Wed, 12 Aug 2020 04:57:47 +0000

Exactly what it says on the tin. Here's a walk-through for starting a new Git repository locally using Git and GitHub. This is intended for beginners, and I've tried to include some explanations to make this less of a monkey-see, monkey-do kind of tutorial.

Hey: notes for absolute beginners are sometimes included like this

Before You Start

Here, I'm assuming you're familiar with the basics of moving around your terminal. If you aren't, go brush up on that first!

In order to start a local (on your computer) Git repository, you'll need an account with a git hosting service. I use GitHub from here on out, but there are other services out there.

Before we do anything, we need to install Git! You can find it with links to downloads here. Go on, I'll wait!

Creating the Local Repository

Okay! First, open your terminal and find (or create) a directory (folder) on your computer that you'd like to turn into a Git repository. Use cd <your/file/path> to change your directory and mkdir <name> to make a directory.

Do git init

You should see something like:

Initialized empty Git repository in /home/khaleesi/plans/conquer_westeros/.git/

That's it! This directory is now a Git repository.

To finish setup, you'll need to create the repository on whatever hosting platform you're using online.

Creating the Remote Repository

Here's the official GitHub documentation on creating a remote repository.

(It isn't hard - log in to GitHub and click 'New'. Follow the prompts, and you're done!)

But wait! How is the local repository going to know about the remote (hosted online) repository? Great question.

First, get the HTTPS link for your remote repository. On GitHub, you do this by clicking the green Code button on the right of your repository page, making sure it says Https and copy that link.

Next, point the local repository at the remote repository.

Do git remote add origin <your-repository-link>

Wait, did it work?

There's no response if this worked.

Do git remote -v

You should see something like:

origin  https://github.com/khaleesi/conquer_westeros.git (fetch)
origin  https://github.com/khaleesi/conquer_westeros.git (push)

And that's it! Your local repository is now pointed at your remote repository.

-v is what's called an option flag - it tells the command git remote to print the verbose response, which includes the remote link

Notice origin is the same as what you put in the git remote add command - you could name this something else, though most places you go you see it called origin

Commit and Push

Ready for the next bit? Awesome. Now you're going to send stuff from your local repository to the remote repository.

First, you need to add something to push (send). How about a Readme file? Everyone knows writing good documentation makes you more attractive.

You can be fancy and use the terminal for this:

Do touch README.md

Now for Git:

Do git add .

Before you can send anything you need to commit your changes.

Do git commit -m 'Added README.md'

Now, git push -u origin master

Because the HTTPS link is being used for the remote repository, you'll be asked for your login credentials.

After a moment, you should see something like:

Counting objects: 3, done.
Writing objects: 100% (3/3), 211 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://github.com/khaleesi/conquer_westeros.git
 * [new branch]      master -> master
Branch master set up to track remote branch master from origin.

There you have it! You can add files, remove files, change files, and as you go follow this same git add, git commit, git push flow.

touch creates a file and the .md extension means it's a Markdown file, like this blog post!

git add . tells Git to add everything in ., the alias for the current directory

-m is an option flag on git commit for 'add a message'

-u is an option flag on git push for set upstream, which tells the local repository's master branch to track the remote repository's master branch - meaning that later you can just do git push on its own and it will know which remote and branch to push to

Notice origin again? This is what we're calling the remote repository. master is the main branch of that repository

A Note on Branches

As a happy side-effect of creating your first repository, you've created your first branch. I'm not going to go into depth here, but I'll just touch on what that means.

Remember master from git remote add and git push? Seemed kind of arrogant, right? Well, the master branch is the main branch of a repository. When you're pushing changes to the master branch, it's a pretty big deal!

Most projects start out with just a master branch, and other branches get added and removed later as you and maybe others develop sections of code on its own before merging it with the master (main) branch.

Here's a resource if you want to learn more: Git Branches in a Nutshell

Sum Up

In summary, Git is easy:

git init to start your directory;

git remote add <your-remote-repository-link> to point it at a remote repository;

git add . to add all files in the local repository to a commit;

git commit -m '<your-message>' to stage a commit;

git push (using -u origin master the first time) to push up to the remote repository, and...

Done!

If you made it to the end here, thanks for reading. Leave a comment if you've found this useful, it's good karma.

DEV Community: Alec DuBois

Algorithm Toolkit #1: Modulo

How Programming Changes the Way You Think

Every Detail Matters

It Isn't Working? Good News!

It's (Almost) Always My Fault

This Is Not The End

N + What? (Or: a brief introduction to n + 1 queries and how to avoid them)

Jump to:

N + What?

How To Avoid Them

In Closing

Git Branches in Five Minutes

Jump To:

Overview

Making a Branch

Pull requests

Cleanup

A (Very) Simple Git Workflow

Jump to:

Basics

Adding a Collaborator

A Note on Branches

Common Pitfalls

A (Very) Simple Workflow

Creating a New Git Repository for the Absolute Beginner

Jump To:

Before You Start

Creating the Local Repository

Creating the Remote Repository

Commit and Push

A Note on Branches

Sum Up