MagicOnion勉強会を開催しました

2019-06-14

【Unity / .NET Core】 MagicOnion勉強会。正確には開催してもらいました、ですが！バーチャルキャストさん、ありがとうございました！

こちらは私のスライド、 The Usage and Patterns of MagicOnion になります。

The Usage and Patterns of MagicOnion from Yoshifumi Kawai

実際何に使えるの、というところについて（妄想の）繋ぎ方を紹介したりしました。まぁ、ようするになんでも使えます、ということですね。

MagicOnionはGitHub Starも1000超えたので、野良ぽっと出謎ライブラリからは、少し脱却したんじゃないかと思います。まだメジャー級とは言い難いですが。アングラ級？

私はP2P推すのどうかなーって思ってるわけなんですが、その理由はポジショントーク、じゃなくて自分がサーバー書けるから、ってのは勿論あるんですが、本当にP2Pでいいんすかねー、というのがあり。実際真面目に。リレーサーバー用意するんだったらもう自前でやる領域を秒速で超えちゃうし、P2P→Dedicated Serverだと、機能制限されたサーバーモデル(サーバーがリレーとしてしか機能できなくてロジック積んだりモロモロができない）になっちゃうので微妙に感じたり、結局自前でやるならP2Pでもマッチングどうすんねんであったり、まぁもろもろ色々と。信頼できるクライアント -> サーバーのRPCが一つあるだけで、色々すっきり解決できるんじゃないのかなー、ってのはずっと思っているところで。

MagicOnionに問題がないとは言わないんですが、特にネイティブDLLは問題の塊なのでPure C#実装に変えたいねえ、そうすればプラットフォームの制限もなくなるしねえ、とかもあったりはあったりはあったりはしますが、まぁそのうちなんとかします:) コード生成に関しては肯定的なんですが（リフレクション拒否した非コードジェネレーションのモデルは、やれることにかなり制約入りますですのです）、現状のヘボジェネレーターはよろしくないのでそれも早急に直しまうす。インフラ系はドキュメントとかの拡充でカバーですかね、知識がいるのは事実なので。

発表一覧

勉強会レポ : 【Unity / .NET Core】 MagicOnion勉強会さんのところにまとまっているのですが、こちらでも改めてリンク集で。

これだけトークが集まって、大感謝です。

第二回の開催、は（あるとしても）当面先だとは思いますが、実際MagicOnionを使用した開発に入っているプロジェクトは割とないわけではない（？）という感じですので、ご安心を（？）。一応歴史的にはかなりの負荷を捌いている実績もあるので……！Cysharpとしても、「会社として」力を入れているところがあるので、その辺も安心材料に含めていただければと思っています。最悪、本当に困ったらお問い合わせ下されば色々解決のお手伝いもできるかもしれません。

また、CEDEC 2019ではUnity C# × gRPC × サーバーサイドKotlinによる次世代のサーバー/クライアント通信〜ハイパフォーマンスな通信基盤の開発とMagicOnionによるリアルタイム通信の実現〜と第して、アプリボットさんと共同でセッションを行うので、そちらも是非是非。

LitJWTに見るモダンなC#のbyte[]とSpan操作法

2019-05-27

LitJWT、という超高速な認証ライブラリを作りました。

github.com/Cysharp/LitJWT

なんと今回はUnity用が、ない！どころか.NET Standardですら、ない！.NET Core専用になってます（今のとこ）。理由はパフォーマンス都合で現状.NET CoreにしかないAPIを使いすぎたので修正が面倒ということなので、そのうちなんとかするかもしれませんかもしれません。

5倍高速

そもそも認証ライブラリでパフォーマンス追求しているものなんてない！ので！まぁそりゃそうだという感じではある。実際、そこまで認証で必要か？というと疑問符が付くところなので、ただのオーバーエンジニアリングなのですが、とはいえ速いというのは良いことです。シンプルに。

JWTに関しては特に説明することもないので（セッションにでも何にでも使えばいいんじゃないかしら、実際、私はMagicOnionのステートレスセッションのために必要なので用意しました）、ここから先は実装の話をします。

モダンBase64(Url)

JWTは大雑把にはJSONをBase64Urlでエンコードして署名を引っ付けたもの、です。Base64UrlというのはBase64の亜種で、URLセーフになるように、使う文字列が少し異なります。性質上、GETでURLにトークンが引っ付いたりするかもですしね。なるほど。

さて、しかしそんなマイナーなBase64Urlをエンコードするメソッドは用意されていないので、普通はこんな風に書いてます。

Convert.ToBase64String(input)
    .TrimEnd('=')      // 新しいstringを作る
    .Replace('+', '-') // 新しいstringを作る
    .Replace('/', '_') // 新しいstringを作る

改めてBase64Urlは、ようするにパディング（4の倍数に収まらない場合に末尾につく)の=が不要で、+が-、/が_なBase64なので、置換！ただたんに置換！する、すなわち新規文字列を無駄に作成！無駄に検索して無駄に作成！なわけです。

実際、別にこのBase64の変換表の一部を差し替えるだけの話なのに。

無駄すぎて発狂しちゃうので、ここは普通に自前でBase64を実装することで大解決しましょう。実際それしか方法はない、しょうがない。

せっかく作るので、今風のAPIにしましょう。例えばデコードのAPIはこんな感じに。

public static bool TryFromBase64UrlString(string s, Span<byte> bytes, out int bytesWritten)
public static bool TryFromBase64UrlChars(ReadOnlySpan<char> chars, Span<byte> bytes, out int bytesWritten)
public static bool TryFromBase64UrlUtf8(ReadOnlySpan<byte> utf8, Span<byte> bytes, out int bytesWritten)

stringだけ受け入れるのではなくて、ReadOnlySpan<char>と、UTF8を直接受け入れられるようにReadOnlySpan<byte>のオーバーロードを用意しましょう（面倒くせえ……）。中身の実装はcharとbyteで似てるようで若干違うので今回は雑にコピペコードで済ませてます。コピペ最強。

ともあれこれでゼロアロケーションなデコードです。

ちなみにSystem.Security.Cryptographyも、こうしたSpan対応のAPIが(.NET Core 2.1なら)あります。.NET Standard 2.0にはありません。2.1から、なのでまだ先です。

bool TryComputeHash(ReadOnlySpan<byte> source, Span<byte> destination, out int bytesWritten)
bool TrySignData(ReadOnlySpan<byte> data, Span<byte> destination, HashAlgorithmName hashAlgorithm, RSASignaturePadding padding, out int bytesWritten)
bool VerifyData(ReadOnlySpan<byte> data, ReadOnlySpan<byte> signature, HashAlgorithmName hashAlgorithm, RSASignaturePadding padding)

今回の最初のリリースが.NETCore Appのみなのは、主にこの辺が理由です。迂回できないこともないんですけどねえ。

stackallocとArrayPoolをめっちゃ使う

先のBase64のデコード繋がりで説明すると、デコード先のbyte[]をどう用意するか、という話であり。headerのBase64とかsignatureのBase64とか、あまり大きくないのが確定しているので、stackallocをSpanで受けて、デコード先を作ります。

Span<byte> bytes = stackalloc byte[Base64.GetMaxBase64UrlDecodeLength(header.Length)];
if (!Base64.TryFromBase64UrlUtf8(header, bytes, out var bytesWritten))

Payloadは長さがわからない（そこそこ大きい可能性もある）ので、stackallocで受けるのは不安があるので、ArrayPoolを使いましょう。

var rentBytes = ArrayPool<byte>.Shared.Rent(Base64.GetMaxBase64UrlDecodeLength(payload.Length));
try
{
    Span<byte> bytes = rentBytes.AsSpan();
    if (!Base64.TryFromBase64UrlUtf8(payload, bytes, out var bytesWritten))
    {
        return DecodeResult.InvalidBase64UrlPayload;
    }
    bytes = bytes.Slice(0, bytesWritten);

    // ....
}
finally
{
    ArrayPool<byte>.Shared.Return(rentBytes);
}

ようするに、今どきnew byte[]なんてしたら殺されるぞ！

ReadOnlySpanの辞書を作る

ReadOnlySpan<byte>はref struct！つまりDictionaryのKeyにはできない！けどルックアップはしたい！

どーいうことかというと、例えば

HeaderのJSONを舐めて、デコードに使うアルゴリズムが何であるかあるかチェックしたいわけですが、まず、今どきはJSONをstringで検索したりはしません。UTF8のままやります(System.Text.Json(preview)やUtf8Jsonを使いましょう)。特に、今回はBase64Urlからデコードしてきたバイナリなので、更にstringにデコードしてしまうのは無駄の極みなので、絶対避けたいわけです。

そうして、algのvalue部分に相当するReadOnlySpanが切り出せたとしましょう。さて、じゃあこれが何であるか。HS256なのかRS512なのか、そして、それをキーにしてIJwtAlgorithmを取り出したいわけです。必要なデータ構造はDictionary<ReadOnlySpan<byte>, IJwtAlgorithm>>なわけです。が、それは無理。C#の言語仕様がそれを許してくれないのです。困ったねえ。

もちろん、答えは自作しましょう。今回はReadOnlyUtf8StringDictionaryというものを用意しました。Dictionary内部で持っておくキーは別にSpanである必要はないので、普通にbyte[]で確保しておきます。ルックアップだけ

public bool TryGetValue(ReadOnlySpan<byte> key, out TValue value)

というAPIを用意すればOKという寸法です。

実装において、byte[]の一致比較はSpanのSequenceEqualを使えば良いんですが、GetHashCodeの実装だけはどうにもなりません（Utf8Stringも控えてることだし、標準でいい感じのがそろそろ入るといいんですけどねえ）。私は延々と使いまわせいているFarmHashの実装をコピペで用意していますが、適当にxxHashを実装したり何かするといいと思います。適当に拾ってきたものを使うとパフォーマンス的に意味のないクソ実装の可能性もあるので、その辺は適当に気をつけましょう。

最後まで配列の切り出しをしない実装を作る

jwtEncoderのEncodeメソッドは、3つのオーバーロード(名前違い含む)を持ってます。

string Encode<T>(...)
byte[] EncodeAsUtf8Bytes<T>(...)
void Encode<T>(IBufferWriter<byte> writer, ...)

一番使うのは、stringだとは思います。Httpのヘッダーとかに埋めたりするケースが多いと思うので、stringが要求されるのでしょーがない。でも、byte[]を返すもののほうが高速です。内部的には全てUtf8 byte[]で処理しているので、stringへのエンコード処理をバイパスできるからです。例えばgRPCは(MagicOnionも)、バイナリヘッダーを許容しているので、stringヘッダーよりも高速に処理できます。

// gRPC Header
var metadata = new Metadata();
metadata.Add("auth-token-bin", encoder.EncodeAsUtf8Bytes());

さて、じゃあ最後の IBufferWriter<byte> はなにかというと、直接これに書き込みます。まぁ、Span<byte>,int bytesWrittenみたいなものですが、Span<byte>を渡すのが使えるのって、処理後の長さが概ね分かっているときで、JwtのエンコードはPayloadの処理とかあるので、基本的には処理が完了するまで分かりません。ので、bytesWritten形式のAPIは向いてません。

IBufferWriterはStreamみたいなもので、これに直接書き込みます。新しいI/O APIである System.IO.Pipelines で使われているAPIで、つまりは、一応それに対応しているということで。MessagePack-CSharpのv2(現在絶賛制作中)も、IBufferWriterが主役になっています。時代はダイレクトライト。

System.IdentityModel.Tokens.Jwtは最低

JWTの話は特にするつもりはなかったんですが、とにかくSystem.IdentityModel.Tokens.Jwtが最低だということは言っておきたい！とにかくAPIがヤバい！まぁ、これ、他の認証系も統合された抽象化の上に乗っているので、JWT的に不要で意味不明なものがいっぱいついているうえに、その抽象化がエンタープライズグレード（笑）の重厚長大な酷いもので、Microsoftの認証が難しいと感じるとしたら（実際難しい）、ただたんにライブラリのAPIが腐ってるから難しいだけですからね。

何かのフレームワークと統合されてて、ワンポチで導入される、とかだったらまだいいんですが、直接は触りたくないですねえ。誰が作ってんだかって感じですが(お、公開されてる先はAzure配下かな……)

まとめ

MagicOnionで――というのもありますが、認証系はJWT中心に、ちょっと色々考えてます。あとまぁ、さすがにパフォーマンスだけが差別化要因というのはしょっぱいので、Unity対応しよ。

MagicOnion Ver 2.1.0

2019-05-14

MagicOnionのVer 2.1.0を出しました。前回が2月28日なので、3ヶ月ぶりで少し間が空いてしまった感じもありますが、色々良くなったので紹介していきまうまう。

StramingHubClientでメッセージが詰まるバグの修正

いきなり致命的な話なんですが、StreamingHubClientが1フレにつき1メッセージしか送信されないという、しょうもないバグが存在していました。このバグの原因が面白くて（？）、元はこんな感じのコードだったんですよ。

// readerはIAsyncEnumeratorというMoveNext, Currentでデータを取ってくる非同期イテレーター
while (await reader.MoveNext())
{
    var message = reader.Current; // byte[]
    OnBroadcastEvent(message);    // messageは実際にはヘッダ解析したり色々してます
}

gRPCはIAsyncEnumeratorというかっこつけたインターフェイスを採用しているので、awaitでサーバーからデータが届くのを非同期で待機できる。

で、このawaitが問題で、UnityだとUnitySynchronizationContext経由してawaitの先が実行されます。なので安全にメインスレッドでOnBroadcastEvent(これは最終的にユーザーが実装したインターフェイス定義のメソッドが呼ばれる)が呼ばれて嬉しい。のですが、reader自体は別スレッドで動いているので、awaitの度にメインスレッドへの同期を待っているのです。

正確にはUnitySynchronizationContextがawaitの度にメインスレッド上だろうがなんだろうが問答無用で次フレームに叩き込む仕様だから、なのですけれど。

何れにせよ、そんなわけで、サーバーから同一フレームで沢山のデータが送られてきたとしても、クライアント側は1フレームに1メッセージしか捌けないので、どんどん詰まっていくわけです。もちろん、バグです。仕様じゃなく。普通に。バグ。

var syncContext = SynchronizationContext.Current;

// ConfigureAwait(false)でSyncContextを外して、このループはずっと別スレッドで動かす
while (await reader.MoveNext().ConfigureAwait(false))
{
    var message = reader.Current;
    if (syncContext != null)
    {
        // 手動でPostする（待たない）
        syncContext.Post(() => OnBroadcastEvent(message));
    }
    else
    {
        OnBroadcastEvent(message);
    }
}

と、いうわけで、こんな具合に半手動でPostするコードに書き換えました(Postでラムダ式のキャプチャが発生する問題がありますがshoganai。正確にはobject stateが渡せるのですが、実際のデータでは複数の値が必要になるのでTupleを作る必要があって、余計なオブジェクトが必要という点で変わらない)。ConfigureAwait(false)をつけないことは意識して、意図してやったこと(同期コンテキストを維持してメインスレッド上でコールバックを飛ばす)だったんですが、そこまで意識しといてこういうバグにつなげちゃうのは完全に甘かった、ということで反省しきりです。

ともあれこれで詰まり問題は大解決です。

MagicOnion.Hosting

最初のサンプルがConsole.ReadLineで待っているコードなのでアレなのですが、普通に実開発ではMagicOnion.Hostingというプロジェクトを使って欲しいと思っています。

// using MagicOnion.Hosting
static async Task Main(string[] args)
{
    await MagicOnionHost.CreateDefaultBuilder()
        .UseMagicOnion(
            new MagicOnionOptions(isReturnExceptionStackTraceInErrorDetail: true),
            new ServerPort("localhost", 12345, ServerCredentials.Insecure))
        .RunConsoleAsync();
}

Hostingとは何かと言うと、Genric Hostという.NET Core時代の基盤フレームワークの上に乗っかっています。これは、こないだ作った MicroBatchFramework – クラウドネイティブ時代のC#バッチフレームワークと同じ仕組みです。

.NET Generic Hostは、標準的な仕組みとしてロギング／コンフィグ読み込み／DIをサポートしています。これによりコンフィグのマッピング、ロギングなどを標準的な作法でフルサポートしています。

というわけで、何が嬉しいかと言うと、↑の件をフルサポートしてくれていることです。コンフィグとか何をどう読み込めばいいんですかー？という話は、Generic Hostの仕組みを使ってください、というのが答えになります。ドキュメントもMicrosoftのドキュメントサイトで沢山解説されていて、それがそっくりそのまま使えるので、良いことしかない！

また、これによってコンストラクタインジェクションでのDIも使えるようになりました。

static async Task Main(string[] args)
{
    await MagicOnionHost.CreateDefaultBuilder()
        .ConfigureServices((hostContext, services) =>
        {
            // DI, you can register types on this section.

            // mapping config json to IOption<MyConfig>
            // requires "Microsoft.Extensions.Options.ConfigurationExtensions" package
            services.Configure<MyConfig>(hostContext.Configuration);
        })
        .RunConsoleAsync();
}

public class MyFirstService : ServiceBase<IMyFirstService>, IMyFirstService
{
    IOptions<MyConfig> config;
    ILogger<MyFirstService> logger;

    public MyFirstService(IOptions<MyConfig> config, ILogger<MyFirstService> logger)
    {
        this.config = config;
        this.logger = logger;
    }

    // ...
}

好きな型を、ConfigureServicesのとこで追加してもらえれば、コンストラクタで設定されたのが入ってきます。

今後

v2のリリース告知から半年経って、かなり注目度が上がっているというのが肌感としてあります。GitHub Starも962まで来ていますし、海外からの問い合わせも国内からも来ていて、盛り上がりありますよ！時代はC#！かもしれない！

というわけかで、来月の6月4日に初のMagicOnion勉強会が開催されます。私も登壇しますので、ぜひぜひ来てください（今はもうキャンセル待ちですが……！）

開発的には、サーバーサイドゲームループ（まだ未サポート）などの追加を挟みつつ、もう少し野心的なものも狙っていますので、是非是非楽しみにしていただければと思います。コードジェネレーターの使い勝手が悪いのも、(MessagePack-CSharpともども)改善の最優先タスクの一つになってますので、なんとかします。

また、フィードバック超大事！なので、ぜひ使ってみて、Twitterでつぶやくなり(捕捉してます)、Qiitaに書いてくれるなり（やったー！）、Issueで報告してもらったりなどなどしてくれると嬉しいです。

CIや実機でUnityのユニットテストを実行してSlackに通知するなどする

2019-05-06

前回（？）CircleCIでUnityをテスト/ビルドする、或いは.unitypackageを作るまででは、ユニットテストに関する部分がうまく行ってなくて放置でした。放置でいっかな、と思ってたんですが、改めてユニットテストをCIでがっつり実行したい、というかIL2CPPのテストをがっつしやりたい。という切実な要望が私の中で発生したので（N回目）、改めて取り組んでみました。

さて、オフィシャルな（？）ユニットテストのコマンドラインの実行の口は、Writing and executing tests in Unity Test Runnerの最後の方のRunning from the command lineの節に書いてありました(コマンドライン引数のほうのマニュアルにはリンクすら張ってなかったので気づかなかった……！)。つまり、こんなふうにやればいい、と。

Unity.exe -runTests -testResults C:\temp\results.xml -testPlatform StandaloneWindows64

そうすると、テストが失敗しても正常終了して（？） results.xml に結果が入ってるからそっち見ればOK、と。んー、いや、何か違うような。「Run all in player」で出てくるGUI画面も意味不明だし、Editor上のTest Runnerはいい感じなのだけれど、ビルドしてのテストだとイマイチ感がめっちゃ否めない。

と、いうわけで、なんとなく見えてきたのは、テストはUnity Test Runnerでそのまま書きたいしエディタ上でPlay Modeテストもしたい。それをそのままCIや実機でテストできるように、表示やパイプラインだけをいい具合に処理するビルドを作る何かを用意すればいいんじゃないか、と。

RuntimeUnitTestToolkit v2

ちょうどUnity Test Runnerがイマイチだった頃に作った俺々テストフレームワークがありました。ので、それを元にして、Unity Test RunnerのCLI/GUIのフロントエンドとして機能するようにリニューアルしました。コード的には全面書き換えですね……！

Cysharp/RuntimeUnitTestToolkit

Unity Test RunnerのPlayModeで動くテストがあれば、それだけで他に何もする必要はありません。例えばこんなやつがあるとして

メニューのほうで適当にターゲットフレームワークとかIL2CPPがどうのとかを設定してもらって

BuildUnitTestを押すと、こんなような結果が得られます。

比較的ヒューマンリーダブルなログ！WindowsでもIL2CPPビルドができるようになったのがとっても捗るところで、検証用の小さめプロジェクトなら1分あればコード編集からチェックまで行けるので、リフレクションのキワイ部分をごりごり突いてもなんとかなる！昔のiOSでビルドして動かしてをやってたのは本当に死ぬほど辛かった……。

これはHeadless(CUI)でビルドしたものですが、GUIでのビルドも可能です。

イケてる画面かどうかでは微妙ですが、機能的には十二分です。Headlessだと上から下まで全部のテストを実行しちゃいますが、GUIだとピンポイントで実行するテストを選べるので（ただしメソッド単位ではなくクラス単位）、テストプロジェクトが大きくなっている場合はこっちのほうが便利ですね。

さて、Headlessでビルドしたものは、もちろんCIでそのまま実行できます。

これはNGが出ている例ですが、ちゃんと真っ赤にCIのパイプラインが止まるようになってます。止まればもちろんCIの通知設定で、Slackでもなんでもどこにでもサクッと飛ばせます。実に正しい普通で普遍なやり方でいいじゃないですか。はい。というわけでやりたかったことが完璧にできてるのでめでたしめでたし。

Linux ContainerとUnity

相変わらずCircleCIで色々トライしているのですが、Linuxコンテナ + Unityでの限界、というかUnityのLinux対応が後手に回ってる影響をくらってビミョーという現実がやっと見えてきました。まず、そもそもにLinux + IL2CPPはまだサポートされてないので、CI上でIL2CPPビルドしたものを実行してテスト、みたいなのはその時点でできない。残念。しゃーないのでWindows + IL2CPPビルドを作って、実行だけ手元でやるのでもいっか、と思ったらそもそもLinuxでIL2CPPビルドができない。なるほど、そりゃそうか、って気もしますが悲しみはある。

と、いうわけで、コンテナベースでやるとどうしてもLinuxの上でのパターンが中心になってしまうので、Unityだと結構厳しいところはありますよねえ、という。

さて、CircleCIの場合は(有料プランでは)Mac VMも使えるので、多少コンフィグの書き方も変わってきますが（マシンセットアップ部分が面倒くさくなる！）、動かせなくもないんちゃうんちゃうんといったところです。或いはAzure DevOpsなどを使えばWindowsマシンが使えるので、こちらもUnityのインストールなどのセットアップは必要ですが、安心感はありますね。どちらにせよWindowsでしかビルドできないもの(Hololensとか)もあるので、ちょっとちゃんと考えてみるのはいいのかなあ、と思ってます。

何れにせよ、VMでやるんだったらそりゃ普通にできますよね、という当たり前の結論に戻ってくるのが世の中きびすぃ。とりあえず私的にはIL2CPPビルドが実行できればいいので、Linux + IL2CPP対応をどうかどうか……。

RandomFixtureKit

ユニットテスト用にもう一個、RandomFixtureKitというライブラリを作りました。こちらは .NET Core用とUnity用の両対応です。

Cysharp/RandomFixtureKit

なにかというと、オブジェクトにランダムで適当な値を自動で詰め込むという代物です。当然リフレクションの塊で、これのIL2CPP対応に、先のRuntimeUnitTestToolkitが役に立ちました。

APIも単純でFixtureFactory.Createで取り出すだけ。

// get single value
var value = FixtureFactory.Create<Foo>();

// get array
var values = FixtureFactory.CreateMany<Bar>();

// get temporal value(you can use this values to use invoke target method)
var (x, y, z) = FixtureFactory.Create<(int, string, short)>();

テスト書いていてダミーのデータを延々と書くの面倒くせー、という局面はめっちゃあって、別に賢い名前なんて必要なくて（例えばAddressにはそれっぽい住所、Nameにはそれっぽい人名を入れてくれるとか）、全然ランダム英数でもいいから詰めてくれればそれでいいの！というところにピッタリはまります。

実用的には、私はシリアライザの入れ替えとか（なぜか）よくやるんですが、旧シリアライザと新シリアライザで互換性なくて壊れたりしないように、相互に値を詰めたりとかして、同一の結果が得られることを確認したりします。そのときに、dllをなめて対象になる数百の型を取って、RandomFixtureKitを使って、適当な値を詰めた上で、一致を比較するユニットテストを用意するとかやったりします。

面白い機能としては、ランダムな値ではなくて、エッジケースになり得る値だけを詰めるモードを用意しています。

たとえばintだったらint.MinValue, MaxValue, 0, -1, 1を。コレクションだったらnull, 長さ0, 長さ1, 長さ9の中からランダムで詰める、といったものですね。

こういうキワいデータが入ったときにー、みたいなことは想定しなきゃいけないし、テストも書いておかなきゃなのは分かってるけれど、毎回データ変えて流すのクソ面倒くさいんですよね（私はシリアライザを（なぜか）よく書くので、本当にこういうデータをいっぱい用意する必要が実際ある）。ので、CreateManyで1000個ぐらい作って流し込んでチェックすれば、多少はケースが埋まった状態になるでしょうというあれそれです。使ってみると意外と便利ですよ。

ところで

ゴールデンウィークの最終日なのですが、ほとんど何もやってない！始まる前は、MessagePack-CSharpやMagicOnionのタスクを潰しつつ、Pure C#のHTTP/2 Clientを作ってMagicOnionを強化するぜ、とか息巻いていたのですが全然できてない。副産物というか横道にそれたユニットテスト関連を仕上げて終わりとか、なんと虚しい……。

できなかった理由の半分はSwitchでCelesteを遊び始めたらめちゃくちゃハマって延々とやり続けちゃったせいなのですが、まぁそれはそれで面白いゲームをたっぷり楽しめたということで有意義なのでよしということにしておきます。

MagicOnionは6月4日に勉強会をやります。というわけで、やる気もかなりあるし、アップデートネタも溜まっているんですが、実際にアップデートはできてないので（Issueのヘンジはちゃんとやってます！）、GWでガッと手を入れておきたかったんですが、うーん、まぁ明けてからやりまうす。色々良い感じになっていると思います。いやほんと。

True Cloud Native Batch Workflow for .NET with MicroBatchFramework

2019-04-24

AWS .NET Developer User Group 勉強会 #1にて、先日リリースしたMicroBatchFrameworkについて、話してきました。

True Cloud Native Batch Workflow for .NET with MicroBatchFramework from Yoshifumi Kawai

タイトルが英語的に怪しいですが、まぁいいでしょう（よくない）

MicroBatchFrameworkの概要については、リリース時にCygames Engineers' BlogにてMicroBatchFramework – クラウドネイティブ時代のC#バッチフレームワークとして書かせていただきました。そう、最近はそっち（どっち）に書いてしまうのでこっち（あっち）に書かれなくなる傾向が！リポジトリの置き場としても、Cysharpオーガナイゼーション中心になってきています。これは会社としてメンテナンス体制とかもしっかり整えていくぞ、の現れなので基本的にはいいことです。

ちなみにCysharp、ページ下段にお問い合わせフォームが（ついに）付きました。興味ある方は応募していただいてもよろしくてよ？ビジネスのお問い合わせも歓迎です。別にゲームに限らずで.NET Coreの支援とかでもいいですよ。ただしオールドレガシーWindows案件はやりません。

クラウドネイティブ

これはセッションで口頭で言いましたが、バズワードだから付けてます。という側面は大いにあります。世の中マーケティングなのでしょーがないね。そもそも私はそういうのに乗っかるの、好きです。

そんな中身のないクラウドネイティブですが（真面目な定義はCNCFのDefinitionにちゃんとあります)、まぁコンテナ化です。ベンダー中立な。というのをコンテナ化ビリティの高さという表現に落としました。.NET Coreは結構いい線言ってると思いますよ。実際。

さて、そんなクラウドネイティブなふいんきのところでの、理想のバッチ処理ってなんやねん。というのを考えて、逆算でアプリケーション側で埋めるべきものを埋めるために作ったのがMicroBatchFrameworkです。インフラ側の欠けてるところはそのうちクラウド事業者が埋めてくれるか、現状でも全然実用レベルで回避はどうとでもなるでしょう。

私としてはC#が快適にかければなんだっていいんですが、なんだっていいというだけではなくC#としての自由の追求に関しては相当ラディカルなのですが、でも、それって割とクラウドネイティブの定義（ちゃんとしたほうの）通りなんですよね。別にコンテナに夢見てるわけじゃなくて、意外と堅実に正しく定義どおりのことやってるわけです。まー、FaaSのオーケストレーターは私の理想からベクトル真逆だし、FaaSのランタイムの重さ（実行が遅いという意味ではなくてシステムとしてのヘヴィさ）も受け入れ難いんで、世の中の正しい進化について正面から向かい合うのが結局一番ということで。

ところでMicroBatchFrameworkのウェブホスティング機能(MicroBatchFramework.WebHosting)はSwaggerによる実行可能なドキュメント生成、のほかに、HTTPをトリガーにする待ち受けという側面もあります。GCP Cloud Runの実行のためにはそういうの必要ですからね。毎回コンテナ起動みたいな夢見たモデルだけじゃなくて、割とちゃんと現実に即して機能は用意してます。意外と。割とちゃんと。そもそも、その辺は実用主義なので。

MicroBatchFrameworkはいい具合のバランス感覚で作れていると思うので、実際良いと思います。というわけで、是非試していただければですね。

CircleCIでUnityをテスト/ビルドする、或いは.unitypackageを作るまで

2019-04-08

死ぬほどお久しぶりです！別にインターネット的には沈黙してるわけじゃなくTwitterにもいるし、会社(Cysharp)関連で露出あるかもないかもというわけで、決して沈黙していたわけでもないはずですが、しかしブログは完全に放置していました、あらあら。

C#的にも色々やっていて、CloudStructuresのv2を@xin9leさんとともにリリースしたり、多分、今日に詳細を書くつもりですがMicroBatchFrameworkというライブラリをリリースしたり、Ulidというライブラリをリリースしてたり、まぁ色々やってます。ちゃんと。実際。今月はそのMicroBatchFramework関連で、AWS .NET Developer User Group 勉強会 #1に登壇しますし。リブートしたMagicOnionも来月勉強会開催予定だったりで、めっちゃやる気です。

さて、そんなやる気に満ち溢れている私なのですが（実際Cysharpもいい感じに動き出せているので！お問い合わせフォームないけどお問い合わせ絶賛募集中！）、ブログは放置。よくないね。というわけで表題の件について。

目的と目標

CIの有効性について未だに言う必要なんてなにもないわけですが、しかし、.unitypackageを手作業で作っていたのです。今まで。私は。UniRxとかMessagePack-CSharpの。そして死ぬほど面倒くさいがゆえに更新もリリースも億劫になるという泥沼にハマったのです。やる気が満ち溢れている時は手作業でもやれるけれど、やる気が低下している時でも継続してリリースできなければならないし、そのためにCIはきっちりセットアップしておかなければならないのです。という真理にようやく至りました。なんで今さらなのかというと、私がアプリケーション書くマンであることと、CIとかそういうのは全部、部下に丸投げして自分は一切手を付けてこなかったマンだからです。しかし会社のこともあるので、いい加減にそれで済まなくなってきたので（今更やっとようやく）真面目に勉強しだしたのですね……！

で、CIにはCircleCIを使います。なんでCircleCIなのかというと、一つはUnity Cloud Buildだとunitypackageを作れない（多分）というのが一つ。もう一つは、私が.NET CoreのCIもCircleCIに寄せているので、統一して扱えるといいよねというところです。また、Linuxの他にMacでのビルドもできるので（有料プラン）、iOSに、とかも可能になってくるかもしれませんしね。あと、単純にCircleCIが昨今のCIサービスで王者なので、長いものに巻かれろ理論でもある。でも私自身も最近使っていてかなり気に入ってるので、実際良いかと良いかと。コンテナベースで記述するのがとても小気味よいわけです、モダンっぽいし。

ゴールは

リポジトリの一部ソース郡から.unitypackageを作る
EditorでUnitTestを行う
IL2CPP/Windowsでビルドする(↑のUnitTestのIL2CPP版を吐く)

となります。普通はAndroidやiOSビルドがしたいって話だと思うのですが、私はライブラリAuthorなので、まずそっちの要求のほうが先ということで（そのうちやりたいですけどね！）。Editorテストだけじゃなくて、IL2CPPで動作するか不安度もあるので、そっちのexeも吐ければ嬉しい。できればIL2CPPビルドのものも、ヘッドレスで起動して結果レポーティングまでやれればいいん＆ちょっと作りこめばそこまで行けそうですが、とりあえずのゴールはビルドして生成物を保存するところまでにしておきましょう。そこまで書いてると記事長くなるし。

認証を通してUnityをCircleCI上で動かす

CircleCIということでコンテナで動かすんですが、まぁUnityのイメージを持ってきてbatchmodeで起動して成果を取り出すという、それだけの話です。適当にUnityのコマンドライン引数とにらめっこすれば良い、と。

コンテナイメージに関しては、幸い誰か(gablerouxさん)がgableroux/unity3d/tagsに公開してくれていて、綺麗にタグを振ってくれています。コンテナの良いところっていっぱいあると思いますが、コンテナレジストリが良い具合に抽象化されたファイル置き場として機能するのも素敵なとこですねえ。また、こうして公開してくれていれば、社内CIのUnityインストール管理とかしないで済むのも良いところです。大変よろしい。

で、Unityの実態は /opt/Unity/Editor/Unity にあるので、それを適当に -batchmode で叩けばいいんでしょって話ですが、しかし最大の関門はライセンス認証。それに関してはイメージを公開してくれているgablerouxさんのGabLeRoux/unity3d-ci-exampleや、そして日本語ではCircleCIでUnityのTest&Buildを雰囲気理解で走らせたに、手取り足取り乗っているので、基本的にはその通りに動かせば大丈夫です。

ただ、ちょっと情報が古いっぽくて、今のUnityだともう少し手順を簡単にできるので（というのを試行錯誤してたら苦戦してしまった！）、少しシンプルになったものを以下に載せます。

まず、ローカル上でライセンスファイルを作る必要があります。これはdockerイメージ上で行います。また、ここで使うイメージはCIで実際に使うイメージと同じバージョンでなければなりません。バージョン変わったらライセンス作り直しってことですね、しょーがない。そのうちここも自動化したくなるかもですが、今は手動でやりましょう。

docker run -it gableroux/unity3d:2018.3.11f1 bash
cd /opt/Unity/Editor
./Unity -quit -batchmode -nographics -logFile -createManualActivationFile
cat Unity_v2018.3.11f1.alf

イメージを落としてきて、 -quit -batchmode -nographics -logFile -createManualActivationFile でUnityを叩くと Unity_v***.alf という中身はXMLの、ライセンスファイルの元（まだuseridもpasswordも入力してないので、テンプレみたいなものです)が生成されます。こいつを、とりあえず手元（ホスト側）に持ってきます。docker cpでコンテナ->ホストにファイルを移動させてもいいんですが、まぁ1ファイルだけなのでcatしてコピペして適当に保存でもOK。

次にhttps://license.unity3d.com/manualを開いて、上記のalfファイルを上げると Unity_v2018.x.ulf ファイルがもらえます。これが実体です。生成過程でUnityのサイトにログインしているはずで、そのuserid/passwordが元になって、ライセンスファイルの実体が生成されました。中身はXMLです。

で、これは大事な情報なのでCircleCI上のEnvironment Variablesで秘匿しよう、という話になるんですが、改行の入った長いXMLなので、そのまんま中身をコピペるとファイルが、たいていどこか壊れて認証通らなくなります（散々通らないでなんでかなぁ、と悩みました！）。とはいえファイルそのものをリポジトリに上げるのはよろしくないので、CircleCIでUnityのTest&Buildを雰囲気理解で走らせたにあるとおり、暗号化したものをリポジトリに追加して、Environment VariablesにはKeyを追加しましょう。

openssl aes-256-cbc -e -in ./Unity_v2018.x.ulf -out ./Unity_v2018.x.ulf-cipher -k ${CIPHER_KEY}

${CIPHER_KEY}は、適当な文字列に置き換えてもらって、そしてこれをCircleCI上のEnvironment Variablesにも設定します。ファイルの置き場所は、とりあえず私は .circleci/Unity_v2018.x.ulf-cipher に置きました、CIでしか使わないものなので。

またはマルチラインキーの場合は base64を使うことが推奨されているようです => Encoding Multi-Line Environment Variables。こちらのほうが良さそうですね。

あとは .circleci/config.ymlを書くだけ、ということで、最小の構成はこんな感じになります。

version: 2.1
executors:
  unity:
    docker:
      # https://hub.docker.com/r/gableroux/unity3d/tags
      - image: gableroux/unity3d:2018.3.11f1
jobs:
  build-test:
    executor: unity
    steps:
      - checkout
      - run: openssl aes-256-cbc -d -in .circleci/Unity_v2018.x.ulf-cipher -k ${CIPHER_KEY} >> .circleci/Unity_v2018.x.ulf
      - run: /opt/Unity/Editor/Unity -quit -batchmode -nographics -silent-crashes -logFile -manualLicenseFile .circleci/Unity_v2018.x.ulf || exit 0
workflows:
  version: 2
  build:
    jobs:
      - build-test

-nographicsにすることでそのまま叩けるのと、-manualLicenseFileでライセンスファイルを渡してやるだけです。認証する際の || exit 0 がお洒落ポイントで、認証が正常に済んでもexit code 1が返ってくるという謎仕様なので、とりあえずこのステップは強制的に正常終了扱いにしてあげることで、なんとかなります。なんか変ですが、まぁそんなものです。世の中。

まぁしかしGabLeRoux/unity3d-ci-exampleの（無駄に）複雑な例に比べれば随分すっきりしたのではないでしょうか。いやまぁ、Unityのイメージ作ってもらってるので感謝ではあるのですけれど、しかしサンプルが複雑なのは頂けないかなあ。私はサンプルは限りなくシンプルにすべき主義者なので。

.unitypackageを作る

バッチモードでは -executeMethod により特定のstatic methodが叩けるので、それでunitypackageを作るコードを用意します。今回は Editor/PackageExport.cs に以下のようなファイルを。

using System;
using System.IO;
using System.Linq;
using UnityEditor;
using UnityEngine;

// namespaceがあると動かなさそうなので、グローバル名前空間に置く
public static class PackageExport
{
    // メソッドはstaticでなければならない
    [MenuItem("Tools/Export Unitypackage")]
    public static void Export()
    {
        // configure
        var root = "Scripts/CISample";
        var exportPath = "./CISample.unitypackage";

        var path = Path.Combine(Application.dataPath, root);
        var assets = Directory.EnumerateFiles(path, "*", SearchOption.AllDirectories)
            .Where(x => Path.GetExtension(x) == ".cs")
            .Select(x => "Assets" + x.Replace(Application.dataPath, "").Replace(@"\", "/"))
            .ToArray();

        UnityEngine.Debug.Log("Export below files" + Environment.NewLine + string.Join(Environment.NewLine, assets));

        AssetDatabase.ExportPackage(
            assets,
            exportPath,
            ExportPackageOptions.Default);

        UnityEngine.Debug.Log("Export complete: " + Path.GetFullPath(exportPath));
    }
}

ちょっとassetsを取るところが長くなってしまっているのですが、.cs以外をフィルタするコードを入れています。たまに割と入れたくないものが混ざっていたりするので。あとは、CIではライセンス認証のあとに、これを叩くコマンドと、artifactに保存するコマンドを載せれば良いでしょう。

version: 2.1
executors:
  unity:
    docker:
      # https://hub.docker.com/r/gableroux/unity3d/tags
      - image: gableroux/unity3d:2018.3.11f1
jobs:
  build-test:
    executor: unity
    steps:
      - checkout
      - run: openssl aes-256-cbc -d -in .circleci/Unity_v2018.x.ulf-cipher -k ${CIPHER_KEY} >> .circleci/Unity_v2018.x.ulf
      - run: /opt/Unity/Editor/Unity -quit -batchmode -nographics -silent-crashes -logFile -manualLicenseFile .circleci/Unity_v2018.x.ulf || exit 0
      - run: /opt/Unity/Editor/Unity -quit -batchmode -nographics -silent-crashes -noUpm -logFile -projectPath . -executeMethod PackageExport.Export
      - store_artifacts:
          path: ./CISample.unitypackage
          destination: ./CISample.unitypackage
workflows:
  version: 2
  build:
    jobs:
      - build-test

完璧です！

コマンドに関しては普通にWindowsのUnity.exeで試してから挑むのがいいわけですが、一つWindowsには難点があって、ログが標準出力ではなく %USERPROFILE%\AppData\Local\Unity\Editor\Editor.log にしか吐かれないということです。というわけで、Editor.logを開いてにらめっこしながらコマンドを作り込みましょう。めんどくせ。

EditorでUnitTestを行う

基本的に -runEditorTests をつけるだけなのですが、注意点としては -quit は外しましょう。ついてると正常に動きません（はまった）。

version: 2.1
executors:
  unity:
    docker:
      # https://hub.docker.com/r/gableroux/unity3d/tags
      - image: gableroux/unity3d:2018.3.11f1
jobs:
  build-test:
    executor: unity
    steps:
      - checkout
      - run: openssl aes-256-cbc -d -in .circleci/Unity_v2018.x.ulf-cipher -k ${CIPHER_KEY} >> .circleci/Unity_v2018.x.ulf
      - run: /opt/Unity/Editor/Unity -quit -batchmode -nographics -silent-crashes -logFile -manualLicenseFile .circleci/Unity_v2018.x.ulf || exit 0
      
      - run: /opt/Unity/Editor/Unity -quit -batchmode -nographics -silent-crashes -noUpm -logFile -projectPath . -executeMethod PackageExport.Export
      - store_artifacts:
          path: ./CISample.unitypackage
          destination: ./CISample.unitypackage

      - run: /opt/Unity/Editor/Unity -batchmode -nographics -silent-crashes -noUpm -logFile -projectPath . -runEditorTests -editorTestsResultFile ./test-results/results.xml
      - store_test_results:
          path: test_results
workflows:
  version: 2
  build:
    jobs:
      - build-test

editorTestsResultFile で指定し、store_test_resultsに格納することでCircleCI上でテスト結果を見ることができます。

と、思ったんですが、なんかテスト周りは全体的にうまく動かせてないんで後でまた調べて修正します……。或いは教えてくださいです。

IL2CPP/Windowsでビルドする

なぜWindowsかというと、私がWindowsを使っているからというだけなので、その他のビルドが欲しい場合はそれぞれのビルドをしてあげると良いんじゃないかと思います！

いい加減コンフィグも長くなってきましたが、-buildWindows64Playerでビルドして、zipで固めてぽんということです。

version: 2.1
executors:
  unity:
    docker:
      # https://hub.docker.com/r/gableroux/unity3d/tags
      - image: gableroux/unity3d:2018.3.11f1
jobs:
  build-test:
    executor: unity
    steps:
      - checkout
      - run: openssl aes-256-cbc -d -in .circleci/Unity_v2018.x.ulf-cipher -k ${CIPHER_KEY} >> .circleci/Unity_v2018.x.ulf
      - run: /opt/Unity/Editor/Unity -quit -batchmode -nographics -silent-crashes -logFile -manualLicenseFile .circleci/Unity_v2018.x.ulf || exit 0
      
      - run: /opt/Unity/Editor/Unity -quit -batchmode -nographics -silent-crashes -noUpm -logFile -projectPath . -executeMethod PackageExport.Export
      - store_artifacts:
          path: ./CISample.unitypackage
          destination: ./CISample.unitypackage

      - run: /opt/Unity/Editor/Unity -batchmode -nographics -silent-crashes -noUpm -logFile -projectPath . -runEditorTests -editorTestsResultFile ./test-results/results.xml
      - store_test_results:
          path: test_results

      - run: /opt/Unity/Editor/Unity -quit -batchmode -nographics -silent-crashes -noUpm -logFile -projectPath . -buildWindows64Player ./bin-win64/CISample.exe
      - run: apt-get update
      - run: apt-get install zip -y
      - run: zip -r CISampleWin64Binary.zip ./bin-win64
      - store_artifacts:
          path: ./CISampleWin64Binary.zip
          destination: ./CISampleWin64Binary.zip
workflows:
  version: 2
  build:
    jobs:
      - build-test

これで一旦は希望のものは全てできました！

以上な感じが最終結果になります。

CircleCIでUnityビルドはプロダクトで使えるか

今回の例のようなライブラリ程度だと、リソースもほとんどないしリポジトリも全然小さいんでいいんですが、実プロダクトで使えるかというと、どうでしょう。まずリポジトリのサイズの問題で、次にビルド時間の問題で。クソデカい＆高級マシンでも焼き上がり1時間は普通とか、そういう世界ですものね。常識的に考えてこれをクラウドでやるのは難しそう。オンプレのCircleCI Enterpriseだったら行けそうな気もしますが、どうでしょうねえ。しかしJenkinsマンやるよりは、こちらのほうが夢があるのと、実際うまくクラスタを組めば、ばかばかコンテナ立ち上げて同時並列でー、というビルドキュー長蛇列で待ちぼうけも軽減できたりで、良い未来は感じます。試してみたさはあります、あまりJenkinsに戻りたくもないし。

一回構築してみれば、ymlもそこそこシンプルだし、（ライセンス認証以外は）ymlコピペで済むので、Unity Cloud Build使わなくてもいいかなー、色々自由にできるし。っていうのはあります。というわけで、是非一緒にUnityでCircleCI道を突き進んでみましょう:) 今回はAndroidビルドやiOSビルドという面倒くさいところには一切手を付けてませんが、まぁほとんどビルドできてるわけで、やりゃあできるでしょう。いや、でもiOSとか死ぬほど面倒くさ（そう）なので、そのへんよしなにやってくれつつマシンパワーもそこそこ用意してくれるUnity Cloud Buildは偉い。

ところでこのブログ、ymlのシンタックスハイライトがない模様。やべー。このブログのメンテこそが一番最重要な気がしてきた。

2018年を振り返る

2018-12-30

毎年恒例ということで、今年も振り返ります。だいたい30日に書いてるのですが、理由は12月30日は私の誕生日なので色々ちょうどよいかな、と。いよいよ35歳なので、例のあれ、35年定年説になりました。そのへんどうでもいい外れ値をひた走ってるので一般論はあんま関係ないんですが、体力は落ちてる実感ありますね！肥ったし。文章はどんどんてきとーになってくし。

と、いうわけで、今年は客観的には激動の年です。会社辞めて会社作って会社作って。私生活でも色々あり、イベントが多くて中々どうして落ち着かなかった年です。そのため成果という点では不完全燃焼が否めないですね、どうしても集中しきれないし時間も上手く捻出できないし。GitHubの草生やしで考えれば、もう全然すっかすっか。その中でUniRx.AsyncやMagicOnion2など、今年もちゃんと大きめの成果を出せたのは、意地です。特にUniRx.Asyncの開発はしんどかった……(MagicOnion2のほうはCysharpとしての時間を使えたので良かったんですが、UniRx.Asyncの開発のための時間捻出はめっちゃ厳しかった）。まぁ、ダラダラ草生やすことをKPIにするよりは、一発ホームランをKPIにしたほうがエンジニアの脳トレ的にも随分かいいんじゃないでしょーか？

ここ数年は毎年、C#を書く技量が向上してていいわー、と言い続けてるんですが、今年も随分と向上しました！特に大きかったのはUniRx.Asyncの開発で、これのためにasync/awaitやTask周りの生態系を全部自前実装したので、曖昧な理解だった、ということに気づいてすらいなかったものも、全て完全に理解したので、私自身の能力の向上としてかなり大きいですね。車輪の再発明は良いものです。

きちんと最前線のC#を書けている自信がありますし、対外的な証明もできているので、能力的な意味では老害とはまだ遠そうでいいんじゃないでしょーか。色々な言語に手を出して成長、ってのも悪くはないでしょうが、一つの言語を集中的に深掘りするというのもまた成長の道かと思います。中途半端な深掘りだと言語固有の話になって応用がー、みたいなところがなくもないのですが、徹底的に深掘りすりゃあ、逆に言語固有じゃなくなって、応用が効いてくる領域に入るのです。もしなんとなく成長の限界を感じて他の言語やったほうがいいかな、とか思うのだとしたら、多分、全然深掘りが足りないじゃないかしら？と、思ったりね、します。実に上から目線ですが！

お仕事

先に仕事の話を考えると、株式会社グラニを退任しました。私だけではなく皆バラバラになっているので（もちろんマイネットさんのほうで引き続きタイトル開発にあたっているメンバーもいます）、グラニという会社の始まりから終わりまで、ですね。結末として、悪くはない（退職時の未払いなどももちろんありませんし、エンジニアメンバーは他社に転職した人も、みな良いところに移れているので、グラニという会社が経験としてもキャリアとしても、良いものを提供できたのではないかなー、と思ってます、まぁ役員としてはこれが最後の仕事の成果という形になるのでそう思わせてください……！）ですが、もちろん、最良ではない、です。

CTOとしてどうだったかというと、会社として一点突破な凡百じゃない他にない個性を作れたし、悪くないところまで突き進めた、という点ではよくやれてはいますが（別に「素で」やってるわけじゃなくて割としっかり戦略組んでやっての結果なのでそれなりに大変なんですよ！）、最良のエンディングではないという結果をもって、ベストじゃあないでしょうね。実際反省点はめちゃくちゃ多いです。世の中、結果が全てで、一般論のハンマーを叩き返すには結果を出していかなきゃいけないので、今回の5年間の結果では一般論に反逆はできないんで、次はもっとうまくやる。という決意もあります。

退任後にはNew World, Inc.を設立しました。設立じゃない道も模索していたのですが、うまくまとまらなかったので、とりあえずやったことないしやってみっか、と。なんで株式会社なのかというと、とりあえず作ってみたかったから、以外の理由はない、です。次の会社のスタートまでの間(4ヶ月ぐらい)は、この会社名義、といってもほぼ個人事業主として仕事していました。一応会社としてのビジネスプランも考えてはいたのですが、時間的なものもあって結局ほとんど個人事業主的な働き方に終始しました。

こちらは死ぬほど反省点ありますね……。あまり表明するのもアレですが、多分、まぁ、請負で作業するの自分には向いてないんだとは思います……。それ以外にも単純にスキル不足があって、自分が組んできた環境ではなく自由度もそう高くない中でのパフォーマンスチューニング、みたいなことをするための手札があんまなかったですね。こういうスキルって、多分テクニカルサポート（それも高額なプレミア契約の）の人が持つスキルなんでしょうけれど、明らかに自分の手札にはなかったのを自覚しました。ここはもう能力不足だし、あったほうがいいのは間違いないんで、来年は伸ばしていこうかな、とは思ってます。

グラニでのトラブルシューティングは、徹夜で張り付いて空いてそうな時間にサーバー一時的に止まるの強行でダンプ取ったり、本番環境データベース相当のをコピーして好きに実験したり、既に豊富に用意しているモニタリング系システムにクエリ書いたり追加したり、そもそも根本からライブラリを自作のものを開発して取り替えたりと、権限に甘えきったことやってたんで、まぁ世の中そんなイージーモードなわけないぞ、と。そりゃそうだ。会社としてはイージーモードな世界を作るのが大事で、個人スキルとしてはハードモードな世界でやりきれる能力をつけるのが大事。両面から頑張っていきたい。

そして、株式会社Cysharpを設立しました。設立に関する話は←の記事と、Social Game Infoでのインタビューを読んでいただければなのですが、まず、この座組のインパクトはめっちゃあったかな、と！社名もそうですが！大きなことがやれそうな予感があります。来年はそうした予感を実現していくという、チャレンジの年です。会社としてもそれなりな規模にはしていきたいと思っているので、そのへんもやっていければ。

引き続きゲーム関連で勝負をかけるわけですけれど、ゲーム関連から攻めるのがC#にとって一番、あるいは唯一芽があるから、というのも大きくて。私はインターネットで育ってきたので、ウェブに話題が少ない言語や環境って嫌なんですよね、だからエンタープライズで採用伸びてるとか世界的には数字は良いんだとか、そういうの興味なくて。目の前のインターネットの世界で話題になり誰もが使う言語、であって欲しい。C#が。誰もが使い、話題にし、エコシステムが形成され、若い人がどんどん使う。そこへ向かうには、ゲームやUnityと絡めていくことが唯一の道だと思っています（個人的にはXamarinでは無理でしょう、と思ってるので）。そしてそこに対して貢献したいのです。それはMicrosoftやUnityの「外の人」だからこそできることでもある。

C#

UniTask(UniRx.Async)のリリースによるコンセプト実証と大規模アップデートによる真の実用化。これはNew Worldとして動き出してちょい過ぎぐらいから作成に着手しました。私の中でこれのリリースには大きな意味があって、New World, Incとしての名刺、つまるところ私自身の自信が欲しかったのです。特にUnity関連においてUniRxは前の世代の話なので、今の世代で絶対の自信を持って薦められるものが欲しかった。そういうものがあると自分にも自信ができるんで、交渉も強気に迫れますからね。

UniTaskはUnityに最適化したasync/await生態系の再発明です。これやりきれる人って世の中いないんで、成果として世の中に存在するのはめっちゃレアなんじゃないでしょーか。と思える程度にはいい感じだと思います。しかし例によってまだバグや機能改善がかなり残っているのに、いったん放置が始まっていて、これは本当に私の悪癖ですね……。来年の抱負は放置しない、です。ほんと。ほんと。

もう一個がMagicOnion v2のリリースで、これはグラニでのやり残したことの一つの消化、という意味合いもあります（技術的にはもう一つやり残したことありますけれど、「まともな」UIライブラリの作成とプラクティスの構築とか）。そして、Cysharpで掲げる「C#大統一理論」のキーパーツですね。応用事例をどんどん作っていきたいます。

また、MagicOnionはリポジトリをCysharp/MagicOnionに移しています。これはメンテしっかりやっていくぞ、の現れですね！他にUniRxやMessagePack for C#などもorgnaization(Cysharpじゃなくて中立的組織）に移したいなあ、とは思ってます。そうした継続的メンテナンス体制を作って、永く行き続けていくものになっていければいいなあ、と。まあカウボーイエンジニアから会社経営者になったわけで、そのへんも世の中によりよい形を、ということで。

パフォーマンスの追求は引き続きやっていきたいテーマで、一旦のまとめをCEDEC 2018で最速のC#の書き方 - C#大統一理論へ向けて性能的課題を払拭すると題して講演しました。こういうのってどのへんまでDeepでDopeに書けばいいのか難しくて、浅瀬ちゃぷちゃぷなんちゃうんちゃうんな思いと戦いつつ、実体験ベースってのもあり良いちゃあ良かったんじゃないでしょうか。

Unity ECSはもっと力入れてやりたかったんですが、ほとんど出来なかったですね。LTドリブン開発だー、と思ったけれどロクにできずMemory Management of C# with Unity Native Collectionsでお茶濁しした程度だったので……。物理エンジンと絡めて、やりたいネタが2年ぐらい前からあって、ECSの登場でまさに最適なプラットフォーム！これでちゃりんちゃりんする！と考えてたのに何も実装できず一年が終わるとは……。来年こそリベンジします。

漫画/音楽/ゲーム/その他…

今年感動したゲームはDetroit: Become Human一択ですねえ、もう全く悩まず。映像も音楽もシナリオもシステムも、あらゆる点で監督(デヴィッド・ケイジ)の神経質そうな（ほんと！）目が行き届いていて、完璧。ただの雰囲気ゲーにならずゲームとしてもちゃんと面白く仕上がっているので、非の打ち所がない（リプレイが面倒くさくてエンディングコンプがダルい問題はありますが、一周＋αの体験だけで十分価値あるんで良いんじゃないでしょーか）。

漫画はうめざわしゅん - えれほんがとても良くて、三話(+1)入った短編集で二話目は無料で読めます。とにかくまぁ漫画が上手い。まぁあと古いですが今年読んだんで内田春菊 - 目を閉じて抱いても。全然古くないというかむしろ今の時代のほうが共感できるんちゃうんちゃうん、と(といっても1994-2000だとそこまで古くもないのかー、いや、古いかー)。

音楽は、今年まぁまぁケンドリック・ラマーの記事を目にしたから（来日で一悶着あったからかしらん）、というわけでもないですが最新作のDAMN、ではなくてその前のTo Pimp A butterflyをよく聞いてました。特に一曲目のWesley's Theory。もともとこれ作曲してるFlying Lotusが好きというのもありますが、Flying Lotusの手掛けた中でも傑作と思ふ。アルバム全編を貫くストーリーも重たく、比喩も強烈で、言葉の強さを心底叩き込んでくる。そりゃ心震えますよ！

映画は、これも古いですがNetflixで見たニコラス・ウィンディング・レフン - ドライヴが良かった。映像美とバイオレンス！まぁーもうとにかく最高に格好良い。こりゃすげえ、と思わず監督の大ファンになって初期作のプッシャー三部作、これはまぁまぁだったんですが、最新作のネオン・デーモンが……。設定も良い。映像も良い。プロットも悪くない。映画としてはつまらない。というしょっぱい代物に……。脚本と構成が悪いんかなー、もう少しうまくやりゃあ、めっちゃ良くなったはずなのに感で超もったいない……。設定と映像は本当に好みなだけに、あうあうって感じ。何れにせよ次回作あったら見るよ！と思ったら、来年(2019)にAmazon Prime VideoのシリーズとしてToo Old to Die Youngというドラマを撮ってるそうで。日本に来るのかな、Netflixだったら絶対来るはずだけどAmazon Prime Videoだとどうなんでしょ。

Hajime Kinoko写真集「Perfect Red」は、写真集はもちろん、個展とショーも見に行きましたが、圧倒的な空間で。ショーだと、人間の表現として、静と動の中間のような世界なんですよね。例えば、静が彫刻、動がバレエのようなものだったりだとすると、その間。ほとんど止まっているのだけれど、手の動き、顔の表情、そして縄が皮膚に言葉を与えていて。表現としては未成熟というかアングラ感が拭えないですが（決して悪いことではなくそれはそれでいいんですが）、もっと表に出れば出るほど洗練されていくのでは、というわけで来年も見たいですね。

来年は

とにもかくにもCysharpをしっかり始動させます。会社の理念がC#とOSSを中心に、というのもあるので、技術のコミュニティ貢献も引き続き、ですね。そしてメンテやIssueを放置しないという抱負は、ただの意気込みじゃなくて組織的な解決となるよう、具体的に動いていきます。

技術的には、今年は色々な言い訳がありますが、チャレンジがなかったなー、というのは否めないです。UniRx.AsyncもMagicOnion2も延長線上ですから。時間がない中で一定の成果を出すことが必須という状況下だったのでしゃーなし、という言い訳もありますが、来年こそは今までの延長線上にない別のことも手掛けたい、と毎年言ってますが、今年も思います。とりあえずとにかくUnity ECSは絶対やりますから……！

ともあれ、Cysharpの活動にご期待下さい。人も募集ちゅ（します、そろそろ）。です。そろそろお問い合わせフォームぐらいはつけたい。

MagicOnion v1 -> v2リブート, gRPCによる.NET Core/Unity用ネットワークエンジン

2018-12-28

先にCygames Engineers' BlogでMagicOnion – C#による .NET Core/Unity 用のリアルタイム通信フレームワークとしてリリースを出しましたが、改めまして、MagicOnionというフレームワークを正式公開しました。

GitHub - Cysharp/MagicOnion

MagicOnionはAPI通信系とリアルタイム通信系を一つのフレームワークで賄う、というコンセプトを元に、前職のグラニで「黒騎士と白の魔王」の開発において必要に迫られて捻り出されたものでした。

「黒騎士と白の魔王」gRPCによるHTTP/2 - API, Streamingの実践 from Yoshifumi Kawai

で、今更気づいたのがMagicOnionって正式リリースしてなかったんですよね、このブログでも↑のような形でしか触れていなくて、公式ドキュメントも貧弱な謎フレームワークだったという。今回Ver2って言ってますが、その前はVer0.5でしたし。まぁここでは便宜的にv1と呼びます。

何故に正式リリースまで行かなかったかというと、リアルタイム通信部分が微妙だったから。↑のp.39-40で説明していますが、Unary + ServerStreamingという構成で組んだのが、かなり開発的に辛かったんですね。時間的問題もあり強行するしかなかったんですが、ちゃんと自分が納得いく代案を出せない限りは、大々的には出していけないなあ、と。

その後すったもんだがあったりなかったりで、プレーンなgRPCでリアルタイム通信を組む機会があって、↑の時に考えていたDuplexStreaming一本で、コマンドの違いをProtobufのoneofで吸収する、という案でやってみたのですが、すぐに気づきましたね、これ無理だと。UnaryはRPCなのですが、Duplex一本はRPCじゃないんで、ただたんにoneofをswitchしてメソッド呼び出す、だけじゃ全然機能足りてない、と。

ただまぁコネクション的にはDuplex一本案は間違ってなさそうだったので、その中で手触りの良いRPCを組むにはどうすればいいか……。と、そこでMagicOnionをリブートさせるのが一番手っ取り早いじゃん、というわけで着手したりしなかったりしたりしたのでした。その間にCysharpの設立の話とかもあり、事業の中心に据えるものとしても丁度良かったという思惑もあります。

早速（？）Qiitaでも何件か紹介記事書いてもらいました。

v1 -> v2

Unary系(API通信系)はほとんど変わっていません。それは、v1の時点で十分に高い完成度があって、あんま手を加える余地はなかったからですね。ただしフィルターだけ戻り値をTaskからValueTaskに変えています。これはフィルターの実行はメソッド実行前に同期的にフック(ヘッダから値取り出してみるとか)するだけ、みたいなものも多いので、TaskよりValueTaskのほうが効率的に実行できるからですね。

元々フィルターを重ねることによるオーバーヘッドを極小にするため、純粋にメソッド呼び出しが一個増えるだけになるように構成してあったのですが、更により効率的に動作するようになったと思います。

SwaggerのUIを更新するのと、HttpGatewayの処理を効率化するのが課題として残っているので、それは次のアップデートでやっていきます。

また、Unity向けにはコードジェネレート時にインターフェイス定義でTaskをIObservableに変換していたのですが、今のUnityは.NET 4.xも使えるということで、インターフェイスはそのまま使ってもらうようにしています。Taskのままで。

StreamingHub

の、導入に伴って、v1でリアルタイム通信系をやるための補助機構である StreamingContextRepository を廃止しました。StreamingContextRepositoryは、まぁ、正直微妙と思っていたのでなくせて良かったかな。決して機能してないわけではないのですけれど。

代わりのコネクションを束ねる仕組みはGroupという概念を持ってきました。これはASP.NETのWebsocketライブラリであるASP.NET Core SignalRにあるものを、再解釈して実装しています。

MagicOnionのGroupの面白いところは、裏側の実装を変えられることで、デフォルトはImmutableArrayGroupという、MORPGのようなルームに入って少人数で頻繁にやり取りするようなグルーピングに最適化された実装になっています。もう一種類はConcurrentDictionaryGroupという、こちらはMMORPGやグローバルチャットのような、多人数が頻繁に出入りするようなグルーピングのための実装です。更に、RedisGroupというバックエンドにRedisのPubSubを置いて複数サーバー間でグループを共有するシステムも用意しています、これはチャットや、全体通知などに有効でしょう。

また、GroupにはInMemoryStorage[T]というプロパティが用意されていて、グループ内各メンバーに紐付いた値をセットできるようにしています。これは、通信のブロードキャスト用グループの他に、値の管理のためにConcurrentDictionary[ConnectionId, T]のようなものを用意してデータを保持したりが手間で面倒くさいんで、いっそグループ自体にその機能持ってたほうが便利で最高に楽じゃん、という話で、実際多分これめちゃくちゃ便利です。

まとめ

というわけで、リブートしました！最初チョロいと思ってたんですが、割とそんなことはなくて、この形にまとめあげるまではそれなりに大変でした……。の甲斐もあって、今回のMagicOnionはかなり自信を持って推進できます。以前はそもそもgRPC本体をフォークして魔改造したり、というのもあったのですが、今は公式ビルドを使えるようになったのでUnity向けにも良い具合になってきています。

MagicOnion2の内容は、(v1を)実際に使ってリリースした後の反省点が盛り込まれているので、そういう点で二周目の強みがあります。最初からこの形で出すのは絶対にできないであろうものなので、しっかりと経験が活かされています。実プロダクトで使って初めて見えるものっていっぱいありますからねー。とはいえv1はv1で大きな役割を果たしたと思いますし、まぁあと自分で言うのもアレですが「黒騎士と白の魔王」が証明したこと(gRPCがUnityでいけるんだぞ、という)ってメチャクチャ大きかったなあ、と。

CysharpとしてもMagicOnion、使っていきますし、ほんと是非是非使ってみてもらえると嬉しいです。コードジェネレーターもついにWin/Mac/Linux対応しましたので（まだ微妙にバグいのですが年内か、年明け早々にはなんとかします）、ガッツリと使っていけるのではないかとです。

UniTask(UniRx.Async)から見るasync/awaitの未来

2018-12-25

C# Advent Calendar 2018大遅刻会です。間に合った。間に合ってない。ごめんなさい……。今回ネタとして、改めてコード生成に関して、去年は「動的」な手法を解説した - Introduction to the pragmatic IL via C#ので、現代的な「静的」な手法について説明してみよう、と考えていたのですが、そういえばもう一つ大遅刻がありました。

7月にUniTask - Unity + async/awaitの完全でハイパフォーマンスな統合という記事を出して、リリースしたUniTaskですが、その後もちょこちょこと更新をしていて、内部実装含め当初よりもかなり機能強化されています。といった諸々を含めて、Unity 非同期完全に理解した勉強会で話してきました。

Deep Dive async/await in Unity with UniTask(UniRx.Async)

9月！更新内容の告知もしてなければ、この発表のフォローアップもしてない！最近はこうした文章仕事がめっちゃ遅延するようになってしまいました、めっちゃよくない傾向です。来年はこの辺もなんとかしていきたい。

と、いうわけで、予定を変えてUniRx.Asyncについて、というか、それだとUnity Advent Calendarに書けよって話になるので、UniRx.Asyncは独自のTask生態系を作っている、これは.NET Core 2.1からのValueTaskの拡張であるIValueTaskSourceに繋がる話なので、その辺を絡めながら見ていってもらえると思います。

Incremental Compilerが不要に

告知が遅延しまくっている間にUnity 2018.3が本格リリースされて、標準でC# 7.xに対応したため、最初のリリース時の注釈のような別途Incremental Compiler(preview)を入れる必要がなくなりました。Incremental Compiler、悪くはないのですが、やっぱpreviewで怪しい動きもしていたため、標準まんまで行けるのは相当嬉しいです。というわけで今まで敬遠していた人も早速試しましょう。

new Progress[T] is Evil

これは普通の.NETにも言える話なのですが、C#のasync/awaitの世界観では進捗状況はIProgress[T]で通知していくということになっています(別にAction[T]でよくね？そっちのほうが速いし、説はある)。進捗はReport(T value)メソッドで通知していくことになりますが、こいつは必ずSynchronizationContext.Post経由で値を送ります。これがどういうことかというと、Unityだとfloatを使う、つまりIProgress[float]で表現する場合が多いはずですが、なんと、ボックス化します。(If T is a value type, it will get boxed here.)じゃねーよボケが。アホか。これはオプションで回避不能なので、new Progress[T]は地雷だと思って「絶対に」使わないようにしましょう。

代わりにUniRx.AsyncではProgress.Createを用意しました。これはSynchronizationContextを使いません。もしSyncContext経由で同期したいならマニュアルでやってくれ。Unityの場合、進捗が取れるシチュエーションはメインスレッド上のはずなので、ほとんどのケースでは不要なはずです。

こういった、あらゆる箇所での.NET標準の余計なお世話を観察し、Unityに適した形に置き直していくことをUniRx.Asyncではやってるので、async/await使うならUniRx.Asyncを使ったほうがいいのです。標準のも、今の時代で設計するならこうはなってないと思うんですけどね、まぁ時代が時代なのでshoganai。

コルーチンの置き換えとして

コルーチン、或いはRxでできた処理は、改めて全部精査して、全てasync/awaitで実装できるようにしました。

Add UniTask.WaitUntil
Add UniTask.WaitWhile
Add UniTask.WaitUntilValueChanged
Add UniTask.WaitUntilValueChangedWithIsDestroyed
Add UniTask.SwitchToThreadPool
Add UniTask.SwitchToTaskPool
Add UniTask.SwitchToMainThread
Add UniTask.SwitchToSynchronizationContext
Add UniTask.Yield
Add UniTask.Run
Add UniTask.Lazy
Add UniTask.Void
Add UniTask.ConfigureAwait
Add UniTask.DelayFrame
Add UniTask.Delay(..., bool ignoreTimeScale = false, ...) parameter

概ね名前からイメージ付くでしょう、イメージ通りの挙動をします。こんだけ用意しておきゃほとんど困らないはず（逆に言えば、標準のasync/awaitには何もありません）

ちなみにSwitchTo***は、最初のVisual Studio Async CTP(お試しエディション)に搭載されていたメソッドで、すぐに廃止されました。というのも、async/awaitが自動でスレッド(SynchronizationContext)をコントロールするというデザインになったからですね。あまりにも最初期すぎる話なのでこの辺の話が残っているものも少ないのですが、ちゃんと岩永さんのブログには残っていたので大変素晴らしい。

UniRx.Asyncでは不要なオーバーヘッドを避けるため（そもそも特にUnityだとメインスレッド張り付きの場合のほうが多い）、自動でSynchronizationContextを切り替えることはせず、必要な場合に手動で変更してもらうというデザインを取っています。というか、今からasync/await作り直すなら絶対こうなったと思うんだけどなぁ、どうなんでしょうねぇ。ちょっとSynchronizationContextに夢見すぎだった時代＆Windows Phone 7（うわー）とかの要請が強すぎたせいっていう時代背景は感じます。

Everything is awaitable

考えられるありとあらゆるものをawait可能にしました。AsyncOperationだけじゃなくてWWWやJobHandle（そう、C# Job Systemもawaitできます！）、そしてReactivePropertyやReactiveCommand、uGUI Events(button.OnClickAsyncなど)からMonoBehaviour Eventsまで。

さて、AsyncOpeartionなど長さ1の非同期処理がawait可能なら、そらそーだ、って話なのですが、イベントがawait可能ってどういうこっちゃ、というところはあります。

// ようするところこんな風に待てる
async UniTask TripleClick(CancellationToken token)
{
    await button.OnClickAsync(token);
    await button.OnClickAsync(token);
    await button.OnClickAsync(token);
    Debug.Log("Three times clicked");
}

コレに関してはスライドに書いておきましたが、「複雑なイベントの合成」をする際に、Rxよりも可読性良く書ける可能性があります。

Rxは「複雑なイベントハンドリング」を簡単にするものじゃなかったの！？という答えは、YesでもありNoでもありで、複雑なものは複雑で、難しいものは難しいままです。イベントハンドリングは手続き的に記述出来ない（イベントコールバックが飛び飛びになる)ため、コールバックを集約させて合成できるRxが、素のままでやるより効果的だったわけですが、async/awaitはイベントコールバックを手続き的に記述できるため、C#のネイティブのコントロールフロー(for, if, whileなど)や自然な変数の保持が可能になります。これは関数合成で無理やり実現するよりも、可読性良く実現できる可能性が高いです。

単純なものをasync/awaitで記述するのは、それはそれで効率やキャンセルに関する対応を考慮しなければならなくて、正しく処理するのは地味に難易度が高かったりするので、基本的にはRxで、困ったときの必殺技として手段を知っている、ぐらいの心持ちが良いでしょう

async UniTask TripleClick(CancellationToken token)
{
    // 都度OnClick/token渡しするよりも最初にHandlerを取得するほうが高効率
    using (var handler = button.GetAsyncClickEventHandler(token))
    {
        await handler.OnClickAsync();
        await handler.OnClickAsync();
        await handler.OnClickAsync();
        Debug.Log("Three times clicked");
    }
}

↑こういう色々なことを考えるのが面倒くさい。

Exception/Cancellationの扱いをより強固に

UniTaskでは未処理の例外はUniTaskScheduler.UnobservedTaskExceptionによって設定されている未処理例外ハンドラによって処理されます（デフォルトはロギング）。これは、UniTaskVoid、或いはUniTask.Forgetを呼び出している場合は即時に、そうでない場合はUniTaskがGCされた時に未処理例外ハンドラを呼びます。

async/awaitが持つべきステータスは「正常な場合」「エラーの場合」「キャンセルの場合」の3つがあります。しかし、async/awaitならびにC#の伝搬システムは、正常系は戻り値、異常系は例外の二択しかないため、「キャンセルの場合」の表現としてawaitされた元にはOperationCanceledExceptionが投げられます。よって、例外の中で、OperationCanceledExceptionは「特別な例外」です。デフォルトではこの例外が検出されて未処理の場合は、未処理例外ハンドラを無視します。何もしません。キャンセルは定形の処理だと判断して、無視します。

また、例外を使うためパフォーマンス上の懸念もあります。そこで、UniTask.SuppressCancellationThrowを使うことで、対象のUniTaskが例外の発生源であれば（throw済みで上の階層に伝搬されたものではない)、例外の送出ではなく、Tupleでの戻り値としてキャンセルを受け取り、例外発生のコストを抑えることができます。これはイベントハンドリングなどの場合に有用です、が、正しく使うことは内部をかなりのレベルで理解していないといけないため、ぶっちゃけムズい。ただたんにSuppressCancellationThrowを使うだけでパフォーマンスOKというわけにはいかんのだ。というわけで、どうしてもパフォーマンス的に困ったときのための逃げ道、ぐらいに思っておいてください。

UniTaskTracker

とはいえなんのかんのでTaskがリークしてしまったり、想像以上に多く起動してしまっていたりもあるでしょう。UnityのEditor拡張でトラッキングウィンドウを用意したので、すべて追跡できます。

こういうのRxにも欲しいわー。そうですね、なんか実装方法は考えてみようかとは思いますが一ミリも期待しないで待たないでください。

IValueTaskSourceでWhenAllを進化させる

.NET CoreのC#はTaskとValueTaskに分かれているわけですが、面倒くせーから全てValueTaskでいーじゃん、というわけにはいきません(なお、私の意見は全部ValueTaskでいいと思ってます、というのも使い分けなんて実アプリ開発でできるわけないから）。そうはいかない一番大きな理由はWhenAllで、このTaskで最も使われる演算子であろうWhenAllは、Taskしか受け取らないので、Taskへの変換が必要になってきます。せっかくValueTaskなのにモッタイナイ。じゃあValueTask用のWhenAllを作ればいいじゃん、というとそれも無理で、Task.WhenAllはTaskのinternalなメソッドに依存して最適化が施されているので、外部からはどうしても非効率的なWhenAllしか作れない仕様になっています（クソですね！）。

が、しかし、そもそもWhenAllってあんま効率的じゃなくないっすか？というのがある。と、いうのも、配列を受け取るAPIでも、まず保守的にコピーしてるんですよね。可変長引数でWhenAll(new[]{ foo, bar, baz })みたいに渡してもコピーされてるとか馬鹿らしい！あと、WhenAllの利用シーンでもう一つ多いのが WhenAll(source.Select(x => x.FooAsync()))のような、元ソース起点に非同期メソッドを呼んで、それを全部待つ、みたいなシチュエーション。なんかねー、別に配列作んなくてもいいじゃん、みたいな気になるんですよね。

と、そこでIValueTaskSourceの出番で、Task(ValueTaskですが)の中身を完全に自分の実装に置き換えることができるようになった、のがIValueTaskSourceです。よって、真に効率的なValueTaskに最適化されたうえで↑のような事情を鑑みたWhenAll作れるじゃん、って。思ったわけですよ。

そこでMagicOnionでは(UniRx.Asyncじゃないのかよって、IValueTaskSourceはUnityの話じゃないですから！)ReservedWhenAllPromiseというカスタムなWhenAllを用意してみました。

var promise = new WhenAllPromise(source.Length);
foreach (var item in source)
{
    promise.Add(item.FooAsync());
}
await promise.AsValueTask();

のように書けます。つまり何かと言うと、WhenAllに必要なのは「個数」で、個数が最初から確定しているなら、それを渡せばいいし、WhenAll自体の駆動に配列は必要ないので、随時Addしてあげてもいいわけです。これで、一切配列を使わない効率的なWhenAllが実装できました。めでたし。

他にも型が異なるTaskをawaitするのにValueTupleで受け取りたい、というのをTask.WhenAllを介さずにその個数に最適化したWhenAllを用意するとか、やりたい放題にめっちゃ最適化できるわけです。

と、いうのも踏まえて、(サーバーサイドC#における)アプリケーションのTaskの定義はValueTaskで統一しちゃっていいと思うし、そのかわりに幾つかの最適化したValueTask用のWhenAllを用意しましょう。というのが良い未来なんじゃないかなー、って思ってます。(このValueTask用のWhenAllのバリエーションはCysharpとして作ったらOSSで公開するので、こちらは期待して待っててください！）

まとめ

UniRx.AsyncナシでUnityにasync/awaitを持ち込んで使いこなすのはかなりの無理ゲーなので、よほどUnity以外で使い込んできた経験がある、とかでなければ、素直に使って頂ければと思います。また、そうでなくてもUnity向けに完全に作り直しているUniTaskの存在価値というのは、スライドのほうで十分理解してもらえてるのではとも思っています。

別にCLRの実装は至高のものだ！ってこたぁ全然なくて、時代とかもあるんで、後の世に作り直されるこたぁ往々にめっちゃある。Microsoftのハイパーエンジニアが練りに練ったものだろうがなんだろうが、永遠に輝き続けるコードなんてあんまなく、時代が経ちゃあどれだけ丁寧に作られたものでも滅びるんです。人間もプログラムも老化には逆らえない（WPFなんて何年前のUIフレームワークなんでしょう!)。というわけで、あんまり脳みそ固くせず、自分の意志で時々に見直して考えてみるといいんじゃないでしょうか。(古の)Microsoftよりも(現代の観点では)私のほうが正しい、とか自信持って言っておきましょう。

さて、UniRx.Asyncは(UniRxも)まだまだ完成しきってるとは言えない、のにドキュメント放置、更新放置で例によって半年ぐらい来てしまったのですが、その間は株式会社Cysharpを設立しましたであったり、MagicOnionのリブートであったり、結構わたわたしてしまったところがありなのですが、ようやく諸々落ち着いてきたので、また腰据えて改善に取り組んでいきたいと思います。まぁドキュメントが全然足りないんですけど(UniRx.Asyncの機能は、かなり膨大なのです……)。

C#的にも、自分でTaskの全域を見つめ直して作り直すという経験を通して得られたものも多かったので、今回の記事もそうですが、Unity関係なくasync/awaitを使っていく上で使える話は色々出せていければというところですね。ではまた次回の更新の時まで！次こそはすぐブログ書きますから！

株式会社Cysharpを設立しました

2018-10-31

株式会社Cygames、技術開発子会社を立ち上げ　株式会社Cysharp設立のお知らせ

Cygamesさんと共に、新しくCysharpという会社を立ち上げました。今年の5月に、創業期より参加し6年ほど取締役CTOを務めていた株式会社グラニを退任し、6月からNew Worldという会社を作っていたのですが、今後の活動は基本的にCysharpに集約していきます。

社名の通り、C#を全力でやる会社です。分かりやすい！という出落ちな社名が一周回って気に入ってます。

単一言語にフォーカスするのは勿論リスキーなのですが、自分達の働きがC#をレガシーにしない、むしろ常に最前線に押し上げていく。雇用も需要も作る。世の中のスタンダードをC#にする。という妄想、ではなくて覚悟でやっていくので、つまりは大丈夫にしていくのです。C#自体の発展が滞ってしまえばオシマイなのですが、そこもまた世界が盛り上がっているなら投資は続きます。逆に盛り下がれば、より危なさが増していくので、「業界全体やコミュニティの発展」が大事なわけで、そこを強く意識しながら動いていきたいですね。

もう一つは会社として多様性の確保をどこでやるのか。そもそもグラニの時からC#全振りで多様性のかけらもなかったのですが、無数にあるスタートアップは総体として多様性があればいいと考えてます。テクノロジーを固定して、当たるスタートアップもあれば外れるスタートアップもある。小さな企業がマイクロサービスだの多様性だので採用技術を分散させるのは、中途半端で力を集中させられないだけで、失敗する可能性を上げるだけです。

さて、Cysharpなのですが、親会社であるCygamesさんがかなり大きな企業で、会社を支えるモバイルゲームの部門もあれば、先月発表されたPS4向けのProject AwakeningのようなAAAゲームを内製ゲームエンジンで制作する部門もあれば、Cygames Researchのようなアカデミックに近い研究開発部門もある。大きな企業ならではの自社内での多様性、その中の一つとしてCysharpを考えれば、何も違和感はないでしょう。

私自身としても、個人、あるいは小さいところでやっていくのにはスケールに限界があり、もとより技術にフォーカスした会社を成立させるのはかなり厳しいと考えていたのですが（ミドルウェアで成立させている会社は本当に凄い！）、そしてせめてそれ自体が市場での価値があるものなら、プロダクトベースでやってやれないこともないのですが、「C#」を主軸にしてどうこうっていう、それ自体で大きな価値、大きな影響を作っていくのはかなり難しい。

そういうこともあったりなかったりで（中略）Cygamesさんと共にやっていくことになりました。こうした組み方であれば、言語にフォーカスするというのは、大きなシナジーを産めるはずです！

基本的にゲーム領域での技術開発を中心に行っていきますが、今までどおりに「業界全体の技術やコミュニティの発展に貢献してまいります」、というわけで、ゲームに限らず色々なところで使えるテクノロジーを発信し続けられると考えています。ゲーム業界が魅力的なのは、技術的にハイエンドであり、そこで培われる技術は広い目であらゆるところで役立つからです。実際、グラニでの成果は世界レベルで大きな影響を与えられたと思っていますが、よりスケールアップして、日本はもとより、世界でも大きい存在感を出せるようにしていければと考えています。

なので引き続き、開発した成果はOSSとして出していきますので、その辺はもろもろ安心してください。

会社としての究極的な目標は「C#大統一理論で世界征服」です。クライアントサイドとサーバーサイドに分けて、クライアントサイドでは(Unityの)C#スクリプティングで究極のパフォーマンスを目指す。サーバーサイドではLinux上で動く(さよならWindows Server).NET Coreにフォーカスして、C#でのコンテナベースでの次世代アーキテクチャの確立と実証。でやっていきます。そして両方そなわり最強に見える。

とりあえずまずはMagicOnionをリブートします:)

まだ積極的な採用までは行きませんが、「C#の可能性を切り開いていく」ことに共感し、本気でコミットしていく覚悟があるなら（ちなみにCLR至上主義みたいなのは私は好きではないです、それは可能性を狭めていることなので。UnityもCLRもそれぞれ共に良いと考えて、特性を引き出せる人が望ましいですね）、是非、私の方まで直接言って頂ければというところです。

ちなみにオフィスは渋谷/神泉ですので(Cygamesさんのフロアです)、お近くの方は是非是非。

Memory Management of C# with Unity Native Collections

2018-10-23

と、題してECS完全に理解した勉強会で登壇してきました。

Memory Management of C# with Unity Native Collections from Yoshifumi Kawai

ECSは今後力を入れていきたい分野で、LTドリブン開発ということで、登壇するからにはやってこにゃ！という意気込みだったのですが諸々が諸々で色々間に合わずだったので、ややお茶を濁した展開になってしまいました。なむ。それは別として、これ自体は結構いい話なんじゃないかとは思います。

制約には必ず理由があるはずで、UnityやECSが持つ制約(それは時にC#らしくない、という難癖に繋がる）も、その理由をちゃんと紐解けば合理的な判断に見えるはずです。そこを示していきたいな、というのが今回の発表の流れです。時間的都合もあってECS成分が薄くなってしまいましたが、意味や繋がりは分かってもらえたはずです。私はCoreCLRのアプローチもUnityのアプローチも、どっちもいいと思ってるしどっちも面白く感じられているので、両者を見ながらC#の可能性を広げていきたいですね。

まるでC++というか原始時代に回帰してると言えなくもないんですが、表面のレイヤーはmanagedなC#であることに変わりないし、なるべくその表面のレイヤーを増やす努力は続いていると思われます！ただ、一昔前では、そこC++がー、とかそこはランタイムがー、で賄っていた部分がC#で実装するものとして表に出てきたんですね。これ自体はいいことなのですが、故に、使いこなすための知識としては、回帰してます。(Spanはunsafeまみれじゃないぞ、と言いたいかもしれませんが、Unsafe.***はunsafeマークのついてない実質unsafeなので、むしろより悪質です)。

時代は変わっていくし、C#らしさも変わっていくわけなので、そこは「面白く思うこと」が何より大事だし、変わったものには素直に従って深く追求していく姿勢が大事。乗り遅れず、最前線でやっていきましょう！

最速のC#の書き方 - C#大統一理論へ向けて性能的課題を払拭する

2018-08-25

と、題しまして、CEDEC 2018にて講演してきました。

CEDEC 2018 最速のC#の書き方 - C#大統一理論へ向けて性能的課題を払拭する from Yoshifumi Kawai

今回、事前情報で事務局による誤記が漏れたり、当日のスポンサードの表記から分かる通り、縁がありこのセッションは某社にスポンサードいただきました。公募で落ちてしまい話したくても話せないというパターンも少なくない中で、このような形で枠を得られたのは、申し訳なさもありますが、同時に幸運でもありますので、いつになく気合を入れて仕上げてきました！（ほんと）。難易度はそこまで高いわけじゃない（実際、中辛で設定しました）ので、もっとdopeな話を聞きたい人には物足りなさもあるかもですが、C#というテーマだとあまり語られることのない、目新しい領域の話ですので、新鮮に聞いていただけた方も多いのではないかと思います。

会場も満員御礼で立ち見からの入場規制まで行きましたし、反響も資料は多くリツイートされましたし、反応もかなり良いようなので、かなり満足度高いセッションということでいいのではないでしょうか（多分！）。

謎のChapter4, 5, 6は勿論、最初から存在しない……！次回にご期待下さい。また来年。

Chapter 4: async/await Hackに関しては、来月9/15に行われる「Unity 非同期完全に理解した勉強会」にて話させていただく「Deep Dive UniRx.Async(UniTask)」に内容含まれますので、そちらに乞うご期待。ぜひ参加どうぞどうぞ、と言いたいところなのですがめちょくちょ埋まってしまっているので、ぜひ生放送のほうを見てください。

C#元年を始めよう

去年Uniteにて発表したC#大統一理論がかなりインパクトあったというのもあり、また、その波及効果なのかはさておき、最近手応えを感じ始めてきところでもあります。なのでまぁ、諦めたくないんですね、ここで踏み込んでいけばまだまだ行けるはずなんだ、という。

というわけかで、これは自分自身へのスローガンでもあり、あらゆる方向からアプローチしていこう、と。最初の方で冗談めいて言ってるトライアングル論法は、割と真面目な話でもあり、UniRxの強化(async/await, UniTask)は、よりサーバーサイドC#との親和性を高めていくことにも実は繋がっているのです。実は。

全方位で武器を磨き示すことによって、多くの人が合理的な判断としてC#を選択していく。そんな時代が作れるんじゃないか、始まるんじゃないか。そんな期待と、そのために色々やっていくぞ、という宣言なわけです。ほんと。

こういうの昔もなんかあったなー、と思い出すものがありまして、2012年にgloopsを辞めてからグラニが表に出る前の謎の空白期間があったのですが、その頃のような心境です。何か大きなことを仕込んでいて、やってやるぞ！という、あれそれです。

というわけで、外から見て私が何やってるかは完全に謎だとは思いますが、今後の私の活動にも期待しておいてくださいな。

UniTask - Unity + async/awaitの完全でハイパフォーマンスな統合

2018-07-12

Unityでasync/await使えてハッピー。が、しかしまだ大々的に使われだしてはいないようです。理由の一つとして、Unityが標準でサポートする気が全くなさそう。少なくとも、Unityがフレームワークとしてasync/awaitには何一つ対応していない。async/awaitという道具立てだけじゃあ何もできないのです、フレームワークとして何らかのサポートがなければ機能しないわけですが、なんと、何もない……。

何もないことの理由はわからないでもないです。パフォーマンス面で不満/不安もありそうですし、マルチスレッドはC# Job System使ってくれというのは理にかなっている（私もそちらが良いと思います、つまりTaskのマルチスレッドな機能は原則使わない）。とはいえ、async/awaitは便利なので、このまま、便利だけど性能は微妙だから控えようみたいな扱い（あ、それ知ってる、LINQだ）になるのは嫌なのよね。まぁLINQは局所的なので使わないのは簡単なのだけど（実際、最近は私もあまりLINQ書いてないぞ！遅いからね！）、async/awaitは割と上位に伝搬していって汚染気味になるので、そもそも一度どこかで使うと使わない、という選択肢が割と取りづらいので、ならいっそむしろ超究極パフォーマンスのasync/awaitを提供すればそれで全部解決なのである。

という長ったらしい前置きにより、つまり超究極パフォーマンスのUnityのasync/await統合を提供するライブラリを作りました。場所は（面倒くさいので）UniRxに同梱です。というわけでなんと久しぶりにUniRxも更新しました……！(主にReactivePropertyが高速になりました、よかったよかった。PRとかIssueのチェックはこれからやります、いや、まず重い腰を上げたというのが何より大事なのですよ！)

GitHub/UniRx と、アセットストアに既に上がっています。

UniTask

何ができるか、について。

// この名前空間はasync有効化と拡張メソッドの有効化に必須です
using UniRx.Async;

// UniTask<T>をasyncの戻り値にできます、これはより軽量なTask<T>の置き換えです
// ゼロ（or 少しの)アロケーションと高速な実行速度を実現する、Unityに最適化された代物です
async UniTask<string> DemoAsync()
{
    // Unityの非同期オブジェクトをそのまま待てる
    var asset = await Resources.LoadAsync<TextAsset>("foo");

    // .ConfigureAwaitでプログレスのコールバックを仕込んだりも可能
    await SceneManager.LoadSceneAsync("scene2").ConfigureAwait(new Progress<float>(x => Debug.Log(x)));

    // 100フレーム待つなどフレームベースの待機(フレームベースで計算しつつTimeSpanも渡せます)
    // (次の更新でフレーム数での待機はDelayFrameに名前変えます）
    await UniTask.Delay(100); // be careful, arg is not millisecond, is frame count

    // yield return WaitForEndOfFrameのような、あるいはObserveOnみたいな
    await UniTask.Yield(PlayerLoopTiming.PostLateUpdate);

    // もちろんマルチスレッドで動作する普通のTaskも待てる（ちゃんとメインスレッドに戻ってきます）
    await Task.Run(() => 100);

    // IEnumeratorなコルーチンも待てる
    await ToaruCoroutineEnumerator();

    // こんなようなUnityWebRequestの非同期Get
    async UniTask<string> GetTextAsync(UnityWebRequest req)
    {
        var op = await req.SendWebRequest();
        return op.downloadHandler.text;
    }

    var task1 = GetTextAsync(UnityWebRequest.Get("http://google.com"));
    var task2 = GetTextAsync(UnityWebRequest.Get("http://bing.com"));
    var task3 = GetTextAsync(UnityWebRequest.Get("http://yahoo.com"));

    // 並列実行して待機、みたいなのも簡単に書ける。そして戻り値も簡単に受け取れる（これ実際使うと嬉しい）
    var (google, bing, yahoo) = await UniTask.WhenAll(task1, task2, task3);

    // タイムアウトも簡単にハンドリング
    await GetTextAsync(UnityWebRequest.Get("http://unity.com")).Timeout(TimeSpan.FromMilliseconds(300));

    // 戻り値はUniTask<string>の場合はstringを、他にUniTask（戻り値なし）、UniTaskVoid（Fire and Forget）もあります
    return (asset as TextAsset)?.text ?? throw new InvalidOperationException("Asset not found");
}

提供している機能は多岐にわたるのですが、

Unityの非同期オブジェクトをawaitできるように拡張（最速で動くように細心の注意を払って対応させています）
コルーチンやUniRxで出来るフレームベースのawaitサポート(Delay, Yield)
戻り値をTupleで受け取れるWhenAll, どれが返ってきたかをindexで受け取れるWhenAny, 便利なTimeout
標準のTaskよりも高速でアロケーションの少ないUniTask[T], UniTask, UniTaskVoid

となっています。で、何が出来るのかと言うと、ようはコルーチンの完全な置き換えが可能です。async/awaitがあります、っていう道具立てだけだと、何もかもが足りないんですね。ちゃんと機能するようにフレームワーク側でサポートさせてあげるのは必須なのですが、前述の理由（？）どおり、Unityはサポートする気が1ミリもなさそうなので、代わりに必要だと思える全てを提供しました。

Taskを投げ捨てよ

目の付け所がいかれているので、Taskを投げ捨てることにしました。Taskってなんなの？というと、asyncにする場合戻り値がTaskで強要される、という型。そして究極パフォーマンスの実現として、このTaskがそもそも邪魔。なんでかっていうと、歴史的経緯によりそもそもTaskは図体がデカいのです。異様に高機能なのは（TaskSchedulerがどうだのLongRunningがどうだの)、ただたんなる名残（或いは負の遺産）でしかない。アドホックな対応を繰り返すことにより(言語/.NET Frameworkのバージョンアップの度に)コードパス的に小さくはなっていったのですが(async/awaitするためだけには不要な機能がてんこ盛りなのだ！)、もういっそ全部いらねーよ、という気にはなる。

そこでC# 7.0です。C# 7.0からasyncの戻り値を任意の型に変更することが可能になりました。詳しくは言語仕様のAsync Task Types in C#に書いてありますが、Builderを実装することにより、なんとかなります。

というわけで、UniRx.Asyncでは軽量のTaskであるUniTaskと、そのためのBuilderを完全自前実装して、Unityに最適化されたasync/awaitを実現しました。

代わりにC# 7.0が必須のため、現状ではIncremental Compilerを導入する必要があります（現状のUnity 2017/2018はC# 6.0のため)

Incremental Compilerではなくても、恐らくUnity 2018の近いバージョンではC#のバージョン上がりそうな気配なので、先取りするのは悪くないでしょう。

PlayerLoop

UniRx.AsyncはUniRxに依存していません。そのため、GitHubのreleasesページではUniRxを含まないパッケージも提供しています。併せて使ったほうがお得なのは事実ですが、なしでも十分に機能します。

さて、UniRxではMainThreadDispatcherというシングルトンのMonoBehaviourにMicroCoroutine(というイテレータを中央管理するもの)を駆動してもらっていましたが、今回スタンドアロンで動作させるため、別の手段を取りました。それがPlayerLoopです（詳しくはテラシュールブログの解説が分かりやすい）。

これをベースにUpdateループをフックして、await側に戻す処理を仕掛けています。

Multithreading

掲げたのはNo Task, No SynchronizationContext。何故かというと、そもそもUnityの非同期って、C++のエンジン側で駆動されていて、C#のスクリプティングレイヤーに戻ってくる際には既にメインスレッドで動くんですよね。例えば AsyncOperation.completed += action とか。コルーチンのyield retunもそうですね、PlayerLoop側で処理されている。ようするに、本来SynchronizationContextすら不要なのです、全てメインスレッドで動作するので。

通常のC#はスレッドベースで、Windows FormsやWPF, ASP.NETなど諸々の事情を吸収するために存在していたわけですが、Unityだけで考えるなら完全に不要です。他のものにはないフレーム毎に駆動することと、本体がC#ではなくC++側にあるということが大きな大きな違いです。async/awaitやTask自体は汎用的にする必要があるため、それらの吸収層が必要（SynchronizationContext）なわけですが、当然ながらオーバーヘッドなので、取り除けるなら取り除いたほうが良いでしょう。そのために、UniTaskの独自実装も含めて、全てのコードパスを慎重に検討し、不要なものを消し去りました。

UniTaskはどちらかというとJavaScript的（シングルスレッドのための非同期の入れ物）に近いです。Taskは、そうした非同期の入れ物に加えてマルチスレッドのためなどなど、とにかく色々なものが詰まりすぎていて、あまりよろしくはない。非同期とマルチスレッドは違います。明確に分けたほうが良いでしょうし、UnityではC# JobSystemを使ったほうが良いので、カジュアルな用途以外（まぁラクですからね）ではマルチスレッドとしてのTaskの出番は少なくなるでしょう。

嬉しいこととして、スレッドを使わないのでWebGLでもasync/awaitが完全に動作します。

Rx vs Coroutine vs async/await

もう結論が出ていて、async/await一本でOK、です。まずRxには複数の側面があって、代表的にはイベントと非同期。そのうち非同期はasync/awaitのほうがハンドリングが用意です。そしてコルーチンによるフレームベースの処理に関してはUniTask.DelayやYieldが解決しました。ので、コルーチン→出番減る, async/await → 非同期, Rx → イベント処理というように分離されていくと思われます。

C# Standard vs Unity

正直なところ私は別にUnityがC#スタンダードに添わなくてもいいと思ってるんですよね。繰り返しましが、Unityの本体はC++の実行エンジンのほうで、C#はスクリプティングレイヤーなので。C#側が主張するよりも、C++に寄り添うことを第一に考えたほうが、よい結果がもたらされると思っています。よりC#に、というならPure C#ゲームエンジンでないとならないですが、商業的にはほぼ全滅であることを考えると、Unityぐらいの按配が実際ちょうどいいのだろうな、と。理想もいいんですが、ビジネスとしての成功がないと全く意味がないので。

と、いうわけで、C# JobSystemは大歓迎だしBurst Compilerは最高 of 最高なわけですが（そしてECSなんてそもそもオブジェクト指向ですらなくなる）、さて、Task。UniTaskの有用性や存在意義については、よくわかってもらえたと思います！そのうえで、それを分かったうえでもノンスタンダードな選択を取るべきなのか論は、それ自体は発生して然りです。

まぁ、まずUnityだとそもそもC# 7.0が来たら片っ端からValueTask（という、TとTaskのユニオンがC# 7.0から追加された）に置き換え祭りは発生するでしょう。実際async祭りで組むと、「同期で動くTask」がどうしても多く発生してしまい、無駄なアロケーション感半端ないので、ValueTask主体のほうがよい。

更にその上で.NET Core 2.1ではValueTaskにIValueTaskSourceという仕掛けが用意されて、これは何かと言うと、やっぱりasync/awaitの駆動においてTaskを無視するための仕組みです（現状はSystem.IO.Pipelinesというこれまたつい先週ぐらいに出た機能のみ対応）。そう、別にUnityだけじゃなくて通常の.NETでもTaskはオーバーヘッドと認識されているのだ……。

つまりなんというか、そう、そもそもC#本流ですら割と迷走しているのだ……。存在すると思っているStandardなんてもはやないのだ……。てわけで、別にUniTask、いいんじゃない？とか思ってしまいますがどうでしょう。どうでしょうね、それはさすがにポジショントークすぎにしても。

ようはポリシーとして、asyncで宣言した際に、TaskにするかValueTaskにするかUniTaskにするかを迫られます。逆に言えばそれだけです。あれ、意外と人畜無害。そう、意外と人畜無害なのです。よし、なら、とりまやってみるか。いいんじゃないかな？別に最悪、一括置換で戻したり進めたり割と容易なので。あと、ちなみに、UniTaskがUnityでデファクトスタンダードになれば、尚更迷う必要性はなくなるので、むしろ是非みんなでデファクトスタンダードまで持っていきましょう:)

まとめ

非同期革命の幕開け！そもそもこれぐらいやらないと世論は動かない、というのもあるので、フルセットでどーんと凄い（っぽい）（実際凄い）のを掲示することにはめちゃくちゃ意味があります。UniTaskが流行っても流行らなくても、この掲示にはめちゃくちゃ意味があるでしょう。UniRx.Asyncが何を実現したかを理解することは非常に重要です、教科書に出ますよ！

それと、UniRx全然更新していなくてごめんなさい、があります。ごめんなさい。今回、ReactivePropertyのパフォーマンス向上を（ようやく）入れたり、今後はちゃんと面倒みていくのでまたよろしくおねがいします。

Open Collective/UniRxというところで寄付/スポンサー募集もはじめたので、よければ個人/企業で入れてくれると嬉しいですね……！今ならUniRxのGitHubページのファーストビューにロゴが出るので、特に企業などはアピールポイントです……！

Microsoft MVP for Visual Studio and Development Technologies(C#)を再々々々々々々受賞しました

2018-07-02

新規は毎月で、更新は7月に統一という周期らしく、全然忘れていたのですが、当日はインターネット的にはそわそわした空気を感じたりなかったりはします。変わらず、Visual Studio and Development Technologies、つまりC#を受賞しました。

↑このリングに一個足されます（後日発送）

去年はMessagePack for C#やUtf8Jsonといった、世界的にもヤバいレベルのライブラリの作成（とその実装詳細の紹介）が、最も直接的な成果ですね。私が担っているのはOSSと、実践的で先鋭的なC#、その実証と共有というところであり、世界的に見ても成果を示せているという自信もあり、またMVPはその客観的な証明と考えています。偉そう！まぁ実際成果はえらい。

毎年、今までの延長線じゃない何かをやりたいんだ！と言いつつ、手癖のバリエーション勝負になってる気がしなくもないのがどうなのよ、と思うところもあるのですが、まぁそれはそれでしつこく繰り返すことで、ちゃんと深化しているので、よしとはしておきましょう。近年は C# x 無限大のパフォーマンス、を勝負の軸にしているのですが、結構意義はあると思います。

4月の退職エントリでは、これから何をやっていくのか模索中、という感だったのですが、結果的に今は、割とちゃんと会社を立てて、その名義で仕事を受けています。New World, Inc. ← 未だに何もデザインされていない。UnityやgRPC関連でのアドバイスとかやっていますので、興味あればお問い合わせくだしあ。

去年よりも上を、去年よりも上を、とハードルは無限に高くなっていくので、個人にせよ会社にせよ、世界にインパクトを残していける何かをやっていこう、というのが目標ですね。手元でも一つ二つ、仕込んでいるのがあるのできっと近いうちにお見せ出来ると思います。願わくばそれでチャリンチャリンできるといいんですが（笑）、まぁできなくてもそれはそれですねん。

Rx.NETの近況、或いはUniRxの近況（？）

2018-05-07

あまり長々とした記事ばかりではなく、サラッと流したのも書きましょう！というかリハビリです、リハビリ。ハイパー無職タイムが発動しつつあることもあり、ダラけようと思えば無限にダラけてしまえるのです。なんだかやっぱ一瞬、緊張の糸が途切れた感はどうしてもあります、どうしても。GitHubのグラフもかなり白くなってしまっていますからねー、いやはや。その辺はそろそろモードを切り替えないと、というタイミングです。色々と考えてはいるんですけどね。やることが多すぎると逆にフリーズするというあるああるあるです。

dotnet/reactive

GitHubのリポジトリが Reactive-Extensions/Rx.NET から dotnet/reactive に引越ししました（リダイレクトされます）。これ、ただ単に引っ越したというだけではなく、今回からついにRx.NETがコミュニティ主導による開発に引き渡された、という意味合いを持ちます。これ凄く大きなことでめちゃくちゃ大事なのですよ。

何故かというと、経緯は issues/466 Become an official dotnet repo?のディスカッションにありますが、Rx.NET自体が、ずっとRx v2以降長らくRx.NETの開発をほぼ一人でリードしてきた Bart J.F. De Smet氏(MicrosoftのPrincipal Software Development Engineer, 直近ではBingやコルタナの裏側の分散サービス基盤をRxで実装、とか）によって開発の主導権は握られていました。これは別に悪いことではないですよ！（ほぼ）オリジナルのAuthorですし、実装力も高いですし、学生時代(MS MVP時代)のブログなんかはもう10年前とかの記事ばかりですが今でも珠玉のものばかりですし、私のリスペクトするエンジニアの一人です。んで、まぁそれはいいんですが、かなり昔（4年も前）にRx v3の計画を発表していて(Cloud-scale Event Processing using Rx)、その中心が「Reactor」という上記コルタナの裏側で作られたシステムを元にしてRxを見つめ直すという、多分に野心的なシステムで、なんと結局パブリックにするといって未だにパブリックにされていない！

その辺ののらりくらりっぷりは、以前に私の書いた各言語に広まったRx（Reactive Extensions、ReactiveX）の現状・これからという記事で悲観的に説明しましたが、やはり想像通りに、そんな野心的なビジョンがあるせいで、Rx.NETの開発はほとんど止まっちゃいました。その後の進捗としてはRx.NETをGitHub上でコミュニティを加えて開発していく、という話があり、実際にコミュニティの手によりv3もリリースされましたが、UWPや.NET Standardへ対応するといった、リリースマネージャーを引き受けただけであり、Rx.NETを発展させていく、という点では依然としてコミュニティの手には渡っていない状況が続いていました。

とはいえ、RxJavaやRxSwiftは次々と進化を遂げていて、Rx.NETは元祖ではあるが、ただ単に元祖であるというだけで、すっかり先端ではなくなった現状が間違いなくあり、また、もはや決して看過されるべきではない時期が来ている。壮大なビジョンやオリジナル著者へのリスペクトも大事ですが、何よりも重要なのは止まらない成長なのだ。と、突きつけられたのが件のissueで、まぁ概ね開発の主導も移されました。

こういうの、パイオニアってだけじゃ追いつかれ追い抜かれちゃうから、現代では元祖であること、そのこと自体には価値はないのですよね。良くも悪くも目の前にあるモノの出来が全てで。元祖だとか、10年先を行っていただとか、それは立派なことで尊敬されるべきことですが、ようするにただの勲章なのです。勲章を誇りだしたら老害ですから、一番よくない価値観でもある。(C#は昔からー、とかWPF/XAMLはー、とかMVVMはずっと前にー、とかRxはー、とか言うのはダサいところは結構あります、C#が格好良かった（まだ過去形ではない）のは、実践的な形に落とし込んだ先端を走り続けていたことでしょう）。

さて、開発の主導が渡されたからといって、じゃあ誰が開発していけるの？という話ですが、まずはRxJavaに追いつこうぜ、というところで、現在RxJavaのプロジェクトリードであるakarnokd氏が（RxJavaのコミット数2位、2015年以降だと1位）入って、オペレーターの追加やRxJavaによって成熟された最適化が始まっています。外部の風強い……。

議論の場もreactivex/slackのrxnetチャンネルに移り、活発にやり取りされています。そんなわけで、そう遠くなくRx.NETの時は動き出しそうです。めでたしめでたし。

UniRxの近況？

まぁ、ぶっちけるとRx.NETにおける Bart先生と同じような状況ですね！やりたいこともあるし将来のビジョンもあり、やる気もあるはずなのだけど、手が止まっている、みたいな。ダメじゃん！ダメですね……。

ではなくて、ええと、まぁ私もNew World, Inc.という会社をこないだ立ち上げまして、とりあえず何かお金に変えていかなければならないのです！別に有料にしたりはしませんが、寄付ぐらいは入れたいかなー、とか、思っているのですけれど、だったらプロジェクトはアクティブじゃないとダメですよねアタリマエですよね、ということで、いよいよついにちゃんとガチでやってきます。ほんと。これはほんと。人は霞じゃ生きていけないのでチャリンチャリンも大事。私はよくチャリンチャリンビジネスと言ってます。

それとは別にRx.NET本体をUnity(.NET 4.6/IL2CPP)対応させるというのもあります。これは、Rx.NET側からの要請もあって、手伝っていきたいことですね。とはいえ、UniRxはUnityにフィットさせるために手を加えているものも多いので、コンパイル通してランタイムエラー潰しただけだと、ぶっちけイマイチなところがかなり出てくるので、単純移植はそこまで価値あるかというと、そうでもないかな。というわけで、どちらにせよRxJavaに追いつけプロジェクトのほうが優先なわけで、そちらが落ち着いたら、UniRx側で得た知見などを少しずつフィードバックしていこうかなとは思ってますが、だいぶ遠い未来にはなりそうなので、そういう面でもUniRxは安心して使ってほしいですね。更新もします、しますから……！

実際まあ、Unityもasync/await入ってRxとどう使い分けるとかそもそも使い分けないとか、色々あるわけで、で、私はその答えを持っているので（async/await自体もC#7までの機能をフルに使って色々ごにょったりしたことあるので、私、めちゃくちゃ詳しいんです！）、ライブラリ実装という技術面でも、こうした文章での解説でも、出せていけたらなーという感じですねー。

とにかくダラダラ生きないためにも今年は色々やっていきますよです。

Prev | | Next