chigichan24のお気持ち表明

イケてるエンジニアになりたい.

mainframerで外部ビルド環境を作った話

最近

  • 購入して一年も経ったMacBook Pro(メモリ 8GB)でAndroid Studio × 3,XCode,RubyMine,PyCharm,Chrome(タブ50個 over)とかで開発を同時多発的にやっていると コンピュータが重くて重くて しかたなかった.

  • 特にAndroid Studioを触る機会が多いが,他人のコードをレビューする際にDatabindingやdaggerで生成された静的ファイルを一度消してビルドする必要があり(clean build & rebuild)それが重すぎて重すぎてコンパイルしている時は 虚無 になって Perfumeのことを考えるくらいしかやることがなく ,非常に時間がもったいないと感じていた.

そこで!!
  • せめてAndroidのビルドだけでも外の環境に投げてその間でも開発が続けられるようにーと思って,mainframerを導入してみました.

mainframerとは?

github.com

  • これのことで,要するに,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なのですが容量の問題でループできなかったのでリロードして確認してみると遅いことが分かるかと思います.

f:id:chigichan24:20180418202953g:plain

After(remote でビルドする)

f:id:chigichan24:20180418180652g:plain

お気持ち

  • localでやっていた時,フルビルドで最悪7-8[min] 早いときでも2[min]程掛かっていたビルドが,最悪でも 2[min] ,早い時は数秒でビルドが終わるので開発効率が上がりました.

  • ビルドしている時にコンピュータが重くならないので,なにか別の作業をすることもできます..コンピュータのファンが唸らない!!

  • これはまだやってませんがついでにCIもCircleCIやTravisに頼ることなく自前で回せます.

まとめ

  • これで作業が遅いことをPCのせいにする言い訳ができなくなった...

Bonfire Android #3 に参加しました

遅くなってごめんなさい.完全に私の怠慢です.

なんかそれ,発表のときに伝えたかったニュアンスとズレてる🤔🤔🤔というときは 指摘していただけると助かります.

はじめに

3/12に参加してきました.

yj-meetup.connpass.com

今回のテーマは サービスと設計 という,話を聞いているとだんだん耳が痛くなって途中退出したくなる系(?)だけどめちゃくちゃためになる話でした.

Androidアプリにおけるソフトウェア設計の考え方

スライド

speakerdeck.com

ざっくりまとめ

感想

  • 上の話に加えて実例があったので非常にわかりやすかった.
  • "名のあるアーキテクチャを採用するだけでは設計したとは言えない" が心にぶち刺さり思考停止しました...おっしゃるとおりでございます...

課題感から始めるクラス設計とチーム内での合意形成

スライド

speakerdeck.com

ざっくりまとめ

  • DroidKaigiでもセッションを聞きに行って感動したきりみんさん!!!
  • いろいろなアーキテクチャがある理由とは?→そこに課題があるから
  • 偉い人がイケてると言っているから導入というのはメリットがない. →心の声(ほんまそれ)
  • 無理に凄い設計パターンを導入する必要はない.課題を解決するためにはなにをするべきかを考える.
  • こういう課題があるから導入しようぜ→「それな」のながれが一番いい.
  • 導入手順
    • Issueベース(テキストベース)で議論を進める.
    • 具体案を見せる.一部をその方針に則って実装し,PRを出してみる.
    • コードベースでの議論を進める.
    • リファクタする.
    • 最高✌
  • そして,一人で突っ走らない.設計の対象はプログラムだが,大事なのは正しい課題の認識とコミュニケーション

感想

  • テキストベースの議論,一部を適用,コードベースでの議論の流れは確かにメンバーの意識を揃える上ではかなりバランスの取れた方針だと感じた.
  • 個人開発や,超少人数開発だとどうしてもやりたい放題(あのアーキテクチャがすごそうだからとか,このライブラリが熱いから)とやってしまうが,サービスとなると話が変わってくるなとしみじみ感じた.
  • チーム開発で,根幹に関わる部分であるからやはり正しく課題を認識して,それを共有するというのが大事なんだなぁ.

4年の開発が積み重なったアプリへのリファクタリング手法

スライド

speakerdeck.com

ざっくりまとめ

  • リファクタは現在進行系で某アプリをやっていたので聞く前から楽しみだった.
  • いきなり,「よっしやったるでーーー!!!」って着手するのは危ない.
    • なぜ→システムの特性や開発メンバのことを知らないと最適な判断は下せない.
  • 元からいる開発メンバに責務分けを委ねる(これ凄いドメインエキスパートが登場するDDDっぽい感じある.)
  • 使用したい技術(Rx,LiveData,Databinding,Dagger2)を全部入れると学習コストがでかくなるので,Rxだけにする.
    • これすごくチームでやってるからという感じがした.自分一人なら,上にもかいたがやりたい放題やってしまいがち.
  • リファクタ
    • Layerdアーキテクチャな感じにして,一方向に依存させる.逆方向はRxのストリームを流す.
    • Viewからロジックを剥がす.→これは修行だ...
    • ロジックはドメインにまかせて似た処理がバラバラ事件になってるのを収束させる.
  • こうした結果チームで設計の話を共有し,次なる課題が見えるようになった!!!

感想

  • 序盤に動いているコードにはリスペクトをという文言が出てきた.これは本当に思う.コードはやばくても動いているのだ.サービスとして成り立ってときには収益を上げているのだ.そこはリスペクトを.
  • あまり学習コストということを考えて来なかったことを思った.みんなコード中にわけわからんのが出てきたら好き勝手学習してきて勝手にできるようになってるという変な先入観があった.そこもコストなんだなぁと改めて.
  • 発表者の方は,すごくチームを観察してそのチームでのベストパフォーマンスをだすには?をすごく考えていた人だなぁと思った.
  • Rxは強すぎるので使う機能や使い方を制限するというのは確かにと思った.(ViewでのみsubscribeやSubjectを使わないという話)

設計にみるAWA Androidアプリのこれまでとこれから

スライド

speakerdeck.com

ざっくりまとめ

  • AWAアンドロイドアプリの歴史を振り返る感じのスライドタイプ
  • 立ち上げ期→MVCしてた
    • ビジネスロジックが色んな所に散った.→これを書く層が必要.
    • →Modelが肥大化していった→責務分割が必要
  • 設計改善期→設計を改善したが,設計のすり合わせがなされていなかったため,一貫性がなくなった. →これは怖いなぁと思った.きちんとコミュニケーションをとらないといけない理由が明確に見えたと思った.
  • リーダビリティメンテナビリティテスタビリティの三本柱で!
  • 現在進行系の設計→MVVM + LayerdArchitecture + CQRS
  • Repositoryがデータソースを気にしてはならないという理念の基,APIをRepositoryから剥がした.
  • CommandとQueryをきちんと分けることで複雑性が解消された.
  • QueryはFlowable,CommandはCompletableで!
  • 設計は可視化しよう!!!

感想

  • 設計のすり合わせがなかったがゆえに,一貫性が無くなるというのを曖昧な設計をやめ,可視化することで改善するのはいいなぁと思った.
  • 設計は俺の頭にあるんだ.じゃダメなんだ.それを具体的に形にしないととつくづく感じた.
  • 具体的にRxの型まで縛るとたしかに一貫性は保たれるし,やれること・やれないことを明確に示せるなぁと思った.

Yahoo! JAPANアプリのLayered Architectureについて

スライド

speakerdeck.com

ざっくりまとめ

  • 超大人数での開発とどう向き合うか.→チームに20人はやべぇ.
  • 明確な設計方針がなかった→やべぇ.というかそれで回っていたということはプロが回してたんだなぁと思った.
  • 導入したもの→Layerd Architecture.
    • これを守らせるために,レイヤーごとにモジュールを切って,機械的にgradleで弾く(私もこれやりたい!!)
  • 一方向に依存させる.
  • 大規模なリファクタ前後での品質担保のため,Application以下はユニットテストを義務付け,Coveraveが80%→やべぇ.やべぇ.80ってやべぇ.
  • 導入のメリットとして,機能追加に悩みにくくなり,新規のjoinが容易に.
  • 維持する取り組み
    • 他にはなかった話.多分,大規模であるがゆえの苦悩なのだろうと感じた.
    • コミッター制度を導入し,レビューの責務を見てもらう(コミッターの人めちゃくちゃ大変そう)
      • 平均すると1人のコミッターが4人を見てる.すごい...
    • 仕様共有会→設計の可視化だ!!
    • 設計レビュー会

感想

  • 大人数での開発が垣間見えた.
  • 無理に多くのことを導入しようとしない.これは本当にそう.あれもこれもってするとわけがわからなくなるんだなぁ.メンバーやビジネス側の理解をもらうことは個人開発で趣味の領域だとぜんぜん意識しないなあと思った.

お寿司

  • お寿司を食べながら,色んな人とお話できました.
  • 登壇者の方ともお話できました.
  • お話してたらお寿司を食べそこねた(うけぽ)

全体を通した感想

サービスと設計というタイトルをみて参加ボタンを押した時,私はゴリゴリの設計論の話を期待していたがいい意味で裏切られた.

それは,きりみんさんのスライドにもあった通り,改善したいのはコードだけど改善するのは人だから,コミュニケーションを適切に取らないといけない.コミュニケーションを取るにはきちんとチームを観察し,考えを共有,そして意見・意志の合致を取る必要がある. それができて初めて,使用する技術だとかアーキテクチャとか,そういう話になるのだ.

そうしないと,コードがどんどん汚くなってしまう.ビジネス的にも美味しくない結果が待ってる.開発者も気が乗らない,または,深い意味もないのに無駄に高尚なアーキテクチャを選定し,その意味を分からず使ってしまうなどなど,いろんな問題が生まれるんだなぁと思った.

今まで私はほとんど個人やかなり少数での開発で,それもただの趣味的なものだから好き勝手ライブラリを入れ,DIとか雰囲気でいけるっしょ(笑)みたいな感じで導入し,MVVMイケてるっぽいから導入しようぜ👊ってやってきたけど,これビジネスが関わってきたらまじ卍(語彙力)って結果を招いていたんだなぁとちょっと反省した.

最後に

Bonfire Android開催の運営に関わった方々,発表をしていただいた方々,懇親会でAndroidの知見をいろいろと共有していただいた参加者の方々ありがとうございました!!!!

*1:このサイトは比較的わかりやすかった.

DroidKaigi2018に参加しました

DroidKaigi2018に参加してきました.一言で感想を要約すると死ぬほど楽しくて死んだ.

参加記です.聞いたセッションのことを備忘録としてさらさらと書いてみます.

スライドはここにいろいろまとまってるっぽいです.

  • DAY 01
    • ウェルカムトーク
    • Kotlinアンチパターン
      • スライド
      • 思ったこと
    • How to improve your MVP architecture and tests
      • スライド
      • 思ったこと
    • How to Kontribute
      • スライド
      • 思ったこと
    • DataBindingのコードを読む
      • スライド
      • 思ったこと
    • Say bye to Fragments with Conductor & Kotlin
      • スライド
      • 思ったこと
    • 実例で理解するMaterial Design Animation
      • スライド
      • 思ったこと
    • Kotlin版CleanArchitectureのテンプレート作ったら爆速開発になった話+α
      • スライド
      • 思ったこと
    • スポンサーブースを回る
      • いろんな企業
      • コーヒー
    • After Party
      • 思ったこと
  • DAY 02
    • コンテンツ流通基盤概論
    • コードで見るFlutterアプリの実装
      • スライド
      • 思ったこと
    • Gradleプラグインを作って開発効率を改善しよう
      • スライド
      • 思ったこと
    • 終わった直後
  • DAY -??
  • 全体的な感想
続きを読む