if(document.queryCommandSupported('copy')) {
if(text=='') { text = ' '; } // empty inputs do not get selected
// copy text to off-screen input
$('#clipboard').val(text);
// 1.) does copy empty inputs, but adds newline before content
var range = document.createRange();
range.selectNode(document.querySelector('#clipboard'));
#/bin/sh | |
cd ~/.vim/bundle | |
for i in `ls -p`; do | |
cd "$i" | |
echo "Updating $i..." | |
git pull --recurse-submodules | grep -v 'Already up-to-date' | sed 's/^/ /' | |
[ -f .git/.gitmodules ] && git submodule update | sed 's/^/ /' | |
cd .. | |
done |
\documentclass{standalone} | |
\usepackage{tikz-cd} | |
\usepackage{amsmath} | |
\usepackage{tgpagella} | |
\begin{document} | |
\begin{tikzcd} | |
& & \lambda\omega \arrow[rrr] & & & \lambda\Pi\omega \\ | |
& & & & & \\ | |
\lambda 2 \arrow[rruu] \arrow[rrr] & & & \lambda\Pi 2 \arrow[rruu] & & \\ |
<head> | |
<title>My First React Experience</title> | |
<script src="https://unpkg.com/[email protected]/umd/react.development.js"></script> | |
<script src="https://unpkg.com/[email protected]/umd/react-dom.development.js"></script> | |
</head> | |
<body> | |
<div id="app"></div> | |
<script> | |
//Will add code here to try React | |
</script> |
<?xml version="1.0"?> | |
<root> | |
<appdef> | |
<appname>Terminal</appname> | |
<equal>com.apple.Terminal</equal> | |
</appdef> | |
<item> | |
<name>TMUX Key Remappings</name> | |
<item> | |
<name>TMUX: Right Control to Ctrl+B</name> |
import fetch from 'node-fetch'; | |
import { observable, action, runInAction } from 'mobx'; | |
export default class GithubStore { | |
@observable searchName; | |
@observable user; | |
@observable repos; | |
@observable fetchingData; | |
constructor() { |
Concurrency is a domain I have wanted to explore for a long time because the locks and the race conditions have always intimidated me. I recall somebody suggesting concurrency patterns in golang because they said "you share the data and not the variables".
Amused by that, I searched for "concurrency in golang" and bumped into this awesome slide by Rob Pike: https://talks.golang.org/2012/waza.slide#1 which does a great job of explaining channels, concurrency patterns and a mini-architecture of load-balancer (also explains the above one-liner).
Let's dig in:
tl;dr I built a demo illustrating what it might look like to add async rendering to Facebook's commenting interface, while ensuring it appears on the screen simultaneous to the server-rendered story.
A key benefit of async rendering is that large updates don't block the main thread; instead, the work is spread out and performed during idle periods using cooperative scheduling.
But once you make something async, you introduce the possibility that things may appear on the screen at separate times. Especially when you're dealing with multiple UI frameworks, as is often the case at Facebook.
How do we solve this with React?
var items = Array.prototype.slice.call( | |
document.querySelectorAll('*') | |
).map(function(element) { | |
var listeners = getEventListeners(element); | |
return { | |
element: element, | |
listeners: Object.keys(listeners).map(function(k) { | |
return { event: k, listeners: listeners[k] }; | |
}) | |
}; |