インフラ・ストリーミングチームの近藤 (id:udzura) です。 ミラティブのインフラ運用では、監視・自動化などさまざまなツールにGo言語を利用しています。ツールはコマンドラインツールとして提供して、バージョンごとにリリースを作成して各環境にデプロイしています。リリースの作成にはGitHubのRelease機能を利用しています。 今回は、GitHub Releaseの作成をGoogle Cloud Build（以下、単にCloud Build）で自動化したことについて、実装内容と効果を書いていきます。 なぜ Cloud Build を採用したか ミラティブの開発はGitHub Enterprise Cloudを利用しています。対応するCI/CDのサービスとしてはGitHub ActionsやCircleCIなど*1数多くありますが、ミラティブにおいてはGCPの利用箇所が多く、既存GCP

こんにちは、クライアントエンジニアのちぎら（@_naru_jpn）です。Apple が Swift Concurrency への移行をサポートするためのサンプルプロジェクト Updating an App to Use Swift Concurrency を公開しているのをご存知でしょうか。 このプロジェクトには、DispatchQueue を用いて記述されたアプリのコードと、それを Actor などの Swift Concurrency を使用したコードに書き換えたアプリのコードの 2 つが同梱されています。運用しているプロダクトのコードを書き換えるのは規模も大きく大変ですが、小さいプロジェクトから書き換えの課題感を掴んだり、ウォーミングアップとして Apple のサンプルプロジェクトから学べることがあるだろうという事から、このプロジェクトを題材にして社内勉強会を開催しました。 勉強会の

みなさま、おはようございます。よこて @n0mimono です。令和になってなんと4年目に入りました。 今回はミラティブのプロダクト開発チームを更新したよ、という話をします。ついでに周辺の取り組みも紹介してみます。 前回記事はこちら tech.mirrativ.stream ちなみに今日はこの本の影響を受けています。 チームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計 作者:マシュー・スケルトン,マニュエル・パイス日本能率協会マネジメントセンターAmazon プロダクト開発と体制 組織 まず基本情報から。プロダクト開発に関わる組織そのものは今まで通りです。いわゆる機能別組織です。メンバー一覧見たら80人くらいいました、エンジニアは30人くらい。 技術部 ← エンジニアとか 分析部 ← 分析とか 企画部 ← PdMとか デザイン部 ← デザイナーとか エンジニアの組織はエン

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

はじめに こんにちは、Unityエンジニアのおはぎ @ohayo_ohayo_ です。 前職ではスマホゲームの開発をしており、今年の5月にジョインして約半年が経ちました。 現在はMirrativ内でエモモというアバター部分の開発をしています。 スマホゲーム開発とは結構違うなあと思ったので、 その辺をカジュアルに書こうという試みです。 プロダクト 大前提としてMirrativはゲーム配信アプリであり、ゲームではありません。 Unityを使っている部分は主にエモモの制御部分であり、一つのシーンで完結しています。 そのシーンに様々な機能を追加していくため、大きな一つのシーンとなります。 機能としては着せ替え、アニメーション、Cinemachineを使った演出が主であり、 それぞれはゲーム開発でも使われることがある技術です。 体力や攻撃力などのパラメータがないため、 パラメータのほとんどが見た目に

はじめに みなさまお久しぶりです、前回記事を書いたのが1年前というよこて @n0mimono です。今回はミラティブのプロダクト開発の体制的な話を書いてみようと思います。 ミラティブではMirrativというサービスを作り、運営していますがこれをどういう体制で作っているのかというお話です。開発フローとか技術的な話というより、どういう組織構造で作ってるのか、あるいは開発するものをどう決めているのかというあたりを語ります。（開発フローってどうなってんの？みたいな話は他の誰かが書いてくれるはず！） 先にネタバレするとこの記事はこの本の影響を受けています。 www.amazon.co.jp 本の影響を受けて開発体制をつくったというわけではなく、少しずつ改善していって後から振り返ったら「あれこれ似たようなことやってるな・・」という感じですね。 プロダクト開発と体制 The tribes ミラティブの

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

こんにちわ、エンジニアのタテノです。 8/21 に ISUCON11予選 が開催され、ミラティブから私とかずたかさん、stakmeさんの3人でチームミラティブとして参加しました。 isucon.net 3人ともISUCON参加ははじめてで、各々事前準備しつつ、当日、一時30位くらいまでスコアが伸びる場面もあるなど健闘しましたが、残念ながら予選敗退しました。 ミラティブからは、牧野さんが別チームで参加しており、見事10位で予選通過しました！おめでとうございます！ tech.mirrativ.stream 本記事では、チームミラティブでのISUCON予選を振り返っていきます。 参加表明 5/28 にISUCON11 の予選受付日程がアナウンスされ、牧野さんからエンジニアチームに対して、ミラティブチームでも出ませんかとお声がけがあります。 私は、これまでちょくちょくISUCONの話を聞いていたも

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

こんにちは Mirrativ CTOの夏です。 現在、ミラティブでは事業部単位でチームや目標を管理しており、エンジニアが所属するチームとして以下の6つがあります。今回はこのうち、エンジニアチームについて、2019年度に行ってきた取り組みの振り返りをしたいと思います。 ライブプラットフォームチーム ユーザの定着を追う マーケ連携チーム ユーザの新規獲得を追う エモモチーム 3Dアバターであるエモモを使った新体験の創出・基礎体験の向上を追う ストリーミング改善チーム モバイル端末でのライブストリーミングの配信・視聴の品質改善を追う インフラチーム クラウド上での安定したインフラ基盤の設計・構築を追う エンジニアチーム お問い合わせ調査、不具合・障害の再発防止、開発体験の向上を追う AI技術部 コミュニティやストリーミングとAI活用の可能性を追う 毎週定例で振り返りを行っており、Confluen

ミラティブのサーバーサイドエンジニア、ハトネコエです！ 今日は、GitHub の自動レビューとして reviewdog を導入した話をします。 1. 動機 すでに CTO の夏さんによって、Perl 用の linter である perlcritic が導入されていました。 そして、テストが走る際に perlcritic のチェックもおこなわれ、 指摘箇所があればテストが落ちるようになっていました。 まずは緩めの設定で導入したけれど、perlcritic のチェックをもっと厳しくしたい！ だけど厳しくすると、すでに存在するコード（つまり、プルリクで変更していない部分）が原因で テストが落ちるようになってしまいます。 残念ながら perlcritic には autofix の機能も無いようで、 設定を変更した後は、人力での修正が終わるまでテストは落ち続けてしまいます。 これでは開発に支障が出る

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