以下斜め読んだ内容

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

Quincy Larson「30〜50歳超えてからエンジニアのキャリアをスタートさせた人たちの体験談を300件」

  • freecodecamp.org 2018.1.12 のエントリ
  • Quincy は、プログラミング学習サービス freecodecamp のメンターやってる人
  • とあるおっさん「中年リーマンだけど今からエンジニアになりたいとか 夢見すぎ?」
  • 俺「いけるいける。年齢はただの数字」
  • とあるおばさん「 今から勉強してエンジニアの仕事を得たいなんて思うのは無謀過ぎる?」
  • 俺「いけるいける。よくあること」
  • というやりとりを何百回とループしてきた Quincy がやり方を変えて、実際にエビデンスを集めることにした
  • その成果をまとめたエントリ

いい話

以下斜め読んだ内容

ほぼ tl;dr

中年からのエンジニアのキャリアスタートを夢見るが、尻込みして動けない人たち

自分はどうだったか

  • 相談してくる人たちの気持ちは本当によくわかる
  • 自分は 20 代は教師やってた
  • 30歳に初めてコードを書いた
  • 31歳にエンジニアとしてジョブオファーを初めてもらった

自明なこと

  • 年齢はただの数字
  • 誰だって仕事ゲットできるだけのスキルを得るために努力できる

他方で自明なこと

  • 「つまり、夢を描けるなら夢は叶う」???
    • Walt Disney流でもなんでもいいが、そういったのテンプレ回答
  • 「Don't stop believing!」?
    • テンプレ回答は無力。相談をしてくる人たちの不安を癒す力はない

テンプレ回答マンとは別路線を模索

不安を増大させるステロタイプ

f:id:vwxyz:20180222225419j:plain

  • ハリウッド映画が描くステロタイプ
  • コンピュータの天才は 30 歳以下限定
  • 30 歳超えたらみんなテクノロジー音痴、という決まり
  • 映画「The Social Network」とかみれば分かる話
  • エンジニアのステロタイプなイメージをきっちり植え付けてくる

「中年からのジョブチェンジ体験談」の収集をスタート

  • まずそんなリストはどこにもなかった
    • オジさんエンジニアリストはあるのはある
    • けれど、エンジニア歴 10-20 年とかの人で構成される
  • 中年になってからエンジニアになって食べてる人たちのリストはないから作ることにした
  • リスト作りのために twitter で呼びかけた
    • 「私は 30(or 40 or 50)代だけどエンジニアとしてキャリアをスタートさせるのは年齢的に無理ですか?」という質問を何度も受けること
    • 自分は 31 歳からエンジニアとしてのキャリアをスタートさせてこと
    • そう言う人を知ってたら教えて欲しい
    • https://twitter.com/ossia/status/949421989126602752

呼びかけに反応してくれた人が沢山出てきてくれた

「中年からエンジニアのキャリアをはじめること」はよくあること

  • 「よくあること」ってことを納得してもらいたくて作った
  • このリストは成長させていきたい。まだまだ募集中
  • 「エンジニアのキャリアをスタートさせたい」
    • そう思ったときに何歳であってもその気持ちを無くさないようにしてほしい
    • 珍しい話ではないし、よくあること
    • 君はきっと将来いい会社にエンジニアとして在籍してるはず

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

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にバグがある