neue cc - CircleCIでUnityをテスト/ビルドする、或いは.unitypackageを作るまで
死ぬほどお久しぶりです！別にインターネット的には沈黙してるわけじゃなくTwitterにもいるし、会社(Cysharp)関連で露出あるかもないかもというわけで、決して沈黙していたわけでもないはずですが、しかしブログは完全に放置していました、あらあら。 C#的にも色々やっていて、CloudStructuresのv2を@xin9leさんとともにリリースしたり、多分、今日に詳細を書くつもりですがMicroBatchFrameworkというライブラリをリリースしたり、Ulidというライブラリをリリースしてたり、まぁ色々やってます。ちゃんと。実際。今月はそのMicroBatchFramework関連で、AWS .NET Developer User Group 勉強会 #1に登壇しますし。リブートしたMagicOnionも来月勉強会開催予定だったりで、めっちゃやる気です。 さて、そんなやる気に満ち溢れ
neue cc - 2021年のC# Roslyn Analyzerの開発手法、或いはUnityでの利用法
C#のAnalyzer、.NET 5時代の現在では標準でも幾つか入ってきたり、dotnet/roslyn-analyzersとして準標準なものも整備されてきたり（非同期関連だと他にmicrosoft/vs-threadingのAnalyzerも便利)、Unity 2020.2からはUnityもAnalyzer対応したり、MicrosoftもUnity向けのmicrosoft/Microsoft.Unity.Analyzersという便利Analyzerが登場してきたりと、特に意識せずとも自然に使い始めている感じになってきました。 Analyzerって何？というと、まぁlintです。lintなのですが、Roslyn(C#で書かれたC# Compiler)から抽象構文木を取り出せるので、それによってユーザーが自由にルールを作って、警告にしたりエラーにしたりできる、というのがミソです。更に高度な機
neue cc - TaskとValueTaskの使い分け、或いはValueTaskSupplementによる福音
ValueTaskSupplementというライブラリを新しく作って公開しました！ Cysharp/ValueTaskSupplement これは、ValueTaskにWhenAny, WhenAll, Lazyを追加するという代物で、それだけだとヘーそーなんだー、としか思えないと思われます。しかし、ValueTaskを使っていくと、めっちゃくちゃ欲しくなる機能になってます。ないと死ぬレベルで。 と、いうわけで、なんでこれが必要なのか、っていうところから説明します。 C# 5.0にasync/awaitが導入された当初はTaskしか存在しませんでした。標準APIのあらゆるメソッドにasyncメソッドを生やすなど、Microsoftの多大な努力により、C#はいち早く非同期時代を迎え、async/awaitは多用（濫用とも言う）されるようになりました。しかし、多用された結果、当初思ってたよりも
neue cc - async decoratorパターンによるUnityWebRequestの拡張とUniTaskによる応用的設計例
UniTask v2も2.0.30まで到達し、いい加減そろそろ安定したと言える頃合いです（ほんと！）。GitHub Star数も1000を超えて、準スタンダードとして安心して使ってもらえるレベルまで到達したと思うので、基盤部分から入れ込んで設計するとこんなことができますよ、という一例を出してみます。 UnityWebRequestはかなりプリミティブな代物で、そのまま使うよりかはある程度はアプリケーションに沿ったラッパーを被せることがほとんどなのではないかと思います。しかし、ライブラリ単体でアプリケーションの要求を全て満たそうとするとヘヴィになりすぎたり、というかそもそもアプリケーション固有の要求には絶対に答えられない。というわけで、理想的なラッパーというのは、それ自身が極力軽量で、拡張性を持たせたプラガブルな仕組みが用意されているものということになります。プラガブルな拡張性がないと、例え
neue cc - ProcessX - C#でProcessを C# 8.0非同期ストリームで簡単に扱うライブラリ
C#使う人って全然外部プロセス呼び出して処理ってしないよね。というのは、Windowsがなんかそういうのを避ける雰囲気だから、というのもあるのですが、ともあれ実際、可能な限り避けるどころか絶対避ける、ぐらいの勢いがあります。ライブラリになってないと嫌だ、断固拒否、みたいな。しかし最近はLinuxでもばっちし動くのでそういう傾向もどうかなー、と思いつつ。 避けるというのはOSの違いというのもありそうですが、もう一つはそもそも外部プロセスの呼び出しが死ぬほど面倒くさい。ProcessとProcessStartInfoを使ってどうこうするのですが、異常に面倒くさい。理想的にはシェルで書くように一行でコマンドと引数繋げたstringを投げておしまい、と行きたいのですが、全然そうなってない。呼び出すだけでも面倒くさいうぇに、StdOutのリダイレクトとかをやると更に面倒くさい。非同期でStdOutを
neue cc - UniTask - Unity + async/awaitの完全でハイパフォーマンスな統合
Unityでasync/await使えてハッピー。が、しかしまだ大々的に使われだしてはいないようです。理由の一つとして、Unityが標準でサポートする気が全くなさそう。少なくとも、Unityがフレームワークとしてasync/awaitには何一つ対応していない。async/awaitという道具立てだけじゃあ何もできないのです、フレームワークとして何らかのサポートがなければ機能しないわけですが、なんと、何もない……。 何もないことの理由はわからないでもないです。パフォーマンス面で不満/不安もありそうですし、マルチスレッドはC# Job System使ってくれというのは理にかなっている（私もそちらが良いと思います、つまりTaskのマルチスレッドな機能は原則使わない）。とはいえ、async/awaitは便利なので、このまま、便利だけど性能は微妙だから控えようみたいな扱い（あ、それ知ってる、LINQ
neue cc - UniRx 5.4.0 - Unity 5.4対応とまだまだ最適化
UniRx 5.4.0をリリースしました！ちょうどUnity 5.4もリリースされたので、5.4向けの修正(Warning取り除いただけですが)を出せて良かった。というわけで5.4正式対応です。リリースは前回が5月だったので3ヶ月ぶりです。5.2 -> 5.3も3ヶ月だったので、今のとこ3ヶ月スパンになってますが偶然です。 GitHub/UniRx AssetStore/UniRx 何が変わったのかというと Add: Observable.FrameInterval Add: Observable.FrameTimeInterval Add: Observable.BatchFrame Add: Observable.Debug(under UniRx.Diagnostics namespace) Add: ObservableParticleTrigger and OnParticleC
neue cc
MicrosoftからIntroducing Garnet – an open-source, next-generation, faster cache-store for accelerating applications and servicesという記事が今日公開されて、Garnetという新しいインメモリデータストアがOSSとして公開されました。Microsoft ResearchでFASTERを手掛けていたチームによるもので、FASTERはC#実装の高速なキーバリューストアでした。今回のGarnetはその発展形のようなもので、FASTERベースのストレージと、Redis互換のプロトコルによる、インメモリデータストアになっています。詳しくはGarnetのほうのブログA Brief History of Garnetで。GarnetもC#で作られています。 ベンチマークによると、Re
neue cc - Utf8Json - C#最速のJSONシリアライザ(for .NET Standard 2.0, Unity)
Utf8Jsonという新しいC#用のJSONシリアライザを作りました。.NET Standard 2.0で作っているのでふつーの.NETでもXamarinでも概ね動くはずです（.NET 4.5版もあります）。また、Unity用にもちゃんと用意しています。Unityの場合はJsonUtilityと比較してどうよ、ってことなんですが、いいと思いますよ（あとで少しだけ説明します） GitHub - neuecc/Utf8Json なんかバズって、一気に350 Star超えしました。GitHubのToday's Trending - C#で1位、全体で20位ぐらいになってたりました。 使い方を説明してもしょうがないので(ReadMe見てね)、ここではパフォーマンスに関する実装面での工夫について説明します。 赤枠で囲ったのがUtf8Jsonで、それより左側はバイナリシリアライザです。JSONでは最速
neue cc - .NET最先端技術によるハイパフォーマンスウェブアプリケーション FAQ
Build Insider Offlineにて、「.NET最先端技術によるハイパフォーマンスウェブアプリケーション」と題して、グラニのC#によるウェブアプリケーション作成の仕組みについて話してきました。 一日でViewsが1万、はてブが250と、ドトネト系にしては珍しく多くの人に見てもらえたようでなにより。 今までのC#関連って、MS純正ライブラリを使ったどうのこうの、というのはありましたが、外部ライブラリを組み合わせて、実践的にどうしているかっていうような話ってほとんどなかったんですよね。やってるところがない、ことはないのですが、しかし表にない、見えないものはないに等しいです。 別にC#だって自分達の手でライブラリを選び、作り、組み上げていく。それがこれからの時代のスタンダードです。遅れていたのかもしれません。しかし、遅すぎるなんてことはない。素材は良いし、.NETは死んだのでなく、むし
neue cc - UniRxでの空呼び出し検出、或いはRoslynによるCode Aware Libraries時代の到来について
UniRx - Reactive Extensions for Unity用に、メソッド呼んだだけで何も処理してないIObservable<T>があったらWarningを出すAnalyzerを作ってみました。 AnalyzerはVisual Studio 2015からの機能です。というわけでVisual Studio 2015 RCが必要です。あとは、NuGetからAnalyzerが入れられるようになっているので Install-Package UniRxAnalyzer でOK。Unityのプロジェクトであっても問題なく使えます(ただしVSTUのcsproj自動生成でAnalyzerタグは吹っ飛ぶので、生成をフックして復元する必要はあります、フック方法の詳細はみんな大好き Boo.Lang を SATSUGAI する方法を参照のこと)。もし、他にこういうAnalyzerがあったら便利なの
neue cc - 第一回UniRx勉強会を開催しました＋スライドまとめ
と、いうわけかでUniRx勉強会を開催しました。当日の模様はtogetterまとめで。登録が150人ほど、生憎の雨天でしたが130人以上来てくださってめっちゃ嬉しかったですね。慣れないというかはぢめての主催＋司会でその辺アレだったのですが、会場をお貸し下さったgloopsさんの手厚い協力のお陰で、なんとか成立させることができ、ほんとうに感謝です。 私の発表資料は「History & Practices for UniRx UniRxの歴史、或いは開発(中)タイトルの用例と落とし穴の回避法」になります。 あまりUniRx固有、という感じでもなく、また凄い話、でもなんでもない地味な内容なのですけれど、ちょっとはまると嫌だなー、けどはまりがちなポイントを説明してみた、といった感。地味すぎてトリとしてはなんともいえない感じでしたね、うむむむ。ちなみにReal World UniRxというのは、Re
neue cc - 非同期時代のLINQ
この記事はC# Advent Calendar 2013の4日目となります。2012年はMemcachedTranscoder - C#のMemcached用シリアライザライブラリというクソニッチな記事で誰得でした（しかもその後、私自身もMemcached使ってないし）。その前、2011年はModern C# Programming Style Guide、うーん、もう2年前ですかぁ、Modernじゃないですねえ。2011年の時点ではC# 5.0はCTPでしたが、もう2013年、当然のようにC# 5.0 async/awaitを使いまくる時代です。変化は非常に大きくプログラミングスタイルも大きく変わりますが、特にコレクションの、LINQの取り扱いに癖があります。今回は、非同期時代においてLINQをどう使いこなしていくかを見ていきましょう。 Selectは非同期時代のForEach これ超大
neue cc - 同期（風）コードと対比させたUnity+UniRxで非同期を扱う場合のパターン集
UniRxのGitHubのStar数が500行きました！ 今のところGitHub上でのUnity + C#でスター順の検索だと、世界5位です。おおー。更に上を狙いたいところですね。最近はちょっと更新が滞っていますが、ネタはあるのでより完成度を高めたい。(滞った理由は、PhotonWireとか色々他のところに手を出していたため……) さて、本題。イベント結合に使う際はあてはまりませんが、Rx(UniRx)を非同期（長さ1のIOservableシーケンス)として扱う場合、それなりに癖があります。とはいえ、基本的には同期（或いはyield return)で書いていた際と、1:1で対比できるパターン化した形で概ね対応できるので、そのためのチートシートを考えてみました。コード例はC# 5.0のasync/awaitで出しますが、同期コード or IEnumeratorと同じように思ってもらえればいい
neue cc - C#(.NET, .NET Core, Unity, Xamarin)用の新しい高速なMessagePack実装
と、いうものを作りました。MessagePackのC#版です。以前に作ったZeroFormatterのコードをベースに、バイナリの読み書きをMsgPackのフォーマットに差し替えたものになります。MsgPackのライブラリはすでにあるじゃん(MsgPack-Cli)！ってことなんですが、パフォーマンスにかなり差があります。 neuecc/MessagePack-CSharp JSON.NET（スタンダードで、豊富なAPIを持ってる）に対するJil（スピード特化、APIは必要十分はあるけれどJSON.NETほどではない）のようなものと思ってください。とはいえ、生のまま使っても問題は出ない（デフォルトのままで最高速が出るようにチューニングしてある）でしょうし、カスタマイズの口自体も十分用意してあります！詳しくは「拡張」の項で説明しますが、既に私自身が他のライブラリへの対応・インメモリデータベー
neue cc - ZeroFormatter - C#の最速かつ無限大高速な .NET, .NET Core, Unity用シリアライザー
（現状は）C#専用の、新しいシリアライズフォーマットを作りました。アセットストアには置いてないんですが、GitHubで公開しています。ReadMeが超書きかけですが明日ぐらいには全部書き終わってるはず……。 neuecc/ZeroFormatter 特徴はデシリアライズ速度がゼロなので、真の意味で爆速です。そう、無限大高速。 嘘くせー、って話なんですが、実のところこれは類似品があって、Googleの出してるFlatBuffersと基本的な考えは同じです（他にCap'n Protoというのもあります、こっちも元Googleの人ですね）。デシリアライズ「しない」から速い。つまるところ必要になるときまでパースを先送りするってことです。これは、アプリケーションの作りにもよりますが非常に効果があって、例えばデカいマスタデータをドバッと取得するなんてときに、その場で必要なデータってその巨大データのごく
neue cc - C#のGCゴミとUnity(5.5)のコンパイラアップデートによるListのforeach問題解決について
UnityにおいてList<T>のforeachは厳禁という定説から幾数年。しかしなんと現在Unityが取組中のコンパイラアップデートによって解決されるのだ！ついに！というわけで、実際どういう問題があって、どのように解決されるのかを詳しく見ていきます。 現状でのArrayのforeachとListのforeach まずは現状確認。を、Unityのプロファイラで見てみます。以下の様なコードを書いて計測すると……。 var array = new int[] { 1, 2, 3, 4, 5 }; var list = new List<int> { 1, 2, 3, 4, 5 }; // ボタンを叩いて計測開始 button.OnClickAsObservable().Subscribe(_ => { Profiler.BeginSample("GCAllocCheck:Array"); fo
neue cc - UniRx 5.0 - 完全書き直しによるパフォーマンス向上とヒューマンリーダブルなスタックトレース生成
UniRx(Reactive Extensions for Unity)のVer 5.0が昨日、AssetStoreにリリースされました。前回が4.8.2で6月なので、半年ぶりで、今回はメジャーアップデートとなります。現在の最新であるUnity 5.3（の新機能）に対応というのもあります、が、今回の目玉は書き直しです。半年間なにやっていたかというと、書き直そう！いよいよやっと重い腰を上げてスタックトレースに優しいコードにしよう！と思い立って始めてみたもののメンドウくささが極まって挫折して放置。してたんですが、先月ぐらいに、いい加減に手を付けたくて、ちょっとうちの会社の仕事時間を貰ってゴリゴリ進めてやっと終わりました。 GitHub - UniRx UnityAssetStore - UniRx とりあえず分かりやすい成果としては、スタックトレースです。 var rp = new React
neue cc - Unityでのボクシングの殺し方、或いはラムダ式における見えないnewの見極め方
Happy boxing! UniRxの前回リリース(UniRx 5.0.0)でパフォーマンス向上を果たしたと書きましたが、まだやり残したことがありました。それがボックス化(boxing)の殺害です。ボックス化は単純に言うと、せっかくの値型が箱に入っちゃってGCゴミが発生してGCがーーー、というもの。避けれるなら避けるべし。あ、ちなみに今回の内容は特に別にUnityに限らないふつーのC#の話です。 それと、というわけかでUniRx 5.1.0リリースしました、アセットストアから落とせます。基本的な内容は以下に解説するボックス化を徹底的に殺害したことによるパフォーマンス向上です。 ボックス化とジェネリクス GCって、別に見えてるnewだけで発生するわけでもありません。見えてるものを警戒するのは大事ですが、見えないものを見てないのは片手落ち感が否めない。そんな見えないものの代表例がボックス化で
neue cc - Unityにおけるコルーチンの省メモリと高速化について、或いはUniRx 5.3.0でのその反映
UniRx 5.3.0をリリースしました！今回のアップデートは、内部的な最適化、です。最適化は、もうそろそろあんまやるところ残ってないよね、なんて思ってたんですが、じっくり考えるとそんなことなく割とあったので埋めました。それが表題のコルーチンの省メモリと高速化です。使い方次第ではありますが、場合によっては今回のアップデートでものすごく恩恵に授かる人もいればそこそこの人もいるかもです。ともあれ基本的に内部的に変更してるだけなので、入れるだけでそれなりに高速化したりする可能性がそれなりにあります。 GitHub/UniRx AssetStore/UniRx 前回が2月だったので3ヶ月ぶりですね。あまりオペレータ追加がないので、次はオペレータ追加に集中したい気もする。なんか優先的に欲しいのあればリクエストもどうぞ(Observable.Windowとかいい加減そろそろ入れろよって話なんですが）
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
