I recently needed to send an AJAX request to a secure web service (a Node.js + Express service using Passport in particular) from within a Chrome extension and was hitting an issue with the web server not getting sent the session cookies for the domain. Here is how I solved it:

First, in your manifest.json, you need to declare your permissions properly for both cookies and the domain you’re requesting from:

The include part tells Chrome that you want to send a CORS request to the server which sends along the cookies properly.

Now you should be able to send requests to a secure webservice with your Chrome extension. This is particularly useful if you have an extension that needs to only work when a user is authorized and logged in.

NPM after version 2.0 has added the ability for developers to install local packages into their projects easily.

You would want to use a local package for a few reasons, but most commonly is when you’re developing a module and you want to test it out locally.

The docs discourage using this technique in production projects but don’t give clear arguments as to why.

You can follow this same technique to break your application up into sub components that you could eventually make into their own NPM modules. Doing this allows you to not have to use relative requires

First, you need to make sure that you are using at least NPM v2.0 or newer: npm -v

I’ve worked with enough teams to know that code review should be an essential part of any software team’s worflow.

It’s far too easy for mistakes, inconsistent conventions and low quality code to be introduced to ignore the benefits of code review.

Here are a few quick reasons why your team should be using code review if you aren’t already:

Better transparency into the work being created. When everyone sees the code added to a project, you increase the familiarity of all developers with the code base. The more familiarity each developer has, the faster they can make changes and reason about existing functionality.

Gives team members a chance to agree on implementation before it’s too late. It’s much easier to discuss implementation when the code is on a feature branch then after the fact when it’s in production. Use the code as a starting point for conversations about better paths of implementation.

Enforces standards and conventions. When everyone is on the same page about standards and conventions, your code base starts to appear to be written by a single person. This is a Good Thing ™.

Gives new developers a chance to ensure they’re taking edge cases into account. Allow new developers the benefit of the eyes of more senior engineers before committing code.

Allow developers to learn from each other. When developers see each others code, they tend to learn better ways to implement things. In my experience, even the most senior engineers have things to learn from their peers. The more learning you can facilitate, the better off your team is.

Fixing bugs before they exist. Many times in code review a potential bug is spotted before even making into the main line of development. Having other eyes on the code tends to suss out many bugs that the developer by themselves could not see.

As with everything, there are a few drawbacks to doing code review in a team, specifically:

The slight slow down of having to wait for a peer to review code. This can be mitigated if the team agrees to do code review as their first step when working for the day.

The time it takes to do review. In general, the drawback of development speed being slowed down is far outweighed by the improved quality of code and team collaboration as outlined above.

Team adoption. Getting developers to adopt code review can sometimes be tricky. I’ve found the best way is for the benefits to be clear to everyone on the team. It is also helpful to not allow any code to be merged into the main branch unless it’s been reviewed by at least one developer.

To my mind, these are acceptable drawbacks if creating quality software is your goal and I have yet to suffer because of implementing in a team.

If you are interested in implementing code review in your team, consider using tools like Github, Stash or GitLab to implement code review in your team. My personal favorite approach is to use Github Pull Requests to do collaborate review, but don’t let the tools get in you way towards adopting code review.

A quick one today, use scp to copy files to and from a remote machine. scp uses SSH to securely transfer files from one computer to another. As long as you’re able to SSH into a machine, you should be able to use scp.

The general structure of scp is:

scp user@host:file user@host:file

If you’re transferring to or from your local computer, you can just use a path instead.

To copy a remote file to your local machine:

scp user@example.com:backup-2014-05-04.zip ~/backups/

Or, copy a local file to the remote machine:

scp ~/cats.jpg user@example.com:~/

You can specify any source and target directories that you have permissions to write or read from.

scp is a simple and useful tool that should be part of any developers toolkit.

Combining components together

The most fundamental and useful part of React is that
you can create any number of components and nest them
just like you would any HTML tag. You pass down data
to your components from parent components in a one-way
data flow.

Note: If you use something like Flux/Reflux you have a bit
more power when it comes to data storage and event handling.
Using a Flux-like framework with React is very helpful but beyond
the scope of this article.

File this one under “note to self”, but knowing how to properly comment your JavaScript is an important part of being a proficient developer.

At the time of this article, jsdoc seems to be the industry standard for documentation formatting in the JavaScript world. It’s a succinct and helpful way to comment your JavaScript classes and methods.

To get started, first install jsdoc globally:

npm intall -g jsdoc

Now that it’s installed, you can run it on one of your JavaScript files:

jsdoc myfile.js

Of course you could do this every time you update your files, but if you’re really cool you can put it into your build process using something like Gulp, Grunt or the Rails asset pipeline.

Ok, with setup and running out of the way, let’s write some docs! Here is a sort of all-in-one example:

Sometimes you need to create a patch from a commit in your git repository. I’ve had to do this when moving some commits from an old repository over to a new one or for code review when a project isn’t using a code review tool like Pull Requests.

Here’s how you do it:

# For a specific commit SHA:
git format-patch -1 <sha>
# Shortcut for the commit at the branch's HEAD:
git format-patch -1 HEAD

The -1 flag says to only create a patch from the last commit. If you passed in, say -3, it would create a patch that contains the last 3 commits from <sha> on back in the history.

Then to apply the patch, run:

patch -p1 file.patch

Where file.patch is the patch file created from the above command. This applies the patch with any sort of meta information like author, date, etc… so it appears almost like it was cherry picked.

The approach I’ve been taking lately is to start my projects in the main package and as I go keep an eye for any emerging patterns or abstractions I can make.

Once I see something I feel can be pulled out of my code, I put it into a sub-directory in my project, give it a descriptive package name and then import it into my main package.

If a package is specific to the project I’m working on and would have little value as an external library, I’ll keep it in the sub-directory. Otherwise, I will abstract out the package into it’s own repository and think more seriously about the public interface.

Go makes creating new packages trivially easy: Just create a new folder foo, move your foo library over and change package main to package foo. I’d recommend taking advantage of that fact and abstract and encapsulate your code as much as possible using this convention.

This can be done in many other languages, but the fact that you can go get any code within a folder on Github or Google Code makes it simple to share packages with other developers or to reuse code in future projects.

If you’re coming from a Ruby background like myself where you’d have to create a new Ruby Gem each time, you can see how this encourages code reuse at a language level.

In Go, when a value is initialized without a initializer value it returns the “zero value” of that type.

In our contrived example below, when we initialize the User struct without an initialization value, we get the zero value of the struct. So when we get the Admin value, it returns the zero value for a boolean, which is false: