タグ

c#に関するgriefworkerのブックマーク (201)

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

    A Brief History of UniRx/UniTask, IUniTaskSource in Depth

    Deep Dive async/await in Unity with UniTask(UniRx.Async)
  • Expression Trees をシリアライズする | TAKESHIK.ORG

    griefworker
    griefworker 2018/09/13
    「なぜ Expression をシリアライズできないようにした!!」
  • WebAssembly でシングルページアプリケーションが開発できる Blazor フレームワークの公式チュートリアルをやったら近未来感が凄かった - Qiita

    WebAssembly でシングルページアプリケーションが開発できる Blazor フレームワークの公式チュートリアルをやったら近未来感が凄かったC#SPAWebAssemblyASP.NET_CoreBlazor はじめに Blazor は、WebAssembly を使用してブラウザで実行される、.NET上に構築されたシングルページ Web アプリケーションフレームワークです。 @jsakamoto さんのC# で Single Page Web Application が書ける Blazor が凄かった件 にとても詳しく載っています。 大まかな仕組みとしては C# をコンパイルした IL(.NET の中間言語)を WebAssembly にコンパイルすることでブラウザで .NET が実行できます。 TypeScript やその他 AltJS のように JavaScriptトランス

    WebAssembly でシングルページアプリケーションが開発できる Blazor フレームワークの公式チュートリアルをやったら近未来感が凄かった - Qiita
  • CEDEC 2018 最速のC#の書き方 - C#大統一理論へ向けて性能的課題を払拭する

    Talked at CEDEC 2018, 2018/08/22 - https://2018.cedec.cesa.or.jp/session/detail/s5b559852a6405

    CEDEC 2018 最速のC#の書き方 - C#大統一理論へ向けて性能的課題を払拭する
    griefworker
    griefworker 2018/08/22
    狂気に彩られた執念。凄まじい。
  • neue cc - UniTask - Unity + async/awaitの完全でハイパフォーマンスな統合

    Unityでasync/await使えてハッピー。が、しかしまだ大々的に使われだしてはいないようです。理由の一つとして、Unityが標準でサポートする気が全くなさそう。少なくとも、Unityがフレームワークとしてasync/awaitには何一つ対応していない。async/awaitという道具立てだけじゃあ何もできないのです、フレームワークとして何らかのサポートがなければ機能しないわけですが、なんと、何もない……。 何もないことの理由はわからないでもないです。パフォーマンス面で不満/不安もありそうですし、マルチスレッドはC# Job System使ってくれというのは理にかなっている(私もそちらが良いと思います、つまりTaskのマルチスレッドな機能は原則使わない)。とはいえ、async/awaitは便利なので、このまま、便利だけど性能は微妙だから控えようみたいな扱い(あ、それ知ってる、LINQ

  • neue cc - asyncの落とし穴Part3, async voidを避けるべき100億の理由

    だいぶ前から時間経ってしまいましたが、非同期の落とし穴シリーズPart3。ちなみにまだ沢山ネタはあるんだから!どこいっても非同期は死にますからね! async void vs async Task 自分で書く場合は、必ずasync Taskで書くべき、というのは非同期のベストプラクティスで散々言われていることなのですけれど、理由としては、まず、voidだと、終了を待てないから。voidだと、その中の処理が軽かろうと重かろうと、終了を感知できない。例外が発生しても分からない。投げっぱなし。これがTaskになっていれば、awaitで終了待ちできる。例外を受け取ることができる。await Task.WhenAllで複数同時に走らせたのを待つことができる。はい、async Taskで書かない理由のほうがない。 んじゃあ何でasync voidが存在するかというと、イベントがvoidだから。はい。b

  • neue cc - 株式会社グラニを退任します

    創業期より参加し、取締役CTOを務めている株式会社グラニを退任します(今日、ではなく正確にはもう少し残りますが)。 マイネットさんのプレスリリースより、グラニのスマートフォンゲーム事業に関する買収と協業に向けた基合意のお知らせ、グラニのスマートフォンゲーム「黒騎士と白の魔王」の配信権を買取。4月よりマイネットグループが提供・運営を持ちまして、タイトルならびにグラニのメンバーはマイネットグループへと参画しますが、私は移らず、そのまま退任という形になります。開発チームそのものはマイネットさんへ引き続きジョインしますので、ゲーム自体の運営は問題なく続いていきます。その点はご安心ください。 私の次は決まっていないので、とりあえずGitHubにレジュメを公開しています。 GitHub - neuecc/Resume また、個人会社として New World, Inc. を設立しました(正確にはまだ

  • C#の実験的なBlazor(WebAssembly+Razor)とSignalRでチャットを作ってみた2実装編 - Qiita

    前書き こちらはタイトル通りのチャットの基部分をとりあえず作ってみたのでサンプルとして投稿しております。当投稿は実装編となり、開発準備などを行った1準備編の続きです。 あくまでも実用レベルではありませんので見た目は適当で送受信する内容もチャットとして使うには足りていないものになりますが、以下の内容を実装できればとりあえずの基礎部分はできるため十分かと思います。 送信ボタンのクリックでC#のイベントハンドラを呼び出す C#からJavaScriptを呼び出し、画面の入力値をクラスのインスタンスを引数として渡す SignalRをJavaScriptから使用してServerのhubへ送信し、全クライアントで受信する(こちらはただのAsp.Net CoreによるSiganlRなので特に問題はないはずでした) JavaScriptからC#のメソッドを呼び出してhubより受信したオブジェクトを引数とし

    C#の実験的なBlazor(WebAssembly+Razor)とSignalRでチャットを作ってみた2実装編 - Qiita
  • C#の実験的なBlazor(WebAssembly+Razor)とSignalRでチャットを作ってみた1準備編 - Qiita

    この投稿は何? とりあえずBlazorとSignalRを使用してシンプルなとなりますがチャットを作るところまで持って行けましたので投稿してみました。 ※この記事はBlazorの0.1.0preview頃の情報を元にしています。 正直2018年06月29日現在では0.5.0previewになっており、破壊的な変更も多く入っています。 また、Blazorが凄かった件のjsakamoto氏のBlazor アプリケーションプログラミング自習書は非常に役に立ちますので一読することをお勧めします。 自分もこれを見てやっちまってるゎーと思って修正したところやこんなことができるのかと追加したところがあります。(追記:2018年06月29日) 2020年01月28日のASP.NET Blog|Blazor WebAssembly 3.2.0 Preview 1 release now available B

    C#の実験的なBlazor(WebAssembly+Razor)とSignalRでチャットを作ってみた1準備編 - Qiita
  • C# で何か出来るのか?まとめてみた - かずきのBlog@hatena

    追記 2020 年 3 月版を書きました。 qiita.com 文 C# は好きな言語です。C# 1.0 が 2002 年 4 月に出てからもうすぐ16 年!?になろうとしています。 今でも結構イケてる部類にランキングしてると個人的に思ってる C# ですが何が出来るのか?というのをまとめてみたいと思います。C# をこれから始めようと思っている方や、プログラミングを始めようと思ってるけど何を勉強しようか迷っている方が C# を検討する上での参考になればと思います。 コンソールアプリケーション開発 誰もが一度は書く黒い画面に Hello world の文字列を印字するアプリケーションもコンソールアプリケーションです。C# でももちろん作ることが出来ます。以下のような OS に対応しています。 OS .NET Fw or .NET Core Windows .NET Framework and

    C# で何か出来るのか?まとめてみた - かずきのBlog@hatena
  • neue cc - ReactivePropertySlim詳解

    ReactiveProperty v4.1.0 をリリースしましたということで、Pull Requestしたコードをリリースして頂きました。ReactivePropertyはオリジナルは私が作ったのですが、数年前からokazukiさんがメインに開発/リリースしてもらっています。 今回はReactivePropertySlimという新クラスが追加されました!名前の通り、軽量なReactivePropertyで、これはもともと社内で(Unityの)ReactivePropertyを大量に使っていて、改善のやり玉に上がっていて、その中で施された/施した施策を移植してきたという代物になります。当初そんな乗り気じゃなかったんですが、同僚に書き換えてもらったのを見て、ようやくやる気が上がったという、最低ですね、はい。 無印との違いは フィールド数を最小限にしてアロケーションを抑えた(無印はバリデーショ

  • HttpClientをマルチスレッドで運用する場合の注意点 - Qiita

    始めに HttpClientをマルチスレッドかつ高負荷で回す時、少々ハマった点があったので、注意するべき点について書く。 シングルスレッドの場合 https://aspnetmonsters.com/2016/08/2016-08-27-httpclientwrong/ にもある通り、できる限り一つのHttpClientインスタンスで使いまわすという方法で問題はない。 実際自分もこういう風に使っていた。 マルチスレッドの場合 しかし、マルチスレッドでこれを行うと少々厄介なことになる。 実際に以下のようなメソッドを適当なWindowsマシン上で実行してみよう。(要dotnet-sdk-2.0以上) using System; using System.Net; using System.Linq; using System.Net.Http; using System.Threading.T

    HttpClientをマルチスレッドで運用する場合の注意点 - Qiita
  • もう少し簡単に Xamarin.Forms で Windows (Classic) Desktop アプリ開発を今からしてみる - Qiita

    もう少し簡単に Xamarin.Forms で Windows (Classic) Desktop アプリ開発を今からしてみるC#XamarinXamarin.Forms はじめに 前回 の記事でまだリリースされてない Xamarin.Forms の GTK / WPF PlatformGitHub のソースコードから使う方法をまとめましたが、 Xamarin.Forms の Nightly Builds を使った方がもっと簡単できるという事がわかったので改めて記事にしたいと思います。 今回の記事は下記 blog を参考にさせてもらっています。ありがとうございます。 Xamarin Forms WPF - Quick Start 手順的に大きく違うところは GitHub からソースを取得してビルドするのではなく、 myget.org というところにある Nightly Build

    もう少し簡単に Xamarin.Forms で Windows (Classic) Desktop アプリ開発を今からしてみる - Qiita
  • neue cc - UniRx 4.8 - 軽量イベントフックとuGUI連携によるデータバインディング

    UniRx(Reactive Extensions for Unity)のVer 4.8が昨日、AssetStoreにリリースされました。UniRxとはなにか、というと、巷で流行りのReactive Programming、の.NET実装のReactive Extensions、のUnity実装で、私が去年ぐらいからチマチマと作っています。実際のところ細かいリリースは何度も行っているんで(差分はGitHubのReleasesに書いてあります)、開発/アップデートはかなりアクティブな状態でした。その間に、Google PlayやiOSのAppStoreでもチラホラと使用しているタイトルがあったりと(ありがとうございます!!!)、案外存外しっかりRealWorldしていました。GitHubのStarも順調に伸びていて、まぁまぁメジャーになってきた気はします。 その間に、いくつか素晴らしいプレゼ

  • neue cc - 2017年を振り返る

    毎年恒例ということにしているので、今年も振り返ってみます。 まず、「黒騎士と白の魔王」がリリースされました。開発2年分の成果が結実ということで、まずはメデタシ。セールス的にも一定の足跡を残せています。昨今モバイルゲームもシブい状況になってきてはいますが、その中でキャラ物ではないノンIPのオリジナルタイトルでこのレベルに達せているものがどれだけあるか、ということを考えると、自分達でいうのもアレですが、実際やりますな、みたいなのは、ありますね! さて、私個人としても、今年は大きな弾を幾つか出して、大きなインパクトを与えられたんじゃないかと思います。去年ではC#を書く技量が向上した、というのが実感としてありました。そして今年も引き続き、技量向上しました!と、はっきりと言い切れる、感じ取れるだけの成長は果たせています。人間どこででも、どこまでも成長できるし、完成したと思った瞬間に下り坂は始まるので

  • Xamarinの基盤「Mono」のmonoランタイムとクラスライブラリ

    Xamarinにおけるソフトウェアの基盤であるMonoを深く理解すれば、Xamarin製品の理解はもっと深まる。今回はmonoランタイムと、Monoのクラスライブラリについて解説する。 ← 前回 連載 INDEX 次回 → 前回は、Monoの成り立ちから、そのソフトウェア構成、C#コンパイラーの内容まで、Monoについて解説した。今回も引き続き、monoランタイムと、Monoのクラスライブラリについて解説する。 mono: ECMA CLIランタイム 次はmonoランタイムについて説明しよう。monoランタイムは、.exeファイルや.dllファイルを解釈して、そのCIL(MSIL)コードをCPUのネイティブ命令に置き換えて実行する、実行エンジンだ。その中身は、CIL(MSIL)メタデータローダー、JITコンパイラーなどの実行エンジン、メモリ管理(ガベージコレクション)、AppDomain

  • 小ネタ Concurrent コレクション

    .NET 4以来、System.Collections.Concurrent以下に、 Concurrentなコレクションがいくつか追加されました。 Concurrent、英単語の意味としては「同時に起こる」という意味の形容詞。 プログラミングにおいては、「複数のプログラムやスレッドから同時にアクセスされる」という意味で使われ、 「並行」とか「同時実行」とか訳されます。 たいてい、「Concurrentなんとか」みたいな名前のものは「同時実行があっても問題が起きない」という意味になります。 ただし、「問題を起こさない」って言ってもいろいろな意味があって、それぞれのコレクションの性質をちゃんとわかっておかないと困ったりします。 (.NET のSystem.Collections.Concurrentに限らず、たいていのプログラミング言語のたいていのライブラリで、Concurrentと名の付くも

    小ネタ Concurrent コレクション
  • C# でオレオレパーサコンビネータをつくってみる - Qiita

  • libsoundio-sharpとPInvokeGeneratorについて - ものがたり

    このエントリはC# Advent Calendar 2017の7日目のエントリです。6日目のあめいさん @amay077 のエントリからのバトンを引き継いでいます。 まえがき .NETエコシステムに圧倒的に足りないもののひとつが、クロスプラットフォームのサウンド系APIです。サウンド系APIは伝統的にプラットフォーム固有のものであり(例: NAudio、CSCore)、SharpDX)、これらはクロスプラットフォーム アプリケーションで使うことはできません。これではC#でクロスプラットフォームのサウンド系アプリケーションが書かれる日は未来永劫来ないでしょう。 クロスプラットフォームのサウンド系アプリケーションなんてあるんでしょうか? あるんですよ。格的なのが。 Bitwig Studio 2.2: Renoise 3.1: Tracktion Waveform8: これ全部Ubuntu

    libsoundio-sharpとPInvokeGeneratorについて - ものがたり
  • ビルドで使う C# コンパイラーを差し替える

    Visual Studio 2017 15.5で、C# コンパイラーのコード生成の仕方がちょっと変わりました。 その余波で起きる問題を回避するために、Visual Studio は 15.5 のまま、C# コンパイラーのバージョンだけを下げる方法について話します。 背景 C# コンパイラーが出力するコードのどこが変わったか 15.5 の世代では、とにかくいろいろパフォーマンス改善を行っています。 .NET Coreのランタイムや標準ライブラリのパフォーマンスも1~2割上がっています。 Visual Studioも、ソリューションのロードにかかる時間が半減していたりします。 C# コンパイラーも、コンパイラーが出力するコードがより速くなるように微妙に調整が入っています。 コンパイラーの出力結果なんですが、今まで int (符号付き)だったところが uint (符号なし)で生成されていたりしま

    ビルドで使う C# コンパイラーを差し替える