今年の振り返り 2019

買ってよかったもの

  • ViewSonic 32インチ ディスプレイ (アンチグレア)
  • モニターアーム
  • 横幅2mくらいのデスク
  • 珪藻土バスマット
  • ノイズキャンセリングワイヤレスイヤホン
  • 人工観葉植物 + 間接照明
  • ダメ着4G (着る毛布的な)

今年読んだ中でよかった本

  • Web API The Good Parts
  • DEEP WORK
  • UNIXという考え方
  • Android テスト全書
  • わかる!ドメイン駆動設計 ~もちこちゃんの大冒険~

ゲーム

イベント

  • マジカルミライ2019
  • TGS
  • DIVE XR FESTIVAL
  • ほんだのバイク 1周年イベント
  • グラブルフェス
  • UNSER Tour at Tokyo DOME (UVERWorld)
続きを読む

Gradleでライブラリのアップデート自動検知

この記事はAizu AdventCalendar 8日目の記事です。

adventar.org

はじめまして。元会津大学生のスルメです。
いまはDMMでAndroidエンジニアやってます。

はじめに

Gradleでマルチモジュールで開発しているとライブラリのバージョン管理を一か所でやりたくなります。 そのためversion.gradleといったようなファイルで一括管理をして各モジュールでそこで定義した変数から値を取得しるような実装をします。 このようにするとversion.gradleに使用ライブラリや言語のバージョンなどが集約されて変更が容易になります。 ただし、version.gradleはあくまで変数が書いてある場所でしかないのでIntellijやAndroidStudioなどでライブラリのアップデートを検知できません そのため今回はCI時にライブラリのアップデートを自動で検知す仕組みを導入したのでそれについて話していきます。

CIで自動検知

今回導入したものはこちらです。

github.com

こちらを導入するとgradle taskが新しく増えます

gradle dependencyUpdates
./gradlew dependencyUpdates

これだけでライブラリのアップデートを自動で検知してくれます。またデフォルトだっとtxtをはいてくれますがオプションを付けるとjson, xmlをはいてくれます。 これで準備は完了です。 あとは .circleci/config.yml でこのコマンドを実行すればライブラリのアップデートを自動で検知してくれます。 ただこの段階だと検知した物を外に投げる手段がありません。そのためDangerを用います。

github.com

あとはjsonで出力したものをdanger側のコードで解析してPRのコメントに流せば完成です!!!

./gradlew dependencyUpdates -Drevision=release -DoutputFormatter=json

f:id:slme9364:20191203083326p:plain

注意事項としてgradle-version-pluginsは初期設定だと最新版を検知するので設定を加えないとα, β, rcなども対象に含まれます。個人プロダクトの場合は問題ないかもしれませんが業務プロダクトだとそうもいかないのでrelease版のみを検知するようにしましょう。

公式docにも書いてありますが特定versionをrejectすると動きます。

def isNonStable = { String version ->
  return ['ALPHA', 'BETA', 'RC', 'EAP', 'DEV'].any { it -> version.toUpperCase().contains(it) }
}
dependencyUpdates {
  rejectVersionIf {
    isNonStable(it.candidate.version)
  }
}

ちなみにoutputしてきたjsonを解析して警告するとこのDangerfileの実装です。Ruby力は皆無なのでコードがクソなのは許してください

require 'json'
Dir.glob("**/dependencyUpdates/report.json").each { |report_file_path|
  results = File.open(report_file_path) do |io|
    JSON.load(io)
  end
  available_update_lib = results["outdated"]["dependencies"]
  available_update_lib.each { |lib|
    report = "#{lib["group"]}.#{lib["name"]}: #{lib["version"]} -> #{lib["available"]["release"]}"
    warn(report)
  }
}

新卒AndroidエンジニアがAndroidのチームリーダーをやった話

この記事は「DMMグループ Advent Calendar 2019」の7日目の記事です。

qiita.com

今年新卒でDMMに入社いたしましたスルメです。
僕は今新規事業系の部署に配属となり四ヶ月くらいが経ちました。
現在AQUIZっていうアプリを作ってます。

aquiz.jp

自分がチームに対して何を思ってどう行動したか時系列順に書いていきます。

  • 初期リリース
  • 大型アップデート
  • その後
  • これから

チームリーダーになった経緯

チームリーダーになった経緯を軽く説明します。
もともと自分が配属になったチームは、横断支援チーム的な人にがっつり依存して開発されていました。そのため事業部としてはそことの依存を切って事業部の人にチームリーダーをやって欲しいという意図があり自分がやることになりました。実は配属2日目に「チームリーダーをやって欲しい」と言われて当時は戸惑いしかなかったですが、「挑戦するだけするか」的な精神で取り合えず承諾しました。経緯も何もないですねw

ちなみに弊社はDMM.ESSENCEというのを掲げています。

inside.dmm.com

特に

  • 本気の失敗を肯定する
  • 好奇心を忘れない

あたりを意識した挑戦になったので、良い挑戦だなと思いました。

初期リリース

先ほども言った通り、もともと自分が配属になったチームは横断支援チーム的な人にがっつり依存して開発されていました。そのためこのフェーズに関しては新規実装を支援部隊の方に任せてコードの理解や細かいバグ修正などをメインに行っていました。さらにiOS版がAndroidリリース予定日より一カ月早くリリースしているので現行のiOS版が初期リリースから先行して実装してある機能も並列で実装する必要がでてそこら辺の実装なんかも担当したりしました。
このフェーズは自分の実装担当のほかに(横断支援チーム含む)チーム全体のタスク管理、テストケースの作成、申請周りなどなどやることが多く一番忙しかったです。
この段階だと正直チームの成熟度などはわからないため個々のチームメンバーの力を見ると同時にリリース最優先で動いたため、特にこれといった行動はしてないです。

大型アップデート

初期リリースが終わり一段落かと思ったらそうでもなくて、次の大型アップデートの準備が始まってました。支援部隊の方も初期リリース後は極力関わらないようになり、初期リリースという一つの山を超えたので自分が最低限必要だなと感じたものだけ作りました。

  • PRのテンプレート
  • issueのテンプレート
  • branch運用

あたりです。
開発方針やフローに関しては支援部隊の人が既に作ってくれていたので、自分が初期リリースで足りないと感じていたPR, issueのテンプレ作成を行いました。まだ自分含めて開発メンバーが未熟なのでテンプレを作っておかないと記述漏れが発生することが多々あったためです。実際ここら辺がテンプレ化することで記述漏れはなくなりスムーズにレビューができたりできました。特によかったのはセルフレビューという文化です。もともと支援部隊の人が入れてくれていた文化なのですが、自分で再度読み直すことで単純なミスコードがなくなり指摘箇所が減るのでコストが減ります。概要はこんな感じです。

f:id:slme9364:20191203100141p:plain

どの項目もPR出す前に当たり前にやっていないといけないことですが急いでたりすると忘れてしまうこともあるのでPRのテンプレに入れておくには良い文化だなと思いました。

issueのテンプレに関しては「どのPBIと関連しているか」や「解決策はどんな感じか」、「アラートライン」などをテンプレートとして提供しています。各々が未熟なのでここら辺を明示することで「なにも声があがらない」といった問題に対処しやすくなります。
プログラミングをする前に徹底的に考えてから実装する」といった文化が根付いてないのもあるので解決策をこの段階からある程度提示してもらうようにもしています。

ただこれらのテンプレ作成などは、所詮自分の暗黙知を表出化させて形式知に変えただけです。

f:id:slme9364:20191203100800p:plain

大型アップデートを終えて、そしてこれから

大型アップデートを終えて

大型アップデートを終えて上記の文化はチームに馴染み色々と改善していきました。この大型アップデートを通してチーム全体の成熟度を把握したので次は「最低限守って欲しいルール」を作りました。ただここら辺のルールは本当に最低限のことしか書いてないので今後チームに合わせてどのレベルまでルール化していくかは検討中です。

これから

僕自身はチームに一番必要なのはルールや文化だと思っています。
先ほど言った通り、まだ自分は最低限守って欲しいことしかルール化してないです。 なのでここから、チームがもっと良くなるためには、あるいは各々の力を最大化していくためにはどうしていけば良いかを考えていかなくてはなりません。
そこで恩恵があるのが新卒やインターン生です。ここの層はあまり特定の会社に染まってなくて色んな会社を見ていることもあり思考も新鮮なので鋭い疑問を投げかけてくれます。 実際、弊Androidチームではインターン生が投げてくれた疑問から新しく文化として定着したものもあります。ライブラリのアップデート自動検知であったり、実装に関する別アプローチの提案だったり色々あります。こういった疑問をちゃんと受け止めてパワーを持ってる人が検討するのが一番健全です。

まとめに入りますが、今回自分はAndroidチームリーダーをやって学んだことは色々あります。
そもそもAndroidでちゃんと開発するのは初めてなのでマルチモジュールやDagger、Androidチーム開発も学びになりましたし、Android以外にもAPI設計やデザインレビューもあるのでそういったところも勉強する良いきっかけになりました。また今までこういったチーム開発もはじめてなので、スコープが大きくなって取り組むことも変わってきたのも一つの変化ですね。

まだまだ未熟なところがありますが、これからも頑張っていきたいです。

参考リンク

以下自分が色々と参考になったリンク集です

プログラミングの前に、徹底的に考えよう - ボクココ

Google エンジニアリング・プラクティス ドキュメント | eng-practices

合同会社DMM.comに新卒入社しました

はじめに

すごい久しぶりにブログを書きます。スルメです。
DMMに新卒入社いたしまして少し経過したのでポエムを書こうと思います。
大学同期の友人が入社エントリをぼちぼち書いていたので自分も書いてみよう的なノリです。

入社までの流れ

自分の周りは優秀というか先をしっかり見てる人しかいないのでその人たちと比べれば大したことは書けませんが軽く書いてみます。 割と自分は「なんとかなる」精神で大学を過ごしてきたので3年夏あたりまで特に就職について考えていなかったです。
技術領域に関しても実はバラバラで大学1年のころはUE4とかC++触ってて2年のころはRustとか機械学習やってて、3年のころはRubyとRustって感じで4年でGoとKotlin(Android)って感じです。
こうしてみると自分は技術力が浅く大したことのない人材と自負していたので就活に対してかなりの不安を抱いていました。
そんななか某社の人事の方と飲みに行く機会があったのですが、その人事の方がめっちゃくちゃ優しくて色々と相談に乗ってもらって自分の不安も取り除けて本当に感謝しかないです。 そこからカジュアル面談ってやつで色んな企業さんとお話ししたのですが、その中で面白さを感じたのがDMMだったのでそのまま入社しました。

入社して

入社して4ヶ月ほど経ちました。 4ヶ月で話せることもあまりないので

  • 新卒研修
  • 配属

この二つを軸に書いていきます。

新卒研修

実は新卒研修がめちゃくちゃすごいんですよ

inside.dmm.com

あまり深いお話はできないのですが、全部の分野をレベルの深いところまでやって最後にチーム開発で一つのプロダクトを作りました。 正直どの分野も学びしかなくて、個人的に面白かったのは

  • 負荷テスト・パフォーマンスチューニング
  • セキュリティ
  • Android
  • SRE

ここらへんかなと思います。

配属

配属に関してですが技術的にもサービス的にも興味のあるところに行けたのでとても満足です。いまも楽しく仕事してます。 新卒という形で配属になっていますが部署では新卒という壁なく扱ってもらえてるので普通に楽しいです。 部署の人たちはみんな思考がしっかりしていて自分の考えるべき点がしっかり見えてくるので学びしかないです。
ダイレクトに宣伝ですが弊部署ではAQUIZというサービスを開発しています!ぜひDLお願いします!(Android版は今僕が精一杯開発してるので少々お待ちを!)

aquiz.jp

ちょっと不満に思うこと

とりあえず不満に思うこと一覧をばっと上げます

  • 研修期間中のフレックス
  • 夏季休暇
  • GHE

研修期間中にフレックス使えそうな状況でも研修期間中は使えなかったり、夏季休暇短かったりちょっとここらはつらみです。 GHEに関してはGitHub Enterpriseの話なのですが、アカウントがGitHubと別なのでちょっと悲しいってだけです。

おわりに

そんなこんなで日々楽しく生きています。
今年度は活発な年にしたいと思ってKotlinFestのLT申し込んだら採択されたのでぜひ!

kotlin.connpass.com

こんな浅い内容のエントリを最後まで読んでくださりありがとうございました。

Pixel3を購入時に発生した問題点と使い心地的な

はじめに

お久しぶりです。スルメです。就活は終えました。 HTC10 HTV32を使い始めて約2年。Pixel3が発売するとのことで予約したいなと思いました。 けれどお金がない僕は最初予約を渋っていたのですが、よく考えたら残高あったので予約しました。

続きを読む