ビルゲイツが出演中、ウィンドウズが目の前でブルーバックとか。。。

昨日と同じく、デスクトップにあるネタの整理
（なので、何の脈絡もありません）

透過PNG画像によるWEBデザインテクニック集
http://phpspot.org/blog/archives/2007/05/pngweb.html
ほー。。。

JavaScript: 触って分かる公開鍵暗号RSA
http://www.faireal.net/articles/8/01/#d40204
説明がわかりやすいです。PigPGP 0.2.3 日本語版を使ってるみたい。

1.4.5 特徴抽出
http://www.jpo.go.jp/shiryou/s_sonota/map/denki02/1/1-4-5.htm
特許庁の技術分野別特許マップの一部。技術分野別特許マップって、よくまとまってるよねー

放送事故　ビルゲイツがウィンドウズ壊す
http://vision.ameba.jp/watch.do?movie=193727
注意：上記サイトをリンクすると、読み込み後、すぐ音が出ます。

ビルゲイツの目の前でブルーバック（＾＾；）

アップルによる著作権２．０も、起こりえるかも？

ここのニュース
アップル、文化庁を激しく非難 「日本の著作権行政、消費者を無視している！」「文化庁、もはや著作権行政運営の資格なし！」
http://blog.livedoor.jp/dqnplus/archives/984514.html
（元ねたは、ここ）
によると、（以下斜体は上記痛いニュースからの引用）


私的録音に関する著作権者への補償金支払いをiPodなどのデジタルオーディオプレーヤーにも義務づけようとする、いわゆる「iPod課金問題」に対し、アップルジャパンが内閣官房に提出した意見書の全文が首相官邸のサイトに公開された。アップルはこの制度には科学的根拠がないとして、即時撤廃すべきと強く主張している。


そして、その補償金制度の即時撤廃を主張する根拠なんだけど、
５つ上げているけど。。。

１つめは、

1つの家庭で同じCDなどの著作物を2枚、3枚と買う可能性は極めて低い。

（中略）

CDの販売料金に加えてさらに料金を徴収するのは二重課金にあたる

そ、そーだよねえ（＾＾；）

さらに。。いくつかあげた後、


アップルが世界最大のデジタルコンテンツ流通企業であるというものだ。iTunesを通して販売されている楽曲は累計20億曲におよび、2006年度には12億曲を販売したと紹介したうえで、「（アップルは）iTunesからの売上から世界で最も著作権料を著作権者に納付している企業である」としている。


えー、言い換えると、世界的に見たら、ミュージシャンに著作権を支払っている団体はアップルであり、JASRACではない。。っていったら、JASRACの存在価値は。。。（＾＾；）

でも、もっともな主張だ。。

そして、さらに、

はなから『結論ありき』の審議会運営をする著作権事務局には真摯な姿勢は微塵も感じられず、もはや公平公正な著作権行政を運営する適切な省庁とは言い難く、速やかに著作権行政を他の省庁に移管することを強く望む」（アップル）と訴えている。


と、言い切ってしまった。。。言っちゃいましたね（＾＾；）
さすがだ。。みんな思っていたことを言い切ってしまう、
アップルは、さすがという以外ない。。

これで、もし、アップルが、アメリカの政府に働きかけて、日本への年次改革要望書に、この著作権問題を載せるようにしてしまったら、政府は、JASRACは、どーなるんでしょう。。。

アップルなら、そこまでやっても不思議はない。。。
でも、そしたら、JASRACは解体され、著作権はまったく違う仕組みになっていくんでしょうね。。

アップルによる著作権２．０？

開発の初めから順番に書いていってみる その５５：プログラミング（１７）入出力の自動生成５

　シリーズ「開発の初めから順番に書いていってみる」の続きです。
　設計手順には、要求分析、外部設計、内部詳細設計・プログラミング、単体テスト、結合テスト、総合テスト、運用テスト及び運用とあります。
　現在プログラミングです。
（プログラミング以前は、ここ http://www.geocities.jp/xmldtp/index_kaihatsu.htm）

　プログラミングでは決定表と自動生成のお話をします。
　今、DB入出力の自動生成をやっています。

　DB入出力は、JDBCで行うのですが、JDBCアクセス部分は、
　　execute
　　selectExecute
　で行い、それは、ここで説明しました。

　その上の部分として、テーブルごとに用意した、
　　・select
　　・update
　　・insert
　　・delete
　メソッドから、SQLを発行し、executeとselectExecuteを呼び出すという話は
　ここでしていて、現在selectの中のwhere句のところまできました。
　今回、そのWHERE句の作り方です。

---

■WHERE句について－仕様

　で、SELECTの場合、

　SELECT 項目名,・・・ FROM テーブル名 WHERE 条件文・・・

　となるという話でしたが、すべてのWHEREを自動生成させるのはたいへんです。さらに、WHEREのあとにGROUP　BYとかきたら、どーすんのか？という話があります。そこで、このようにします。

・今回自動生成するのは、＝で結ぶ条件のみとする
・そうでないものは、項目名を*zyokenとして、WHEREのあとの条件文
　（ORDER BYやGROUP　BY、HAVINGから副問い合わせまで全部）
　を全部書く
　　→Vectorのなかに、１ハッシュマップあり
　　　その１ハッシュマップのキーが*zyoken

そして、昨日の条件
・Vectorにいれて、各要素はORでつなぐ。
　そして、Vectorの各要素はハッシュマップで、このハッシュマップの
　要素の　キー名＝値　とし、要素分、ANDでつなぐ
・要素の値はStringで、’を付ける処理は、この自動生成内で行う。

---

■WHEREを作るところのソース

まず、WHEREを作るところです。

そこは、Vectorに
・なにもなければ、何もしないでかえる
・１要素だけあるとき、
　　それのキーが*zyokenなら、その値だけ入れて返す
　　*zyokenがないなら、１ハッシュマップ分の条件を設定する
・２要素以上あるとき
　　それぞれのハッシュマップの条件文をつくり、ORで結ぶ
ということになります。

　この処理をしたのが、こいつ

	/*
	 * where句を作る
	 * @param	Vector	whete
	 * @return	String	結果（１レコード１ハッシュマップで入っている）
	 */
	public	String	makeWhere(Vector where)
	{
		StringBuffer buf = new StringBuffer();
		
		//	WHEREデータがない
		if ( where	==	null )
		{
			return	null;
		}
		//	WHEREデータがない
		else if ( where.size()	==	0 )
		{
			return	null;
		}
		else
		{
			//	WHEREデータ１行分のとき
			if ( where.size()	==	1 )
			{
				HashMap map = (HashMap)where.elementAt(0);
				if ( map.get("*zyoken")	!=	null )
				{
					//	条件文が指定してある
					buf.append((String)map.get("*zyoken"));
				}
				else
				{
					//	条件文は自分でつくる－１行分
					buf.append(whereOneRec(map));
				}
			}
			//	条件文は自分でつくる－複数行アリ=ORでつなぐ
			else
			{
			   for(int i = 0 ; i ＜ where.size() ; i ++ )
			   {
			       if ( i	==	0 )
			       {  
				buf.append("( ");
			       }
			       else
			       {
			  	buf.append("OR ( ");
			       }
			       buf.append(whereOneRec((HashMap)where.elementAt(i)));
		 	       buf.append(" ) ");
			   }	
			}
		}
		return buf.toString();
	}

（上記＜　＞　￥は本当は半角）

　ここで、whereOneRecというのをつかって、ANDで結ぶ条件を作っています。
　で、whereOneRecなのですが、あとでupdateをやるとき、ANDを,にかえると、set句の部分が作れるので、両方共有するために、こんなことをしています。

	/*
	 * where句の検索条件のAND１個分を作る
	 * @param	HashMap	taisho
	 * @return	String	結果（１レコード１ハッシュマップで入っている）
	 */
	public	String	whereOneRec(HashMap taisho)
	{
		return makeOneRec(taisho," AND ");	
	}

	/*
	 * set句の更新条件を作る
	 * @param	HashMap	taisho
	 * @return	String	結果（１レコード１ハッシュマップで入っている）
	 */
	public	String	setOneRec(HashMap taisho)
	{
		return makeOneRec(taisho," , ");	
	}

（上記＜　＞　￥は本当は半角）

で、結局１行分はmakeOneRecでつくっています。

---

■１行分を作る

これは、以下のようなロジックでやっています。
・ハッシュマップから、項目名をキーにして、データを取り出す
・先頭の書き出しはANDが要らないので、書き出しフラグを作成

以下、項目分
　・もし、項目名のデータがあれば、
　　　　書き出しフラグOFF(０）なら、ONにして
　　　　ONなら、AND（区切り文字）を書き出す
　・項目名＝値を書き出す
　　このとき、文字なら’で囲む
　（自動生成上、そうでないときは、空文字でかこっている。
　　こうすると、実質は囲わない）

それを、ソースにするとこんなかんじ

	/*
	 * where句の検索条件のAND１個分を作る
	 * @param	HashMap	taisho
	 * @return	String	結果（１レコード１ハッシュマップで入っている）
	 */
	public	String	makeOneRec(HashMap taisho,String kugiri)
	{
		StringBuffer buf = new StringBuffer();
		String	name	=	(String)taisho.get("name");
		String	pass	=	(String)taisho.get("pass");
		String	kind	=	(String)taisho.get("kind");

		int	out_flg	=	0;

 		//ユーザー名の設定
		if ( name	!=	null )
		{
			if ( out_flg	==	0 )
			{
				out_flg	=	1;
			}
			else
			{
				buf.append(kugiri);
			}

			buf.append("name =");
			buf.append("'");
			buf.append(name);
			buf.append("'");
		}

 		//パスワードの設定
		if ( pass	!=	null )
		{
			if ( out_flg	==	0 )
			{
				out_flg	=	1;
			}
			else
			{
				buf.append(kugiri);
			}

			buf.append("pass =");
			buf.append("'");
			buf.append(pass);
			buf.append("'");
		}

 		//ユーザー種別の設定
		if ( kind	!=	null )
		{
			if ( out_flg	==	0 )
			{
				out_flg	=	1;
			}
			else
			{
				buf.append(kugiri);
			}

			buf.append("kind =");
			buf.append("");
			buf.append(kind);
			buf.append("");
		}

		return	buf.toString();
	}

（上記＜　＞　￥は本当は半角）
項目はname,pass,kindの３種類、nameとpassは文字列でkindは数字です。

---

■実際には

　実際には、これだと、＝しか処理できないので、値のはじめに＜や＞など、比較演算子があった場合、その部分と値の部分を切り出して処理するなどをするんですが、そーすると、すんげー長いソースになってしまうので、今回は省略します。

　また、条件文は、なにを初めにおくかで処理スピードが違う場合があります。
　KIND=1 AND NAME="root"と NAME="root" AND KIND=1では、結果は同じなのですが、途中の処理のせいで時間が違うことがあります。

　このため、上記の項目順をかえることがあります。

　なお、この項目の部分は仕様書から自動生成しますが、それは、話のあとのほうにでてきます。

---

ということでselectはおしまい

米MS、LinuxディストリビューターのXandrosと提携

ここのニュース
MS、LinuxディストリビューターのXandrosと提携
http://www.itmedia.co.jp/news/articles/0706/05/news013.html
によると（以下斜体は上記サイトより引用）

米MicrosoftとLinuxディストリビューターの米Xandrosは6月4日、Microsoftソフトと商業用オープンソースに相互運用性を持たせることで合意した。WindowsとLinuxの混在環境を持つ顧客が、より効率よくシステムを管理できるようなソリューションを提供するのが狙い。

両社は今後5年間、主に5つの目標達成を主眼として掲げていく。



５つの狙いとは（以下青字は、上記サイトの内容を引用し、編集）

・システム管理の相互運用性
・サーバの相互運用性
・オフィス文書の互換性
・知的財産の保証
・Microsoftによる販売、マーケティング支援


このうち、３番目の「サーバの相互運用性」
はこんなかんじ

Xandrosは、Open XMLとOpen Document Formatで保管された文書が互換性を持てるよう、オープンソーストランスレータの開発でMicrosoftと協力する。Xandrosは近くリリースするXandros Desktopとともにトランスレータを提供する計画。


それ以外に興味のある人は、上記サイトを見てね！
報告終わり！

一般的な編集ソフトの作り方 その６：メモリ上への要素展開（親子関係）

　ワープロやドローイングソフトなどの編集ソフトを作る上での一般的な考え方を考える「一般的な編集ソフトの作り方」です。

　いま、メモリ上に、要素を展開するには？という話をしています。

　今回は、親子関係があるモノの場合です。

---

■親子関係

　たとえば、DTPを考えると、
　本の中にページがあり、ページの中に枠があり、枠の中に文字があります
（行とか、段とかも考えることがあるけど、すくなくとも、こういう関係になっています）

つまり、

　　本
　　｜
　ページ
　　｜
　　枠
　　｜
　文　字

　という関係になっているといえます。
　このとき、ページからみたら、本は、親、本からみると、ページは、子という関係になります。。よね（＾＾；）
（枠の親はページ、子は文字となる。本から見ると、枠は孫になる）

この親子関係を、メモリ上に表す方法を考えます。

---

■親子関係の表現法－連結リストと配列（やVector)

　親子関係についても、要素と同様に、連結リストと配列（やVector)で表せます。
まず、配列の場合（やVector)は、かんたん

public class Item {
	int	id;
	Item	prev 	= null;
	Item	next 	= null;
	Vector	child;	　　　　　//　ここに、子供が入る	
	Item	parentItem = null; // 親 
}

　ということになります。childに、自分が持つ子供全部が入ります。
　子供がない場合はNULLです。Vectorなので、どんな要素でもじゃんじゃん入れられます。

　親はもってなくてもいいんですけど、持っていたほうが楽です。
　prevとnextを持っていないと、全部配列（やVector)で処理する形となり、この方法も可能です。

　一方、連結リストは、こんなかんじ

public class Item {
	int	id;
	Item	prev 	= null;
	Item	next 	= null;
	Item	firstChild = null; // 先頭の子供
	Item	lastChild  = null; // 最後の子供
	Item	parentItem = null; // 親 
}

実際には、先頭だけ持っていれば、あとはその子供のnextで、どんどん順番に処理できます。ただ、最後の子供と、親を持っていたほうが、処理上、楽なことが多いです。

　これは、どちらでも、かまいません。

---

■親子関係と、insert,delete処理

　親子関係がある場合、insert,delete処理をどこにかくべきか？なのですが、
・配列（やVector)で行う場合、
　親のほうに、次の要素は何かの情報をもっています
　（初めはchild.elementAt(0)で、
　　その「次の要素」はchild.elementAt(1)です）
　なので、insert,deleteのように、順番を扱う処理は、親のほうでやるしかないです。

　つまり、親のクラスに、insert,delete処理を書くことになります。

・連結リストで行う場合
　C++などでは、削除時、delete処理を行うことになります。
　自分自身の中にdeleteを書いてしまうと、自分自身をdeleteしたあとに抜けるとなり、ちょっと不自然？なので、この場合も、親のほうに書いたほうがいいでしょう。

　つまり、親のクラスに、insert,delete処理を書いたほうが、向いているということになります。

---

■いわれてもれば、Domでも

　で、Domでも、挿入、削除は、親から、子に対して行ってますよね（removeChild,appendChildなど）、あんなかんじで、親から子を操作したほうが、操作しやすいです。

---

　で、insert,deleteはこんな感じなのですが、メソッドには他に、いくつか必要なものがあります。それについては、次回以降で述べていきます。