MongoDB cheat sheet

mongodbThis simple MongoDB tutorial is for you if:

  • you’re completely new to MongoDB and just want to do SOMETHING with it
  • you have MongoDB running but forgot the particulars of using the MongoDB shell
  • you want to look inside your db and confirm data’s actually getting written to it
  • you rebooted and lost your Mongo server and you can’t remember how you got it running in the first place
  • you don’t want to wade through the documentation again

Or, you’re just me in the future looking for where I wrote this down. You’re welcome, future self.

1. Install Mongo!

Install steps are better covered by Mongo itself: official MongoDB

2. Start Mongod

These steps differ by OS.

Mac / Linux

On my Mac machine, I can start mongod from anywhere because it’s in my $path (see this guide for steps on adding MongoDB to your $PATH).

Just use:


Successful connection looks something like:
Screen Shot 2015-04-26 at 11.59.03 AM


On my Windows machine, I have to navigate to Mongo’s installation folder to start mongod. Open Terminal (Mac) or Command Prompt (Windows). Navigate all the way into the bin folder. On my Windows machine, my mongo folder is here:


Now use:


On Windows, I see a connection spam scroll by. Leave this window open and go to the next step.


Problems starting Mongodb?

If you get the “Unable to lock file: data/db/mongod.lock. Is a mongod instance already running?” problem, you probably have multiple instances of mongodb already running. This can happen as you switch projects, switch between user accounts on the same machine, etc.

To fix it, do this to list your computer’s processes and filter them to just mongo (this example is from when I had the problem on my Mac):

ps aux | grep mongo

On my machine, running that command revealed a couple instances of mongo already running (these were started by Jim using a separate account on the same computer). The third process in the list (the one owned by mjgrant) is the grep itself.

Screen Shot 2015-04-26 at 11.24.10 AM

Because my mongo instance was started by “root” (another Mac account, really), I had to be all dirty and use sudo to kill it by its process number (second column from the left).

sudo kill 61180

If you run the ps aux command again, you should see that there are now no instances of mongo running. If there are, just kill them using the same steps.

But what’s this? Trying to start mongo gives me this error now:

2015-04-26T11:30:11.114-0700 [initandlisten] couldn't open /data/db/memry_database.ns errno:13 Permission denied
2015-04-26T11:30:11.114-0700 [initandlisten] error couldn't open file /data/db/memry_database.ns terminating
2015-04-26T11:30:11.114-0700 [initandlisten] dbexit:

Rather annoyingly in our shared-computer situation, mongo’s knowledge of databases transcends user accounts. Navigating up to /data/db I can see all the databases on this computer. cbm_database is the one I’m trying to use, but mongo is choking on trying to access Jim’s memry_database.

Screen Shot 2015-04-26 at 11.35.10 AM

I check their permissions…

ls -la

Screen Shot 2015-04-26 at 11.37.15 AM

When asked why his databases belong to “root”, Jim says, “I probably did it wrong” :D Alas, we don’t know how we ended up with databases belonging to “root”, but Jim must have been using mongo as a root user, hence why he didn’t run into problems accessing databases owned by mjgrant.

Anyway… I used chown to assign ownership of these rogue root databases to my own account to unblock my work. (Standard disclaimer applies: use sudo with caution.)

sudo chown mjgrant memry_database.ns
sudo chown mjgrant memry_database.0

I run ls -la again and confirm that now I own all of the databases.

Now you should be able to start MongoDB with…


And now you should see the connection data:

Screen Shot 2015-04-26 at 11.59.03 AM

3. Start the Mongo Shell

Open a new window (and navigate again to the bin folder if you’re on Windows).


This line starts up the Mongo shell.

(So to recap, mongod has to happen before mongo.)

On Mac:

Screen Shot 2015-04-26 at 12.09.22 PM

On Windows: 


MongoDB shell version: x.x.x
connecting to: test

You can now start your localhost server.  (If you were blocked by Error: failed to connect to [localhost:27017] that should now be resolved.)

From here on out, commands you type into the command line will be mongo-specific.

3. Viewing your MongoDBs

Let’s say you want to see your databases:

show dbs

show dbs delivers a list of your databases. You should see something like this in your terminal window after you type it:



On mine, the result is:

> show dbs
admin <empty>
local 0.078GB
meals-development 0.078GB

4. Using your Mongo DBs

These are your database names. Go inside them with “use”:

use meals-development

Once you’re “using” a database, though, the terminal doesn’t give much clue as to what to do next.


5. Viewing Collections

A collection is a group of MongoDB documents. Generally, they’re similar in purpose, but they don’t have to conform to one shared schema. You can see collections inside a db by typing:

show collections

As an example, inside my recipes-development example I have:



Ah hah, finally. Now I know the name of the collection that contains my recipe (meal) data.

6. Look inside a collection

We’re almost to the good part. To see inside the meals collection, type:


You should get a number of objects with ids, names, etc. Each object will start with something like: { “_id” : ObjectID<“544dabfba054…

That’s it!

This was just a short guide to my most commonly used MongoDB shell commands. When I’m setting up a new db, I use these steps to look inside my db and see if data is being saved the way I expect it to.

Helpful Links

Code Fellows Seattle Review: I survived the JavaScript Dev Accelerator!

code_fellowsThis summer I did something completely crazy awesome: I quit my game industry design job to attend one of those trendy “coding bootcamps”, specifically Code Fellows in Seattle and start a new career in web development! After 8 weeks of intense work, I completed the Full Stack JavaScript Development Accelerator on September 26th, 2014.

There aren’t a ton of reviews on coding bootcamps, so I thought I’d add my own to the mighty Interwebs and try to answer some of the questions that I had going into it.


It was awesome! I learned a TON and my fellow students were brilliant and enthusiastic. Highly recommend, would do again.

  • Instruction: My class was taught by Ivan Storck and Tyler Morgan. They were both excellent instructors: good at explaining things, patient with questions, up to date on trends and technologies.
  •  Pacing: Intense! They introduced 5-10 new things a day. Homework filled every minute of my bus ride home and evening.
  • Job placement: I have not accepted a full-time position yet (2 weeks post graduation) but I have been in contact with a number of hiring managers who got my info directly from Code Fellows. I accepted a full-time software engineer position at Expedia, doing challenging and rewarding work with a great team of programmers!

The accelerator is not for beginners, so start writing code now if you’re interested.

What I did to Prepare for Code Fellows

Like most Code Fellows applicants, I was changing careers. Unlike many students, though, my past life was in software development. Even though I never wrote code for my design jobs, I was immersed in the lingo and processes of making a software product.

I’ll talk more about what I did, specifically, to cram for the class in a later section of this review.

Why I Didn’t Pursue a Bachelor’s of Computer Science Instead: Boot Camps vs. Degrees

Like a lot of boot camp attendees, I considered going for a Computer Science degree instead. I live near good schools and I’m sure I could have succeeded at any of them. Boot camps are too new to really know if they’re going to replace the traditional CS degree path into programming. And tech directors and hiring managers are right to worry about boot camp grads: apparently, some coding boot camps really suck.

But in my case, all that was really separating me from the front-end developer job I was aiming for was a better understanding of some very specific web technologies.  After finishing the program, I can say that I definitely made the right choice for me.

I can’t say if boot camp is the right choice for high school grads hoping to skip the cost and time investment of a CS degree. I think that comes down to what you want to do, and how much you value a degree. There’s a lot of entrenched thinking (right or wrong) that having a degree is an indication of a job applicant’s worthiness, and until that changes, a degree will continue to open certain doors. Plus, a hard science education is virtually essential to get hired making airplane software, medical devices, and other things where the price of failure is very high.

Web development and game development seem to play more loose and free with degree requirements, and some of my brightest and bestest co-workers did not have degrees, so I’m not personally convinced of the necessity of a degree in order to write code for a living. Being great at what you do and being likable should guarantee you never run out of opportunities.

As a point of interest: almost everyone in my class of 18 students had at least one college degree, and the majority had workplace experience. A handful (maybe 4 of us) had software development experience in some capacity.

What I Knew Going In: My Coding Background Prior to the Boot Camp

I already knew a bit of ActionScript (learned it in college and used it at my first job to script menus), HTML, CSS, and WordPress (picked these up from my blogging hobby), lua (from when I tried my hand at making little indie games in Corona SDK), Java (from a free online Stanford course) but I wouldn’t have called myself a programmer. At best, I was a hacker who modified existing things to make what I needed.

Still, there were a number of things I did in the year leading into my Code Fellows class that I think helped me do well:

  • Started and maintained several WordPress blogs – this taught me about web hosting, deploying to a web host, and a lot of web dev processes and lingo
  • Customized several WordPress themes – basically a crash course in CSS and PHP (I didn’t use PHP in the Accelerator, but there’s no “bad learning”, so to speak)
  • Completed Stanford’s CS106A Programming Methodologies – this taught me basic Java and object-oriented practices. The course videos are free on YouTube and the course materials are available on Stanford’s site. I cannot recommend this course enough. It gave me a stronger background in Computer Science than many of my fellow Code Fellows students had the benefit of, including an understanding of object oriented design, primitive data types, data structures, memory management, pointers, compiling, and more.  It was worth it for the object oriented instruction alone.
  • Finished the JavaScript Road Trip on CodeSchool – A one month CodeSchool subscription was easily the best $30 bucks I’ve ever spent towards my coding education. CodeSchool is great at showing you all the stuff a language can do, but not so good at showing you how to use it outside of the CodeSchool vacuum, so use it as a way to get introduced before moving on to building stuff on your own.
  • Knew quite a bit of Git – I learned Git as a part of my last job, which was great because Git can took me a while to wrap my head around, even though I had worked with version control before. Git proficiency freed up a lot of brain space for harder coding problems during the class.
  • Opened a GitHub account – All the class homework and class projects are hosted on GitHub. Already knowing how to create repos, clone repos, fork repos, create branches, resolve merge conflicts, merge branches, and collaborate with others on GitHub was big advantage for me.
  • Read the first several chapters of Code Complete – This “best practices” book is all about how to approach coding problems and how to structure the code you write. How long should a method be? What are good naming practices? Stuff like that. It’s approachable even to novices and I owe a lot of my good habits to it.
  • Followed this AngularJS tutorial and then built my own separate site using what I had learned – It took me a little while to really grasp MVC and the role of a framework like AngularJS, so spending a couple weeks on this before the 4 days it was covered in class was very helpful.

The class moved very fast and there wasn’t really time to get mired on a new technology or technique, so I tried to give myself a good grasp on the basics before the class.

Not that Code Fellows didn’t have its own preparation courses, which I’ve outlined in the next section.

Foundations I and Foundations II Review

Foundations I and Foundations II are Code Fellows’s pre-Accelerator preparation classes. When I took them, they were $500 and $1350 respectively (when paid for up front). Foundations I was pretty general, though we did write in JavaScript. Foundations II varies by stack – if you’re pursuing Python you’ll do a Python FII, iOS students go to an iOS FII, and so on. I took the JavaScript flavor of FII.


Both Foundations classes meet two weeknights a week for four weeks each, 7-9pm. The classes are open to everyone; you don’t have to be committed to an Accelerator to take a Foundations class.

Both classes featured:

  • Live instructor-led demos on a big projector screen
  • Work time in class with access to TA’s
  • Challenging homework assignments to supplement instruction
  • A customized “what to work on next” guide for each student, given at the end of the class


The Foundations I class was held at the University of Washington’s Seattle campus. Parking was usually $5 a night, but it was occasionally free due to unexplained reasons. The campus was beautiful, well-lit, and easy to navigate. The class was held in the biggest classroom I’ve ever been in, with about 150 students in attendance.

Here’s a pic I snapped 15 mins before class one night:


Foundations II was held at Code Fellows’s campus in South Lake Union at 511 Boren Ave. You can park in the Amazon garage around the corner (heading west on Republican, drive past Boren and then turn right into the garage). After hours parking has an unadvertised rate of $2.44 and it’s a ghost town by 7pm.

This parking garage doesn’t show up on Google maps. It’s a hidden gem.


Heads up to any Eastsiders – I live near the Kirkland/Bothell border and my drive into the city for the night classes was hell. I took either via 520 or I-5, whichever one Google Maps predicted a shorter drive for at the time of my departure. The shortest I ever made the trip was an hour, and the longest was 90 minutes. It was tedious and miserable, and there were no better public transit options. Inbound traffic is super jammed up between 5-7pm. Just something to take into account if you live or work on the Eastside and have dreams of getting to these classes in a reasonable amount of time.

Foundations Curriculum

I came into the Foundations classes with familiarity with most of the material they introduced, but I appreciated the “legitimization” of my self-taught knowledge. Plus, the homework was good practice.

Foundations I included:

  • A brief history of Computer Science
  • Using GitHub – forking repos, pushing to repos
  • Writing simple JavaScript loops
  • Simple CSS styling
  • Creating a simple card game, first without and later with a visual (in browser) component

Foundations II included:

  • Creating a menu using jQuery
  • Lodash and Underscore
  • An introduction to Big O
  • More Git practice

I wouldn’t recommend relying 100% on the Foundations classes for Accelerator prep. You won’t get enough coding practice unless you do as much as you can on the side in addition to the classwork.

Dev Accelerator: 8 weeks of kicking my ass with code

The pace was brutal, the homework was never-ending, and the whole 8 weeks flew by so fast I was shocked when it ended so “soon.”

A typical day introduced anywhere from 5-10 new technologies to read up on, learn, install, and use in the homework. (A lot of these were node packages.) The class squeezed every last drop out of me, which I loved – I feel like I got my money’s worth!

Ivan Storck and Tyler Morgan were fantastic teachers. Just absolute geniuses at this stuff and I miss them now that the class is over! They were both very approachable, knowledgeable, and good at assisting in ways that helped without just giving away the answer.

Technologies Covered

This will probably be hilariously out of date in 6 months, but here’s a list to give you an idea of just some of the material we covered:

  • node.js
  • Workflow and build tools – Grunt, Yeoman, Sass, JSHint, Browserify
  • npm packages galore
  • mongoDB – CRUD operations
  • authentication / authorization
  • Unit testing in Mocha
  • Karma, Jasmine testing
  • deploying projects to Heroku and Amazon Web Services
  • Google Maps API
  • Algorithms
  • Backbone and AngularJS
  • Data structures – linked lists, queues, stacks, arrays, using objects as hash maps
  • Whiteboard questions like the kind you might encounter in an interview

And by “covered”, I don’t mean “they mentioned this in a demo once”. I mean actually wrote code that used these technologies, usually as homework and/or for team projects.

Daily Schedule

I actually had no idea what to expect for the class schedule other than “every day from 9-4”, so I’ll share what mine was like here.

Class Days

Class was held every week day from 9am to 4pm for 8 weeks total. Mondays-Thursdays followed a schedule of co-working time in the morning and instruction in the afternoon. Fridays were “How to Get a Job” workshops and did not include any coding instruction (more on those later).

For my class, the 9am-1pm part of the day was “co-working” time. This means everyone in the class is expected to be present, but the time is for homework and asking questions. The instructors are available during this time for help.

The co-working space was big enough for several classes worth of students to hang out in there at once:


People typically left for lunch around 11:45-12:00 and everyone returned by 1pm. Food in South Lake Union is pricey, and I brought my lunch almost every day – Code Fellows has refrigerators and microwaves on site.

The 1pm-4pm part of the day was instructional time, where everyone sat at desks facing the projector and followed along on laptops to the live demos and lectures that were given by the class’s two instructors. They instructors filled every minute until 4pm with useful stuff, which was great – I hate when class I’m paying a fortune for ends early. ;)

Here’s my class near the end of an afternoon lecture session:


Some classes flip it and do instruction in the morning and co-working in the afternoon. On days when my bus ran late, though, I really appreciated missing 15 minutes of work time instead of 15 minutes of expensive instructional time. At $9,000 for the course (assuming you pay in full up front for the discount), every hour of instruction costs $93.75!

Team Project Weeks

Team Project weeks were weeks 4 and 8. Groups were self-selecting and typically 4-5 students each. The whole week was given as co-working time for teams to work together on projects that were then presented to the class as a whole on Friday. Instructors were available all day every day for help.

Team project experiences vary by team and individual. My two team projects went pretty well overall, and I learned a lot about Google Maps API and JavaScript (first team project) and Angular (second team project) by the time the week was done.

Like everything else in the class, the team projects are hosted on GitHub!

  • Find Fit – Week 4 (Google Maps and Places APIs, JavaScript)
  • InstaPitch – Week 8 (AngularJS, Auth/Auth, REST)

Friday “Get a Job” Lectures and Workshops

Instead of class, each Friday was a “How to get a job” lecture or workshop session. There were six of these total, usually an hour or two in length. A couple of the sessions were pretty elementary stuff, but I’ve worked in software for nearly a decade and have introduced myself more times, written more resumes, and interviewed more people than I can remember by now.  These sessions might be more exciting to someone without that experience.

But there were some real gems in the Friday sessions, too!

Gina Luna, a Code Fellows staffer and photographer, has a great eye for portraiture.  She took photos of each student and we all got a bunch of professional-quality photos of ourselves to use on our GitHub and LinkedIn profiles.

Code Fellows also invited two alumni to speak to the class in one of the Friday sessions. Those guys were awesome, and I had fun picking their brains about what it’s like to work at their respective web dev companies.

I also loved the presentation given by Mitch Robertson – he showed us a lot of LinkedIn tricks and emphasized the importance of being likable (in my own experience with hiring people, being likable is often more important than raw skills).

The Hardest Stuff

All things considered, the most challenging aspects of the class were keeping current on the homework (more every day!) and the week where we did whiteboard challenges for a couple hours every afternoon in small groups. These problems were hard, but they became more manageable the more of them we did, and now I feel pretty well prepared to write code on a whiteboard in an interview.


How do I Job Now?

Code Fellows doesn’t place students in jobs, but they do have a bunch of “hiring partners” – companies that basically get first dibs on the Code Fellows resume stack.

I’ve already heard back from several of these companies, and they’re prestigious, exciting companies located in downtown Seattle, not Bumblefracktucky. So that’s awesome. (However, I’m only pursuing Eastside opportunities at this time.)


At Code Fellows, assuming you’re not a huge jerk, you’ll get to know a lot of great people who will be the start of your new professional network. I’ve personally never gotten a job where I didn’t already know someone on the inside vouching for me, so I think this “instant network” was just another one of the class’s benefits.

The Accelerator instructors also encouraged us to attend local Meetups, which I did, and I left with another half dozen really good contacts to keep in touch with.

In short, I met a lot of great people as a result of the class.

My Advice to Interested Students

  • Start programming now. This isn’t for beginners. The more you know going in, the more you’ll get out of it. You don’t want to be the person stuck on Git basics when everyone else is doing cool stuff.
  • Get some practice with algorithms, data structures, and Big-O. These topics really deserve more time than they get in the class, and they’ll probably hit like a bag of bricks the first time you encounter them.
  • If you’re a procrastinator or are just doing it for the paycheck, you probably won’t survive. This class was brutally difficult and frustrating at times, and the only way to survive it is out of a genuine interest and passion for computing.
  • Also, You’ll need a laptop with a UNIX based operating system.  That means a MacBook or a machine with Linux installed. I started this adventure with a Linux machine but purchased a 15.4″ MacBook Pro refurb right before the accelerator. It was a good choice.

And that’s it!

Overall, a fantastic experience and I’m glad I went for it. I think it would have taken me at least a year to learn all this stuff on my own, and it really helped to have knowledgeable teachers pointing me at the right technologies, answering questions, and challenging me with things I might not have discovered (or given up on) if I had been relying entirely on self-teaching.

If you’re considering a coding boot camp and you live in the Seattle or Portland area, you should check out the next Code Fellows open house.

Push to GitHub without entering username and password every time (Git Bash on Windows)

Today I learned… how to save my GitHub username and password so I don’t have to re-enter them every time I push something to GitHub from my Windows machine.

A bit of backstory:

I recently set up git on my Windows 7 machine using Git for Windows (mysisgit). That process went smoothly and I feel right at home in my little emulator, Git Bash, using all the same commands I already know and love from my Mac.

If you’re used to using git on a Mac and have to work on a Windows machine for whatever reason, I highly recommend mysisgit.

Credential check… every time!

Everything was going great until I pushed my changes. Every push triggered a new credentials check!

$ git push origin master
Username for '': xyz
Password for '':

I don’t want to enter my GitHub username and password every time I push something.


So I hit the Google and found this StackOverflow question, where some helpful folks say the problem results from connecting over HTTPS instead of SSH, but GitHub’s help documentation recommends connecting over HTTPS, not SSH.

I’m hesitant to disobey the word of GitHub, so instead of relying on SSH, I followed GitHub’s instructions to use a credentials helper.

Credentials Helper Setup

However… GitHub’s explanation of how to cache your password with the credentials helper aren’t very clear. They tell you to enter this line and then don’t tell you what to do next.

Here’s what I did – worked for me.

In your Git Bash window, enter this line:

$ git config --global credential.helper wincred

Now push a change to Github and enter your credentials – this is where your username and password information gets saved to the credential helper.

You won’t get any feedback telling you that, but you can confirm it worked by pushing another change. This time, you shouldn’t have to enter your credentials again.

But I have this problem on Linux!

Try this: Caching your GitHub password in Git

$ git config --global credential.helper cache

WordPress Genesis Framework – Showing a List of Post Titles in Category View

Today I learned… how to customize the “Category” view in WordPress (Genesis framework) to show just the post titles as ordinary links in a list.

I really like the way posts of a category are displayed on DailyBlogTips. Each post gets a bullet in a simple unordered list.

DailyBlogTips’s category view shows just the post titles in an unordered list.

By default, WordPress (and Genesis) gives you two options for displaying posts by category: either their full form one after another (do not want), or a truncated version with the post title and excerpt (also do not want).

A solution in which the titles were rendered as <a hrefs> between <li></li> tags required modifying the loop when on a Category page.

Please note that this code requires a theme built on the Genesis framework, though it should not be hard to modify the hooks to suit your framework if you know your way around a bit.

Copy the contents of functions.php into your child theme’s functions.php file.

Here’s what this is doing, in English:

When the current page is ‘Categories’ (Line 9), don’t do the usual genesis_loop (Line 13). Instead, do this custom loop (Line 14) called mjg_custom_loop.

Over in mjg_custom_loop, create a new unordered list (Line 21) and for each post (Line 22), echo its permalink and its name into a set of <li> </li> tags (Line 24).

The contents of style.css will probably need to be customized to fit your site’s design, but hopefully this is enough to get you through the hardest part which is customizing the loop on the category page.

Here is how it looks on the site:

Titles-only Category view on

Book Review: You Don’t Know JS – Scope & Closures by Kyle Simpson

Scope & Closures by Kyle Simpson

If you’re an intermediate JavaScripter who’s tired of weighty tomes and arcane examples, You Don’t Know JS – Scope & Closures by Kyle Simpson is right up your alley. This smart book takes a laser-focused look at scope and closures in JavaScript.

My rating: 5/5

Who it’s for: Intermediate JavaScripters. If you’ve heard of scope, closures, JS compiling theory, but aren’t sure you really understand them as well as you should, then this book is for you.


Let me preface this review by saying I’m not a big fan of coding books.

I have been frustrated by out-of-date books, untested code, and overly complex explanations from coding wizards who have long since forgotten what it’s like to be a newbie. I’ve always been more of an in-the-trenches doer than an ivory tower studier, anyway.

So, I wasn’t expecting to like Kyle Simpson’s You Don’t Know JS: Scope & Closures book so much. A programmer friend insisted I read it, and 87 pages of golden JS secrets and epiphanies later, I’m glad I did.

This book is…

  1. Brief. No long-winded explanations or storytelling.
  2. Focused. One topic, explored deeply FTW.
  3. Short examples, usually just a handful of lines total.
  4. Easy-to-follow examples with good style choices, such as verbose variable names and comments listing the expected result.
  5. Concepts are explained and re-explained before moving on. This is complicated stuff for us intermediate JavaScripters, and he takes the time to attack topics from multiple angles.


You Don’t Know JS – Scope & Closures covers:

  • variables: declaring, setting, and updating
  • scope
  • lexing
  • hoisting
  • closures
  • how the JavaScript compiler reads code
  • tokenizing

This book deserves credit for explaining the compiler’s process of operations in a way that actually clicked for me.

I also loved the short examples. They were easy to follow, none of that 30+ lines of code spread across two pages stuff you see in other books.

The book’s small size is a plus.  I took it with me on a day trip – hooray for books that aren’t the size of my laptop.


The only thing I might say is that some examples in the book are like, “Yeah, duh, don’t do it that way” but to be honest, I probably had to be told some of these “duh” things myself when I was starting out a few years ago.

Overall, I’d give this book an A+. It fits into the vast gulf between “total n00b” and “JavaScript Jedi”.

Check it out on for the current price (as well as any coupons and deals that might be running).

Note to readers: TILCode is an Amazon Affiliate. Purchases made through some links on this site help support the site at no extra cost to you. Read the full disclosure here.

Read this: Airbnb’s Excellent JavaScript style guide

Today I learned… that Airbnb has a fantastic JavaScript “style guide” available for free on github. The guide is light on long-winded explanations and big on DO and DON’T examples. Check it out, it’s a 15 min read at most.

Here are just a few of the things I learned from it:

Declaring multiple variables

A long list of variable declarations should be done with the unassigned variables last, and all declarations can share one use of var.

// multiple var declarations like so:
var items = getItems(),
    daytime = true,

I’m definitely guilty of var var var var var… but I’m not sure how I feel about this particular style. I like the clarity and editability of beginning each line with var, but for declaring lots of like items, I can see the usefulness of this style.

Shortcuts for the win

Instead of writing “if this thing is greater than zero”, you can just write “if this thing”.

Here’s an example:

// bad
if (cars.length > 0) {
  // ... code here

// good
if (cars.length) {
  // ... code here

Easy enough.

Comment with good style

Oops, I’ve definitely been getting this one wrong. Comments belong on their own line, not off to the right of the line the comment explains.

// bad
var active = true;  // is current tab

// good
// is current tab
var active = true;

Guilty. I’ll quit doing this, as tempting as it is for the sake of shorter files…

Saving a reference to “this”

Oops, here’s another mea culpa. I’ve been saving reference to “this” as “self”, but the style guide suggests _this as a better alternative.

I’m inclined to agree – I found “self” confusing the first time I encountered it, and its relation to “this” wasn’t immediately apparent.

// bad
function() {
  var self = this;
  return function() {

// bad
function() {
  var that = this;
  return function() {

// good
function() {
  var _this = this;
  return function() {

Those are just a handful of the discoveries I made while exploring this guide.

Be sure to check it out yourself and see what you could be doing better, and don’t miss the giant list of resources at the bottom of the page!

Declaring a variable as a number before adding to it with +=

Today I learned… that you have to explicitly declare a number variable as a number before you can increment it with += in JavaScript.

This is probably a boneheaded newbie mistake, but it had me stumped for several minutes. I declared a variable, var total; and then tried to add to it by writing total +=5.  And then I scratched my head as my code returned NaN.

var total;
total += 5;
console.log(total); //prints "NaN"

This happens because “undefined” and zero are not equivalent in JavaScript! 

Even though JavaScript isn’t “strongly typed”, you can’t add numbers to something that isn’t a number yet.

Declaring total by setting it to an actual number, ie: var total = 0, fixed my “NaN” problem.

var total = 0;
total += 5;
console.log(total); //prints a 5

Add a screenshot to your Github repo

Today I learned… that you can add images to a Github repository file! I’m now drunk with power and the desire to decorate all my repos with screenshots.


![alt text](screenshots/filename.png "Description goes here")

This approach (with a relative filepath to screenshots/filename.png) assumes your screenshot is part of your repo. For student projects, personal work, and other small stuff, including screenshots in your repo is no biggie.

If you don’t want the screenshot in your repo, you can upload it somewhere else and link to it directly like so:

![alt tag]( "Description goes here")

.png is the preferred file format.

To take a screenshot on a Mac, press COMMAND + SHIFT + 4 at the same time. By default, the screenshot is saved as a .png to your desktop.

Reasons why repo screenshots rule:

  • screenshots illustrate what the project does
  • they help distinguish your repos from one another
  • they can help you remember projects you worked on a while ago
  • they show off your ability to document your work*
  • save you from having to clone in a project and start up a server to remember what it looked like
  • make a pretty portfolio of your work

* Documenting your stuff helps future-you and everyone else you might ever work with (including maybe your manager or boss). The people who do well in their careers are often those who take the time to record what they did, how they did it, why they did it that way, and share it with others. The ability to document one’s work is something I always looked for when making a hiring decision.

Screenshot action shot:

Screen Shot 2014-09-10 at 10.16.02 AM

I don’t expect to win any graphic design awards here, but I can surf my own repos and remember what I did at a glance, which is pretty sweet.

Quickly add lines to .gitignore using echo in the command line

Today I learned… that you don’t have to open .gitignore in your editor, add a line(s) to it, save it, and close it. You can do all that in one step from the command line using echo!

Here’s a preview:

$ echo '.DS_Store' >> .gitignore

How it works

Here’s a common scenario. You do git status on your working folder and discover git wants to add some file you don’t want added to your remote repository, like the pesky .DS_Store file.

Thanks, but no thanks, git. I don't want that .DS_Store file in my git repository.
Thanks, but no thanks, git. I don’t want that .DS_Store file in my git repository.

If your git project doesn’t already have a .gitignore file, create one in one step by typing this while in your project’s root directory:

$ touch .gitignore

From here, you could open that .gitignore file in an editor and add lines to it, save it and close it, but that’s rather cumbersome if all you need to add is one or a few lines.

Here’s a faster way, using “echo” to push some new data into the file.

$ echo '.DS_Store' >> .gitignore

The double >> is important. If you type just one >, you’ll overwrite the existing contents. Using >> appends your echo string to the end.

For a sanity check, open up .gitignore and you’ll see that .DS_Store has been added.

Once you’re more accustomed to using .gitignore you’ll probably come up with a “boilerplate” .gitignore to copy and paste into all your projects, but you’ll probably never reach a point where you aren’t occasionally surprised by an unwanted file showing up in your git status.