Simon.P.G. Good Log: 4月 2012

2012/04/15

総務省「事業計画作成とベンチャー経営の手引き」がすごい件

title: 総務省「事業計画作成とベンチャー経営の手引き」がすごい件
url: http://blog.livedoor.jp/lalha/archives/50215344.html
http://www.b-t-partners.com/pdf/080307.pdf

snippet:

-----引用-----
総務省のプロジェクトでこんなんつくりましたということで、「事業計画作成とベンチャー経営の手引き」という資料が送られてきたのだが、これが無料で配布されている資料とは思えないほどの非常に充実した内容で、いつか会社を始めるかもしれないと思っている人にはきっと役に立つだろうと思ったのでブログで紹介したいと思う。
総務省報道発表資料
「事業計画作成とベンチャー経営の手引き」及び「事業計画作成支援コースの運営とベンチャー支援上のポイント」の公表
-----引用-----

2012/04/14

マイクロソフト内の開発プロセス

title: マイクロソフト内の開発プロセス
url: http://csharptan.wordpress.com/2011/12/23/%E5%80%8B%E4%BA%BA%E3%81%8B%E3%82%89%E3%83%81%E3%83%BC%E3%83%A0%E3%81%B8/

snippet:

-----引用-----
マイクロソフトでは、例えばVisual Studioという製品だけを取ってみても3500人以上の人間が開発にかかわっています。これだけの人数を一括して管理できるわけはなくて、以下のような分散管理になっています。

10人程度のチームに分かれています
進行管理1名、開発5名以下、テスト5名以下
開発手法はそれぞれのチームが自由にやっていい。ただし、報告を義務付け
コミット前にクオリティチェックがある

そして、分散した開発状況全体を把握するために、TFSの可視化機能が使われています。また、開発とテストの比率がほぼ1対1なことも注目に値するでしょう。
-----引用-----

失敗の教科書

title: 失敗の教科書
url: http://csharptan.wordpress.com/2011/12/23/%E5%80%8B%E4%BA%BA%E3%81%8B%E3%82%89%E3%83%81%E3%83%BC%E3%83%A0%E3%81%B8/

snippet:

-----引用-----

「これをやれば成功する」なんてものがないのは明白です。そんなのがあればみんなやります。しかし、「ここを外したら失敗する」みたいなものは、結構あります。教科書は、「成功するためのもの」ではなくても、「失敗しないためのもの」ではありえます。それをおろそかにして、失敗していませんか？

-----引用-----

2012/04/13

Code Contracts (現状のC#で非null保証をしたければ)

title: Code Contracts (現状のC#で非null保証をしたければ)
url: http://ufcpp.wordpress.com/2012/04/10/null%E9%9D%9E%E8%A8%B1%E5%AE%B9/

snippet:

-----引用-----
現状のC#で非null保証をしたければ、Code Contractsというのを使って、契約プログラミングします。Contractクラス（System.Diagnostics.Contracts名前空間）を使って、契約表明できます。

public static T Parse(string s)
{
Contract.Requires(s != null);
Contract.Ensures(Contract.Result<T>() != null);
return new T(); // 仮実装
}

これで、Parseメソッドがnullを返さないことを保証します。

このRequiresやEnsuresメソッドは、実際には何もしない
Conditional属性が付いていて、コンパイル後に消える

静的検証

Visual Studio 2010に関しては、Code Contractsの別途インストールが必要
有償エディションにしか入らなかったはず
その上で、コード解析オプションをOnにしないと働かない
静的コード解析、そこそこ時間がかかる

動的検証

静的解析しきれない部分を検証するために、動的検証コードを入れるオプションもある
契約の表明はあくまで自己申告なので、やろうと思えば虚偽申告できる
Code Contractsに対応していないライブラリを使うと、必然的に何らかの動的検証が必要
この場合、（C#のコンパイル結果の）ILコードを書き換えて、検証コードを埋め込んでる
契約違反は実行時例外発生
もちろん、検証コード分、実行時の負担になる
ちなみに、.NETの標準ライブラリには、.NET 4から、Code Contractsによる契約が表明されています。また、書いた契約をドキュメントに反映する仕組みも持っています。

-----引用-----

単体テストで使える便利ツール: Pex, Moles, Moq

title: 単体テストで使える便利ツール: Pex, Moles, Moq
url: http://csharptan.wordpress.com/2011/12/22/%e5%8d%98%e4%bd%93%e3%83%86%e3%82%b9%e3%83%88/

snippet:

-----引用-----
Pex
メソッドの中身に応じてテストコードを生成してくれるVisual Studioアドインです。テスト漏れが起きないように、きわどいケースなんかを生成してくれます。

Moles
Pexの付属品なんですが、標準ライブラリ内のメソッドを自作のものに置き換えてしまう機能を提供するツールです。
例えば、DateTime.Nowのような、常に違う値を返すメソッドを、所望の値を返すように書き換えてしまうというような使い方ができます。

Moq
動的処理の回で書きましたが、テストのお供にモック（mock: 模造品）生成フレームワークがあります。代表例はMoqなどです。
-----引用-----

Script# = C#からJavaScriptコードを自動生成

title: Script# = C#からJavaScriptコードを自動生成
url: http://csharptan.wordpress.com/2011/12/21/%e3%81%9d%e3%82%8c%e3%81%a7%e3%82%82%e3%82%af%e3%83%ad%e3%82%b9-%e3%82%bf%e3%83%bc%e3%82%b2%e3%83%83%e3%83%88/

snippet:

-----引用-----
Googleは結構、JavaからJavaScriptコードを生成してるんでしたっけ？まあ、ですよねー。
.NET界隈でも、C#からJavaScriptコードを生成するようなツールが結構あります。有名なものでは、Script#など。
-----引用-----

2012/04/11

マネージヒープ = ガベージコレクション（garbage collection）機能によって管理されたメモリ

title: マネージヒープ = ガベージコレクション（garbage collection）機能によって管理されたメモリ
url: http://csharptan.wordpress.com/2011/12/15/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%97%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0/

snippet:

-----引用-----
.NETのように、ガベージコレクション（garbage collection）機能によって管理されたメモリをマネージヒープ（managed heap）と言います。

マネージヒープの性質:

マネージヒープは、全体としてのスループット的には非常に性能がいいです
ヒープ（動的なメモリ確保）が必要なら、素直にマネージヒープに任せる方がいいです
ただ、処理負荷がある1点に集中してしまうことがあります
手動管理ではそもそもヒープを使わないような最適化が可能ですが、自動管理の場合はそういう最適化がしにくいです
下手なことをすると、ガベージコレクションの仕事を阻害して、かえって遅くなります
マネージヒープは、確保できる物理メモリ量が多めにある時に良い性能を発揮します
省メモリ環境は苦手です
物理メモリを目いっぱい使うようなキャッシュ処理は苦手です

-----引用-----

.NETの共通型システム

title: .NETの共通型システム
url: http://csharptan.wordpress.com/2011/12/15/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%97%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0/

snippet:

-----引用-----
今はもう、ライブラリやフレームワークなくしてアプリなんて作れません。.NETやJavaを見ての通り、標準ライブラリの時点で膨大な量のライブラリがあり、さらに、第3者提供のライブラリも山ほど見つかります。

これだけ大量のライブラリがあって、使いこなすことが要求されると、プログラミング言語自体を覚えることよりも、ライブラリを覚えるコストの方がはるかに大きいです。逆にいうと、ライブラリさえ共通利用できるなら、言語の違いなんて微々たるものです。

.NETのライブラリは、C#からでもVBからでも、なんなら、PowerShellやIronPythonなどからでも共通利用可能です。これが可能なのは、共通型システム（common type system）という、型の取り扱いに関する規格を持っているからです。

Windows 8で、共通型システムの適用範囲が広がります。.NETのメタデータ規格を流用して、ネイティブやJavaScriptでも型を共通利用できるようになります。
-----引用-----

2012/04/09

C#とILコード(.NETの中間言語)の対比

title: C#とILコード(.NETの中間言語)の対比
url: http://csharptan.wordpress.com/2011/12/17/net%e3%81%ae%e4%b8%ad%e9%96%93%e8%a8%80%e8%aa%9e/

snippet:

-----引用-----

intなどのいくつかの型は、加減乗除など、専用の命令を持っています（プリミティブ型と呼ばれます）
ちなみに、decimalはプリミティブではないです。ただの構造体
デリゲート、列挙型は特別扱いを受けています
内部的にクラスになったりするわけではなく、別定義
一方、null許容型はただの構造体です
配列も結構特殊な扱いを受けています
文字列（stringクラス）は単なるクラスですが、リテラルの扱いが多少特殊です
C#で、文字列だけは参照型なのにconstを付けれるのはそのため
ポインター型もあります
加減乗除などの命令には、オーバーフローのチェックをするタイプとしないタイプとがあります
チェックするタイプでは、オーバーフロー時に例外を発生させます
switchステートメント相当の専用命令があります
状況に応じて、if-else的なコードにJITするか、ジャンプテーブル的なコードにJITするか選んでくれるそうです

C#にはあるけど、ILには直接はないもの:

インデクサー
内部的にはプロパティ扱いです
ユーザー定義の演算子
単なる静的メソッドになります
ループ（while, for, foreach）
ifとgoto的なコードに展開されます
ラムダ式、イテレーター、非同期メソッド、dynamic
かなり込み入ったコード生成してます
イテレーターとかラムダ式に至っては、クラスが生成されたりしてます
クエリ式
割かし単純なメソッド呼び出しへの置き換え
lockステートメント
Monitorクラスに丸投げ
拡張メソッド、デフォルト引数、dynamicな引数
属性が付くだけ

ILにはあるけど、C#にはないもの:

本当の意味での可変長引数
C#のものは、配列の自動生成で実装しています
ILレベルでは、任意個数のスタックを消費してメソッドを呼び出す方法があります
変数の間接参照
C#だと、引数を参照渡しするときしか間接参照がおきませんが、ILレベルではもっといろいろ使える参照ロード/ストア命令があります
デリゲートとは別に、関数ポインターを持っています

-----引用-----

スタック型とレジスター型

title: スタック型とレジスター型
url: http://csharptan.wordpress.com/2011/12/17/net%e3%81%ae%e4%b8%ad%e9%96%93%e8%a8%80%e8%aa%9e/

snippet:

-----引用-----
.NETのILに限らないんですが、多くの仮想マシンはスタック型マシンになっています。

一方で、実CPUはだいたいレジスター型と呼ばれる構造をしています。スタックとは別に、レジスターと呼ばれる、高速に読み書き可能な記憶領域（個数が限られています）を持ちます。

コンパイラーがスタック型の命令を作るのは結構簡単です。仮想マシンの命令がスタック型になっていることが多いのはこのためです。レジスター型のCPU向けのコンパイラーであっても、一度スタック型の中間言語を生成した後で、実際のレジスター型の命令に置き換えるようなものも多いです。
-----引用-----

IL逆アセンブラー

title: IL逆アセンブラー
url: http://csharptan.wordpress.com/2011/12/17/net%e3%81%ae%e4%b8%ad%e9%96%93%e8%a8%80%e8%aa%9e/

snippet:

-----引用-----
今だと、C#逆コンパイラーとかも普通にフリーで手に入ります。私の場合は、IL Spyっていうツールを使っています。ILを読むのは結構大変なわけですが、C#化されればだいぶ読めると思います。なので、わざわざIL逆アセンブラーを使う理由はあまりなくなりました。

ILは、.NET Frameworkの仮想マシンによって、都度、ネイティブコード（実CPUが直接解釈できるマシン語）にコンパイルしながら（Just-In-Time方式のコンパイル、略してJIT）実行されます。

アセンブリの中には、メタデータ（型情報や属性）と、ILコードが入っています。
-----引用-----

便利ライブラリ: Moq

title: 便利ライブラリ: Moq
url: http://csharptan.wordpress.com/2011/12/16/%e5%8b%95%e7%9a%84%e5%87%a6%e7%90%86/

snippet:

-----引用-----
モック生成のためだけにTypeBuilderなどを使うのは結構大変なので、補助してくれるライブラリを使うのが一般的です。モック生成用のライブラリは、結構いろんなものがオープンソースで提供されています。

有名どころだと、Moq
-----引用-----

便利ライブラリ: MEF

title: 便利ライブラリ: MEF
url: http://csharptan.wordpress.com/2011/12/16/%e5%8b%95%e7%9a%84%e5%87%a6%e7%90%86/

snippet:

-----引用-----
プラグイン的な動的ローディングをサポートするためのフレームワーク
MEFは、.NET Framework 4からは標準ライブラリに取り込まれました。
System.ComponentModel.Composition名前空間以下のクラスがMEFの実体
-----引用-----

.NETの標準シリアライザ(XML/JSON)の使い分けまとめ

title: .NETの標準シリアライザ(XML/JSON)の使い分けまとめ
url: http://neue.cc/2011/12/10_357.html

snippet:

-----引用-----
XML:

XmlSerializer
DataContractSerializer

JSON:

DataContractJsonSerializer
Json.NET
JavaScriptSerializer

XmlSerializer:

外部から手に入るXMLをクラスにマッピングするところで使う
XmlSerializerなら順序無視なので大丈夫です
Dictionaryがシリアライズできない
LINQ to XMLの登場により、手書きで変換するのも十分お手軽

DataContractSerializer

オブジェクトの保存・復元用にはDataContractSerializerは無類の強さを発揮します
例えば設定用のクラスを丸ごとシリアライズ・デシリアライズ
Dictionaryだってなんだってシリアライズできます
対象クラスにDataContract属性をつけてあげる
引数なしコントラクタがないクラスだってシリアライズできちゃう
.NET 4版ではprivateプロパティの値も復元できる

-----引用-----

2012/04/06

バッチ・ファイル中で日付をファイル名に使用する

title: バッチ・ファイル中で日付をファイル名に使用する
url: http://www.atmarkit.co.jp/fwin2k/win2ktips/419batchdate/batchdate.html

snippet:

-----引用-----
C:\>echo %date:~-10,4%%date:~-5,2%%date:~-2,2%
20110824
-----引用-----

MS-DOSバッチファイル

title: MS-DOSバッチファイル
url: http://www.ne.jp/asahi/hishidama/home/tech/windows/bat.html

snippet:

-----引用-----
@echo off
別バッチの実行方法
タイトル変更方法
バッチの場所取得
変数
戻り値
標準入力

構文

if
for（for each)
goto（switch）
サブルーチン（call・exit）

-----引用-----

アルゴリズムは静的メソッドで実装

title: アルゴリズムは静的メソッドで実装
url: http://csharptan.wordpress.com/2011/12/14/%e8%a6%8f%e7%b4%84%e3%80%81%e5%ae%9f%e8%a3%85%e3%80%81%e3%82%a2%e3%83%ab%e3%82%b4%e3%83%aa%e3%82%ba%e3%83%a0/

snippet:

-----引用-----
アルゴリズムをクラスのインスタンスメンバーとしてではなく静的メソッドで実装
特定のクラスのインスタンスメンバーとして実装するよりも、別途静的メソッドを用意した方が、依存関係がなくてすっきりします。
-----引用-----

コレクションの内部実装

title: コレクションの内部実装
url: http://csharptan.wordpress.com/2011/12/13/%e3%82%b3%e3%83%ac%e3%82%af%e3%82%b7%e3%83%a7%e3%83%b3-2/

snippet:

-----引用-----
配列リスト
配列がいっぱいになったら、新しい配列を確保して要素をコピーします。

ハッシュテーブルの原理
確保するバケツのサイズは十分大きくなければいけません。事前に大き目の領域を取れない場合、被りやすくなり、性能を落とします。

-----引用-----

.NETのコレクションまとめ用途/計算量トレードオフ

title: .NETのコレクションまとめ用途/計算量トレードオフ
url: http://csharptan.wordpress.com/2011/12/12/%e3%82%b3%e3%83%ac%e3%82%af%e3%82%b7%e3%83%a7%e3%83%b3/

snippet:

どのコレクションを使えば良いのかをトレードオフ

型名
用途
計算量
内部実装

-----引用-----
List<T>

インデックスを使った読み書きはO(1)
末尾以外への要素の挿入や削除はO(n)
あらかじめ大き目の配列を確保しておきます
要素が増えて、サイズが足りなくなったらより大きな配列を確保しなおします

LinkedList<T>

事前に大き目の領域を確保したくない場合や、要素数が大きく変わるので事前確保の量を決めにくい場合に使います

Stack<T>

List<T>と同じ配列リストです

Queue<T>

List<T>と同じ配列リストです

Dictionary<TKey, TValue>

メモリに余裕がある場合にはもっとも高速な辞書です
要素の型は、GetHashCodeメソッドを正しく定義している必要があります
事前に大きな領域を確保できれば、ほぼO(1)で挿入・検索・削除可能
逆に最悪の場合、O(n)になります

SortedDictionary<TKey, TValue>

事前に大き目の領域を確保したくない場合や、要素数が大きく変わるので事前確保の量を決めにくい場合に使います
要素の挿入・検索・削除はO(log n)です
二分探索ツリー（赤黒ツリー）です

SortedList<TKey, TValue>

要素の挿入・削除よりも、検索の方が圧倒的に多い場合に使います
要素の挿入・削除はO(n)、検索はO(log n)

HashSet<T>
SortedSet<T>

同時実行（concurrent）系

System.Collections.Concurrent名前空間に定義されています（.NET 4での追加）。

-----引用-----

2012/04/05

DevOpsとは開発部門と運用部門の協力

title: DevOpsとは開発部門と運用部門の協力
url: http://www.publickey1.jp/blog/11/devops.html
http://en.wikipedia.org/wiki/DevOps
http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr

snippet:

-----引用-----

頻繁なリリースのために開発部門と運用部門が協力していかなくてはならない、というのがDevOpsの根底に流れる考え方
DevOpsの実現には「ツール」と「文化」が重要
たまにしか新たなリリースをしない場合にはそのたびにいっぺんに大きな変更がシステムに生じるため変更のリスクが大きくなるのに対し、頻繁に小さなリリースを繰り返す方が変更の度合いが小さく、リスクが少なくなる、という理由です。
伝統的な組織では、開発部門と運用部門は対立しています。
自動化されたインフラとバージョン管理、ビルドツールといったツール群、そしてお互いを尊敬し、信頼しあう文化が大事であると。
Flickrがいかにして1日に10回も新しい機能をリリースしているのか、そのツールや企業文化を紹介しています。

-----引用-----

TFSを使いたいと思った理由

title: TFSを使いたいと思った理由
url: http://blackssi.cocolog-nifty.com/blog/2011/12/tfs-advent-cale.html
http://cs.gogo-asp.net/blogs/libaty/archive/2011/12/05/TFS-Advent-Calendar-Day-5_5EFF_TFS_4C30D0639B4F573066304D305F305F6AFD806E30095977905EFF_.aspx

snippet:

-----引用-----
TFS2010、TracLightningなどがある
Trac+SVN+JenkinsでだいたいTFSと同じような管理は可能
TFS2010は「管理ツール」ではなく、「管理インフラ」
-----引用-----

2012/04/04

Advent Calendar 2011 いろいろリンク

title: Advent Calendar 2011 いろいろリンク
url: http://csharptan.wordpress.com/2011/11/

snippet:

-----引用-----

C# Advent Calendar 2011
F# Advent Calendar 2011
PowerShell Advent Calendar 2011
Silverlight Advent Calendar 2011
Windows Azure Advent Calendar jp: 2011
TFS Advent Calendar

-----引用-----

登録: 投稿 (Atom)

このブログの中を検索する

2012/04/15

2012/04/14

2012/04/13

2012/04/11

2012/04/09

2012/04/06

2012/04/05

2012/04/04