evancz

Focus

A Focus is a way to work with particular parts of a large chunk of data. On the most basic level, it lets you get and set fields of a record in a simple and composable way. This means you could avoid writing special record update syntax and use something that composes much more elegantly.

This API is inspired by the concept of Bidirectional Lenses as described by Nate Foster and seen in a modified form in Haskell as "lenses" and in ClojureScript as "cursors". My personal opinions and understanding comes from this talk by Simon Peyton Jones, discussions with @seliopou, and a basic understanding of Nate Foster's PhD thesis on bidirectional lenses. I chose the name "Focus" for this outline because it is sort of like a lens that only lets you see in one direction.

Here's the pseudocode that describes the basic API:

modul

oelmekki

Rethinking issue management

The core problem

FOSS developers suffer burnouts that cause them to loose interest in their projects, and cause the projects to die.

Wondering about why this happens, we came to the conclusion that maintaining a project, especially on the issue tracker part, is felt as a burden and a really annoying thing. Most of FOSS development today is made around Github, which

teropa

In my proposed lightning talk for the Reactive Conference, I'll create Conway's Game of Life in ClojureScript, and I'll do it in five minutes. I'll use an interactive programming workflow enabled by Figwheel. Each piece will be added into the running application without reloading the page.

If you want to see a little cellular lifeform spawn out of nothing into an running web browser window, I'd appreciate it if you starred this Gist!

Cheers,

(@teropa)

jevakallio

TL;DR: If you want to see me perform a spoken word poem about JavaScript in front of 1000 people (and on video), please ⭐ star this gist. If you're on mobile, you'll need to request desktop site.

JavaScript Slam Poetry

evancz

Architecture in Elm

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:

1. There is a single source of truth. Traditional approaches force you to write a decent amount of custom and error prone code to synchronize state between many different stateful components. (The state of this widget needs to be synced with the application state, which needs to be synced with some other widget, etc.) By placing all of your state in one location, you eliminate an entire class of bugs in which two components get into inconsistent states. We also think yo

lygaret

define(function(require) {
    var React = require('react');

    var paramRegex  = /__(\d)+/;
    var parser      = new DOMParser();
    var errorDoc    = parser.parseFromString('INVALID', 'text/xml');
    var errorNs     = errorDoc.getElementsByTagName("parsererror")[0].namespaceURI;

    // turns the array of string parts into a DOM
    // throws if the result is an invalid XML document.

datagrok

This article is now published on my website: A one-off git repo server.

Raynos

Virtual DOM and diffing algorithm

There was a [great article][1] about how react implements it's virtual DOM. There are some really interesting ideas in there but they are deeply buried in the implementation of the React framework.

However, it's possible to implement just the virtual DOM and diff algorithm on it's own as a set of independent modules.

datagrok

Ideas for improvements to git log --graph

I will maybe someday get around to dusting off my C and making these changes myself unless someone else does it first.

Make the graph for --topo-order less wiggly

Imagine a long-running development branch periodically merges from master. The git log --graph --all --topo-order is not as simple as it could be, as of git version 1.7.10.4.

It doesn't seem like a big deal in this example, but when you're trying to follow the history trails in ASCII and you've got several different branches displayed at once, it gets difficult quickly.

arj03

const tribes = require("ssb-tribes")
const Bot = require("scuttle-testbot")

const Stack = Bot.use(require("ssb-backlinks")).use(tribes)
const bot = Stack()

const Stack2 = Bot.use(require("ssb-backlinks")).use(tribes)
const bot2 = Stack2()

bot.tribes.create({}, (err, data) => {