みなさん、こんにちは！2022年8月よりAndroidエンジニアとしてインターン中の kitakkun です。 現在MirrativのAndroidチームでは、アプリケーションの品質向上を目指してマルチモジュールの導入を進めています。 Mirrativでは、元々あったmirrorman（当時の開発コードネーム）という巨大なモノリスのモジュールから、新規開発部分をfeatureモジュールに切り出して開発をしています。 モノリスモジュールからfeatureモジュールを分離 元々モノリス部分だったmirrormanが巨大で、mirrormanにあるクラスをfeatureモジュールで使いたいケースがあり、未だmirrormanへの参照が残っている状態です。 なるべくmirrormanへの参照をなくすために、特定のfeatureモジュールでしか使われていないファイルをmirrormanから移動してい

こんにちは。ミラティブのAndroidエンジニアのかねき@kanesyです。 以前の記事でも何度か紹介していますが、MirrativのAndroidアプリでは新規で作る画面には積極的にJetpack Composeを活用しています。 tech.mirrativ.stream Jetpack Composeでの開発が活発になるにつれて、Viewの多重タップや、リスト中の複数アイテムの同時タップなどの想定外の挙動に向き合う必要が出てきました。 そこで今回は、MirrativのAndroidアプリで採用したJetpack ComposeにおけるViewの多重タップや、リスト中のアイテムの複数同時タップに対する取り組みについて紹介します。 Android Viewにおける多重タップ防止 Jetpack Composeでの実装の説明に移る前に、まずは既存のAndroid Viewにおける多重タップ防

Unityエンジニアの森田です。今回は前回書いた記事の続きで、CI/CDのちょっとした改善をした話を書いていきます。 tech.mirrativ.stream 課題 以下の記事で書いたように、ミラティブでは複数のアプリのバージョンを運用しており、それに合わせてアセットも複数のバージョンを管理しています。 tech.mirrativ.stream アセットの更新がアセットのFix用ブランチとして運用しているmasterブランチに取り込まれると、その更新をリリース用のブランチにそれを取り込まなければいけないのですが、この作業をその都度デザイナーからエンジニアに依頼する形になっていました。またバージョンごとに作られたリリース用ブランチ全てに取り込まなければいけないため、とても煩わしいです。 そのため今回はmasterブランチにアセットの更新が入った時点で各リリース用ブランチに自動的にマージされる

インフラ・ストリーミングチームの @udzura です。（一ヶ月経ってしまいましたが）9月8日から9月10日まで、三重県でRubyKaigiがありました。 rubykaigi.org 久しぶりのオンサイト会場での開催ということで、大いに盛り上がり、感想ブログなどもたくさん書かれています。 今回は、Rubyをメインで使っていない会社であるミラティブのエンジニアの立場から、RubyKaigiのトークは勉強になるという話をします。 ミラティブの技術スタックとコミュニティについて ところで、以下に、ミラティブのEngineer's Handbookから、技術スタックについての紹介ページを引用します。 エンジニアハンドブックより引用 この通り、実はRubyはアプリケーション開発のメインは使っていないのです*1。 ですが、今回は、後述する通り私がRubyKaigiのCfPに通過したため、「社内外へ積極

ミラティブのAndroidエンジニアの chocomelon です。 MirrativのAndroidアプリでは、Androidアプリケーションの内部品質向上のために開発で以下を取り入れています。 データフローの単方向化（Flux導入） Viewからのロジック切り離し（Flux、Jetpack Compose導入など） 責務分割、依存方向の強制（Flux、マルチモジュール導入など） 今回の記事では特にマルチモジュールについてお話します。 MirrativのAndroidアプリは、配信/視聴機能、アバター機能、リッチなアニメーションなど複雑な要素を一つの画面で表現することが多々あります。 これらを考えなしに実装すると、可読性の悪化を招いたり、不具合が発生しやすく調査しづらいコードにしてしまいがちです。 複雑なアニメーションやアバター機能などを持つ配信画面 ミラティブでは多くのメンバーがネイテ

みなさま、今年も夏（summer）がやってきました。よこて @n0mimono です。今回はミラティブのプロダクト開発組織を更新したよという話をします。ついでにこれまでの歴史と今後の展望も紹介します。 前回記事はこちら tech.mirrativ.stream プロダクト開発と体制 組織 まず基本情報から、ミラティブの展開するサービスは『Mirrativ』です。メンバーは何らかの形でこのサービスに関わります。前回記事時点で80人と書きましたが、今確認したら100くらいのメンバーがいます。エンジニアが所属する技術部を数えたら40人くらいいます。 前回記事の時点では、単一の技術部の下にグループをぶら下げる構成にしていました。 技術部 アプリ バックエンド インフラ・ストリーミング 人数も増えてきたため、7月から 技術部を2つに分けました 。だいたいこんな感じ。 プロダクト開発 Unity アプ

ミラティブのAndroidエンジニアのmorizoooです。 MirrativのAndroidアプリでは、新規で作る画面には積極的にJetpack Composeを活用しています。 tech.mirrativ.stream Mirrativは、多くのユーザーがゲームや雑談などの配信をしており、配信を盛り上げるための演出として通常のアニメーションに加えてLottieも織り交ぜ、リッチなアニメーションを実装しています。 Jetpack Compose導入以前は、AnimationListenerのCallbackを入れ子にする形で複雑なアニメーションを実現していたのですが、いざJetpack Composeで実装しようとなるとどう実装するのが良いのか苦心しました。 今回の記事では、実際にアプリで使っているアニメーションを例に、Jetpack Composeで作ったアニメーションを紹介します。

こんにちわ。shogo4405です。普段は、ミラティブで開発しながら、余暇にOSSのHaishinKit*1をつくっています。本エントリーは普段UI開発を行なっているクライアントエンジニア向けに、ミラティブで導入しているDangerの実践レシピを公開いたします。 はじめに Dangerとは「Pull Requestの作法を形式化して指摘を自動化」するツールであり、採用している開発者の方も多いのではないでしょうか。Dangerの導入にあたってはDangerで始めるPull Requestチェック自動化 - コネヒト開発者ブログを参考にして導入いたしました。ありがとうございます。 ミラティブ社でも形式的なチェックは基本的にDangerに任せるにようしています。本エントリーでは、開発現場のあるある指摘内容をレシピ集という形でまとめました。 レシピ１：githubの更新があった箇所のみ指摘する 定

こんにちはLivePlatformチーム所属の_mkazutakaです。 ミラティブでは、週1回木曜日にエンジニア向けの社内勉強会を開催しています。社内勉強会にはバックエンドエンジニアのみならず、iOSエンジニア、ビジネスサイドからの参加があります。 今年の8月でサービスリリース6周年を迎えたミラティブですがこれまで社内勉強会するという文化はありませんでした。 ミラティブでの社内勉強会も次で26回目になります。振り返りの意味も含め、なぜ・どうやって勉強会を開催しているかを紹介していきたいと思います。 社内勉強会をやっているけれども他の会社ではどのようにやっているのだろう、社内勉強会に興味がある、といった人達にとって参考になれば幸いです。 なぜ開催し始めたのか ミラティブでは月に一回プレミアムエモイデーという全体会議があります。当時プレミアムエモイデーにてチーム内の行動指針に沿った行動につい

こんにちは。エンジニアのshogo4405です。普段は、ミラティブで開発しながら、余暇にOSSのHaishinKit*1*2をつくっています。本稿では、Androidチームで取り組んだAndroid Studioから出てくる警告対応ゼロの仕組み化について紹介します。 はじめに 筆者は、警告は一つ一つ適切なアクションを行うべき対象と考えています。警告一つ一つに意味を持っています。リリース後にクラッシュレポートを見て「あー警告」で指摘されてたという失敗経験もあります。チーム開発においては、IDEの警告ゼロが当然になるように働かきかけています。 Androidチームでは、2021年第3四半期のOKRの一つとして警告ゼロ対応を掲げました。着手当初は278 warnings, 306 weak warnings, 75 infosの警告等がありました。 ゼロ警告へのアプローチ まず初めにチームで実施

こんにちは ハタ です。 今回は以前iOSのクライアントサイドで実装していた通知ぼかし機能をサーバサイド(配信サーバ)上に再実装した事を書きたいなと思います 今回はかなり内容を絞りに絞ったのですが、長くなってしまいました、、 目次機能があったのでつけてみました、読み飛ばして読みやすくなった(?)かもしれません 目次 目次 通知ぼかし機能とは サーバサイド通知ぼかし プロトタイプの実装 苦労の始まり その1 画像処理速度 苦労の始まり その2 データ量 さらなる計算量の削減を求めて さらなる最適化へ Halide の世界へ 簡単な halide の紹介 苦労の始まり その3 いざ リリース リリースその後 We are hiring! 通知ぼかし機能とは 通知ぼかし機能は、ミラティブ上での配信中に写り込んでしまったiOSの通知ダイアログをダイアログの中身を見えないようにぼかし処理をしてあげる

こんにちは Mirrativ CTOの夏です 今回は先日iOSでリリースした通知ぼかし機能について、裏でどういうことをしているのかについて軽く紹介したいと思います。 MirrativではOSから提供されるAPI（ ReplayKit・MediaProjection ）を用いて、スマホ画面を直接収録・配信することで、配信用のSDKを各ゲームやアプリに埋め込んでもらう必要がなく、ユーザさんが色々なアプリを気軽に切り替えながら友達と雑談を楽しんだり、ゲームを通じて新しい友達を作ることができます。 その反面、配信者が適切な設定を行っていない場合、意図しないプッシュ通知が視聴者に表示されてしまう場合もあります。 Mirrativでは配信準備画面に注意文言と啓蒙動画を載せていますが、どうしても設定が漏れたりする場合があるため、配信者が注意しなくても、プッシュ通知が視聴者に見えない仕組みを以前から検討し

Mirrativ Androidエンジニアのmorizoooです。今回はAndroidアプリをFluxにリアーキテクチャした話をします。 背景 Mirrativは2015年春頃に開発が始まり、もうすぐリリースから6周年を迎えようとしています。以前はアーキテクチャについてのルールが決まっておらず、個々人が思うがままコードを書いており、開発しているメンバーでさえ処理の流れが追えなくなっているような状況でした。そこで、まずは既存のコードの改善を行いました。詳しくは以下の記事をご覧ください。 tech.mirrativ.stream 既存コードを改善した後に、開発の指針としてFluxアーキテクチャを選定しました。 Fluxを選定した理由 状態がどこで更新されているのか分からなくなるという一番の課題が、Flux の導入によって解消できそうだった iOSはFluxで実装していくという話が出ており知見を

Mirrativ Androidエンジニアのmorizoooです。MirrativではデバッグツールとしてFlipperを使っています。Flipperはモバイルアプリデバッグのためのデスクトップアプリケーションで、アプリ内のデータの整形や可視化を行うことができます。また、Flipperはネットワークの通信状況を確認するNetworkPluginなど、標準でいくつかの機能が用意されています。詳細についてはこちらをご覧ください。 tech.mirrativ.stream Flipperは標準機能だけでなく、独自のCustomPluginを作成することもできます。MirrativではCustomPluginを積極的に作成し、バグ調査や開発効率の改善に役立てています。一つ例を上げると、Mirrativではコメントやギフトの機能のために、WebSocketベースの独自のPubSubライブラリを使用し

こんにちは、テックリードの夏です。 今年4月にCTOからテックリードに肩書が変わり、ガリガリコードを書くようになりました。 背景については、こちらをご覧ください。 www.wantedly.com 普段はプロダクト側の機能開発と、サーバ側の基盤開発を半々ぐらいの割合で仕事しています。 一口にサーバ側の基盤開発といっても定義が曖昧なのですが、基本的にはこんな感じのタスクをやっています。 インフラコストの最適化 不正なアクセスからの防御 障害の再発防止 新技術の導入やアーキテクチャの整備 今回はこのうち「新技術の導入やアーキテクチャの整備」の中で、サーバサイドをGo + Clean Architectureで再設計したことについてお話したいと思います。 背景 ミラティブは2015年春頃に開発が始まり、同年8月にサービスがリリースされ、2020年8月で5周年を迎えました。 その過程で組織やプロダ

Mirrativ Androidエンジニアのmorizoooです。 Mirrativのエンジニアは週4日をプロダクト開発に、週1日を開発体験の向上に時間を割いおり、CTOによる旗振りのもと、エンジニア主導で技術的負債の返済に取り組んでます。 今回は、Androidチームで取り組んだ技術的負債の返済のために行った取り組みについて紹介します。 背景 以前、2019/04に 突撃!!隣のアーキテクチャ - connpass でもお話したのですが、Androidアプリが主に以下の理由でつらい状態なっておりました。 ロジックが散在 今ではあまり使われないライブラリへの依存 JavaとKotlinの共存 speakerdeck.com これに対してAndroidチームで以下の取組みを行いました。 ActivityとCustomViewの再設計 ライブラリの最新化 Kotlin化の推進 それぞれのトピッ

Mirrativ Androidエンジニアのmorizoooです。 今回は Mirrativ Androidアプリにおいてデバッグ用のツールをStethoからFlipperに変更して開発体験が向上した事例を紹介します。 Stethoとは Facebookが開発したネットワーク通信デバッグ用のブリッジライブラリで、 Chrome Developer Toolsを使ってネットワーク通信/Preference/SQLiteの確認ができます。 Mirrativ内では主にネットワーク通信確認で使っていました。 facebook.github.io Stethoの課題 とても便利なツールではあるのですが、ネットワーク通信を確認しながらアプリを起動していると度々クラッシュが起きていました。 Chrome Developer Toolsでアタッチしていないと発生しないのですが、デバッグ時にストレスがたまる