Andrey Bakuta dra1n

Architecture in Elm

This document is a collection of concepts and strategies to make large Elm projects modular and extensible.

We will start by thinking about the structure of signals in our program. Broadly speaking, your application state should live in one big foldp. You will probably merge a bunch of input signals into a single stream of updates. This sounds a bit crazy at first, but it is in the same ballpark as Om or Facebook's Flux. There are a couple major benefits to having a centralized home for your application state:

There is a single source of truth. Traditional approaches force you to write a decent amount of custom and error prone code to synchronize state between many different stateful components. (The state of this widget needs to be synced with the application state, which needs to be synced with some other widget, etc.) By placing all of your state in one location, you eliminate an entire class of bugs in which two components get into inconsistent states. We also think yo

The introduction to Reactive Programming you've been missing

(by @andrestaltz)

This tutorial as a series of videos

If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.

From https://en.wikipedia.org/wiki/Zebra_Puzzle

There are five houses.
The Englishman lives in the red house.
The Spaniard owns the dog.
Coffee is drunk in the green house.
The Ukrainian drinks tea.
The green house is immediately to the right of the ivory house.
The Old Gold smoker owns snails.
Kools are smoked in the yellow house.

Clustering: The basics

The trick? pass the file descriptor from a parent process and have the server.listen reuse that descriptor. So multiprocess in their own memory space (but with ENV shared usually)

It does not balance, it leaves it to the kernel.

In the last nodejs > 0.8 there is a cluster module (functional although marked experimental)

http://nodejs.org/api/cluster.html
Simple cluster example:

	import { Component } from "React";

	export var Enhance = ComposedComponent => class extends Component {
	constructor() {
	this.state = { data: null };
	}
	componentDidMount() {
	this.setState({ data: 'Hello' });
	}
	render() {

	// These two need to be declared outside the try/catch
	// so that they can be closed in the finally block.
	HttpURLConnection urlConnection = null;
	BufferedReader reader = null;

	// Will contain the raw JSON response as a string.
	String forecastJsonStr = null;

	try {
	// Construct the URL for the OpenWeatherMap query

	// This script will boot app.js with the number of workers
	// specified in WORKER_COUNT.
	//
	// The master will respond to SIGHUP, which will trigger
	// restarting all the workers and reloading the app.

	var cluster = require('cluster');
	var workerCount = process.env.WORKER_COUNT \|\| 2;

	// Defines what each worker needs to run

	(ns reagent-test.core
	(:require [reagent.core :as reagent :refer [atom]]
	[datascript :as d]
	[cljs-uuid-utils :as uuid]))

	(enable-console-print!)

	(defn bind
	([conn q]
	(bind conn q (atom nil)))

	#!/bin/bash

	# Author: Erik Kristensen
	# Email: erik@erikkristensen.com
	# License: MIT
	# Nagios Usage: check_nrpe!check_docker_container!_container_id_
	# Usage: ./check_docker_container.sh _container_id_
	#
	# Depending on your docker configuration, root might be required. If your nrpe user has rights
	# to talk to the docker daemon, then root is not required. This is why root privileges are not

	function harvest(id, parent) {
	var promise = $.Deferred();
	var post;

	request({
	url: "...",
	json: true,
	timeout: 30000
	}, function(error, response, body) {