Ryuzee.com

あなたのうつ病度診断結果 

あなたのうつ病度診断結果

ヘルスチェック

ということでまだ大丈夫（ｗ
しかし疲れた。まだまだ続く。

梅屋敷の町工場 

昨日アド街を見ていたのだが、梅屋敷の町工場の社長（社員６人だが、シェアも技術もすごい）いわく

「利益を追求するのではなく、技術を追求したい」

すばらしい。社長が言っていたときに、偉そうでもなく、当たり前のように普通に言っていた。その精神が体に根付いているからだろう。

小メモ 

最近やっていることのいくつかのメモ。

SELinuxを無効にする

/etc/selinux/configで、SELINUXをdisabledにしてサーバ再起動すれば良い。

yumでproxyを使う

/etc/yum.confにおいて

VMWareで、e1000_clean_tx_irqエラー

e1000_clean_tx_irqというエラーはNICで発生しているエラーでモジュールとしてはカーネルでロードされているドライバだ。
新たにVMWareにOSをインストールした際に、pingやらネットワークに関係するコマンド叩くと、すべてこのエラーが出ていたのだが、解決。

VMWareの設定で仮想OS起動時にNICをActiveに設定すれば良い（するの忘れてた・・・。かなりアホ）

それにしても、NICがActiveでないときにこのエラーってのは想像つかなかった。

何故オープンソースを利用するのか 

会社で真面目に生産の構造改革をしないといけないミッションを背負っているのだが、なかなか真面目に文書化する時間が無いので、とりあえずブログに書きなぐっておくことにする。
―――――――――

俺自身、商用のソフトウェアよりオープンソースを利用することが非常に多いのだが、特に最近、顧客の要望にあったオープンソースのパッケージソフトを導入するケースが多くなってきた。
どのような判断を行った結果、商用パッケージやスクラッチ開発ではなく、オープンソースパッケージを選択したのかという点について述べておきたい。

一点注意としては、ここでいうオープンソースパッケージとは、基本的にはフロントエンドに配置されるアプリケーションの実態としてのパッケージである。それら自身を構成するミドルウェア(apache、MySQLなど)やOS(Linux)や開発言語(PHPなど)を指しているわけではない。

俺らが仕事を受注する際、顧客の中では当然やりたいことがおおよそ決まっている。
このやりたいことの内容によってスクリーニングが行われる。

顧客の業務のコアコンピタンスに関わることだったらNG

顧客の本業に対する投資であり、顧客が存在するための差別化要件であるから、ここではオープンソースのパッケージは相容れない。
　例えばオープンソースの株式自動売買システムがあったとして、少なくともそれを顧客にそのまま導入することは出来ない。まぁそもそも俺はそんなシステムは作りたくないけど。
　

コミュニケーション、ナレッジマネジメントに関することだったらOK

コミュニケーションというのは、どの会社でも必ずやらなければいけないことだ。コミュニケーションプラットフォーム上で必要とする機能はどこの会社も大差ない。こういうのは必ずオープンソースパッケージが存在するし、思いつく限りの必要な機能が先についている。こういうケースはプラットフォームをどう使うのか、というのが重要であって、プラットフォームを多額の投資をかけて自作する必要はない。
　この手のパターンのソフトウェアには、グループウェア、FAQ管理、wiki、チケット管理、ブックマークなどがある。
　

プロセスを定型化するものだったらOK

例えばWebサイトで顧客からアンケートを取りたいとか、CMSでサイトを管理したいとか、ブログ(コミュニケーションに近いが)。
　この手のパターンもOK。何故なら、それらを使って何をするかの方が重要であるからだと考える。
　アンケートであれば、アンケートを取る事によって差別化できるわけではなく、取った結果をサービスに反映することで差別化できる。
　CMSもしかりで、CMS自身によって差別化できるわけではなく、あくまでコンテンツによる差別化だ。
　

まずはこのような判断を行い、オープンソースパッケージの適用可能性がある案件かどうかを判断する。
しかし、あくまでパッケージソフトであるから、顧客の要件によってはカスタマイズの必要があったりするかもしれない。

このような場合でオープンソースを適用しない方が良いケースとしては、顧客がカスタマイズの要件を相当数出してくる場合。この場合さらに後から後から色々なカスタマイズ要件が出てくることが容易に想像がつくため、トータルコストを判断するとオープンソースパッケージの適用を行わない方が良いかもしれない。カスタマイズすればするほど、別プロダクトへと分岐していくため、バージョンアップも容易に出来なくなる。
また上述の通りだが、コアコンピタンスに関わらない箇所で過大なカスタマイズをすることは投資効果としてはお勧めできない。これを理解できないような顧客に対してはオープンソースパッケージは向いていないと思われる。

なお、本文でスコープ外にしたミドルウェアレイヤーのものや言語のフレームワーク等についていえば、俺にとってはそもそも使わない理由が無いので顧客が明示的にOracleとJAVA使ってくれ～、とか言わない限りデフォルトでPHP+Mojavi+MySQLとかRuby+Rails+MySQLとかになる。

何故生産性があがったのか(身近な事例からの考察) 

会社で真面目に生産の構造改革をしないといけないミッションを背負っているのだが、なかなか真面目に文書化する時間が無いので、とりあえずブログに書きなぐっておくことにする。
―――――――――

俺自身の身近なある運用案件を例に考えてみる。

その案件はとあるサイトの運用だったのだが、どのような運用をしていたかというと、

• 体制は各階層に分離され、html製作者と画像製作者などは分離された分業制で運営
• 顧客からの指示を各階層に伝達するため、全案件で指示書を電子媒体で作成しそれを元に作業
• 要件、スケジュール等の重要情報の伝達は電子メール

結果として、以下のような問題があった。

• コストに見合わない大量の要員の投入
• 見えない納期
• イマイチな品質

なんでこんな問題が起こったか、という理由だが、俺の中ではかなり明確である。

• 運用案件であり、日々要件が追加されるにも関わらず、ウォーターフォール式に案件をコントロールした。これにより、各工程間でのオーバーヘッドが増え、ベルトコンベアの先まで仕事が流れてこない状況になった。
  必然的に、手前の工程のベルトコンベアを流すために、そこを手当てする人を増やして対応せざるを得なくなったが後工程の人を減らせるわけではないので、問題が起こるたびに人が増えていった。
  人が増えるということはコントロールのコストも肥大化するということで、どんどんコストに見合わなくなっていく。
• 運用案件について言えば、本来、契約金額は成果物の量もしくは労働時間をもとに決まるはずである。この案件では本来4人程度の要員で回すことを見込んでいたのだが、ピークでは10人以上になってしまった。この時点で金銭的なリスクは膨大なものになっている。もし要員の人数で契約しているのであれば、こうなる前に手当てがなされるべきであった。
  また成果物ベースでの契約だとすると、見積もりのミスということも考えられる。もし見積もりのミスでないとすると、生産性は一般と比較して25%ということになってしまう。これで利益が出る筈がない。
  後は、納期回答も出来ないような混乱の状況下では、顧客の要望をすべて受け入れざるを得なかった、という可能性もある。しかしながら金額が決まっているということから、最低限契約金額内で対応できる案件なのかそうでないのか、は判断を行う必要があったはずだが、マネージャはそれを放棄していたと思われる。
• 電子的なコミュニケーションに頼ったため、多忙な部分への意思伝達が遅延してしまい、また本来関係があるはずの人が自身に関係ない連絡と見なして、認知しなかった状況が発生。必要な進捗状況すらもマネージャにあがってこなくなる。当然納期の回答なんて出来るわけがない。
• ベルトコンベア式に分業したため、品質の保証範囲が個々のコンポーネントまで単位化され、全体最適かどうか（＝顧客の視点で適切なのか）を気にすることが出来なかった。そもそも大量のことを早くやらねばならなかったため、品質のチェックまで手が回っていなかった。

さて、これらの問題は、色々な人の努力によって解決された。どのような対応を行ったかというと

• コミュニケーションは電子媒体ではなく、全員集めて対面で行う方式に変更
• 分業モデルを廃止し、機能単位に分離した上で、セル生産に変更

これによって、最後は当初見込んだ人数である4人より少ない人数に収束し、顧客満足度も向上した。

最初の１点の対応は実はアジャイルでいうところの
・プロセスやツールより人と人同士の相互作用を重視する。
　→文書化を含めた開発プロセスより対面のコミュニケーションを重視する。
のそのものズバリである。２点目に関して言えば、近来話題になる、ソフトウェアセル生産モデルの適用ということになる。またアジャイルでいうところの「包括的なドキュメントより動作するソフトウェアを重視する」にも該当する。ソフトウェアセル生産については、松本吉弘先生によって様々な研究が進められているが、まだ多様な表現が出来そうな分野といえる。
ソフトウェアセル生産については、俺自身が関わる案件については、必然的に（＝他の人に振ろうにも人がいない、プロトタイプからの開発なので、外注に出しにくい、動くものを先に作らないと要件が決まらない）セル生産であるが、セルの単位にカプセル化されたものについては、個人に責任が委譲されるため、やる気が出やすい、という利点はある。もっともカプセルの単位が大きすぎると、リスクが顕在化した際には取り返しがつかない、ということも考えられるため、この辺のコントロールについては検討の余地があろうと思われる。

参考リンク
アジャイル開発マニフェスト
アジャイルとは
アジャイルとは

テストは続くよどこまでも 

会社で真面目に生産の構造改革をしないといけないミッションを背負っているのだが、なかなか真面目に文書化する時間が無いので、とりあえずブログに書きなぐっておくことにする。
---
アプリケーションは生き物なので、生きている限りテストしないといけない。

よくあるのが、５年も１０年も脈々と受け継がれているコードがあって、当然それを作った人はもういない。仕方ないので機能追加をするたびに影響調査という名の高い金を取り、その上でやっとコードの修正をし、最後に自信なさげにテストしてリリースするケース。俺らの会社でもよくある（というかほとんどがそんな感じだ）。

こんなとき自動化されたテストがあれば相当にマンセー。

一度書いたテストコードは何度でも実行できるから、自信なさげだろうがなんだろうが手を入れるたびに毎回全部自動でテストを実行すれば良い。アプリケーションの要件が変わった場合は、まずテストを修正する。テストの修正が終わったら、コードには手をいれずに取り合えず実行して、テスト結果がNGになることを確認してから要件にあわせた開発を行っていけば良い。テストコードの精度によるが、こうやることで予期しない他の画面のデグレードも防げる可能性が高い。

また一方で、テストの手順も含めて自動化するため、自動化されたテストを作り上げるまでの時間は多くかかったとしても、以降はテストに所要する時間が下がっていく傾向にあるのだが、一方で人手によるテストは機能追加によって常に所要時間が増加していく傾向がある。この点もマンセーのひとつ。あとは、人が変わってもテストコードで担保すべき要件がはっきりしているから、なんか特殊な隠し機能や要件もテストコードで明らかになり、引継ぎ漏れによる品質劣化も防げる。

自動化テストは別にアプリケーションのみに限った話ではなく、静的なWebページだって適用できる。
例えばサイトのURLリストを用意しておいて、ページ毎に、禁止用語が入っていないか、copyrightが正しいか、404になっていないか、など様々なテストを自動化できる。

俺がテストを作っているパターンはこんな感じ

1. クラス単体のテストケース
2. 画面側の画一的な確認のテストケース
3. 画面側の操作（パラメータ入力し、送信した結果が正しいか）

これらに分けている。すべてでユニットテスト用のモジュールを使い、また3のケースのみSeleniumなどを使いJAVASCRIPTの動作まで自動で再現させている。2番目と3番目のケースでは、テストケースに失敗した場合のみ、画面のエビデンスを自動で保存しておくようにWeb用のユニットテストクラスを継承した自前モジュールを使っている。

なお、自動化テストコードも必ずバージョン管理が必要なのは言うまでもない。その場限りのテストコードでは、時間がたつにつれてファイルサーバの片隅にうずもれて、そのテストが実行されなくなる可能性もあるし、誰かが同じテストを書いてしまう危険性もある。

そういう意味では、そもそもまともにソースコードのバージョン管理もしないような環境で効率化しようってのは、裸足で剣山の上を歩くようなもんだ。

やってはいけない実装 

いま、とある案件でPHPのソースをガシガシ触っている（俺、ホントにコーディング好きだねぇ）。
過去に協力会社に発注して作ってもらったもののバージョンアップを重ねているのだが、今日触った箇所に大きな問題があったのでメモしておく。

まずはソース。

こんなのありえない。
具体的な問題として

• そもそも常にTRUEが返される。
• クラス変数以外のデータ変更が行われており、その他のクラスにおいてこのセッションデータの存在が前提になっている。このようなケースでは、グローバル変数としてセッションを直接いじくるのはNG。本当は状態管理用のクラスを用意して、そいつに値をセットし、セッション内ではそのクラスのインスタンスを持ちまわるのが良い。百歩譲って、この関数ではデータの取得のみを行い、取得したデータを戻り値として返すのみとし、呼び出し元のコンテキストでセッションにセットするならぎりぎり許容。
• この実装だとユニットテストがしにくい。

のような問題がある。

XAMPPでの嵌りメモ 

ローカルではXAMPP使っていて、Eclipseから色々叩いているのだが、嵌ったのでメモ。

XAMPPに同封されているPHP4は--with-opensslでコンパイルされていないので、以下のようなコーディングは利用できない。

こいつを実行すると

てな感じでエラーになる。

これの何が不便かっていうと、PHP4の案件で、ユニットテストを使うときにSimpleTestのWebTestCaseがSSLで動作してくれない。くそ。
PHP4の寿命は今年8月だった気がするので、そろそろ真面目に捨てろ、ということだな。

PHPでユニットテスト 

CakePHPなどで使われているSimpleTestを使ってみる。Eclipseのプラグインもあるし、PHP4、PHP5のどっちでも動く。

1.入手

sourceforgeから入手する。

2008/1/15現在の最新バージョンは
simpletest_1.0.1beta2.tar.gz
simpletest_1.0.1beta.eclipse_0.2.1.zip

2.配置
SimpleTestはどこに配置しても良いのだが、パスを通すのが面倒なので、PEARディレクトリ直下に配置してみた。
eclipseのプラグインは解凍して、eclipseのインストールディレクトリに上書きする。

3.eclipseのプラグイン設定
ウィンドウ(W)→設定(P)で設定画面を開き、左側のSimpleTestの項目を選択する。

4.試してみる
あとはテストケースを作成し、右クリックして、実行→SimpleTestを選択すれば良い。

テストケースのサンプル

こいつには呼び出し元の記述は無いが、直接テストとして呼び出せる。
また、呼び出し元として、以下のようなソースを書いても呼び出し可能だ。

eclipse上から何度でもテストできるからリファクタリングしやすいね。

eclipseからsftpやftp 

もうWinSCPとか使って開発機にコピーするのさえ時間が勿体無いわけですわ。同じ作業の繰り返しだしさ。
ということで、eclipse上から済ませてしまうためには、SFTP Plug-in for Eclipse というプラグインがあるので、こいつを使う

＜インストール＞
ヘルプ(H)→ソフトウェア更新(S)→検索およびインストール(F)の順に選択し、新規リモートサイトで下記を指定する。

＜使い方＞
eclipseのエクスプローラ上で右クリックした際に表示されるエクスポート(O)というメニューを利用する。

1.まずエクスポートに利用するプロトコルを選択する。FTPやWebDAVも使える。

続きを読む »

« 前の記事 

日記 PHP オープンソース インストールマニアックス IIS Trac MySQL Perl Linux Agile・生産性向上 wordpress フリーソフト 自宅サーバ 書評 ブックマーク phpMyFaq TraM Plugin 早起き Delphi apache CakePHP Firefox Ruby eclipse セキュリティ プラグイン アジャイル mojavi Subversion Ajax/Web2.0 SQLServer Zope サーバ フレームワーク phpBB 仮想化 PostgreSQL OpenVZ scuttle CMS 文字化け 自宅 翻訳・日本語化 ApacheDS LDAP Excel 生産性向上 CodeIgniter XAMPP hacks taskfreak 修正 言語ファイル Ajax SBM ダウンロード HTML::FillInForm mod_security 情報共有