This gist shows how to create a GIF screencast using only free OS X tools: QuickTime, ffmpeg, and gifsicle.
To capture the video (filesize: 19MB), using the free "QuickTime Player" application:
2015-01-29 Unofficial Relay FAQ
Compilation of questions and answers about Relay from React.js Conf.
Disclaimer: I work on Relay at Facebook. Relay is a complex system on which we're iterating aggressively. I'll do my best here to provide accurate, useful answers, but the details are subject to change. I may also be wrong. Feedback and additional questions are welcome.
Relay is a new framework from Facebook that provides data-fetching functionality for React applications. It was announced at React.js Conf (January 2015).
The idea is to have nginx installed and node installed. I will extend this gist to include how to install those as well, but at the moment, the following assumes you have nginx 0.7.62 and node 0.2.3 installed on a Linux distro (I used Ubuntu).
In a nutshell,
So for example, www.foo.com request comes and your css, js, and images get served thru nginx while everything else (the request for say index.html or "/") gets served through node.
Testing React components seems simple at first. Then you need to test something that isn't a pure interaction and things seem to break down. These 4 patterns should help you write readable, flexible tests for the type of component you are testing.
I recommend doing all setup in the most functional way possible. If you can avoid it, don't set variables in a
beforeEach
. This will help ensure tests are isolated and make things a bit easier to reason about. I use a pattern
that gives great defaults for each test example but allows every example to override props
when needed:
//usr/bin/env go run $0 "$@"; exit | |
package main | |
import ( | |
"fmt" | |
"os" | |
) | |
func main() { | |
fmt.Println("Hello world!") |
// ==UserScript== | |
// @name fails-first | |
// @namespace https://asottile.dev | |
// @version 0.1 | |
// @description put failed statuses first | |
// @author asottile | |
// @match https://github.com/* | |
// @icon https://www.google.com/s2/favicons?sz=64&domain=github.com | |
// @grant none | |
// ==/UserScript== |
// ==UserScript== | |
// @name fsso | |
// @namespace https://asottile.dev | |
// @version 0.1 | |
// @description click a da button | |
// @author asottile | |
// @match https://github.com/* | |
// @icon https://www.google.com/s2/favicons?sz=64&domain=github.com | |
// @grant none | |
// ==/UserScript== |
#Error management in gulp
Sucking at something is the first step to becoming sorta good at something
No one can assure you, that plugins will run smooth in any circumstances (except for tests - they could), so neither should you convince anyone, that your plugin will never break. Only thing, that you could possibly do (if something gone wrong) - is gracefully inform your plugin user, that something went wrong and die.
We are will use this plugin from beginning to demonstrate error management. Suppose you have a task in gulpfile.js
that contains this code (we modified it a little bit to be closer to real-usage):
var coffee = require('gulp-coffee');
#!bin/bash | |
# Arguments: $1 --> Ledger source file | |
# $2 --> Year Period, eg '2013' | |
# | |
# Example: bash ledger_close_year.sh mybooks.ledger 2013 | |
# Equity report from ledger | |
ledger -f $1 equity ^Income ^Expenses -p $2 > pl.tmp |