⌘T | go to file |
⌘⌃P | go to project |
⌘R | go to methods |
⌃G | go to line |
⌘KB | toggle side bar |
⌘⇧P | command prompt |
source 'http://rubygems.org' | |
gem 'less' | |
gem 'uglifier' | |
gem 'watchr' |
bash -c ' | |
<%= "export http_proxy=\"#{knife_config[:bootstrap_proxy]}\"" if knife_config[:bootstrap_proxy] -%> | |
yum install -y wget | |
wget <%= "--proxy=on " if knife_config[:bootstrap_proxy] %>http://rbel.co/rbel5 | |
rpm -Uvh rbel5 | |
yum install -y rubygem-chef | |
' |
body { | |
font-family: Helvetica, arial, sans-serif; | |
font-size: 14px; | |
line-height: 1.6; | |
padding-top: 10px; | |
padding-bottom: 10px; | |
background-color: white; | |
padding: 30px; } | |
body > *:first-child { |
This article has been given a more permanent home on my blog. Also, since it was first written, the development of the Promises/A+ specification has made the original emphasis on Promises/A seem somewhat outdated.
Promises are a software abstraction that makes working with asynchronous operations much more pleasant. In the most basic definition, your code will move from continuation-passing style:
getTweetsFor("domenic", function (err, results) {
// the rest of your code goes here.
#!/usr/bin/env perl | |
use strict; | |
use warnings; | |
use GD; | |
sub draw_page { | |
my ($width, $height) = @_; | |
return unless $width && $height; |
You've built (or are maintaining) a product which has many services over different machines at the backend, all orchestrating together to implement one or more business processes. How are you tracking this system?
In general: how can we provide visibility for linear-pipeline distributed systems where a series of processing stages are arranged in succession to perform a specific business function over a data stream (i.e. transaction), and across several machines?
A simple, somewhat crude, example for cross-systems transaction would be an order preparation system in real life, let's say in an electronics factory. During such a workflow, an order entering the processing pipeline goes through each stage defined by the manufacturing floor manager - "planning, provisioning, packing, shipping".
Taking this a bit closer to the Web, we can easily see instances of such transactions, even if we are not always aware we've implemented them that way. A background job is a pipeline, or a transa
# Copyight (c) 2013 Kenichi Kamiya | |
# No Strict parser for the LTSV(Labeled Tab Separated Values) format | |
# What is LTSV? | |
# @see http://stanaka.hatenablog.com/entry/2013/02/05/214833 | |
module LTSV | |
ROW_SEPARATOR = "\n".freeze | |
COLUMN_DELIMITER = "\t".freeze |
# -*- coding: us-ascii -*- | |
require 'csv' | |
require 'yaml' | |
class LTSV < CSV | |
attr_accessor :ordered | |
alias ordered? ordered | |
def self.def_options(opt, options = {}) |