nDiki : 開発環境

開発 エディタ .NET Framework インストール Linux Windows C# Emacs Perl Naney ビルド Visual Studio Microsoft Visual C# インストーラ Flash コンテンツ Ming Eclipse CVS Firefox メモ Flex 2 MinGW SSH ノート PC 単体テストフレームワーク コーディング規約 コマンド プロンプト マイク Apache

■ ActivePerl で Ming

ActivePerl で Ming を使えるようにしておきたい。

@ Visual Studio で

Ming 0.3 beta1 のソースパッケージには Visual Studio 6.0 用のプロジェクトファイルが含まれている。 Cygwin の Bison と flex があればライブラリをビルドできるようだ。 横着して Linux 側で bison と flex で生成したファイルをコピーして(それから unistd.h をインクルードしている部分を消して)、ビルドしてみたところ一応 lib ファイルは作成成功。

しかし ActivePerl 用にPerl モジュールの make は失敗。

@ MinGW + nmake で ActivePerl のモジュールをビルドできるらしい

調べたところ ExtUtils::FakeConfig を使うと Visual Studio が無くても MinGW + nmake でモジュールをビルドできるらしい(全てではないと思うが)。

ということで Ming を MinGW でビルドした後、そのまま ActivePerl 用モジュールの作成まで持ち込むことにしてみる。

@ MinGW + MSYS + GnuWin32 で開発環境を構築

コンパイルに必要な環境を MinGW で、configure に必要な環境を MSYS で用意する。

• MinGW-3.1.0-1.exe -> インストーラ形式
• MSYS-1.0.10.exe -> インストーラ形式
• msysDTK-1.0.1.exe -> インストーラ形式

@ bison は GnuWin32 で

Ming のビルドに必要な Bison は MinGW、MSYS のインストーラに含まれていない。 bison-1.875.0-2003.02.10-1.exe というのが別途あるがうまく動かない。

ソースパッケージ(bison-2.0.tar.gz、bison-1.875.tar.gz)からはビルドできず。 MinGW/MSYSのプロジェクトにある bison-1.875-2003.02.10-1-src.tar.gz はビルドできるものの make check が通らない。

とうことで GnuWin32 の bison-1.875-4.exe (インストーラ形式)をインストール。 c:/usr/local/GnuWin32 にインストールした後、MSYS の /etc/fstab で /GnuWin32 にマウントし、/GnuWin32/bin に PATH を通しておく。

@ flex はソースパッケージから

flex-2.5.4a.tar.gz を展開して

 ./configure; make; make check; make install

インストール時ハードリンクが作れなくてエラーがでているようだが無視。

@ zlib (Ming で必要)

MSYS 上でビルドしてインストール。zlib-1.2.2.tar.gz を展開して

 ./configure; make; make check; make install

@ LibUnGif for Windows (Ming で必要)

MSYS 上でビルドしてインストール。 libungif-4.1.0b1-src.zip を展開して

 rm config.cache;
 config.h内の-DHAVE_VARARGS_Hをコメントアウト。
 ./configure; make; make install

make check はエラーが出るが無視。

@ libpng (Ming で必要)

MSYS 上でビルドしてインストール。libpng-1.2.8-config.tar.gz を展開して

 CFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib ./configure
 make; make check; make install

@ いよいよ Ming

MSYS 上でビルド。ming-0.3beta1.tar.gz を展開して

 CFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib make static

@ ActivePerl 用モジュール作成

ExtUtils::FakeConfig と PPM::Make で Ming の SWF PPM パッケージを作成する。 (MSYSのシェルではなく)コマンド プロンプトを開いて、Mingソースパッケージの中の perl_ext に移動。 MSYS、MinGW、nmake にPATHを通しておく。

それから Makefile.PL の実行で -lz を発見できないので、libz.a を Makefile.PL と同じディレクトリにコピーしてしまう(-L/usr/local/lib を指定しても効かなかったので)。 libpng.a、libungif.a も同じくコピーしておく。

Makefile を作成。Makefile.PL では -lz しか指定していないが、libpng と libungif も必要なのでコマンドラインオプションで指定する。ExtUtils::FakeConfig の Config_m を使用して MinGW を使用するようにする。

 perl -MConfig_m Makefile.PL LIBS="-lpng -lungif -lz"

ここで生成される Makefile の中で libperl58.a を指定している部分があるが、ActivePerl では perl58.lib になるので、エディタで書き換え。 後はいつも通り

 nmake
 nmake test
 make_ppm

で PPM パッケージ作成完了。

簡単なPerlプログラムでSWFファイルが作れる事を確認。 やった。

• PAR::Repository でビルド済み Perl モジュールをネット... (2006-12-12)
• Module::Build でソースパッケージング (2005-08-24)
• Windows 用 GNU Make (2004-07-24)
• OpenSSH for Windows (2004-08-05)
• Windows 用 GNU tar (2004-08-05)

■ 書籍の処分の判断はどのようにするべきですかね

今年も今日が最後である。昼休みはオフィスのスタッフ全員で近くのPATATI PATATAへテクテク歩いて行って食事会。 午後の3:00過ぎから、大掃除。

チームメンバ内で「本が増えてきたから本棚が欲しいね。その前にまずは今あるキャビネットにある古い本を捨ててスペースを確保しよう。」と話ていたので、今日実行することにした。

古いハードウェアのマニュアルやら、もはや使っていない開発環境に関する解説本やら出るわ出るわ。また、プロジェクトの資料として購入していたであろう特定分野の本などもいろいろと。

「もはや、いらんだろう」という本が多いのだが、こういうのって誰かが「それいる」というのが出てきそうで決断しにくかったりするのだよね。 誰が何のために買ったのかわからんものは特に。

ということで不要と判断した本を一度山積みして必要だと思った人がそれらを棚に戻し、残ったものは捨てるということにした。

なので、大掃除は済んだものの机の上にはいらないであろう本がどっさり。

今後、本を購入していく際はどうしていくのがいいのだろうね。 購入を希望した人の名前を書いておくかね?

• NASA World Wind 1.3 は他人のPCで (2005-03-22)
• オフィスの高度 (2004-12-24)
• スティラコサウルスは How How と鳴く? (2005-04-25)
• ちくわ笛 (2006-02-02)
• スクラッチから書き直したくなるプログラマは、書き直したプログラムもまたスク... (2008-06-14)

■ 「○○についてのお薦めの本、ありますか?」

たまに

「○○についてのお薦めの本、ありますか?」

と問われることがある。 ○○には C++ とか、C# とか Perl とかその他もろもろのコンピュータ関連キーワードが入る。

正直この質問は辛い。

コンピュータ関連の書籍は、今や大量に出版されているし陳腐化も激しいので相当マメにチェックしていないと人に紹介できるもんじゃない。

もちろん古典・定番もあることはあるが、こういう質問の時はたいがいこれには当てはまらない。 言語や開発環境なんかの本の質問はあるけれど、計算機数学とかアルゴリズムとかそういうのを求めてくる人などいないのである (大体そういうのに興味がある人は自分で探している)。

たまたま自分が詳してかつ最近リサーチをかけた分野については良書と呼べるものを知っている場合があるが、良いと思ったら自分でも買っているから既にその人に貸していたりする。

安直にコンピュータ書籍を紹介して欲しいという人は、よくわからないというのを理由に自分で探さず、しかもハズレを引いて金を払うことを非常に嫌っている。

一応質問されると Amazon.co.jp とかのぞいてみるのだが、その人のスキル・その人が求めているものまで理解していないので、結局徒労に終わるのである。 だいたいその程度なら、本人ができるはずなのだが。

ま、ようはケチらずどんどん読んで「この本はウンコだ」と言えるようになるのが一番ということだ。

で、なんかお薦めの本ありませんか?

• Naney お薦めの本

• ハッシュとは (2004-06-09)
• 今日もよくたれています。 (2006-11-17)
• ActivePerl で Ming (2005-02-23)
• トム・デマルコ ゆとりの法則 - 誰も書かなかったプロジェクト管理の誤解 (2004-04-17)
• ソフトウエア開発 55の真実と10のウソ読了 (2004-06-08)

■ ノート PC を持たずに会社に行きたい

今日は夕方から社外でミーティング。 Windows 環境でのデモンストレーションが必要なため、普段持ち歩いている自分の ThinkPad X31 (Linux BOX) に加えて会社の Dell のノート PC を持って出発。重い。

メールや開発環境などは一元管理したい派なので普段の通勤でノート PC を持って往復するのはまあしょうがないのだが、こういう日は家に置いてきてせめて1台にしたいところである。

オフィスで開発などのヘビーな作業をしない日は、最近構築を進めている USB メモリによるポータブル環境で済ませられるようにぜひしたい。

@ 母艦でしていることを思いつく範囲で列挙

認証がからむものをできるだけポータブル環境にまとめたいところ。 データはさすがに全部 USB メモリに入れて持ち歩けないので、どんどん Subversion リポジトリに置くようにして必要なものだけ取れるようにした方がいいかな。

• Linux 母艦ノート PC を使わずに仕事ができるかチャレンジ (2007-08-20)
• 納品前日なのに /var が壊れた! HDDからのブートで Debian ... (2005-09-27)
• 普通の人向けに svnserve を立ち上げるか (2005-07-26)
• Linux で入力して Windows で参照できるパスワード管理ツール ... (2006-12-31)
• sniffit 0.3.7 beta をインストール (1999-01-22)

■ Linux 上で Flex 2 SDK を使った Flash コンテンツ開発を開始

Flash コンテンツ開発については以前から興味があったんだけれど、手元 (Debian GNU/Linux BOX) で開発環境が構築できないので、ほとんど手をつけていなかった。 Ming を試してみたこともあったのだが、全然使いやすくなかったし。

しかしながらここ最近では Flex 2 SDK によって、Linux 上でも Flash コンテンツを開発できるようになった。 ということで技術調査をかねて開発環境構築と、コード書きを始めてみた。

まずはエディタとコンパイラと単体テストフレームワークがあれば開発できる。 Debian GNU/Linux sid 上で用意した環境は以下。

• JDK - sun-java6-jdk (6-02-1 Debian パッケージ)
• Ant - ant (1.7.0-3、Debian パッケージ)
• Emacs 21 (Debian パッケージ)
• Flex 2 SDK (2.0.1、Adobe よりダウンロード)
• Flex Language Pack (日本語、Adobe よりダウンロード)
• Flex Ant tasks (022607、Adobe Labs よりダウンロード)
• FlexUnit (code.google.com よりダウンロード)
• Flash Player 9 スタンドアロン版

エディタは素直に Emacs で。単体テストフレームワークは、FlexUnit (.85) をチョイス。

今回はビルドツールを何にするか迷ったけれど Apache Ant にすることにした。最初は Makefile を使ってサンプルをビルドしていたりしたけれど、今後 Autotools 使うのもどうかなと思って。

ドキュメントについては Adobe から結構な量で提供されているのでこれを見ればたいがい足りそう。

ということでぽちぽちプロジェクト作成。とりあえず SWF ファイルと同じところにあるテキストファイルを読み込んで表示するだけの MXML ファイルを作成して、build.xml を構築。

ほとんどの時間は build.xml 書きと、Subversion リポジトリセットアップに費された。

後は別途ちょっとサンプルで試してみた FlexUnit をプロジェクトに組み込めば発進できそうだ。

• Linux で使えるデスクトップ検索ツール Beagle でローカルファイ... (2006-08-08)
• ActivePerl で Ming (2005-02-23)
• Debian GNU/Linux で Dropbox (2008-09-16)
• JAlbum で Webフォトアルバム (2004-11-14)
• Windows でも Linux でも動くタスク管理ツール Task Coach (2006-01-12)

■ 今日のさえずり - 鉄道マンてダイヤ乱れると高揚するのかな?

• 09:25 京浜東北線北行まだダイヤ乱れているな。L:大井町駅[mb]
• 09:43 鉄道マンてダイヤ乱れると高揚するのかな? 台風接近すると興奮するみたいに。[mb]
• 12:14 レンタル品の期間延長料金振り込んだ。[mb]
• 12:24 アリシア・キーズの CD 買った。L:秋葉原[mb]
• 15:16 社長「FON AP 助かるな」 - それ私が社内に設置したやつ。
• 16:08 ワンダ「キン肉マン胸像フィギュアコレクション」でウォーズマンをチョイス。[mb]
• 18:14 週末仕事できるように会社のノート PC に開発環境つくるかな。まずは Visual C# 2005。
• 18:58 ポータブル HDD に入れていた Firefox Portable を Firefox の　Check for Updates... からアップデートしちゃったけど問題なかったかな。 *Tw*
• 19:04 TortoiseSVN インストール完了。ここでタイムアップ。 *Tw*
• 19:31 Twitter 大喜利やってても興奮しなくなった。[mb]
• 19:57 バーガーキングのネエチャンがサンタの帽子かぶってる。[mb]

• 今日のさえずり - 昭和通りでホームレスがトロフィーかかげてる! (2008-08-31)
• 今日のさえずり - ささやかな気持ちDES (2008-11-07)
• 今日のさえずり - 「ドン吉くんの鳥グッズ展」終了間近 (2008-08-08)
• 今日のさえずり - 会社の横の空き地でポイの昼練 (2008-10-29)
• 今日のさえずり - 背後に立たれていても気がつかないという恐れ (2008-09-09)

■ スクラッチから書き直したくなるプログラマは、書き直したプログラムもまたスクラッチから書き直したくなる。

自分がプログラムをスクラッチから書き直したいと思った時、またスクラッチから書き直したいと言われた時のためにまとめておこう。

@ スクラッチから書き直したい理由

スクラッチから書き直したいと思う理由はだいたいこうだ。

• もっと良くできると思うから
  • 「もっと良いやり方がある」「自分ならもっとうまく書ける」
  • 「統一されていない」「もっと汎用的にできる」
  • 「今なら新しい開発環境(・新しい実行環境・新しいライブラリ・新しい言語)を使って簡単によりいいものが素早く作れる」
• よくわからないいから
  • 「何をやっているかわからない」「どう直していいかわからない」
  • 「もう直しようがない」
  • 「作り直した方がはやい」
• あいつのだから
  • 「あいつが書いたコードだから」

どんなプログラムでも開発が進み詳細がわかってくると、こうしておけば良かったと思う点がでてくるものだ。

さらに、他人が書いたプログラムだとよく分からない。

It's harder to read code than to write it. (プログラムというのは書くより読むほうが難しい。) -- Things You Should Never Do, Part I - Joel on Software

いっそ作り直してしまいたいと思うのはどの開発者でもあることだ。

@ スクラッチから書き直してはいけない理由

しかし多くの場合スクラッチから書き直すことはリスクとデメリットだらけだ。

• 今までの投資を失うから
  • 「そのプログラムには検討・不具合修正に膨大なエネルギーが投入されている」
  • 「ユーザは今のプログラムのために学習コストをかけている」
• 時間がかかるから
  • 「その新しいプログラムが今と同じレベルの価値を実現するまでは時間がかかりすぎる」
  • 「スクラッチし直してから投入したのでは、もはや価値を失っている可能性が高い」
• 前轍を踏むから
  • 「どう直していいかわからないと思う時は往々にして目標がわかっていない。目標がわからずに作ったものは結局またスクラッチから書き直したくなる」
  • 「あなたが連続的にプログラムを修正できないというのなら、どちらにせよ新しく作り直したプログラムもあなたは連続的にプログラムを修正できない」(リグレッションテストの習慣はあるの? リファクタリングスキルはあるの?)

ほとんどの場合は、漸進的に今のプログラムを修正・改良していった方が得策なのだ。

@ スクラッチから書き直してもいい場合

そうはいってももちろんスクラッチから書き直した方が合理的な場合もある(書き直してはいけない場合も書き直した方が合理的だと思ってしまうわけではあるが)。

それは次のような場合だろう。

• ソースコードがない場合 (ディスククラッシュした。利用する権利がなくなった)。
• もはや開発環境も実行環境も手に入らず、移植も困難な場合。
• 個人的な趣味のプログラムの場合。
• スクラッチから書き直したプログラムに対して、また「スクラッチから書き直したい」という欲求にかられない自信がある場合。

本当にスクラッチから書き直した方がよい場合は止める理由はない。

さてこの記事をスクラッチから書き直したいと思う時がきませんように。

@ 参考

• Joel on Software
  • Things You Should Never Do, Part I - Joel on Software
• はじめからやり直したい症候群
• 最上の日々 - なぜ最初から作り直したくなるのか
• [を] アホでマヌケな米国(アメリカ)ハイテク企業

[ ソフトウェアプロジェクトマネジメント ]

• Joel on Software - 必読書 (2008-08-14)
• ナノパーセント日 (2005-10-26)
• 今日のさえずり - 納豆にオリーブオイル+胡椒 (2008-08-02)
• 個人目標設定における課題 (2006-02-06)
• Module::Build でソースパッケージング (2005-08-24)