dethi

#!/bin/bash

# Launch inside a create-react-app project after building the production build.
# Require `jq`.

diff \
	<(find src -type f \( -name '*.js' -o -name '*.jsx' -o -name '*.css' \) | sort) \
	<(cat build/**/*.map | jq --raw-output '.sources | join("\n")' \
		| grep -v '\.\./' | grep -E '\.(js|jsx|css)$' \
		| sed "s#^#src/#" | sort | uniq) \

justinwoo

How to make a Cycle.js + Elm hybrid Etch-a-Sketch app

A couple of days ago, I wrote a Cycle.js app using Elm to render stuff to the page. This was pretty fun and got some attention, so I might as well write about it some.

Writing this thing

Overview

A Cycle.js application consists of three parts: your main function declaration, your drivers setup, and your application initialization with Cycle.run (which sets up the "Cycle" part of your application). We'll do the following in our app:

jamescmartinez

require 'net/http'
require 'json'
require 'uri'

@token = ''

def list_files
  ts_to = (Time.now - 30 * 24 * 60 * 60).to_i # 30 days ago
  params = {
    token: @token,

justinwoo

Reposted from Qiita

For almost a year now, I've been using this "flux" architecture to organize my React applications and to work on other people's projects, and its popularity has grown quite a lot, to the point where it shows up on job listings for React and a lot of people get confused about what it is.

Why I'm tired of using and teaching flux

There are a billion explainations on the internet, so I'll skip explaining the parts. Instead, let's cut to the chase -- the main parts I hate about flux are the Dispatcher and the Store's own updating mechanism.

If you use a setup similar to the examples in facebook/flux, and you use flux.Dispatcher, you probably have this kind of flow:

jed

How to set up stress-free SSL on an OS X development machine

One of the best ways to reduce complexity (read: stress) in web development is to minimize the differences between your development and production environments. After being frustrated by attempts to unify the approach to SSL on my local machine and in production, I searched for a workflow that would make the protocol invisible to me between all environments.

Most workflows make the following compromises:

• Use HTTPS in production but HTTP locally. This is annoying because it makes the environments inconsistent, and the protocol choices leak up into the stack. For example, your web application needs to understand the underlying protocol when using the secure flag for cookies. If you don't get this right, your HTTP development server won't be able to read the cookies it writes, or worse, your HTTPS production server could pass sensitive cookies over an insecure connection.

• Use production SSL certificates locally. This is annoying