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 'https://github.com': xyz
Password for 'https://xyz@github.com':

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 TowerSecrets.com

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 Amazon.com 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 README.md

Today I learned… that you can add images to a Github repository README.md 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](http://domain.com/path/to/img.png "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.


Automate Express server restarts with Nodemon

Today I learned… that you don’t have to navigate to Terminal, press CTRL + C to stop the server, and re-enter node server.js to start up the express server again in order to see your latest work in the browser.

There’s a better way: get Nodemon and automate this repetitive process!

Nodemon will watch the files in the directory you run it in and restart your server automatically when it detects a change.

To install Nodemon:

$ npm -g install nodemon

To get Nodemon running:

$ nodemon server.js

Leave that Terminal window open and let Nodemon work its magic.