筑波大のOB・OGはGoogle Driveを容量無制限で使えるらしい

なんか筑波大OB・OGはGoogle Driveを容量無制限で使えるらしい。
嘘のような本当の話。
　
同窓の友人が試して実際にアカウント発行してもらえたらしい（そもそも、その友人がこの情報のネタ元）ので、事実であることは確認済み。
　
では、なぜ、掲題のようなうまい話があるのか、という理由なのですが、
"交流広場"という現役生・OB・OG・教職員・教職員のOB・OG等が交流できる筑波大学が運営しているSNSがあって、

筑波大学交流広場

その利用アカウントとしてG Suite for Educationでメールアドレスを発行していて（発行する側は、生涯メールアドレス、と呼称しているので、基本的にはずっと使えるようにしておくことを想定しているのでしょう。しかし、生涯というキーワードはインパクトあるなあ）、そのメールアドレスにはGoogleアカウントがくっついてるので、それでGoogle Driveが使える、という話のようです。
　
mast在学中に使えるソフトウェアライセンスを紹介！Microsoft Office 365, Google Drive, Windows - MAST Web

f:id:kanbayashi:20190824091236p:plain
Gmail, Google Drive等についての記述
　
で、SNSの利用規約を確認すると、
https://alumni.tsukuba.ac.jp/openpne/web/default/userAgreement
===
（会員）
第4条　次の各号に掲げる者は、別に定める本サービスの会員登録の申請をし、認められた場合、会員として本サービスを利用することができる。
(1)　本学（前身校を含む。）の卒業生、修了生及び元教職員
(2)　本学に在籍する学生及び教職員
(3)　その他本学が認めた者
===　
　
とあり、在学中から利用していること、という要件は別項でも書かれていないので、卒業済みでもアカウントを発行してもらえるというのは、間違いないようです。
　
ちなみに、申請にあたっては、入学年度と在籍した学群と学類もしくは、研究科と専攻をちゃんと覚えていれば大丈夫なのでご安心を（学生番号とかは求められない）。
　
ま、難しい話はさておき、交流広場ってなんか面白そうだから使ってみよー。
　

Unityでお盆に作っていたレトロゲームモドキが完成した

Unityで作っている「砦の攻防」モドキですが、もうこれは完成と言ってもいいのでは？なところまでできたっす。
操作は十字キーの左右で射出パワーを調整、上下で角度調整、スペースキーで発射。
一回発射すると相手のターン。ターンは画面左上、右上の射出時のパラメータの表示のところの左に＠マークがあるかで判断します（＠がある方がターン中）。
障害物は弾が何度か当たると消えます。
弾の速度が速いと、一発でぶち抜かれます。
　
基本は2人で遊ぶようにできていますが、一緒に遊ぶ人がいない人が一人でも遊べるように数字の1を押すことで1Playerモードと2Playerモードを切り替えられるようにしてあります（１回押しただけでは切り替わらないことがあるので、その時は何度か押してみて下さい）。
　
※特に確認とか出ずに、音が流れるのでご注意下さい
ryogrid.net


　
※PCブラウザ用に作ってあるのでスマホだと動かない場合も多いと思います。
また、キーボードで操作するように作ってあるので、Bluetoothでスマホにキーボードを接続して操作するとかしないと、そもそも動作しても操作できません。
　
・残TODO

  • 【済】勝負がついたときの残存障害物のクリアが実装されてないので、一回勝負がついても、残っている障害物は次の回も持ち越しで、新たに障害物が追加で生成されてしまう
  • 【済】砲身を角度に合わせて出したい（分かりにくいので）
  • 【済】砲身の角度調整処理がたまにおかしくなるというのが、利用している方法の都合で起きていたので、それを回避するためにiTweenというアセットを利用して、書き直した。
  • 【済】障害物に耐久度を設けて、耐久度に応じてだんだん色が透明に近づいていくとかしたい。残耐久度の更新は、弾が当たった時の弾の速度を得る方法は分かっているので、それで力積とか求めてよろしくやってやればいいはず
  • 【済】セルフキルが起きないようにした
  • 【済】弾の運動エネルギーがブロックを破壊しても残っている場合はそのまま突き進むようにした
  • 【済】弾がブロックの上で停止してしまった場合に、よろしく消えるようにした
  • 【済】BGM と 各種サウンドを実装した
  • 【済】1Playerモードを実装した

　　
githubリポジトリ
github.com
　
ものほんではないが、かなり再現度の高い「砦の攻防」クローン
www.nicovideo.jp
　
Unityは今回はじめて、それなりにまともに使いましたが、今回のプログラムだと、物理計算とか全部Unityにお任せするとやってくれたりするのは楽ですなー（弾道計算とか）。

プログラマのコードの生産性は何によって決まるのか

タイトルはいくらか誇大に書いてますw

以下では、もう少し因子？を絞って書きます。
要は地頭（頭の良さ）の部分ですね。

前提

・知識や経験は同じものとする

本論

ぶっちゃけて言ってしまうと私はコード書くのは遅い方だと思います（同じだけの経験・蓄積のある人間で比べれば）。

じゃあ、その差はなんで生まれるのか自分なりに分析してみたことがあるのですが（論文とかまで調べたわけではないです）、大雑把にくくれば地頭の出来とかになるのかなと思うのですが、それだと大雑把過ぎるし、地頭といってもいろんな要素があるし、IQが高ければ生産性が高いの？って言うと、なんか違うような気がしたんですよね。まあ、他の人のIQなんて知らないので、気がしたってのもいい加減な話なのですが。

で、結局、私が考えた限りでは、ワーキングメモリの量が、生産性を決める因子？として大きいのではないかとという結論に至りました。

ja.wikipedia.org

なお、この記事を書く時にぐぐってみましたが、日本語圏だと、以下のQiita記事でもワーキングメモリに言及しているのを見つけました。

qiita.com
　
自分の場合、おそらくワーキングメモリがあまり大きくないので、コード書く時に定義済みの関数や変数をいちいち見返したりするのに結構時間を食っている気がします。
また、コードベースがそれなりに大きいとソースファイルの数も多くなってると思うのですが、さっき確認したソースファイルの中身、どんなだったっけな、とか忘れて、読み返したりも多い気がします。

プログラマって、実はコード書いてる時間より、他人のコードを読んでる時間の方が多かったりする、とかいう話もあったりしますが（要出典）、上記と同じようなことが起きるので、これもやはりワーキングメモリの多寡でパフォーマンスが変わるのではないかと思います。
(なお、ワーキングメモリは鍛えることが一応でき、Qiita記事で言及されているNバック課題とかいうが一つの方法で、私もそれができるソフトだかサイトだかで1-2週間ほどトレーニングを試みたことがありますが、面倒くさくなってやらなくなってしまいました）

しかし、そういう人間を助けてくれる強い味方もいて、まあ、IDEってやつですね。
クラスやオブジェクトのメンバ補完であるとか、開いているファイル内で定義されている関数や変数を脇のペイン？とかに出してくれるのも助かりますね。
変数名・関数名の補完もしてくれますし（IDEじゃなくても、できますけど）。
標準ライブラリや、import することで（importというキーワードを利用しない言語は読みかえて下さい）使えるクラス名や関数名なんかも最近は補完して、よろしくimportしてくれたりします（確か）。

ただ、この手のIDEでのサポートって静的型付け言語の方がやりやすくて（IDEがコード解析やらなんやらしやすい）、動的型付けだと例えばPython用 IDEの PyCharm とかかなり良くできていますが、静的型付け言語と比べるといくらか（結構？）落ちます。
私はどちらかというと静的型付け言語の方が好きなのですが、IDEでのサポートの受けやすさってのも、あまり意識したことなかったですが、理由としてあるのかもしれません。

あと、知名度の高いようなトッププログラマ（？）が、IDEとかあまり使ってなくて、EmacsやVimとかにこだわるのは、そもそもIDEによるサポートとかあまり必要のないワーキングメモリの持ち主だから、なんてこともあるのかなとか思いました。

特に良いオチはないのですが、以上です。

いや違うだろ！などコメントあればどしどしお寄せください！

余談:
IQ値の多寡とワーキングメモリの多寡って相関はありそうですが、どれぐらいあるんでしょうねー

追記:
ちゃんとぐぐったら日本語のWebページでもこの手の話が既にいくつかあったので関連ページとして貼っておきます
プログラミングの効率アップの鍵はワーキングメモリだった | リバティドック
プログラムのアルゴリズムを理解するのって脳のワーキングメモリが結構重... - Yahoo!知恵袋
プログラミング学習と脳の使い方～本当に正しい学習してるのか？

ガウス過程での回帰についていろいろやってみた成果物？のまとめ

ガウス過程での回帰のコード（1スカラ入力)はサンプルコードを3つ動かしてみたのだけど（3つめは多次元入力のコードもあった）、3つめの多次元対応は最初にやったやつでもうまくいくか気になって、修正したらできたので、どちらも要はやってることは同じそうだ、ということが確認できた。
　
ryogridJupyterNotebooks/gaussian_process_regression_sample_org_0606_umakuikanai_huniki.ipynb at master · ryogrid/ryogridJupyterNotebooks · GitHub
　
最初にやったやつを修正した版
ryogridJupyterNotebooks/gaussian_process_regression_sample_org_0606_umakuikanai_huniki.ipynb at master · ryogrid/ryogridJupyterNotebooks · GitHub
　
少し前にQiitaに書いたガウス過程での回帰に関するなんちゃって解説記事
qiita.com

論文 "DEEP NEURAL NETWORKS AS GAUSSIAN PROCESSES" に少し目を通した

いきなり読んでも意味不明なので、掲題の論文をネタ元にしている
machine-learning.hatenablog.com
を読んで可能な限り理解を深めた後で、掲題の論文の肝心そうなところに目を通した。

"DEEP NEURAL NETWORKS AS GAUSSIAN PROCESSES"
Jaehoon Lee, Yasaman Bahri, Roman Novak , Samuel S. Schoenholz,
Jeffrey Pennington, Jascha Sohl-Dickstein (members of Google Brain) , ICLR 2018
https://arxiv.org/pdf/1711.00165.pdf

あるディープなL層のNNがあった時に、最終的にはそれに対応するガウス過程（以降GP）での回帰をするための共分散行列K{L} (カーネル?) を作れば、それで同じように学習・推論できるで、って話のようだ。
で、その最終的な共分散行列K{L}を得るためには (論文の2.5節参照) 、ざっくり言うと、NNを一段目から追って行って、それに合わせて F（ラージエフ) なる行列を求めて、それをなんかよくわからんけどよろしくそこまでに求めた共分散行列K{l - 1} (lはその時計算している？層）に反映していくというステップをL回やる、と。
あとは、GPでの普通のやり方？で K{L} を使って学習・推論（回帰？）すればよろしい、と。
で、この論文の contribution の一つは上の記事にも書いてあるけど、GPでの推論（回帰）に必要な共分散行列を、一つの共分散行列 K{l} に集約させることで、学習も推論もおおむね行列演算一発 (実際には一回では済まないけど、複数のKを扱う必要はない) ようにしたってことらしい。
　
評価に置いては、MNISTとCIFARに対するDNNと、それらに対応するGPのカーネル？モデル？を構成して、それでモデルの評価をしたら、DNNよりパフォーマンス良いときもあったで、とか書いてるので、結構まともな（？）DNNについても、対応するモデルが構成できるっぽい、です。
　
まあ、ちゃんと理解できたとは思わないですが、こんな感じでした。

しかし、GPって遺伝的プログラミング？って思っちゃうので、どっちか略記を変えた方がいいのではないかと思う（暴論）。

SonyのGUIでポチポチするだけでディープラーニングできる Neural Network Console が思っていた以上に良くできている件

最近知人が使ってみていて、それを聞いていくらか調査してみたんですが、Sony の Neural Network Console (以降、NNコンソール) 悪くないです。
コードを書かずにお手軽にディープラーニング試してみたい、ってことであればかなりおすすめです。
dl.sony.com

　
結構本格的なネットワークが組めるようですし（対応しているレイヤも結構豊富）、これで作った（ネットワークを構成して学習した）推論（予測）モデルを、Python で使って推論をする、とか、コマンドラインツールに食わせて推論をする、とかもできます。(学習時は少なくとも) GPUも使ってくれます。
GUI持ってるネットワークをポチポチするアプリ本体(?)はダメかと思いますが、それ以外のコマンドラインツールや、NNコンソールで作ったモデルを使ってあれこれするライブラリとかはLinuxでも動きます（自分が調べた限り）。

特に、作成したモデルを、ちゃんとライブラリやCLIツールで使えるようにしてるあたりが、（実用を前提とした場合）よく考えられているなと感心しました。
　
あと、基本的には全て（のはず）OSSで公開されているのもナイスです。
　
なお、GUIアプリ使わなくても、コマンドラインツールを使ってネットワーク設計(?)、学習もできるようです。
　
ネットワーク設計だけGUIアプリでやって、その結果をファイルに出力して、コマンドラインツールに読み込ませたうえで学習する、という形をとれば、学習処理を、AWS の GPUインスタンスや Google Corabolatory (GPUやTPU が搭載されてて、無料で使える機械学習用クラウド) で、高性能なGPUを活用して行うということも可能なはずです。
　
ネットワークの設計って、Kerasなんかの抽象度を高くした？比較的利用難易度の低いライブラリを使っても、やれテンソルの次元が合わないだとなんだとか言われて、苦労したりするんですが（少なくとも私はそうだった）、NNコンソールがそこらへん親切にエラーとか出してくれるとか、よろしくつじつまが合うようにサポートしてくれる、とかなら、ネットワークの構成だけに使うというのも一考の価値があるかもしれません 。ONNXという多くのディープラーニング用フレームワークがサポートしている共通規格のフォーマットで、設計したネットワークの構成情報をダウンロードすることもできるようです。

Scene Explorer Mac build

Environment

  • MacOS Mojave 10.14.4
  • Qt 5.12.3
  • clang++

$ clang++ --version
Apple LLVM version 10.0.1 (clang-1001.0.46.4)
Target: x86_64-apple-darwin18.5.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

  • xcode のツールセット？
    • /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk
  • ffmpeg

$ ffmpeg --version
ffmpeg version 4.1.1 Copyright (c) 2000-2019 the FFmpeg developers
built with Apple LLVM version 10.0.0 (clang-1000.11.45.5)
configuration: --prefix=/usr/local/Cellar/ffmpeg/4.1.1 --enable-shared --enable-pthreads --enable-version3 --enable-hardcoded-tables --enable-avresample --cc=clang --host-cflags='-I/Library/Java/JavaVirtualMachines/openjdk-11.0.2.jdk/Contents/Home/include -I/Library/Java/JavaVirtualMachines/openjdk-11.0.2.jdk/Contents/Home/include/darwin' --host-ldflags= --enable-ffplay --enable-gnutls --enable-gpl --enable-libaom --enable-libbluray --enable-libmp3lame --enable-libopus --enable-librubberband --enable-libsnappy --enable-libtesseract --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265 --enable-libxvid --enable-lzma --enable-libfontconfig --enable-libfreetype --enable-frei0r --enable-libass --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-librtmp --enable-libspeex --enable-videotoolbox --disable-libjack --disable-indev=jack --enable-libaom --enable-libsoxr
libavutil 56. 22.100 / 56. 22.100
libavcodec 58. 35.100 / 58. 35.100
libavformat 58. 20.100 / 58. 20.100
libavdevice 58. 5.100 / 58. 5.100
libavfilter 7. 40.101 / 7. 40.101
libavresample 4. 0. 0 / 4. 0. 0
libswscale 5. 3.100 / 5. 3.100
libswresample 3. 3.100 / 3. 3.100
libpostproc 55. 3.100 / 55. 3.100

  • ffprobe

ffprobe --version
ffprobe version 4.1.1 Copyright (c) 2007-2019 the FFmpeg developers
built with Apple LLVM version 10.0.0 (clang-1000.11.45.5)
configuration: --prefix=/usr/local/Cellar/ffmpeg/4.1.1 --enable-shared --enable-pthreads --enable-version3 --enable-hardcoded-tables --enable-avresample --cc=clang --host-cflags='-I/Library/Java/JavaVirtualMachines/openjdk-11.0.2.jdk/Contents/Home/include -I/Library/Java/JavaVirtualMachines/openjdk-11.0.2.jdk/Contents/Home/include/darwin' --host-ldflags= --enable-ffplay --enable-gnutls --enable-gpl --enable-libaom --enable-libbluray --enable-libmp3lame --enable-libopus --enable-librubberband --enable-libsnappy --enable-libtesseract --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265 --enable-libxvid --enable-lzma --enable-libfontconfig --enable-libfreetype --enable-frei0r --enable-libass --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-librtmp --enable-libspeex --enable-videotoolbox --disable-libjack --disable-indev=jack --enable-libaom --enable-libsoxr
libavutil 56. 22.100 / 56. 22.100
libavcodec 58. 35.100 / 58. 35.100
libavformat 58. 20.100 / 58. 20.100
libavdevice 58. 5.100 / 58. 5.100
libavfilter 7. 40.101 / 7. 40.101
libavresample 4. 0. 0 / 4. 0. 0
libswscale 5. 3.100 / 5. 3.100
libswresample 3. 3.100 / 3. 3.100
libpostproc 55. 3.100 / 55. 3.100

Procedure

Disclaimer

  • information above made MacOS build success at 2019/05/25
  • but I do not know in the future and I will not do maintanance of my forked repository

LL言語のGIL (グローバルインタプリタロック) がなぜあるか

　掲題の通り、LL言語のGIL (グローバルインタプリタロック）がなぜあるかという話。
　
　なお、以下は全てのLL言語で同様のことが言えるとは限らない、かつ私の認識が誤っている可能性もある、という disclaimer を初めに書いておきます。
（専門家の方々にいいかげんなこと言うな、とか叩かれそうですが、お手柔らかにお願いします・・・）
　
　要はLL言語のランタイム & 標準ライブラリ？ の実装で利用しているライブラリ（ランタイムだったらlibcとか、標準ライブラリだったら、それらが内部で利用している、プラットフォームに存在する各種ライブラリ）の関数がスレッドセーフかどうかいちいち調べて対応する工数がパないからGILで解決してしまえ、って話のようである。
（普及してしまった段階においてGILの必要性について考える場合は、サードの提供するライブラリも考慮しないといけないでしょう）
　
　スレッドの実装が行われた時点で既にそうだったかは分からないですが、例えばPythonやRubyなんかは多様なプラットフォームで動作する実装を提供しているので、合理的な割り切りだとは思います。そんなところではなく、他のところにマンリソースを割くべき、という判断でもあったのでしょう。なので、怠慢だ！とか単純にディスれる話ではないと思っています。
　
　あとは、仮にGILを使わなくて済む実装ができて（少なくともランタイム部分については）、標準ライブラリについても、"スレッドセーフではない可能性があります" とか、ちゃんとドキュメント化できたとしても、サードのライブラリが同様の対応をしてくれると期待するのは難しいだろうし、それが成されたとしても、スレッドを使うときに、利用する関数がいちいちスレッドセーフかどうかとか意識して、コードを書かないといけないというのは、LL言語のポリシー的なところとか、想定される利用者層、用途を踏まえると、ただ使いにくいだけ、になりかねないという判断もあった（ある）のかな、と思います。
　
　ただ、なんかもにょるな、ということが言いたかっただけです。はい。
　
　ちなみに、Rubyで言うと、MRI ( Matzらのリファレンス実装 ) は GIL がありますが、JavaによるRuby実装である JRuby は GILが無いそうです 。あとは、詳しくは知らないですが、 Rubinius という処理系も無いそうです。JRubyなんかは以前から存在を知っていましたが、最近、GILが無いというのを知って、結構衝撃を受けました。
　なお、JRuby や Rubinius という GIL の無い実装が存在するからといって、MRI も簡単に GIL を無くせると言っているわけでも、思っているわけでもないです。そこは強調しておきます。
　
追記:
CやらC++やらだとメモリモデルがちゃんと定められてなくてつらたん、って事情もありそうですね。
https://www.ibm.com/developerworks/jp/java/library/j-jtp02244/index.html

これとは対照的に、CやC++といった言語には明示的なメモリ・モデルはありません。

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

Copyrightとライセンス

動作環境

サーバ

  • 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