... or Why Pipelining Is Not That Easy
Golang Concurrency Patterns for brave and smart.
By @kachayev
// Playbook - http://play.golang.org/p/3wFl4lacjX | |
package main | |
import ( | |
"bytes" | |
"crypto/aes" | |
"crypto/cipher" | |
"crypto/rand" | |
"encoding/base64" |
var fs = require('fs'); | |
var infile = process.argv[2]; | |
if (!infile) return console.log("need infile"); | |
var data = fs.readFileSync(infile, 'utf8').split('\n'); | |
var outlines = []; | |
data.forEach(function(item) { |
... or Why Pipelining Is Not That Easy
Golang Concurrency Patterns for brave and smart.
By @kachayev
THIS GIST WAS MOVED TO TERMSTANDARD/COLORS
REPOSITORY.
PLEASE ASK YOUR QUESTIONS OR ADD ANY SUGGESTIONS AS A REPOSITORY ISSUES OR PULL REQUESTS INSTEAD!
A future version of Ember will come with a new templating engine known as HTMLBars.
The original motivation for HTMLBars was to allow helpers and properties to have better contextual information about what they were bound to.
So for example, consider a template like this:
<!DOCTYPE html> | |
<html> | |
<head> | |
<meta charset="utf-8"> | |
<title>Why can't I have Proxy yet??</title> | |
</head> | |
<body> | |
<div id="item"> | |
<h1 class="name">name goes here</h1> |
HTMLBars serves as a polyfill for a native implement of node.bind
.
Instead of letting the browser parse the HTML and generate nodes, which leaves us at the mercy of the limitations of the parser, HTMLBars implements an HTML parser and generates the nodes itself.
As HTMLBars generates the nodes, it calls into node.bind
if it detects mustache syntax.
Open questions:
The Ember router is getting number of enhancements that will greatly enhance its power, reliability, predictability, and ability to handle asynchronous loading logic (so many abilities), particularly when used in conjunction with promises, though the API is friendly enough that a deep understanding of promises is not required for the simpler use cases.
Over the last 3 years or so I've helped a bunch of companies, small and large, switch to Django. As part of that, I've done a lot of teaching Django (and Python) to people new to the platform (and language). I'd estimate I've trained something around 200-250 people so far. These aren't people new to programming — indeed, almost all of them are were currently employed as software developers — but they were new to Python, or to Django, or to web development, or all three.
In doing so, I've observed some patterns about what works and what doesn't. Many (most) of the failings have been my own pedagogical failings, but as I've honed my coursework and my skill I'm seeing, time and again, certain ways that Django makes itself difficult to certain groups of users.
This document is my attempt at organizing some notes around what ways different groups struggle. It's not particularly actionable — I'm not making any arguments about what Django should or shouldn't do (at least