zdying

jbochi

katowulf

// assumes you add a timestamp field to each record (see Firebase.ServerValue.TIMESTAMP)
// pros: fast and done server-side (less bandwidth, faster response), simple
// cons: a few bytes on each record for the timestamp
var ref = new Firebase(...);
ref.orderByChild('timestamp').startAt(Date.now()).on('child_added', function(snapshot) {
  console.log('new record', snap.key());
});

pomber

jamesknelson

A 4-line shell script to convert your movies into gifs. Defaults to 10fps, 700px wide.

WIDTH=420 FPS=12 togif input.mov

You'll need to have ffmpeg installed -- on mac, you can do this with brew:

brew install ffmpeg

acdlite

Demo: Coordinating async React with non-React views

tl;dr I built a demo illustrating what it might look like to add async rendering to Facebook's commenting interface, while ensuring it appears on the screen simultaneous to the server-rendered story.

A key benefit of async rendering is that large updates don't block the main thread; instead, the work is spread out and performed during idle periods using cooperative scheduling.

But once you make something async, you introduce the possibility that things may appear on the screen at separate times. Especially when you're dealing with multiple UI frameworks, as is often the case at Facebook.

How do we solve this with React?

markerikson

Design Goals

reduxjs/redux#8 (comment)

The main goal of this library is to prove that Flux can be implemented in a way compatible with full hot reloading (and explore how this can be done). You can run the example code with npm start, change action creators or stores, and the new logic will kick in before you refresh.

cantbewong

Install DC/OS on bare metal

Assume 5 physical nodes, or VMs, that will be used with ScaleIO storage

• All nodes have 2 CPU cores, 64GB of disk storage. Hardware or VM type needs to support CentOS 7.3.
• The Install bootstrap node needs 4GB of memory, Other node types might get by with 2GB, though the spec calls for more (32GB on Master and Boot node, 16GB on others), and 2GB is cutting it close on the Master node for sure.
• Assume a single NIC each, All on a common subnet - though other configurations may work
• Each node must have a hostname in DNS, with forward and reverse lookup working, DHCP is OK

jpf

After many years of writing and thinking about developer documentation, I'm convinced that the discipline is still in its infancy. The goal of this document is to summarize my current opinions on the topic of documenting software.

When you ask a software developer what their favorite documentation is, you'll get a wide range of opinions with consensus centering roughly around the Stripe and Twilio documentation, as well as the documentation for open source software like Django, Perl, Flask, etc.

In academia, the uncontested master craftsman of developer documentation is Donald Knuth, who pioneered "Literate Programming"

At the frontier of developer documentation, we find projects like Eve and other projects inspired by Bret Victor's seminal "Inventing on Principle" video.

However, as folks at Dynamicland will often point out, the medium (in the McLuhan sense of the word) of software hasn't changed much since the days when code was written on teletypes: We still write software on fancy typewriters. The

RLesur

ttf

curl 'https://fonts.googleapis.com/css?family=Karla'

woff2

curl 'https://fonts.googleapis.com/css?family=Karla' -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8' -H 'User-Agent: AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116'

woff