- Functions
- Types, Kinds, & More Functions
- FP Toolbox
define(['handlebars'], function (Handlebars) { | |
var templateHelpers = { | |
// Register all defined template helpers | |
load: function () { | |
// Render JSON representation of current context, | |
// e.g., {{{debug this}}} | |
Handlebars.registerHelper('debug', function (context) { | |
return new Handlebars.SafeString( |
{-# LANGUAGE DataKinds #-} | |
{-# LANGUAGE GADTs #-} | |
{-# LANGUAGE PolyKinds #-} | |
{-# LANGUAGE TypeFamilyDependencies #-} | |
module Sigma where | |
import Data.Kind (Type) | |
type family Sing (i :: k) = (o :: Type) | o -> i |
{-# LANGUAGE DataKinds #-} | |
{-# LANGUAGE FlexibleContexts #-} | |
{-# LANGUAGE FlexibleInstances #-} | |
{-# LANGUAGE FunctionalDependencies #-} | |
{-# LANGUAGE GADTs #-} | |
{-# LANGUAGE KindSignatures #-} | |
{-# LANGUAGE ScopedTypeVariables #-} | |
{-# LANGUAGE TypeApplications #-} | |
{-# LANGUAGE TypeOperators #-} | |
{-# LANGUAGE UndecidableInstances #-} |
# Delete the possibly existing autocomplete test index | |
curl -X DELETE localhost:9200/autocomplete_test | |
# Put the config of the autocomplete index | |
curl -X PUT localhost:9200/autocomplete_test -d ' | |
{ | |
"settings" : { | |
"index" : { | |
"analysis" : { | |
"analyzer" : { |
// This file gives pseudocode for the complete operation of a Raft peer, | |
// including the fast backtracking optimization. The implementation here is | |
// currently 0-indexed, as this simplifies the implementation in many cases. | |
// This implementation also does not discuss locks at all, which will be vital | |
// in any real implementation. | |
// | |
// ============================================================================ | |
// The following data needs to be persisted | |
// ============================================================================ |
jQuery does good jobs when you're dealing with browser compatibility. But we're living in an age that fewer and fewer people use old-school browsers such as IE <= 7. With the growing of DOM APIs in modern browsers (including IE 8), most functions that jQuery provides are built-in natively.
When targeting only modern browsers, it is better to avoid using jQuery's backward-compatible features. Instead, use the native DOM API, which will make your web page run much faster than you might think (native C / C++ implementaion v.s. JavaScript).
If you're making a web page for iOS (e.g. UIWebView), you should use native DOM APIs because mobile Safari is not that old-school web browser; it supports lots of native DOM APIs.
If you're making a Chrome Extension, you should always use native APIs, not only because Chrome has almost the latest DOM APIs available, but this can also avoid performance issue and unnecessary memory occupation (each jQuery-driven extension needs a separate
// Configurable variables | |
// ⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻⁻ | |
// Absolute height of body text, in pixels | |
$base-font-size: 16px !default; | |
// Absolute height of one line of type, in pixels | |
$base-line-height: 24px !default; | |
// The font unit to use when returning values in rhythm functions |
(dominic: this list of papers was originally recommended to me by Brain Noguchi @bnoguchi, and was a great start to understanding distributed systems)
Here's a selection of papers that I think you would find helpful and interesting:
The seminal paper about event ordering and concurrency. The important result is that events in a distributed system define a partially ordered set. The connection to what we're working on is fundamental, as this defines how to detect concurrent updates. Moreover, the chosen algorithm to turn the partially ordered set into a totally ordered set defines the conflict resolution algorithm.
http://research.microsoft.com/en-us/um/people/lamport/pubs/time-clocks.pdf