新しいブログに引っ越しました

フリーランスになったのに合わせて（といってもかなり遅れましたが…）、自分のサーバにブログを開設しました。

新しいアドレスは「http://www.meibinlab.jp/nishijima/ 」です。


しばらく休止していましたが、これからはちゃんと記事を書こうと思っていますので、宜しくお願いいたします。

ご無沙汰しております

約3ヶ月間後無沙汰しております。
私のブログを購読されている方（がおられるかわかりませんが…）、すいませんでした。
ブログの更新をサボって何をしていたかというと、実は勤めていた会社を辞めてフリーランスとして独立してたりします。
フリーランスとして心機一転、別サイトにブログを移動させようと思っていたのですが、予想以上に手間取っているのでとりあえずアメブロで再開しようと思います(;^_^A
これに懲りず、また相手をしてやってください。宜しくお願いしますm(_ _ )m

シェルスクリプト（バッチファイル）を別ディレクトリからの起動に対応させる

シェルスクリプトやバッチファイルを書いていると、コマンドの中に相対パスで別のファイルを指定したりしてしまいます。
例えばシェルスクリプトと同じディレクトリにある"test.txt"というファイルを開くシェルスクリプトなら、単純に

cat test.txt

とすればよいように思うかもしれません。
試しに、上記の内容を記述したファイルを/tmp/test.shとし、適当なテキストファイルを/tmp/test.txtとして用意し、
自身のホームディレクトリより
/tmp/test.sh
として実行するとどうなるでしょうか。
きっとエラーになるはずです。
これは、シェルスクリプトの中で実行されるコマンド(cat)が、ホームディレクトリのtest.txtというファイルを開こうとするからです。

シェルスクリプトと同じディレクトリにあるファイルを開こうとするなら、一度シェルスクリプトがあるディレクトリに移動し、終了後に戻るという操作が必要です。
これをシェルスクリプトで記述するなら以下のようになります。

pushd `dirname $0` > /dev/null
（実行するコマンド）
popd > /dev/null

また、バッチファイルなら以下のようになります。

@pushd %~dp0
（実行するコマンド）
@popd

私は、シェルスクリプトやバッチファイルを書くとき、とりあえず上記のコマンドをおまじないとして書くようにしています。

注意： ファイルパスをオプションとして指定するようなコマンドを作成するときは、上記の手法は使えません

フレームワークの選定

仕事でPHPとJavaを使うことが多いのですが、最近フレームワークに不満が出てきました。
昔は「Strutsを使っとけば大丈夫！」とか無責任に考えていたんですが、今はどれも短所ばかりが気になってしまいます(^^;

PHPは小さなプロジェクトが多いので、適当なフレームワークで（俺様フレームワークでも？）大丈夫なのですが、問題はJavaで作ることが多い、ある程度の規模があるプロジェクトのときです。
数ヵ月後に1～1.5人年程度の規模のプロジェクトを予定しているんですが、アーキテクチャを考え中です。
個人的にはJBossのSeamsやSeaserのChuraに期待しているんですが、どちらもこれからですしね…。

EJBを採用するほどの規模もないですが、かといってStrutsは先が見えてるような気がしています。
とりあえず、JSF(MyFaces) + Faceletes + Spring2.0 + Hibernate (+ Annotations + EntityManager)あたりで趣味に走ってみようかと考えています。

ところで皆さんは、どのようなフレームワークを使われているんでしょうか？

これも中国クォリティ？

このブログには珍しく、技術関係ではない記事を書いてみます。

インターネットニュースを漁っていてショックを受けた記事がありました。
その記事とは、「中国で「ニセモノの塩」が氾濫 」というものです。
その記事によると、中国には化学工業原料の「亜硝酸塩」を食塩として販売している業者が存在するそうです。この「ニセ食塩」を長期間摂取すると中毒になるそうで、死亡者も出ているそうです。

以前にも同じような記事を見た記憶があったので調べてみたところ、以前のものは「人造卵 」（リンク先は中国語）でした。
私は中国語はさっぱりですが、どうやら中国では人工的に製造された人造卵が存在し、この人造卵を長期間摂取すると大脳にダメージを与えて痴呆症の原因になるようです。

これらのニュースを私たちは「対岸の火事」と思っていてはいけません。
厚生労働省のサイトにある国内における中国産冷凍ほうれんそう違反事例 に見られるように、粗悪な食品が日本に続々と輸入されてきています。
（現在はポジティブリスト制度で農産物に関しては改善されているようですが）

中国を敵視したくはないですが、このような事件があると考えてしまいますね…。

ドキュメントは必要？

傲慢SE日記さんの「ドキュメントは必要？ 」という記事を見て、私も思うところを書いてみたいと思います。
本当はコメントに書こうと思ったのですが、長くなりそうなので記事にしてみました。

私が以前いた職場ではウォーターフォールで仕事をしていたのですが、たしかに設計者に書かれたドキュメントには抜けや間違いが多く、結局はドキュメンとソースが乖離したものになってしまいます。
ですので私も、傲慢SEさんのように「どうせドキュメントには不備があってソースが正しいのだから、ドキュメントはいらないのではないか」と考えていました。

ですが、初めてプロマネと設計を担当（人数が少ないのでプロマネと設計を兼務しました）し、私のこうした考えを一変させる経験をしました。

そのプロジェクトのメンバは6人で、殆どのメンバがスキルに自信を持ち、殆どのメンバがドキュメントの作成を苦手としていました。
そこで私はメンバと話し合い、アジャイル手法の一つであるXP でプロジェクトを進めることにしました。
これでドキュメントを書く工数や製作工数が削減できると考えたのです。

結果から言うと、これは大失敗でした。
XPの各プラクティスに対して、次のような問題が発生したのです。（ここに挙げている問題点は私たちの未熟さから発生したもので、XPの問題ではありません）
  • ストーリーの不備による要求変更の増加
    プロジェクトの終盤にさしかかっても要求変更が相次ぎました。
    これは私が基本設計しているにもかかわらず、私が所属する会社が孫受けだったことが原因だと思います。このような立場では、顧客の常駐どころか対面も叶いません。
    プロジェクトの終わりのほうで知ることになるのですが、私たちが作成したドキュメントやプロトタイプは、プロジェクトの終盤になるまでエンドユーザに見せられていませんでした。定期的に元請のSIerに提出していたにもかかわらずです。
    この結果、プロジェクトの終盤になっても要求が変更され、その結果仕様変更が相次ぎました。
    また、ストーリーが明確でないため、メンバは最後まで仕様を理解しませんでした（理解しようともしませんでした）。
  • 反復形開発による仕様変更の増大
    XPではドキュメントで顧客にコミットメントを取らないため、必ずといっていいほどプロトタイプを公開したときに仕様変更を要求されます。これは間違ったことではなく、本来、XPは「仕様変更を受け入れよう」という考えのもとに作られているのだと思います。
    ですが、このプロジェクトでは仕様変更するたびに、「なぜ俺が作ってから仕様変更が発生するんだ」とメンバから不満が続出しました。
  • テスト駆動開発の形骸化
    最初はユニットテストをきっちり行っていたのですが、仕様変更がある度に徐々にテストケースと仕様が食い違うようになり、最終的には誰もテストケースを更新しなくなってしまいました。
    結局、メンバは（目先の）工数削減のためにテストを省略してしまったのです。
    その結果、品質は目に見えて低下していきました。
  • YAGNIを取り違えたやっつけ仕事の増加
    YAGNIとは、「You Aren't Going to Need It.（今必要なことだけ行う）」ことです。
    これは私は、「将来必要になるかどうか分からない機能を今作りこむのはやめよう」ということだと思っています。
    これをメンバは、「エラー処理も今は必要じゃないから作るのはやめよう」と考えたようです。このため、ソースコードには大量にTODOとかかれたままでエラー処理を考えられることなく作られていきました。
  • ドキュメント工数の削減の失敗
    ドキュメント工数を削減できると考えていたのですが、結局納品物として、基本設計書、画面設計書、テスト成績書等、普段作っているものと同じだけのドキュメントが必要でした。
    それも検収の関係上から、プロジェクトの中盤で完成したドキュメントの提出を求められました。
    結局、「ドキュメントを書かなくてもよい」ということにはなりませんでした。

これらの問題点は、単純にプロジェクトがアジャイルプロセスに即していないだけだったかもしれませんし、私やメンバの力不足があったのは確かです。ですが、私はこれを機に仕事の進め方を考え直すこととなりました。
その後に読んだある本（題名は失念してしまいましたが、確かスティーブ・マコネルの本だったと思います）（Joel Spolsky の「ジョエル・オン・ソフトウエア」でした）に、ドキュメントについての重要性が書かれていました。
内容も詳しくは忘れてしまいましたが、その本に学ぶところがあり、私はウォーターフォールを適用すべきガイドラインと、ウォーターフォールを適用する場合の注意点を次のように考えています。（これらのポイントは私の中でまだ未完成ですので、これからも変えて行きたいと思っています。）

ウォーターフォールを適用すべきガイドライン
  • お客様にアジャイル手法を受け入れてもらえない場合
  • 製作者が働いている会社が元請ではない場合（製作者が元請のオフィスに常駐している場合はOK）
  • 製作者の技量が低く、また教育するだけの余裕がない場合
  • アジャイル手法が理解できていないメンバが半数以上いる場合
ウォーターフォールを適用した場合の注意点
  • フェーズごとにお客様に確実にコミットメントを取ること
  • 期限だからといって、完成していないのに次のフェーズに移行しないこと
  • ドキュメントを書く人はドキュメントを書くスキルを持っていること
  • ドキュメントの保守に専任の担当者をつけること

リストの中でも太字にしましたが、ウォーターフォールの中での問題点の一つは、「ドキュメントを書くスキル」の必要性が見過ごされていることだと思います。ドキュメントを書いた人はドキュメントの読者が理解できない場合、往々にして「読む人の頭が悪い」のが原因だと考えてしまいがちです。ですが本当にそうでしょうか？私は、ドキュメントの書き手が悪い場合のほうが多いと思っています。
ちなみに、ウォーターフォールを適用した場合の注意点は、先述の本と「アジャイルソフトウェア開発の奥義」に学ぶところが大きいです。

最後に、私が傲慢SEさんと同じような状況に置かれたときにとった行動は、「ドキュメントを読んで理解できない点や矛盾点をリストアップして送りつける」というものでした。
設計者のプライドを傷つけないよう、文句をつけるというより、単純に分からないとか論理的に矛盾しているというスタンスをとるように気をつけました。
そのリストで相手が非を認めた項目については、早急にドキュメントを修正してもらうようにしました。
この方法が正しいかどうかは分かりませんが、ウォーターフォールの下流工程を担当する上での一つの対策だと思っています。

Joel Spolsky, 青木 靖
Joel on Software

ロバート・C・マーチン, 瀬谷 啓介
アジャイルソフトウェア開発の奥義

一括ダウンロードソフトを拒否する

先日、管理しているサイトの負荷が増えてきたので、一括ダウンロードソフトによる画像へのアクセスを禁止したいという相談を受けました。
以前より、「リクエストヘッダのUser-AgentにMozillaが含まれていないブラウザからのアクセスは禁止する」や「Refererが同じサイトでないアクセスは禁止する」といったことはよく行われていると思います。

ですが、これらの方法には問題があることが分かりました。
まずUser-Agentを見る方法ですが、ブラウザによってはUser-Agentに「Mozilla」が含まれていない場合がありますし、最近のダウンロードソフトはUser-Agentを偽装する機能を持っているようです。
また、Refererを見る方法は、ノートンのセキュリティソフトを使っている訪問者を弾いてしまう可能性があります。

そこで別の方法を考えることにしました。
究極的には「同一IPアドレスからの異常な連続アクセスを拒否する」という対応が一番だと思うのですが、レンタルサーバではWebサーバ側で対策を行うことができません。
PHPなどのスクリプトを経由することも考えたのですが、それでは負荷が大きくなってしまい、本末転倒になってしまいます。
そこで、Cookieを使ってみることにしました。

具体的な流れは次のようになります。
１．トップページ（もしくは画像へリンクしているページ）に以下のようなタグを追加する。
<meta http-equiv="Set-Cookie" content="access=true">
２．画像（や一括ダウンロードソフトのアクセスを禁止したいファイルがあるディレクトリ）に以下のような.htaccessファイルを設置する。
<FilesMatch "\.(jpg|jpeg|wmv|avi|mp3|mp4|scr|exe|lzh|zip)$">
SetEnvIf Cookie "^access=" accessed
Order deny,allow
Deny from all
Allow from env=accessed
</FilesMatch>

これで、１で設定したページをブラウザで一旦表示させない限り、２で設定したディレクトリにある画像などのファイルへ表示できなくなります。
ブラウザがCookieを許可している必要があったり、Webサーバが.htaccessファイルを許可している必要がありますが、この設定で大半の自動ダウンロードソフトを弾けるのではと思います。

参考：
参照元 (リファラ) が遮断され、Web サイトが正しく表示されない (Norton Internet Security 2003/Norton Personal Firewall 2003)

私が勉強をする理由

傲慢SE日記さんの「何故SEは勉強をしないのか？ 」というエントリーに影響を受けて、私の考えも書いてみることにします。

仕事に対する姿勢として、社会人は大きく２つに分かれると思います。
一つが、「生活は仕事中心。お金をもらって仕事をするからには責任を果たすべき。」派で、もう一つが、「仕事はあくまでお金をもらう手段。仕事以外で人生を充実させるべき。」派です。

私の少ない経験の上での話ですが、ソフトウェア業界は後者の方のほうが多いようです。
以前私がいた職場で働いている方の過半数は、仕事は会社にいる間だけで十分で、家に帰ってから勉強するなど考えられないようでした。
人生は仕事が全てではないので家にいる間は家庭や趣味を大切にしたいのでしょうし、私はその人の考え方を否定するつもりはありません。

ですが、やっつけ仕事で建てられた家には住みたくありませんし、二日酔いの医者に掛かかりたくないのは私だけではないはずです。
同じように世の中の大半の人は、責任を持って仕事をしていない人が作ったソフトウェアにお金を払いたくないはずです。

世の中には、努力なしで仕事を完璧に遂行する天才がいるのかもしれません。
残念ながら私はこのような天才ではありませんが、凡人なりに責任を持って仕事をしているので、業務時間以外でも勉強を続けるしかないのです。