モバイルからデスクトップまで開発経験あり。
動画編集ソフトといったマルチメディアを扱う開発が得意。

ネイティブアプリケーション

筑波大学生向け時間割アプリ。有志で集まりチームで開発・運用されています。
自分はバックエンドの開発とAndroidの開発を担当しています。

![twinte-sc1](//images.ctfassets.net/27i46hewzrkc/64cbmfK6ZWWiCdxri0gvCW/0ed317a79073fb3d90a98217819279aa/pixel4-1__1_.png)

# Twin:teのバージョン遷移
Twin:teは過去に何度か大型アップデートを行っており、そのたびに大きく構成が変わっています。

- v1：初期バージョンで自分は開発に参加していませんでした
- v2：フロントにVue(2.x)・バックエンドにnode.js/express
- v3（現在）：フロントにVue(3.x)・バックエンドにnode.js/express/gRPCマイクロサービス

# 現在のバックエンド
v3では機能毎に細かくサービスを分割して協調して動作するマイクロサービスとなっています。
基本的にフロントエンドが得意なメンバーにも開発ができるように言語はTypescriptを使用していますが、一部はgoで動いています。
サービス間はgRPCで通信しており、フロントエンドとはapi-gatewayというサービスを介してhttpsで通信しています。
全てのサービスはlinodeのk8s上で動作しており、CI/CDはGitHubActionで整備されています。

# マイクロサービスを選んだ理由
v2までは一つのバックエンドサービスがすべての機能を実装する一般的なものでした。
しかしv3では機能毎に細かくサービスを分割して協調して動作するマイクロサービスとなっています。
マイクロサービスに切り替えた理由として以下が挙げられます。

## 新サービス実装の心理的負担を減らす
Twin:teは筑波大学生が便利に使えるサービスを開発したいというメンバーが集っています。
よって新しいサービスや機能は思いついたらすぐ実装して公開できる仕組みが必要だと考えました。
仮に全バックエンドが一つのサービスで成り立っていた場合、まず全体のコードの把握が必要になります。また、得意としない言語やフレームワークの場合学習コストがかかります。
こういった新機能を開発したいという気持ちを削いでしまう要因をできるだけ減らすために、また各々が挑戦したいことを既存のコードで制限したくないという思いもありました。マイクロサービスであれば使いたい言語でgRPCが利用できればそれ以外の制約はありません。

## コード把握のコスト削減
v1から始まったTwin:teのサービスは大きくなり、時間割以外の機能も多く実装するようになりました。例えばTwin:teはユーザーから寄付金を募っており決済の実装も行っています。
このようにメイン機能ではない性質の異なる機能を一つのバックエンドとして開発する必要がで出てきました。これにより特に新メンバーがコードを把握することが難しくなりました。
例えば特定の機能を修正したい場合に全体のコードをある程度把握する必要がありますが、サービスレベルで完全に分割されていれば対象サービスを把握するだけで修正ができます。

## コードの流動性
各々が異なる言語・異なる設計でサービスを開発すると将来的に技術的な負債になりえます。しかし、負債になったら新しく書き直すくらいの流動性があるべきだと思っています。
Twin:teは学生によって構成されるためメンバーに流動性もあります。そのため一つのコードベースを長期的に保持することは難しいのです。
マイクロサービスなら小さい単位から新しく書き直すことが可能になります。

# Androidアプリ
Twin:teはチームの規模の観点から、フロントエンドはweb技術で統一しています。
そのためiOS/AndroidアプリのメインUIはWebViewになっています。
ただし、通知機能やウィジェット機能はネイティブで実装する必要があります。

Twin:te AndroidアプリはKotlinで書かれています。
Android12でウィジェット周りのAPIがアップデートされたため利用できないか模索している段階です。

# chrome拡張
大学が使用している学習支援システムManabaで提供される授業の課題情報をGoogleCalendarに転送する拡張機能です。UIはReactで書かれています。

Twin:te

Kotlinで開発したクロスプラットフォームな動画編集ソフト。
現在は開発を凍結しています。

![citrus-sc1](//images.ctfassets.net/27i46hewzrkc/7dmQJ0Y3gfGLKeMDVl5EZw/1ce8b7e243565fd67841fa6a2df36000/image.png)

# 技術スタック
UIにJavaFX、動画のレンダリングにはOpenGL、動画のエンコード・デコードにはJavaCVを使用しています。
JavaFXはJavaの中ではモダンなUIフレームワークで、XMLとCSSライクな環境でUIを記述できます。
ハードウェアアクセラレーションが効くためパフォーマンスが良いです。
文字を重ねたり等、動画の表示・レンダリングにはOpenGLを使用しています。
動画そのもののエンコード・デコードにはJavaCVというOpenCVやFFmpegをラップしたライブラリを使用しました。（開発当時、JavaCVのFFmpeg関連でバグを発見・修正を行ったことがあり一応Contributerです。）

# こだわりポイント
このアプリはAviutl・Blender・Premiere Pro・AfterEffectsを参考に開発していました。
自分が使いやすいと感じた機能やUIを詰め込んでおり、拡張性を考慮してプラグインシステムを簡単に導入できるよう設計していました。


Kotlinで開発したクロスプラットフォームな動画編集ソフト

動画編集ソフト Citrus

Android向け音声波形表示ライブラリ。
Android5.0で導入されたMediaCodecAPIを活用してランタイムに波形データを生成、表示しています。

![waveformview-sc1](//images.ctfassets.net/27i46hewzrkc/2Bn2K8dm3WtHqJbcbmFweC/cacfeb51b2289a3055daa9f8b8ea51c6/sample1.png)


Android向け音声波形表示ライブラリ

waveform-view

大学3年次の夏にDMMの動画配信事業部でインターンを行いました。

# 参加したきっかけ
ある逆求人イベントに参加した際、DMMの動画配信事業部の方に声をかけていただきました。
もともとマルチメディアを扱うことに興味があり、また趣味で動画編集ソフトやキャプチャソフトを開発していました。ライブ配信に憧れのようなものを抱いていたこともあり、就業型インターンとして1ヶ月間参加させていただける事になりました。

# やったこと
## 概要
（※書けない内容は伏せているためわかりにくい表現が含まれるかもしれません）

ライブ配信を管理・監視するアプリケーションがFlashに依存しており今後使えなくなることから、新規ツールのリプレイスを一人で行いました。

## 使用技術
RTMPはFlashと併用されることが多いストリーミング用のメディアコンテナです。
そのためFlash無しでブラウザで取り扱うことが出来ません。（因みにWebRTCが扱えるプロトコルはRTPです）
よってネイティブアプリケーションとして実装する必要があります。
Windowsアプリケーションが要件だったため。WPFを採用しました。映像のデコードはFFmpegを使用することになるので制約の強いUWPは候補から外しました。

## 結果と感想
1ヶ月という短い時間ではありましたが運用までたどり着くことが出来ました。
一つの配信で同時接続10万人を捌いたDMMの配信システムを直に触ったことで、
実運用されている配信システムの技術を知れて非常に勉強になりました。
さらにその一部となるコンポーネントを開発できたことを非常に嬉しく思いました。

ありがとうございました。

インターン / ライブ配信監視ツールのリプレイス

DMM.com

頭部伝達関数(HRTF)を畳み込んで立体音響を再現するアプリケーション

HRTFSimulator

C#アプリにスクリプティング機能を追加してみる

C#でSoundCloudライクな波形を表示する音楽プレーヤを作ってみる

Works