たいへん遅ればせながら、YAPC::Okinawa 2018 ONNNASONで使用したスライドを、こちらにて公開する次第です。 ベンチマークの難しさとチューニングの奥深さ、楽しさを共有できた結果がベストトーク賞につながったのかなと考えています。ありがとうございました&今後ともよろしくお願いいたします。 HTTP/2で 速くなるとき ならないとき from Kazuho Oku
lestrratさんがやってくれました。 ずいぶん前から、ソースコードを検索して読みやすいコマンドはないかなーと思っていました。個人的にはackで検索して見つかったファイルをlessで開いて再びキーワードを入れて当該行までジャンプしていたのですが、毎回毎回めんどくさい感じでした。コマンド一発でインクリメンタル検索してキーワード周辺のソースコードを読めるツールが欲しいなぁって思ってたんです。 とあるslackでお昼時に、mattnさんと「ほしいですよねー」という話から始まって、vimにあるgrepとかも物色しながら「いいのないねー」とか言ってたらkanさんが「@lestrrat 案件だ」って言い出して牧さんが召喚されてついさっきpecoに必要な機能が追加されてました。速いw ためしにpicotlsの開発ディレクトリでpecoの一行ラッパーperoを起動し、「EVP_Digest」を検索してみ
「「技術的負債」を問いなおす」というタイトルでJAWS DAYS 2014で話してきた #jawsdays - delirious thoughtsにて、追記でコメントいただけたので、外野として好き放題言わせてください。すばらしいスライドありがとうございます&いつもすみません。 僕が興味がもつとすると、それは「技術的負債」の定量評価手法についてです。 なぜ、そういう前提を置くかと言うと、それは、たとえばKrutchenによる「技術的負債」の定性評価は、とてもわかりやすいものの、技術を取捨選択するツールとしては使えないからです。 スライドでは、技術評価における将来の不確定性を象徴する問題としてSSDの普及前夜にシャーディングをがんばって実装してしまう例をご紹介いただきましたが、実際、そのような不確実性を織り込んだ正しい決定を我々が日々のエンジニアリングで下すことができているのか疑問に感じるこ
APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sightにはブコメしたのですが、Rebuild: 35: You Don't Need API Version 2 (Kenn Ejima)でも本件に言及があったようなので、少し一般論を書いておきたいと思います。 ■Web APIの設計原則について そもそも、良いAPIとはどのような特性をもつものでしょうか? 一般的に、以下の2点が挙げられると思います。 拡張が容易である 拡張時に後方互換性を破壊しない ウェブの場合は、これに加え、 スケーラブルである HTTPに起因する問題に上手に対処できる ことが求められます。 前2者はウェブに限らない要件です。これを満たす設計手法としては、 リクエストおよびレスポンスのパラメータを拡張可能に 互換性を壊す拡張が必要な場合は、関数名を変える 古い関数は従来と同じ機能を
「オープンソースソフトウェア(OSS)」と聞いて、あなたがイメージするものはなんですか? 多くの人は Linux や Apache、Firefox といった成功した大規模なソフトウェア製品を思い浮かべることでしょう。 実は、ウェブ上でサービスを提供する会社のエンジニアたちは、これらとは別の種類のOSSを使って仕事をしています。このブログエントリでは、そのようなOSSを紹介し、それらがなぜ開発され使われているかを説明したいと思います。 ■ウェブ企業におけるOSS開発の実例と合理性 下の図は、Perl で記述される大規模ウェブアプリケーションの一般的な構成を示しています注1。このうち、「自社ロジック」と書かれているところ以外は、全てオープンソースとして開発/公開されているモジュール(ソフトウェア部品)です。各社のエンジニアが密接に協力しながら、ミドルウェアをオープンソースとして整備していること
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く