Webアプリケーションのベンチマークをとるときに気をつけている10のこと - たごもりすメモ
10もないかも、と思いながら項目を書き出してみたら10以上余裕であってキリがないので10で収めた。いやあ、あるなあ。 仕事柄よくベンチマークを実行したりしてて色々と思うところが溜まっていたところ、以下のような記事を見掛けたのでなんか書こうと思った。ところでこの記事はベンチマークを実行するための準備作業がループを回して2時間かかるところの待ち時間に書かれている。 sfujiwara.hatenablog.com ISUCONといえば多少縁があるコンテストで、文中でISUCON5のことについても言及されているので、それも含めて。 自分が業務でいじっているのは "Webアプリケーション" というとちょっと違うんじゃないのというものばかりだが、いやー、最近なんでもHTTPで外部APIを作るからベンチマークのコツとしては大体変わんなかったりするよね。 なおこの記事でベンチマークはどのようなものかとか
ISUCON8本戦出題記というよりぶっちゃけ工数感どうなの？って話 - KAYAC engineers' blog
こんにちは！ サーバーサイドサイドエンジニアの荒賀です。 普段はソーシャルゲーム事業部でゲームの開発したり、Lobi事業部でコミュニティサービスの開発をしたりしています。 さて、この度ISUCON8の本戦問題の出題を担当させていただきました。 問題に関する解説は公式のブログを書きましたのでこちらを御覧ください。 ISUCON8 本選問題の解説と講評 こちらでは技術的なことは置いておいて、業務としてどのようにISUCON8に関わってきたかを書き残しておきたいと思います。 (※カヤックの出題はISUCON3でもしており今回が2回目です。) はじまり (2017/12〜2018/2) だいぶ曖昧な記憶ですが、ISUCON7で優勝させていただいた直後の打ち上げの場で、僕の耳元で941さんが「来年はカヤックさんどうですか〜(ニヤニヤ)」と囁いてきたので、とりあえずニヤニヤで返したことを覚えています。
ISUCON8 本選フォトレポート : ISUCON公式Blog
お題となるWebサービスを決められたレギュレーションの中で限界まで高速化を図るチューニングバトル、それがISUCONです。過去の実績も所属している会社も全く関係ない、結果が全てのガチンコバトルです。第8回目となった ISUCON のフォトレポートを今年もお届けしたいと思います。 関連エントリ ▼ISUCON8 開催決定！出題とサーバ提供はあの会社さんだ！ #isucon : ISUCON公式Blog ▼ISUCON8 オンライン予選の参加登録を開始＆参加チームとメンバーリスト : ISUCON公式Blog ▼ISUCON8 本選 Tweet まとめ #isucon - Togetter 9時開場、10時開始というエンジニアにとってはわりと早い時間帯のスタートにも書かわらずバッチリ集合してくださった皆さん。気合い充分です。 準備万端であります ISUCON公式@isucon_official
ソフトウェア開発技術者が知っておくべき５つの法則 - スタジオ・アルカナ技術ブログ
はいどうも～。 本日はhidetarouの番ですが休業中のため代打でしゃしゃり出たエンジニア吉田です。 「○○○な●●つの○○○」なんて感じのタイトルを付けると、 なんだか興味が惹かれるというのを目にしたので活用してみました。 ※個人的にはそうでもない気がしている。 というわけで、今回はソフトウェアに関係しそうな「法則」を５つほど紹介し、 それをソフトウェア開発業務にどう生かしていくかを考えてみます。 本日ご紹介する法則は以下の5つです。 ブルックスの法則コンウェイの法則パーキンソンの法則マーフィーの法則ハインリッヒの法則 でわでわ、早速。 ブルックスの法則 「遅れているソフトウェアプロジェクトへの要員追加はさらに遅らせるだけだ」 これは、IBMのOS/360（メインフレームOS）の開発者であるフレデリック・ブルックスが 名著「人月の神話」で提唱したプロジェクトマネジメントに関する法則です
AWS X-Ray による ISUCON8 本選問題の解析 - 酒日記 はてな支店
ISUCON8 の本選問題は、競技者がコントロールできない外部 API 呼び出しを多数含んだ出題内容でした。 講評では、 サービスの特性を適切に分析した上で、まとめるところはまとめたり、遅延させるところは遅延させるなど ……とさらっと書かれていますが、実際そんなことを短時間で分析することは可能なのかよ！という話題が競技後の懇親会でもあったので、それ AWS X-Ray でできるよ、というエントリをまとめておきたいと思います。 今回の解析は Perl 版の初期実装に対して行ったものですが、なぜ Perl かというと AWS の公式 SDK にない X-Ray 関連の CPAN モジュールを自分が書いているので、その宣伝も兼ねています。(blogエントリ書いてなかった) AWS::XRay Plack::Middleware::XRay Devel::KYTProf::Logger::XRay
ユーザーファーストなサービスの立ち上げ方 - Speaker Deck
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
ドッグフーディングの落とし穴 - 小さなごちそう
photo by Mitchel ドッグフーディング（Dogfooding）とは、自社製品を社員が日常的に利用して、製品の問題点をチェックすることを言う。ユーザー視点で製品の品質やUXを確認することができる。 ただ、ドッグフーディングにはいくつか落とし穴がある。Wikipediaに簡潔にまとまっていたので紹介する。 ▼ Eating your own dog food / Criticism and alternative terms 開発者はユーザービリティや一般ユーザーの知識量を考慮せずに機能追加しがちである。 「ソフトウェアのアップデートをリリース版からではなくβ版から行う」など、一般ユーザーと異なる利用体験をしていることがある。 自社製品だけでシステムを構成してしまう（一般的にユーザー企業は複数のベンダーの製品を組み合わせて社内システムを構築する）。 個人的に注意しなければならない
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DXレポート ～ITシステム「2025年の崖」克服とDXの本格的な展開～（METI/経済産業省）