Skip to content

Instantly share code, notes, and snippets.

@paulmillr
paulmillr / active.md
Last active November 8, 2024 13:04
Most active GitHub users (by contributions). http://twitter.com/paulmillr

Most active GitHub users (git.io/top)

The list would not be updated for now. Don't write comments.

The count of contributions (summary of Pull Requests, opened issues and commits) to public repos at GitHub.com from Wed, 21 Sep 2022 till Thu, 21 Sep 2023.

Because of GitHub search limitations, only 1000 first users according to amount of followers are included. If you are not in the list you don't have enough followers. See raw data and source code. Algorithm in pseudocode:

githubUsers
@datagrok
datagrok / git-branch-simplify.md
Last active April 16, 2024 17:26
How to simplify the graph produced by git log --graph

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.

@datagrok
datagrok / git-serve.md
Last active April 21, 2023 07:33
How to easily launch a temporary one-off git server from any local repository, to enable a peer-to-peer git workflow.

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.

@lygaret
lygaret / index.js
Last active January 18, 2023 17:26
ES6 Quasi-Literal for JSX
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.
@evancz
evancz / Focus.md
Last active March 3, 2017 14:58
Potential outline of a simple and useful lens library for Elm

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
@evancz
evancz / Architecture.md
Last active December 21, 2022 14:28
Ideas and guidelines for architecting larger applications in Elm to be modular and extensible

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
// If the ES6 Promise is available, it uses that, else:
Rx.config.Promise = RSVP.Promise;
// To promise with success
Rx.Observable
.just(42)
.toPromise(/* Optional Promise ctor like RSVP.Promise */)
.then(
result => console.log('Result', result),
reason => console.log('Reason', reason));
function NOOP() {}
var button = getSomeButtonSomehow();
// all of these Animation objects are immutable, and just describe the motion
var moveRight = Animate.positionX({ from: 0, to: 100, ease: Easing.easeOut, duration: 200 });
var moveDown = Animate.positionY({ from: 0, to: 100, ease: Easing.easeOut, duration: 200 });
var fadeOut = Animate.opacity({ to: 0, ease: Easing.cubicBezier(0,1,1,0), duration: 50 });
var move = moveRight.with(moveDown, 100); // start moveDown 100ms after moveRight starts
var reusableAnimation = move.then(fadeOut, -fadeOut.duration); // start fadeOut 50ms before move ends
anonymous
anonymous / dom$.js
Created May 8, 2015 14:47
import Cycle from 'cyclejs';
const { h, Rx } = Cycle;
// all html/svg element names <<
var elements = [
'a',
'abbr',
'address',
'area',