I’m really writing this post more for myself than for anyone I have spoken to, but I think most people will be able to get something out of this post. I’ve been debating about this post for a while, trying to find the right words and all that. I think this is something that needs to be said, and I hope someone reads it and asks the question they’re been afraid to ask.

I think feeling competent is an especially difficult thing for a self-taught coder, like myself. I started out in journalism (yes, that’s right – at newspaper. They DO still make those.) and that might explain my love of incorporating literature into my posts. Or I might just be weird.

I started teaching myself on Codecademy, and if you’ve ever done it alone, you’ll know how tough it is to learn a language on your own. There is no reference point, it’s like walking around in the dark with holes in the floor. If you fall through the floor you have no idea why, only that you did something wrong.

So beyond yammering about how I learned coding, what am I getting at here? Well… I tend to apologize when I ask any type of question. And that’s if I ask the question at all. So often I will hold on to a question because I’m not sure of the terminology, or I’m afraid that it’s going to make me look stupid and reveal the lack of knowledge I have and everyone will know that I don’t really know what I’m talking about and the sky will fall and the universe will IMPLODE.

Ok, maybe that’s a long shot. But I still don’t want to look stupid, and asking might make me look stupid, so I don’t ask. When there comes a time I do ask the question, it usually looks something like this:

• “I hope I’m not bugging you but…. <question>”
• “Sorry to bother you…”
• “This is probably really obvious, but….”
• “Is this a bad time?”
• “Sorry if this is stupid…”

You get the idea. I frequently apologize and I’m super hesitant to ask. And these people are my friends! But asking is a scary thing. In a field where knowledge is currency, you are expressing that there is something you don’t know.

Spoiler Alert: Everyone has something they don’t know.

(If this is something you are really having trouble with, check out this video on Imposter Syndrome.)

The main thing I was to say here is that if you haven’t figured it out yet, it’s ok to ask. Give it the old college try on Google, and try to make sense of what you find. Get on JSFiddle and try to use it yourself. Open up the console and mess around to see how it works.

BUT

If you’ve done this and still aren’t getting it. ASK SOMEONE. And whatever you do, do not apologize for asking.

If anyone tries to make you feel bad or stupid for asking your particular question, they are an asshole. Period. They do not deserve your time. Don’t ask them again, and keep asking and Googling until you get it.

The best thing I have ever found for grasping a difficult concept is just working with it. Pull open the console and start logging stuff out. Try it a different way. Put log statements throughout your function in different places. Tweet out your question.

Just don’t give up. And definitely don’t apologize for asking.

Happy Friday.

Do you guys remember that Geico commercial with Salt-N-Pepa singing ‘Push It Real Good’? I think about that commercial every time I push to GitHub.

Ok, but really. In all seriousness, I used to have a ton of trouble pushing to GitHub. In my last post, I talked about creating a GitHub repository. In this post, I’m going to explain how to push to it after you’ve created it.

When I was first getting started on GitHub, I seemed to follow this inevitable pattern. First, I would make a repository and push the files I had locally to that repository. Then I would change some stuff around locally, like move the files to a new folder, or something like that and I wouldn’t be able to push to GitHub anymore. I’d delete the repository, (lose all the commits I’d been tracking in the process) and it was an all-around bad deal.

But practice makes perfect, and with much practice, I was finally able to figure out what the hell was up with GitHub. I’m really happy I did, because GitHub is actually pretty cool.

So, I’ll assume at this point that you already have a GitHub repository you’re pushing your work to. If not, check out my first post. Many times when I’ve been discussing GitHub with friends, I’ve been asked whether or not a person should wait until their project is completed and then post it to GitHub. The answer to this is a resounding No.

GitHub has a great function of tracking your changes, and holding on to your history for you. If you aren’t uploading your code as you create it, it cannot track it for you. In addition, it is a great way to back up your code (though you should be doing this with USB drives, as well) and it allows you to share your code with others if and when you get stuck on something.

So, moral of the story is, push your code to GitHub as soon as you have some code to push.

Let’s get started on how you can do this. All directions are for pushing code from the terminal, as is my preference. First open your terminal and go ahead and CD into the directory containing your work.

git status

This command will check the status of your GitHub repository against the status of your local work. If there are differences, such as new files, deleted files, or changes within a file, it will list this out for you in your terminal.

git diff

This command will show you the differences between the file in your GitHub repo, and the file you have locally.

git add . OR git add --all OR git add “filename”

The first two variations will add all of the changes (including any deletions) you have made. The third command will allow you to only add changes from a specific file. This can be useful if your settings change between your local machine and GitHub. You’ll be able to add only the changes to the code, and keep your settings the same.

git commit -m “message”

This actually commits the files you have added.

git push origin <branchname>

This will push all of your local changes to GitHub, and then ta-da! You’re all done.

Questions? Tweet me!

If you follow my blog at all, you probably know that I really, really like GitHub. Have you looked at GitHub and wondered, “Why? What’s the big deal, Carmen?”

That’s ok! When I first discovered GitHub, I really didn’t get the appeal either.

<flashback to past-me>I mean, it’s cool, I guess. It’s a place to put code, and all the coders I talk to say I should have one, so I guess I’ll get one.

*makes account. does nothing with it for 6 months.*</flashback>

But present-me loves GitHub.

GitHub is a place to show off your code. And as a beginner, or even a non-beginner, it’s totally fine to use it in this sense. I also use it as a sort of ‘staging server’ before I push my stuff to my live website. This allows me to see how things render before actually pushing them live. Also completely fine. But the possibilities of GitHub span far beyond this.

Let’s pretend you want to work with a group of coders on your ‘cool project A.’ And let’s also say that because you are an incredibly efficient bunch, you’ve divided up the work amongst yourselves. How can you make sure that your work isn’t overlapping, and keep track of the changes, and, you know, actually do the work?

Well! GitHub is going to help you with two of those things. (Spoiler: GitHub will not do your work for you. I’ve tried.)

Being the industrious group that you are, you hop on GitHub and make yourselves a repository (or repo). You and your friends each fork that repo on to their own GitHub pages, and then create branches based on the work each of you are assigned.

You commit work on to your own branch, and since everyone has their own branch, none of the work deletes the other work being done. GitHub will keep track of when the commits were made, and who made them. It will also keep your old commits for you, so you can see the progression of the work. Pretty sweet, right?

Then once you’ve completed your work and can do a pull request into the main repo and voila! And if it turns out that some of the teammates got their wires crossed and they have code that contradicts each other, GitHub will let you know, and show you where this code is. This is especially helpful when you’ve been coding for so long you can’t see straight anymore, and then come back to realize you’ve completely messed up some stuff you did before. (That was personal experience there.)

So, now that I’ve convinced you that GitHub is the way to go, let’s git started! (hahaha, see what I did there??)

Keep in mind, I am giving instructions for doing this through the command line, as is my preference. If you don’t have Git installed, you’ll need to get that installed. You find more information on that here.

GitHub does offer a GUI tool, but I have never liked it. (This tool is available for both Windows and Mac.) If you do try it out, please let me know what you think of it in the comments!

Before we get started on this, you should already have a folder with the work you are uploading somewhere on your computer.

Step 1: Create a GitHub account

This step should be pretty easy. Just go to GitHub, and make an account.

Step 2: Create a repo

This is what your GitHub homepage looks like. Kind of like Twitter or Facebook. You’ve got the NewsFeed showing you what your coder friends have been up to. On the right side you’ll see a button with a plus sign on it, “+ New repository.” Click there and you’ll be able to make a new repository.

Pretty simple. Just fill in the blanks and BOOM. New repo. Look at you go!

Step 3: Man the terminal

Ok, so this might be a little bit intimidating if you’ve never used the terminal before, but it’s not bad, I promise. And I’m whipping up a post about handy terminal commands here shortly, so you’ll be able to use that as a reference.

You can find the terminal by simply searching for ‘terminal’ in your spotlight on your Mac. I use iTerm, which you can get here. Using iTerm is fine, as is using your built-in terminal. Use your terminal to cd (change directory) into your desired directory.

Let’s take a quick look at these commands.

I usually skip the first echo command. All that does is write the name of your repository into a readme file. It’s fine to go ahead and use that command, or skip it.

git init

This command initializes the repository in your local directory.

git add

This command will add one or multiple files. If you run this command the way the picture above shows, you’ll only upload the single readme file. If you run instead ‘git add .’ (and remember that space, it’s important and no quotes) you’ll add all of the files and changes in your local directory. This does not actually upload the files. It only adds them so they can be committed.

git commit

This command is what actually commits your files. You’ll run ‘git commit -m “message here”’ (once again, spacing is important, and only place quotes around your message). Try to give a good message of what you’re actually uploading. This helps if you’re going back through old commits later trying to remember what they all were.

git remote add origin

You’ll only use this command once when you’re actually setting up your repo. This tells your local directory which URL to send those files to.

git push

You’ll run git push -u origin master to commit your first files to the master branch. Typically you’ll see master as the main branch, and all changes are pulled into master so it isn’t changed much. However, you can call your branches whatever you like.

The push commit will look like this…. ‘git push origin <BranchName>’

Step 4: Celebrate!

And that’s it! You’ve uploaded your first files into your brand new repo! If you refresh the page you’ll be able to see what your repo looks like now.

This is just how to get started with your first repo on GitHub. Be sure to check out for my next post on pushing changes to GitHub.

I would also be remiss if I didn’t mention some of the other great resources out there for learning about GitHub. You can checkout an interactive class from Jessica Lord. The exercises are very informative and the class is fun!

Also check out CodeSchool’s Try Git class. While this class is free, I definitely recommend signing up for CodeSchool if you can afford it. There are lots of great classes on there, and they work hard everyday to add more classes for us. (Yup, I’m a student there!) Plus their jingles are pretty rad.

I hope this helps get you started, and I hope you come back for the next post in my GitHub weekend series!

Questions? Tweet me!

In my last post I explained the difference between using == and ===. In this post I’m going to talk about type conversion in JavaScript.

(2 + 2) * (2 + 2);

('2' + '2') * ('2' + '2');

What do you think the answers are? It should be 16, right? Well, it should be, and the first equation does have an answer of 16. That second equation though is a little bit weird.

Look closely and you’ll see that the numbers are not actually numbers….they are in fact strings. JavaScript uses the plus sign to concatenate two strings, so what actually happens here is the strings are pushed together to result in 22.

This ends up looking like this: (‘22’) * (‘22’).

What happens next is where things start to get interesting. The ‘22’ is still in a string, but the JavaScript doesn’t really know what to do with two strings that should be multiplied.

Rather than throw an error that you can’t multiply two strings, JavaScript instead tries to help by converting the string to a number. So (‘22’) * (‘22’) ends up being 484. It’s good to note that JavaScript does not covert the number back to a string afterward.

If you would like to a take a closer look, you can check out my JSFiddle here.

Wait, wait, wait, you think. What happens if you multiply two strings that are actually letters. Like this: ‘what’ * ‘happens’ * ‘if’. (This is also in the JSFiddle, if you want to check that out.)

Well the type conversion still happens, but because you can’t actually multiply ‘what’ * ‘happens’ * ‘if’, the result it will give you is NaN, or Not a Number.

Kinda weird … but kinda cool, right?

Questions? Tweet me!

This is an ongoing series about weird things I’ve run across in JavaScript. For part one, we’ll talk about === vs. ==.

Three equal signs is unique to a few languages, including JavaScript. When you have two equal signs like this:

2 == 2;

You are testing if each item is equal to the other, you can use two equal signs. The above expression would be true. But with three equal signs, it also tests the type.

2 === 2;

This would also evaluate to true, but let’s take a look at some of the weird things you can do with two equal signs as compared to three equal signs.

'2' == 2;

'2' === 2;

The first example will evaluate to true, even though the first two is in a string. This is because two equal signs does not check for type, in fact it will completely ignore the type if the contents of the string are equal to the number. This can cause some weird things to happen, and we’ll get to that in a moment.

The second example will not evaluate to true because that third equal sign does test for type. Even though the content of the string is 2, because the types are not the same, they cannot be equal.

Questions? Tweet me!