Firefoxの名称を"Iceweasel"(氷のイタチ)にする動き。。。

　が、Debian Projectで出ているらしい。
　（いまいち、話が、よくわからないんだが。。）

くわしくは、ここのスラッシュドットニュース

Debian Project, Firefoxの名称を変更する方向へ
http://slashdot.jp/linux/06/10/02/0039252.shtml

　や
Firefox のボイコット
http://taken.s101.xrea.com/blog/article.php?id=647

を見るといいみたいよ。。

　フォクすけは、どうなるんだろう。
　フォクすけでは、いたちっぽくないから、Debian用に、また名前を付ける
　。。。なこたーないか（＾＾；）

ＪＡＶＡのフォーマット変換：ＤＯＭ編（その４：ＤＯＭを生成してＸＭＬ保存）

　前回のＪＡＶＡのフォーマット変換：ＤＯＭ編では、操作をおこないました。
　で、いままでは、ファイルを読み込んで、それを保存していたので、今回は、ファイルを読み込まず、ＤＯＭを生成してその内容を保存します。

---

■概要
ドキュメントビルダーをつくるまでは、今までとおりです。

DocumentBuilderFactory dbfactory = DocumentBuilderFactory.newInstance();
DocumentBuilder builder = dbfactory.newDocumentBuilder();

で、今までは、パースしていたのですが、今回は、ドキュメントを作成しますので
Document xtree = builder.newDocument();

となります。

あとは、前回の編集で、appendChildしたやりかたとおなじなのですが、
一番トップのノードを、ドキュメントにappendChildします。

xtree.appendChild(ne1);

---

■ソース

● 仕様
＜Hotel＞
　　＜HotelName＞ホテル追加その１</HotelName>
＜/Hotel＞
というかたちで、＜Hotel＞をルートにして、
hotel3.xmlというファイル名で書き出します。

●ソース
　以下のとおり

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

//	出力のために追加
import javax.xml.transform.*;
import javax.xml.transform.dom.*;
import javax.xml.transform.stream.*;

public class test {
	/*
	 * 	メイン処理（呼び出し元）
	 */
	public static void main(String[] args) 
	{
		try
		{

			//==============================//
			//	読み込む		    //
			//==============================//
		         // ドキュメントビルダーファクトリを生成
			DocumentBuilderFactory dbfactory = 
                            DocumentBuilderFactory.newInstance();
		         // ドキュメントビルダーを生成
			DocumentBuilder builder = 
                                dbfactory.newDocumentBuilder();
     		         // パースを実行してDocumentオブジェクトを取得
      		         Document xtree = builder.newDocument();

		         //	エレメント(Hotel)追加
		         Element ne1 = xtree.createElement("Hotel");
			Element ne2 = xtree.createElement("HotelName");
			Text nt1 = xtree.createTextNode("ホテル追加その１");
			ne2.appendChild(nt1);
			ne1.appendChild(ne2);
			xtree.appendChild(ne1);
			
			//==============================//
			//	変換のための元生成	     //
			//==============================//
			DOMSource source= new DOMSource(xtree); 

			//==============================//
			//  変換先（ファイル）生成      //
			//==============================//
			File f　=new File("hotel3.xml"); 
			FileOutputStream fo = new FileOutputStream(f); 
			StreamResult result = new StreamResult(fo); 

			//==============================//
			//	変換		     //
			//==============================//
			TransformerFactory transFactory = 
                               TransformerFactory.newInstance(); 
			Transformer transformer =
                               transFactory.newTransformer(); 
			transformer.transform(source, result); 

			//==============================//
			//	あとしまつ	     //
			//==============================//
			fo.close(); 
			System.out.println("Job End");
		}
		catch (Exception e)
		{
      			e.printStackTrace();
    		}

	}
}

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

BREWで複数画面を（分割して開発可能な）開発する場合の方法論（その６：仕様追加－２）

　シリーズ「BREWで複数画面を（分割して開発可能な）開発する場合の方法論」で仕様変更（というか１画面追加）というお話をやってます。
　前回、仕様を書きましたから、今回は、方針と、新規画面について書きます。

---

■方針
　まず、以下の画面に修正・作成が入ります。

・全体画面
　　構造体　：共通領域に、ユーザー名追加
　　イベント：新規画面(gamen10_HandleEvent）呼び出し

・gamen2
　　・共通領域から、ユーザー名を受け取り表示する

・gamen10
　　新規作成

で、これらを作る作業手順について考えます。

---

■作業手順

　ふつうなら、

・全体画面を修正し、gamen10のダミー画面を作成
・gamen10を作成
・gamen2を修正(gamen10と同時にできる）
・gamen10とgamen2をあわせる

　となるのですが、今回はわけあって（というか、こういうことが多い。こちらのフレームワークにはいれないで、単体で来ることは良くある）、gamen10を単体で作成し、それをあとから、このフレームワークに入れ込むという手順をとることとします。
　つまり、はじめにgamen10を作成します。この作業と、全体およびgamen2作成作業は同時にできます（というか、gamen10作成作業は、何にも邪魔されずにできます）

---

■新規画面を作成する
　で、gamen10を作成します。

　今回、ヘッダと関数を分けました。ヘッダはgamen10.h、関数はgamen10.cに書きました。
　ソースは下記リンク先を参照。

　　　gamen10.c
　　　gamen10.h

　で、ここでヘッダについては、テキストとメニューのコントロールのほかには単に
int curno
　というのが追加されていて、それは、現在の項目の番号
　（テキストのほうにフォーカスが当たってたら０、メニューのほうだったら１）
　というだけなので、説明は省略して、gamen10.cのほうを説明します。

---

■コントロールを使う場合のカーソル移動など

　で、gamen10.cの関数は、
boolean gamen10_HandleEvent(gamen10* pMe, AEEEvent eCode,uint16 wParam, uint32 dwParam);
boolean gamen10_InitAppData(gamen10* pMe);
void　gamen10_FreeAppData(gamen10* pMe);
boolean gamen10_DispAppData(gamen10* pMe);
int　gamen10_NextCurItem(gamen10* pMe,int flg);

とあるのですが、このうち、gamen10_InitAppDataは、ご覧のとおり、テキストコントロールとメニューコントロールを生成してるだけだし、gamen10_FreeAppDataは、単純に解放しているだけなので、ここでは、HandleEventとDispAppData、NextCurItemについてとりあげます。

●gamen10_HandleEvent
　上下左右キーが押された場合は、
　　pMe->curno　=　gamen10_NextCurItem(pMe,wParam);
　で、次のカーソルの位置を求め、
　　gamen10_DispAppData
　で再描画します

　メニューのコマンド（EVT_COMMAND）について、画面１の表示に関しては、今回のではやっていません（結合時のソース編集で行います）。
　終了する場合は、gamen10_FreeAppDataでメモリ解放したらISHELL_CloseAppletで終了します。

●gamen10_DispAppData
　これで再描画します。このとき、カーソルが移動します。
　方法は、
　　コントロールについて
　　　　Redrawします
　　　　カーソルが対象だったら（pMe->curnoが、その項目の番号だったら）
　　　　　　　IsActive(TRUE)して、カーソルをもってきます
　　　　　　　それ以外ならFALSE

　　コントロール以外(文字、絵など）
　　　　ここで、書き直した後IDisplay_Updateします。

　　こうすると、コントロールもコントロール以外も再描画され、
　　pMe->curnoの項目にカーソルがきます。

●gamen10_NextCurItem
　現在のカーソル番号から次のカーソル番号を導き出します。
　といっても、今回の場合、どのキーをおされても０なら１、１なら０なので、
　（２つしかないので）そのように、書いてあります。

---

　ということで、今回はここまで。
　次回のこのコーナーは、全体部分などの修正です

画面ごとに担当者が別れているようなケースの構成管理（その２）

　このまえの話のつづき。
　構成管理、つまり、できたプログラム、ソースの管理において、求められる要求というのは、以下のものが、多いと思います

（１）最新版が入手できること
　→この場合、コンパイルできる最新版という意味で、やみくもに新しくても困る

（２）自分が更新しようとしているときに、他人に更新されないこと
　→ロングトランザクション問題と呼ばれます。
　（あ）自分が対象ソースを入手
　（い）他の人が対象ソースを入手
　（う）他の人が修正してアップデート
　（え）自分が修正したものをアップデート
　しようとしたとき、（え）でアップデートすると、（う）の内容が消えてしまいます。
　消えていいのか、いけないのか（本来、（う）の修正をしたあとで、（え）の修正をすべきか、（え）の修正をした後で（う）の修正をすべきか）分からない。

　これを防ぐために、チェックイン（コミット）、チェックアウトや、ロックのしくみを使います
　が、実は、この方法、ある決まりごとを決めてしまえば、必要ありません。
　その決まりごとについては、後述します。

（３）更新履歴がとれること

　ほかに（４）複数バージョンが同時にできること（たとえば、Windows用、Linux用が、同時に作れること）などもありますが、とりあえず、上の３つと言うことにしておきましょう。

---

　そして、上の３つの要求を満たす、構成管理のシステムとしては、大きく２つの形態に分かれます。「サーバーでソース管理型」と「レプリカを作る型」です（正式な言い方ではありません。正式名称を書くと誤解されて厄介な議論になり、それで本質をごまかしているので、わざとあえて、このような本質を明確にした書き方で書いています）。


　「サーバーでソース管理型」は、ソースなどを１つのサーバーに集中して管理する方法で、ＣＶＳなどが、これにあたります。前に挙げたファイルをサーバーに置いておいて共有するなどもそうです。
　この方法の場合、上記要求は満たすのですが、サーバーと開発側がネットワークでつながっていないといけません。

　この要求は、意外と大きな障害で、実際の開発の場合、ぜんぜん知らない会社にネットワークつないで覗かれるということは嫌がられるので（そりゃそーだ）、実現しないことも多いです。

　「レプリカを作る型」というのは、ソースなどが、複数のサーバーに分散してある方法で、ふつうは、コピーが、開発マシン側にもあって、サーバーが集配信するというものです（サーバーにあるときもあるし、ないときもある）
　この方法は、ネットワークがつながっていなくてもいいのですが、（２）のロングトランザクションの問題が、何の手立てもしない場合、おきます。

---

しかし、以下の条件をつけると、２）のロングトランザクションの問題はおきません。

　１ファイル１担当者とし、担当者以外はファイル更新が出来ない。

　こうすると、（２）の問題は起こりません。なぜなら、更新している人は自分だけなので、自分のファイルは、自分以外の人はなおさない（問題となる（う）の事象は起こり得ない）し、仮に直したとしても、それは規約違反なので、違反したほうが悪い、上書きして消しちゃってＯＫです。

　もし、他の人が修正したい場合は
　　・担当者にお伺いを立て、自分が修正したソースを担当者に渡して、
　　　担当者から更新してもらう（必要があれば担当者が直してしまってもかまわない）
　　　とするか

　　・担当者を、自分にかえる

　とすることになります。

　なお、このケースで担当者を、構成管理をする人にした場合、典型的な、構成管理に申請書をだして、頼みに行く方法になります。

---

　では、上記の条件は成立するとして、というか、前回の話のときから、上記の条件なんですけど、分散して、ソースを管理する方法を考えましょう。
　こういうしくみにすればＯＫです。

・自分のローカルのサーバーに出来上がったものを置く
・自分の作業用フォルダに、開発中のものをおく
・ＩＴ１確認用のフォルダをつくる

・そして、自分の担当分は、自分の作業用フォルダのものを、
　　それ以外の部分は、自分のローカルのサーバーのものをリンクします。

・自分の作業分のものが出来たら、メーリングリストに、出来たものを添付して送信します。
　　→これを、更新メールと呼びます

・更新メールを受け取った管理者は、履歴用に保存し（たとえば、gamen1.cというファイルが、３回目の更新だったらgamen1.c.3のような感じでサーバーに保存）、その記録を残しておきます。
　→自動的にＣＶＳに入れてもＯＫだけど

・更新メールを受け取った人々は、自分のローカルサーバーに、その添付ファイルをコピーします

・ＩＴ１の確認依頼の場合は、確認依頼メールを担当者に流します
　そうすると、各担当者の人はＩＴ１確認用フォルダにその内容をいれ、
　そいつをリンクして確認します。ＯＫだったら、ＯＫメールを返信します。

こうすると、メールを使って、構成管理ができるため、メールが届けば、直接ネットがつながって無くてもＯＫです。また、これは手作業でやってもいいし、プログラムを作って自動化してもＯＫです。

　なお、前のものに戻す場合は、サーバーの履歴管理していたファイルを使って戻します。

　Ｌｉｎｕｘ用、Windows用などにわけるには、メーリングリストを使い分けます。
　共通のメーリングリスト、Linuxのみのメーリングリスト、Windowsのみのメーリングリストのようにわけて、このプログラムは、共通へ、このプログラムは、Linuxのみへ、などというようにわけます。

　そして、受け取り側は、Linuxの場合は、共通＋Ｌｉｎｕｘのみ、Windowsの場合は共通＋Windowsのみのように受け取るメーリングリストを組み合わせて、必要なモノをそろえます。


Ｐ．Ｓ
　ただし現実は、ＣＶＳに固執すると思います。でも、現実は分散環境なので、上記のようにメーリングリストをきれば済むはずなのに、それを認めず、ＣＶＳでやれ（でも、ネットワークは切れている　＾＾；）ってお上はいう。そのため、メーリングリストも、メールフォーマットも、ましてやツールもつくらず、構成管理の人が、悲惨な環境で働いている（徹夜で死ぬ思いで、４時間コンパイルを実施しているのに、それを上司の人は無視している。自分がメーリングリストとメールの内容を決めてしまえばおしまいなのに）というのが、現状です。

　もちろん、上記のようにやっている会社もあります。ウィリアムのいたずらの経験だと、パッケージ会社などは、メールを決めるほうに近い。中小の開発はＣＶＳ、大きい開発は、わけわかんないことが言う人がいて、上の人は、なにもわからず、破綻してる。

　専門学校や大学や学会や出版社や権威もその現状を無視して、ＣＶＳやSubversionを押し付けてたりするわけだ（＾＾）サーバーでソース管理する方法で、どーやって、ネットワークつながってないところを管理するのよ。。。っていうことは、答えずに。。（けっこう、上記のメールの自動化、作っちゃうと簡単なのにネ。perlプログラムで、ファイルのコピーとか、そこら、それをメールに登録すればいいだけなんだけど。）

　そもそも、内容に競合があったということを通知されても、じゃあ、そのとき、どうしたらいいかっていうことを、誰が判断するのよ！その判断する担当者を決めておかなきゃいけないジャン。　判断する担当者決めるなら、そのソースは、そいつ担当って言うことで、そいつが修正すればいいじゃん（修正してもらいたいやつはお伺いを立てる。緊急の場合は、一時的に担当者を変え、平時になったら、担当者を戻す）。

　っていうと、おまえは、大きなプロジェクトやったことないからしらないんだ、修正は、入り混じるんだ、みんなが修正できるようにしなきゃいけないんだって言う（そー言うこと言うやつに限って、ウィリアムのいたずらの経歴を知らないんだけどね　＾＾；）。
　でも、その結果、ごちゃごちゃになって、えーいコミット！っていって、コミットしちゃってデグレードじゃん！わかってねーのは、どっちだちだよ！！

　とぺーぺーのウィリアムのいたずらは思ったりもします。

BREWで複数画面を（分割して開発可能な）開発する場合の方法論（その６：仕様追加－１）

　BREWで複数画面を（分割して開発可能な）開発する場合の方法論のつづきです（前回のプラス１とは違い、本論の続き）。

　ここで、仕様追加をして、１画面増やしたら、どうなるか？という話をします。
　で、今回増やす１画面は、IHtmlViewer（を使いやすくしたIHtmlCtl）を使わず、IMenuCtlやITextCtlを使ってやります。

　で、今回は、追加仕様について

---

■追加仕様
　以下のような画面を、起動時に出すようにする


　ここで、
＜上記画面について＞
１．ユーザー名はチェックしないでよい
　　→１０字以内で、もし、それ以上入力されても１０字まででよい
２．メニューで「開始」が選択されたら、第一画面が出るようにする
３．メニューで「終了」が選択されたら、終了する

＜第二画面について＞
４．第二画面で結果表示のとき、一番上に
　　○○さんの結果
　と、ユーザー名が出るようにする（○○さんが、ユーザー名）
５．第二画面で「終了」を押されたら、上記画面に戻る

なお、上記画面をメニュー画面とし、gamen10とプログラム上ではする
（gamen10.c,gamen10.hが、画面のソースとなる）

---

では、次回は、上記画面の単体のソース（BREWで複数画面を（分割して開発可能な）開発する場合の方法論でやってきた、全体のソースに入れない状態のもの）を紹介します。