ライブドアの不正アクセスポイントアップと楽天の自動巡回を防止する手段の考察

　最近、ライブドアの不正アクセスポイントアップという方法が問題になってます。
　要するに人気のブログ（サイト）から自分のブログを見えないように表示させ、カウントアップをはかるというもの。でもこれって、「見えちゃえば」、見えたものはカウントしても問題ないし、関係ないブログが急に表示されれば、非難ごうごうとなるので、そういうことも、そうそうできないでしょう。
　つーことで、今日は、その見えないものを表示させる方法(iframeの大きさ指定の無効化）をご紹介します。

　ついでに、ぜんぜん話は違うんだけど、楽天で問題になっている、自動巡回についての話題も合わせて、お楽しみください

---

ライブドアの不正アクセスポイントアップ

■■　方法

その方法について、くわしくは、「なんでも評定」さんの「livedoorBlogのランキングポイントは簡単に操作できてしまう」（ページ表示したら、ちょっと下のほうにスクロールすると、いろいろ書いてあります）がくわしいみたい。

■■　問題点

　で、ここの問題は、

「しかし、普通はアクセスが多いサイトの中に別のブログが表示されていたら不自然である。そこで、見かけ上、ブログが表示されないようにすることになる。」

　っていうことですよね。

　なぜなら、もし、アクセス数が多いサイトのなかに、別のブログが、ちゃーんと表示されていたら、それはそれで、ブログのカウントとして、上がってもいいことになりますよね。見えているんだから！！

　つまり、ここにかいてあるように、見えないのが問題！っていうことで、いいですか？

　なら、対策はあります。

■■　対応策

　＜iframe＞タグで幅、高さを０にしても、強制的に、ある大きさにすることができます。
　したがって、ライブドアのほうで、このjavascriptを入れてもらえば、ここに書かれているように
<iframe src="http://www.geocities.jp/xmldtp/ht_iframe1.htm" height="0" width="0"></iframe">
と、あるブログやサイトが書いていても、見えないようにはできず、ばっちり強制的に表示させることができます。

　参考例：http://www.geocities.jp/xmldtp/ht_iframe.htmここのページで、幅、高さ０と送っているのに、フレームが、みえてますよね。
　その理由は、http://www.geocities.jp/xmldtp/ht_iframe1.htm(SRC先)のところで、javascriptで

resizeTo(700,280);

と書いているからです。そうすると、この大きさになります。

　つまり、ライブドアBlogの場合、ライブドアさんが、宣伝なんかをつけるついでに、resizeToを、どっかに入れてくれるとOKなはず。

　ちなみに、javascriptを書くと最近のIE（WindowｓXP?)だと、情報バーでブロックされますよね。
　それの回避方法は、ここ
ht_iframe1.htmで、＜!-- saved from url=(0014)about:internet --＞とやってるところが、回避策となります。

---

次のお題

楽天の自動巡回の問題

これも最近話題になってます。

■■方法
　
　くわしくは、こちら

「巡回ソフトを使い、楽天広場内に大量の足跡を残し、
楽天ショップの商品をみなさんに買っていただこうと、
しているわけです。」

だそうです。
　これが、楽天にとって、いいことなのか悪いのか？の話は別問題として、巡回ソフトを使っている人かどうかをチェックする方法について、考える。

　チェックして、自動巡回の人は、足跡のよこに「自動巡回疑惑！」とか表示するかどうか、なーんてことは、ウィリアムのいたずらには、興味ないし、考えることではない。

■■　対応策

　アクセスログをチェックする。
　巡回ソフトであれば、同じ人が、短い間隔で、いろんなところを訪問しているはず。

　なんで、アクセスログをIPごとにまとめて、あるIPにおいて、短時間間隔で、いろんなところを訪問し、かつその人が楽天のメンバーだったらチェックするとかなら、楽天サイドでできるはず。

　ただし、この人たちが、楽天からみて、規制すべき人かどうかは？？
　自動巡回でも、結果として楽天市場のものが売れれば、楽天は、それはそれで、いいんでないかい？？

---

てなかんじで、今日は最近、ブログで話題のアクセスカウント問題を考えてみました。
　

この「ある「ハッカー」の顛末」面白すぎ！（を高橋メソッドで紹介）

この「ある「ハッカー」の顛末」

http://www.rubyist.net/~matz/20050420.html#p02

---

もう面白すぎ！

---

１２７．０．０．１ときて

---

オチは

---

想定の範囲内

---

でも

---

水戸黄門

---

的な予定調和な

---

オチに

---

最高！

---

以上。

---

TurboLinuxがオリジナルパソコンって言うじゃない！Web開発用とかあればいいのに

　ターボリナックスが、オリジナルパソコン事業というのをはじめたっていうニュースがでてました。

　まあ、そのニュースでは、「企業・法人は、イメージキャラクタ/ロゴやブランドカラーをあしらったユニークな形状のオリジナルパソコンにより、効果的なイメージ戦略やプロモーション用途としてのみでなく、アプリケーションのカスタマイズにより特定の機能に特化した専用パソコンとすることで」って書いてあるけど、きっと、キャラクターＰＣを中心に考えてるんでしょね。

　キティちゃんＰＣとか、
　ミッキーマウスＰＣとか、
　乙部綾子さんＰＣとか？？

---

　でも、本当に意味があるのは、Web開発用ＰＣとかで、Webサーバー機能と、開発環境、帳票出力環境などがプリンストールされていて、環境設定もある程度されていて、で、ドキュメントも入ってる。なんていうと、さすがＴｕｒｂｏ，技術力ある！っていう感じになるんじゃないかな。

　もちろん、ウィリアムのいたずらが以前指摘した、バージョンの相性も確認済み、前もってサンプルプログラムが動くことを確認してあって、サンプルも入っている状態で。

　まあ、入れるものとしたら、こんなかんじ（もう、入ってるものもあると思うけど）。
JDK
Apache
Tomcat
Struts

cocoon
FOP

eclipse（easy strutsつき）
Ant
CVS(またはsubversion）

UMLのお絵かきツール(argoＵＭＬとか？）

とかで、すぐに開発に入れるように、説明書もついてるやつ

---

　でも、ディストリビューターさんって、そういう開発のツールとかを一まとめにして、チューニングしてくれて売ってくれてないのよね。本来のディストリの仕事って、そういうことだと思うけど。。。

　って書いてると、「じゃあ、おまえつくって、どっかのサーバーに置いとけよ！」っていわれそうだけど。

最近話題のプレゼンテーション技術？なのか？高橋メソッド

　最近のプレゼンテーション技術（パワーポイントなんか使って行うもの）に「高橋メソッド」というのがあるそうです。
　くわしくは、こちら
　巨大な文字で、プレゼンしていく、新技法？？のようだ。

　この高橋メソッドで書いた例（日本rubyの会の説明）をみれば、その斬新さ？がわかります。（ただし、シートをつなげてあるようです）

　人気のすごさは、高橋メソッドをぐぐってみると、すでに「高橋メソッド の検索結果 約 247,000 件中 1 - 10 件目 (0.09 秒) 」と出るほどだ
　「高橋メソッド」の高橋さんは、日本Rubyの会のらしいが、日本Rubyの会をぐぐってみても、「日本Rubyの会 の検索結果 約 10,200 件」、ちなみにRubyの説明はこちら

　学校や会社でやったら、大うけするか、怒られるかのどちらかだろう
　ブログでやったら、こんなかんじになります（本家のブログでやってみた）

ブロッコリーとガンホーの新作萌え系ゲームのニュースで始めて知った言葉MMORPG

　最近話題のブロッコリー（「デ・ジ・キャラットにょ」とか作ってるところ、このブログで時々書く、「目からビーム」は、その「デ・ジ・キャラットにょ」で「でじこ」がいう言葉＆する行為）と、同じく話題のガンホーが、萌え系のＲＰＧを作ると話題が出てたけど、発表になりましたね。
[ゲーム]ブロッコリーとガンホー、ヘッドロックが3社共同で“萌え系”新作MMORPG

MMORPG？？なんだろうと思って、しらべてみました（ここ）

Massively Multiplayer Online Role Playing Game

うーん、フルスペルでかかれると、なおさらわかんないね。

最近の見積もりは、高く見積もるより、安くしないといけないケースのほうが多いと思うよ

　日経ソリューションビジネスの２００５年４月１５号の「熱血第三営業部」の記事８２ページで、システム開発の見積もりのところ、

「え、？今まで協力会社さんは、これで見積もってくれてたんですよ」
「バカにされてたんじゃないのか？この程度の資料しか出さないから、リスク分を積まれて高い見積もりだされてたんだよ」

　ってあるけど、これ、逆のケースのほうが、結構ある気がする。

　つまり、「ちゃんと見積もると、高すぎるといわれるので、逆にシステムを変えて、安い見積もりを出さないといけない。そのために、あまりにも細かい資料をもらうと困る」っていうケース、結構あると思う。

---

　具体的に話すと、たとえば、Webで会員管理のシステムっていうと、中小企業だと、４００万っていうのが、相場くらいじゃないかな。

　これは、システム規模の問題ではない。そのくらいしか、出せないのだ。

　会員システムなんていうのは、２、３年で、仕様変更、手が入る。したがって、２、３年で償却できないといけない。売上１０億の会社だと、情報化投資の相場は１％と言われるので会社全体で１千万になる。

　会員管理システムに、全部は投資できないので。。。というと四百万くらい？？
　受発注システムだと、もうちょっと大きくて１千万から２千万くらいもありえるかも（２、３年にかける経費を、半分くらい～すべてつぎ込む感じ）

　で、普通、Ｗｅｂシステムで４百万っていうと、Apache、PosgreSQLないしMySQLのフリーＤＢを使って、StrutsもしくはCGI(ActivePerl使用）で、ほとんどシステム費用をかけず、全部を人件費にして、１人月単価６０万程度の人を半年、ないしは、１００万程度の人を４ヶ月ってかんがえますよね。

---

　ところがー！です。システムを知らない中小企業だと、この費用、ハードソフト込みで、ＤＢにオラクルとかいいだすのですよ。

　おいおい、開発費、どーすんだよお！

　で、そー言う会社に限って、無謀な仕様をだすのです。

　４００万くらいだと、会員の仕組みが、そんなに難しくない状態で、会員の登録、削除、変更などが出来て、検索、会費の管理などができるという程度（画面と帳票あわせて１０～２０くらいかなあ）なんて、想像するけど、

・会員の仕組みが死ぬほどむずかしかったり、
・つーか矛盾してたり
　（１つの会員がいくつものカテゴリに入り、割引が何種類も考えられるとか）
・おいおい、そこまでこのシステムひろげるのかよお！

って言うケースが。。。あるのよね。

---

　そういう場合、その仕事、とらなくていいなら、適当に（適切に！）見積もりを書いてだすけど、どうしても取りたいとなったら、仕様を変えるしかない。

　なので、あんまり決まってないほうが、やりやすいこともある。

　ただし、こういう仕事は、営業がとってきたあとで、仕様を押さえ込んだはずなのに復活してしまったり、押さえ込んではいけない（矛盾がでる）機能を押さえ込んでしまったりして、結局、全機能作らないといけないんていうオチになったりするんだけどね。

PDAとリブレットと携帯、外出先のお仕事に使うには？（VNC、skype等比較）

東芝のノートＰＣ「Libretto」が復活するらしいという記事（ここ）があった。それと、本家のブログに書いたけど、ライブドアが公衆無線LANに参入するみたいだし、最近は、Skype for Pocket PCとか使って、ＰＤＡでSkypeができるらしい。

　そこで、ＰＤＡと、そのリブレットと携帯電話、外出先のお仕事につかうには、どれ！というのを考えてみました

---

■■　リブレットでおしごと

　これは、パソコンですから、問題ないでしょう。
　OSは、Windows XP Home Edition SP2っていうことだから、Office製品は、載せられるでしょう（どういうアプリがプリインストールされてるかは、記事からわからなかった）。
　Skypeもたぶん、大丈夫でしょう。
　そのSkypeや、インターネットについて、記事によると、「IEEE 802.11b/g対応の無線ＬＡＮ」が使えるそうです（すみません、無線ＬＡＮ詳しくないので、どういうのかは、わかりません）。
　ＶＮＣも、大丈夫でしょう。

　大きさ210×165×33.4mm(最薄部29.8mm)、重量 約1499g(リブレットDVDドック装着時) 、価格が問題ですな。

---

■■　ＰＤＡでおしごと

　これ、意外とできるのかも？？
　HP iPAQ rx3715(ipaqシリーズ）を基準に考えると、
　ＯＦＦＩＣＥ製品は、「Pocket Word、Pocket Excelの搭載で外出先での書類閲覧、作成、編集が可能です。もちろんPCのExcel、Wordとのデータ互換も可能なので、よりシームレスな環境が実現します。」だそうな。

SkypeでＰＤＡを使うには、Skype for Pocket PCが必要らしい。このページからダウンロードできるようだ。
すでに、ライブドアのSkypeのホームページでは、いろいろ議論されてますな。
ただし、スペックが
・Windows Mobile 2003 for Pocket PC
・400 MHz processor
・WiFi-enabled
らしい。

　無線LANは、「無線LAN（IEEE802.11b）機能とBluetooth® ver.1.1.機能を内蔵」だそうです。
　ＶＮＣは、どーなんだろう？？
　ちなみに、Pocket VNCというのがあるらしいが。。。
ザウルスでの話は、できそうっていうことは、前に書いた気がする。

　大きさは、もんだいないでしょ。

---

■■　携帯電話でおしごと

　まず、Skypeを使う前に、携帯なら、はなしちゃうでしょ。電話で。
　なので、これは、考えない。

　ＶＮＣについては、マイクロＶＮＣというのが、最近できたらしい。

　Brew対応なので、ＡＵですな。　

　これなら、パソコンを携帯で操作できるから、WORDだろうが、Excelだろうが、操作できる。。。のかなあ？？


　JavaのＶＮＣをIアプリあるいはVアプリっていうのは、どうなんだろう。開発できるのかなあ？まあ、画面のところはアプリ用にしないといけないのは当然だけど、問題は、どんなところにもパケットを飛ばすことができるのか？？（ＢＲＥＷは、どこのサイトでもＯＫのはず）。

---

しかし、ここで、最大の疑問がある。

そこまでして、外で、お仕事したいか？

XMLからJava（以外もOK)自動生成その３:DOMで、属性・テキスト・タグ名取り出し（２）

前のブログで書いた、「XMLを読み込み、ハッシュマップにいれよう」で使ったメソッドの説明です。

■■説明

以下のメソッドを使っています。

ノードから、タグをとりだす

　そのノードのgetNodeName()で取り出せます

---

ノードから、テキスト部分をとりだす

　そのノードのgetNodeValue()で取り出せます。

　ただし、ここで注意したいのは、<tag>値です</tag>というタグがあったとき、すくなくとも私が使ったJDK1.4.2では、tagタグのgetNodeValue()では、値を取り出せませんでした。この値は、tagタグの子ノードに入ってました。

　そこで、今回は、
　　１．子ノードが１つで
　　２．その子ノードのタイプがテキスト（Node.TEXT_NODE）
　のとき、<tag>値です</tag>の形とみなし、子ノードのgetNodeValue()した値を、そのタグの値として、ハッシュマップにいれています。

---

属性をすべてとりだす

　getAttributes()メソッドを使います。ノードリストが帰ってきますので、そのリストの中から、１個ずつノードをとりだします。ノードリストに何個、ノードが入っているかは、getLength();指定したノードを取り出すのは、item(何番目０スタート);で取り出せます。

　属性１個分のノードを取り出したらあとは、getNodeName()メソッドで属性名,getNodeValue()で属性の値が取り出せます。

---

ノードの型と、子どもを持っているかを知る

　ノードの型は、getNodeType()
　ノードが子どもを持っているかはgetChildNodes()
　ノードが属性を持っているかはhasAttributes()
メソッドでわかります。

---

これらを組み合わせて、昨日のプログラムはできています。

O/Rマッピング支持に宗旨替えしそうな、JavaのDBアクセス

　最近、JAVAでデータベースアクセスする際、O/Rマッピングというのが話題になってます。
　O/Rマッピングの意味は、ここでも見てもらうとしましょう。（っていうか、この絵が、気に入った）

　ただ、実務上、O/Rマッピングの目的としてあげられる、

・JDBCなどをみんなが直接さわるようなことをしない 　→データアクセスのオブジェクト(DAO)を経由する。 ・テーブルの名前が変わってもビジネスモデルに影響を与えない

などを実現するためには、O/RマッピングのHibetnateとかを使うのではなく、

実務上、こんなクラスをつくって、実現すると思う。

・データアクセスクラス(DAOに相当）を提供する 　　・そのクラスに検索条件をわたしたり、更新、削除情報を渡すのは 　　　　　ハッシュマップ、 　　　検索結果を返すのは、ハッシュマップの配列やVectorを使う

ていうのが、一般的だと思う。

　もちろん、こんな考え方でなく、EJBを使って、セッションBeanとエンティティBeanでやる手もあるけど、普通は、ただのクラスで、データアクセスクラスを作成する。そういう意味では、O/Rマッピングで言われるPOJOっていうことになるのかな。

---

　で、なぜそういうクラスで実現して、Ｏ／Ｒマッピングツールを使わないかというと
・そのほうがわかりやすい
・テーブル項目の仕様が変わったとき、setterやgetterを作ったり,
　クラスに変数を定義したりすると、複数の参照先で、それを見ていると、
　修正中にリンクできなくなる（テストできない、テストファーストにならない）
などの問題があるから。

　そこまでは、ぜんぜんOKっす。

---

でもね、問題もあるのよ。
（以下、妄想ということにしておいてください。こういう経験をしたかどうかは、ご想像におまかせっす）

　ハッシュマップって、値がObjectで、なんでも入れられるのよ。
　でね、データベースの仕様書にはNumber型になっていたりすると、その値をハッシュマップにいれるのに、ある担当者は、Longでいれてみたり、ほかの担当者は、Doubleでいれてみたり、まちまちなんていうこともありえるわけよ。。

　でもねでもね、いくら、すべてStringにすれば便利だからって、数字項目をStringで入れておく人って、いないよね。。。
　きっといないよね。。。うーん（；＿；）

ハッシュマップで、キャストのエラーになったら、値の型をしらべてみよう。 　それがいやなら、toString()して、全部文字列にしてから、考えよう。

　うーん、全部自動的にできる、O／Rマッピングツールに心ひかれたりして。そうすれば、担当者によっての違いはなくなりそう。つーか、こんなことExcelドキュメントから、自動作成してよ！そうすれば、おなじプログラム使えば統一するじゃん。

　でも、統一させたいだけだったら、全部、ハッシュマップに入っている値、toString()して、Stringにしてから使えば、安全なんだけどね。

XMLからJava（以外もOK)自動生成その２:DOMで、属性・テキスト・タグ名取り出し（１）

前のブログで取り上げた、パラメータと値のとりかたについてです。

---

今日のお題

XMLを読み込み、ハッシュマップにいれよう

前回はタグ名だけをとってきましたが、今回は、タグ名のほかに、属性やテキストの値もとってきます。
入力は、前回と同じです。

ハッシュマップへの入れ方

キー	値
#tag	タグ名
#child	子供があればYES、なければNO
#val	子供があるとき Vector vectorの１要素は、子供１つ分のハッシュマップ ハッシュマップの構造は、この構造 子供がテキストのとき<tag>文字列</tag>のとき その文字列 子供がなかったら<tag/>の形 null
それ以外 （アトリビュート名）	アトリビュートの値

　一応、その内容を出力してみました。

　なお、このプログラムでは、一番最後の子供のタグにのみ、テキスト項目を持つ形になっています。
　テキスト項目が任意のタグのところに入るようにするためには、拡張が必要です。
　次回以降に話すと思います。

---

■■　プログラム

import java.io.*;
import javax.xml.parsers.*;
import org.w3c.dom.*;
import java.util.*;

public class xmlReadTest {
	static	String	inFname = "testClass.xml";

	public static void main(String[] args) {

		try
		{
			//----------------------------------------------//
			//	Dom取得のためのお決まりの部分	  //
			//----------------------------------------------//
		      	// 入力ファイルを読み込み、Documentオブジェクトを取得
		      	Document doc = DocumentBuilderFactory.newInstance()
				         .newDocumentBuilder().parse(new File(inFname));


			//----------------------------------------------//
		    	// クラス名となる、ルート要素を取得して表示	  //
			//----------------------------------------------//
		      	Node root = doc.getDocumentElement();
		      	HashMap mp = null;

			//	ＸＭＬをハッシュマップに入れる
    			mp = nodeToHashMap(root);
    			
    			//	ハッシュマップの内容を、表示する
    			String[] key = (String[])mp.keySet().toArray(new String[0]);
    			for(int j = 0 ; j < key.length ; j ++)
    			{
    				System.out.println(key[j] + ":" + mp.get(key[j]));
    			}

		}
		catch (Exception e)
		{
			e.printStackTrace();
		}
	}

	/**
	 * ノードの中身を取得して、ハッシュマップに入れる
	 * @param oneNode	ハッシュマップに入れるノード
	 */
	private static HashMap nodeToHashMap(Node oneItem)
	{
		HashMap ret = new HashMap();
 
				//	子ノードがあるかないか
  		if ( oneItem.hasChildNodes() == true )
  		{
  			NodeList chNode = oneItem.getChildNodes();
  			if ( ( chNode.getLength() == 1 ) && ( chNode.item(0).getNodeType() == Node.TEXT_NODE))
  			{
  				//	子ノードが１個で、それはテキスト＝<tag>val</tag>の形
 				ret.put("#tag",oneItem.getNodeName());
  				ret.put("#val",chNode.item(0).getNodeValue());
 				ret.put("#child","NO");
			}
			else
			{
				//	子ノードがいっぱいある<tag><chtag>aaa</chtag><tag>
 				ret.put("#child","YES");
 				ret.put("#tag",oneItem.getNodeName());
 				Vector chVec = new Vector();
 				for (int j= 0 ; j < chNode.getLength(); j++)
 				{
 		  			if ( chNode.item(j).getNodeType() == Node.ELEMENT_NODE)
 		  			{
 		  				HashMap chMp = nodeToHashMap(chNode.item(j));
 		  				chVec.add(chMp);
 		  			}
 				}
 				ret.put("#val",chVec);
			}
		}
 		else
  		{
  				//	子ノードはない
				ret.put("#tag",oneItem.getNodeName());
  				ret.put("#val",null);
 				ret.put("#child","NO");
		}
  			
  			//	アトリビュートの設定
      		if ( oneItem.hasAttributes() == true)
      		{
      			NamedNodeMap attr = oneItem.getAttributes();
      			for (int j = 0 ; j < attr.getLength(); j ++ )
      			{
      				Node para = attr.item(j);
      				ret.put(para.getNodeName(),para.getNodeValue());
      			}
      		}
		return ret;
	}
}

■■　結果
#tag:testClass
#child:YES
extends:absClass
#val:[{#tag=komoku1, #child=NO, #val=9999}, {#tag=komoku2, #child=NO, arrays=*, #val=XXX}, {#tag=komoku3, type=long, #child=NO, #val=null}]

---

このプログラムで使った、属性、値の取得メソッドなどの説明については、次回以降にします（ながくなるから）。

Excelドキュメントからモデル駆動型アーキテクチャ(MDA)によるJavaソース自動生成を考える

　以前のブログで、ヒアリングからＵＭＬのドキュメントを作成、Javaのクラス作成までを半自動化で行う手順 として、「ＵＭＬシステム設計実践技大全―アッと驚く達人の技」という本を元にまとめましたが、UMLにおける、ソースコードの自動化という話題は、モデル駆動型アーキテクチャ(MDA)でもやっているみたいですね。

　ということで、Excelのドキュメント（仕様書）から、このMDAのツールに読み込めれば、プログラムのソースコードを自動生成できるんじゃないかと空想した（ほんとかいな？？）

　MDAのツールは、Java　Worldの５月号に、AndroMDAが紹介されていたので、これにしようと思った。
　どうも、javaWorldの５月号を読んだ限りでは、もし、そのExcelの仕様書が、XMI形式で書き出せれば、変換できそうだ。
　でも、XMI形式って、どんなの？？

　と思ったが、まあとりあえず、AndroMDAで、ソースコードを自動生成する方法をしらべた
　このブログにあった。

　そこを見て思った。モデリングツールが書き出すXMIを解析して、それと同じ形で、ExcelドキュメントからXMIが書き出せれば、自動生成できると。

　おお、モデリングツールをおとしてきましょう！
　ということで、ArgoUMLをダウンロードしてきた。

　夜も、おそくなった。
　今日は、ここまで。

（ちなみに、ブログは、朝、アップしているが、夜書いている。
　夜中に更新してしまうと、見る人が、少ないようだ）

Adobeが、Macromedia買収したよ(@_@!)

すげえー。とうとうAdobeが、Macromedia買収したよ(@_@!)
　とりあえず、以上。

でも、どこのニュースでもとりあげてくれない。すっげーことなのに！

流通XML-EDIのJava化計画：その４：モデルとXMLのずれ、危険な香りがする。撤収！

　流通XML-EDIのJava化計画？ですが、うーん、危険なものにクビを突っ込んでしたっまらしい。

　流通ＸＭＬ－ＥＤＩで、実際に、交換するメッセージが、概説書の後ろのほうに載っている。そこで、それを、ＸＭＬに書き直しているとき、手が止まった。

こんな項目があるのです。

伝票区分　伝票の種類をあらわすコード（発注伝票／返品伝票などの区分を示す）
納品区分　店直、センター納品の区分

　ちょっとまって？？
　概説書のどこにも、返品なんて言葉は出てこない。センターなんていう言葉も出てこない。
　つーことは、概説書に載っているモデルと、実際交換しているフォーマットがずれている？？

　危険な香りがします。

---

　こういう、データ構造から想定されるモデルと、実際の要求仕様で書かれた業務モデルが異なることは、結構あります。たとえば、こういうときです。

・要求仕様のときには、そんな業務を作らなくていいことになっていたが、急に、やっぱ作んないとダメ！ということになり、現場で対応した。

・要求仕様書では、カットされているが、現場の人間が、「それですむわけ無いだろう」と、こっそり入れている（想定の範囲内とか、折込済みとかＳＥさんが、よく言う言葉）。

この２つのケースが多いと思う（とくに前者）。
　で、とくに前者の場合だと、現場で部分的に対応するから、インターフェースが狂ったり、バグが出たりとなる。でも、流通ＸＭＬ－ＥＤＩの場合、国のお金で作ったから、急に仕様変更っていうのは、考えにくい。
　つーと、後者のケースかな？と想像されます。つまり、統一伝票にあわせないとまずいだろうっていうふうに考えた。

---

　まあ、いずれにしろ、要求仕様と、現場のプログラムがずれている可能性があるわけで、この場合、経験上言えることは、「このプログラムを元に作ろうとすると、デスマーチがおこる。捨てたほうがいい。」
　要求仕様とプログラムが正確に、またはほぼ合っている場合、論理的な矛盾はすくないので、これは、再利用してもＯＫです。

　でも、要求仕様とプログラムがあっていない場合、結果として、全体から見ると矛盾している可能性があります。もし、矛盾しているところがあると、矛盾＝嘘ですから、嘘を正しく見せるために、嘘を嘘で上塗りしていくしか、なくなります。
　結果として、嘘だらけになります。嘘を重ねて正直者になるのは、大変です。
　そのために無駄な努力が費やされるわけです（開発はデスマーチとなるわけですな）

---

　そういう場合、すなおに、さくっとプログラムを捨てるのが一番です。

　うーん、ウィリアムのいたずらも、ここで撤退したほうがよさそうです。
　ということで、このシリーズを期待していた人、ごめんなさい。
　でも、ウィリアムのいたずら、身の安全が一番です。

　ということで、この企画、ここで

　撤収！！

フレームワークのドキュメントが開発上、重要なんだけど、システム開発規約には。。

　昨日のブログで、、「乙部さんはいいんだよ、システム開発の場合、なんのドキュメントが必要なのさ！」という話について。

---

　システム開発のときにどのドキュメントを残すかということで、意外と大事なのに、渡されないドキュメントとして、「そのシステムで採用しているフレームワークがらみのドキュメント」があります。

　もちろん、Strutsとかの、標準的なものだけを採用している場合は、いいんです。なくっても。

　でも、Strutsだとしても、ＤＢとの接続のとき、O/Rマッピング「もどき」のことをやっている場合って、多いと思うんです。Hibernateとかを使わないで（なぜ使わないのかについては、後日書きます。予定未定だけど。現在、理論武装中）。
　ちなみに、「もどき」というのは、セッション部分と、実際にSQLを発行する部分を分けています。それをフレームワークで規定しているものをさします。

　そうやって、独自のフレームワークを使っている場合で、そのプロジェクトに途中から入った場合、プログラムを書こうとしても、どうやって書くのが正しいか、はっきりしません。
　とくにフレームワーク部分をライブラリ（あるいはjar)のバイナリの形で渡された場合、確認のしようがありません。
　サンプルプログラムを渡されても、そのサンプルと違ったこと、新しいことをやろうとしたとき、フレームワーク内でどう規定されているかわかんない。

　結局、「えいや！」と書いてしまい。。フレームワークに外れたりして、バグをつくりやすくしてしまったりするわけです。

　さらに、解析のときも、そういうドキュメントがあれば、プログラムの流れが分かりやすく解析しやすい。

---

　で、フレームワークのドキュメントなんですが、フレームワークは、プログラムの書き方だけでなく、画面構造、あるいは、設計の仕方まで規定してしまうこともある（Strutsとかね）

　ところが、今、ドキュメントの開発標準というと、たとえば、日経システム構築の３月号「のとはら先生のプロジェクト・マネジメント指南」P１２３に書いてあるのをみると、

■■プロジェクト標準
　　・共通
　　・プロジェクト・マネジメント規約
　　・システム開発環境規約
　　・システム開発規約
　　・システム運用規約

となってます。
　さらに、フレームワークに関係しそうな、システム開発規約に書いてあるのは、以下のとおり。

■■システム開発規約
　　システム開発方法論
　　要求定義・設計ガイドライン
　　ユーザーレビューガイドライン
　　ユーザーインターフェース設計ガイドライン
　　・画面設計
　 　・帳票設計
　　コーディング規約
　　テストガイドライン
　　セキュリティ設計ガイドライン

　ふつう、こんなもんだとおもいます。
　この中で、フレームワークについてかけそうなところは、「システム開発方法論」だけど、方法論のところに、まさか、クラスの継承の仕方やメソッドの内容までも書けず。。。

　ということで、フレームワークの内容が、分散してしまうんです。

　で、分散していればまだいいんだけど、コーディング規約をプロジェクトマネージャーが、なにもかんがえず、他のところからもってきてしまうと、このシステムのフレームワークについて、どうコーディングしていいかについて、書かれることが無く。。。
　なんてことになりかねない。

---

　もちろん、現場の人は、この問題を知っているので、フレームワークについてのまとめたドキュメントを持っているんだけど、いかんせん、プロジェクトマネージャーとかが、それがどれだけ大切かを知らないので（たんなる現場の資料だと思っている）渡してくれないことがあるのね。

　そーすると、たいへん、こまったりするわけです。

ライブドアのホームページ、さすが有名？IT企業だけあって、IT業界の問題点を踏襲している

ライブドアのトップページにいくと、上のほう（カテゴリ選択の上、ロゴの下の３つある文のまんなか）に、「ライブドア広報の輝くワケは？ 」ってありますよね。で、それをクリックすると、Livedoorデパートの、Toe Brights(トゥ・ブライツ）のところにいきます。
　なんじゃこりゃ？？何かの間違い？？トゥ・ブライツは輝いてるけど、広報の人とどう関係あるの？？

と思ってしまいますよね。

---

　多分、これ、ライブドアの人は、こう考えているんだと思います

１．	ライブドア美人広報といえば、乙部綾子さんのことであることはみんな知っている →　まあ、これはいいだろう
２．	乙部綾子さんがブログをはじめたことは知っている →　うーん？？ちなみに、そのブログはここ
３．	その乙部さんのブログで、トゥーリング（＝Toe Brights(トゥ・ブライツ））のことを照会した ここ。だから、みんな知ってるよね。 →そう思ってるのは、ライブドアの人だけ。 この乙部さんのブログが話題になったのは、１５日ごろ。 そのときには、この記事は、かなり下のほうに行っていたので、見てない人も多いはず。

　つまり、ライブドアの人は、乙部さんのブログのことをはじめから全部みているので、あたりまえのこととおもってしまうけど、途中から見た人には、なんのことだか、さっぱり？？っていうことになってしまいます。

---

　これ、システム開発なんかでもおおいよね。（っていうか、この前もありました）。

　システムをはじめからやっている人には、いったいどのドキュメントが大事なのかわからない。
　そこで、途中からシステム開発をお手伝いすることになった人に

　必要なドキュメントを渡さないで、いきなり

　　　　　プログラム書いて！

　といってしまうケース。


　いわれたほうは、「おいおい、そーいわれても、どうやって書いていいの？」となってしまう。

　で、結局、ソースコードやサンプルコードを参考にして、てきとーに書くというのが普通ですよね。
　当然、もらったソースコードと違うケースのプログラムを書く場合、規約から外れることもあるだろうし、サンプルがバグってたら、バグになっちゃうよね。

---

　本来、指示を出す側は、指示を遂行するのに必要な、重要なドキュメントを渡すか、それを説明しないといけないわけ。
　ところが、それが、仕事を指示する人は、自分でコーディングしているわけではない。なので、コーディングのときなにが重要なのかわかんない。だけど、毎日、なんとなーく流れて言う。

　なのであらたまって「重要なドキュメント」といわれても、
　（乙部さんの例でいうと「乙部さんがトゥーリングについて書いた記事」）
　どのドキュメントが重要だかわかんないし（自分でコーディングしてないから）、
　

　うまく説明もできない
　　（乙部さんの例でいうと、キャッチコピーを、「ライブドア広報の輝くワケは？」でなく、
　　　「広報の乙部綾子さんを輝かせる一品」かなんかにするとか）

　その結果、プログラムに統制がとれなくなり、システムに人を投入すればするほど、ずれていき、バグが入って、デスマーチになっていくと。。。

---

　おお、そう考えると、まさにライブドア、IT業界の問題点を踏まえているわけで、
　さすが、IT企業です。

　でも、このIって、InfomationのI？
投資(Investment)のI？
　まさか、いんちき(inchikiローマ字っす！)のIじゃないよね。きっと、たぶん。。自信ない。


P.S　ちなみに、「乙部さんはいいんだよ、システム開発の場合、なんのドキュメントが必要なのさ！」という方。。。まあ、こんど説明する機会があればします（その説明を、この下に、書いていたんだけど、長くなってしまうので、乙部さんファンの人がこのページをみたら、怒られそうなので、さくっと消してやめときました。）