読者です 読者をやめる 読者になる 読者になる

以下斜め読んだ内容

pseudo translation of useful posts, book reviews, remarks,etc. twitter: feeddict

エマニュエル・トッド「ドイツがヨーロッパ大陸を牛耳る」

UKの国民投票関連でオススメ。再読してる

抜き書き

  • 私はイギリスを「離脱途上」というように描写した。なぜならばイギリス人たちは、彼らにとってぞっとするものである大陸ヨーロッパのシステムに加入することはできない。

  • 彼らはある種のフランス人たちとは違い、ドイツ人に従う習慣を持っていないのだ。それだけでなく彼らは、ドイツ的ヨーロッパよりはるかにエキサイティングで、老齢化の程度もより低く、より権威主義的ではないもう一つの別の世界である「英語圏」、つまりアメリカやカナダや旧イギリス植民地の世界に属している。

  • 私はある折りに、彼らのジレンマに共感すると述べた。貿易上は格別に重要であるが、メンタル的にはどうしても和解できないタイプのヨーロッパを前にして、イギリス人であることはどれほど居心地の悪いものであるかを語ったのだ。

  • −−いつか彼らはEUから去ると思いますか?

  • もちろん!イギリス人はより強いわけでも、より優れているわけでもない。けれども、彼らは背後にアメリカ合衆国を持っている。

  • 早い話、自分のことを言わせてもらえば、自分の属するネイションの自立性の消滅に直面しちえる一フランス人として、もしドイツの覇権かアメリカの覇権か、どちらかを選べと言われたら、私は躊躇なくアメリカの覇権を選ぶよ。

以下斜め読んだ内容

あとでかく

「Uptown Funk弾いてみた」upしたらMark Ronsonとカバー作ることになった話

いい話


Mark Ronson Surprises Fans at Abbey Road Studios

  • いわゆる「celebrities surprise」系のyoutubeビデオ
  • Uptown Funkの「歌ってみた」「弾いてみた」動画がUPされてる
  • 「ドキュメンタリーに楽器弾けるファンとして出てくれない?」「アビーロードスタジオ招待するし自由に使っていいよ」と数組招待する
  • アビーロードスタジオ入りして、感動しながら楽器鳴らしてるところに、Mark Ronson登場
  • 一緒にカバー作りたいと提案して、本当にカバー作って、youtubeで公開

出来上がったカバー


Uptown Funk Cover -­ Produced by Mark Ronson

backstatge

Evan Czaplicki「脱FRP。またはThe Elm ArchitectureからSignalを消した件」

elm-lang.orgの2016.5.10のブログエントリ farewell-to-frp

ElmクリエータのEvanによる最新版0.17のアナウンス

  • 「Reactiveとか、非同期データストリームとかObservableとか、まあええけど、敷居上げすぎじゃね?」
    • 「じゃあSignal外して」「脱FRPしとくか」(今回)
  • 「WebAssembly来るかも?」
    • 「じゃあサクッと移行できるようにJSとのインフェース最小にしとくか」
    • 「いつでもどこでも脱AltJSできるように準備しとくか」
    • 「クロスコンパイルとかはいいわ」
  • OSS化しましたので皆様使って頂けたら。。。。」

というノリで、「使える言語」「使いやすい言語」ために手を打っていくところが面白い

以下斜め読んだ内容

  • The Elm Architectureのおさらい
    • webアプリ作るためのシンプルなパターン
    • Elmでコード書くときの標準的やりかた
    • 他言語に輸出された
      • reduxとか
      • JS界隈でも広まってきてる
    • 「成功した」と呼べるレベルに到達
  • Q:The Elm Architectureに沿って、websocketやGraphQLやgeolocationどう使う?
  • A:Subscription使え
    • コミュニティ内でこういう声は耳にしてきた
    • Subscriptionは自信作。いい感じににwebsocketつかえる
    • 今日(=2016.5.10)リリースするElm 0.17で追加した
  • Subscription入れると。。。

    • コンポーネントはメッセージを待受するだけに
    • ライブラリが裏で大量の手強いリソース管理をやってくれてる
    • Subscriptionでwebsocketが手軽に使える点は、エントリで後述する
  • Elmの学びやすさ・使いやすさの飛躍的な向上

    • Subscriptionなどが入った)Elm 0.17リリースの意味
  • 少し前までElmには、SignalAddressPortというのがありまして。。。
    • こいつらがElmの敷居を高くしていた。
    • Subscriptionを次のリリースでElmに入れてみようか、と考えてるときに気付いた
    • Signal(とかの難解なコンセプト)は無くてもいいじゃん
    • もっとシンプルなコンセプトに分解していけば、Signal引退できる
    • (補足)
  • 「Elmを使いこなす」ために理解しないといけないコンセプトの数
    • Signalが引退すれば、この数をぐっと減らせる
  • 「使いやすさ」のためにElmをデザインしてる
    • これは思いがけず開けた道筋。かなりうれしい展開。
  • 「皆さん注目!」的な言い方を敢えてしてみると。。。
    • Signalに関係してるもの全部引退
    • もっとシンプル、もっと優れたものに置き換え。
  • Signal引退をElm界隈でアナウンスしてみた
    • 2パターンの反応
    • 反応1:クレージー。コードは動くのか
    • 回答1:95%(俺調べ)のコードはそのままで動く
    • 反応2:お前は何言ってるんだ? FRPとかSignalとか何それ
    • 回答2:「知らん」でOK
      • 今回のリリース(0.17)に直結する話。
      • Elmには不要になった
  • あれこれ回答するよりも、新しいElmがどう動くかを見せた方がいい。
  • 閑話休題
    • subscription以外の0.17のおすすめ紹介
    • HTMLレンダリングを高速化(ベンチマークは後で出す)
    • web platformのテクノロジーを簡単に使えるライブラリを追加
      • geolocation
      • Page Visibility API
      • websockets
    • コンパイル最適化
      • outputのjsのサイズをダウン
      • outputされるjs
        • closure compilerに通せる
        • RequireJSサポート
        • CommonJSサポート
    • GraphQLやPhoenix(Elixir)のようなサービスと連携するための機能
    • ドキュメント改善:Gitbookベースに
    • JSONデコードエラー時のメッセージ出力の改善

subscription例その1。現在時刻の待受

  • コンポーネントがメッセージ待受をサポートできるようにするための方法
    • subscriptionが一つのやりかた
  • コンポーネントがsubscribeする対象
    • 現在時刻
    • 位置の変化
    • websocketメッセージ
    • etc..
  • SVGによるアナログ時計を使って説明する
    • SVG時計の基礎は、時間へのsubscribe
    • subscriptionの最もシンプルな例
    • とりあえずSVG時計のソースコードをざっと見てもらいたい
      • 典型的なElmコード
-- 0.17以前と違う箇所はこの3行だけ
subscriptions : Model -> Sub Msg
subscriptions model =
  Time.every second Tick       
  • 与えられたmodelに対して、アクティブなsubscritpionがこれだけで記述されてる
  • 関数Time.everyを使って、現在時刻へのsubscriptionを記述
  • 現在時刻は毎秒更新
  • 新しい時刻(ex Tick 1462487781991)はupdate関数に渡される
  • (補足)
    • subscriptionは、Sub msg型(Sub = Platform.Sub
    • 関数Time.everyの型定義は、Time.every : Time -> (Time -> msg) -> Sub msg
    • なので、Time.every second Tickは、Sub msg
    • あと、secondTime.secondは)Time
    • Ticktype Msg = Tick Timeという型定義から、(Time -> msg)
      • Tick 1462487781991Msg
    • Tickは冗長にかけば、(\time -> Tick time)、となる
    • つまり、Time.every second (\time -> Tick time)
  • subscription以外の部分はすべては0.17以前と同じまま
  • 何かを待受してるだけなので、一番簡単な例
  • 次は、もうちょっと複雑なシナリオで

例その2。websockets通信

  • シンプルなchatクライアントdemo
    • 送信されたメッセージを表示するだけの機能(荒れても困るので)
  • ソースコード
    • SVG時計と見比べると大変よく似てる
    • よく似たコードだけど、このコードだけでwebsocket通信を管理してる
-- ソースコードで注目すべきはこの2行だけ
-- こっちはメッセージを送信
WebSocket.send "ws://echo.websocket.org" input
-- こっちはメッセージをsubscribeしてる 
WebSocket.listen "ws://echo.websocket.org" NewMessage
  • 送信してるコード、subscribeしてるコードの共通してること
    • chatサーバのアドレスを渡してる点
    • 通信を助ける値を渡してる
  • WebSocket.listenでは渡されてるNewMessageMsg型のタグを返す関数
    • (補足)
      • Msg型の型定義は、 type Msg = Input String | Send | NewMessage String

        Union Types使って定義されてる

      • Input StringSendNewMessage Stringをタグと言う(らしい)
      • なのでUnion Typeと呼ばずに、Tagged Unionと言う人がいる
  • サーバーから「hi」というメッセージを受け取り、NewMessage "hi"、をupdate関数に渡す
  • (補足)
    • WebSocket.listenの型定義は、String -> (String -> msg) -> Sub msg
    • NewMessageは、String -> msg型の関数
    • NewMessage "hi"Msg
  • 自慢できること
    • あれこれ細かい制御のためのコードを書かなくてもチャット機能を提供できてること
    • sendしてlistenする。それだけ
  • チャット機能をjsでやろうとすると。。。
    • ひとつはブラウザAPIを直接触る
      • new WebSocket(...するところから
      • コネクション開く
      • onerrorリスナーつけ忘れない
      • 切断されたら再接続するように書く
        • いわゆるExponential Backoffの仕組みもいる
      • 切断されてたらメッセージ送らないようにしないといけない
        • ランタイムエラーになるから
      • キューイングシステムも実装必要
        • 切断時にpostされたメッセージを貯めとく
      • さらに
        • どのコンポーネントがwebsocket通信するかを考えて設計しないといけない
        • 接続の切断についても適切な時間でやれるようにしないといけない
    • JSライブラリを使う手もある
      • 調べると2,000以上はある。npm検索で
      • 最初の1、2個で当たりが出ることを祈りましょう
  • ElmのWebSocketパッケージを使うと。。。。
    • websocket通信のための細々とした管理は自動的に行われる
    • subscriptionが発生すれば自動接続
    • subscribeがゼロになれば自動切断
    • メッセージのキューイング、再接続はバックグラウンドで処理され、意識しないでいい

さらに学ぶためのリソース

  • 公式ガイド
    • http://guide.elm-lang.org/
    • Elmと The Elm Architectureがやろうとしてることを知りたい人
      • The Elm Architectureのセクションを一読してほしい
      • 順序立ててSuscriptionを使った実装をやるとこまで書いてる
    • 他にもいいサンプルある
  • Elm経験者にはアップグレードガイド用意してる
  • Slackチャンネル作った。活用してほしい
    • Elm初心者が質問する場所、何か学ぶ場所として
    • 0.16以前のアプリを0.17に移行させたい人の質問する場所として

さらばFRP

  • このraycasterみたいな、楽しくなるプロジェクト
  • シェアしたくなるプロジェクト
  • プログラミングすることに熱中させてくれるプロジェクト
  • Elmは、こういうプロジェクトを作っていける何か
  • Elmを作ってる自分が自問してきたこと
    • どうすればElmがもっとシンプルになるか
    • どうすればElmが学びやすくなるか
    • どうすればもっと楽しくなるか
    • どうすればもっと素早くプロトタイプを作れるようになるか
    • どうすればもっと信頼できる言語になるか
  • こういった自問し続けてることが、Elmの設計哲学の中心にあり、Elmの成功の根幹にある
  • 2011年頃に自分が卒論を書いてた頃の話
    • http://elm-lang.org/papers/concurrent-frp.pdf
    • たまたま"Functional Reactive Programming" (FRP)と呼ばれるニッチな学問領域に突入した
    • FRPの手法をシンプルな形に落とし込むことを考えていた
    • 結論として類似の関数型言語よりも学習しやすいものを作ることができた
    • Signalは難解なコンセプトが折り重なったもの
    • Elmには必要ではなかった
  • SignalはElmにある数少ない躓きポイント」
    • Elmを教えた経験のある人なら同意してくれるところ
  • SignalによってElmは使やすくなった」
    • 類似言語との比較でならそうとも言える
    • SignalはElmそのものを「やさしい」言語にはしなかった
  • The Elm Architecture導入後
    • Elmでのプログラミング体験の大部分で、Signalを考えないといけない時間を消し去った
    • start-appパッケージ
      • これは実験だった
      • Signalは「後から学べばよい」という位置付けに変えたらどう変化するか?
      • かなりよい結果がでた
        • 素早くElm入門できるようになった
        • すばやく上達し、Elmでのプログラミングを楽しんでくれた
        • Signalについて多くの事柄を学習してなくても、素晴らしいElmプログラマをたくさん生み出せた
        • Signalにまつわる事柄は必須ではなかった
        • 0.17 のリリースでこの流れを一歩先に進めただけ、とも言える
  • 結構前からSignalはElmから削除可能だった
    • 「Elmはconcurrency重視」に舵を切っていたから
    • cocurrency重視のアイディアの原型は自分の卒論に確認できる
    • 0.15でElmにTaskを導入してから、Elmの実装レベルでこの方向に進み出した
  • 0.15で導入されたスケジューラ
    • スケジューラはwork(?)の切り替えをサポートし、必要なときだけ実行させることができる
    • 0.17で大幅に改善された箇所
    • スケジューラはeffect managerの基盤
    • さらに、effect managerがSubscriptionの基盤
    • (補足)
      • Elmでは、Effect(作用)はデータとして表現され、Elmランタイムが実行し、実行時に最適化を行う
      • Effectの例:httpリクエスト、乱数取得、時刻取得、DB書込、etc..
      • データとして表現され、Elmランタイムが最適化しながら実行するEffectは、SubscriptionCommandの2種類
    • ドキュメントをもっと書き換えたいところ
    • スケジューラ、effect managerの内部のことを深く知る必要はElmのエキスパートになるのに必要でない
    • concurrencyの利点を即座に享受できることを目標にしてる
      • この点は私の卒論Concurrent FRPの頃から変わってない
  • ElmはFRP的ななにか?
    • かつてそうだったが、今はそうでない
  • Elmはconcurrencyに真剣に取り組む関数型言語であり、フレンドリーな関数型言語であるだけ

  • 閑話休題

    • この辺に興味持ってる人だとLucid Synchroneという言語も面白いと思うかも
    • 自分がElmで考えてることと、同期的プログラミング言語の間にはたくさん共通点がある
      • 自分が卒論書いてる当時は知らなかったこと
      • Elmと同期的プログラミングのつながりは自分にとって衝撃だった
      • ElmはFRPな何かであったことは一度もなかった、付け加えておく

Elmの今後

  • Elm 0.17開発初期の自分のヴィジョン
  • Elm 0.17はこのヴィジョンの基礎になるリリース
  • 次に取り組む問題
    • 1 webプラットフォームの全てをサポート
    • 2 GraphQL, Elixir Phoenix, Firebaseなどのバックエンドのサポート
    • CommmandsSubscriptionでは全てのケースはハンドリングできる
      • The Elm Architectureできちんと使えるパッケージを組み合わせて、一貫性をもたせることもできる
    • これからこのへんの開発がどうなっていくのかが楽しみ
  • 次の問題へどうアプローチするか
    • ちゃんとみれば、the web platformはそれほど巨大じゃない
      • 残ってるAPIをサポートしていく
    • 「jsにコンパイルされる」という部分は将来無くなるかも。WebAssemblyが来たら
    • Elmとjsのインターフェースは小さくしていく
      • そうすればjsから別のプラットフォームへの切り替えはスムーズに
    • ロスコンパイルは眼中にない
  • これから新たに作っていくライブラリ開発に参加したい方へ
    • そういう声をすでにもらってる
    • コントリビュートしたいという情熱が素晴らしいアウトプットを生む
      • 空回りなく、これが確実に起こるようにしておきたい
      • そのために、一貫性のある開発プロセスをまず自分が作る
      • それまで待っててほしい
    • 次期リリースのために現時点でできるコントリビュート
      • slackに参加して、elmコミュニティの動向を知ること
        • 何かコントリビュートするときは常に事前にやるべきことだが

thanks you

  • @JustusAdam
    • elm-reactorのnavigation画面の作り直し
    • 数年前に完了してた。ようやく公開できた
  • 0.17の設計に参加してくれた人たち
    • なんども繰り返して「これはあかんね」となったりもした
    • それでも付き合ってくれて、優れたアウトプットしてくれた
  • Elmコミュニティ

Gavin Andresen「MITでフルタイムでbitoinプロジェクト続行できるようになった件」

以下斜め読んだ内容

  • Digital Currency Initiativeに参加することにした

  • 自分がやってるbitcoin関連のプロジェクトはここで続ける

  • Wladimir van der LaanとCory Fieldsも一緒に参加
    • WladimirとCoryはBitcoinのコア開発者
    • 二人ともMITが開発継続にとって良い場所だと感じてる
  • MITがbitcoin開発の総本山になったってこと?
    • No
    • オープンソースだし、プロジェクトへの参加の仕方や立場は色々あるしできる
  • 開発者へのサポートが色んな所からある状況はいいこと
    • 例えばプロジェクトをサポートしてくれつどこか会社なり組織なりが潰れた、とする。
      • そうなっても、プロジェクト自体が即死亡することが回避できる
  • bitcoin財団の経営破綻が公になってから、色んな人が声をかけてくれた
    • 自分(Gary)、Wladimir、Coryが開発継続に必要な資金が得られなくなっていた
    • 声をかけてくれたみんなに感謝したい
    • Joi Ito(Meia Lab所長)と、Brian Forde(Digital Currency Initiative責任者)にも感謝したい
      • 二人が色々動いてくれた
      • bitcoinコミュニティーへのサポートするために凄い力注いでくれてる
      • 興味があれば、brianにコンタクトとるといいと思う

Daniel Stenberg「2015年春時点でのHTTP/2普及の現状と今後」

  • daniel.haxx.se 2015.3.31のブログエントリ
  • http/2が今どれくらい普及してるのか、年末にどうなる、サーバーとかプロキシーとかCDNとかのサポートはどんなんなのか、等々
    • 手際よくまとまってて勉強になる
  • エントリの締めの円グラフは「2015年末にhttp/2普及度合は?」アンケートをまとめたもの
    • 「fb/g+/twitterの中の人として働く人の実感ではこうだ」というのがわかって面白い

以下斜め読んだ内容

  • HTTP/2プロトコル
  • 2015年2月のデータだと全トラフィックの5%でhttp/2利用してる
    • 2015.2.15にエントリ書いてる
    • daniel.haxx.se » HTTP/2 is at 5%
      • (補足)ざっくり斜め読み
        • http/2をデフォルトで有効にしてるブラウザ
          • Firefox35(2015.1.13リリース)
          • Chrome40
        • 2015.1.28発表のgoogleのデータだと5%のトラフィックはhttp/2
        • mozillaのデータ
          • Firefox35ユーザから利用してるhttpプロトコルの情報を収集
            • 総数3400億のhttpレスポンス
            • そのうち9%がhttp/2でした
    • 実際にもっと多いんじゃ?
  • 俺予想
    • 2015年末には10%越え
      • 20-30%くらいいけるんじゃ
      • ビッグプレイヤーの一挙一動の影響がある程度あるが
      • facebookinstagramtumblryahoo!、などなど
    • 2016年には大半のhttpリクエストはhttp/2利用するはず
      • 最低でもブラウザではそうなるはず
  • 5%とか10%とか20%、等々の数字の出し方
    • httpリクエストの数についての比率
      • データ転送量ではない
      • ブラウザの数でもない
    • 2014年12月時点では5%とか20-30%とかの数字はどうだったのか?
      • 計測方法の是非について議論は可能
      • ただこの手の議論の行き着く先は決まってる
        • 曰く「めいめいが正しいと思う方法で計測すべし」
  • 「俺予想」とか言ってるお前は誰なの?
    • プロコトル、http/2にとても関心持っている人
    • httpワーキンググループも何年も参加してる
    • http/2実装のいくつかに参加してる
    • 所属とか勤務先とかの立ち位置をこのエントリに読み取ろうとするのはご自由に
      • ただあくまで個人ブログで書いてること
  • 現時点でhttp/2実装は36ある

ブラウザ

  • chrome,firfoxは前からサポートしてる
  • IEは未サポート
    • tech preview触った感じだとちゃんとhttp/2実装されてそう
    • 今後出るパブリックリリースで搭載では
  • safari
    • http/2サポートする気配ゼロ
  • 俺予想
    • 2015年末にはブラウザ全体で50%以上はhttp/2サポート

サーバ

  • apache httpd
    • mod_h2があるが進捗はアルファレベル
    • icing/mod_h2
    • 正座して待て or 開発助けよう(金でも人手でもok)
  • nginx

  • h2o

    • h2o/h2o
    • 新顔で。高速なことがウリ
    • ずいぶん前からhttp/2サポートしてる
  • nghttp2
    • Nghttp2: HTTP/2 C Library - nghttp2.org
    • リバースプロキシ提供
      • http/2からhttp/1.1にダウングレード
      • 運用中のhttp/1.1しか話さないサーバのフロントとかに置ける
    • サポートしてる機能は他にもいろいろ
  • apache traffic server
  • nettyとか、jettyとかもサポートしてる
  • 俺予想
    • 2015年末時点でhttp/2喋るサーバーのシェア80%越え

プロキシー

サービス

  • google(傘下のサービス。youtubeとか)、twitter
    • 数ヶ月前からhttp/2有効にしてる
  • spdyサポートしてるwebサービス多い
    • chromeが2016年にspdyサポートを切るとアナウンスしてる
    • この時期をめどにspdyからhttp/2に切り替えていく気ではないか(と想像)
  • 俺予想
    • 2015年末時点
      • 大規模サービスだとhttp/2サポートになってるか、準備中か、のどっちか

CDN

httpクライアント(ブラウザ以外)

  • curl、libcurl
    • 数ヶ月前からhttp/2サポート
  • プログラミング言語ごとに使えるhttp/2対応クライアント
  • 割とhttp/2に切り替えしやすい状況では

他には?

  • あるかも。思い出したら補足する

http/1.1の寿命

  • 俺予想
    • 今後何年も使われるし
    • インターネット全体でhttp/1.1だけサポートしてるサイトの数は二桁をキープし続けるはず
    • なんで全体が移行していかないかは色々ですね

まとめ

f:id:vwxyz:20150421105935p:plain

  • twittergooglefacebookにいる友達に聞いてみた
    • 2015年末時点でhttp/2の普及の度合
    • 答えやすいように、5%ごとに区切った選択肢作って選んでもらった
    • 50%まで5%刻み。それと50%以上
    • 回答集めて、円グラフにしていた
    • もちろん統計的な厳密さはないけど、参考程度に
    • 自分は15-20%くらいを選ぶ
    • 中央値とると10%くらいか

Kenton Varda「OSXのカーネルバグを使ってChromeとNode.jsを無限ループに嵌らせる」

sandstorm.ioの2015.4.8のブログエントリ

  • Sandstorm News: Remotely send Chrome and Node.js into infinite loops via this one weird OSX kernel bug
  • osx/iosの非同期i/oを捌くkqueueのバグを見つけた件について
  • 見つけた経緯、振舞いの詳細、バグを使ってできる攻撃、影響を受けるアプリ、書いた理由(アップリのdescriptionは素っ気なさすぎ)、学んだこと、各所パッチ出したからこのネタ解禁できる、等々
  • kqueueを使ってるos/software全てが影響受けるわけでないこと(Darwinのみ、nginxはセーフとか)もさらっと書かれてて勉強になる

以下斜め読んだ内容

  • 数ヶ月前に発見したDarwin kernelのバグ
  • セキュリティバグ
  • Dawrin kernel自体はほぼ全てのappleプロダクトで使われる
  • このバグを攻撃者が利用すると。。。
    • DoSアタックができる
    • ターゲットはnetwork serviceやアプリ
    • リモートから、しかも手軽にできる
  • このブログ書いてる日にappleからパッチがでた

  • 最初に断っておく

    • バグをみつけた自分(Kenton)
      • Adam Langley先生(ImperialVioletの人)レベルの人間じゃない
    • 見つけたバグ
      • HeartbleedとかShellshock級の深刻なバグとかではない
      • 攻撃者がこのバグを突いてできることはしれてる
        • 一時的なサービス利用停止くらい
  • 全てのセキュリティバグはそれぞれ全容を書かれるべき
    • というのが持論
    • それぞれのバグから自分らが学べるように
    • 今回のバグについてのappleの記述は素っ気ない代物
      • ここからは何かを学ぶのは無理
  • それとは別の今回のバグの話なネタとしていい線いってる

  • eventドリブンなI/Oを利用するためのインターフェース

    • OSによって特色がある
    • この辺りをリサーチしてるときに発見した
      • このインターフェースを例えるならこんな感じ
    • 「これとこれと・・・がいま自分が開いてるコネクションです。こいつらからメッセージが飛んできたら起こしてくれ。それまで寝る」
  • これに対するOSの反応はさまざまで、5タイプくらいある
    • LenuxはepollBSDkqueue、winは、・・・(略)
    • メカニズムが違うだけでなく、それぞれがカバーしてるユースケースの範囲も違う。
  • ユーザは特定のメカニズムを選ばないといけない
  • 自分ら開発してるCap’n Protoのために、このosごとの違いを抽象化する仕組みを作ろうとしてた
    • Cap’n Proto
    • これ作るために各osのインターフェースの特色をきちんと理解しようと色々やってた
  • man読み比べて気づいたこと

    • OOB(Out of Band)データの扱い
    • 別名緊急データ(urgent data)
    • このデータのハンドリングについて記述は有るものもないものある、という感じ
    • tcp接続では頻度小ながら使われる機能
      • tcp接続ではデータはキューに入って順番に送られる
      • この順番待ちをスキップして送ることのできるデータ
    • OOBのことは知らなくて当然
      • telnet使うとき以外だと、はユーザは利用する機会のない機能
      • 接続先のアプリが入力を処理してないときに"ctrl+C"押すみたいなことを通知する方法が必要だから
  • ほぼ全てのevent通知APIでは、通常データとOOBデータは違うイベントを発火する

    • poll()と後継のepollの場合
      • 通常データはPOLLINイベント
      • OOBデータはPOLLPRIイベント
  • アプリがOOBデータ受信を想定していない場合

    • アプリはOOBデータのイベント通知について問い合わせをしない
    • kernelはOOBデータのイベントをスルーするか、通常データストリームに含めるかのいずれか
  • 各os別のkqueue

    • BSD
      • OOBデータハンドリングについて曖昧
    • FreeBSD`
      • kqueue(2)
      • OOBデータハンドリングについて記載ゼロ
      • 調べた限りだと、OOBデータイベントがサポートされてない
    • DragonflyBSD
      • OOBデータイベントEVFILT_EXCEPTが定義されてる
    • DragonFly On-Line Manual Pages : kqueue(2)
    • Darwin(OSX/iOS)
      • ドキュメントにはOOBデータのことが書いてないが実装されてる機能あり
      • EVFILT_READイベント
        • 通常の(つまりin-band)データ受信で発火
        • どうやらOOBデータ受信した時もEVFILT_READイベントを発火してる
          • ただフラグ( EV_OOBAND)をつけてイベントを発火してる
      • 通常の流れ
        • 通常データ受信
        • recv()コールして受信データ読み込み
        • それでおしまい
        • 再びイベントループへ戻る
      • level-triggeredモードでkqueue使ってる場合
        • 簡単なのでたいていの人が使うモード
        • osは読み取りした後も、OOBデータが残る読み取り前データとして残る
          • ずっと受信してるかのように振る舞う
          • 同じイベントを繰り返して発火する
        • こうして無限ループに入り込む
  • 緊急データをtcpパケットで受けとっただけでほぼ全てのイベントドリブンなネットワークアプリが無限ループに嵌るという話?
    • んなアホな?と思ってた
    • 試してみた
    • ホンマやった
      • chrome、node、nginx調べた
    • chrome
    • node
    • nginx
      • セーフ。無限ループにならなかった
      • 新しいデータを受信したときだけ意図してないイベントを受け取るように動く
      • 何度も利用できるデータがあったとしてもイベントを何度も受け取らない
        • edge-triggeredモードでkqueueが使われてるおかげ
    • nginxは無事だったが、chorme, nodeでは無限ループを生んだ
      • chromeもnodeといった有名どころが影響受けてる
  • 今回のバグはAPI設計レベルの問題
    • kernelにバグがあるわけでない
    • インターフェースが混乱気味
      • さらにちゃんとドキュメントに載っていないせいでもある
      • インターフェースのまずさのせいで複数アプリで同じバグが再現する羽目に
  • このバグを直すやり方は二手にわかれる
    • このバグの影響の出るアプリ全てを直す
      • 今後出るだろうアプリも含めて
    • APIそのものを変えて、このAPIの挙動に依存したアプリは無視
      • つまりクラッシュさせる変更をする(数は相当少ないだろうが)
  • 自分からみて正しいと思うやり方でappleはこのバグに対応してる
    • appleはインターフェース修正した
      • TCPでOOBデータ受信したときにEVFILT_READが発火しないようにした
    • appleのこの件の記述が全くようわからん
      • なんでこの問題が"state inconsistency issue"と表現できるのか
    • パッチ適用後のmacで自分でもOOBデータ送信テストしたがバグは消えた
      • OOBデータはスルーされるようになった
  • このバグの教訓
    • 混乱気味のAPIはセキュリティ問題になる
    • もしあなたのAPIを利用する多くのユーザがセキュリティバグを生むようなやり方をしてるなら、それは彼らのコードにバグがあるのではなく、APIにバグがある

Daniel Cawrey「Bitcoinのコア開発者による定点観測と予測」

がわかって面白い

  • 追記2015.4.23
      -  Gavin AndresenのDigital Currency Initiative参加の件を追記
    

以下斜め読んだ内容

  • Peter Toddさん(30歳)

  • Toddと話す機会あったので色々聞いてみた

  • bitcoinの今後(長いスパンで)とか

時の権力者の脳内は「bitcoin=変わるべき』一択

  • bitcoin業界への政府の介入は不可避とtoddはみてる
  • 危惧というレベルではない
  • todd自身が役人と、bitcoinへの規制をめぐって議論してきたことから得た結論
  • todd曰く
    • 政府がbitcoinに実際に口を挟むことはどんどん起こる
    • プロトコルの仕様とか根幹の部分も標的になる
    • 役人とカンファレンスずっと話をしてる
  • 役人たちの 脳内はシンプル

bitcoinネタで資金調達はある意味大変

  • bitcoinで何か、的なスタートアップへの投資はどんどん増えてる
  • 投資家がcryptocurrency系スタートアップに期待してること
    • これが問題だとtoddは考えてる
    • アーリーステージなのに、すぐに収益を上げろと圧力
    • こういう圧力のある環境だと真っ当な資金調達が難しい
  • todd曰く
    • 早期にマネタイズできるビジネスモデルがないと資金調達できない
    • これはcryptocurrency業界の大きな問題
    • 最近のRipple Labの900万ドル調達がいい例
    • Ripple Labs | CrunchBase
    • rippleのXCPトークン
      - (補足)rippleの貨幣はxrpなので、typoでは?
      
    • 本来アーキテクチャにとって必要のない代物
    • これはセキュリティの点でもシステムの安定性の点でもひどい妥協
    • XCPトークン導入によって中央管理型のシステムに成り下がった

マイニングへの最大の脅威は政府

  • マイニングが分散型であることが重要だと考えてる人たちは多い
  • bitcoinマイナーの手足を封じたいと政府が考えれば、そのたの冴えたやり方を政府はきっと思いつく、とtoddはみてる
  • todd曰く
    • 政府はASICの製造自体を規制すればいい
    • ハードウェアに強制停止ボタンを埋め込んでメーカーが遠隔で停止できるようにする、とか
    • マイナー(ASIC利用者)を許可制にする、とか
  • 政府にとってASICを作れるだけの技術力を持ったメーカーに圧力をかけるのは簡単
  • todd曰く
    • パフォーマンスとコスト双方で売り物になるレベルのASICを作れるメーカーは数えるほどしかない。
    • つまり、Intel、ASMC、GlobalFoundries

bitcoinのライバルは全然面白いのがない

  • 金融系テック企業は高収益なので、多くのスタートアップあり
  • todd曰く
    • ErisもHyperledgerもとても良いテクノロジー
    • ただ超ツマラン
    • 既存のものよりも優れた会計ソフトを作ってるだけ
    • 会計の整合性を確保するために暗号技術を使ってるだけ
    • Eris Industries
    • Hyperledger
  • こうしたbitcoinオルナティブのやってることがうまくいっても、bitcoinにとっては全然良い材料にならないのが問題
  • todd曰く
    • ? "The worry for Bitcoin is that when it does catch on you’ll have alternatives that for law abiding companies are at least every bit as good as Bitcoin; probably better."

bitcoinは魔法の送金手段ではない

  • bitcoinで送金はハードなビジネス
    • 多くのプロジェクトが突き進んでる
  • toddはbitcoin送金は人々が考えるほど手軽にはならない、と考えてる
  • todd曰く
    • 送金において、bitcoinは規制されてる既存の組織と競えるのか?
    • 消費者が既存組織に値下げするように仕向けれるなら、競える
    • uberが規制の穴をついて利益得てる話みたいなこと

bitcoin founcationは不祥事多すぎ

  • 2011年設立のbitcoin foundation
    • この団体の目的はcryptocurrencyの認知拡大
    • その必要自体はtoddも同意
    • 内部にたくさん問題抱えてる
    • bitcoinエコシステムで重要な役割果たせるような所までいけてない
  • todd曰く
    • 政治的な圧力団体してうまく行く可能性もっていた
    • 政権や制度に入り込んでいくのは重要
    • foundationは抜けた
      • 政治よりも開発にpivotしてしまったから
    • 役員のスキャンダルのせいで悪名高くなり、存在価値自体低くなってしまった

bitcoinがスケールするのか?まだよく分からない

  • bitcoinプロトコルに技術的な変更を入れること
    • toddは強く反対してる
  • todd曰く
  • foundationチーフサイエンティストのGavin Andresenのスケーラビリティについての仕事
    • これを特にtoddは問題視してる。
    • アカデミックレベルの厳密さが欠けてる
  • todd曰く
    • Gavinはbitcoinのスケーラビリティについてどの研究機関のリサーチにも参加してない

    • Gavinのスケーラビリティ論はリサーチに基づいてない

    • 実際にGavinがやってることも本来必要される厳密さが欠けてる
    • (補足)この懸念は解消されそう

二重支払はbitcoin会社へのペナルティと化す

  • bitcoinの取引では10分かかる承認
  • 承認完了するまで二重支払いのリスクあり
  • todd曰く
    • 二重支払いのせいでお金を失う人はその事態を認めることがまずない(認めるためのモチベーションがない)
  • 詐欺師が同じ額のbitcoinを二回以上つかえてしまうことを意味する
    • bitcoin会社にとっては結構でかい問題とtoddはみてる
  • todd曰く
    • Coinbaseなんかは承認数が0の支払いを契約によって受け取らないといけない
    • Coinbaseは自分らのビジネスをうまく回すためにそういう風にしてるんだろうが

Ethereumは学生レベルのプロジェクト

  • Ethereum
    • bitcoinをより良いものしようというプロジェクト
    • bitcoinの歴史でもかなり早い時点でスタートしたプロジェクト
    • todd自身はEthereumに色々問題があるとみてる
  • todd曰く
    • Ethereumの中の人はみんなスマート
    • 集中してやってないし真剣さがたりない
    • 学生のリサーチプロジェクトっぽい
    • 消費者が今抱えてる問題を実際に解決するような代物じゃない
  • Ethereumの志は良い
  • Ethereumをより優れた、ちゃんとマネタイズできるスタートアップが出てくるとtoddや多くの開発者は予想してる
  • todd曰く
    • Ethereumは今後よいアイディアを何個か出してくるはず
      • 最終的にはEthereum発のよいアイディアを取り込んだよりシンプルなシステムにEthereumは負ける

I expect to see them produce some good ideas, but ultimately be out competed by simpler systems incorporating those ideas.

承認時間の短縮は不可能

  • 10分
  • bitcoinのブロック承認の所要時間
  • transactionの確定のせいでもっと時間かかることも
  • コード改良しても承認時間短縮は実現できない、とtoddは感がてる
  • todd曰く
    • 承認時間はセキュリティパラメータ
    • 時間短縮はシステムの根本的な安全性を下げることになる
    • 理由は色々あげることができる
    • 例えば、巨大で中央管理されたプールを有利にしてしまう
  • bitcoinのような分散型システム
  • サードパーティへの信頼を不要にする
  • 中央管理型モデルと比べると速度はたいてい遅くなる
  • 高速化実現が意味すること
    • 大衆への普及の代償としてbitcoinテクノロジーの放棄
  • todd曰く
    • 承認時間1〜2秒の実現
      • これが中央管理型システムと互角になるレベル
      • ECで実用できるレベル
      • このレベルへの到達は不可能
    • bitcoinのシステムの1つ上のレイアーでそういう実用レベルのシステムを構築する方が見込みがある

bitcoinから派生したものがとても多い

  • 2008年の経済危機の只中でbitcoinは大衆へプッシュされていった経緯がある
  • すぐ忘れられやすい話

  • toddも今後のためにその点を強調してる

  • todd曰く

  • そもそもbitcoinとは。。。。
  • クレバーな経済と政治があってこそうまく機能するようなシステム
  • 政治的な狙いを持ってる

  • Proof of workというアイディア

  • 中央管理型システムや政府への関心があってこそ生まれた
  • 自分たちで銀行を回す
  • そうルーツがあるとしても、可能な解決方法の候補ではなさそうだが
  • todd曰く
  • 政治的な動機がないなら、proof-of-workみたいなややこしい仕組みを使う必要性はないはず
  • 信頼できる少数精鋭のサーバーで回した方が、シンプルだしずっと効率的