As easy as 1, 2, 3!
Updated:
- Aug, 08, 2022 update
config
docs for npm 8+ - Jul 27, 2021 add private scopes
- Jul 22, 2021 add dist tags
- Jun 20, 2021 update for
--access=public
- Sep 07, 2020 update docs for
npm version
/* | |
* Copyright (C) 2008 Apple Inc. All Rights Reserved. | |
* | |
* Redistribution and use in source and binary forms, with or without | |
* modification, are permitted provided that the following conditions | |
* are met: | |
* 1. Redistributions of source code must retain the above copyright | |
* notice, this list of conditions and the following disclaimer. | |
* 2. Redistributions in binary form must reproduce the above copyright | |
* notice, this list of conditions and the following disclaimer in the |
// Joins path segments. Preserves initial "/" and resolves ".." and "." | |
// Does not support using ".." to go above/outside the root. | |
// This means that join("foo", "../../bar") will not resolve to "../bar" | |
function join(/* path segments */) { | |
// Split the inputs into a list of path commands. | |
var parts = []; | |
for (var i = 0, l = arguments.length; i < l; i++) { | |
parts = parts.concat(arguments[i].split("/")); | |
} | |
// Interpret the path commands to get the new resolved path. |
A design rationale.
For the past fews years, the Web has been shifting control to the client. Given the limitations of remote services, developers are now looking for ways to "unhost" static applications – that is, break the dependency on remote servers while still using the Web platform.
One untapped technology for client-side control is the Web Worker Sandbox. This API lets the Page load, execute, and destroy separate Worker threads which use their own Virtual Machines. By using Worker Sandboxes to drive behavior, the Web can give users the choice of which software they run together, shifting development from a centralized SaaS model into a distributed and free (as in freedom) script-sharing model.
Worker Sandboxes can Execute Arbitrary Code
A state machine is defined as follows:
Input
- a set of inputsOutput
- a set of outputsState
- a set of statesS0 ∈ S
- an initial stateT : Input * State -> Output * State
- a transition functionIf you model your services (aggregates, projections, process managers, sagas, whatever) as state machines, one issue to address is management of State
. There must be a mechanism to provide State
to the state machine, and to persist resulting State
for subsequent retrieval. One way to address this is by storing State
is a key-value store. Another way is to use a SQL database. Yet another way is event sourcing. The benefit of even sourcing is that you never need to store State
itself. Instead, you rely on the Output
of a service to reconstitute state. In order to do that, the state machine transition function needs to be factored into two functions as follows:
(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:
Server-Sent events is a specification for implementing server-side-push for web frontend applications, through plain-old HTTP.
It is best contrasted with WebSockets, which offer a full-duplex messaging channel over a custom protocol, operating within a single TCP connection (with an HTTP-compatible handshake).
node server.js