Josh Duff TehShrike

Versioning in a Repository

Lately I've been doing a lot of thinking around versioning in repositories. For all the convenience and ubiquity of package.json, it does sometimes misrepresent the code that is contained within a repository. For example, suppose I start out my project at v0.1.0 and that's what's in my package.json file in my master branch. Then someone submits a pull request that I merge in - the version number hasn't changed even though the repository now no longer represents v0.1.0. The repository is actually now in an intermediate state, in between v0.1.0 and the next official release.

To deal with that, I started changing the package.json version only long enough to push a new release, and then I would change it to a dev version representing the next scheduled release (such as v0.2.0-dev). That solved the problem of misrepresenting the version number of the repository (provided people realize "dev" means "in flux day to day"). However, it introduced a yucky workflow that I really hate

This song is Copyrighted in U.S., under Seal of Copyright # 154085, for a period of 28 years, and anybody caught singin it without our permission, will be mighty good friends of ourn, cause we don’t give a dern. Publish it. Write it. Sing it. Swing to it. Yodel it. We wrote it, that’s all we wanted to do.

Woody Guthrie, 1940's —

Weird Idea

UPDATE working on this here!

so… I've had this weird idea recently...

In git (and in other secure + distributed systems) you have a tree of hashes where each object is identified by it's hash and objects contain pointers to other objects. They just have the hash of other objects stored inside them.

note: I converted this script into the much easier to install joinopenwifi module on NPM

see https://github.com/maxogden/joinopenwifi#joinopenwifi for installation instructions

title: A New Streaming API for Node v0.10 author: Isaac Z. Schlueter date: Sun Dec 16 16:46:12 PST 2012 slug: streams2 category: feature

tl;dr

Node streams are great, except for all the ways in which they're terrible.

In August 2007 a hacker found a way to expose the PHP source code on facebook.com. He retrieved two files and then emailed them to me, and I wrote about the issue:

http://techcrunch.com/2007/08/11/facebook-source-code-leaked/

It became a big deal:

http://www.techmeme.com/070812/p1#a070812p1

The two files are index.php (the homepage) and search.php (the search page)

Locate the section for your github remote in the .git/config file. It looks like this:

[remote "origin"]
	fetch = +refs/heads/*:refs/remotes/origin/*
	url = [email protected]:joyent/node.git

Now add the line fetch = +refs/pull/*/head:refs/remotes/origin/pr/* to this section. Obviously, change the github url to match your project's URL. It ends up looking like this:

	// Here’s a 100% deterministic alternative to `Math.random`. Google’s V8 and
	// Octane benchmark suites use this to ensure predictable results.

	Math.random = (function() {
	var seed = 0x2F6E2B1;
	return function() {
	// Robert Jenkins’ 32 bit integer hash function
	seed = ((seed + 0x7ED55D16) + (seed << 12)) & 0xFFFFFFFF;
	seed = ((seed ^ 0xC761C23C) ^ (seed >>> 19)) & 0xFFFFFFFF;
	seed = ((seed + 0x165667B1) + (seed << 5)) & 0xFFFFFFFF;

	var gpio = require("gpio")
	var gpio22, intervalTimer

	// Flashing lights if LED connected to GPIO22
	gpio22 = gpio.export(22, {
	ready: blinkLED
	})

	function blinkLED() {
	intervalTimer = setInterval(function() {