Arvid Kahl arvidkahl

UPSTART

sudo vi /etc/init/.conf

add inside:

description "<reponame>"
author "name"

The final result: require() any module on npm in your browser console with browserify

This article is written to explain how the above gif works in the chrome (and other) browser consoles. A quick disclaimer: this whole thing is a huge hack, it shouldn't be used for anything seriously, and there are probably much better ways of accomplishing the same.

Update: There are much better ways of accomplishing the same, and the script has been updated to use a much simpler method pulling directly from browserify-cdn. See this thread for details: mathisonian/requirify#5

inspiration

Several developers asked me about how difficult it will be to migrate Angular 1 to Angular 2. Angular 2 isn't done, so I legitimately have no idea how hard it will be. But there are a few high-level guiding principals in the design of Angular 1 that make adapting to changes like this fairly painless.

Angular 1 was designed so it would have a fairly minimal API surface. Let's look at controllers, since these are the meat of your app. Controllers are just functions that get passed other components as arguments:

MyController ($scope) {
  $scope.list = [];
  
  $scope.addItem = function (name) {
    $scope.list.push({

My Elixir Deployment Wishlist

Foreward

Based on my recent experience of deployment, I've become rather frustrated with the deployment tooling in Elixir. This document is the result of me thinking to myself, "I wish we had x...". This document isn't meant to dishearten anyone who has built tooling for elixir - thank you so much for what you've done. This is meant more as what I personally see as something that would help a lot of Erlang/Elixir newbies like myself to be able to get deploying quickly and efficiently.

1. Release files should be templates

It should be possible to add in custom configuration to the bootstrap scripts. This would allow plugins to be able to add extra steps to the startup / shutdown / upgrade procedure. One way to implement this would be to make all scripts which handle bootstrapping or controlling the machine [.eex][1] templates. This would allow other parts of the release system to inject new functionality where needed.

	# CoffeeScript and Stylus watch/build cakefile
	{spawn, exec} = require 'child_process'

	task 'assets:watch', 'Watch source files and build JS & CSS', (options) ->
	runCommand = (name, args...) ->
	proc = spawn name, args
	proc.stderr.on 'data', (buffer) -> console.log buffer.toString()
	proc.stdout.on 'data', (buffer) -> console.log buffer.toString()
	proc.on 'exit', (status) -> process.exit(1) if status isnt 0

	// Subclass marker
	var CustomMarker = L.Marker.extend({
	// override the update function
	update: function(){
	//call the original update method
	L.Marker.prototype.update.call(this);

	// fire the update event
	this.fire("update");

	<!DOCTYPE html>
	<html>
	<head>
	<title>My Iframe</title>
	</head>
	<body>

	<button>Botão</button>

	<script type="text/javascript">

	(function(window){

	var EVENT_EXISTS = 'GlobalEvents: Event already exists.';

	var eventIsRunning,
	_eventStack,
	_findByName,
	stackEvent,
	removeEvent,
	eventListener,

	var addUnloadEvent = function(unloadEvent, device) {

	// device is a object containing parsed user-agent information

	var executed = false,
	exec = function() {
	if (!executed) {
	executed = true;
	unloadEvent();
	}

	Openstack as microservices
	--------------------------

	One of the more promising experiments I did in the devops space in the last couple of years was supporting
	microservices architectures in the way OpenStack is deployed and operated. The core design is that we have
	consul running across all nodes as the initial or 'seed' service to establish cluster membership, and from
	that base we can build everything we need. When data changes in consul, this triggers puppet runs on the
	nodes that are subscribing to that data via consul_watch, and the updated data is sent in via hiera to be
	realised on each node. This creates a feedback loop whereby services can be arbirtrarily distributed or
	consolidated as needed depending on the deployment scenario.