本サイトからスピンオフした姉妹サイトです。「最先端のC#技術活用」を掲げる会社の開発現場では、どのような技術やライブラリが、どんな理由で使われているのか。C#開発者必読の、勉強会レポート。第1回」を開催した(場所は、六本木ヒルズ森タワー15Fにあるグラニのファンスペース)。この勉強会では、下記の2つのセッションがあった。氏が登壇した1のセッション内容の中から、筆者が重要だと感じたポイントを簡潔にまとめたものである。文章によるレポートの他、本稿の最後にはセッションスライドと動画もあるので、全内容を詳しく知りたい場合は併せて閲覧・視聴してほしい。5という最新C#&.NET技術やUnityを活用している。Extensionsを開発したりしている。2012年に創業したグラニでは、これまで図1のような製品をリリースしているとのことだ。グラニがリリースしている製品ちなみに、「神獄のヴァルハラゲート」のキャラである「マンモン伯爵」のLINEスタンプもあるとのこと。CSharp;」を標語に掲げており、開発では「C#を使っていく」と決めているという。ちなみにC#は現在、下記のようにあらゆる領域で使えるようになっている。MotionC#を選ぶ理由この方針のため、C#言語一つに依存することになるわけだが、「逆にそれは強みでもある」と河合氏は語る。多様な言語を使い分けると技術・ノウハウは分散してしまうが、C#、1本に絞ればそういった問題を回避できるからだ。MVCのWebサービス」の両方が開発できる。これだとサーバーとクライアントの開発スキルが統一できるので、開発者間のコミュニケーションが取りやすくなったり、両方を同じ開発者が担当したりできるなど、かなりメリットが大きい。これが「グラニがC#を選ぶ理由である」が、もちろん「C#が好きだから」というのもあると、河合氏は話した。グラニのフレームワークグラニでは、開発で必ず使うフレームワークのようなものは、基本的に作らないことに決めているそうだ。あるのは最低限のルールだけ(コーディング規約すらなく、コードの書き方も既存のコードを見て“習うより慣れろ”形式である)。している理由は、「フレームワークによってプログラミングに制約を課すことなく、自由に開発できる体制を維持したいからだ」という。共通ライブラリを使う場合も、DLLファイルによるアセンブリ参照ではなく、プロジェクト参照にすることで、ライブラリのソースコードをデバッグ時にすぐに参照できるようにしている。要は、自分で考えて自分で解決できる環境を作ることで、フレームワーク側を強化するのではなく、開発者自身の成長を促しているわけだ。「フレームワークは作らない」といっても、便利なメソッドをまとめたような小さな共通ライブラリは作っているとのこと。次節で、それを紹介しよう。共通ライブラリのGrani.CoreLib.dllはグラニ社内唯一の共通ライブラリで、グラニのあらゆるプロジェクトがこのライブラリを参照している。河合氏は、その特徴を捉えて「ヒュージ・モノリシック・ライブラリ」(=内部に実装がまとまったシンプルなクラスやメソッドを数多く集めた、単一のライブラリ)と呼んでいる。そのライブラリ・プロジェクト内には、例えば以下のようなフォルダーが存在する。AsyncOAuthBatchCoreDataDiagonosticsExtensionsGeographyGlimpseGreeIOMathOpenSocialRedisReflectionSerializationTextThreadingWebこのうちの1つを見ると、例えばBatchフォルダーには、図2に示すようにバッチ実行するコンソールアプリで使える共通的なコードなどが存在する。第1引数にクラス名、第2引数以降にパラメーター群を指定してコンソールアプリを実行すると、そのクラス名のクラスに実装されたExecuteメソッドを、パラメーター群を使って実行する。コンソールアプリのバッチ実行には、Windows標準のタスクスケジューラーなどを使っている。その他、以下のようなGrani.CoreLibが提供する機能も紹介されたが、本稿ではその内容説明は割愛する。ポイントだけ説明するが、「TableGenerator」に書かれているMicroORMとしてはDapperを使っているとのことだ。Grani.CoreLibプロジェクトの、その他のフォルダー内のコード内容例ここまでが現在のライブラリだが、次バージョンの計画もある。内容もかなり出来上がってきているとのことで、河合氏はその内容についてさらに紹介を続けた。次期版では、実はライブラリを分割して、ヒュージ・モノリシックに「さよなら」することにしたという。具体的には下記の7つのライブラリに分けた。Grani.CoreGrani.Data.MySqlGrani.Data.RedisGrani.DiagnosticsGrani.GlimpseGrani.OwinGrani.Unity「なぜ分割することにしたか」というと、「NuGetで依存関係を解決してくれて、プロジェクトにアセンブリ参照を自動的に追加できる」としても、ヒュージ・モノリシックではその依存関係が大きくなりすぎてNuGetで大量のアセンブリ参照が追加されてしまい、「開発効率が悪い」と感じられるようになったからだ。そこで、特に多くのプロダクトで使っているCoreフォルダーを分離することで、Coreだけは依存関係ゼロにして開発効率を高めたいと考えたと河合氏は説明した。残りの部分も同様に、分離しすぎず、かつ依存関係も最小になるようにバランスを見極めて、さらに6つに分割することにしたというわけだ。グラニが2015年に選択した.NETライブラリこの次期版の各ライブラリ・プロジェクトから使っている、外部の.NETライブラリは次の通り。これらは、2015年にグラニが選出した、必要最小限のベスト.NETライブラリといえる。GameObject、websocket-sharp、Json.NET河合氏はまず、この中からGrani.Diagnosticsプロジェクトのロギング(Logging)について説明した。2015年時点でベストなログ出力技術とは?.NETプログラムでロギングを実装する場合は、Log4netやNLogといったログ出力用ライブラリ(=ロガー)を使うことがこれまでの定番だった。これからの時代では、下記の3要素が必須となっていくであろう。その要件においては、これらのロガーはふさわしくない。ログ出力は通信して外部に保存することが一般的。通信の安全なシャットダウンや負荷分散のためにも、ログ処理を外部プロセスに移すべきGrani.Diagnosticsライブラリが提供するLoggingの次期バージョン機能では、これらの要件を満たすものになっている。具体的には以下の内容を採用している。4.5から標準搭載されたEventSourceクラス(System.Diagnostics.Tracing名前空間)を使用している(図4)。Windows(以下、ETW)にログを出力できる。構造化ログを実現するEventSourceクラスEventSourceクラスは標準ライブラリに含まれているので、外部ライブラリへの依存もない。ETWはWindowsネイティブ機能であるため、アプリからETWへのログ出力も軽快だ。Block(以下、SLAB)を使用している(図5)。先ほどのEventSourceクラスが出力する構造化ログはそのままでは扱いづらいが、SLABを使えば、ログがIObservable<EventEntry>として扱えるのでRxにより処理できる。外部プロセス化SLABには「内部プロセス(In-Process)」と「外部プロセス(Out-of-Process)」の2形態がある。外部プロセスにすることで、ロギング処理がアプリ本体のクラッシュなどの影響を受けなくなるし、逆にロギング処理が重くなっている際にはアプリ本体に影響を与えなくて済むというメリットがある(図6)。Blockこのようにしてログを収集したら、それを解析していく必要がある。RedShift、Hadoop、自分でプログラムを書くなど、ビッグデータとなったログを解析する手法はいくつか考えられるが、「2015年に入った現段階では、グーグルのBigQuery一択。さまざまな点で機能が優れていることももちろんだが、何より圧倒的に簡単である。』も最近発行されたので情報も十分ある」と河合氏は力説した。Insiderの連載記事で解説予定)。2015年時点でベストなプロファイリング技術とは?河合氏はGrani.Glimpseプロジェクトに含めるプロファイリング機能の説明に入る前に、「ASP.NET開発をしているなら、Glimpseを使わないのはあり得ない」と語った。それほどGlimpseは良いらしい。良いのは、タイムラインがかなり見やすいこと。カスタマイズ性も高く、必要な場合はカスタムプラグインで問題を可視化したりできる(図7)。Glimpseでのカスタムプラグインの例(グラニの場合)2015年時点でベストなデータキャッシング技術とは?グラニでは、永続ストレージ層にMySQL、NoSQL層にRedisを使っており、Redisにおいては2015年もStackExchange.Redis+CloudStructuresの組み合わせを使っていく予定とのこと(Grani.Data.Redisプロジェクト)。2015年時点でベストなシリアライズ技術とは?グラニでは、Redisキャッシュに、C#のクラスからシリアライズしたバイナリを入れている。Buffersを採用してきた。「扱いやすさ」があまり良くなかったため(例えば「Dumpが全くできない」など)、次期版ではJSON形式+LZ4圧縮に切り替える予定とのことだ。JSONは非常に取り扱いやすく、LZ4は圧縮率はそこそこだが、圧縮/展開がかなり高速だからだ。Environment)への過渡期であり、OWINはDNXへのつなぎにすぎない。DNXのこれまでの名称変更(KREやXREなどと呼ばれていた)や、安定版のリリースもかなり先になりそうなことを考えると、現時点でDNXに乗っかるわけにもいかない。そこでグラニは、「DNXに対しては待ち」と判断したとのこと。「将来性のないOWINを使うべきか」という点だが、DNXでのMiddlewareの作り方やパイプラインの構築概念はOWINのそれに似ており、しかもOWIN自体は薄いレイヤーでしかないので移行時の影響範囲は小さいと考えられるため、現時点であれば「OWINで開発した方がいい」だろう。グラニはそう判断した(Grani.Owinプロジェクト)。API構築には、内製のLightNodeを活用しているとのこと。API構築だけに特化したコンパクトなMicroフレームワークは標準ライブラリ内には存在しない。そのため、「RubyにおけるRailsに対するGrapeフレームワークの存在」と同じ構図で、このLightNodeを作成したとのこと。LightNodeは前述のGlimpseにも対応している。Extensions「UniRx」も河合氏が自作したオープンソースのフレームワークで、これをUnityによるゲーム開発で活用している(Grani.Unityプロジェクト)。社内で報告されたUniRxのバグの修正は、随時、GitHubのリポジトリにも反映しているとのこと。現在、GitHub上でも注目度が上がってきており、人気も出てきている。4.6から搭載されたuGUIをWPF風に拡張する「uGUI.Ext(仮)」を制作中で、今後、オープンソース化する可能性もあるとのこと。まとめグラニでは、外部ライブラリはそれほど多く使っておらず、共通ライブラリにおいても派手な実装はなく、DLLファイルのサイズも小さい。C#や.NET自体がよくできており、Glimpseなどの外部サービス/OSS(オープンソース・ソフトウェア)も充実しているので、小さなそれらの組み合わせで、グラニが達成しているような大きな結果をもたらせる。外部ライブラリやサービスの組み合わせだけで全てが完成することはないので、「何を作るべきか、何を作らないべきか」の判断基準を、本セッションで紹介した事例から感じとってもらえるとうれしい、と河合氏は締めくくった。Infrastructure」のセッション内容を紹介する。CSharp;」な企業を支える技術方針とベスト.NETライブラリ「最先端のC#技術活用」を掲げる会社の開発現場では、どのような技術やライブラリが、どんな理由で使われているのか。C#開発者必読の、勉強会レポート。Insider主催勉強会のレポート記事。機械学習エンジニアを目指す人~初中級者のための技術情報サイトです。「機械学習&AI」「クラウド&ビッグデータ」「IoTデバイス」のネット記事情報を共有中。開発者のためのSlackチーム、作りました:「機械学習&AI」「クラウド&ビッグデータ」「IoTデバイス」のネット記事情報を共有中。2020最適なビューへの切り替えを推奨します:スマートフォン用表示に。