Windows向け省帯域リモートデスクトップシステム (クライアントはAndroid) の開発中お試し版を配布してみます

何?

  • 出先で、モバイルデバイス(主にはスマートフォン)を使ってモバイルネットワーク経由で自宅PCにインストールしてある音声付きノベルゲームをやれたらいいな、と思った
  • Windows公式リモートデスクトップとかだとパケ死するので、ダメ
  • 利用したいアプリケーションの特性(画面の大部分は頻繁には更新されない)を考慮すると、FPSを落とすとか、全画面表示にしておけば画質を落としても何とかなるのでは?と考えた
  • 画像・音声の両方に対応していて、画質やFPSを極端に落とせるソフトウェアは見つからなかった
  • ので自分で作ることにした
  • まとめると、すげえ馬鹿みたいに画質やFPSを落とせて、結果的に省帯域で使えるリモートデスクトップシステム(サーバ、クライアントとなるAndroidアプリ)です!

作り

頑張った・苦労したところ

  • 画像 (動画) と 音声の エンドレスなライブエンコーディング・デコーディングを実装した
    • 画像はH264、音声はOpus
    • 英語で書かれたものも含めてインターネッツにあまり情報がない
    • Android組み込みのデコーダの初期化のしかたがとにかく良く分からない。トライアンドエラーでなんとかした
    • 音声は最初にAACで実装したが、レイテンシ(要はエンコーディング・デコーディングにかかる処理時間)が大きすぎて使い物にならず、作り直しになった
      • コーデックによって結構違うんだなあと、勉強になりました
  • クライアント側は大部分をXamarin.Forms (プラットフォーム非依存でUI含めて実装できる) で書いた
    • 音声デバイス回り、メディアデータのデコーダがプラットフォーム依存な形で実装されているが、そこさえ対応すればiOSアプリにもできる(簡単じゃないと思うけど・・・・)
  • タッチパネルでのマウス操作をまともに使えるレベルの仕様(実装とは言っていない)で作った

未実装の機能などなど(これから実装しないといけないところ)

  • クライアント側からFPS、画質、音質を設定できるようにする
  • サーバ側の設定の外部ファイル化
  • サーバにグローバルIPでアクセスしても動作するように (インターネットアクセス権限の取得処理)
  • (できたら・・・、)UDPホールパンチング等を用いてVPN無しで出先でのモバイルネットワークからNAT内のサーバにアクセスできるようにする
    • 今のところ、Hamachiなどを用いて自宅のPCとVPNを張ってもらうしかない

配布ファイル

クライアントのapkパッケージも、拡張子がapkだとスマホブラウザでダウンロードした時に開くアプリとかで面倒なことになったりするみたいなので、zipで固めてあります。
展開して中のapkパッケージをインストールしてください。
なお、Google Play経由でのインストールではないので、以下のページで説明されているような手順でのインストールが必要になります。
https://qiita.com/gumby/items/9e1431b73bdb6b0684d8

上記で配布しているバージョン1.1に対応するコードは以下です。
GitHub - ryogrid/RemoteDesktopOneWindowForNovelGrame at d18f7ede53d73216bf5041959501a63ba741eb29

動作環境

サーバ

  • Windows10 64bitでのみ動作確認していますが、Windows7以降 (64bit) ぐらいなら動作するのではないかと思います
  • .Net Framework v4.6.1をターゲットにビルドしてあるため、そのバージョンと互換性のある環境であれば動作可能なはず
  • ポートは10010番と10011番を利用します

クライアント(Androidアプリ)

ネットワーク

  • Hamachi等のVPNを用いても良いのですが、同一ネットワークに存在する状態でないと動作しないと思います(インターネットアクセスの権限取得などの処理を実装していないため)

注意

  • サーバとクライアントの間の通信は暗号化されません
  • クライアントアプリはバックグラウンドにいったときの処理が未実装のため、終了させずに他のアプリに切り替えると、異常動作をするのではないかと思います!!!
  • 省帯域というのを示したいので、画質はかなり落としてあります。正直、今のパラメータだと実用に耐えないと思います

お願い

  • うまく動作しなかった場合は、コメント欄にOSのバージョンとデバイスの機種名(クライアント側の場合のみ)、また可能ならどのような現象が発生したかをご報告いただけると大変ありがたいです

使い方

サーバ

zipファイルを展開して、RemoteDesktop.Server.XamaOK.exe をファイルエクスプローラなりコマンドプロンプトなりで起動すれば使えます。

コマンドプロンプトが追加で開きますが、そこにはサーバの標準出力が出ています。

終了するときは、上記のコマンドプロンプトを閉じるか、タスクマネージャなりでプロセスを終了させればOKです。
動作させるPCの設定を変更したり、ファイルを生成したりすることはありません。
従って、アンインストールはフォルダを削除すればOKです。

機能・処理
  • PCのメインスクリーンの内容をキャプチャしてクライアントに配信する(1秒おき)
  • PC内で流れている?サウンドをクライアントに配信する
  • クライアントからのマウス操作を、マウスカーソルに適用する

クライアント(Androidアプリ)

  1. 起動したらIPアドレス入力フォームがあるので、それにタッチしてフォーカスをあててサーバのIPアドレスを入力
  2. 左上の「三」みたいなのを押して、RDPSessionを選択 => サーバへ接続が開始され、画像と音声が送られてきます
  3. リモート操作は現状、マウスのみ対応です。PC画面はスマホを横にした状態で見える形で表示されます。タッチしたまま指を移動させるとカーソルが連動して動きます。タップすると左クリック。ロングタップで右クリックです。ダブルクリックはタップ2回ですが、あまり速いとうまく認識されないので、ゆっくりめを意識してやってみてください
  4. 終了のさせかた。終了ボタンとかはないので、Androidの□ボタンとかで起動中のアプリを出してシュッとするとかで終了させて下さい

UDPホールパンチングでNAT越えしてP2P直接通信(SCTP)でファイル転送やパイプ転送するツールの設計(案)

前にUDPホールパンチングでover NATのP2PのSCTP通信路を作ってファイル転送するってのを試したりしてたんですが(aiortcというライブラリでWebRTCのデータチャネルを使う。aiortcのリポジトリのexampleを少し拡張した)、それをさらに拡張したツールの設計を考えています。
 
で、要件としては
シグナリングサーバは共用して使えるものを私がホストしておき、Pipingサーバ( https://qiita.com/nwtgck/items/78309fc529da7776cba0 ) のように2者で決めた識別子を互いがシグナリングサーバに送信するような実装にすることで、通信をつなぐ2者を区別する
・一度通信路ができたらそれを使いまわしたい(何度も同じか別かどっちでもいいですが、識別子を指定してコマンドを実行させることは避けたい)
・双方向でファイル転送と、パイプ接続によるデータ転送をできるようにしたい
 
で、今考えてる設計は、2つコマンドを(コマンドラインなり、シェルで実行する実行ファイル)用意して、
 
【コマンド1】
・ファイル転送モードとパイプサーバモードのどちらかを選択して起動
・ファイル転送モードでは、簡単なコマンド入力できるようなインタフェースを用意して(通信路ができるとsftpコマンドみたいに、インタラクティブに入力できる状態になる)、send <ローカルにあるファイル名> とかすると、相手が何もせんでも、相手がコマンド1起動時に指定したワーキングディレクトリ(双方が指定しておく)にそのファイルが転送される。で、転送が終わったらまたコマンド入力待ちになる
・パイプサーバモードで起動するとローカルで動くサーバ的なもの(以降、ローカルパイプサーバ)として起動しっぱなしになる
 
【コマンド2】
・ローカルパイプサーバと連携するためのコマンド
・sendモードとrecvモードのどちらかを選択して起動
・データを送りたい側はパイプのつなぐ先にコマンド2を指定してsendモード指定で起動。内部的にはローカルパイプサーバとして起動しているコマンド1のプロセスによろしくデータを転送する。
・データを受信したい側はコマンド2が受信データをstdoutに吐く前提でパイプなり、リダイレクトなりを指定して、recvモードでコマンド2を起動
・送信側、受信側のコマンド実行のタイミングはどちらが先でも良く、双方が起動するまでブロックする
・一回転送が終了したら、双方のローカルパイプサーバは(コマンド2からの)接続待ちの状態に戻り、コマンド2を用いて別のデータ転送に利用できる
・ローカルパイプサーバが一つのコマンド2プロセス によって使用中の時は、追加でコマンド2を起動してもパイプサーバがエラーを返す(sendとrecvだったら同時に使わせてもいいかも)
 
って感じです。どうすかねー。
忌憚のないご意見をお待ちしております。
 
なお、前に動かしたちょっと拡張版exampleはここに置いてあります。
https://github.com/ryogrid/aiortc-dc/tree/master/examples/datachannel-filexfer

9年前から4年弱ほど富士通にいたものです

なんか下の増田がバズってたので乗っかってブクマ稼がせてもらいますね。

5年いた富士通を退職した理由
https://anond.hatelabo.jp/20190326233147

自分は2010年から2014年頭までの4年弱勤めてました。
担当業務はスパコンミドルウェア開発。まあ、いわゆるスパコン京とかのやつですね。

詳しくは以下の退職エントリ参照
https://ryogrid.hatenablog.com/entry/20140120

で、書いてある内容だけど、多分嘘ではないのでしょう。開発機とかは確かに似たようなもんだったし。でも、自分の場合は、どうせ、SSHで開発用のサーバとかに入ってEmacsとかでコード書いてたのでスペックとか別にどうでも良かった。

というか、どこらへんの部署にいたか書いてないのでなんとも言えないというのが正直なところ。

せめて、事業部か、SI部門か、研究所か、それぐらいは書いてくれないと。

職種もよくわからんし。

あと、富士通もでかい組織なので、部門ごとに文化とか全然違ったりするし、みんなこれと同じ環境だと認識されると、さすがになあという気はする。これは大企業全般に言えることだと思いますが。

一方で共感する部分もいくつかある。新しい技術の導入に積極的でないとか、なんだとかはその通りだと思うし、みんな内向きで、プライベートで新たな技術について情報を摂取して研鑽する、ってなことをあまりしないというのも、まあ確か。でも、そうでない人もたくさんいます。ただ、まあ、そういう人はいずれ辞めちゃうんだけどね。。。

開発基準?うんぬんは自分は知らないですね。品質管理のためのドキュメントをやたら書かされるのは確かだけど、まあ、エンタープライズの世界なのでしゃあない。

椅子だの机だのは普通でした。良くもなければ悪くもない。

バージョン管理もちゃんとしてましたよ。チームによって微妙に違ったりとかしたけど、Subversionぐらいは普通に使ってたし、導入に前向きな人がいるチームとかはgitとか使ってた。

ビルドは普通にmakeです。

あと、ウォーターフォールをやたら叩いてますが、重要なのはプロジェクトの性質や規模に合った開発プロセスを選択することです。大人数で回すでかいプロジェクトでアジャイルとかやったら、終わりますよ?
(ただ、細分化されたチームの中でアジャイル的なものを組み合わせる形で取り込むのはアリです。自分もスクラムを導入したりしましたし)

ま、想像するにこの方はSI部門だったんじゃないかなあ。
で、そうだとしたら、大企業のSI部門なんて、どうせ、どこもクソだし、まともにエンジニアリングしようなんて、そもそも無理なんで、新たな職場で頑張ってください。

あと、学生時代に、記事に書いたような事態になることはちゃんと情報収集してれば十分知り得たはずなので(さすがに中途の人じゃないよね?) 、あなたも自分の進路選択の失敗について我が身を振り返って、今後に活かしてください。

以上。
今後のご活躍をお祈りします。

追記: (ブコメに負けたと思われると癪なので、追記部分以外はいじっていません)
つい、仕事を終えて疲れているところで、言及先の記事を目にして、古巣を不当に?過剰に?ディスられていたので、脊髄反射で書いてしまい、汚い言葉を使ったり、本音が漏れてしまったりしてしまいました。

で、ブクマのコメントとか見るとマウントとろうとしているとか言われているのですが、それは否定しておきます。職業に貴賤なし、ではないですが、SIをやってる人間より、まあこの記事の話に限定すれば、スパコンミドルウェア開発をしている人のほうがすごいとか、えらいとか、そういうことは思っていません。

ただ、現在のSI業界の現場が、特に、大企業に連なる、ITゼネコン?なんて言われてしまうような、多層構造(もっと適当な言葉がある気がする)の中の現場がよろしくないとは認識していて (聞いた話やらなんやらを総合して)、上の文章は、そういうことを汚い言葉で書いてしまったということです。

例えば、開発プロセスだのという観点で言えば、同じSIでも、大企業が受注するようなものと比べれば相対的に小さめな規模のプロジェクトだとは思いますが、ユーザ企業と密に連携し、アジャイル的な手法を使ってイテレイティブに開発を行うことで、より短納期(手戻りを減らすことで)で、よりニーズにマッチした成果物を提供していくといった、新たなモデル?を模索しているようなベンチャーなんかがあることも知っています。その企業は、開発のための人材は全て自社で抱えて、いわゆる下請け企業に投げるといったことはしません(私が知っている限り)。基本的に一次請けだけやっているはずなので、社員一人あたりでみた時の収益もそれなりにあると思います。したがって、労働環境も少なくとも言及先の増田に書いてあるようなことはないはずです。

ただ、これをやるためにはユーザ企業側(発注元)の理解が必須で、単にアジャイル開発プロセスを導入すればいいという話ではありません。

で、同じようなことが、今の大企業が受注するようなプロジェクトでできるかと言えば、おそらく難しいでしょう。規模が違いますし、発注元の理解を得るというのも、まあ、難しかろうと。というか、現時点では理解してくれる企業のほうがマイノリティなのだと思います。

ま、なので大枠はウォーターフォールで、各工程の中にアジャイルな要素を取り入れるか、

あとは、こっちはまだ十二分に難しいと思いますが、最低限運用可能なレベルを満たしたところからスタートで、何回かインクリメンタルに?納品するというのを認めてもらうか(で、最初の一回はウォーターフォール)。

というのが現実的な落としどころかなーという気がします。
で、それが業界として当たり前になってくれば、業界全体の構造や体質も変わっていく、、、、といいですね。残念ながらここは自信がないです。開発プロセスの話以外にもいろんな力学が働いてると思うので。

ま、ただ、発注元企業の視点で考えてみると、発注をする部門は面倒なことはしたくないわけで、要件定義だけ付き合って、あとはよろしくね、ってのが、まあラクなわけです (発注する部門が必ずしも自社への利益を最優先とした行動原理で動いてるとは限らない)。

じゃあどうすればいいんでしょうね。私にもわかりません。

と、何を書いてるのかわからなくなってきましたが、補足でした。

追記2:
おおむねブコメを見ると叩かれているのですが、ちょっとこれは反論ないし説明しておきたいというものにレスします。

どんな部署でどんなことやっててどんな感じだったかを読みにきたんだけどチリほども情報がなかった

私のことでしたら退職エントリへのリンクを貼っておいたはずなのですが、それでは不足でしたでしょうか。

ブログがレスポンシブにすらなってなくて、「え、これスマホで読むの?」ってまず思っちゃった。そういうとこやぞ。

ご指摘はごもっともです。
私がPC向けのデザインを気に入っているというのと、スマホ用表示が無味乾燥としていて嫌だったので、PC用と同じ(のはず)表示がされるよう設定しています。
要は私の趣味です。

若い人が苦労したブログに乗っかって上から叩いてブクマ稼いで……そんなにいうなら自分はなんで辞めたのか

退職エントリへのリンクを貼ってあるのでご一読いただければ。

追記のがんばってカタカナ使いました感。合わない奴は合わないで済ませればいいのにSIとか邪推してマウント取る根性。

がんばってカタカタ使いました感は自分でも書いてて指摘されるだろうなと思いました。
まあ、ルー語みたいなもんだと思っておいて下さい。
あと、マウントをとろうとかは思っていません。本当に。
SIと邪推しているという指摘はごもっともだと思います。ただ、おそらく当たってはいると思います。

何がしたいかったのかさっぱり分からんw

自分でもそう思います。

レスポンシブデザインにしろよ 今時富士通でもやるぞ(たぶん)

上述の通り

部門によって全然違うのに就活真面目にやれば分かったはずとか、自分で矛盾言ってる事気づかないのだろうか

これですが、増田の人も、結果的に配属されるおおまかな部門(ざっくり、SIか、自社製品の開発か、研究所か)と職種(上記)は、採用を受ける前に想定できたはずなんです。なんかわかりにくいですね。
要はざっくりとしたくくりで見れば、希望したところ希望した職種で配属されるということが想定できたはず。
というのは、少なくとも私が採用された2010年の時点(リーマンショックやらのあおりで採用数が前年の半分?とかになっていた時)でも、面接の中もしくは内定後・入社後に職種(と、あと行きたい部署)の希望はとっていて、職種(詳細は伏せますが、ざっくりとSE、営業、研究開発(ソフトウェア希望なら、いわゆるソフトウェアエンジニア。SI部門には行かない)、その他)についてはごくごく少数の例外を除いては希望通りになっていたと認識していますし、希望部署も、感覚的には少なくとも6割ぐらいは希望通りになっていたように認識しています。別に集計したわけではないので確かなところはわからないですが、そんな感じでした。
新入社員の三年離職率?がかなり高くてやばいとかなんとか言われてる昨今(当時既に)なので、ミスマッチがあると、入社した人も不幸だし、会社からすると辞められちゃう可能性が高まるわけで、全然いいことないですから、人事も(少なくとも最初の)配属は、適当に決めたりはしません。
で、入社後のこのような流れは、FNHTあたりならどこも同じような感じだったはずで、ネットをあさるとか、OB訪問をする、研究室・ゼミの先輩に話を聞く、などで十分知り得たはずです。


情報収集ってどうやるの教えてください

ネットをあさるだけでも結構な情報は得られると思いますが、OB訪問や、内定が出て新年度から社会人、というような先輩に話を聞くのが一番でしょうね。

追記がさらに酷い。テスト駆動開発でも大規模開発出来る事を知らなさそう。

私が薄学で知らないだけなのかもしれないですが、アジャイル = テスト駆動開発なのですか?
まあ、それはさておき、アジャイルで大規模開発が出来るということであれば、私は知らなかったので勉強になります。
ついでに、ネットで参照できる事例なんかも教えていただければありがたいです。

元増田の記事をディスりと感じてしまうのはすごい。ただただ改善すべき点を述べているだけに見えるのだが。そういう声を上げられないような職場環境が富士通の衰退を招いたのかしら?

確かに言われてみればそうだなと思いました。
私が幼稚であったということだと思います。反省です。

自分で6割ぐらいは希望通りに配属っていうなら、元増田は残り4割だったかもしれないのに、就職活動まじめにやってなかった、って決めつけでdisるのはいくらなんでも元増田に対して失礼なのではなかろうか

書き方が分かりにくかったかもしれないですが、私が書いたこと、伝えたかったことの意図は、おおまかな希望した分野?の部署 (SI希望ならSI、自社製品の開発なら同様)に、希望した職種でほとんどの場合配属される、ということです。
そして、それで想定可能な範囲としては十分ではないか、と私は考えているわけです。
部署が違うと文化が違ってうんぬんっててめえが言ってるじゃねえかと指摘されると辛いところですが、ざっくりとSI部門と絞れればまあ、おおむね実態は想定可能だったと、私は思っています(増田の方がいたのがSI部門だったのかは確定事項ではないですが、ここまで書いてしまったので、それを仮定)。


追記3:
正直最初は増田の記事の一部をとりあげて、いいかげんに書いてしまったので、個別にコメントしときます。

開発環境がだめ

使う開発環境によって評価も変わる気はしますが、Chromeとかメモリ食いまくるし、時代と照らし合わせれば確かに低スペックだと思います。
ただ、まあ、高齢化してしまった大企業とかだとこんなもんでは?ぐらいの話のような気もします。
とりあえず、私はスペックが低くて、困ったなあ、と感じたことは特になかったです。

"Macなんか認めん!iOSアプリも富士通PCで作れ!(本当にあった話)。"
これはたしかにかなりアレ

机上環境もだめ

上述

事務室環境もだめ

やっている事業によってはこういう状況なのかもしれません。
不快に思うのは同意します。

評価制度の納得感がない

ごもっとも。
ただ、人事評価ってすごく難しいので、じゃあどうすれば良いのか、と考えてみるといいかなと思います。

古い方法へのこだわり

開発標準とやらは聞いたことがありません。
それ以外は上述。

"工程だけでなく、品質についても言及されている。例えば試験項目の品質はいかにバグが検出されたかで測られる。"
この考え方に疑問を持つ気持ちは良く分かりますが、品質管理?においては一般的?な考え方ではあります。
「バグ曲線」とかでググってみて下さい。

新しい方法・技術の導入の難しさ

上述

クラウドは私がいた当時はまだそこまで普及していなかった?ような気がするのでノーコメントで。

残業時間の評価

基本給が安くて、残業代で稼ぐモデルなのは確か。
でも、新卒で、独り身だとしたら、生活に困るほどでしたか?

ビルドは普通にmakeです。(ブコメでウケがよかったのでもう一度書いておきますね)

スキルと無関係の異動

部署が違うのでよくわかりません。

車輪の再開発してるんじゃね?って話は、まあ気持ちは分かりますが、ビジネスなので、食っていかないといけないので、と割り切ってやるしかないような気はします。

社外技術への関心のなさ

上述

なんちゃってフレックス

これは、増田の人のブコメに少し書いてありましたが、いろいろ事情があるそうです。
最初から今みたいな?ヘンテコなシステムだったわけではなかったないようです。

人が均質的

同意

でも尊敬できる人もたくさんいました。

個人時間のなさ

程度の違いはあれど、同意します。

未来のほの暗さ

同意

私はこうやって (10年前ぐらい) Googleに落とされた

書け、という天の声 が聞こえているひとがいるらしいので、私も書きます。

てめえ誰だよ、という声が聞こえてきそうなので、経歴やらのリンク貼っておきます。
プロフィール (神林亮)
業績 (神林 亮)

時期

10年前ぐらいです。

学生時代

詳細は上に貼った業績のページをご覧ください。
大学ではコンピュータサイエンスを学んでおりました。
ざっくり書くと、趣味でプログラム書いたり、研究活動に精を出したりしていました。

現職(当時)

富士通スパコン京をはじめとする、スパコン向けのジョブマネージャ・スケジューラの開発をやっていました。
退職エントリを昔書いたので、それでだいたい何やっていたかの説明になるかな、と思います。
富士通を退職してGunosyにjoinしました - Ryoの開発日記 Neo!

英語

修士に進学する時の入試で必要だったのでTOEIC 受けたときは750ぐらいだった気がします(2008年ぐらい)。
あと、学部一年の頃に一年やっていただけですが、塾講師のアルバイトで中学生に英語を教えていたのが案外自分の英語力向上につながったのか、おそらく英語圏でソフトウェアエンジニアとして働く時に最低限コミュニケーションはできるかな、という程度のスピーキング・ヒアリングはできました。

面接の準備

特にやってないです。
なお、応募はリファラルというやつで知人のGooglerに話を通してもらって、採用プロセスが開始しました。

面接

一次面接に相当するのか知らないですが、最初はなんか英語で電話がかかってきて、英語で応対しました。
応募書類に書いたはずなのですが、使える言語は?とか、特に弊社のやっている事業で関わりたいものはあるか?とかそんなことを聞かれた気がします。
私も英語ペラペラではないので、100%の意思の疎通はとれていなかったと思いますが、まあ70%程度は理解して質問に回答できていたと思います。
あとから考えると、その人は人事の人だったんだと思います。

で、採用プロセスを進むことができたのか分からんですが、次はエンジニア(日本人)とのリモートでの面接で、Google Docsとか使って、コーディング面接的なことをさせられたり、プログラミングからは少し離れた(ソフトウェア開発の範疇ではあったと思いますが、)何かよくわからないアクロバティックな質問をされて、それぞれ、一応回答はできました。
ですが、手ごたえは正直微妙、という感じでした。
一筆も書いた覚えはないのですが、この面接の開始時にNDAを結んでいるので面接の内容は他言無用だと言われましたが、他のGooglerのエントリからすると、この程度は書いていいのかな、と思って書いています。
落とされたやつは、社内の人間とは扱い違うから、とお叱りが来て、数日後には消しているかもしれません。
魚拓でもとっておいてください。

面接後

ダメもとだったので受かったらラッキーぐらいの感じで結果を待ってましたが、最初の人事の方から今回は縁がありませんでしたとお電話をいただきました。
あえて炎上しそうなことを書いておくと、地頭には自信ないですが、高校時代からプログラミングをやったりして、(当時の)同世代と比べればスキルはそれなりにあると自負していたところもあったので、少しショックでした。

振り返って

現職に不満ないので、つぶれたりしない限りは転職するつもりはないです。
ただ、Googleは何度も採用を受けて入社するという強者も多いそうだし(友人にもいる)、死ぬまでに「俺、Googlerだぜ」って言ってみたいという思いはあったりするので、いつかまた採用を受けることがあるかもしれません。
 
その時はGoogleさん、よろしくお願いいたします。

Python製WebRTC ライブラリ aiortc のデータチャネルを介したファイル転送を行うサンプルプログラムを動かしてみる

qiita.com

Windows環境のpython(2.x系列)でstdinからstdoutにデータを流し続けるプログラム(バイナリ対応)

https://qiita.com/ryo_grid/items/60a1b1873192e16d2d0e

Signal Subspace法(カーネルPCA)を使って音声データのノイズ除去(音声強調)をやってみた

https://qiita.com/ryo_grid/items/6ae473d42595f7a8ff1b

MMSE-STSA法の音声強調・ノイズ除去をJSにポーティングしたがあと一歩うまく動かない話

https://qiita.com/ryo_grid/items/7e31449ddef5ab5681f7

チームでの趣味ソフト開発ノウハウ -マイクロブログホスティングサービスUZOMUZOの開発を通して-

http://qiita.com/ryo_grid/items/117604c35493406b3644