(by @andrestaltz)
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.
namespace MaybeMonad | |
{ | |
using System; | |
using System.Collections.Generic; | |
using System.Linq.Expressions; | |
using System.Reflection; | |
static class Monads | |
{ | |
/// <summary> |
var cluster = require('cluster'); | |
var http = require('http'); | |
var numCPUs = require('os').cpus().length; | |
if (cluster.isMaster) { | |
// Fork workers. | |
for (var i = 0; i < numCPUs; i++) { | |
cluster.fork(); | |
} | |
cluster.on('exit', function(worker, code, signal) { |
(by @andrestaltz)
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.
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:
Thanks to @seejee for making this for me!!!
The goal of this is to have an easily-scannable reference for the most common syntax idioms in C# and Rust so that programmers most comfortable with C# can quickly get through the syntax differences and feel like they could read and write basic Rust programs.
What do you think? Does this meet its goal? If not, why not?
type Term = | |
| Var of int | |
| Pair of Term * Term | |
| Int of int | |
let (|Find|_|) s k = Map.tryFind k s | |
let rec walk (s: Map<_,_>) = function | |
| Var(Find s t) -> walk s t | |
| t -> t |
This cheat sheet provides a detailed overview of the exposed lifecycle events and available commands (and entrypoints) of the Serverless framework, that can be hooked by plugins (internal and external ones). The document is structured by the commands invoked by the user.
Lifecycle events are shown as the globally available outer events (all providers) and sub lifecycle events that are provider specific in the called order. Currently only the AWS provider is shown. If you have information about the other provider,