Fastly に入社しました
Summary in English: Joined Fastly, will continue my work on H2O there as an open-source developer. 2017年1月1日付で、Fastly 社へ転職したので報告いたします。 過去５年間、DeNA では R&D 的な立場から、様々な基盤的ソフトウェア（オープンソースになったものもありますし、クローズドなものもあります）の開発に携わってきました。 最近２年間は、同社のゲーム用サーバに端を発するオープンソースの HTTP/2 サーバ「H2O」の開発に従事してきましたが、その実装品質が高く評価され、世界有数のコンテンツ配信ネットワーク（CDN）である Fastly で採用された他、大規模なウェブサービス事業者で採用にむけた動きが進むなどの成果が出つつあります。 また、H2O における実装経験をもとに、H
Kazuho's Weblog: HTTP/2 is much faster than SPDY thanks to dependency-based prioritization
HTTP/2 is much faster than SPDY thanks to dependency-based prioritization Background HTTP/2 provides two methods to prioritize streams (e.g. files being served). One method is called weight-based prioritization. In weight-based prioritization, every stream is given a weight, and the value is used by the server to proportionally distribute the bandwidth between the streams. The other method is depe
論理削除はなぜ「筋が悪い」か
「論理削除が云々について - mike-neckのブログ」を読んで。 データベース設計において、「テーブルの書き換えをするな、immutableなマスタと更新ログによって全てを構成しろ」というこの記事の主張はモデリング論として全く正しい。 だが、残念なことに、ディスクやメモリが貴重な資源だった時代の技術であるRDBは、そのようなモデリングに基づいて設計されたデータベースには必ずしも適していない。 第一の問題は、RDBに対してなされる様々な「更新」（トランザクション）は不定形（どのテーブルをどのように修正するかはアプリケーション依存）だという点。不定形な「更新」を時系列にそってRDBに記録していくのは、設計と並走性の点において困難あるいは煩雑なコーディングが必要になる（というか、そのような「イベント」による「変化」はREDOログに書き、その更新された「状態」をテーブルに反映していくというのが
Kazuho's Weblog: 「技術的負債」は避けるべき？ - 割引率を使って考えてみた
「技術的負債」をコントロールする定量評価手法への期待 からの続きです。 ソフトウェアサービス企業における技術責任者の最も重要な仕事のひとつが、エンジニアリングの効率化です。そのためには、サービスの初期開発コストだけでなく、運用コストを織り込んだ上で正しい技術的判断を行っていく必要があります。 「技術的負債」という言葉は、この運用コスト最適化の重要性を指摘する上で、とてもキャッチーなフレーズだと考えられます。しかし、「技術的負債」を産まないように、あるいは負債を早めに返していこうとすると、開発工数が大きくなってしまうという問題もあります。 初期開発コストと運用コストのバランス注1を、どのようにとっていけば良いのでしょう？ 同等の機能を提供する「ソフトA」と「ソフトB」を考えてみます。ソフトAは、初期開発工数が6だが、２年目以降の維持工数が毎年4かかるとします注2。ソフトBは、初期開発工数が1
LINE「独自暗号化」のメリットと安全性について
LINEが使用している「独自の」暗号化手法について、情報が一部開示（参照：LINEの暗号化について « LINE Engineers' Blog）され、Twitterでもやりとりをしたので、まとめてみる。 ■なぜTLSを使わないか TLSではなく、１パスのメッセージ暗号化を使っている理由については、Adopting SPDY in LINE – Part 2: The Details « LINE Engineers' Blogに以下のような記載があり、TLSを使うことによるレイテンシの増加を懸念しているためと考えられる。 3G mobiles networks normally operate at slow speeds. （中略）If the connection changes modes when the user sends a message, we are forced t
パスワードが漏洩しないウェブアプリの作り方 〜 ソルトつきハッシュで満足する前に考えるべきこと
■■序論 徳丸さんのスライド「いまさら聞けないパスワードの取り扱い方」に見られるように、昨今、ウェブアプリケーションの設計要件として、サーバ内に侵入された場合でもユーザーのパスワードをできるだけ保護すべきという論調が見受けられるようになってきました。 上掲のスライドでは、その手法としてソルトつきハッシュ化を勧めています。しかしながらスライドに書かれているとおり、ソルトつきハッシュには、複雑なパスワードの解読は困難になるものの、単純なパスワードを設定してしまっているユーザーのパスワードについては十分な保護を提供できないという問題があります。そして、多くのユーザーは適切なパスワード運用ができない、というのが悲しい現実です。 ソルトつきハッシュを使った手法でこのような問題が残るのは、ウェブアプリケーションサーバに侵入した攻撃者がユーザーの認証情報をダウンロードして、認証情報をオフライン攻撃するこ
「オープンソース開発者がDeNAを選ぶ理由」 (OSC 2011-Kyoto 発表資料)
Hi to every one, it’s really a nice for me to pay a visit this site, it includes useful Information. Thanks a lot for sharing with use! Greatclosetspoeler ReplyDelete Thanks for sharing this nice post. http://5thpm.in/ http://5thpm.in/packers-and-movers-gurgaon.html http://5thpm.in/packers-and-movers-delhi.html Packers and Movers @ http://5thpm.in/ Packers and Movers in Gurgaon @ http://5thpm.in/p
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
