HTTP/2サーバー「H2O」の開発者である奥一穂氏が次世代CDNの米Fastlyに転職
HTTP/2に対応したHTTPサーバーソフトウエア「H2O」など多くのオープンソースソフトウエアの開発で知られる奥一穂氏が2017年1月12日、DeNAから米Fastlyに2017年1月1日付けで転職したことを自身のブログで明らかにした（ブログエントリ）。Fastlyは、配信拠点サーバーのキャッシュを高速に更新できる次世代のCDN（コンテンツデリバリーネットワーク）サービスを運営する。 同氏は転職の理由として、Fastlyが「H2Oの世界最大の利用者であり、世界有数の規模のHTTPトラフィックを捌く事業者であり、HTTPを高度に運用することを事業のコアとしている」（同氏のブログエントリより）ことを挙げている。同社は、著名なソフトウエアエンジニアである宮川達彦氏が在籍していることでも知られる。同氏は「最も尊敬するエンジニアの一人である奥氏と働けることにとても興奮している」（原文は宮川氏のツイ
TLS 1.3 と 0-RTT のこわ〜い話 | BLOG - DeNA Engineering
DeNA Engineer Advent Calendar 2016 7日目の記事です。 こんにちは。奥一穂です。 DeNAのゲームサーバが元になっているオープンソースのHTTPサーバ「H2O」の開発や、IETFでプロトコル関連の標準化活動を行っています。 11月に韓国のソウルで開催されたIETF 97では、私たちが提案中のHTTP拡張（Cache Digests for HTTP/2、103 Early Hints）の議論の他、TLSの次期バージョンであるTLS 1.3のプロトコル実装に関する相互運用性の確認を行ってきました。 その結果を先月末に開催されたhttp2勉強会 #10で発表してきましたので、こちらにて資料を公開させていただきます。 昨年制定されたHTTP/2に続き、TLS 1.3は制定秒読み段階、さらにQUICの標準化作業が開始されるなど、ウェブを支えるプロトコルは変革の時を
An HTTP Status Code for Indicating Hints
Network Working Group K. Oku Internet-Draft DeNA Co., Ltd. Intended status: Informational October 31, 2016 Expires: May 4, 2017 An HTTP Status Code for Indicating Hints draft-kazuho-early-hints-status-code-00 Abstract This memo introduces an informational status code for HTTP that can be used for indicating hints to help a client start making preparations for processing the final response. Status
Kazuho@Cybozu Labs: Picoev: a tiny event loop for network applications, faster than libevent or libev
I am sure many programmers writing network applications have their own abstracting layers hiding the differences between various I/O multiplex APIs, like select(2), poll(2), epoll(2), ... And of course, I am one among them. While writing mycached (see Mycached: memcached protocol support for MySQL for more information), I was at first considering of using libev for multiplexing socket I/Os. Libe
「第10回 日本OSS貢献者賞・日本OSS奨励賞」受賞者を選定 | 日本OSS推進フォーラム
日本OSS推進フォーラムは、このたび、優れたオープンソースソフトウェア（OSS）の開発及び普及に貢献した個人等を表彰する「第10回 日本OSS貢献者賞」および「第10回 日本OSS奨励賞」の受賞者を選定しました 「日本OSS貢献者賞」は、OSS開発の振興を図ることを目的に、影響力のある開発プロジェクトを創造・運営した開発者や、グローバルプロジェクトにおいて活 躍する卓越した開発者、OSS普及への貢献者を表彰するものです。本賞は2005年度に創設され、今回が第10回目となります。 「日本OSS奨励賞」は、過去1年間にOSSの開発や普及に顕著な活躍をした個人ないしグループを表彰するものです。本賞は2009年度に新設し、今年度が第6回目となります。 ■日本OSS貢献者賞 受賞者（4名、50音順） 岡島 順治郎 奥 一穂 亀澤 寛之 古橋 貞之 ■日本OSS奨励賞 受賞者（9名、1団体、50音順）
雑なツイートをしてしまったばかりにrubyを高速化するはめになった俺たちは！
逆に言うと、Rubyの文字列型の内部実装がropeになれば、freezeしてもしなくても変わらない速度が出るようになって、結局freezeする必要なんてなかったんやーで丸く収まるんじゃないの？と思いました #雑な感想 — Kazuho Oku (@kazuho) October 6, 2015とツイートしたところ、処理系の中の人から @kazuho 文字列を弄る話じゃなくて、文字列の identity の話なので、ちょっと関係ないかなぁ、と — _ko1 (@_ko1) October 6, 2015みたいなツッコミをもらって、うっすみません…ってなってRuby VMのコードを読むことになったわけです。 で、まあ、いくつか気になる点があったので手をつけてしまいました。 1. オブジェクト生成のホットパスの最適化 ホットスポットだとされていたところのコードを読んでると、オブジェクト生成の際に
Kazuho's Weblog: さらば、愛しき論理削除。MySQLで大福帳型データベースを実現するツール「daifuku」を作ってみた
さらば、愛しき論理削除。MySQLで大福帳型データベースを実現するツール「daifuku」を作ってみた 先のエントリ「論理削除はなぜ「筋が悪い」か」で書いたとおり、データベースに対して行われた操作を記録し、必要に応じて参照したり取り消したりしたいという要求は至極妥当なものですが、多くのRDBは、そのために簡単に使える仕組みを提供していません。 daifukuは、RDBに対して加えられた変更をトランザクション単位でRDB内にJSONとして記録するためのストアドやトリガを生成するコマンドです。 % daifuku dbname tbl1 tbl2 > setup.sql のように実行すると、指定されたテーブル（ここではtbl1とtbl2）にセットすべきトリガや、更新ログを記録するためのテーブル「daifuku_log」を生成するCREATE TABLEステートメントなど、必要なSQL文をset
論理削除はなぜ「筋が悪い」か
「論理削除が云々について - mike-neckのブログ」を読んで。 データベース設計において、「テーブルの書き換えをするな、immutableなマスタと更新ログによって全てを構成しろ」というこの記事の主張はモデリング論として全く正しい。 だが、残念なことに、ディスクやメモリが貴重な資源だった時代の技術であるRDBは、そのようなモデリングに基づいて設計されたデータベースには必ずしも適していない。 第一の問題は、RDBに対してなされる様々な「更新」（トランザクション）は不定形（どのテーブルをどのように修正するかはアプリケーション依存）だという点。不定形な「更新」を時系列にそってRDBに記録していくのは、設計と並走性の点において困難あるいは煩雑なコーディングが必要になる（というか、そのような「イベント」による「変化」はREDOログに書き、その更新された「状態」をテーブルに反映していくというのが
Kazuho's Weblog: 「技術的負債」は避けるべき？ - 割引率を使って考えてみた
「技術的負債」をコントロールする定量評価手法への期待 からの続きです。 ソフトウェアサービス企業における技術責任者の最も重要な仕事のひとつが、エンジニアリングの効率化です。そのためには、サービスの初期開発コストだけでなく、運用コストを織り込んだ上で正しい技術的判断を行っていく必要があります。 「技術的負債」という言葉は、この運用コスト最適化の重要性を指摘する上で、とてもキャッチーなフレーズだと考えられます。しかし、「技術的負債」を産まないように、あるいは負債を早めに返していこうとすると、開発工数が大きくなってしまうという問題もあります。 初期開発コストと運用コストのバランス注1を、どのようにとっていけば良いのでしょう？ 同等の機能を提供する「ソフトA」と「ソフトB」を考えてみます。ソフトAは、初期開発工数が6だが、２年目以降の維持工数が毎年4かかるとします注2。ソフトBは、初期開発工数が1
なぜ今、新しいHTTPサーバが必要なのか - H2O について勉強会で話したこと
先月末の話になりますが、SAPジャパンさんを会場に開催されたデータ転送ミドルウェア勉強会で、私が中心になって開発しているHTTPサーバ「H2O」について話す機会をいただき、登壇してきました。 以下は当日使用したスライドです。なぜ今H2Oを開発しているのか、その背景にある現状認識と将来の方針について、日本語で説明してあるので、興味ある方はご覧ください。 発表の機会をくださった@repeatedlyさんと@frsyukiさん、会場を提供してくださったSAPジャパンさん、ありがとうございました。 H2Oの開発は順調に進んでおり、HTTP/2サーバプッシュへの対応も完了し、まもなく次のバージョンがリリースできるかと思います。今後ともよろしくお願いいたします。
ab has not been the bottleneck in the benchmarks since both servers were pinned ... | Hacker News
ab has not been the bottleneck in the benchmarks since both servers were pinned to a single core. It is true that ab is too slow for benchmarking a HTTP server running on multiple CPU cores, but it is at least faster than a server only using one core.Regarding the performance of the HTTP parser, I have heard that picohttpparser (the HTTP/1 parser used by H2O) is much faster than the HTTP parser us
[Ann] Initial release of H2O, and why HTTPD performance will matter in 2015
[Ann] Initial release of H2O, and why HTTPD performance will matter in 2015 Happy Holidays! Today I am delighted to announce the first release of H2O, version 0.9.0; this is a christmas gift from me. H2O is an optimized HTTP server with support for HTTP/1.x and the upcoming HTTP/2; it can be used either as a standalone server or a library. Built around PicoHTTPParser (a very efficient HTTP/1 parse
![[Ann] Initial release of H2O, and why HTTPD performance will matter in 2015](https://cdn-ak-scissors.b.st-hatena.com/image/square/90ae381c088a6467bbfda3c7bff3025f8d1e363e/height=288;version=1;width=512/https%3A%2F%2Fblogger.googleusercontent.com%2Fimg%2Fb%2FR29vZ2xl%2FAVvXsEj-dKgYGLLQh_WZHPJmLENO-NsAGqRHW5Tzq6Tvc_1A6jnwYCkpRuVfX0hQWEIiJL-65Yixw-EZ7eszSZKC_wLdfziaS3lJtEHm_nSpwuK3xfZZDcriUNhfLfpwa8ln0_hoFsyLPLuQqWp1%2Fw1200-h630-p-k-no-nu%2Fh2o-bench.png)
ソースコード以外もとにかくテストする。もしくはカバレッジだけではダメだという話 | おそらくはそれさえも平凡な日々
あなたはプロジェクトのソースコードに対して適切にCIを回しているかもしれません。定期的にコードカバレッジの測定も行い、90%以上もしくは100%の数字を出しているかもしれません。 しかし果たしてそれで十分でしょうか？もしくはコードカバレッジだけにとらわれすぎていないでしょうか？ 監視とは(システムに対する)継続的なテストである、というのは筆者の尊敬する奥一穂氏の言葉ですが、その逆もしかりで 「テストとはプロジェクトに対する継続的な監視である」 ということも言えます。 その観点に立ってみると、プロジェクトのソースコード以外にもテストが必要なものがたくさんあることに気づくでしょう。以下に実際に筆者が自分のプロジェクトの中でソースコード以外にテストを書き、CIを回していたものを挙げてみます。 アプリケーション設定ファイルのテスト 開発中に本番用の設定ファイルを使うことはないため、本番用の設定ファ
C言語で可変長引数をとる関数を、型安全に書く方法
C言語の可変長引数は、型安全でない（まちがった型の引数を渡してもコンパイルエラーにならない）とされています。これは言語仕様の理解としては正しいのですが、特定の型の引数を任意の個数とる関数に限っては、マクロを使うことで型安全性を確保することができます。 任意の個数のdoubleを引数にとり、その和を返す関数「sumf」を例にあげて説明します。 C言語の可変長引数機構を使ってsumfを定義すると、以下のようになります。 #include <math.h> #include <stdarg.h> #include <stdio.h> static double sumf(double nfirst, ...) { double r = 0, n; va_list args; va_start(args, nfirst); for (n = nfirst; ! isnan(n); n = va_a
プログラミング言語における正規表現リテラルの必要性について
Twitterに書いたことのまとめです。 プログラミング言語の仕様の一部として正規表現リテラルを提供することの得失について、JavaScriptを例に説明します。 ■より簡潔なコード 言うまでもありませんが、正規表現リテラルを使った方が簡潔なコードになります。 (new RegExp("abc")).exec(s) // リテラルを使わない場合 /abc/.exec(s) // リテラルを使った場合 また、正規表現リテラルがない場合は、文字列リテラルとしてのエスケープと正規表現としてのエスケープが二重に必要になる結果、コードの保守性が低下します注1。 new RegExp("\\\\n"); // リテラルを使わない場合 /\\n/ // リテラルを使った場合 ■エラー検出タイミング 正規表現リテラルがない場合、実際にその正規表現が評価されるまで記述エラーを検出することができません。正規表
もうひとつの知られざるオープンソース 〜 ウェブ企業のOSS戦略
「オープンソースソフトウェア(OSS)」と聞いて、あなたがイメージするものはなんですか？ 多くの人は Linux や Apache、Firefox といった成功した大規模なソフトウェア製品を思い浮かべることでしょう。 実は、ウェブ上でサービスを提供する会社のエンジニアたちは、これらとは別の種類のOSSを使って仕事をしています。このブログエントリでは、そのようなOSSを紹介し、それらがなぜ開発され使われているかを説明したいと思います。 ■ウェブ企業におけるOSS開発の実例と合理性 下の図は、Perl で記述される大規模ウェブアプリケーションの一般的な構成を示しています注1。このうち、「自社ロジック」と書かれているところ以外は、全てオープンソースとして開発／公開されているモジュール（ソフトウェア部品）です。各社のエンジニアが密接に協力しながら、ミドルウェアをオープンソースとして整備していること
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DeNA Engineering - DeNAエンジニアのポータルサイト
picoev/picoev.h at master · kazuho/picoev
optimize gc sweep by kazuho · Pull Request #1049 · ruby/ruby
GitHub - h2o/picohttpparser: tiny HTTP parser written in C (used in HTTP::Parser::XS et al.)
