Liam Clancy metafeather

Falsehoods programmers believe about time

This is a compiled list of falsehoods programmers tend to believe about working with time.

Don't re-invent a date time library yourself. If you think you understand everything about time, you're probably doing it wrong.

Falsehoods

There are always 24 hours in a day.
February is always 28 days long.
Any 24-hour period will always begin and end in the same day (or week, or month).

From time to time, Musk will send out an e-mail to the entire company to enforce a new policy or let them know about something that's bothering him. One of the more famous e-mails arrived in May 2010 with the subject line: Acronyms Seriously Suck:

There is a creeping tendency to use made up acronyms at SpaceX. Excessive use of made up acronyms is a significant impediment to communication and keeping communication good as we grow is incredibly important. Individually, a few acronyms here and there may not seem so bad, but if a thousand people are making these up, over time the result will be a huge glossary that we have to issue to new employees. No one can actually remember all these acronyms and people don't want to seem dumb in a meeting, so they just sit there in ignorance. This is particularly tough on new employees.

That needs to stop immediately or I will take drastic action - I have given enough warning over the years. Unless an acronym is approved by me, it should not enter the SpaceX glossary.

Interactive Machine Learning

Taught by Brad Knox at the MIT Media Lab in 2014. Course website. Lecture and visiting speaker notes.

Power to the People: The Role of Humans in Interactive Machine Learning by Knox, Cakmak, Kulesza, Amershi, and Lau
A Few Useful Things to Know about Machine Learning by Domingos
Machine Learning that Matters by Wagstaff
Beyond Concise and Colorful: Learning Intelligible Rules by Pazzani et al.
[Designing Games with a Purpose] (https://www.cs.cmu.edu/~biglou/GWAP_CACM.pdf) by von Ahn and Dabbish
[Human Model Evaluation in Interactive Supervised

How to check file integrity with shasum

For verifying the integrity (but not authenticity of data, i.e., who authored it or the origin of the file) of a file, it is necessary to run a checksum function on the file which will output a value and compare it to a previously stored checksum value; if both values match, we can be relatively confident that the file hasn't been tampered with or altered.

You might be asked to verify a file's sha1sum or sha2sum–-all this means is calculating and verifying the cryptographic sha1 or sha2 hash value or digest included in the file.

Various commands and methods for verifying shasum 1 or 2:

Organic:
In terminal run:

	var els = document.getElementsByClassName('pl-video');

	for(i = 0; i < els.length; i++) {
	var el = els[i];
	if(el) {
	var src = el.getElementsByClassName('yt-thumb-clip')[0].getElementsByTagName('img')[0].src;
	if(!src.match(/\.com\/vi\//g)) { continue; }
	var id = src.split('.com/vi/')[1].split('/')[0];
	console.log(id);
	}

	#!/usr/bin/env node

	var express = require('express');
	var http = require('http');
	var path = require('path');
	var server = require('socket.io');
	var pty = require('pty.js');
	var fs = require('fs');

	var opts = require('optimist')

	/**
	* FAST PACKING / UNPACKING JSON
	*
	* If all objects in a collection follows a similar schema,
	* then there is gain in changing the representation from a dictionary to a simple array.
	*
	* It is known results used in database, protocols, in v8 itself with shadow maps and IRL.
	*
	* In this example, we expect our final exchange to be equivalent to this literal representation:
	* [

	import {jStat} from 'jstat'

	/**
	* describe statistics of data
	* like: http://pandas.pydata.org/pandas-docs/stable/generated/pandas.DataFrame.describe.html
	* @param {Object} data - e.g. {x:[1,2,3],y:[6,7,8]}
	* @return {Object} - e.g. {x:{mean:2,...},y:{...}}
	*/
	export function describe(data){
	var labels = {