== vs ===

JavaScript language provides two comparison operators for comparing the equality of the two values. It sometimes can cause a big confusion to the execution of the code if it is not clearly understood how these internally works. I’ll try to explain these differences using some examples.

Type Coercion

Type Coercion means that when the operands are different types, one of these operands will be converted to an equivalent value of the other operand’s type. This comparison is mostly done to a number. This implicit conversion process is known as Type Coercion.

For example: ‘2’ == 2 returns true.

‘==’ equality operator

A.k.a. loose equality operator and are considered evil by some. They are evil because syntactically the code would just look just fine but the output of the comparison could be something like unexpected. Here is the reason why this unexpected behavior can happen. == Operator tries to implicitly convert the type of one of the operands to a common type and then doing the comparison between them. Java-script would not complaint about the types mismatch but try to smartly do type coercion and present a result. Few developers find it scary and it can cause various bugs into the system. Consider following examples and see for yourself what this can cause:

1 == 1 //returns true;

1 == ‘1’ is executed as 1 == ToNumber(‘1’), hence 1 == 1 // returns true

‘1’ == 1 is executed as ToNumber(‘1’) == 1, hence 1 == 1 // returns true

undefined == null // returns true

new String(“”) == true//returns true because an object is always true

“” == true //returns false because empty string is considered false

“” == false //returns true because empty string is considered true.

Above mentioned examples apply to all condition constructs in JavaScript for example an ‘if’ statement.

‘===’ equality operator

A.k.a. strict equality operator would also take into account the data type of the operands before doing the comparison. It will simply return false if the types are different. In case of objects, the instances being compared should refer to the same instance to be truthy.

Here are some examples:

1===1   //returns true

1===’1’ //returns false

“” === false //returns false



Quick intro to Git – Part III

In this article I am going to show you how to play with branches and merges.

Create branch

As shown in previous article, I was working on the master branch. GitHub gives you the flexibility to create branches and allows you to cherry pick your changes to be merged back to your main branch. So lets make a new branch:

On your repository, you will see a pull down button showing you the current branch as master. Click on it and type name for your new branch. I called this Feature1. Click on the blue bar that says ‘Create branch: Feature1’.


Clicking this will create a new branch Feature1 from master. You will see all your files in your branch (I know i have one file only :)). Clicking on the same button should show a tick mark against ‘Feature1’, which means you are now in Feature1 branch.


Clone branch locally

What i am doing here is that the Feature1 branch code is being cloned into a new folder called TestRepoFeature1.

C:\work\amar\Code\TestRepo [master =]> git clone https://github.com/amarsingh19/
TestRepo.git -b Feature1 ../TestRepoFeature1
Cloning into '../TestRepoFeature1'...
remote: Counting objects: 6, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 6 (delta 0), reused 6 (delta 0), pack-reused 0
Unpacking objects: 100% (6/6), done.
C:\work\amar\Code\TestRepo [master =]> cd..
C:\work\amar\Code> cd TestRepoFeature1
C:\work\amar\Code\TestRepoFeature1 [Feature1 =]>

Make edits

Now I am going to make some changes to FirstFile.txt such that it looks like this:

This is first file.

Version 3

Branch: Feature1

Next lets do commit and push the changes.

git add FirstFile.txt

git commit -m "Feature1 first commit..."

git push -u origin Feature1

and voila! If you check your repository on GitHub Feature1 branch should get updated with your changes.

Merge Feature1 changes to master

To initiate the merge, you will have to submit a New pull request to the owner of the original repository. Pull request is something like you’re requesting the owner of the repository to review your changes and merge into the main branch. You can do so by clicking on the button highlighted:


Since I am the owner of the original repository, I see below screen


Click on the ‘Merge pull request’ button:


Click on the ‘Confirm merge’ button. At this stage you can delete this Feature1 branch.


Now lets check what happens to the main branch. Open FirstFile.txt and notice the contents have been merged from Feature1 branch.


This completes one complete workflow of creating a repository, branching and merging the changes back to the main branch. I hope I was able to provide good information here.


Distributed Version Control System

Quick intro to Git – Part II

Hi guys! As promised, here is the second part of ‘Quick Intro to Git’ topic. Here I will share my experience on working with git. I’ll walk you through with the steps needed to install the git command line and then use GitHub account to work with a repository and branches. I will try my best to keep this concise.

GitHub account

First step is to setup a git hub account. Visit this link. You can choose your personal plan based on your requirement.

Install Git command line

If you plan on using Git with GitHub only then you can probably live happily with GitHub desktop. This is a tool that gets installed to your local system and allows performing all the git operations with a simple to use user-interface. You would never have to worry about running commands at command line when you use GitHub desktop. But there are few points you might have to consider so please checkout their FAQ page. In this article I’ll explain the command line workflow.

Note: GitHub desktop also installs the git command line for you.


Once you have installed git, next you would need to configure it. Git configuration can be performed at following levels:

  • System Level
    • git config –system
    • Configuration file stored at c:\Program Files (x86)\Git\etc\gitconfig.
  • User Level
    • git config –global
    • Configuration file stored at c:\Users\<USER>\.gitconfig.
  • Repository Level
    • git config
    • Configuration file stored in .git/config under the repository.

Configuring user name & email

Depending upon which level you want to specify these settings at, choose the appropriate flag. I have set these settings at user level as I always want to use the same settings for all of my repos. Fire up your git shell command tool from your programs menu (i had a shortcut on my desktop) and run following commands:

#set user name
git config --global user.name "John Doe"

#set user email
git config --global user.email "johndoe@xyz.com"

#set editor
git config --global core.editor notepad

#list settings
git config --global --list
user.name=John Doe

Create Repository on GitHub

First step is to create a new repository on GitHub. Go to github.com and sign in with your credentials. If you don’t have a user account, create one. Next create a new repository by clicking ‘+’ on top bar or go to https://github.com/new.


Creating a new repository on GitHub.

For the purpose of this article, i created my repo at https://github.com/amarsingh19/TestRepo. Next I created a local folder on my computer which will store the code from my repository. Using command prompt go to this folder and initialize this folder as a git project. For this run the following command:

 git init
 Initialized empty Git repository in C:/Test/GitProject/.git/

This will initialize an empty Git repo and you will see a special folder called .git which will be hidden. Do not fiddle with this folder unless you know what you are going to do. By default your working branch is called ‘master’.

Create new files & Commit

I used notepad to edit file like this:

touch FirstFile.txt
notepad.exe FirstFile.txt

Add following content and save your file.

This is first file.

Version 1

Branch: Master

Next just to check how git recognizes your files, run the following command and notice the output. Newly created files are not tracked by git.

#check the status of the files
git status

# On branch master
# Initial commit
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#           FirstFile.txt

Run following commands to add your file to git and commit.

git add FirstFile.txt
git commit -m "First Commit..."
# -m is for adding comment to the commit.
[master (root-commit) 987ff41] First Commit...
1 files changed. 5 insertions(+)
create mode 100644 FirstFile.txt

This way you can work with files and make edits locally. All your commits are being done offline. These are not yet pushed over to your GitHub repo yet.

Push your changes to your GitHub repo

You are now ready to push your changes to GitHub. If at this stage you would like to unstage the changes, you can use run git reset command. Before you push your changes you would have to add a remote reference to your repo on GitHub.

git remote add origin https://github.com/amarsingh19/TestRepo.git

#next push your contents to your repo
git push -u origin master

Now go to your git hub repository and refresh. You should see the new added file.

Lets make another change before we move forward:

notepad.exe FirstFile.txt

Modify the content of this file and change version to 2.

This is first file.

Version 2

Branch: Master
#check the status of the files
git status

#On branch master
#Your branch is up-to-date with 'origin/master'.
#Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
# modified: FirstFile.txt
#no changes added to commit (use "git add" and/or "git commit -a")
git add FirstFile.txt
git commit -m "Second Commit..."

#[master 1c01996] Second commit...
# 1 file changed, 1 insertion(+), 1 deletion(-)
git push -u origin master

Now go to GitHub and open FirstFile.txt. You should see the updated version in the file content. 🙂


So by now you should be able to use the git hub command line to initialize a new repo locally and then commit your files to git hub.

This is all for this part of the article. In my next article I will brief you on how I created a feature branch and submitted a pull request and finally merge the changes from feature branch back to master branch.


Distributed Version Control System

Quick intro to Git – Part I

Hello friends!

Lately I was challenged and given an assignment to consume some source code hosted on GitHub and contribute to it by performing few given tasks. I, being pretty new to Git spent few hours over internet and trying to figure out how does this thing work. I had no prior knowledge on it and given the fact that of my past experience has been on Microsoft technologies I was actually little scared. 🙂

But, let me tell you, i felt much better when i completed that challenge. Although I must admit that despite being a simple challenge it was still daunting to me.

Anyways, I felt that it would be kind of nice to share my experience and may be help others to understand about git.

What is Git?

Git is an open source project that has a great community support and a solid user base. If you are an open source developer then Git is probably a first class requirement for you. Based on your use, it can be free of cost to you.

Hey ! But what exactly is git and why would somebody use it? Good question !

Git is probably the widely used version control system in today’s computer world. It is used more than other popular ones in the league, like TFS, SVN.

Few reasons for its popularity:

  1. Flexibility
  2. Robustness
  3. Performance
  4. Distributed

Git has a great support for distributed development. Rather than everything pointing back to a central code repository, Git allows each developer to have their own local repository where all their code changes and commits with full history are maintained. Since you are going to be working locally in your own repository, you can work in a disconnected mode and still commit files and push all of your commits to server using a simple push command in one go. Isn’t that a great feature?


During my challenge I used GitHub which is a code hosting platform to store my code files. See this Hello World example to understand more about GitHub tool but in short it lets you create repositories, create branches and merge them. You will need to create an account on GitHub to perform these operations.

GitHub allows you to access various public repos available. You can make your own copies from them by forking out and start to contribute. When you create a new repository it is accessible at a web url (see example below) which makes it so easier to be shared with someone else:


Fork a repo

Fork is basically a copy of a repository. You can either create a blank repository or fork (read as copy) out an existing repository. This feature makes it so easier to have something in place to begin with and not work from scratch. This also allows you to work independently in your own copy without impacting the original repository. You can find links to tons of existing repository and contribute here.

Pull Requests

Later on when you are done with your changes/fixes you can collaborate with the owner of the original repository by issuing ‘Pull Requests’ to the owner. I consider ‘Pull Request’ to be like a code review exercise and if your changes are approved then these can be merged into the original repository by the owner. You can also set notifications using ‘Watch’ and you will be notified whenever an action is performed on your pull request.


It is always a good idea to provide a solid documentation for your project. This helps others to understand and contribute to your project in much better way. When you create a new repository a master branch is created for you automatically. This branch contains a blank file called README.md (.md is a short for markdown). You can use this file to provide some documentation about what your project is and what current branch contains. For more information on how to format the markdown file, follow this link.

But readme.md files are generally kept short and concise. If you wish to produce more detailed and long form content about your project then you can put that information on wiki for your repository.

I hope this article was informative. Apart from these concepts, I would also like to share how to setup a git repo locally and talk about few git commands at windows command prompt. I will explain more in Quick Intro to Git – Part II.