実力を出し切るチーム作り a.k.a. ISUCON7参加記録

はじめに

ISUCON7 チームhetenkoの@anoworlです。@kodam(ISUCON7に参加しました - おっぱい)および@hentekoと参加しました。

このチームでISUCONに参加するのはこれで3回目なのですが、3回目にして個人的には実力を出し切れたと言えるようになり、また実力不足で敗退したと胸を張って言えるようになりました。意外とこれが難しく、1回目や2回目では達成できなかったので、知見を共有するためにこのブログを記しました。

またタイトルはこんなんですが別に自分はチームを作っておらず、3人が力を合わせたことで実力を出し切ることができたと思っています。

実力を出し切るとは

仮に実力が発揮できなかったとしたら、それはどんな状況を指すでしょうか。例えば以下が挙げられると思います。

  1. 競技開始後に方針を決める所から始まり、実作業に移るまでロスがある
  2. 思いつきで改善し、点数の上下に一喜一憂する
  3. 単独の作業に徹し、複数人で参加する意味が無い
  4. 不具合を発生させてしまった際に原因を特定できず、過大なロールバックが発生する
  5. レギュレーションの読み間違いで、意味の無い部分にコミットする
  6. 取り戻せない失態を犯し、不戦敗となる
  7. 提出間際まで改修を加え、動いているか分からない状態で提出する
  8. 再起動試験に失敗する

では、そのために何が出来るでしょうか。

  1. 方針を事前に決め認識を合わせ、当日はその通りに行動する
  2. 計測を行い確信を持って改善し、着実に点数を伸ばす
  3. 複数人でレビューを行ったり知恵を出し合うことで、単独で起こすミスを防いだり一人では思いつかない方法を取り入れる
  4. バージョン管理システムで管理すると共に、各時点のログや点数を記録しておき、任意の時点にロールバック出来るようにする
  5. レギュレーションを最初に確認し、余計な手戻りや勘違いを防ぐ
  6. 不戦敗となってしまう部分には殊更気をつけ、そもそも起こらないフローを確立する
  7. 提出前にやることリストを作り予めスケジュールに時間を確保する
  8. 余裕を持って再起動試験を行う

今回特によくやったと思えた、1と2について説明します。

実力を出し切るためのいくつかの方法

1. 方針を事前に決め認識を合わせ、当日はその通りに行動する

私はISUCONに参加するのはこれで4回目ですが、未だに時間が限られたコンテストとなるとイキってしまい、視野が狭まったりしてしまい普段できていることができなくなります。

その対応策として有効なのは、興奮していないコンテスト前に冷静な頭で何をどのようにやるか決めておくことです。今回はへんてこさんがホワイトボードにいい感じにまとめてくれたので、コンテスト中にイキってもそれを見てその通りに行動することで、空回りしたり見落としをしてしまうことが防げました。

2. 計測を行い確信を持って改善し、着実に点数を伸ばす

これまでのコンテストで悔しかったのは、思いつきで改善したけど効果が上がらず、無駄に時間を浪費していたことです。例えば思いつきでインデックスを張ったが、特に速くならないし場合によっては遅くなったみたいなことが、過去にはありました。

その対応策として有効なのは、計測を行ってどこがボトルネックになっているのか特定し、その部分に対して改善を行うことです。今回は以下のツールを使って計測を行いました。

  • netdata
  • kataribe
  • rack-lineprof
  • pt-query-digest

またこの方針で行動して良かったのは、議論が発散した時に誰かが「計測しよう」と言うことで、その時点で空中戦が終わり計測という具体的なプロセスに入れることです。

「思いつきで改善すると点数が上がる(かもしれない)」という射幸心を煽る状況に加え、長時間の疲労で人間はまともな思考が出来なくなるので、投げかけて貰えることで一旦場が整う一言があったのは強かったと思います。

おわりに

今回は残念ながら予選敗退となってしまいました。しかし突破された方のブログなどを見て、自分たちの方向性は間違っていなかったと強く確信することが出来ました。課題も明確になったので来年は実力をつけ、笑顔で優勝したいと思います。

ウェブサービス企画書供養その1: Facecards

VALUというサービスをTechCrunchで発見し、共感すると共に以前コンペ(就活)で企画を練ってた関連しそうなウェブサービスを思い出したので供養ついでに公開。

シナリオ例やビジネスモデルは完全に忘れてたけど、今読んでも結構面白かった(自画自賛)。今突っ込めと言われた死ぬほど突っ込めるけれど…。

ちょこっとスライド紹介

背景

要はこの頃クラウドファンディングが流行ってたんだけど、自分は紐付きじゃないお金が欲しかったので考えた(ゲス)。&ソシャゲのカードは仮想価値だけどたくさん投資されてるよね&それをもっと個人をエンパワーするために使っていこう&若い世代へ価値を転化してもいいのでは。

f:id:anoworl:20170604013016p:plain

ユーザシナリオ

個人を応援するという意味ではVALUに似ている。カードなのはソシャゲから。

f:id:anoworl:20170604013106p:plain

ビジネスモデル

1はJASRAC儲かってていいな!っていう感じで書いてた。

f:id:anoworl:20170604013233p:plain

SlideShare

おわりに

企画書のフォーマットに落とすと結構考えるので良いなと言う想い!企画書やっていきましょう✊

実在する人間のBOTを作る方法序説

前置き

この記事はDark - Developers at Real Kommunity Advent Calendar 2015 - Adventarに寄せる9日目の記事です。昨日はarataさんのDarkを支える技術 #3 テスト編 - 日頃の行いでした。この記事は《闇》【Dark】を意識して書かれたものです。

この記事では実在する人間のBOTをSlack上に作り、一年間にわたってメンテナンス、運用した実例をご紹介します。

この記事で分かること

  • 実在する人間のBOTの一年にわたる運用例

この記事で分からないこと

なぜ作ったか

インターネットにへんてこさんという人物がいます。その人物が発する言葉はあらゆる文脈に適用可能で汎用性があり、またユーモアに長けていました。それはまるで磨き抜かれた珠玉がほろほろとネット上に紡ぎだされているようでした。私はその零れ落ちた珠玉が流れ去ってしまうのを見過ごしてしまうことが出来ず、その珠玉を拾い集め再利用する術を探し、BOTを作成するに至りました。

どうやって作ったか

本人に許諾を得る

対象となる人物をコンテンツ化することになるので、本人にまず許諾を取りました。これもただ許諾を取ったら終わりではなく、BOTに手を加える際には対象となる人物が嫌ではないか一度考えてから行うようにしています。

複数人による発言のキュレート、保存

このBOTを作るのに必要なのは、何よりその人物が紡ぎだす珠玉です。それを集めなければなりません。当初は私がへんてこさんの発言を手作業でキュレートしたものを使っていました。全ての発言を強引に取得し使うことも出来たのですが、へんてこさんも人間であり全ての発言において汎用性がある訳ではありません。そこで、汎用性のある発言を私という人の手を介し選別していました。

しかしこの選別にも限度があり、私が忙しい時、またやる気の無い時に発生した珠玉を集めることが出来ません。また私という見識の浅い一人の人間に依拠してしまうと、取りこぼされてしまう珠玉が存在するという問題もありました。そこでSlackに珠玉を集約するチャンネルを作り、他の人間にも手伝って貰うようにしました。これにより、一人ではモチベート出来ない作業も競争原理でモチベートされると共に、時間ややる気の制約から珠玉の集約作業を切り離し、安定化させることが出来ました。

キュレートにおけるルールの策定

複数人でキュレートを行うと発生するのがキュレートの妥当性です。ここでは実在する人間に許諾を取りその人物を模したBOTを作ったということもあって、その人物が発した発言以外は認めないという方針を取りました。ただその人物が発した発言であればSlackはもちろん、Twitterでも現実世界でも可としました。発言が集約されるチャンネルには、他の人間がソースを確認できるよう、必須ではありませんがソース元のURLやどういった場で発言されたものか付記する文化が醸成されました。

ランダム発言BOTの作成

肝心の集めた発言の使い方です。前述したように発言には汎用性があったので、数時間に一回のペースでランダムに発言を行うようにしました。またこの際一手間加えており、最近キュレートされた発言ほど発言される確率が高くなるように設定しました。これにより内輪ウケはもちろん、キュレートした人のモチベート向上にも繋がったと思います。

雑談APIの使用

ランダムな発言だけではBOTに色が付かないので、NTTドコモの雑談対話APIを使い会話を行えるようにしました。

雑談APIには特に大きなカスタマイズはせずそのまま使用しているのですが、その際にキャラクター設定を「赤ちゃん」にしました。これによりBOTの口調が特徴的なものになり、本人から離れた"BOT"というキャラクター象が生まれ、BOTへの愛着が各人に出来ました。この口調を真似するものも出てきており、BOTの人格形成という意味で非常に役に立ちました。

最後に

誇張ではなく、無くてはならないSlackの一員となるまでBOTは成長しました。今後の成長も期待しています。

カネの力でTwitterアイコンバッジ創るぞ!!!

前置き

この記事はhenteko Advent Calendar 2014の二日目です。昨日の記事は kubo39 さんのhenteko advent calender Day.1でした。

hentekoさんについて

へんてこさんのTwitter IDは @bilyakudan です。なぜ @henteko で無いのかと問うたところ、何か理由があった気がするのですが、忘れました。そのせいで、Twitterアカウントとリアルのへんてこさんが一致するのに時間がかかりました。

バッジを創った経緯

そんなへんてこさんしかり、私はTwitterアカウントとリアルの人を一致させるのが苦手です。そのため勉強会では、みんなの頭の上にTwitterアイコンが浮かんでいたらすっごい便利だなぁと思うことがよくあります。

ではまず自分からということで、勉強会でTwitterアイコンのバッジを付けることにしました。もちろん元々そんなのは持っていないので、カネの力で創りました。その始終がこの記事です。

カネの力でバッジを創る

バッジ屋さんとプランの選定

バッジ屋さんというのは探してみると意外にたくさんあります。料金体系は同人誌の印刷を印刷所さんにお願いすることを考えると想像しやすいです。 以下が選定の際に考慮する点となります。それぞれに注意点を付記しました。

  • 最低作製個数
    • 自分で付ける場合そんなにはいらないのですが、最低作製個数が決まっているところも多くあります。1個から作ってくれる所もあるのですが、1つあたりの値段が高かったり……。
  • 1つあたりの値段
    • 多く作れば作るほど安いです。
  • 送料
  • 形態
    • サイズ
      • だいたいの所が小さいものから大きなものまで複数のサイズを取り揃えています。
      • 丸がスタンダードで真四角に対応してくれている所もあります。私はTwitterアイコンは四角というイメージがあったので、四角にしました。
    • 裏側
      • スタンダードな安全ピン以外に、クリップピンにも対応してくれている所もあります。服に穴を空けたく無い場合はお勧めかもしれません。マグネットやストラップ、キーホルダーにしてくれる所もあります。
  • 納期
    • それぞれ違い、特急作製を行ってくれる所もあります。
  • 品質
    • サンプルを貰える所では貰って確かめるのも一つの手かもしれません。ただそんなに多くは無かった気がします。
    • 私もどうやって注意すれば良いのか分かりませんでしたが、サイト上の説明などを参考にはしました。
  • 対応
    • 名前で検索すると2chなどに口コミがあったりします。

私はsocondpressを選択しました。値段と特急作製の有無、サイトの説明で選びました。最低個数はこの際無視しました。ちなみにこの場合の見積例を以下に挙げます。

●お見積もり内容
・商品
四角形40mm缶バッジ                20個 @    85円 =    1700円
・オプション
特急製作料金                       1個 @   510円 =     510円
送料                               1個 @   850円 =     850円
_____________________________________________
小計                                             3060円
消費税                                            245円
合計                                             3305円

デザインデータの用意

上記を決めたらバッジのデザインを作成します。バッジ屋さんでテンプレートを用意してくれているので、そちらを開いて編集しましょう。だいたい、IllustratorPhotoshopのテンプレートが用意されている気がします。CMYKモードで作成することに気をつけましょう。JPEGに対応してくれている所もあります。

私が作成したデータを以下に示します。

f:id:anoworl:20141202115827p:plain

購入

ぽちぽちです。良い時代になったものです。

届いた

やった!

f:id:anoworl:20141118181803j:plain

自由に楽しみましょう

f:id:anoworl:20141202121159j:plain

後置き

明日は Amothic さんです!

(スープ)カレーはさいきょうのたべもの

前置き

この記事はカレー Advent Calendar 2013 23日目の記事です。昨日の記事はtan_go238さんの空堀の旧ヤム邸にカレーを食べに行ってきました。でした。

(スープ)カレーはさいきょうのたべもの

カレー!!私が自炊においてカレーが最強の食べ物だと確信した経緯をお話します。それは私が大学に入学し一人暮らしあーんど自炊を始めた頃のお話です・・・。

自炊を始めた最初の一週間では、手間の問題からまず素材(じゃがいもや肉、もやしなどを)を蒸すなりチンするなり焼くなりしてそのまま食べていました。しかしさすがに一週間かそこらで素材そのままの味ではキツくなっていきました。もやしを何も付けずに食べるのは非常に大変なものがあります・・・。

次に調味料を買い素材に付けるようになり、更に一週間ほど凌ぐことが出来ました。しかしこの頃調理が面倒になっていました。調理する時にずっと炒めるなりなんなり手を動かさないとならないのは非常に手間だと。

そこで次の一週間では煮込み料理であるポトフを作るようになりました。これは材料を洗って切って全部鍋にぶち込んで煮ればいいので簡単です。ただそれでも面倒なので、一週間分を作り冷蔵庫に入れて毎日少しずつ食べていました。一週間の終わりには飽きてきました。

そして満を持して私の食生活のベストプラクティスが次の一週間に見つかりました。

それは(スープ)カレーです。

一週間の始めにスープカレーを作り冷蔵庫に入れて少しずつ消費していきます。するとスープカレーは数日で水分が少なくなりまるでカレーのようになります。更に週の終わりには更に水分が少なくなりドライカレーのようになります。

スープカレー→カレー→ドライカレー

これが私の自炊における最高の方程式です。 ありがとうございました。

最高のカレーにしようぜ!

以下はせっかくなので今日食べたゴーゴーカレーですが、自分の作るカレーとは違い具が見当たりませんでした。自炊カレー食べたいなぁ・・・。

f:id:anoworl:20131223130031j:plain

後置き

明日はsyo_sa1982さんです!!

カッティングプロッタで羽の様な名刺を創ろう

前置き

FuniSaya Advent Calendar 2013 11日目です!昨日はкёкуさんの荒木良造・著「姓名の研究」を読んだので感想を書いてみた~FuniSaya Advent Calendar 2013 10日目でした!

はじめに

好きなモノは創りたい。私の行動原理。

過程

好きなモノ

これのみゲームのスクリーンショットユメミルクスリより転載。

f:id:anoworl:20131211232114j:plain

きっかけ

f:id:anoworl:20131211232228j:plain

ラフ

f:id:anoworl:20131211232243j:plain

デジタル

f:id:anoworl:20131211232316j:plain

パス化

f:id:anoworl:20131211232413j:plain

テスト出力

f:id:anoworl:20131211223611j:plain

名刺サイズ

f:id:anoworl:20131211232605j:plain

思いつき

f:id:anoworl:20131211232816j:plain

量産

f:id:anoworl:20131211232841j:plain

ふへへ

f:id:anoworl:20131211232913j:plain

かんせー!

f:id:anoworl:20131211232923j:plain

後置き

明日はUSAMI Kentaさんです!

Railsアプリケーションにおけるパフォーマンス測定について調査

背景

Heroku上でRuby on Railsを使い作成したウェブアプリケーションを運用している。しかしアプリケーションの一つの機能である画像のアップロードについてレスポンス時間が長く、ボタンの二度押しや複数同時アクセスがあった時に応答が返ってこないことやアップロードに失敗することがある。そこを解決するためにこのアプリケーションのパフォーマンスチューニングを行うが、定量的な測定が出来なければ改善したかどうかが施策後曖昧になってしまい、目標を達成できたのか(いつどこで施策をやめるのか)、どの施策が有効だったか分からず今後に活かせないことが考えられる。そこでここではRailsアプリケーションにおけるパフォーマンス測定について調査する。

他に参考にした記事

Rails アプリケーションのパフォーマンスについて RubyKaigi 2013 で発表しました | クックパッド開発者ブログ

RubyKaigi 2013で発表されたクックパッドの社員の方によるRailsアプリケーションチューニングについての資料。最近の資料でありRailsを大規模に使っているクックパッドの事例なので、とても資料価値が高いように思われる。

rails/rails-perftest

Rails 4にてgemに切りだされたパフォーマンス測定ライブラリ。

newrelic/rpm

New Relicでの測定が優れているという噂。Developer ModeとProduction Modeで表示される情報が違うらしい。

#368 MiniProfiler - RailsCasts

日本語の資料です。主にSQLクエリのプロファイリングを行うことができます。

#411 Performance Testing (pro) - RailsCasts

RailsCastsの有料記事です。

指標

チューニングする値について

サーバ側でチューニング可能な、リクエストが最後までサーバに辿り着いてから、サーバがレスポンスをクライアントに向けて送信し始めるまでの時間のチューニングを行う。ここではDOMのレンタリング時間や複数のコネクションを張ることによる遅延時間は対象に含めない。またクライアントから送られるデータのサイズによるネットワークの遅延時間も対象とならない。

レスポンスタイム(応答時間)の定義について

例えばクックパッドでは200ms以下にレスポンスタイムを抑える目標を持っていますが、この「レスポンスタイム」とはどのように計測したものなのか、まず考察しました。どうやら先日行われたRubyKaigi 2013でのIssei Narutaさんのスライドを見るに、前項での定義と同じだと思いました。よってここでもその定義に従おうと思います。 ただ一部でクライアントがレスポンスを受信するまでの時間と定めている記事があり、これはネットワークでのデータ送受信にかかる時間が含まれ前述のレスポンスタイムの定義とは異なることから、各々の記事でどのようにレスポンスタイムが定義されているかについては、意識しなければならないと思いました。(情報処理試験における定義ISO/IEC9126における定義についても面白かったです)

実際

Apache JMeterで規定のリクエストを30回行い、サーバ側でレスポンスタイムを測ると共にJMeerでサンプルタイムを測り、それらの値をグラフ化及び平均化し比較及びチューニングを行った。