akras14

Git Cheat Sheet

Commands

Getting Started

git init

or

pnommensen

Full blog post can be found here: http://pnommensen.com/2014/09/07/high-performance-ghost-configuration-with-nginx/

Ghost is an open source platform for blogging founded by John O'Nolan and Hannah Wolfe. It's a node.js application and therefore works great in conjunction with nginx. This guide will will help you create a high performance nginx virtual host configuration for Ghost.

"Don't use #nodejs for static content" - @trevnorris. If #nginx isn't sitting in front of your node server, you're probably doing it wrong.

— Bryan Hughes (@nebrius) August 30, 2014

<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

The node.js application runs on a port on your server

jmar777

First, we need to figure out what the actual error is.  This is obviously frustrating given that the error message is intentionally truncating it.

1) SSH in to your node (various guides available for this if you're not already familiar with this).
2) Run this command (basically an Elastic Beanstalk wrapper command for npm install I found in a blog post [1]):
   $ sudo /opt/elasticbeanstalk/containerfiles/ebnode.py --action npm-install 2
3) Find the actual error message in the output from the npm install.

Once you know the error, it should hopefully be fairly obvious how to fix it.  I've run into two different errors over the last couple days on Elastic Beanstalk:

The first was a dependency that was using the new "^X.Y.Z" version syntax, which is only supported in Node >= v0.10.26 (whereas Elastic Beanstalk only supports up to v0.10.21 as of today).  The solution here was easy: hardcode a dependency version *prior* to when that dependency adopted to the new syntax.

jed

How to set up stress-free SSL on an OS X development machine

One of the best ways to reduce complexity (read: stress) in web development is to minimize the differences between your development and production environments. After being frustrated by attempts to unify the approach to SSL on my local machine and in production, I searched for a workflow that would make the protocol invisible to me between all environments.

Most workflows make the following compromises:

• Use HTTPS in production but HTTP locally. This is annoying because it makes the environments inconsistent, and the protocol choices leak up into the stack. For example, your web application needs to understand the underlying protocol when using the secure flag for cookies. If you don't get this right, your HTTP development server won't be able to read the cookies it writes, or worse, your HTTPS production server could pass sensitive cookies over an insecure connection.

• Use production SSL certificates locally. This is annoying

jordanbaucke

var https = require('https');
var crypto = require('crypto');

var url = 'https://bitfinex.com/api/v1/balances';
var subPath = '/balances';

var api_key = '';
var api_secret = '';

var path = '/api/v1' + subPath;

clonn

/**                                                                                                                                                                               
 * @overview                                                                                                                                                                      
 *                                                                                                                                                                                
 * @author Caesar Chi                                                                                                                                                             
 * @blog clonn.blogspot.com                                                                                                                                                       
 * @version 2012/02/27                                                                                                           

chitchcock

Stevey's Google Platforms Rant

I was at Amazon for about six and a half years, and now I've been at Google for that long. One thing that struck me immediately about the two companies -- an impression that has been reinforced almost daily -- is that Amazon does everything wrong, and Google does everything right. Sure, it's a sweeping generalization, but a surprisingly accurate one. It's pretty crazy. There are probably a hundred or even two hundred different ways you can compare the two companies, and Google is superior in all but three of them, if I recall correctly. I actually did a spreadsheet at one point but Legal wouldn't let me show it to anyone, even though recruiting loved it.

I mean, just to give you a very brief taste: Amazon's recruiting process is fundamentally flawed by having teams hire for themselves, so their hiring bar is incredibly inconsistent across teams, despite various efforts they've made to level it out. And their operations are a mess; they don't real