The evolution of c#
- 1. The Evolution of C# C#の秘めるポテンシャルとソーシャルゲーム gloops Holdings Pte. Ltd. Engineer Microsoft MVP for Visual C# Yoshifumi Kawai
- 2. Self Introduction 株式会社gloops (グループス) ソーシャルアプリケーションプロバイダ 大戦乱!!三国志バトル, 大召喚!!マジゲート, etc… Windows Server(IIS) + SQL Server + ASP.NET + C# で構築 個人活動 Web : http://neue.cc/ Twitter : @neuecc Microsoft MVP for Visual C# (2011/04 – 2013/04)
- 3. 進化する言語 C#
- 4. The Evolution of C# Async 2010 C# 4.0 LINQ 2012 C# 5.0 Dynamic 2005 C# 2.0 Java/Delphi 2008 C# 3.0 Generics 2002 C# 1.0
- 5. 最適な言語を選択する 領域が変われば言語は変わる Cは基本！C最速！Cで全て書ける！ ……わけはない。 Cの生産性でウェブアプリケーションを作るのは大変だし利点もない 書けないわけではないけど、実質書けない ウェブアプリケーションで大事なのは？ パフォーマンスは勿論大事、だけど全てにおける優先事項ではない 比較対象がC++とか、そういうお話 CPUよりもDBアクセスとかがネックになりがちなので 速いリリース速度に対応するための軽量さが何よりも大事
- 6. 軽量とは Lightweight Laguage... 軽量プログラミング言語（けいりょうプログラミングげんご、和製英 語:Lightweight Language,LL）とは、日本においてスクリプト言語を指す ジャングリッシュで、取り回しに優れ、コードの作成や修正が容易と見な されるプログラミング言語のことを指す。 出展:ウィキペディア「軽量プログラミング言語」 つまるところ コードの作成や修正が容易であること それは、リリース後も高速に更新をし続ける、ソーシャルゲームで何より も大事なこと
- 7. C#は軽量か？ 軽量です！ Rubyなどと比較しても？ Visual Studioという翼があれば！ 今時の言語は単独で評価できない IDE・フレームワーク・言語、これらは三位一体 Visual Studioはロケットブースター C#単体の走る速度はLLには敵わないかもしれない しかしロケットブースターがついた時、その速さには誰も敵わない
- 8. 自動生成 vs 言語機能 どちらも大事 自動生成があれば全て事足りる、などということはない いくらIDEがロケットブースターでも、重さは、重さ 例えば型推論 C# 3.0から入った機能 型は非常に大事だけど、手で書くのは面倒なので推論してくれる 言語機能にそれがない場合、IDEを使って右側の型から自動生成で宣言す る型を作ることもできる(e.g. Eclipse) でも、頻繁に行う部分でそれって、凄く手間だし、コード上の視覚的にも 良くない
- 9. 静的型付け vs 動的型付け コンパイルでの検出ってやっぱ大事 ユニットテストがあるからなくても大丈夫、ではない コンパイルエラーならIDEが「リアルタイム」に検出する リアルタイムなのは、速さであり軽さ 強力な入力支援 甘美なるIntelliSense！もうこれなしで生きていけない！ 強力なリファクタリング支援 ソーシャルゲームの頻繁な更新のもとでは、設計は不変、ではない むしろころころ変わる 強固なリファクタリング支援は型付けあってのもの
- 10. 足を止めたらお終い 要求が変わっていくのは当たり前 10年前に現代のようなプログラミングは想像できたか？ 言語も進化し続けなければならない 要求が変われば、追随していかなければならない ただたんに書ければいい、というだけではダメ より軽量に！より高速に！ →C#ははどのように進化していったか
- 11. 進化する言語 C#
- 12. C# 3.0 - LINQ LINQの存在はC#の大きな強み あらゆるデータを統一的に扱う仕組み 特にコレクションに対する操作(LINQ to Objects)が強力 LINQ != SQLです:) コレクション？ データベースから取得したデータもそう "select * from hogehoge"の結果は行のコレクション ウェブアプリケーションの中心はやはり、それ！ DB上で整形済みだから、特に必要ない……？
- 13. JOINを避ける DBへの負荷削減 大量のデータを扱う関係上、JOINは極力避けるようにしている 代わりにメモリにキャッシュ可能なデータは積極的にメモリへ NoSQL 高速なデータ取得、かわりにDB上での柔軟な結合はない gloopsではMemcachedとRedisを利用中 LINQ to Objectsによるインメモリ結合 データはC#上で結合するが、普通にやると生産性落ちるしバグの元 そこで、LINQ to Objectsを使う SQLよりも強力なパワーを持つので、むしろ書きやすい
- 14. 例えばこんなインメモリ結合 パーティー 装備アイテム 皮の鎧、とか…… 勇者 色が一致するのがそのキャラ クターの装備してるアイテム 剣士 魔法使い パーティーテーブルと装備アイテ 僧侶 ムテーブルを結合したい！
- 15. こういう風に結合されればいい 勇者 剣士 魔法使い それGroupJoinで一撃 僧侶 party.GroupJoin(equipItems, x => x.CharacterId, x => x.CharacterId, (character, items) => new { character, items });
- 16. GroupJoin != OuterJoin 勇者 剣士 魔法使い オブジェクトの集合をバラさ ずそのままで結合 僧侶 party.GroupJoin(equipItems, x => x.CharacterId, x => x.CharacterId, (character, items) => new { character, items });
- 17. LINQ > SQL SQLの外部結合と同じようにも出来る SelectManyでバラすだけ // SelectManyでバラす & DefaultIfEmptyで存在しない場合のnull化 party.GroupJoin(equipItems, x => x.CharacterId, x => x.CharacterId, (character, items) => new { character, items }) .SelectMany(x => x.items.DefaultIfEmpty(), (chara, .... でも、わざわざバラす必要はない むしろバラした形でしか問い合わせできないのはSQLが問題 自由なクエリはSQL的なしがらみに囚われなくていい
- 18. C# 4.0 - Dynamic 世界の全てが型付けできはしない 外の世界とのやり取りの境界線が必ずある そこで基本は静的に、部分的に動的にするのがdynamic 例えば？ SignalRというWebSocketなどを透過的に扱うライブラリがある WebSocketという最新フィーチャーにも.NETは追随してます！ （擬似的に）ブラウザ上のメソッドを呼び出すことが出来 ここでの境界はブラウザ上で動くJavaScriptであり、動的な存在
- 19. C# 5.0 - Async 高まる非同期処理の重要性 Node.js（流行ってますね！）に代表されるノンブロッキングI/O I/Oを待っている間のスレッド消費がなくなる が、しかしコールバック地獄 ネストする関数 例外処理は？リトライ処理は？ 気の利いたライブラリでカバーしようにも限界 C# 5.0は言語構文として用意した 非同期処理が重要だ、という時代の要請への素早い対応
- 20. C# 6.0? - Compiler as a Service C#はIDEとの相性が考えられている C# + Visual Studioの良さは、言語設計からして考慮されているから 例えばC#の型推論は非力な側面もあるけれど、IDEでの入力補完などを考 えると、ギリギリのラインになっている Visual Studioを拡張する ただのエディタマクロ以上の拡張を実装するには、構文解析が必要 そこでC#自体のParserを提供、更にVisual Studio拡張との融合も これにより個々のアプリケーション開発に特化した拡張機能を、簡単に作 ることができ、生産性が爆発的に高まる
- 21. Conclusion
- 22. まとめ 進化する言語 C# 大事なことなので三度言いました！ 業界の最前線、高い要求に対して、応え続けてくれる C# + Visual Studio + .NET Frameworkと、三位一体で進化し続けている 言語が思考を規定する 言語が進化するのは、決して複雑怪奇にしたいからではない むしろ楽させるために進化している 常により良いを目指して、しがらみに囚われず変わり続けよう