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

2012/05/21

Live SDKというものがあってSkyDriveにアクセスできる

title: Live SDKというものがあってSkyDriveにアクセスできる
url: http://d.hatena.ne.jp/okazuki/20120329/1333031318

snippet:
-----引用-----

2011年12月にLive SDKというのがリリースされてて、これを使うとWindows Live ******のサービスがアプリケーションから使えるんですってね!!知らなかった!

SkyDriveとかを使うとWindows 7/8, Windows Phone, Android, iOS, Web Serviceで同じストレージを共有したサービスとか自前でストレージ用意しなくてもユーザーごとに最大25GBまで使える領域が手に入っちゃうとか素敵じゃないですか?

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

Loggin Application Blockを使ってHello worldというログをファイルに出力する方法

title: Loggin Application Blockを使ってHello worldというログをファイルに出力する方法
url: http://d.hatena.ne.jp/okazuki/20120405/1333635760

snippet:
-----引用-----

NuGet Package Managerから「EnterpriseLibrary Logging」で検索をして「Enterprise Library 5.0 – Logging Application Block」をプロジェクトに追加

続けて参照の追加からSystem.Configurationを追加

1. using System.Diagnostics;
2. using Microsoft.Practices.EnterpriseLibrary.Common.Configuration;
3. using Microsoft.Practices.EnterpriseLibrary.Logging;
4.
5. namespace HelloWorld
6. {
7.    class Program
8.    {
9.        static void Main(string[] args)
10.        {
11.            // 構成情報を組み立てる
12.            var builder = new ConfigurationSourceBuilder();
13.            builder.ConfigureLogging()
14.                .SpecialSources
15.                .AllEventsCategory
16.                    .SendTo
17.                    .FlatFile("FlatFileListener")
18.                    .FormatWith(
19.                        new FormatterBuilder()
20.                            .TextFormatterNamed("TextFormatter")
21.                            .UsingTemplate("{timestamp(local:yyyy/MM/dd HH:mm:ss.fff)}: {message}"))
22.                    .ToFile("output.txt");
23.
24.            // 組み立てた構成情報からConfigurationSourceを作成
25.            var config = new DictionaryConfigurationSource();
26.            builder.UpdateConfigurationWithReplace(config);
27.
28.            // 構成情報を元にEnterpriseLibraryのコンテナの初期化
29.            EnterpriseLibraryContainer.Current = EnterpriseLibraryContainer.CreateDefaultContainer(config);
30.
31.            // EnterpriseLibraryのコンテナからLogging Application BlockのLog書き込み部品を取得
32.            var logger = EnterpriseLibraryContainer.Current.GetInstance<LogWriter>();
33.            // ログに出力する
34.            logger.Write("Hello world");
35.
36.            // ログを表示
37.            Process.Start("output.txt");
38.        }
39.    }
40. }

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

Enterprise Libraryにある機能

title: Enterprise Libraryにある機能
url: http://d.hatena.ne.jp/okazuki/20120405/1333635760

snippet:
-----引用-----

Enterprise Libraryにある機能の使い方を理解し適切に選択して使用できるようになると、アプリケーションを効率よく開発することが出来るようになると思います。(もしくは、どのような機能セットを提供しているのか、どのような点に留意して作成されているのかという参考にすることも出来ます)
  • Caching Application Block
    • アプリケーション内でキャッシュ機能を提供します。
  • Cryptography Application Block
    • データの暗号化・複合とハッシュを生成する機能を提供します。
  • Data Access Application Block
    • データベースへのアクセス機能を提供します。
  • Exception Handling Application Block
    • 例外処理の機能を提供します。
  • Logging Application Block
    • ログ出力機能を提供します。
  • Policy Injection Application Block
    • 機能横断的なPolicyをアプリケーションに適用する機能を提供します。
  • Security Application Block
    • 承認の規則(操作の許可や拒否など)を構成・管理する機能を提供します。
  • Validation Application Block
    • 値の妥当性検証の機能を提供します。
-----引用-----

SharpDevelop 4.2 新機能

title: SharpDevelop 4.2 新機能
url: http://d.hatena.ne.jp/okazuki/20120517/1337266511

snippet:
-----引用-----

NuGetも使用可能
WPFのデザイナも使用可能
T4 Templateにも対応

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

C++0xの機能 : for文の拡張

title: C++0xの機能 : for文の拡張
url: http://d.hatena.ne.jp/okazuki/20120516/1337178197

snippet:
-----引用-----

これも便利です。
std::vector<int> v;
...
for (int i : v) {
    std::cout << i << std::endl;
}

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

C#でExcel 2003形式/Excel 2007形式のファイルを出力する

title: C#でExcel 2003形式/Excel 2007形式のファイルを出力する
url: http://d.hatena.ne.jp/okazuki/20120429/1335690880

snippet:
-----引用-----

Excel(2003)形式のファイルを出力 : NPOI
C#でExcel 2007形式のファイルを出力する : ClosedXML

NugetからClosedXMLをインストールします。

個人的にはNPOIよりもいい感じに使えます。2年後には、NPOIじゃなくてこっちを使ってもいいかもですね!あと、最終的に行き着く先がOpen XML SDKなのでNPOIみたいに微妙に読めないファイルがあるということが少ないかもしれない。

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

2012/05/19

特許庁の基幹システムはなぜ失敗したのか : 特許庁の基幹システム失敗の背景にある、日本におけるITプロジェクトの実態


title: 特許庁の基幹システムはなぜ失敗したのか : 特許庁の基幹システム失敗の背景にある、日本におけるITプロジェクトの実態
url: http://www.publickey1.jp/blog/12/gpmo.html
http://www.publickey1.jp/blog/12/it_17.html

snippet:

-----引用-----
1.IT技術の活用をイメージできず盲信している

技術を特許庁の業務にどう活かすかという具体性・現実性に乏しく、技術オリエンテッドで物事が進んでいた。つまり僕の目には、当初の基本アーキテクチャそのものに疑問が大いにあった。この責任は開発会社だけではなく、発注者にもある。つまり技術をどう活かすかという結果イメージがシナリオレベルで不明確で両者(発注側・開発側)どちらも説明できていないのだ。

2.業務モデル(フロー)説計の不慣れさ

業務フローをどう活用するかというイメージがなく、ただただ言われた業務を書きうつすだけ。当時そういう人が千名近くいたという。その時点で破たんしているのだ。
業務フローなどのドキュメントはドキュメント過多に陥りやすい。戦略的にどう活用すべきか省庁の中で充分に整理をしてから手をつけないと、無用な産物を作り出すことになる。当時既に無用な産物化していたのだ。

...

4.業務モデルは発注者の理解と覚悟の元作成する

これを開発ベンダー中心で書き続けるかぎり、こういう失敗は続く。つまり「絵に描いた餅」か「現状業務の見える化」にすぎないものを多大な工数を使って作り上げてしまう事になるのだ。
そういう多大なドキュメントを抱え込んだプロジェクトは、設計局面で要求が肥大化し爆発する。また、そうなっている状況において耐え直す勇気がない、それがプロジェクトマネジメントの問題であり、それは請け負った開発会社の問題でもあるだろう。

日本独特の契約形態も絡んでいる

また、この問題には、日本独特のSIerとの契約形態が絡みます。この契約形態こそ日本のIT技術を駄目にしているもので、まだ要求の価値も見いだせない段階で、要求を定義していく過程で絞り込みができず、要求の量が爆発的に増大。そして、その爆発した要求に対して工数を見積もるような慣習です。それがプロジェクトを超大規模化させる原因であり、IT業界が価値を生み出さず、3Kと言われる屈辱的な状況を作り出している。
-----引用-----

-----引用-----
そもそもITの使われ方が業務と密接に絡んでいるのに、ユーザはITをSIerに丸投げしてしまう、あるいは業務プロジェクトのIT化の進め方が解っていない。一方のSIerも業務の変革に踏み込もうとしない。あるいは踏む込む知識を持ちえない。

このような状況になっているのは、システム要件定義から始まる開発契約という日本のITにおける慣習が邪魔をしています。日本人は慣習に弱いのです。これが現代のビジネスに合わなくなっているのにもかかわらず、この慣習から逃れられません。
-----引用-----

グーグルはコードの品質向上のため「バグ予測アルゴリズム」を採用している : ソースコードの修正履歴を基に予測


title: グーグルはコードの品質向上のため「バグ予測アルゴリズム」を採用している : ソースコードの修正履歴を基に予測
url: http://www.publickey1.jp/blog/11/post_193.html

snippet:

-----引用-----
コードの中にバグがありそうな箇所を分析する手法としては、「ソフトウェアメトリクス」がよく用いられます。しかしグーグルが用いたのはもっとシンプルな方法でした。ソースコードの修正履歴を基にバグ予測をすることにしたのです。

そう、私たちはコードのどこが修正を必要とされてきたかという、本物の記録を持っています。それはバグトラッカーとソース管理のコミットログです。例えばFixCacheなどの研究によると、ソースコードの履歴を元にしたバグ予測は非常にうまく働きます。そこでこれをグーグルで運用することにしました。
それは、過去にそのコードがバグフィックスのため、いつ、何回修正されたか、という情報を基にした実にシンプルなアルゴリズムです。

彼らが発見したのは、そのコードに対してこれまでバグフィックスのコミットが何回行われたかをランキングすることで、コードの中のホットスポットを見つけられるだろう、というものです。まさにシンプル! そしてこれは私たちの直感、もしも何度もバグフィックスが必要なファイルはデベロッパーが苦労しているところだからホットスポットに違いない、というものにマッチするのです。
-----引用-----

2012/05/18

マイクロソフトはどのようにソフトウェアをテストしているか?


title: マイクロソフトはどのようにソフトウェアをテストしているか?
url: http://www.publickey1.jp/blog/12/_jasst12_tokyo.html

snippet:

-----引用-----
マイクロソフトはワールドワイドで9800人のテスターがいて、開発者とテスターはほぼ同じ、開発者一人にテスターが一人という割合。これらのテストを行っているテスターはどんな人たちなのか? コンピュータサイエンスや電子工学の卒業者を採用しているが、そういう人はみな「デベロッパーになりたい」と考えているため、テスターになるよう説得しなければならないことが多い。

マイクロソフトには「テストアーキテクト」というポジションがある。これは管理職としての仕事はしない。開発のエンジニアリングプロセスの改善に責任をもっている。テストアーキテクトになるにはバイスプレジデントの承認が必要なため、なかなか簡単にはなれないが、こうしたキャリアパスがあることで優秀なエンジニアを引き留めることができている。

テストで重要なのはお客様の利用シナリオだ。どの製品であってもシナリオから始まり、フィーチャー(機能)を設計、開発していく。開発サイクルでは継続的にシナリオに当てはめ、バグフィクスの優先度を決める際にもシナリオを重視している。

「Day in the life Testing」(日々の生活の中でのテスト)もしている。製品の各機能はシナリオに基づいているが、往々にして起こるのは全体としての体験シナリオになっていないことだ。
-----引用-----

グーグルはあれほど多くのソフトウェアのテストをどのように行っているのか?

title: グーグルはあれほど多くのソフトウェアのテストをどのように行っているのか?
url: http://www.publickey1.jp/blog/11/post_144.html

snippet:

-----引用-----
Yes, that's right: at Google it's the product teams that own quality, not testers. Every developer is expected to do their own testing. The job of the tester is to make sure they have the automation infrastructure and enabling processes that support this self reliance. Testers enable developers to test.
そう、グーグルではテストチームではなく、製品チームが自身で品質管理を負っている。各デベロッパは自身でテストすることを期待されている。テスターの仕事は、自動テストのインフラを確立することと、それによってデベロッパ自身がそれをプロセスの中で実行できるようにすること。テスターはデベロッパーがテストできるようにするのだ。

各製品チームは、Engineering Productivityのメンバーの支援を受けつつ、自分たちの責任でテストを行わなければならない、ということがグーグルのテストを行う際のポリシーのようです。

テストエンジニアはテストへの取り組みを促進する
-----引用-----