$ sudo apt-get update
Here is a high level overview for what you need to do to get most of an Android environment setup and maintained.
Prerequisites (for Homebrew at a minimum, lots of other tools need these too):
- XCode is installed (via the App Store)
- XCode command line tools are installed (xcode-select --installwill prompt up a dialog)
- Java
Install Homebrew:
ruby -e "$(curl -fsSL https://raw.github.com/Homebrew/homebrew/go/install)"
So one of the painful points of using docker on OS X is that you need to run a virtualbox VM, which often suffers from performance issues. With xhyve, a OS X virtualization system, and docker-machine-xhyve you can now have docker use the native OS X hypervisor to run containers.
No more dealing with virtualbox shenanigans!
In this script, I've also set up a way to autoconfigure terminal sessions to load docker's environment vars (dependent on docker-machine) so you do not have to run eval $(docker-machine env whatever) every time you open a new terminal window.
Prerequisite: latest Docker for Mac on MacOS Sierra
$ brew update
$ brew install --HEAD xhyve
$ brew install docker-machine-driver-xhyve
$ sudo chown root:wheel $(brew --prefix)/opt/docker-machine-driver-xhyve/bin/docker-machine-driver-xhyve
$ sudo chmod u+s $(brew --prefix)/opt/docker-machine-driver-xhyve/bin/docker-machine-driver-xhyve
$ curl -Lo minikube https://storage.googleapis.com/minikube/releases/v0.18.0/minikube-darwin-amd64 && chmod +x minikube && sudo mv minikube /usr/local/bin/make net=host container inside network have access to rancher internal dns 
cp /etc/resolv.conf ~/resolv.tmp
sed -i.bak '1 i\nameserver 169.254.169.250' ~/resolv.tmp
cp -f ~/resolv.tmp /etc/resolv.conf 
| $(function() { | |
| // good opportunity to combine into a single statement | |
| // qq w cw <esc> A, <esc> 0 j q | |
| var a = 10; | |
| var b = 20; | |
| var c = 30; | |
| var d = 40; | |
| var e = 50; | |
| // opportunity to simplify syntax | 
Server Price Breakdown: DigitalOcean, Amazon AWS LightSail, Vultr, Linode, OVH, Hetzner, Scaleway/Online.net:
Permalink: git.io/vps
| Provider | Type | RAM | Cores | Storage | Transfer | Network | Price | 
|---|
| /* | |
| WallabyJS React Native Config | |
| Works well with Jest + Enzyme | |
| */ | |
| /* eslint-disable */ | |
| module.exports = function (wallaby) { | |
| return { | |
| files: [ | |
| 'src/**/*.js', | 
以下の内容は M63 時点の情報です。
WebRTC ライブラリのソースコードはサイズが 6GB 以上あってダウンロード時間でペヤングが 100 個は食べられるほどで、ビルドするにも Mac Pro の 12 コアをフル回転させて 1 つのアーキテクチャにつき最低 15 分はかかります。その上ビルドは相当に複雑な構成をしており、全地球のプログラマの寿命を戦闘機のカタパルトで助走をつけて殴っていいレベルで削らせるブラックなボックスです。あまりに自力ビルドの難易度が高いので WebRTC Build Scripts というビルドスクリプトも登場しましたが、最近ビルド方法が大きく変更されたために残念ながらこのビルドツールの内容は古くなってしまいました。
幸い iOS では公式ビルドのバイナリをダウンロードできるようになりました。 ところが「これで iOS はすべて解決!」とも言えません。 WebRTC のビルドには様々なオプションが用意されており、公式ビルドはあくまで特定のオプションの組み合わせの一つです。残念なことに用途によっては公式ビルドでカバーできない場合もあり、気軽に依存できない状況もあると思います。 時雨堂の WebRTC SFU Sora とかそうです (宣伝)。
この記事の目的は、ビルドの各手順の意味を把握してもらうことです(理解とは言ってない)。おそらく自力ビルドせざるを得ない人はほとんどいないと思いますが、万が一の場合に参考になれば幸いです。
| #!/bin/bash -euo pipefail | |
| if [ ${#} -eq 0 ] | |
| then | |
| # read from STDIN | |
| MAYBE_GIT_HASH=$( cat ) | |
| else | |
| MAYBE_GIT_HASH="${1}" | |
| fi |