時計を壊せ

駆け出してからそこそこ経ったWebプログラマーの雑記

YAPC::Tokyo 2019で話したことの落穂拾い、あるいはISUCON8予選問題出題の感想

話してきた。スライドはこちら。

speakerdeck.com

20分で話せるボリュームにまとめるにはちょっとスコープが広すぎて抽象的かつ割と普通な結論になってしまったなと題材選びに反省がある。 もう少し具体例について堀り下げられる時間がほしかったが、コンテキストなくそこだけ話してもやはり本質的には意味の薄いものになってしまっただろう。 問題を考えるときに、チームとして実際に考えてたことの本質的な部分についてなんとか言語化できたかなーという気がする。 逆に言えばそういう言葉を使って議論してたわけじゃなくて、自然とそういう目的や価値観を議論の中で共有できたからこそ、問題を良い方向にどんどんブラッシュアップできた。といえると思う。(ぼくが勝手にそう思っていただけでなければ…)

基本的にはまとめに書いたとおり、目的ドリブンで価値観を決めて、その価値観をもとに良し悪しを図り、やっていく。を実践した結果としてこういうのが出来たという話をした。 言ってることは当たり前のことになっちゃったけど、なんだかんだ一番重要かつ本質的に一番大事だったのはここで、これをそのまま伝えることにした。

プロポーザルに書いておいて語れなかったことにちょっと触れる。

どのようにしてブラックボックスとなっているアプリケーションが仕様を満たしているかをテストするとよいのか

これは id:sonots さんが主にやっていたことなので本当はインタビューしないといけないんだけど、 基本的には操作による状態の変化をエミュレートして、サービスが返すデータがそれと矛盾していないことをテストしていた。 簡単な具体例をだすと、S席が100席あるときに並列で5人同時に買ったら、残り95席になっているはず、それぞれ別の席が得られているはず、ということを確かめる。

実際はもっと複雑で、タイムアウトがありえる。すると何が難しいかというと、クライアント側からは操作が成功しているか失敗しているかが分からない。 つまり、並列で5人同時に買った操作のうち2件がタイムアウトした場合、残りの座席は95席とは限らないし97席とも限らない。 僕たちはどうしたかというと、許容誤差の範囲を動的に計算して、95席〜97席の範囲に収まっていれば正とするようなチェックをしていた。

また、座席のランダムチェックに関しては、全体でn件以上予約した結果として全体の座席の割り振られた順番が等差数列的になっていないことを確認していた。 こうすることで、単純な ORDER BY RAND()ORDER BY id などに書き換えればFAILさせることができるし、一方でランダムにn個生成した数が等差数列になる確率は許容範囲になるだろうという目論見があった。 n件予約できない場合はもちろんこのチェックは走らないが、このようなことを試すモチベーションは仕様無視して予約処理の高速化を図るチート行為なので、件数が増えたときだけチェックすればよく何ら問題がなかった。

極限までチューニングする上でどのようにプロファイリングするとよいのか

普通にプロファイリングする。のだけど、以下のようなツールを組み合わせてボトルネックを解析してチューニングするのをひたすら繰り返していた。

ボトルネックとその原因を明確につかめるまでは多角的に情報を集めて矛盾の無い判断をするように気をつけていたと思う。 あと、PerlのNYTProfはかなり詳細に出せるので、読み方さえ理解すればすごく強力な武器になった。

あとは理屈上このほうが速いんじゃね?というのを適当にいろいろ試したりするのは予想外の結果になったりして面白く純粋に楽しかった。

そのほか

当たり前だけど、完璧な問題が作れたわけじゃない。課題はたくさん残ったまま予選当日を迎えてしまったし、いくつか初期実装の不備も出してしまった。 それらの点に関しては講評でも触れたとおりだけど反省しかないし申し訳ないと思っている。

その一方で、出題した問題そのものの本質的な問いかけに関しては、自分で言うのもなんだが高い評価をもらえたんじゃないかなと思っている。 おこがましいけど過去イチで面白くやりがいのある問題を作り上げてやろうと(勝手に)思っていて、そう思っていた反面ぜんぜん自信がなかったからずっと不安だったけど、良いフィードバックがたくさんもらえたのは本当に嬉しかったし、ひとに会うたびに無限に褒められが発生したので自信につながった。

あとは、ISUCONの作問は業務時間を使ってやっていたんだけど、仕事としてやる以上は成果を残さなきゃいけないというプレッシャーもあった。 ISUCONに関わる上での成果とはなにかって考えると、やはり良い問題を作るというのが本質的なコミュニティへの貢献だし、それこそが会社や自分自身のプレゼンスの向上への最大の近道だと思ってやっていた。逆にいえば、中途半端な成果にはしないという覚悟をしたからこそ「やります」という声を挙げられた。覚悟だいじ。

今年もいろいろ覚悟を決めて良い変化をちょっとずつ起こしていきたい。

追記

落ち穂拾い != 落ち葉拾い。覚えた。

落穂拾い - Wikipedia

ところでこれ送り仮名つけるのとつけないのどっちが正しいの?

YAPC::Tokyo 2019で「ISUCON8予選問題の裏側」について話します

こんな感じのトークをします:

ISUCONとはIikanjini Speed Up CONtestの略で、アプリケーションからOSレイヤまでなんでもありのWebアプリケーションの総合的な高速化スキルを競うコンテストです。2018年で第8回目の開催となり、参加者数は1000人を超えます。本年度の出題はDeNAとカヤックでした。僕はDeNAのエンジニアの一人としてISUCON8予選の問題作成に携わりました。

ISUCONの問題の提供のためには、参照実装(具体的な問題)の作成、ベンチマーカーの作成、競技を成立させるための最低限の制約であるそしてそれが十分に高速化できることを示すための模範解答の作成が必要です。ISUCON8の予選問題はPerlで最初に参照実装が作成されました。そして、模範解答も実はPerlで作成されています。そして、その参照実装が各言語へ移植されて競技で各言語ごとに様々なチューニングが行われました。

その過程で様々な学びを得ました。たとえば、ISUCONのような競技で気を遣うべきポイントはなにか、どのようにして問題を考えていくと良いのか、どのようにしてブラックボックスとなっているアプリケーションが仕様を満たしているかをテストするとよいのか。極限までチューニングする上でどのようにプロファイリングするとよいのか。他言語移植においてどのようなポイントで問題が起きるのか。などといったものです。

このセッションではISUCON8予選問題の作問の過程から、どのような学びを得たかについて語ります。

あんまりPerlっぽいことは出てこないのでPerl詳しくなくても聞きやすいと思います。 ぜひ聞きに来てください!

個人的注目トークです:

blog.yapcjapan.org

公式見どころ情報です:

blog.yapcjapan.org

明日までにチケットを買えば自由なサイズのTシャツが購入できます。 気になってきた方はこれを見てどうぞ:

blog.yapcjapan.org

CSS初め

このブログのデザインに対して冷静になった結果、どうも背景の主張が強すぎてタイトルとかが読みにくいという思いに至った。 はてなブログはたしかカスタムCSSが書けたはずなので、CSSでなんとかすることにした。

書いたのはこんな感じ:

body:before {
  content: '';
  position: fixed;
  top: -5px;
  left: -5px;
  width: 120vw;
  height: 120vh;
  z-index: -1;
  background: inherit;
  filter: blur(5px) brightness(40%);
}

div#wrapper {
  margin-right: -221px;
}

div#wrapper>* {
  margin-right: 220px;
}

aside#box2 {
  width: 180px;
}

要素名は詳細度を調整して優先されるようにこうした。!important 使え案件な気もする。

背景を暗めにしてぼかす

はてなブログ全部なのかこのデザインのみなのか分からないけれど、背景画像はbodyに設定される。 暗めにするだけならその直下で全部くるんでるdivとかで background-color: rgba(0, 0, 0, .6) とやってやればよいのだが position: absolute な要素があるのでうまく行かなかった。

CSS3 filterを使うことにしたが素直に適用すると背景以外の全体に掛かってしまう。困ってぐぐってみたところこんな記事がヒットした。

kuroeveryday.blogspot.com

最背面に置いた疑似要素に対してやれば良い感じなのねーということで、position: fixed な疑似要素を width: 100vw; height: 100vh; で画面サイズに合わせて最背面に配置するという感じでうまくいった。ついでなのでblurもかけてボカした。ボカしたところ端っこが残ってしまったので top: -5px; left: -5px としつつ width: 120vw; heigth: 120vw としてお茶を濁した。 position: fixed はiPhoneで描画がアレだったきがするけど、どうせデザインはモバイル向けに適用されないので良いでしょう。

サイドバーを広げる

Twitterのフォローボタンがきゅうくつな感じだったので、広げたくなった。

単純にサイドバー #box2 を広げたがうまくいかず、下にコンテンツが回ってしまった。デバッガを眺めていたところ float: left で実装されていてそれで吹っ飛んだことがわかった。 もう少し調べるたところ、どうも#wrapper#wrapper > * への指定がキモらしい。

#box2 には 160px の幅と 20px のmarginが全体に設定されており、横幅は合計で 200px となる。 一方、 #wrapper には margin-right: -201px; という怪しげなネガティブマージン、 #wrapper > * には margin-right: 200px; が設定されていた。 つまり #wrapper のネガティブマージンでサイドバーぶんの余白+1pxを確保して、 #wrapper > * でmarginをもとに戻すことで余白を確保したのだろう。 コーディングの苦労が伺える。いまであればFlexboxでやるのが良さそうだが、当時はこういうハックしかなかったのだろう。実装方法に関心した。

というわけでちょっとこのブログが見やすくなった気がします。

2018年のKPT

昨年度:

techblog.karupas.org

Keep

良かったこと、続けたいこと

YAPC::Okinawaで話した

id:charsbar さんの代打でPerlの最新情報について話せる機会を頂けたので(想定外にスタッフ業が忙しくなってしまったので辛かったけど)charsbarさんの力を借りながらなんとか自分なりに調べてまとめて話した。

大変だけどPerlの最新機能をあれやこれや調べたり試したりできてよかった。これをきっかけにperl-portersを購読しはじめた(あんまり追えてないけど…)

Shibuya.pmをやった

YAPC::OkinawaのKeynoteでid:yappoさんがShibuya.pmに触れて、Shibuya.pmも次の人につないでいくべきだよねという話をしていた。 懇親会でやらないかとなったので、Gotanda.pmと両方やるのは難しいのでこっちを誰かに渡せたらやりますとしたところid:kfly8が快諾してくれたのでそっちは彼に引き継いでShibuya.pmを正式に引き継ぐことになった。そのまま7/5になんとか開催して伝統(?)の引き継ぎの儀もやった。

LTもやった:

speakerdeck.com

いろいろな人の協力もあって、楽しんでもらえてよかった。

ライブやった

ひょんなことで知り合った八王子の居酒屋さんの新年会で年明け早々の1月2日に弾き語りでライブやって、2月,4月とモンズリーズで出演。 11月にはソロで5年ぶりくらいに弾き語りでエンジニアライブに出演。客層わかってたからそこに絞って構成と演出練ったらウケたっぽいので良かった。新曲も作ったのでレコーディングしたい。年明けそうそうに喉の調子がよかったらやる。

ベース教室に通い始めた

自分で練習しているとどうしても自分の手癖っぽい感じに偏りがちだったりするので教室に通い始めた。 指弾きが特に独学過ぎてわからんかったので、フォームの修正から入っていった。リズムに関しても厳しく見て優しく教えてくれてリズム感も鍛えられた。 特にコードの解釈とベースのフレージングの幅が広げられた気がする。TAB符でない普通の楽譜は苦手意識があったんだけど読譜も上達して苦手意識も減ってきた。 何より、定期的にあるとやる気が補充できるという嬉しい効果があったのがよかった。

社の軽音部に加入した

社にいつのまにか軽音部が発足していたので入った。ときどきセッションをしたりするゆるい感じ。 最近はコピーを何曲かガチめにやるぞという取り組みをしていて、普段やらないジャンルの選曲なので難しくて楽しい。

builderscon.tokyo で話した

素人ながらレコーディング/ミキシングのさわりを話した。

speakerdeck.com

割と好評だったようで、フィードバックも良いものがもらえてよかった。 60分でも触りから説明しようとしたら時間的に難しかったので色々端折ったので何かの機会にもうちょっと踏み込んだこと喋りたい。

ISUCON8出題した

がんばった!たのしかった!これ読んで:

isucon.net

各種コミュニティ/社内勉強会で話せた

引き続き各種コミュニティ、社内勉強会で話して交流できたのでよかった。 特にひとでさんの結婚を皮切りに京都方面とのコミュニケーションが厚くなったきがする。楽しいのでもっと入っていきたい。

これは今年公開したるなかで一番好きなスライド:

JPA引き続き活動できた

YAPCの主催以外の諸々など引き続き活動できて、実際いくつか動きがありました。 ここで書くのも適切じゃないので、ほかの機会にまたお知らせできればと思います。

Problem

技術ブログあんま書けなかった

今年の唯一の記事がこれ。

techblog.karupas.org

エイプリルフールだし、ボタンぽちっとだけだし、書いたうちに入らなさそう。

本当はShibuya.pmのやつとかYAPCとかISUCONとかも書きたかったんだけど色々大変なまま時間とれず過ぎ去ってしまった。 このままだと1年を振り返るブログになりつつあるが来年こそは何かしら記録していきたい。

スケジュール調整が厳しい

ベース教室や軽音部を始めたり、社やJPAの仕事の幅が広がったりしたデメリットとして、ただでさえ苦手なスケジュール調整が増えて大変になってしまった。 スケジュール調整を効率的に無心でやるすべを身に着けたい。

karupas.org がぶっ壊れたまま放置してしまった

NuxtとFirebaseで作り直すかとなってるんだけど色々忙しくてほとんど進められてない。

Try

TBD

2017年のK

Keep

良かったこと、続けたいこと。

YAPC::Kansai 2017 OSAKAを主催できた

JPA再編後に実施されているYAPC::JapanはJPAと各地域PMが連携して主催する日本のPerlカンファレンスですが、 3月にやったYAPC::KansaiではJPA側のリーダーとしていろいろやらせてもらいました。 自分なりに出来る範囲で良いカンファレンスには出来たのかなと思う反面、各方面にだいぶ迷惑掛けてしまったなというのもあり、学びが多くありました。 カンファレンスを作る大変さと楽しさを身をもって知れたのはとても良かったです。

興味のあるひとはぜひ1度やってみると良いと思います。大変だけど。 持ち回り製を採用していることもあり、会を重ねる毎に経験者が増えていっているので、バックアップが年々強力になっています。 もし、ちょっとでも興味があればお気軽にご相談ください。

Perl Hackers Hub にまた書かせてもらった

雑誌に書かせてもらうの、プレッシャーすごいし、大変だけど、前回と比較してより良い記事が書けたと思うので、成長が実感できてよかった。

インフラやれた

お仕事で、新しいインフラを作れるチャンスがあったので、頼んでやらせてもらいました。 PaaSが増えてきた昨今だとあまりOSまわりをいじる機会が少なくなりましたが、とあるIaaSを使ってイチからImmutable InfrastructureでAuto Scalingな構成を組んだりできて楽しかったです。キャパシティプランニングや監視設計、負荷試験とかも含めていろいろできて楽しかった。

Perl/Goがっつり書けた

今年もPerlやらGoやらでいろいろお仕事のコードが書けてよかった。 趣味でもぼちぼち書いていたっぽい。あと、YAPC::FukuokaでAnikiのトークもできた。

ワークライフバランスが良かった

給与明細に実労働時間と勤務日数が出ていたので計算してみたところ、慣らすと年間平均で7.8時間/日くらいのペースで労働をしていたらしい。 時間で見る限りは、働きすぎずサボりすぎず、良い塩梅でバランスよく仕事ができていたようだ。

バンドのレコーディング素材のミックス作業をやってた時期とかは月平均で6時間/日くらいだったり、逆に時間に追われてた時期は月平均でも10時間/日になっていたり。とはいえ普段は良いペースで勤務できていたようだ。

もちろん、勤務時間がそのまま成果に直結するわけではないが、少なくとも裁量労働制をうっかり悪用してサボりすぎてないかという心配が解消してほっとした。

バンドが去年より活動できた

レコーディングしてデモCDを配布しました:

前と比較して完全に新しい環境でのMixとなってしまったので比較はできないけど、チャレンジができたこと自体は良かった。 前回と比較すると、一番大きな違いがドラムのレコーディングで、前回バスドラ、スネア、フロア+ライド、アンビエントのモノラル感のつよい4chだったものを、バスドラ、スネア表、スネア裏、ハイハット、ライド(+フロアタム)、ハイタム、ロータム、アンビエントの9chでやったこと。 ミックスの下処理が一気に大変になって大変だったりして、いろいろと反省が多かった。

ライブもできて、池袋Adm、山梨ボデガー東スタジオなどでライブができた。 曲も作ったり、ホームページも作ってそこで予定を公開したりできた:

www.monzllis.info

メンバーの入れ替わりもあり、一歩戻って二歩前進という感じで進んでいきたい。

来年

ソロで活動する機会がなかったので作っていきたい。

WEB+DB Press Vol.101のPerl Hackers HubにAnikiに関する記事を寄稿しました

このブログを読む方にはご存知の人が多いと思いますが、ぼくはAnikiというO/Rマッパを2015年に初めてリリースしました。ふざけた名前ですが実装と機能は真面目です。 イメージとしてはTengを自分なりにブラッシュアップしつつ少し高機能にして拡張性を高めたモノという感じです。 2016年に安定版となる1.00をリリースし、この記事を書いている今現在の最新版は2017/07/20にリリースした1.06になります。

metacpan.org

今の時代にO/Rマッパはとてもありふれており、枯れています。 安定したO/RマッパとしてはPerlだとTengやDBICが挙げられるでしょう。 では、そんな時代にO/Rを新しくつくる意義ってあるの?どうやってつくるの?Anikiはどうなってるの?という疑問は当然湧いてくることでしょう。 その問いに対する自分なりの答えとして「Anikiで学ぶ実践的なO/Rマッパの作り方」というタイトルで書かせて頂きました。

f:id:karupanerura:20171005113240j:plain

サポートサイトからダウンロードできるサンプルコードやAnikiのコードと併せて読んで頂くことでより深く理解することが出来る内容となっていますので、ぜひぜひコードを見ながら読み進めてみてください。 以前書かせて頂いたデータベースプログラミング入門の記事と併せて読んで頂くのも良いかと思います。 gihyo.jp

WEB+DB Press Vol.101は今月10月24日に全国の書店にて発売です。 ほかにも興味深い特集が沢山あるのでぜひぜひお手にとってみてください。

WEB+DB PRESS Vol.101

WEB+DB PRESS Vol.101

  • 作者: 森本利博,武井優己,SPY,久保田祐史,大倉香織,石川雅之,袴田類,山下和彦,牧大輔,穴井宏幸,加藤隆一郎,加藤佑典,金昌熙,佐藤健太,のざきひろふみ,うらがみ,久田真寛,ひげぽん,池田拓司,はまちや2,竹原,牟田裕太郎,粕谷大輔,陶山嶺,長谷川智希,石田和太郎,小林純一,WEB+DB PRESS編集部
  • 出版社/メーカー: 技術評論社
  • 発売日: 2017/10/24
  • メディア: 大型本
  • この商品を含むブログを見る

謝辞

編集を担当して頂いた技術評論社の稲尾さんをはじめ、直接監修頂いた牧さん、同僚やバンドメンバーなど各方面の関係者の方々にも様々な面で協力してもらい助けて頂きました。この場を借りて改めて御礼申し上げます。ありがとうございました。

宣伝

来年の3/3にYAPC::Okinawa 2018 ONNASONが開催されます。 現在スポンサーメニューのみ公開されていますが続々と新情報が公開される予定ですのでウォッチ頂けると幸いです。 90日以上前であれば航空券も高くはないので是非是非ご検討ください。長めに宿を取って観光や食も楽しんでもらえると良いかと思います。

yapcjapan.org

Aniki関連スライド情報

Anikiに関してはこれらも参考になるかもしれません。

www.slideshare.net

www.slideshare.net

speakerdeck.com

www.slideshare.net