git challengeに参加しました！
こんばんは．chigichan24です！先日 git challengeというものに参加したのでそのレポートをします！！！
Git Challengeとは？
この記事を斜め読みすると下のような文言が出てきました．
gitリポジトリに設けた難題をチームワークで解決していく競技型技術イベント
なるほど．個人的には，
Gitを使っていた時にやらかし太郎してしまった．けど，あなたならどうする？？？をコンテスト化したもの
というイメージです．
このイベントをやっているのはmixiさんだけ！ mixiさん大好き♥♥
参加する前に
- このイベントは一度しか出ることができない！ということもあり，数年前から出たかったが†Git力†に自信がなかったので躊躇してた．
- が，いつ学生という身分から迫害されるかわからなかったので(?)出ることにした．
- 参加する前には，応募要項として，過去の開発経験とか，あなたのGitエピソードみたいなのを書いて応募すると，抽選された．
- これはオフレコなのですが，熱い想いを書き殴っていたら文字上限を超えてしまいそれに気が付かず提出ボタンをおしたら書いた内容が消えて，1度萎えたという事件がありました．
- なので，皆さんは一度どこかにファイルとして保存しておいてそれをコピペするのをおすすめします．
- 抽選に見事に当たり，参加が確定する．わーい．
当日
お話させていただいて，大変光栄です． https://t.co/ulu7gCMmha
— プリキュア (@chigichan24) September 8, 2018
競技前
競技開始！
- 難易度が★ ~ ★×5 まであって，チーム戦だったのにペアの人に雑に問題を振ってしまい(申し訳ねぇ)，自分は得点が高めなものから見始めてました．
- 適当にやったら得点にならなかったので焦って前からちゃんと解き始めました．
- 問題は現実でも { 遭遇したことある | 遭遇しそう }なものから，こんなことできるんだ！みたいな気付きが多い問題まで多種多様で問題を解きながらもかなり学びが多かったです．
各チーム着実に解答が進んでいるようです。解答をリセットしてくれる「リセットセンター」には今回4つの異なる音の出るボタンをご用意しております。まだあまりリセットの依頼をされるチームは少ないようです。 #mixi_git pic.twitter.com/TDgdHwKtzM
— ミクシィグループ 新卒採用公式アカウント (@HR_mixi) September 8, 2018
- このボタンを4つ同時に押して運営を煽るなど(????)，場を和ませるムーブをしました．
- ほかにも，場を和ませるムーブをしていました．楽しかったです???
結果発表 & 解説
コンテンツ力高めおもしろムーブ部門優勝じゃないですか？ #mixi_git
— プリキュア (@chigichan24) September 8, 2018
- 結果的には4位くらいで，成績的にはかなり，やらかし太郎だったけど，面白かったので良しとします．
懇親会
最後に
- こんな楽しいイベントを作るmixiさんすごい．
- 問題を思いつくのも天才的だし．競技を支えるインフラ，テスターを書くことなどを考慮するとかなり時間がかかるはず．．．
- 特に，私の害悪度高いムーブを受け止めて，淡々と問題を解いてくれたペアの chocoboくんありがとう！
参加者の皆さん！運営の皆さん！誘ってくれた人事の方！皆さんありがとうございました🤩🤩 めちゃくちゃ楽しい競技でした💪💪💪 git力もっと上げます✍️✍️ #mixi_git
— プリキュア (@chigichan24) September 8, 2018
余談
インターネット有名人の @raryosu に煽られたので、この先インターネットできないわ
— プリキュア (@chigichan24) September 8, 2018
mainframerで外部ビルド環境を作った話
最近
購入して一年も経ったMacBook Pro(メモリ 8GB)でAndroid Studio × 3，XCode，RubyMine，PyCharm，Chrome(タブ50個 over)とかで開発を同時多発的にやっていると コンピュータが重くて重くて しかたなかった．
特にAndroid Studioを触る機会が多いが，他人のコードをレビューする際にDatabindingやdaggerで生成された静的ファイルを一度消してビルドする必要があり(clean build & rebuild)それが重すぎて重すぎてコンパイルしている時は 虚無 になって Perfumeのことを考えるくらいしかやることがなく ，非常に時間がもったいないと感じていた．
そこで！！
- せめてAndroidのビルドだけでも外の環境に投げてその間でも開発が続けられるようにーと思って，mainframerを導入してみました．
mainframerとは？
これのことで，要するに，gradleとsourceファイルをみて，remote buildする環境を提供してくれるやつです．
Android Studioにはこれを支援するPluginが入っているので，localの設定はそんなにしんどくありません．
remoteもDockerなどで，ビルド環境を再現してあげればもう簡単に，ヒョイとできます．
Remoteの設定
- AWSなりなんなりに適当なインスタンスを建てる．
- OracleJRE(openJREだとkapt + databinding あたりがバグった)を入れる．
- SDKHandlerで，作りたい環境にあったバージョンのSDKを入れる．
- licenseという概念があり，これが正しく認証されないとビルドができないので，きちんと指定します．
Localの設定
- そもそも，普段
./gradlewをあまり使わない人だと，gradle/wrapperの下にgradle-wrapper.jarがなかったりするので作っておく． - Plugin から，Mainframer Integrationを入れる．
- 先に設定したRemoteを
~/.ssh/configに書いて，それをAndroid Studioの Mainframer constructionで指定する．
ハマりポイント
適当な権限でremoteのSDKやlicenseを指定すると書き込みや実行権限が振られずに正しくビルドできないのでディレクトリごと権限振る，ちゃんとユーザーを作るなどする必要があります．
規模によりますが，私のやっていたコードの場合t2microで立てたらビルドが終わらずに途中で死んでました．多分CPU，メモリスペックともにそれなりなものを選択する必要があります．(私はt2-largeを選択しましたがそれでもCPU使用率が200%近い時がありました．)
結果
Before(普通にローカルでやる)
gifなのですが容量の問題でループできなかったのでリロードして確認してみると遅いことが分かるかと思います．
After(remote でビルドする)
お気持ち
localでやっていた時，フルビルドで最悪7-8[min] 早いときでも2[min]程掛かっていたビルドが，最悪でも 2[min] ，早い時は数秒でビルドが終わるので開発効率が上がりました．
ビルドしている時にコンピュータが重くならないので，なにか別の作業をすることもできます．．コンピュータのファンが唸らない！！
これはまだやってませんがついでにCIもCircleCIやTravisに頼ることなく自前で回せます．
まとめ
- これで作業が遅いことをPCのせいにする言い訳ができなくなった．．．
Bonfire Android #3 に参加しました
遅くなってごめんなさい．完全に私の怠慢です．
なんかそれ，発表のときに伝えたかったニュアンスとズレてる🤔🤔🤔というときは 指摘していただけると助かります．
はじめに
3/12に参加してきました．
今回のテーマは サービスと設計 という，話を聞いているとだんだん耳が痛くなって途中退出したくなる系(?)だけどめちゃくちゃためになる話でした．
Androidアプリにおけるソフトウェア設計の考え方
スライド
ざっくりまとめ
- MVC，MVVM，The Clean Architectureなどいろんなアーキテクチャパターンがある．
- そもそもなんでこれらのアーキテクチャがあるのだろうか→ UI と model を分離したいというモチベーション
- で，UIとModelをつなぐ ビジネスロジック をきちんと整理していきましょう！！！
感想
- 上の話に加えて実例があったので非常にわかりやすかった．
- "名のあるアーキテクチャを採用するだけでは設計したとは言えない" が心にぶち刺さり思考停止しました．．．おっしゃるとおりでございます．．．
課題感から始めるクラス設計とチーム内での合意形成
スライド
ざっくりまとめ
- DroidKaigiでもセッションを聞きに行って感動したきりみんさん！！！
- いろいろなアーキテクチャがある理由とは?→そこに課題があるから
- 偉い人がイケてると言っているから導入というのはメリットがない． →心の声(ほんまそれ)
- 無理に凄い設計パターンを導入する必要はない．課題を解決するためにはなにをするべきかを考える．
- こういう課題があるから導入しようぜ→「それな」のながれが一番いい．
- 導入手順
- Issueベース(テキストベース)で議論を進める．
- 具体案を見せる．一部をその方針に則って実装し，PRを出してみる．
- コードベースでの議論を進める．
- リファクタする．
- 最高✌
- そして，一人で突っ走らない．設計の対象はプログラムだが，大事なのは正しい課題の認識とコミュニケーション
感想
- テキストベースの議論，一部を適用，コードベースでの議論の流れは確かにメンバーの意識を揃える上ではかなりバランスの取れた方針だと感じた．
- 個人開発や，超少人数開発だとどうしてもやりたい放題(あのアーキテクチャがすごそうだからとか，このライブラリが熱いから)とやってしまうが，サービスとなると話が変わってくるなとしみじみ感じた．
- チーム開発で，根幹に関わる部分であるからやはり正しく課題を認識して，それを共有するというのが大事なんだなぁ．
4年の開発が積み重なったアプリへのリファクタリング手法
スライド
ざっくりまとめ
- リファクタは現在進行系で某アプリをやっていたので聞く前から楽しみだった．
- いきなり，「よっしやったるでーーー！！！」って着手するのは危ない．
- なぜ→システムの特性や開発メンバのことを知らないと最適な判断は下せない．
- 元からいる開発メンバに責務分けを委ねる(これ凄いドメインエキスパートが登場するDDDっぽい感じある．)
- 使用したい技術(Rx，LiveData，Databinding，Dagger2)を全部入れると学習コストがでかくなるので，Rxだけにする．
- これすごくチームでやってるからという感じがした．自分一人なら，上にもかいたがやりたい放題やってしまいがち．
- リファクタ
- こうした結果チームで設計の話を共有し，次なる課題が見えるようになった！！！
感想
- 序盤に動いているコードにはリスペクトをという文言が出てきた．これは本当に思う．コードはやばくても動いているのだ．サービスとして成り立ってときには収益を上げているのだ．そこはリスペクトを．
- あまり学習コストということを考えて来なかったことを思った．みんなコード中にわけわからんのが出てきたら好き勝手学習してきて勝手にできるようになってるという変な先入観があった．そこもコストなんだなぁと改めて．
- 発表者の方は，すごくチームを観察してそのチームでのベストパフォーマンスをだすには？をすごく考えていた人だなぁと思った．
- Rxは強すぎるので使う機能や使い方を制限するというのは確かにと思った．(ViewでのみsubscribeやSubjectを使わないという話)
設計にみるAWA Androidアプリのこれまでとこれから
スライド
ざっくりまとめ
- AWAアンドロイドアプリの歴史を振り返る感じのスライドタイプ
- 立ち上げ期→MVCしてた
- →ビジネスロジックが色んな所に散った．→これを書く層が必要．
- →Modelが肥大化していった→責務分割が必要
- 設計改善期→設計を改善したが，設計のすり合わせがなされていなかったため，一貫性がなくなった． →これは怖いなぁと思った．きちんとコミュニケーションをとらないといけない理由が明確に見えたと思った．
- リーダビリティ，メンテナビリティ，テスタビリティの三本柱で！
- 現在進行系の設計→MVVM + LayerdArchitecture + CQRS
Repositoryがデータソースを気にしてはならないという理念の基，APIをRepositoryから剥がした．- CommandとQueryをきちんと分けることで複雑性が解消された．
- QueryはFlowable，CommandはCompletableで！
- 設計は可視化しよう！！！
感想
- 設計のすり合わせがなかったがゆえに，一貫性が無くなるというのを曖昧な設計をやめ，可視化することで改善するのはいいなぁと思った．
- 設計は俺の頭にあるんだ．じゃダメなんだ．それを具体的に形にしないととつくづく感じた．
- 具体的にRxの型まで縛るとたしかに一貫性は保たれるし，やれること・やれないことを明確に示せるなぁと思った．
Yahoo! JAPANアプリのLayered Architectureについて
スライド
ざっくりまとめ
- 超大人数での開発とどう向き合うか．→チームに20人はやべぇ．
- 明確な設計方針がなかった→やべぇ．というかそれで回っていたということはプロが回してたんだなぁと思った．
- 導入したもの→Layerd Architecture．
- これを守らせるために，レイヤーごとにモジュールを切って，機械的にgradleで弾く(私もこれやりたい！！)
- 一方向に依存させる．
- 大規模なリファクタ前後での品質担保のため，Application以下はユニットテストを義務付け，Coveraveが80%→やべぇ．やべぇ．80ってやべぇ．
- 導入のメリットとして，機能追加に悩みにくくなり，新規のjoinが容易に．
- 維持する取り組み
- 他にはなかった話．多分，大規模であるがゆえの苦悩なのだろうと感じた．
- コミッター制度を導入し，レビューの責務を見てもらう(コミッターの人めちゃくちゃ大変そう)
- 平均すると1人のコミッターが4人を見てる．すごい．．．
- 仕様共有会→設計の可視化だ！！
- 設計レビュー会
感想
- 超大人数での開発が垣間見えた．
- 無理に多くのことを導入しようとしない．これは本当にそう．あれもこれもってするとわけがわからなくなるんだなぁ．メンバーやビジネス側の理解をもらうことは個人開発で趣味の領域だとぜんぜん意識しないなあと思った．
お寿司
- お寿司を食べながら，色んな人とお話できました．
- 登壇者の方ともお話できました．
- お話してたらお寿司を食べそこねた(うけぽ)
全体を通した感想
サービスと設計というタイトルをみて参加ボタンを押した時，私はゴリゴリの設計論の話を期待していたがいい意味で裏切られた．
それは，きりみんさんのスライドにもあった通り，改善したいのはコードだけど改善するのは人だから，コミュニケーションを適切に取らないといけない．コミュニケーションを取るにはきちんとチームを観察し，考えを共有，そして意見・意志の合致を取る必要がある． それができて初めて，使用する技術だとかアーキテクチャとか，そういう話になるのだ．
そうしないと，コードがどんどん汚くなってしまう．ビジネス的にも美味しくない結果が待ってる．開発者も気が乗らない，または，深い意味もないのに無駄に高尚なアーキテクチャを選定し，その意味を分からず使ってしまうなどなど，いろんな問題が生まれるんだなぁと思った．
今まで私はほとんど個人やかなり少数での開発で，それもただの趣味的なものだから好き勝手ライブラリを入れ，DIとか雰囲気でいけるっしょ（笑）みたいな感じで導入し，MVVMイケてるっぽいから導入しようぜ👊ってやってきたけど，これビジネスが関わってきたらまじ卍(語彙力)って結果を招いていたんだなぁとちょっと反省した．
最後に
Bonfire Android開催の運営に関わった方々，発表をしていただいた方々，懇親会でAndroidの知見をいろいろと共有していただいた参加者の方々ありがとうございました！！！！
