Skip to content

Instantly share code, notes, and snippets.

View eiriklv's full-sized avatar
🤒
Out sick - I may be slow to respond.

Eirik L. Vullum eiriklv

🤒
Out sick - I may be slow to respond.
View GitHub Profile
var exchange = require('./exchange');
module.exports = BinaryHeap;
function BinaryHeap(scoreFunction, options){
this.content = [];
if (options)
this.options = options;
else
this.options = {};
@eiriklv
eiriklv / test.js
Last active August 29, 2015 14:08 — forked from jmyrland/test.js
/**
* Modify the parts you need to get it working.
*/
var should = require('should');
var request = require('../node_modules/request');
var io = require('socket.io-client');
var serverUrl = 'http://localhost';
(function() {
var CSSCriticalPath = function(w, d, opts) {
var opt = opts || {};
var css = {};
var pushCSS = function(r) {
if(!!css[r.selectorText] === false) css[r.selectorText] = {};
var styles = r.style.cssText.split(/;(?![A-Za-z0-9])/);
for(var i = 0; i < styles.length; i++) {
if(!!styles[i] === false) continue;
var pair = styles[i].split(": ");
/**
* Adapted from https://github.com/Khan/react-components/blob/master/js/timeout-transition-group.jsx
*/
var React = require('react/addons');
var ReactTransitionGroup = React.addons.TransitionGroup;
var Velocity = require('velocity-animate');
var transitions = {
// Forcefeeding: property order = [after, before]

If you haven't read Netflix's Node.js in Flames blog post you should. It is a great deep dive into debugging a node performance problem. The post includes useful tips that can help you solve similar problems.

That said...

My feedback from the perspective of a framework developer is quite different. I found the tone and attitude towards express.js to be concerning and somewhat offensive. Here was a developer blaming the framework he chose for poor architecture when they never bothered to actually learn how the framework works in the first place. Everything that followed originated from this basic lack of understanding.

Express uses a very simple router logic which is at the core of how express works, so let’s examine that first (my knowledge of express is somewhat dated but I think the principal is still the same). Express keeps a hash of the various HTTP methods (GET, POST, etc.) and for each method, an array of middlewares. Each middleware is ju

@eiriklv
eiriklv / knapsack.js
Last active August 29, 2015 14:10 — forked from danwoods/knapsack.js
//Knapsack algorithm
//==================
// wikipedia: [Knapsack (0/1)](http://en.wikipedia.org/wiki/Knapsack_problem#0.2F1_Knapsack_Problem)
// Given a set `[{weight:Number, benefit:Number}]` and a capacity,
// find the maximum value possible while keeping the weight below
// or equal to the capacity
// **params**:
// `capacity` : Number,
// `items` : [{w:Number, b:Number}]
// **returns**:

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

browserify for webpack users

There's been a strange explosion in misinformation about browserify recently, particularly in comparisons to webpack.

Generally speaking, most of this confusion stems from how webpack is more willing to pull features into its core to ease discoverability while browserify is more likely to push features out to userland instead.

I think that longer-term, separability has more benefits from a maintenance and

// browserify
var browserify = require('browserify');
var es6ify = require('es6ify');
// gulp stuff
var gulp = require('gulp');
var livereload = require('gulp-livereload');
var source = require('vinyl-source-stream');
var jshint = require('gulp-jshint');
var livereload = require('gulp-livereload');
var watch = require('gulp-watch');
var express = require('express');
var _ = require('highland');
var fs = require('fs');
var app = express();
function chain(s, f) {
return s.flatMap(_.wrapCallback(f))
}
app.post('/process-file', function(req, res) {