ISUCON10-finalに参加しました ~ありがとうまたあいま賞~

ISUCON10-finalに予選と同じくk5342とPelkiraと共に参加しました．途中の順位highestは5位くらいまで上がっていた気がしますが，最終的には18 / 22位．failのチームも含めると18 / 33位でした． highestは15:43に記録した12835で，最後は11077でフィニッシュしました．

スコアが付いた中では下から5番目で，LINEさんから”またあいま賞”といういい感じの賞を貰えるみたいです．LINEさん大好き．

またあいま賞

とはいえシステムがfailするのはxsuconとしても問題ありなので，重くても動いている方が偉い(?)．最後の試験failしなくてよかった〜

k5さんも本選の様子をふりかえっているので，ちゃんとした内容を読みたい人はこちらへ．

k5342.hatenablog.com

前日まで

• あまり忙しくて例のごとく練習する時間はほとんど取れなかった．しゅうろん♡を控える大学院生は忙しいのだ．
• 予選が終わった & 本戦出場が決まったときに，各々の役割をもう一度考え直して，以下のようにすることとしました．
  • Pelkira先生 : 上がっているIssueからどれを取捨選択するか，実装者のタイムマネジメント，clarの情報共有といったオペレーション周り，意見を吸い上げて困ったときの道筋の最終判断者
  • k5さん : 計測・実装
  • わたし : 椅子あたため係 (計測・実装)
• 練習では上記役割での初動確認及び，秘伝のタレやいい感じにするスクリプトをまとめたMakefileを作ってました．後にこのMakefileが火を吹くことになりました．k5さん天才か？

当日

• 色々仕事が舞い込んできて朝6時くらいまで眠れなかった．終わり．
• ポストイットを買って会場入りする．
• 例のごとく人が何やってたかあんまり覚えてない．

レポジトリ

github.com

個人的にはこのIssueがすき．Pelkiraくんのマネージ力．

説明フェーズ (9:30 - 10:00)

• いつもの導入動画．xsuconの改善が必要になる．毎秒isuconしろ．
• 非常にメタ的だなぁと思った．

序盤 (10:00 - 13:00)

• sshする．
• とりあえず，localでもどんなWebアプリケーションなのかを確認する．
• レギュレーションを読む．
  • web pushは実装する必要あるかなぁと思いつつクリティカルに問題になりそうならやるかぐらいの気持ちでいた．
  • 埋め込まれている定数(TeamCapacity)を変更することによって，トレンドが変化しそうということを把握する．
• DBのスキーマを調べたり，構成要素を調べたり，秘伝のタレ(my.cnf)を微妙に修正しながら流し込んだりする．
  • テーブルに入るitemのオーダーはどこから改善するかの指標にもつながるので，注意してみたほうがいいのだ．
  • slowquery出てこないなと思ったら，slow_query_log = ONの箇所がコメントアウトされていてウケた．
• pprofを仕込んだりする．
• git pushしていたら，サーバーが壊れるなどしたので，伝家の宝刀本番サーバに~/chigiを作って開発するのをやめて，localに開発環境を作る．
  • ついでに，不必要に管理してたruby，nodejs，frontendといったディレクトリをgit管理下から外す．
  • frontendがそこそこデカかったから，static fileのcacheをenvoyに挟めばよかったなぁって今記事を書いていて思った．
• クソデカ・クエリが支配的だったので，とりあえずindexを貼ってみる．

中盤 (13:00 - 16:00)

• 全然スコアがのびない．よく見るとインデックスの貼り漏れがあるので修正
• ついでに，PelkiraからTeamCapacityを上げてみてはどうか？という話があったので，上げてみる．
  • スコアが10000位になる．
• この結果トレンドが変化し，ボトルネックが移った．
  • k5さんが行ロック周りをいい感じにできないかしている間に，私は，コードでsleepしてretryしている部分をアドホックに修正したりしていた．
  • 変化したトレンドの中にN+1もいくつか上がってきていたので，一つを担当して修正，何事もなく変更ができたと思っていた*1
• INSERTが厳しいと話していたので，capacityを上げたり，writeのスレッドを増やしたりした．
• この辺を調査して適当しているときに，実はindexがはられていなかったことに気がつく．
  • 悲しい．
  • schema.sqlがあるしどっかで呼ばれているやろみたいな適当な発言をしてしまったので，ごめんなさい．
• 修正するとスコアは12000位．その時の順位は10位以内に，学生枠では1とか2位だったので嬉しかった．ここで競技終了になればよかったんや(?)

タスクとタイムマネジメントをいい感じにしてくれるPelkiraくんの作業場

終盤 (16:00 - 18:00)

• notification周りがずっと変な感じがしていて，ERR: validation: critical: invalid-response: あるべき通知を受信していないことが検知されましたがでて確率的にfailするようになってきていた．
• failというのは非常に心臓に悪く，順位がつかないのでこれは解決しなければという感じなっていました．
• TeamCapacityやlock_waitの値をごちゃごちゃいじることで落ちないようにすることはできたけれど本質的になぜこうなるのかわからない状態でした．
• この問題を解決しないと最悪スコアが0になるなと思っていたと同時に，依然としてクソデカ・クエリのDB負荷がしんどくこれにはキャッシュの実装が確実に必要だなあとなっていました．どっちをとるかという選択を迫られ，結果的に二兎を追うこととしました．
  • 私はランダムfail問題を解決することを目指して実装を進めました．一部のトランザクションのはられ方が悪く，データ不整合を起こしているのでは？と思い実装しましたが結果的にそれは改善には繋がりませんでした．諦めて，値をチューニングすることで，一旦ある程度はfailしない状態にしました．
  • 一方k5さんはキャッシュの実装をやってくれました．ごりごり実装を進めてくれてベンチに入れると，スコアはぐんぐん伸びて18000を記録していましたがfailの文字が．うーん悔しさがそこにはありました．
• ギリギリまで粘って実装バグを探すk5さんの横で，いつでも再起動(sudo reboot)できるようにログ周りを全て切って回りました．
• ギリギリまでk5さんの実装を見ていましたがある程度のところで見切りを付けて再起動試験をはじめました．あのときのk5さんの悔しそうな表情がすごく脳裏に焼き付いています．この時すでに残り15分，もともと1時間は再起動試験に時間をとりたいと考えていた私達にとっては緊張感のある時間となっていました．
• rebootでベンチが安定して通る(当社比)ところを見た後に最後にTeamCapacityの値を上げて少しでもlatestの数字を上げることにしました．しかし，自分のチューニングした値からすこしでもずらすとすぐに0となったため，すぐに戻しました．この15分の間はずっと本番サーバで直接masterをいじっていたので，非常に怖かったです．

緊迫したベンチ画面

• 残り2分，latestのスコアはチューニングに失敗した値である4281の数字，ベンチは回せてラスト一回，悔しさと次のベンチでfailしたらチームのみんなに申し訳ないという気持ち，もっと自分ができたことがたくさんあったなと8時間が走馬灯のように駆け巡る中「ベンチを入れて」とk5さんにお願いしました．結果は18時が過ぎた時間に11077が出てきました．ひとまずfailじゃなかったことへの安堵でいっぱいでした．

その後 (18:00 - )

• Pelkiraくんはその後に予定があったため帰宅，私とk5さんは時間に余裕があったので，本選通過者に送られた出前館のクーポンでご飯を頼みました．ありがとうございます．
• 下から5位のチームに贈られる賞の枠で発表され，無事にその後のチェックもfailせずに通過したことを知りました．
• 学生が1, 2, 3位フィニッシュだったことに衝撃を受けると同時に，自分の不甲斐なさを実感していました．

最後に

• 楽しい問題をいつも提供してくださるISUCONの運営の方々には感謝です．これが毎年あるおかげで強くなっていることを実感します．
• 初めて本選に行ったのはISUCON6，このときはなんにもわからず，@orisanoと@imishinistに連れて行ってもらっただけで，真の意味で椅子を温めていました．
• 初めて自分の知識を多少生かして，編入同期である@k5342と@euglena1215と本選に進んだISUCON7では，本選問題の何のボトルネックもわからずに懇親会ではこの人達は一体何を話しているんだ？状態で放心状態でした．
• そして，久々の本選である今回のISUCON10では過去とは比較にならないくらい色々できました．感想戦で出てきた話題も「あ〜わかるわかる」，「あ〜頭良すぎか」みたいな状態になれていました．ただ，勝てなかったこと，学生として最後に*2参加するISUCONでもっといいフィニッシュをしたかったなぁと後悔も多くあります．
• そういう意味では「またあいま賞」という素敵な賞をもらえて，また頑張ろうと強く思いました．絶対本選にまた帰ってくるからな．そのときは皆さん対戦よろしくおねがいします．

かっこいいネームカード

*1:後に，実はその修正は間違っていた上にスコアにあまり寄与しないことがわかった．悲しい．

*2:修論はちゃんと出して絶対卒業するぞ

ISUCON10に参加しました 〜ありがとう学生枠〜

チーム「いすこんがさき、しゅうろんはあと 」で　@k5342, @Pelkiraと参加して学生枠4で予選を通過しました．スコアはhighestで1359, latestが1301でした．

頼むからチーム三人の指導教員はこのチーム名に目をつぶってくれ． 修論が先，えぇ研究が先ですよね分かっておりますよ( )．何なら「修論は後」じゃなくて「修論はあと(ハート)」．修論大好き．

本番まで

全然時間が取れなくて2回しか練習できませんでした．1回目は試してみたいツールの確認や初動の確認を，ISUCON9-qualの講評を追いながらやってみました．

2回目は ISUCON8-qualを実践的にやってみて練習しました．

練習はDiscordでやったのですが，ずっとVCをつないで画面共有をしていると思いの外なんとかなるなぁという結論に至りました．とはいえ，

• ISUCONのあのわちゃわちゃした感じはオフラインでしか体現できない(し，私はそれが好きだ)
• 発言したときの表情とかが見えない故，緊迫した空気だと認識の齟齬が発生しそう

だなぁと思って，雨が降ってなかったら感染対策を十分にした上で家に集まるということにしました．(雨に濡れないのは，オフラインで集まる価値より大きい)

当日

雨が降っていなかったので集まりました．ありがとう雲．

自分のタスクは割と鮮明に覚えているのですが，人が何やっていたかの詳細は把握していないです(信頼しているので)．なので，チームメンバがやったことの詳細のログが少ない...

レポジトリ

issueタイトルの癖が強い

github.com

序盤 (12:20 - 15:00)

• \ 502 BadGateway /．運営さんがリアルISUCONをしていた．負けないで．頑張ってくれ．そりゃ500チームも一気にリクエストきたらportalも落ちるわ．
• 準備していたconfigをスルスルっと書き変えてとりあえずインスタンスに入れた．VSCodeからも入れてハッピー．
• git化してGitHubに上げたり(k5)，必要なツールを入れたり(chigi)，レギュレーションを細部まで読んでアプリケーションの概要把握をしたり(Pelkira)をした
• benchが30分くらい回せなくて初回のpprofとかkataribeとかができなかったので，なぞって検索すげーって遊んでた (chigi)
• benchがやっと回せるようになって初回は450前後．結構スコアが揺れる．
• searchEstatesとsearchEstateNazotteがしんどそうということがpprofからわかったのでそこを見る (chigi)
  • 両者INDEXが全然なかったので適当にWHEREに入っているものとか，order byしているやつにINDEXをふったりした．
  • searchEstatesNazotte
    • N+1がおるなぁとなった．
    • それ以前にループが無駄に回っていたので，適当に修正した．
    • 凸包がSQLにあるのしらんくてわろてた．ここ再実装してもいいけどまあ後回しでいいかとなった．
  • searchEstates
    • これは変なコードはあんまりなかったけどfeaturesが正規化されていなくてデータが入っているカラムに対してLIKEが走っていてヤバそうってなった．
    • とはいえslow-queryには出てこないので，放置した．
    • むしろJSONのencodeとかに時間がかかっていて ?? という気持ちになった
  • この辺をやってスコアは580 -600位 だった
• 並行してk5さんが503返していいUAはそもそもどれくらいアクセスが来ているのかを調べていました
  • サブタスクとしてkataribeをaggregationしたりしていた気がする
  • 数が少ないならやる意味はないので．

中盤 (15:00 - 18:00)

• slow-queryを見ると異常にORするやつ遅いなってなってたので，これサクッと直せそうだしといって直したら壊れた．(chigi)
  • その後も無駄にここに時間を溶かした上に，本番に入らなかったので反省
  • よくよく考えると縦・横・奥行きのうち短い2つだけで判定すればよかったので，悪手だったなぁと反省
• chairsのtableに対するクエリが遅いので，INDEXを張ったりした． (chigi)
• slow-queryが吠えているけどpprofではあんまり出てきてないやつらどうしようかなぁと実装みてたけど，結局手つかず (chigi)
• nginxで特定UAからのリクエストをすべて503返すのが出来上がっていた ．
• この辺を入れてスコアは850 - 900位

終盤 (18:00 - 20:30)

• 外が暗くなっていて電気をつけたら明るくなった．文明開化．
• dbのcpu負荷がまあまぁあったので，別インスタンス(instance2)に切り出し (chigi)
  • 練習してたのに，そこそこ手間取ったので反省
  • bind-address = 127.0.0.1をコメントアウトし忘れるのをやりすぎ．
  • my.cnfを調整したけど効いたかは不明
  • cpu負荷が大体ずっと100%で高いなぁとなった(がそれに対する手法が浮かばなかった)
  • cnfを真面目にいじって改善しても良かったんだけど，それを吟味する余裕がなかった．
• searchEstatesNazotteのn+1をk5さんが直してた．
  • ほとんどバグることなくいけてた．
• pprofを見るとやっぱりJSONのencodeがつらそうだったので，アプリケーションの一部を別インスタンス(instance3)を見に行くようにする (chigi, k5)
  • instance3のセットアップ(コードを持ってきたり，dbはinstance2を見に行くようにしたり) (chigi)
  • nginxでいくつかのパスをinstance3に流すようにしていた．
• この辺N+1を直すのとDBの切り出しがほぼ同時にmasterに入ってスコアが1200位，アプリケーションの一部を切り出して1350位

最終盤 (20:30 - 21:00)

• いらないサービスをdisableして回る．
• ログを切って回る．
• 再起動試験をして，動くことを確認する．
• 最後は何回かenqueueして1300を超えたところで止める．

最終構成

• instance1 : nginx(ここで最初のリクエストを受ける) + application リクエストを捌く君
• instance2 : db
• instance3 : application (/api/estate/nazotte, /api/estate/low_priced, /api/chair/low_priced, /api/estate/search)を捌く君

スコア遷移

スコア遷移図

使った言語・ツール

• Golang
  • ここ数年はRubyで出ていましたが，個人的にGolangのほうが手戻り少なく書けるので今年はGolangでGoだぜって祈ってたら祈りが通じた．
• pprof
  • コードに適当に埋め込むだけでいい感じにアプリケーションレベルの辛いところが可視化される．
  • frameで見るとすごくいい感じに分かる．
• kataribe
  • nginxのログを整形して見やすくする．
• querydigest
  • slow-queryをいい感じに可視化する．
• newrelic
  • せっかくもらったのに使う練習できなくて使わなかった．許してください．
• VSCode Remote
  • GUIがsshできると謎のテクノロジー感があって感動する．
  • 私達のチームは本番環境でディレクトリだけ切って作業するため．
• Sequel pro
  • GUIでポチポチしたらいい感じになって好き．GRANTとか雑に変更できて好き．

所感

• 学生枠があったおかげでスコア的にはそこまで良くないが本選にいけます．嬉しい．
• 職人の勘ではなく計測の結果ベースで改善→再計測のサイクルで動くようにできてよかった．
  • 昔であれば初手で気になってしまってfeaturesの正規形壊れているやつを直しに行ったり，凸包の部分を実装しに行ったりしてたので(多分)
• 壊れたらすぐrevertして，fail状態を長くしないをできた．

• 情報共有が下手くそだった．え，そこにN+1あったの知ってたよみたいなやつの情報共有漏れとか，estateとchairのテーブルjoinしてないからテーブルでインスタンスを分けられそうだったよ情報が，競技終了後に知ってあぁ〜となった．

• 課題を洗い出して本選は頑張りたいです．これまで参加した本選は，全く歯が立たずに惨敗しているので流石に3回目の本選は爪痕を残したい．

個人的なやつ

• k5さんとPelkira大先生がだいたいいい感じにやってくれたので椅子を温める・バグを埋め込むなどの作業に徹することができた．
• プログラミングが下手くそなのでプログラミングを勉強しておきたい．
• 学生最後(予定)("""修論""")なので，勝ちに行くは意識しつつも楽しくやりたい．

DroidKaigi2020での発表スライドの補足と雑記

はじめに

本当に残念なことに，DroidKaigi2020は中止となってしまいました．とても残念でしたが昨今の事情を考えればこの判断は適切なものだったと思います．

medium.com

さて，DroidKaigi2020は中止となってしまったが，せっかく作りかけていた資料だし作りきって公開しようと思います．

もともと私のセッションはJA・EN(同時通訳)対象のものになっており，スライドは英語のものが求められておりますが，一旦は日本語のものだけを公開します英訳が本当に進みませんでしたごめんなさい．もうちょっと時間をかけてゆっくり英訳します．

このブログではスライドだけでは伝わらないかもしれない細かい部分の補足を前半に，後半は僕とDroidKaigiの雑談を書いていこうと思います．

スライド

speakerdeck.com

内容補足

以下の補足内容を先に読んでからスライドの方を見る，あるいは並行しながら見ると分かりやすいかと思います．

背景

このスライドは Wantedly, Inc. さんでのインターンシップでの経験をもとに作成しました．実際に私がマルチモジュール化を進めている裏で機能開発/改善は進められており，どういうふうに進めればこの2つは共存できるのだろうという疑問からこの内容で発表することにしました．

単にモジュールを切り分ければ良い，Dagger2でいい感じに配れば良いというような玄人向けではなく，自分自身やってみたけどうまくいかなかったことや断片的には資料はあるがまとまって一つの資料となっていないという問題を解決したいという思いもありました．そのため，本質的にはマルチモジュール化とは関連無いが周辺知識としては必要だよね🤓🤓という内容も盛り込んでいます．

内容の具体性

全体的に薄く広く書くことを意識しました．具体性の高いソースコードを多用するよりもテクニックとしてこのようなものがあるよ！こういうものは手段として有効だよという方針で全体を通して書き進めています． こうしたのにはいくつかの理由があります．

• 個別すぎる事例はプロダクトの性質やチームの方針によって変わるものだと考えているから
• 具体的すぎるコードは共感を呼びにくいから(抽象度が高いと各事例に応用しやすいと考えたから)

例えば，どんな基準でモジュール分けを行うのがいいのかという内容等は省く決断をしました．これはプロダクトの性質や当然チームの方針で粒度が変化するものだと思っているからです．

読者のターゲット

• アプリのモジュール化に興味がある人
• モジュール化の「手順」に興味がある人
• 継続的に機能開発・改善を進めながらモジュール化することに興味がある人

これらの人々に対して，「抽象的すぎてなにを言いたいのかわからないと，具体的すぎてうちの事例には当てはまることがなさそうの中間」を狙って書きました．スライドで示したことを全て用いるということは無いと思いますが，部分部分そのエッセンスを取り入れていただけたら嬉しいです．

第0章 (pp. 1 - 12)

第0章 はOutlineの紹介です．加えて，各章の関係性を示しています．1章はモジュール化導入の価値について，2章から5章までが私が設定したトピックごとのモジュール化に関するテクニックについてで，6章がまとめの章のような流れとなっています．

第1章 (pp. 13 - 37)

第1章はモジュール化導入の価値について語っている章です．はじめにモジュール化とはApplicationモジュールとLibraryモジュールに分けられる(他にもいくつかあるがここでは大きくこの2つとしている)ということと，それらの性質を示しています．その後に3つの観点から導入の利点を示しています． 特に3つ目の循環参照をコンパイル時に縛ることができるというのは，個人的に大きな利点だと考えています．明確なアーキテクチャの元呼び出しのルールを決めていればその必要はないかもしれません．しかしながら，機械的に縛ることができるのは，気が付かないうちに間違ったことをしてしまわないためにもその意義は大きいと思います．

第2章 (pp. 38 - 69)

第2章はこれまで:appのモジュールで記述されていた殆どの処理を:legacyへと移すことをはじめの一歩としようと提案している章です．なぜ:legacyとして切り出すのかを始めに示した後に，ApplicationモジュールとLibraryモジュールの相違から生じるコンパイルエラーについて話しています．ここでは個別の事例を2つ紹介していますが，後半の話が大きいです．ここで伝えたいことは言語やAndroidAPIの仕様・背景を知ることの重要性です．実際にこの処理を行ったときはもっと多くの問題点が出ましたが，そのいずれの問題点にも言えることです．

AndroidDevelopersには，apply plugin: 'com.android.library'とすればそれはLibraryモジュールとして扱うことができます✌のような記述しかありません．しかし，そこには初心者には大きな行間があることを意識してほしいというのがこの章を設定した狙いです(自戒)．スライド中では明記し損ねていますが，settings.gradleにモジュールを追加することなども忘れないようにしましょう．

第3章 (pp. 70 - 107)

第3章は，モジュールを追加するということを主体にbuild.gradle周辺で起きる問題について話している章です．複数のモジュールになることで起きる問題に着眼点を置いています．複数のモジュールで共通の値やリソース的なものを扱うにはどうしたらいいかという例としてBuildConfigを用いています．

また，モジュールをimplementationでつなぐか，apiでつなぐかと単一モジュールで扱っていると深く考えないものについても基礎的な範囲を網羅しています(compileOnly等他にもありますがそれはおいおい)．このimplementation or api問題はモジュール間の制約の強さに関わるものです．すべてをapiにしてしまっては制約を強くするというモジュール化の恩恵を大きく受けられない問題もあるのでここで触れました．

第4章 (pp. 108 - 141)

第4章は，モジュール化を行っていく上でリファクタリング的操作が必要なケースとその対処法について示している章です．この章は特に特定のアーキテクチャに則らずに開発が進められているケース等で大きく役に立つことが予想されます．ここではDIPを主眼に置いてその威力を示しています．ここではDIPを示しましたが，Strategy Pattern等でも同じような効果をもたらすことが可能です．また，ここでは深く書きませんでしたが，BaseActivityのようなものも障壁になるケースが多いため，そこに書かれている処理を適切な箇所に処理を移動させる必要があります．

実際に作業を進めるとこの章に該当することが作業の大多数を占めます．マルチモジュール化はリファクタリングとしての作業の色が強いと感じています．ここで示したようなDIPを駆使する，あるいは筋力💪で解決する等地道にやっていく必要があります．

第5章 (pp. 142 - 162)

第5章は，マルチモジュール化とJetPackとの組み合わせのうち，効用の高いものとしてNavigation Componentを紹介している章です．誤解をしてほしくないのは，例えばLiveDataやViewModel，Roomと言ったものがモジュール化と相性が悪いと言いたいわけではありません．むしろここで上げたようなものはマルチモジュール化する・しないに関わらず近代のAndroidアプリケーション開発では多くの場合強力な武器となります．この章で示したいのは，Navigatoin Componentの遷移の仕組みはモジュール化での遷移の仕組み上でも実践できますということです．

ここでは，詳細の実装に踏み入って話が脱線しそうだったので，Nested NavGraphという概念(NavGraphを複数のxmlに分け，適宜<include />できる仕組み)を示し，これを活用することで，各モジュール間での遷移もNavigation Componentを経由させる事ができることを示しています．具体的な遷移手法についてはスライドでは割愛しましたが，モジュール間をDeepLinkで遷移する方法等があります．

加えて，この方法を取ると部分的なモジュールにNavigationを導入するということも可能であるため，段階的に導入することができます．

第6章 (pp. 163 - 192)

第6章は，タイトルの回収です．継続的に機能開発を進めながらマルチモジュール化するにはどうしていくのがいいのか，私のなかでの方針を書いています．基本的には2から5章で示したテクニックやtipsを駆使しながら進めるといいという流れです．:legacyというモジュールに切り出す作業(第2章)さえ済んでいれば，急ぎの機能開発は:legacyにて行えばこれまでと全く同じ開発体験を提供できるというのがポイントです．

その上で，

• 下のレイヤーからモジュール分割を行うこと
• 新たなモジュールは:legacyへの依存を持たないようにすること

を意識することで，継続的に機能開発を進めながら，モジュール化を行うことができます．この手順の2つはチームでのコミュニケーションが大切です．しっかりとコミュニケーションをとりながらやっていくことが大切だと考えています．

感謝

@wakwak3125 さんには感謝しか無いです．こんな大きなことを任せてもらえてとっても勉強になりました．また，この作業の過程で多くのアドバイスをくださった @swiz_ard さん，@MalvinSutanto さん，インターンの機会をくれたCTOの @kawasy さんや人事の @amanda__mt さんにも感謝です．

雑記

DroidKaigiの存在を初めて知ったのはDroidKaigi2017のハッシュタグのついたtweet(確か@e10dokup)を見たことでした．こんな面白いイベント絶対に翌年は参加したいと思った記憶があります．

大きな期待を胸に参加したのはDroidKaigi2018でした．この年はアプリのコントリビュートも頑張りました．twitter上でしか見たことのないようなレジェンドな方々にPRをレビューされて震えていました．期待を大きく超えた胸の高鳴る多くのセッションを聞いてアプリ開発欲が爆発しました．また，こんなふうに登壇という形でDroidKaigiに関わることへの憧れも大きくなり，絶対に数年のうちに一度は登壇してやる！！と強い気持ちを持ったのを今でも覚えています．

DroidKaigi2019は卒研発表と日程が被って本気で卒業をとるかDroidKaigiを取るか悩みましたが泣きながら卒研発表を選びました．

そして，DroidKaigi2020では運良くスピーカーとして選ばれたのはすごく嬉しかったです．

こうやって振り返ってみると，DroidKaigiによって私のAndroid開発の知見やモチベーションはドライブされていたなと痛感します．そういうコミュニティを作ってくれる運営の方々への感謝を忘れずに，次のDroidKaigiでも何らかの形で関わりたいと思います！！！！