chigichan24のお気持ち表明

おきもちを表明している

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

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

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

本番まで

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

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

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

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

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

当日

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

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

レポジトリ

issueタイトルの癖が強い f:id:chigichan24:20200913210204p:plain

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前後.結構スコアが揺れる.
  • searchEstatessearchEstateNazotteがしんどそうということが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を真面目にいじって改善しても良かったんだけど,それを吟味する余裕がなかった.
  • searchEstatesNazotten+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)を捌く君

スコア遷移

f:id:chigichan24:20200913205702p:plain
スコア遷移図

使った言語・ツール

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

所感

  • 学生枠があったおかげでスコア的にはそこまで良くないが本選にいけます.嬉しい.
  • 職人の勘ではなく計測の結果ベースで改善→再計測のサイクルで動くようにできてよかった.
    • 昔であれば初手で気になってしまってfeaturesの正規形壊れているやつを直しに行ったり,凸包の部分を実装しに行ったりしてたので(多分)
  • 壊れたらすぐrevertして,fail状態を長くしないをできた.
  • 情報共有が下手くそだった.え,そこにN+1あったの知ってたよみたいなやつの情報共有漏れとか,estatechairのテーブル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でも何らかの形で関わりたいと思います!!!!

CyberAgentのインターンシップに参加した話

みなさんごきげんよう.chigichan24です.


今日はCyberAgentでの就業形インターンシップに参加したことを書こうと思います.

受けるまで

実は遠い昔,一度インターンシップの選考を受けたときお祈り🙏🙏🙏🙏を頂きました.それもあって風土と自分の思考・思想が異なるんじゃないかとそこそこ渋りましたが,やっぱり気になっていたので受けてみました.

実際に選考に通るまでの流れは以下の感じです.コーディングテストとかはなかったんですが,私のGitHubにpublicで上げてるコードは見られてたっぽい(ぽい).

書類審査📝
  • 書類を書きました.
  • まじで記憶にありませんが,開発経験とかインターンの経験を書いた気もします.書けそうなネタが人より少ないタイプの人間(コンテスト入賞とかがない)でしたが,それとなく書きました.
  • GitHubアイコンはもちろんあれで出しました.

github.com

一次面接🤓
  • 人事の方とお話しました.The 面接みたいな堅い感じではなかったです.
  • 設計(アーキテクチャ)とかを意識したサムシングを勉強したいです.と言いました.
  • どういうものを作りたいのかの具体性がないのでどの部署を勧めていいかわからない」とクリティカルにありがたい指摘を頂いたので,まあ落ちたのだろうと思いました.
  • 技術面談かと思ってたので,これは見当違いなことを口走ったなと思いました.
二次面接🧐
  • ありがたいことにある部署を勧めてもらいました.完全に落ちたと思ったのでビッくらポンでした.
  • ここでは楽しく会話をした記憶しかないです.現役エンジニアと話すのは面接とはいえめちゃくちゃ楽しいものです.
  • Kotlin coroutinesとReactive Xのpros and consについて話したり,DroidKaigi2019のFluxアーキテクチャの話やAndroid設計本のことを話したりしました.
  • 面接ではなく完全に雑談の会でした.
  • 雑談中に,来てほしい的な発言があって,行くことが確定しました(?)

働いてみた

AbemaTVのAndroidエンジニアとしてのインターンを受け入れてもらえました🎉🎉🎉 SNSやブログ上で知っている人が存在していて,おもろかったです(何様)

実はインターンの期間はもともと一ヶ月の予定でしたが,楽しかったしリリースまでいたいという思いが高まったので二ヶ月お世話になりました.

やったこと

走っていた新機能開発のプロジェクトにぽんと突っ込まれました.ここにタスクがまとまっているから自分をassignしてPR出してみたいな感じで雑にタスクが降ってきました.そこそこ不安がっていましたが,実際にはPR上で丁寧にレビューをしていただき私の理解度に合わせて適切な粒度で方針を示してもらいめちゃくちゃ良かったです.takahiromさんは神.


基本的にはコードを書いてPRを出すという感じのスタイルだったのですが,不明瞭な点について,別のチームの人やデザイナーさん等と話すということをしたり,チームの人が出したPRに対してレビューをしたりと社員さんとほとんど対等みたいな感じで働かせていただけたのは非常にやりやすかったです.

書いたコードのジャンル(?)も多種多様で,

  • ロジックっぽい部分.
  • UIに近い部分.
  • Kotlin化
  • バグ修正

等,AbemaTV-Androidのいろんなところに手を出させていただきました.

最終日に何気なくみてみたら,合計で30個くらいのPRを出していました.当然各PRの重さはバラバラなので単純に個数で計測することに意味はないんですが,「おおーっ」となりました.

そのほか
  • CA.apkというイベントや,社内で行われていたLT会での発表の機会をいただきました.タイミング的に,両者ともたまたまという感じだったんですが,機会提供をしてもらえて嬉しかったです.

cyberagent.connpass.com

  • AbemaTVの番組を実際に作っているスタジオの見学に行きました.コンテンツを提供する側での現場を見れて面白かったです.
  • 引っ越しを経験しました.会社の引っ越しの経験なんてそうそうすることないので,良かったです.てっきり自分の荷物は自分で運べみたいな感じかと思っていましたが,そんなことはなくて,普通に業者さんが運んでくれました(それはそう)

www.cyberagent.co.jp

感じた

いくつかの企業でこれまでもインターンシップをした事があったのですが,そのどこにもなかった(いい意味での)異質さがCyberAgentにはありました.

それは速度感規模感を両立しているところでした.ものすごいスピードで開発を進めつつ,その市場の規模をどんどん拡大していく姿は2ヶ月しかいなかったインターン生でもものすごく感じました.


また,いろんなチームがこだわりチーム観を持って仕事をしているなとも思いました.デザインではこのように表現したいけど,クライアントにとってそれを実現するのはものすごく工数がかかる問題をどうしようというケースがあります.そのときに「ここは妥協したくない」というデザイナーさんの意見と,「ここはこういうふうに実装したい」というクライアントチームの声が毎度いい改善案(解決策)を生み出していて,すごいと思いました(小並感) .

反省点

私の考えていることが基本的に浅はかで,それちゃんと考えてるの?というPRを出してしまったことがいくつかありました.

  • 動くは動くけど,それでいいのか?という部分をもっと深く追う必要があり,なにがどのように動くのかをもっと意識する必要があるなあと改めて感じました.
  • 例えば,AOSPでのコードをちゃんと参照して問題ないということを示されたりしたので,Androidそのものがどのようなコードで書かれているかを深めたいです.


コードを書く速度が社員さんと比べて遅い.

  • ドメイン知識がないだけだとはじめは思っていましたが,明らかに遅い.
  • ある機能を追加したいときに何をどこに,どう書くかを高速にイメージする訓練をしたいです.そのためにはもっともっと引き出しを増やす必要があると深く痛感しました.

おわりに

インターンに参加したときに裏テーマとして,「人日計算の頭数に入れられるくらい一人前のエンジニアとして力になりたい」というのがありました.これを最終日に打ち明けたら,それは初日から達成していたよ(?)と言われたときはめちゃくちゃ嬉しかったです.

すごくいい環境で働かせてもらえて,CyberAgent(というかAbemaTV)の雰囲気を感じ取ることができ,また自分の技術力の向上も得られたので本当に良かったです.もっと精進します.

どうでもいいこと

渋谷のランチ事情に詳しくなった.