Mathieu Darse mdarse

OBSOLETE

This entire guide is based on an old version of Homebrew/Node and no longer applies. It was only ever intended to fix a specific error message which has since been fixed. I've kept it here for historical purposes, but it should no longer be used. Homebrew maintainers have fixed things and the options mentioned don't exist and won't work.

I still believe it is better to manually install npm separately since having a generic package manager maintain another package manager is a bad idea, but the instructions below don't explain how to do that.

Fixing npm On Mac OS X for Homebrew Users

Installing node through Homebrew can cause problems with npm for globally installed packages. To fix it quickly, use the solution below. An explanation is also included at the end of this document.

Encoding Video

Installing

Install FFmpeg with homebrew. You'll need to install it with a couple flags for webm and the AAC audio codec.

brew install ffmpeg --with-libvpx --with-libvorbis --with-fdk-aac --with-opus

# $LOCAL_IP: 'localhost' or machine from local network
# $LOCAL_PORT: open port on local machine
# $REMOTE_IP: remote localhost or IP from remote network
# $REMOTE_PORT: open port on remote site

# Forward Tunnel: map port from remote machine/network on local machine
ssh -L $LOCAL_PORT:$REMOTE_IP:$REMOTE_PORT $USER@$SERVER

# Reverse Tunnel: make local port accessable to remote machine

Since it has come up a few times, I thought I’d write up some of the basic ideas around domain modeling in Clojure, and how they relate to keyword names and Specs. Firmly grasping these concepts will help us all write code that is simpler, cleaner, and easier to understand.

Clojure is a data-oriented language: we’re all familiar with maps, vectors, sets, keywords, etc. However, while data is good, not all data is equally good. It’s still possible to write “bad” data in Clojure.

“Good” data is well defined and easy to read; there is never any ambiguity about what a given data structure represents. Messy data has inconsistent structure, and overloaded keys that can mean different things in different contexts. Good data represents domain entities and a logical model; bad data represents whatever was convenient for the programmer at a given moment. Good data stands on its own, and can be reasoned about without any other knowledge of the codebase; bad data is deeply and tightly coupled to specific generating and

	#!/bin/bash

	function remove_dir () {
	rm -rf "$1_"

	if [ -d "$1" ]
	then
	mv "$1" "$1_"
	fi
	}

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

	cradle.setup({
	host: 'foo.cloudant.com',
	port: 80,
	cache: false,
	timeout: 5000
	})

	* {
	font-size: 12pt;
	font-family: monospace;
	font-weight: normal;
	font-style: normal;
	text-decoration: none;
	color: black;
	cursor: default;
	}

	<?php

	$formHtml = <<<'HTML'
	<form action="%s" method="post">
	<label for="email">Email:</label>
	<input
	type="email"
	id="email"
	name="email"
	value=""

	const I = x => x
	const K = x => y => x
	const A = f => x => f (x)
	const T = x => f => f (x)
	const W = f => x => f (x) (x)
	const C = f => y => x => f (x) (y)
	const B = f => g => x => f (g (x))
	const S = f => g => x => f (x) (g (x))
	const S_ = f => g => x => f (g (x)) (x)
	const S2 = f => g => h => x => f (g (x)) (h (x))

	"""Ansible dict filters."""

	# Make coding more python3-ish
	from __future__ import (absolute_import, division, print_function)
	__metaclass__ = type


	from ansible.errors import AnsibleError