読者です 読者をやめる 読者になる 読者になる

おにやんま - ISUCON5予選敗退してくやしい話 #isucon

2回めの isucon は @karupanerura@silvers のおふたりと参加してきました。

チームおにやんまの活動

https://instagram.com/p/8Es-fjLKqA/


やったこととふりかえり

3人のだいたいの住み分けは、

  • @karupanerura middleware まわり
  • @ar_tama アプリケーションまわり
  • @silver_s SQL まわり

みたいにざっくり切り分けてとりかかりました。

自分のだいたいの動きとしては、

12:00

とりあえず Perl で動かす→ベンチ叩いてみる→ slowlog と accees_log を集計

12:30

いったん手を止めて方針を相談(自分はとりあえず GET '/' のクエリをなんとかすることにする)

13:00

日記のタイトルと本文の分離をはかりたいがデータ多すぎて alter に時間かかりそうなので尻込みする
(ふりかえり)SQL力が低くて初期データ構造を変更しつつ alter するのを思いつかなかった

13:30

とりあえず get_user とか is_friend とかを使わず join しまくる
(ふりかえり)改修を細かい単位で反映させてベンチ取ればよかった

14:30

relations が双方向 insert されていたので friend まわりのクエリ書き換え
このあたりからしばらく comments_of_friends にハマりまくる

16:00

comments_of_friends の他をなんとかして、
しるばす氏(index 担当)かるぱ氏(nginx + my.cnf 担当)の作業ぶんとマージして 5000 点を超える
=> このへんでかるぱ氏が手が空いてきたとのことだったので footprints まわりと comments_of_friends をお願いする
=> entries あたりに手を出し始める(そしてまた焦ってハマる)
(ふりかえり)そこまでベンチに影響を与えていた部分ではなかったのでとっとと参照系のキャッシュ導入とかすればよかった


というかんじで、前半はわりとスコアアップに寄与できたんですが、後半はノーバリューすぎてつらいかんじでした。
詳しくは反省会にまとまっていますが、余裕をなくさないことがとにかく大事だなと痛感…。
それぞれのアプローチとしてはあまり外していなかったはずなので、次回はうまく各々の役割を分担・遂行できるように進めていきたいです。


ベンチマークが公開されたら(されるのかな?)さっそく復習したいくらいには各人くやしさが募っているので、
来年までキープできるようになにかしらアクションしていけたらと思います。
運営・出題のみなさま本当にありがとうございました!!

メンバーのエントリ

ofsilvers.hatenablog.com

おまけ

f:id:ar_tama:20150928224044p:plain

ワタシとPerl、ワタシとYAPC

エモい話を書くのはためらっていたんですが、皆さんのブログを読んでちょっとだけ触発された*1のでちょっぴり綴ってみます。
リアルタイムで聴けたトークがあまりないので、トーク成分は低めです。

2011

ラスト東工大の年。
@sugyan さんと @umeyuki さんに、開催2週間前に「YAPCっていうお祭りがあるよ、よかったらおいでよ」と声をかけていただいてチケットも持たずに*2飛び入り参加。

着いて早々道に迷って途中でお会いした @toku_bass さんと右往左往しながら前夜祭に滑り込んだり、
キーノートだった @hidek さんのお話に惹かれたのが DeNA に入社するきっかけになったり。
初めて会った @nontan__ と双子なのかと @yappo さんに言われたりしたのもよい思い出です-ω-

身一つで飛び込んだにもかかわらずみなさんによくしていただいて、コミュニティのあたたかさをしみじみ感じたことをよく覚えています。

2012

くしいさんに「スタッフやりたいなー」と言ったらやらせていただけることになりました一回目。東大の年ですね。*3
ランチ交流会とか、LTソンとか、企画に富んだ回でもありました。

当時の感想はこんなかんじ。
YAPC::Asia 2012でスタッフしてきた! - たまめも(tech)

関わっているかた全員がYAPCというイベントを愛していて、それぞれの得意なやりかたでコミットしているんだなあと、今回改めて実感しました。

これはずっと変わっていないですね。愛がね、ありますよね。

2013

日吉一回目。
YAPC::Asia 2013でスタッフしてきた! #yapcasia - たまめも(tech)
当日までやる気いっぱいだったんですがなんと高熱でダウン…。
2日めのドラを叩いたことは覚えてます。miyagawaデカールもこの回だったようす。今でも愛用しています。

幕間の CM で音楽を担当したのですが最後まで再生されておらず、カット部分を上司であるところの @nekokak 先生が LT に飛び入り参加してまで流してくださったという…涙なみだです。

2014

日吉二回目。
牧さんくしいさんコンビが解散し激震が走ることつかの間、次期主宰の @yusukebe さんからお声がかかり、コンセプトメイキングのお手伝いをさせていただくことに。

この年はコアスタッフ、当日スタッフ、スピーカー、個人スポンサー、企業スポンサーと本当にいろんな軸から関わらせていただいて、一番感慨深い回です。
YAPC::Asia 2014でトークしてきた! #yapcasia - たまめも(tech)

今年も去年もコアスタッフとしての実務的なお手伝いはほとんどできなかったのですが、新しい視点でイベントを見ることができてとても勉強になりました…!

2015

ビッグサイト
再び牧さん主宰となった今回は、コアスタッフに片足、メインは当日スタッフという形でお手伝いさせていただきました。*4
キャパ増加にともなってスタッフ数も多く基本的には人が足りているような状況だったので、落とし物の受付や遊撃隊業*5につとめていました。

懇親会中にコア/exコアスタッフ*6と「こうやって息をつくことももうできないんだねー」とお話しして不覚にもしんみり。
久々に会うかたがたとまるで昨日の続きのようにお話しができる空気と環境も、これまた YAPC ならではという感がありますね。

総括

このイベントきっかけで人生が変わったというひとがおそらく一定数いるだろうと思っていますし、わたしもそのうちのひとりです。それってすごいことですね!
恩返しをしきれた実感もないまま幕引きを迎えてしまったわけですが、また別の形で*7コミュニティに関わっていきたいです。

YAPC を取り巻く環境は年々変わっていきましたが、変わらないのはやはりイベントやコミュニティへの愛と、懐の広さなんじゃないでしょうか。
今年の参加者も以前と比べたらいろんな層のかたがたがいらしていて、でも空気はいい意味でそのままで。
わたしは Perl コミュニティのそういうところがだいすきです。
初参加のみなさんにも、こうした魅力のいくばくかを持って帰ってもらえたのであれば、スタッフ冥利に尽きます。

主宰の牧さん、くしいさん、ゆーすけべーさん、スタッフ・参加者のみなさま、本当に楽しいお祭りをありがとうございました。

というわけで、YAPC が終わってもぼくらはズッ友だょ…! というところで、締まらない話を無理やり締めたいと思います。ちゃんちゃん。

*1:これは牧さんの思惑通りでは…

*2:くしいさんはじめスタッフ各位、大変お騒がせしました…よい子は真似しちゃだめだぞ

*3:@sasata299 さんが結婚のきっかけを掴んだのはこの回です!!

*4:トークも応募していたんですが、スピーカー二人の仕事の都合がつかず辞退の運びに>

*5:雑用したり、無限コーヒーへの地図を描いたり、喋りやすい・聴きやすい環境の整備や指示をしたり

*6:@ricoimazu さん、@torii さん、@umeyuki さん

*7:エンジニアらしくコードで還元していきましょう

今年もお祭りをつつがなく終えた #yapcasia

f:id:ar_tama:20150823170813j:plain

たのしかった!

10年続いた "YAPC::Asia Tokyo" としては最後の催行となる今年も、スタッフとして、参加者として、堪能してきました。yapcasia.org

会場のキャパシティも去年に比べてとても大きくなりましたが、それを超えるほどの方々(2000人超!)にお越しいただけて本当に嬉しかったです。暑いなかありがとうございました。
これほどの規模、これほど多方面のエンジニアが一堂に会するお祭りももうしばらくなさそうですが…またどこかで皆さんとワイワイできることを祈っています:D
ご来場いただいたみなさま、いままで携わってこられたすべての方々、本当に楽しいお祭りをありがとうございました!

以下蛇足。


噂のPerl6ワインは白のスパークリングでした。
アルコール低めのすっきりしたお味でおいしかったです!

CentOS6 に MySQL+Mroonga を mysql-build 経由でインストールする

前提
ハマったこと

2.5. CentOS — Groonga v5.0.6ドキュメント を見ると

% sudo rpm -ivh http://packages.groonga.org/centos/groonga-release-1.1.0-1.noarch.rpm
% sudo yum makecache
% sudo yum install -y groonga

するのみでよいと書いてありますが、鵜呑みにして Dockerfile に

RUN rpm -ivh http://packages.groonga.org/centos/groonga-release-1.1.0-1.noarch.rpm && \
       yum makecache && yum install -y groonga

と書くだけでは mroonga の configure がうまくいきません。
mroonga は pkg-config で groonga, groonga-normalizer-mysql を探したがっているので、
groonga.pc が含まれている groonga-devel パッケージも同時に install する必要があるのでした。
groonga-normalizer-mysql についても同様です。

RUN rpm -ivh http://packages.groonga.org/centos/groonga-release-1.1.0-1.noarch.rpm && \
       yum makecache && yum install -y groonga groonga-normalizer-mysql groonga-devel groonga-normalizer-mysql-devel

参考になりました: MySQL 5.5 に mroonga を組込む - 飛光よ、飛光よ

JSON Schema の oneOf / anyOf / allOf

draft v4 の validation keyword たちであるところの xxxOf 三兄弟。
混乱しがちなのでまとめるぞ!

共通点

  • object の array であること
  • 中の object は JSON Schema として valid であること
  • array の中身は1つ以上であること

相違点

(oneOf) An instance validates successfully against this keyword if it validates successfully against exactly one schema defined by this keyword's value.


(anyOf) An instance validates successfully against this keyword if it validates successfully against at least one schema defined by this keyword's value.


(allOf) An instance validates successfully against this keyword if it validates successfully against all schemas defined by this keyword's value.

http://json-schema.org/latest/json-schema-validation.html#anchor75
oneOf

"it validates successfully against exactly one schema"
array のうち、かならずひとつの schema に合致することが条件です。
anyOf と違い、array 中のふたつ以上の schema に合致してしまうと fail します。

anyOf

"it validates successfully against at least one schema"
array のうち、ひとつ以上の schema に合致することが条件です。

allOf

"it validates successfully against all schemas"
array の中身すべての schema に合致することが条件です。

特に oneOf と anyOf の違いが仕様を読んでもぱっと頭に入ってこなかったので、実際に実装までたどってナルホドしました…

いまさらMySQLのcharsetとcollationの話

awesome先生*1に基礎を教わってきたので忘れないうちにメモ。

utf8_unicode_ci / utf8_general_ci

  • MySQL で default charset を utf8 に指定すると、デフォルトで選ばれるコレーションは utf8_general_ci
  • unicode_ci は文字に対して独自の weight map でもって評価する(general_ci は ascii とコードポイントで評価)
  • MySQL で実装されている weight map は1階層のみのため、日本語が入る環境では意図しない挙動をする*2
  • utf8mb4 も基本的には同一
    • ただ utf8mb4_general_ci だと絵文字の評価が厳しいので、やるならコードポイントのみで比較する utf8mb4_bin に設定するしかないとのこと

"default" charset の挙動

  • 本来 MySQL は charset / collation を column ごとに適用する
  • charset / collation の適用は column を生成するタイミング(多くは create table 時)のみ
  • column 生成時に default の指定がなかった場合のみ table => database の順に生成条件を参照し、default charset / collation が指定されていればそれが適用される
    • なので、show create database と show create table の charset が違っても慌てる必要はない
    • ただし例え alter で table の charset / collation が変更されても、既に存在する column にその設定は適用されない
  • column の charset / collation と connection 時の(client の)charset が一致していれば(もしくは変換可能な定義どうしであれば)不整合は起きない

そのた

勉強になりました。なむなむ

Slackでカジュアルにスクリーンショットを投下する

みなさんSlackで日常的にスクリーンショットによる晒しageコミュニケーションを取ったりされているとおもうんですが、
これはそのたびにスクリーンショット.pngが増えていってつらいなーと思っている人向けのエントリです。

方法はかんたん、
⌘ + Shift + Ctrl + 4
で選択範囲を画像としてコピーできるので、Slack上で貼り付け(⌘ + v)するだけでアップロードできます。


こんなかんじ。
えんじょい!

(4/21 追記)
なおGitHubやQiitaもこの機能に対応しているとのこと。はかどりますね!