kazuk は null に触れてしまった

C# / .NET 系技術ネタ縛りでお送りしております

カテゴリーアーカイブ: 近況

Doc<Code> というツールをリリースします


技術特化 blog なんで、滅多にやらない事なのですが、宣伝させてください。

宣伝かよ

はい、宣伝です。軽く失注続きで本気にこのままだと路頭に迷う事態なので一人ならどうという事は無いのですが嫁子供居る身なので必死なわけで、個人で作って使ってるツールの類に値段を付けて並べてみようかとの第1弾です。

タダで手に入る物で全部回して主義の方はこの先読んでも意味ないのでお帰り下さい。

Doc<Code> “doc of code” とは

.NET Framework アセンブリとその XML ドキュメントファイルを投げ込むとドキュメントを閲覧できる ASP.NET アプリケーションです。

同様なXMLドキュメントコメントの整形を行うアプリケーションとしては Sandcastle があります。Sandcastle プロジェクト自体は現状 Sandcastle Help File Builder でメンテナンスされているようですが、若干プロジェクトに不安定要素があり、ちょっとややこしい事になっているようです。

Sandcastle との違いは、あちらはビルドプロセスでのバッチ処理でHTML、およびヘルプファイルを作成する枠組みですが、Doc<Code> では、ASP.NET アプリケーションとして要求に応じてアセンブリを随時解析してXMLドキュメントと結合表示する仕組みですので、簡単に言えばビルド時に XMLドキュメントファイルの生成以上の追加処理を必要としません。結果的にビルド時間に対するインパクトを殆ど0にする事ができます。

要するにスロービルドの原因である、誰も見ないようなドキュメント生成を、オンライン解析変換処理にする事で開発スループットをより伸ばせるツールという事です。

インストールに必要な物は?インストールの手順は?

IIS 7.5 以降(Express でも可) 、 .NET Framework 4.5が必要です。 VS2012で普通に開発してる環境なら入っている物ですね。

DocOfCode の紹介とインストールデモ等

普通に NuGet からパッケージ入れるだけで入ります。

どういう使い方が想定されていますか?

普通に開発現場でドキュメントを見る用途、および、オープンソースな物を作ってる人がAPIリファレンスをインターネット上に公開するとかに使って良い様に作っています。

インターネット公開サイトに使う場合に、アセンブリを勝手にアップロードされないようにしたい等は、AssemblyController とその関連Viewそのものを外してしまって下さい。(この場合、アップロードはファイルを直接 App_Data に配置する事でもできますし、アセンブリの一覧管理はプロバイダになっていますので、プロバイダを実装する事で管理方法そのものを変える事ができます)

表示のデザイン等に関わる View および、それに当たる css 等はすべてパッケージ内にありますので、NuGet パッケージを取りこんだうえで修正してもらえれば幾らでもカスタマイズできると思います。

使い方

単純に動かすと能書きの書かれた Index ページの上部にアセンブリと設定のリンクがありますので、アセンブリを選んでもらうと、アセンブリをアップロードするためのページへ遷移します。

アップロード時に指定するタイトルはそのままアセンブリの情報ページのパスとなります、アセンブリ内の名前空間や型、メンバ情報はすべてその配下でアクセスされます。

アップロード済みのファイルと同じタイトルでアップロードを行うと、アセンブリファイルおよび、ドキュメントコメントのXMLファイルの入れ替えになります。

後は飛び回って好きにドキュメントをみて下さいという事です。 Code Contracts で XML ドキュメントコメントを出すようにしておけばそれなりに契約内容も表示されます。

名前空間に関するドキュメントコメント

ドキュメンテーションコメントのXML仕様的には N: で名前空間についてのドキュメントを置けることになっているため、このドキュメントタグが付いた要素があれば表示されるようになっています。また、 NDoc / sandcastle と同様に NamspaceDoc という型に対するドキュメントがあれば、名前空間のドキュメントとして表示されるようにしています。

ドキュメンテーションコメント内のタグ

推奨されるドキュメンテーションコメントタグの殆どはレンダリングできるようになっています。

また、各種HTMLタグはそのままHTMLタグとして表示するようになっていますので、HTMLの aタグをドキュメントコメントに記述しておけばリンクになりますし、imgタグを記述しておけばイメージも表示されます。(当然に img はどっか Web サーバにホストしないと見れませんと思いますけど)

高度な使い方とスケーラビリティ等

Doc<Code> は解析対象アセンブリとドキュメントをすべてメモリ上に読み込んで処理を行う為、スケーラビリティのネックは基本的にはメモリ容量という事になります。また、閲覧されるドキュメントをできるだけ高速にレンダリングしたいため、メモリに読み込んだモジュールやドキュメントをできる限りメモリ保持しようとしますのでアセンブリを登録すれば登録したほどメモリを使います。開発中のドキュメント参照支援等で .NET Framework のすべてのアセンブリとドキュメントを閲覧できるサーバを立てるとかはメモリがきついとかが根本的なネックになるでしょう。

結果的に別々のサーバに、このアセンブリはこっちのサーバ、このアセンブリはこっちのサーバといった形で配置する事になります。これらのサーバ間でドキュメントのリンクを通す事がサーバリンク機能で実現できます。

App_Data/LinkedServers.txt ファイルにリンクされるサーバ名:ポート番号を記述しておくと、該当サーバに存在しないアセンブリへのドキュメントのリンクが自動で解決されます。たとえば A サーバに mscorlib を配置して、Bサーバに自前のライブラリのドキュメントを配置し、BサーバのLinkedServers.txt にAサーバを記述しておくと、Bサーバでドキュメントをレンダリングする場合に String 等 mscorlib 由来の型は A サーバへのリンクとしてレンダリングされます。

Doc<Code>サーバ間は Web API で保持しているアセンブリの問い合わせを行っていますので、Aサーバへのアセンブリの追加などを行った時にBサーバ側は特に何もしないでも自動で反映されます。

注:サーバリンクを使ってサーバ間のリンクをする場合、それぞれのサーバにライセンスが必要です。

解析系の独自拡張の実装

Microsoft CCI に関する知識は必須ですが、アセンブリ、名前空間、型、メンバのそれぞれについて、追加で解析処理を行うロジックを入れるフックポイントが用意されています。

これにより、メンバメソッドのサイクロマチック複雑度を計算するロジックを追加すると、メンバの情報取得時にそれが呼び出され、ロジックが出力した結果は View まで引き渡しされます。

今後の開発ロードマップ

現状では各種メタデータおよび、ドキュメントコメントの表示側に注力している形になっていますが、将来的にはドキュメントコメントの入力、編集ができるようにする事を計画しています。

というのも、綺麗に見えるようになれば欲が出るので、使用例とかの Example をドキュメントコメントに色々書きたくなったりするのですが、それをやるにはコメントの中にコードを書かなければならないし、コメントの中に書かれたコードの中で XML 的な制約で < や > をそのまま書けないし色々と痛々しい思いをしなければなりません。

ドキュメントを充実させたいという思いと、ソースをそんなに汚したくないという思いや色々な葛藤の結果としてドキュメントコメントを実際として機能的に捨てているという現場も多いでしょう。

その辺りに対して、ドキュメントとして入れたい物をソース外からドキュメントコメントXMLに出力できる様にするビルド時ツールとか色々絡めて、十分なドキュメントを書いてもコードファイルが汚れない、それを素早く見れて修正を入れたりとかを Web 上のツールとコード上の双方でできる様にするのを次のマイルストーンとして考えています。

お値段は?

インストールされるサーバにつき1か月300円をめどに設定しています。

販売サイトの方を準備中だったりしますが、 1ヵ月300円、3ヵ月900円、6ヵ月1600円、1年で3000円の4通りのラインナップの予定です。

販売方法としては PayPal でのクレジットカード決済で購入するとメールでライセンスファイルが送られてくるという形式、ライセンスファイルはサーバへ配置が必要です。

また、直接 kazuk.dll@kazuk.jp の方にメール頂ければ見積書、納品書等、会社関係で必要な物は出せる形ができます。

んでいつリリースなのよ

とりあえず、NuGet パッケージについては今月中には出します。販売サイトは月明け早々にも立ち上がり予定、実際のライセンス販売開始は来月10日からを予定しています。(このあたり、多少のずれはあるかもしれません)

ボランティア活動終了と退職とか


近況ブログでありまする。

個人的には今月末でボランティア活動を終了して仕事するかなと言う所。

また、ボランティアに没頭したいのもあり、株式会社クロスワープを退職致しました。

 

という訳で、現状としては個人事業主な形で仕事再開しようと思っております。

まぁ、個人事業主としてやってく上で、仕事を探すのは当然に営業活動をするわけで、宣伝ブログでもあったりします。

という訳で以下箇条書き的にこんな仕事あればお問い合わせ下さい的に

  • Visual Studio 2010 、 C#での開発(Web/それ以外どちらも可)
  • 及び上記環境での開発環境の自動化を含む効率化に関する事柄
    • たとえば繰り返しパターンになる部分のT4テンプレート化
    • ビルド等の処理で必要な msbuild タスクの開発等
  • 及び上記環境での開発に関する講習/講義の実施
    • Pex & Code-Contracts 使ってコードカバレッジを取って等々の高信頼ソフトウェアを開発する為のプロジェクト設定手順等をチームに展開したいなどの講習
  • 及び上記環境での開発でのアプリケーションアーキテクチャの構築支援
    • プロトタイピング→フレームワーク収穫→展開用プロジェクトテンプレート化
    • モデル化およびモデルに基づくデザイン環境の整備(DSL Tools利用)

汎用性の高い物については私個人の製品資産にして頂き利用権を提供する形にしていただければ割安に提供できます。(実装済みの物が即座に出てくる場合もあります)

個別要件の強い物についてはコンサル的に月間数時間の作業時間を予約頂いて提供という形でやれればと思います。

という訳で、問合せはメールにて kazuk.dll@gmail.com です。

Windows Live Spaces から移行してきました。


移行ツール使ったんだけど、コードの断片とかガシガシ落ちてますな。残念な結果でございます。

近況ですが DSL Tools や GAT 2010 / GAX 2010等のVS Extentions系を中心に散策中。

物作りを単純に出来合いツール(要するにVisual Studio)でやってると、なんていうか生産効率とかはどこもかしこも一緒なんすよね。(使いこなしている人を比較すれば:使いこなしていなければ残念でした)

結局の所効率を出そうとすると社内のプロセス全体での改善をかけるのと、局所的なプロセスオプチマイズでチューニングしていくしかないわけで。

TFS とかスクラム、アジャイル等での開発プロセス全体でのオプチマイズは全体に効くんでそっちも重要は重要なんだけど。

いわゆるVisual Studio 2010 っていう「包丁を研ぐ」の段階ですね。

 

包丁を使って作る料理の方は Azure や Sync Framework 等を素材にレシピの検討中です。

ネタばらし的な内容となりますがAzureに代表されるクラウドへの対応にあたって弊社システムとしてはクラウド、オンプレミスのハイブリッド形となる見通しでございます。

Webフロントエンド部の構成としてはオンプレミス側にカリカリにチューニングしたシステムを配置し、トラフィックスパイク等はオンプレミスに連れてきて処理を基本戦略としています。なぜかというとクラウドに発生するコストの懸念であり、弊社の事情としては事例記事にもちらっと出てる通りで顧客特性としてスパイクしたら800倍程度のトラフィックが襲い掛かるわけです。このトラフィックはクラウドにおける主要な課金要素でして、一気に数100倍のコストが発生するのはスパイクを処理した事で売上がそれなりにあっても容認しがたい事でございます。なので固定費で運用されている弊社データセンター側システムで処理する事でコストの平準化効果が非常に高く現れます。

また、事例記事で上がっている通り、弊社のCMSエンジンはかなりのキャッシュモンスターとして実装されており、このキャッシュ等のメカニズムはアクセスが一点に集中すればするほど効率が上がる特性を持ちますのでアクセス頻度の低いページへのリクエストがパラパラくる事でキャッシュに使用しているメモリを食われるよりはスパイク部等のキャッシュがカリカリに効く部分を集めて処理する事でより効率的に動作する事が期待できます。

また、クラウドによるスケールアウト戦略は基本的に否定しています。突発的に800倍の負荷がやってくる所にスケールアウト戦略はそもそもマッチしません、せいぜい数倍のスケールなら事前準備でスケールマージンとしてのマシンを立ち上げておく事はできないでもないですが、数100倍のスケールマージンに相当するシステムを立ち上げておいて予期された(スパイクという名の)商戦が来なかった場合に発生したコストが空振りになるリスクがあります。さらにはシステムをクラウド上で動的にスケールさせる事ができると言っても数十分のラグタイムは絶対に発生し、場合によっては商戦が数分で終了してしまう事もあります。この機会損失リスクも許容しがたい訳です。

結果的に可能なオプションは非常に限られており弊社データセンターに十分にチューニングされたシステムを配備し、平常時の数千倍のスパイクをそこで処理できる様にするしかないという事になります。当然のことながら平常時の稼働効率は要求性能の数千分の1でしかなくても綿密にチューニングされている必要があり、スパイクの規模が大きいほど効率的に動作するキャッシュ等のメカニズムは非常に重要度が高い事になります。

クラウド対応を行う上での基本的な設計方針としてはこんな感じではありますが、これを支えるメカニズムに多くの課題があるのも事実です、クラウドからオンプレミスに処理をスイッチするのはリダイレクトすればいいが誰が引き金を引くのか、数分で数100倍のトラフィックが襲い掛かる所ではログをバッチで分析してなんて手段はそもそも通用しません(バッチがオンプレミス系への切り替えを指示したタイミングですでにコストは発生してしまった後になるでしょう)。Webヘッドノードのスパイク監視で許されるラグタイムは高々数秒しかないのでリアルタイム処理は必須になりますし引き金を引きそこなったら数100倍のコストで沈む計算でかなりセンシティブな実装が要求されるわけです。またクラウドにおけるKVSでのデータアクセスの仕方と、オンプレミスでのデータアクセスの仕方を整合させる必要がありそもそもの PaaSで用意されるストレージとオンプレミスで使っている各種ストレージに対して処理方法やミドルが異なる中で処理内容を整合させるという困難なタスクをこなす必要があります。

いずれも簡単にはいかない困難な要素を抱えておりますが一つづつクリアしていく事でいずれ弊社SaaSがクラウド上で動作するようになりましたという報告ができる様にしたいと思っております。

技術Blogをこっちに移します


最近殆ど書いてなかったとかありますが、こっちに技術blogを移すことにしました。さすがに .Text はもう限界って事で。

オフラインでの編集とサンプルソース類等やスクリーンショット等を簡単における方が良いって事で3年塩漬けにしていた Live spaces を動かしてみます。

以前 ASP.NET Comp* に置いていたコードジェネレータジェネレータ csx は以下に置いてみました。

http://cid-eb33514f53baf4b3.skydrive.live.com/embedicon.aspx/.Public/csx.zip 

世の中的には M とか T4 でしょうけど、なにぶん自分はこれに慣れてしまったので ^^;

たまーにこいつのテンプレートとかをゴンと置くかもって感じ、おもにソース、HTMLからXML、cmdファイルや csproj 等多様な物をこいつでジェネレートしてたりします。

まぁ、仕事の合間にBlogなので、めったに書きませんがよろしくーって事で。

某C#プログラマー


画像つき投稿がどんな感じかのテスト。

これですぐ行けば結構簡単簡単。

画像はとあるC#プログラマの後ろ姿、背中のセミコロンが目に入らぬか。

Windows Live Writer(Beta) からの書き込みテスト


Vistaになった事だし、Windows Live Spaces で遊んでみるテスト。

本家は少なくとも暫くは存続方向なのですが、画像のアップロード含めたBlog編集の関係操作がめんどっちいので色々考え中。

this blog Movedとか出るかどうかは…