Archive | 09:59

C#っ! to the future

25 12月

ネタ切れネタ切れって 言いたい事言いやがって ネタなんて最初からねーんだよ! ブロガーが消費してんのは 寿命だけだオラ!

(意訳: ネタ要素薄くてごめんなさい。)

 

最後に、この無謀な25日間の内容から、要点を抜き出しましょう。将来の方向性の示唆にもなると思います。

上昇傾向

初日に、C#の歴史を振り返ってみました。

 

最初は政治的(SUNとの利害関係) 、経済的(DelphiのアーキテクトであるAnders Hejlsbergがマイクロソフトに引き抜かれてる)な理由で始まったC#ですが、3.0、4.0とバージョン アップを重ね、非常に素晴らしい言語に育ちました。まだまだ伸びるでしょう。

こんな話もあります:

1企業の調査なので、まあ、話半分にとらえるべきかもしれませんが、C#はずっと伸び続けています。

昔だったらJavaなどが採用されそうだったような状況で、C#が採用される場面も出てきています。Unity、PlayStation Suiteと、ゲーム向け開発プラットフォームでの採用が続きました。

ちなみに、日本においても、C#関連のホームページのアクセス数や、書籍の売り上げ、伸びてきているようです。

データ処理と非同期

C# 3.0以降の進化の方向性は、データ処理と非同期処理に焦点が当たっています(C# 2.0までは、いわば基礎固めと言った感じで、既存言語と比べてそれほど目新しいことはしていません)。

 

非同期処理は、これからもまだまだ進歩していく分野でしょう。データ処理においても、ネットワーク越しに別のサーバーからデータを取ってくることが多く、非同期I/Oが重要です。

広い範囲の視野持ってほしい

この25日間で、非常に広い範囲の話をしてきました。.NET自身が広い範囲をカバーしているというのもあります。

 

内部に踏み込んだ話もいくつかしました。

 

設計パターンみたいな話もしました。

 

そして、プログラミングはあくまでも手段であって目的ではありません。広く使える手段となる.NETでは、広い目的を果たせます。5日目には、統計の話なんかもしました。

 

どれも重要なことだと思って、25個の話を書きました。

覚えることが多くて大変と思うかもしれないですが、今、.NETに限らず、IT技術者に求められている必要な知識だと思います。

今は、分業化も進んでいて、各個人が直接必要となる範囲は狭いかもしれませんが、協業相手との円滑なコミュニケーションのためにも、概要くらいは広く知る心構えを持ってください。

共通ライブラリ

何回かは、.NETのライブラリの紹介などもしました。

ほんの一角しか紹介できませんでしたが、.NETには様々なライブラリがあります。

18日目に話しましたが、今は、言語を覚えることよりも、ライブラリを覚えることの方が重要、かつ、大変です。

1つのライブラリを、いろんな言語から利用できるというのは非常に大事です。これは、.NETだけでなく、他の環境でも言えることでしょう。ネイティブと.NETでの共通利用、静的言語(C#やVBなど)と動的言語(IronPythonなど)との間の相互運用も重要です。

銀の弾丸はない

「AかBかどっちがいい?」みたいな質問の答えは、だいたい、「両方」もしくは「中間」になります。

 

GUIかCUIかと言われたら、両方。

静的か動的かと言われたら、両方。

ネイティブかマネージかと言われたら、両方。

ウェブかクライアントかと言われたら、両方。

OOPか関数型かと言われたら、両方。

 

それが現実です。

重要なのは、AとBそれぞれ、適切な利用場面がどこか、そして、選べるかどうかです。

ツール連携

コンパイル時と実行時では、コンパイル時にエラーが発覚してくれた方が、エラーを発見しやすいです。Visual Studioに至っては、コンパイル時どころか、タイピングしたそばからコードが解析されて、リアルタイムにエラー内容が見えます。それが静的な言語のよさでもあります。

一方、動的言語と呼ばれるようなタイプのプログラミング言語は、スクリプティングやメタプログラミングしやすいという利点があります。

ここで再び、「AかBか?」と聞かれたら、両方! C#も、動的な特性や、スクリプティング、メタプログラミングの方向に進歩しようとしています。

 

しかしそれでも、基本方針は、可能な限り静的(コンパイル時)処理、そして、Visual Studioとの連携ありきです。先だって、Roslynで、Visual Studioとの連携を深めようとしています。

 

スクリプト(文字ベースの操作)であっても、GUIの補助により生産性を高めることができます。

 

また、C#という言語に新しい機能を入れるにあたっては、ライブラリやVisual Studioまで含めた視点で、慎重に考える必要があります。

 

クロス ターゲットな”コア”

「AもBも」といろいろ求められる昨今、クロス ターゲット、run anywhereに作れる部分と、そうでない部分をきっちりと分離しましょう。

 

「これはクロス ターゲットに利用可能だろう」と思っていたものが、実はそうでなかったりもするので少し注意が必要です。

10年も前だと、ファイル読み書き(.NETでいうとSystem.IO.Fileクラス)が非ポータブルだなんて思いもしなかったものです。今だと、ファイル読み書きはセキュリティ的なお荷物です。

開発プロセス

Visual Studioは、個人のコーディング → 個人のテスト → 開発チームの連携 → 統制・開発・運用含めた連携 と進歩してきています。

 

「ツールに使われてるみたいで嫌」と思うかもしれませんが、ツールの補助は、ある意味教科書みたいなものです。素直に従ってればいいというものでもありませんが、少なくとも、なぜツールがそうなっているかは考えてみた方がいいでしょう。

色々余計な負担になることもあります。しかし、必要なことを色々端折って始めるのは簡単ですが、後からつらくなることが多々あります。いわば、負債と引き換えに歩を進めているようなものです。リリース後の継続運用・継続開発が重要になっている昨今、負債をしょい続けていいものかどうか、良く考える必要があります。

.NET関連技術

25 12月

C#たんは最初から最後までクライマックスだぜ!

 

この記事は、C# Advent Calendarの方の25日目です! 私の1人Advent Calendarの方は、そっちはそっちで書きます!

今日は、C#や.NETと、その周辺のキーワードを網羅的に紹介していこうかと思います。

.NET周辺キーワード

軽く図にしてみました。

 

コア

クロス ターゲットに使える部分です。.NET Frameworkの標準ライブラリの中でも、基礎中の基礎。

  • Text/RegularExpressions: テキスト処理と正規表現
  • Collections: コレクション
  • LINQ: データ列の加工や集計(.NET 3.0以降)
  • Math: 数学関数
  • Numerics: BigInteger(任意精度整数)とComplex(複素数)(.NET 4以降)
  • IO: ファイルなどの入出力
  • Net: ネットワーク アクセス
  • Reflection: 実行時型情報
  • Expressions: 式ツリー(ラムダ式をデータ化)、動的コード生成
  • Task: 同時実行(並列処理、非同期処理)
  • Service Model: サービス化(システムの備品化、疎結合化)
  • MEF (Managed Extensibility Framework): プラグイン拡張

 

クライアント

いわゆるビュー、プレゼンテーション層技術、GUIフレームワークです。XNA以外は、同じスタイルで開発(XAML+C#、Visual StudioやBlendによるRAD開発)できます。ただし、GUIのクロス プラットフォーム開発は割かし幻想で、ターゲットごとに微妙に差があります。

  • WPF: デスクトップ向け
  • Silverlight(ブラウザー): ブラウザー プラグインとして提供。FireFoxや、Safari上でも動きます
    • デスクトップ向けの.NETと比べると、使えるライブラリが少ないです
    • コアの部分は使えます
  • Silverlight(Windows Phone 7): Windows Phone 7向け。
  • Metro/WinRT: Windows 8なタブレット端末向け(現在、早期プレビュー版)
  • XNA: アクション性の高いゲーム向けのフレームワーク
    • イベント駆動型ではなく、メッセージ ループを直接書く
    • Windows PC、Xbox 360、Windows Phone 7上で動きます

 

加えて、ASP.NETでは、HTMLをサーバー上で生成して、クライアント側はブラウザーを使って表示というパターンもあります。HTML5にも対応しています。最近はjQueryに投資しているようです。

通信

WCFは、.NETにおけるサービス化の要です。ネットワークをまたいで、インターフェイスのメソッドを呼び出すようなプロキシの役割を担います。

元々は、いろんなタイプの通信プロトコルを統一的に扱うためのものでしたが、最近はHTTPを使ったウェブ サービスに最も注力しています。

昔は、SOAPというメッセージ交換プロトコルを主軸にしていましたが、今は、REST形式のプロトコルであるODataを主軸としています。XMLだけでなく、JSONにも対応しています。

アプリ サーバー

処理の大部分をサーバー上で行うようなアプリを開発するためのフレームワークとして、ASP.NETがあります。

サーバー上でHTMLを生成してブラウザーで表示する場合もあれば、ウェブ サービス化しておいてクライアント アプリから呼び出す場合もあります。

  • ASP.NET Web Forms: 通信層を隠ぺいして、デスクトップ アプリと同じ感覚でウェブ アプリを作れます
    • 内部を隠ぺいしすぎて不評というのもあったりします
  • ASP.NET MVC: .NET以外の言語のウェブ フレームワークに多い、MVC構造を採用したフレームワーク
    • HTTPを下手に隠ぺいするのはやめて、規約ベースでURLと処理の対応付けします

 

特に、ASP.NET MVCでは、HTMLの生成用のテンプレート部分に、aspx形式と、Razor形式(拡張子cshtmlかvbhtml)を選べます。Razorでは、<%%> のような不恰好なコード ブロックではなく、@ を使って簡潔にコードを書けます。

データ アクセス

C#などの.NET言語からデータベースにアクセスするためのフレームワークとして、ADO.NETというものがあります。

特に、.NET 4から標準に入った、ADO.NET Entity Frameworkというものを使うと、ER図的なデータ設計モデルからデータベースや、エンティティ クラス(.NET側からデータベースにアクセスするために使うクラス)を作ったりすることもできます。

  • Database-First: データベースからエンティティ クラスを生成します
  • Visual-Model-First: Visual Studio上で、ER図(Entity Relationship Diagram)的なGUIを使ってエンティティを設計し、データベースやエンティティ クラスを生成します
  • Code-First: 素のクラス(何も継承しないし、内部に何も特別な処理を書かない、純粋にデータを表すクラス)から、データベースやエンティティ クラスを生成します

サーバー インフラ

  • WF (Windows Workflow Foundation): フローチャート的な処理手順を、GUI上で編集して実行できます
    • SharePointサーバーやTFSのカスタマイズに使えます
    • 次期バージョンでは、バッチ処理をWFで書いて、PowerShellから起動というようなこともできるようになります
  • WIF (Windows Identity Foundation): 認証基盤

サーバー製品

サーバー アプリを作るなら、それを動かすためのサーバー製品が必要になります。オン プレミス(On Premise: 自前でハードウェアを持って自前で管理する)版と、クラウド(PaaS、管理もお任せ)版の両方が提供されています。

  • Windows Server/Window Azure: OS
  • SQL Server/SQL Azure: データベース サーバー
  • AppFabric: サーバー間の連携や、アクセス制御を担うインフラ

サーバー管理は、RDP(リモート デスクトップ接続)かPowerShellを使います。繰り返しになりますが、GUIにもCUIにもそれぞれいいところがあって、両方需要があります。Azure(のVM Role)ではクラウド相手ですらRDP管理できます。

また、Office製品と連携する業務基盤であるSharePointというサーバー製品もあります。OfficeやSharePointのカスタマイズも、Visual Studioと.NETを使ってできます。

開発インフラ

.NETと言えば、強力な統合開発環境。

  • Visual Studio: 説明不要かと思います。.NETの生産性の高さの原動力
  • TFS (Team Foundation Server): バージョン管理、作業項目管理、継続的インテグレーションなどを行うためのサーバー製品
  • Team Foundation Service: TFSのSaaS版。Azure上で稼働(現在、プレビュー版

Visual Studioは、2010から、拡張が簡単になりました。拡張マネージャーというものを使って、サード パーティ製のVisual Studio拡張を簡単にインストール可能です。拡張を作る側は、Visual Studio SDKというものを使います。

Roslynで一番期待されているのも、Visual Studio拡張によるメタプログラミングです。

現状だと、ビルド時コード生成によるメタプログラミングでは、T4テンプレートを使います。

コミュニティ

ライブラリ

現在では、約2年周期の大きなアップデート(Vistaから7にとか、Visual Studio 2008から2010にとか)の合間合間にも、オープン ソースで広くフィードバックを厚めながら新機能を提供しています。

コードの公開にはCodePlexというオープン ソース コミュニティ向けサイトを利用しています。

いくつか例を挙げましょう。

マイクロソフト公式のもの以外にも、コミュニティ ベースのToolkitもあります。

その他、CodePlexには有用なオープン ソース ライブラリがたくさんあるので、サイト内をいろいろ検索してみてください。

こうして作られたライブラリ(マイクロソフト公式の追加ライブラリや、コミュニティ ベースのもの)は、最近だと、NuGetという、オンライン ギャラリー + Visual Studio拡張を通して、簡単にプロジェクトから参照できます。

情報提供

マイクロソフトの開発者向け製品に関する情報は、MSDN(Microsoft Developer Network)というサイトに集約されています。

  • ライブラリ: APIリファレンスなど、学習コンテンツ
    • 初心者が学ぶには詳しすぎてしんどいなんて話もありますが、網羅性と詳細さは非常に良いです
    • 日本からは、「英語の情報があるってことは、まだ日本語未対応なんでしょ。そんな情報要らない」というフィードバックと「英語でもいいから最新の情報もらえないと困る」というフィードバックが半々で、途方に暮れているそうです
    • 「機械翻訳でもいいから早く」と「機械翻訳とか役に立たねー」も半々
  • ブログ: 社員によるブログ
    • 最新の情報はだいたいここ(の本社社員の記事、もちろん英語)から出てきます
  • マガジン: 毎月刊行される情報サイト
    • 元々は本当に紙の冊子も販売されてた
  • フォーラム: フォーラム(掲示板)形式で、質問や意見/要望を受け付けています
  • Code Recipe: コード付きのサンプル/解説置き場
    • 元々は公式コンテンツしかなかったですが、今ではユーザー投稿(誰でも可能)を受け付けています

多様化

C#やVBだけが.NETじゃなく、マイクロソフトだけが.NET提供しているわけではなく、PCだけが.NETの対象ではありません。

  • DLR (Dynamic Language Runtime): .NET上に動的言語を実装するための基盤
    • マイクロソフトの寄与度が高いものでいうと、IronPythonが提供されています
    • その他、IronRubyなど、いくつかの動的言語がDLR化されています
    • DLR上に実装された動的言語からは.NETのライブラリを利用でしますし、動的言語側で作ったクラスなども、C# 4.0のdynamicキーワードなどを使って相互運用可能です
  • mono: オープン ソースな.NET実装です
    • Mac向けやLinux向け、iOS向けやAndroid向けなども提供されています
    • UnityPlayStation Suiteなどのゲーム開発フレームワークでも採用されています
  • Robotics Studio: C#などを使ってロボットを制御
  • .NET Micro Framework:組み込み機器向け.NET
    • OSすら載せたくないような低フットプリント機器向けに、.NETの最低限の機能だけを提供
    • オープン ソース提供されています
    • Porting Kitを使って特定のハードウェア向けにカスタマイズすることもできます
    • 元から対応しているハードウェア基盤の購入もできます
    • モジュールの組み合わせでプロトタイプ作成ができる、.NET Gadgeteerというプロジェクトも