WPFに関するエントリが結構たまってきたので、ここらへんで一度整理してみようと思います。 整理してみると、結構いっぱいあってびっくりしました…。 無駄に長いエントリになってしまって無念…。 WPF入門・基礎系 WPFの超入門あたりのエントリです。Hello Worldあたりの触りのエントリ。 WPF入門してみた WPF入門してみた　その２ xamlで書いてみよう [WPF]WPFアプリケーションの種類 DependencyObjectについて WPFのコントロールはすべてDependencyObjectを間接的に継承しています。 なので、DependencyObjectについて理解するのは大事なことです。 [C#][WPF]DependencyObjectって [C#][WPF]DependencyObjectって　その２ [C#][WPF]DependencyObjectって その３ [

シャノンさんのアイデアは 面白い試みだと思いました。一部で勘違いされる方もいたようなので要旨をまとめておきます。 その用語、実態はどうなの？ PG/SE論争というのがあります。PG(プログラマ)とSE(システムエンジニア)の仕事についての話題なのですが…。 @ITなどの掲示板では定期的に出てくる話題のように思いますね。 私も過去にエントリを書いています。 この論争の場合、ざっくりとまとめると 大手企業は利益率の良い「上流工程」を行いたがる 「上流工程」の上流というのは貴賓のことではなく、開発工程上のもので特に意味はない 上流工程を主に請け負いたいがために、社員教育の過程として下流工程→上流工程という過程を経る 出世の過程としても下流工程を行う役職(PG)→上流工程を行う役職(SE)という流れ 何を勘違いしたか下流工程を行うのは下賤な仕事という認識を持つ人が出てくる 根本的な価値観の違いが論

CIツールのHudsonを試してみた。 継続的にビルドをしてくれる縁の下の力持ち。 配備は簡単だった。Tomcatにwarを置くだけでOK。 簡単なプロジェクトを登録してみると動きはOK。 多分、ここで躓くことはないと思う。 調子にのってきたので、NetBeansのVisual Web Packで作成したプロジェクトを登録してみると、ビルドにことごとく失敗する。 どうやら、Visual Web Packのプロジェクトはnbproject/private/private.propertiesが無いとビルドに失敗するくさい。 仕方ないので、CIサーバにNetBeansとVisual Web Packをインストールしてprivate.propertiesを採取。 プロジェクト直下にhudson.propertiesという名前で保存しておく。 次に、build.xmlをコピーしてhudson.xm

もっとも「ロジック」というのも程度問題なのだけど、 少なくともプログラム言語で記述するレベルでのロジックを書くというものではありません。 いや、特定の企業ではそういう書類を（しかもプログラム前に！）書かせるように強要してきたりするけども。 参考：IEEE830-1998におけるソフトウェア仕様書（内部）の書き方 そもそも業界ではさも当然のように「外部仕様書」とか「内部仕様書」という言葉を使っていたりしますが、 あまりきっちりした定義はありません。上記でも「内部仕様書」という定義ではないわけですし。 各社の文化で独自に解釈されているのが実情ですかね。 ニュアンスとして外部/内部というのはI/O境界面からの外部/内部といった感じ。 他のチーム(別会社だったりする)とかとやり取りするために、この機能は外から見たらこんな感じ、というのが外部仕様で、 中はこう言う風に作るっていうのが内部仕様とされま

「ひがやすを BOF ITゼネコンをぶっつぶせ」 に期待にて 技術力のあるところがプロジェクトを統括すれば、安く、早く、良いものを作ることができる。これは、技術を売り物に独立起業している人間であれば多くが「うちにやらせてくれるなら出来る」と言うことでしょう。この点はさしたる問題ではない。 などと言ったわけなのですが…。この点、IT業界特有のものでしょう。 IT業界には設備がいらない IT業界特有、というのはシステム開発において「設備」というものが重視されない点です。 自動車整備工の人が、自宅の方が設備がよいので自宅で作業したいと言うでしょうか？ 医師の人が、自宅の方が設備が良いので自宅で手術した方がいいのにと言うでしょうか？ しかしプログラマは「家のマシンの方が性能いいし、モニタもでかいし、本もあるし、 ネットも速いし、家でプログラム書く方がいいよね」と言う人が多い。 マシンが必要といって

「Step数を報告して」と言われると「Step数(笑)ですか」と言いたくなる今日この頃、 みなさん、いかがお過ごしでしょうか。 ところで、Step数って何が悪いのかを説明できますか？ その数字の示すところを知った上で正しく使うには問題ないのですが…。 Step数は規模に対して正の相関関係を持つ まず、Step数と規模にはなんらの関係もないわけではありません。 Step数は確かに規模と正の相関性を持っています。 ただし、誤差があまりに酷いというだけのことです。 Step数という指標の誤差には以下のような原因が考えられます。 コードのフォーマットによる誤差 マルチステートメントなどの記法による誤差 ロジックによる誤差 冗長性による誤差 他にもあると思いますが、挙げ始めるときりがありませんね…。 コードのフォーマットによる誤差 コードのフォーマットによる誤差は for (int i=0; i<1

「誰が書いても同じコード」は大事なことなのかで 語られている話は非常に興味深ものです。 SIerの言うところの「仕様書」というものはなんなのでしょうか。私のblogでも 内部仕様書はロジックを書くものではない で仕様書を話題に挙げたわけですが、仕様書の在り方を、システム開発の分業の在り方を今一度考えてみたいと思います。 「誰が書いても同じコード」になるためには コードとは何でしょうか。プログラミング言語で書かれたアルゴリズムの表記のことです。 プログラムするということはどういうことでしょうか。 ある目的を適える為のアルゴリズムを考え、プログラミング言語でそれを表現する過程を言いいます。 「誰が書いても同じコードになる」ということは、誰もが同じアルゴリズムを採用し、 そして、その表記さえも同じ書式になることです。 書式のブレは瑣末なことです（コード規約の自動チェックツールなどを導入すれば容易

イレイジャではジェネリクスの何が消えるのかにて親クラスを継承する際に投入しているジェネリクス型パラメータはclassの情報として残っていることを述べました。 これを利用すると、 public class A<X> { public class B<Y> extends A<Y> { public class C extends B<String> { といった継承階層があった場合に、C.classからA.classの<X>にどのような具象型が適用されているのか(上記例ではString型)をリフレクションで取得することができます。 Aの型パラメータのプレースホルダ<X>を取得 Bでsuper-classの型パラメータに渡されたTypeを取得 2のTypeが具象型ではなく型パラメータ<Y>なのでさらにサブクラスを走査 Cでsuper-classの型パラメータに渡されたTypeを取得 B<Y>の

なぜこうもレビューされてないコードを記事に書く？ 「サニタイズいうな」と「ハンガリアン」 このあたりの話題は、個々のプログラマに対して「気をつけろ」と注意喚起してもなくならない話題なのですが、 その背景的な部分をば少し。 サニタイズは消毒足り得ない sanitize = 「無害にする」、という英単語ですが、≒ sanitate 「消毒する」と紹介されることが多いですね。 でも、この消毒という比喩は文学的ではあるけども、技術的には問題のある比喩に思います。 XSS(Cross Site Scripting、クロスサイトスクリプティング)への対処として言われることが多いですね。 現実の消毒というのは、過剰に繰り返しても問題はなく、 消毒済みのものをそのままもう一度消毒しても構わない。 なので、食品衛生的な現場では過剰なぐらいに「とりあえず消毒」というスタンスでやるわけです。 これに対しプログラ

Javaのジェネリクスはコンパイル時に解決され、classファイルになった時にはジェネリクスの型情報は残されていません。そのためイレイジャ（型消去：type erasure）方式と呼ばれます。 と、ひとくちで言っても意味がよく分からないのでちょっと掘り下げてみましょう。 インスタンスからジェネリクスの型情報は拾えない リフレクションを用いたとしても、インスタンスからジェネリクス型パラメータが何であるかを取得することはできません。 List<String> stringList = new ArrayList<String>(); のような変数stringListがあったとして、ここから<String>を取得するということができないのです。これが消えてしまった部分。 この変数stringListに対する各種操作において、その型の安全はコンパイル時に精査され、 実行時にはあくまでObject型