| function Bezier(a, b, c, d) { | |
| this.a = a; | |
| this.b = b; | |
| this.c = c; | |
| this.d = d; | |
| this.len = 100; | |
| this.arcLengths = new Array(this.len + 1); | |
| this.arcLengths[0] = 0; | |
| // Named constants with unique integer values | |
| var C = {}; | |
| // Tokenizer States | |
| var START = C.START = 0x11; | |
| var TRUE1 = C.TRUE1 = 0x21; | |
| var TRUE2 = C.TRUE2 = 0x22; | |
| var TRUE3 = C.TRUE3 = 0x23; | |
| var FALSE1 = C.FALSE1 = 0x31; | |
| var FALSE2 = C.FALSE2 = 0x32; | |
| var FALSE3 = C.FALSE3 = 0x33; |
| /** | |
| * Requires node v0.7.7 or greater. | |
| * | |
| * To connect: $ curl -sSNT. localhost:8000 | |
| */ | |
| var http = require('http') | |
| , repl = require('repl') | |
| , buf0 = new Buffer([0]) |
| var net = require('net') | |
| var sock = net.connect(1337) | |
| process.stdin.pipe(sock) | |
| sock.pipe(process.stdout) | |
| sock.on('connect', function () { | |
| process.stdin.resume(); | |
| process.stdin.setRawMode(true) |
This article has been given a more permanent home on my blog. Also, since it was first written, the development of the Promises/A+ specification has made the original emphasis on Promises/A seem somewhat outdated.
Promises are a software abstraction that makes working with asynchronous operations much more pleasant. In the most basic definition, your code will move from continuation-passing style:
getTweetsFor("domenic", function (err, results) {
// the rest of your code goes here.
| /* | |
| S : \x y z -> x z (y z) | |
| */ | |
| // S :: (z -> (a -> b)) -> (z -> a) -> z -> b | |
| function S(x, y, z) { | |
| return x(z)(y(z)); | |
| } | |
| // example: | |
| // add :: a -> a -> a |
| /* | |
| <!DOCTYPE html> | |
| <html lang="en"> | |
| <head> | |
| <meta charset="UTF-8"> | |
| <title>VirtualDOM Example</title> | |
| </head> | |
| <body> | |
| <div id="output"></div> |
Web-based UIs are hard to componentize into encapsulated widgets. DOM + CSS and the browser runtime have their roots in a document-based, progressive-rendering mentality, and that creates friction when attempting to develop components that don't step on each others' feet.
My ultimate starting point when dealing with encapsulation in-browser is to consider the runtime state produced by the combination of JS, DOM API and CSS behaviour.
In purest form, there are just JS objects that exist in memory of the browser and interact with each other via vanilla method calls and data access. The surface of encapsulation of a pure-Javascript component is just its public methods and properties.
When it comes to displaying things on screen, part of the widget component contract becomes rendering something visible in the browser viewport. Of course, we typically use DOM and CSS to do that (although Canvas-driven app UIs do exist). It makes sense to look at DOM and CSS as a sort of
Enterprise software models the real world of human activity, interaction, business transactions. Let's consider a typical person modeled by a run-of-the-mill e-commerce app. They'll have a few attributes (read: DB table columns):
# Key considerations for algorithm "RSA" ≥ 2048-bit
openssl genrsa -out server.key 2048
# Key considerations for algorithm "ECDSA" ≥ secp384r1
# List ECDSA the supported curves (openssl ecparam -list_curves)