Teddy Zetterlund teddyzetterlund

Get started with Ansible in 2 minutes

Install Ansible

$ brew install ansible            # OSX
$ [sudo] pip install ansible # elsewhere

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

@holman got a request about our deployment system, heaven

I know it's not a high priority, but has there been any activity on open-sourcing the core Heaven gem?

There is. I've been working on extracting the non-GitHub specific parts into two gems. This first is a CLI portion called hades. The second is an HTTP API portion called heaven.

When you open source something previously used as in internal tool like Heaven, Hubot, Boxen, etc., how do you manage and hook in the parts that need to stay internal?

Normally I focus around four questions:

Website Contract [month] [year]

Description of this Contract

This contract is not meant to trick or deceive you; the intention is purely to protect both parties. I have tried to keep the wording as plain as possible, but if anything is unclear, please let me know and I will be more than happy to clarify it with you. Also, until you sign it, please feel free to request to change bits of it to suit your requirements.

In short, [client name] is contracting me, [my name], to [description of my role] between [start date and finish date].

By signing this, you are confirming that you have the power and ability to enter into this contract on behalf of [client's company].

Each of these commands will run an ad hoc http static server in your current (or specified) directory, available at http://localhost:8000. Use this power wisely.

Discussion on reddit.

Python 2.x

$ python -m SimpleHTTPServer 8000

Make it real

Ideas are cheap. Make a prototype, sketch a CLI session, draw a wireframe. Discuss around concrete examples, not hand-waving abstractions. Don't say you did something, provide a URL that proves it.

Ship it

Nothing is real until it's being used by a real user. This doesn't mean you make a prototype in the morning and blog about it in the evening. It means you find one person you believe your product will help and try to get them to use it.

Do it with style

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.)

	// Class implementation with inheritance.
	//
	// Creates a constructor function with all the properties of ``params`` and
	// keeps the ``constructor`` property of the prototype intact.
	//
	// Chains the object of special ``params`` key ``Extends`` on the prototype
	// and prevents multiple calls to initialize in a MooTools Class compatible
	// way. Property ``parent`` of the prototype is set to the chained object.
	var Class = function(params) {
	this.createConstructor();

	# A simple Makefile alternative to using Grunt for your static asset compilation
	#
	## Usage
	#
	# $ npm install
	#
	# And then you can run various commands:
	#
	# $ make # compile files that need compiling
	# $ make clean all # remove target files and recompile from scratch

	My woman's in LA
	who wants to grab a beer after work
	My woman just informed me
	that she'll work extra this very evening,
	the universe is telling us something!

	My woman tells me to clean the windows.
	My windows tells me to get a woman.
	That's poo if anyone wonders
	My woman tells me to pick up the kids,