rmehner

#!/usr/bin/env bash

set -e

info() { echo "$0: $1"; }
skip() { info "${1}. Skipping build."; exit 0; }

[[ "$TRAVIS_PULL_REQUEST" == "false" ]] || {
  skip "This build was triggered by a pull request"
}

favila

(ns favila.read-edn.tag-readers
  "Common tag-reader maps for edn."
  (:require datomic.db
            datomic.function
            datomic.codec)
  (:import java.net.URI))

(defmethod print-method URI [^URI x ^Writer w]
  (doto w
    (.write "#uri ")

spion

global.__$scope = new WeakMap();
function __$withScope(f, s) {
  global.__$scope.set(f, s);
  return f;
}

bkase

Production-Ready(?) Native Single-Atom-State Purely Functional Reactive Composable UI Components, or PRNSAASPFRUICC

The native UI toolkits on Android and iOS are frustratingly imperative. Unfortunately, there has been little architecture evolution (unlike the web). However, nothing(ish) is stopping us from bolting something "nice" on top. By nice I mean single-atom-state purely functional reactive composable UI components. In this post, I'll explain what this title means, the inspiration behind the design of the framework, an example component, and dive a little into the framework's implementation.

Right now, there only exists a Kotlin (Android) implementation, but a Swift port will be relatively straightforward and will happen soon.

Let's break down the title:

• "Production-Ready"

favila

(require '[datomic.api :as d])

(defn entity-changes
  "Return transaction history for an entity and its components.
  Returns a sequence of maps, each is the transaction map (tx metadata) plus a
  key `:entity-changes`, which is a nested map of keys: entity id, attribute
  ident, `:db/add` or `:db/retract`, and the value added or retracted, e.g.:
      {12345678910 {:long-card-1-attr          {:db/retract 1
                                                :db/add     0}
                    :long-card-many-attr       {:db/add     #{0}}

scottlet

[
	{
		"name": "atom-beautify",
		"version": "0.28.21"
	},
	{
		"name": "atom-handlebars",
		"version": "1.3.0"
	},

lawnsea

I have been watching the current discussions about running a virtual DOM in a web worker with a great deal of interest. In 2011, I built a research project, [Treehouse][] ([USENIX Talk][] ([DOMTRIS][] demo at 20:25), [paper][]), which ran a hacked-up version of jsdom in a worker. My goal was fine-grained containment of untrusted scripts, while still providing access to browser APIs that existing code expected.

Treehouse achieved a small amount of influence in academic circles, but it had problems and was ultimately unsuccessful. Virtual DOMs were not a widespread or well-understood idea at the time, so the advantages of running one in a worker

mattdesl

agnostic modules

Most of the modules I write are "agnostic" in that they should work in Node, browserify, webpack, Rollup, jspm... hell, even Unreal.js. It's just ES5, CommonJS and a few quirks like process.nextTick or require('path') (which browserify and webpack will shim).

Other modules are a bit trickier, and need to include a static asset like HTML, GLSL or another file.

In Node you might see this:

var fs = require('fs')

mbrzusto

__author__ = 'mbrzustowicz'

# metadata.json has single quotes like this
# {'asin': 'B00M0AEPXG', 'imUrl': 'http://ecx.images-amazon.com/images/I/51hcXTUeHLL._BO2,204,203,200_ ..... }
# so the strategy is to read each line as a string, and dump into a REAL json file

import json
import ast

fr=open("/Users/mbrzustowicz/Downloads/metadata.json")

jamiebuilds

export lint from './task-lint';
export test from './task-test';
export build from './task-build';
export dev from './task-dev';

export default dev;