CYBAI

import React from 'react';
import ReactDOM from 'react-dom';
import isVisible from './isVisible';

class LazyLoad extends React.Components {
  constructor() {
    super();
    this.props = {
      distance: 100
    };

CYBAI

Multiple MySQL Versions with Homebrew

For homebrew version 0.9.5.

brew -v # => Homebrew 0.9.5

Install the current version of mysql.

# Install current mysql version

brew install mysql

CYBAI

set itermRunning to (application "iTerm" is running)
set scriptPath to quoted form of POSIX path of ((path to me as text) & "::" & "start.sh")
set user_shell to do shell script "dscl /Search -read /Users/$USER UserShell | awk '{print $2}'"

tell application "iTerm"
    activate
    if not (exists window 1) or (itermRunning = false) then
        reopen
    end if

CYBAI

tmux shortcuts & cheatsheet

start new:

tmux

start new with session name:

tmux new -s myname

CYBAI

Looking into the Future

futures-rs is the library which will hopefully become a shared foundation for everything async in Rust. However it's already become renowned for having a steep learning curve, even for experienced Rustaceans.

I think one of the best ways to get comfortable with using a library is to look at how it works internally: often API design can seem bizarre or impenetrable and it's only when you put yourself in the shoes of the library author that you can really understand why it was designed that way.

In this post I'll try to put down on "paper" my understanding of how futures work and I'll aim to do it in a visual way. I'm going to assume you're already somewhat familiar with Rust and why futures are a useful tool to have at one's disposal.

For most of this post I'll be talking about how things work today (as of September 2017). At the end I'll touch on what's being proposed next and also make a case for some of the changes I'd like to see.

If you're interested in learning more ab

CYBAI

ESM modules in node: npm edition

JavaScript in browsers has a new module system: ES modules. JavaScript in node.js has had a module system for years: CommonJS modules. JavaScript developers have nearly universally adopted node as the platform of choice for their tooling. Web application frameworks all use command-line tools written in node, pulling shared code from the npm registry, to build applications that run on the browser. Open-source code they find on npm is freely used in these applications. Browser app developers now have the following expectations:

• Code they write for their tooling uses the same language as their browser applications.
• Code they discover in npm's module registry is re-usable in the browser.

CommonJS modules do not work in the browser, but bundling tools like browserify and webpack have allowed CommonJS modules to be built into browser-ready code. Early implementations of ES modules rely on the CommonJS module system under the hood, as Babel transpiles ESM syntax into Common

CYBAI

本文譯自 [Tokio internals: Understanding Rust's asynchronous I/O framework from the bottom up][tokio-internals]。
Thanks [David Simmons][david-simmons] for this awesome article!

[Tokio][tokio] 是 Rust 的開發框架，用於開發非同步 I/O 程式（asynchronous I/O，一種事件驅動的作法，可實現比傳統同步 I/O 更好的延伸性、效能與資源利用）。可惜的是，Tokio 過於精密的抽象設計，招致難以學習的惡名。即使我讀完教程後，依然不認為自己充分內化這些抽象層，以便推斷實際發生的事情。

從前的非同步 I/O 相關開發經驗甚至阻礙我學習 Tokio。我習慣使用作業系統提供的 selection 工具（例如 Linux epoll）當作起點，再轉移至 dispatch、state machine 等等。倘若直接從 Tokio 抽象層出發，卻沒有清楚了解 epoll_wait() 在何處及如何發生，我會覺得難以連結每個概念。Tokio 與 future-driven 的方法就好像一個黑盒子。

CYBAI

Tutorial: Designing a GraphQL API

This tutorial was created by Shopify for internal purposes. We've created a public version of it since we think it's useful to anyone creating a GraphQL API.

It's based on lessons learned from creating and evolving production schemas at Shopify over almost 3 years. The tutorial has evolved and will continue to change in the future so nothing is set in stone.

CYBAI

#!/bin/bash
set -e

# Building LLVM on OSX CMake setup script
#
# Required:
#   - clang by Xcode6 or later
#   - cmake
#   - ninja
#

CYBAI

var USELESS_PROPERTIES = [];

function processContainer(container) {
  if (container instanceof CSSSupportsRule)
    if (!CSS.supports(container.conditionText))
      return false;
  if (container instanceof CSSMediaRule)
    if (!matchMedia(container.conditionText).matches)
      return false;
  if (container.media && container.media.mediaText)