dnagir

# RSpec 2.0 syntax Cheet Sheet by http://ApproachE.com

# defining spec within a module will automatically pick Player::MovieList as a 'subject' (see below)
module Player
	describe MovieList, "with optional description" do
		  
	  it "is pending example, so that you can write ones quickly"
	  
	  it "is already working example that we want to suspend from failing temporarily" do
		pending("working on another feature that temporarily breaks this one")

ry5n

// 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

yorkxin

Avoid jQuery When Possible

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

justinvw

# 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" : {

sevennineteen

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(

dypsilon

Frontend Development

Attention: the list was moved to

https://github.com/dypsilon/frontend-dev-bookmarks

This page is not maintained anymore, please update your bookmarks.

---

jbenet

a simple git branching model (written in 2013)

This is a very simple git workflow. It (and variants) is in use by many people. I settled on it after using it very effectively at Athena. GitHub does something similar; Zach Holman mentioned it in this talk.

Update: Woah, thanks for all the attention. Didn't expect this simple rant to get popular.

staltz

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.

---

dominictarr

(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:

Time, Clocks, and the Ordering of Events in a Distributed System

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

ohanhi

Learning FP the hard way: Experiences on the Elm language

by Ossi Hanhinen, @ohanhi

with the support of Futurice 💚.

Licensed under CC BY 4.0.

Editorial note