IIJ-II 技術研究所 技術開発室の山本です。現在技術開発室は、私を含めた4人で構成されており、主にプログラミング言語Haskellを使って開発を進めています。今回の話題である TLS(Transport Layer Security) 1.3 もHaskellで実装しました。 4年の歳月をかけて議論されてきたTLS 1.3ですが、この8月にめでたく仕様がRFC 8446となりました。貢献者リストに私の名前が載っていることを聞きつけた広報から、ブログ記事の執筆依頼がありましたので、TLS 1.3の標準化や実装の話について書いてみます。 なぜTLS 1.3を標準化する必要があったのか理由を知りたい方は、「TLSの動向」という記事や「TLS 1.3」というスライドを読んで下さい。 インターネットで使われているプロトコルは、IETFという団体で仕様が議論されて策定されます。IETFには、誰でも

お久しぶりです。ひろたんです。 前々から気になっていたAWS EC2の169.254.169.254について少し遊んでみたのでまとめます。 EC2では、インスタンス内から http://169.254.169.254/ にアクセスすると、そのインスタンスに関する情報が取得できるようになっています。 docs.aws.amazon.com あまり意識したことはないかもしれませんが、インスタンスにIAMロールを結び付けた状態でAWS CLIを使うと内部的にこの169のURLが叩かれる仕組みになっています。 これはインスタンス内で--debugオプションを使ってAWS CLIを実行するとわかると思います。 [ec2-user@ip-172-31-30-197 ~]$ aws s3 ls --debug ～～～ 2018-09-03 11:11:33,898 - MainThread - boto

本記事はWebAssemblyに関するシリーズの第5回目で、今回のテーマはWebAssemblyが高速な理由です。前の記事をお読みでない方は、 初めから目を通される (訳注:原文リンク)ことをお勧めします。 前回の記事 (訳注:原文リンク)では、プログラミングに WebAssembly あるいはJavaScriptを使うかは二者択一の選択ではないことを説明しました。私たちは、WebAssemblyのみのコードベースを書く開発者が膨大な数になるとは思っていません。 ですので、アプリケーションにWebAssemblyとJavaScriptのどちらを使うか選ぶ必要はありません。しかし私たちとしては、開発者がJavaScriptコードの一部をWebAssemblyに置き換えることを期待しています。 例えば、Reactで開発しているチームは、リコンサイラコード（言い換えれば仮想DOM）をWebAss

CDN <script nomodule src="https://cdn.jsdelivr.net/npm/ie-buster@2.0.2/dist/ie-buster.min.js"></script> <script nomodule>ieBuster.init()</script> <script> に nomodule を付与すると、ES Modules に対応しているモダンブラウザで JavaScript の読み込み自体をキャンセルできます。 npm $ npm install ie-buster import ieBuster from "ie-buster" // Use ieBuster.init() // OR (If window becomes undefined) process.browser && ieBuster.init() // OR (If proce