mbostock

license: gpl-3.0
redirect: https://observablehq.com/@d3/d3-color-schemes

Chouser

(ns n01se.externs-for-cljs
  (:require [clojure.java.io :as io]
            [cljs.compiler :as comp]
            [cljs.analyzer :as ana]))

(defn read-file [file]
  (let [eof (Object.)]
    (with-open [stream (clojure.lang.LineNumberingPushbackReader. (io/reader file))]
      (vec (take-while #(not= % eof)
                       (repeatedly #(read stream false eof)))))))

betawaffle

defmodule BitString.Example do
  import BitString

  defbitstring data_frame do
    _         :: 1
    stream_id :: 31
    flags     :: 8
    length    :: 24
    _         :: 1
    _         :: 7

aturley

Recently I've been trying to modify the way that I use the word "just" when I'm at work. Merriam Webster offers a few definitions of the word; the one I'm interested in is the one that means "only", "simply", and to a lesser extent "exactly". I've been working on a new project that involves integrating a number of systems, and as I began rolling pieces out I received a lot a questions in the form of "Couldn't you just ...?" These annoyed me at first, but as I thought about it I realized I often asked questions in the same way, so I began to examine the word and the way I use it.

munificent

You appear to be advocating a new:

[ ] cloud-hosted [ ] locally installable [ ] web-based [ ] browser-based [ ] language-agnostic
[ ] language-specific IDE. Your IDE will not succeed. Here is why it will not succeed.

You appear to believe that:
[ ] Syntax highlighting is what makes programming difficult
[ ] Garbage collection is free
[ ] Computers have infinite memory
[ ] Nobody really needs:

swannodette

(ns om-data.core
  (:require [om.core :as om :include-macros true]
            [om.dom :as dom :include-macros true]
            [datascript :as d]))
 
(enable-console-print!)
 
(def schema {})
(def conn (d/create-conn schema))
 

allgress

(ns reagent-test.core
  (:require [reagent.core :as reagent :refer [atom]]
            [datascript :as d]
            [cljs-uuid-utils :as uuid]))

(enable-console-print!)

(defn bind
  ([conn q]
   (bind conn q (atom nil)))

nasser

function namedArgs(fn) {
  var names = fn.toString().match(/function.*\(([^\)]+)\)/)[1].split(',');
  return eval("(function(args) {\
    return fn(" + names.map(function(n) { return "args[\"" + n.trim() + "\"]"}).join() + ");\
  })");
}

rygorous

This just got linked to by the Y combinator news account, without proper context,
so a brief introduction: A month ago (end of May / early June 2014) I had a
Twitter conversation with a bunch of acquaintances. One tweet in the middle
of that thread, with obligatory hyperbole, was me saying that I think VR is
bad news.

Well, that part of the thread (but not the rest that provides context) recently
got retweeted, and then someone asked me if I could explain what I mean by that,
and because Twitter is a great platform for delivering 140 character slogans and
not so great for lengthy explanations, I wrote this. So, obligatory disclaimer:

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