Rafa Yepes rafayepes

The introduction to Reactive Programming you've been missing

This tutorial as a series of videos

If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.

Better local require() paths for Node.js

Problem

When the directory structure of your Node.js application (not library!) has some depth, you end up with a lot of annoying relative paths in your require calls like:

const Article = require('../../../../app/models/article');

Those suck for maintenance and they're ugly.

Possible solutions

⇐ back to the gist-blog at jrw.fi

Project-specific lint rules with ESLint

A quick introduction

First there was JSLint, and there was much rejoicing. The odd little language called JavaScript finally had some static code analysis tooling to go with its many quirks and surprising edge cases. But people gradually became annoyed with having to lint their code according to the rules dictated by Douglas Crockford, instead of their own.

So JSLint got forked into JSHint, and there was much rejoicing. You could set it up to only complain about the things you didn't want to allow in your project, and shut up about the rest. JSHint has been the de-facto standard JavaScript linter for a long while, and continues to do so. Yet there will always be things your linter could check for you, but doesn't: your team has agreed on some convention that makes sense for them, but JSHint doesn't have an option

I'm doing some research on how companies use GitHub Enterprise (or public GitHub) internally. If you can help out by answering a few questions, I'd greatly appreciate it.

What is the primary setup? Is there an organization and each official repo is owned by that organization?
Does every engineer have a fork of each repo they're working on?
Are engineers allowed to push directly to the official repo? Or must all commits go through a pull request?
Do engineers work on feature branches on the main repo or on their own forks?
Do you require engineers to squash commits and rebase before merging?
Overall, what is the workflow for getting a new commit into the main repository?
What sort of hooks do you make use of?
Are there any ops issues you encountered? (Scaling, unforeseen downtime, etc.)

	/**
	* Annotated Gruntfile.
	* This builds a Backbone/Marionette application using Dust.js (Linkedin fork) as a
	* templating system, as well as some helpers from Foundation, with Browserify.
	* It also configures a watcher and static server with live reload.
	*/
	module.exports = function (grunt) {

	// This automatically loads grunt tasks from node_modules
	require("load-grunt-tasks")(grunt);

	if (typeof define !== 'function') {
	// Not AMD
	if (typeof require === 'function') {
	// Node.js
	var define = function (body) {
	module.exports = body(require);
	};
	} else {
	// Vanilla browser
	var define = function (body) {

	<!doctype html>
	<html>
	<head>
	<meta charset="utf-8">
	<title>crypto</title>
	</head>
	<body>

	<script src="./node_modules/vault-cipher/lib/crypto-js/aes.js"></script>
	<script src="./node_modules/vault-cipher/lib/crypto-js/pbkdf2.js"></script>

	(function() {
	'use strict';

	var indexOf = function(list, needle) {
	if (list.indexOf) return list.indexOf(needle);
	for (var i = 0, n = list.length; i < n; i++) {
	if (list[i] === needle) return i;
	}
	return -1;
	};

	// controller
	module.exports = {
	index: function(params, callback) {
	var spec = {
	posts: { collection: 'Posts', params: params },
	feed: { collection: 'Feed', params: params },
	user: { model: 'User', params: params, ensureKeys: ['name'] },
	session: { model: 'Session', params: params }
	};
	this.app.fetch(spec, function(err, result) {

	// modifierKey used to check if cmd+click, shift+click, etc.
	!function($, global){
	var $doc = $(document);
	var keys;

	global.modifierKey = false;

	global.keys = keys = {
	'UP': 38,
	'DOWN': 40,