工业聚 Lucifier129

Rough Notes about CQRS and ES

Once upon a time…

I once took notes (almost sentence by sentence with not much editing) about the architectural design concepts - Command and Query Responsibility Segregation (CQRS) and Event Sourcing (ES) - from a presentation of Greg Young and published it as a gist (with the times when a given sentence was heard).

I then found other summaries of the talk and the gist has since been growing up. See the revisions to know the changes and where they came from (aka the sources).

It seems inevitable to throw Domain Driven Design (DDD) in to the mix.

Concept

People talk about two servers: a web server (e.g. Nginx, Apache, etc.) and a app server (e.g. Language specific servers like Unicorn, Node.js, Tomcat, Http-Kit, etc.). There are exceptions where app servers not required at all (as web server itself provides preprocessors for handling), but let's not talk about now.
Web servers are really fast and supports lot of standard and commonly used MIME-type requests. Concept of serving a file is -- forming and sending a response of bytes of data and labeling it with requested MIME-type by a client (e.g. web browser).
Every response format (in layman's language, a file) is recognized by it's MIME-type, for e.g. a PNG image file has "image/png" MIME-type. JavaScript file has "text/javascript". HTML responses (or files) has "text/html". Plain text files have "text/plain".
Modern Browsers supports a lot of standard MIME-types. Images, videos, text files (XML, HTML, SVG, JS), and they better know how to visualize it. Browser also knows unrec

Moved to Shopify/graphql-design-tutorial

Haskell Language Extension Taxonomy

Caveat: It's just personal opinion, and was written to be a bit provocative and encourage discussion . It is also something that is constantly evolving. Some of the main criteria I used in constructing this taxonomy are age, how widely used it us, and how well understood it is by the average Haskell programmer. These things will change over time.

Aso, this is focused on appropriateness for use in commercial production code bases. If you are not thinking about commercial use with a team of multiple

I saw this poll on Twitter earlier and was surprised at the result, which at the time of writing overwhelmingly favours option 1:

I've always been of the opinion that the (req, res, next) => {} API is the worst of all possible worlds, so one of two things is happening:

I'm an idiot with bad opinions (very possibly!)
People like familiarity

	<!doctype html>

	<!-- http://taylor.fausak.me/2015/01/27/ios-8-web-apps/ -->

	<html>
	<head>
	<title>iOS 8 web app</title>

	<!-- CONFIGURATION -->

	/**
	* Algebraic Effects and Handlers as in <a href='http://www.eff-lang.org/'>Eff</a>
	*/

	'use strict'
	//
	// Note:
	// new Continuation() - returns the current function's continuation.
	//


	// We model the call stack using a linked list of Generators
	// Each Generator has a _return field pointing back to its parent

	function stepGen(gen, arg) {
	const {done, value} = gen.next(arg)
	if(done) {
	if(gen._return) {
	stepGen(gen._return, value)
	}

	// A nano dependent type-checker featuring inductive types via self encodings.
	// All computation rules are justified by interaction combinator semantics,
	// resulting in major simplifications and improvements over old Kind-Core.
	// Specifically, computable annotations (ANNs) and their counterpart (ANN
	// binders) and a new self encoding based on equality (rather than dependent
	// motives) greatly reduce code size. A more complete file, including
	// superpositions (for optimal unification) is available on the
	// Interaction-Type-Theory repository.
	// Credits also to Franchu and T6 for insights.