yamicha.com's Blog - Presented by yamicha.com
Blog yamicha.com's Blog - 2017/11 の記事
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30]

yamicha.com's Blog
 諸事情により、現在更新休止中。ご了承ください。もし今後ブログを再開することがあるとすれば、その際にはこのブログスクリプトではなく、新しく開発したものによるかもしれません。
 当ブログ管理者についてはこちらをご参照。
開発魔法(737)
社会問題(733)
お知らせ(11)
質問・バトン回答(15)
ゲスト出演(8)
経済・知的財産(150)
ゲーム開発(182)
[Ada] 勝手に補足
- Note
- 金配りの次の一手


- Endless Ultimate Diary
- 銃世界

漢字バトン
- うるる雑記帳
- 漢字接力棒

ツキアイゲノムバトン
- ブログ@うにうに画像倉庫
- あぶ内閣

縺イ縺セ縺、縺カ縺励ヰ繝医Φ
- 月夜のボヤキ
- 騎士サーラバトン
パスワードを使う
名無し (2012/02/27)


開発者解放裁判
yamicha.com (2010/03/14)
Winnyに関しては、私も「純白」とまでは考えておりませんし、使用し..

開発者解放裁判
通りすがり (2010/03/08)
winnyに関しては「ダウンロードソフト板」なんてところを拠点に開発..

新型インフルエンザの恐怖
いげ太 (2009/11/03)
> C#などの「int Some(int , int)」は、F#では「(int * int) ->..

時効に関する思考
yamicha.com (2009/08/31)
>いげ太さんコメントありがとうございます。手元にドキュメントが少..
Homepage
Blog Top
Normal View
List View
Search
Calendar
Comment List
Trackback List
Blog RSS
Send Trackback
Phone Mode
Administrator
yamicha.com
Blog
るううるる。
Source
法令データ提供システム
FindLaw
Development
Java2 Platform SE 6
Java EE 6 API
MySQL Developer Zone
PHP Reference
MSDN Library
Ada Reference Manual
Objective Caml
Python Documentation
Erlang
Prolog Documents
これも革命の火の手か
2006/06/23(Fri)18:29:51
 まず1つ。ようやくW杯で日本が敗退してくれました。これでもうすぐニュースサイトも正常化し、重要なニュースを見逃す可能性も低くなるでしょう。周りが楽しんでいるだけなら別に構わないのではありますが、実際のところW杯記事が新聞社サイトを占拠するなど様々な実害も生じていたため、この結果にはとりあえず素直に喜んでおきます。
 ただ、これだけで終わっては面白くありませんので、せっかくですから周囲をからかってみました。例えば、日本が1点入れたことについて、「ブラジルが日本に対して本気を出すというのは、例えるなら3件先の家に茶菓子を届けに行くだけのために大型トレーラー、いや空母を使うようなもの」とか。
 ちなみにその時間帯、私はJSP(後述)を打っていました。周囲が実況を見聞きしており、否が応でも耳に入ってきたのですが、最初の1点2点のうちは点を取られるたびに嘆いていた実況が、3点目ともなると全く無感情で淡々と話していたのが面白かったです。最初に日本が1点取った時には、「ブラジルは決勝進出が決定しているからまじめにプレイしないかもしれない。万一日本が勝ってしまい、決勝に出ることになって、この実害が続いたらどうしよう」と少しヒヤヒヤしたことを正直に告白しておきます。

 最近どうにも火の手が多いですが、少年犯罪という点では奈良の放火殺人など。今のところはっきりした動機は分かっていないようですが、勉学に対する圧力といった話が出てきています。時代はいまや21世紀だというのに、「車輪の下」は健在ということでしょうか。
 とにかく、成績主義などろくなものではありません。事件当日には「保護者会」があり、そこで成績その他の話が出てくるのを嫌った可能性もあるとされています。無論、いかなる理由があろうと放火殺人が正当化されるわけがありませんが、少なくとも車輪に押しつぶされたというのは否定できない事実でしょう。
 今回の場合、被害者でもある親を一概に責めることはできませんが、「学力」などという実体のない幻想を追い続けた結果、子どもを医者にするどころか犯罪者にしてしまったことになります。こうしたことがあるたび、以前からつくづく述べていますが、「学力」と「頭の良さ」の間には何の因果関係も存在しません
 最近は「学力格差」だのという議論が活発ですが、「学力が高いことは、頭が良いということではない」という事実を親が認識していないから、子どもを「お受験戦争」などに巻き込むなど、愚にもつかないことが起こるのです。これでは、いわば「道具」にされる子どももたまったものではないでしょう。
 そういえば、就学援助などに力を入れた自治体が「他に比べて援助率が高い。格差の表れだ」と不名誉な扱いをされるなど、「タマゴが先か、ニワトリが先か」にも近い不思議な議論が起こったこともありました。どちらの言い分が正しいのかは知りませんが、「世間が学力格差論争に過敏になっている」というのも、こうした問題がクローズアップされる理由に含められるのでは。
 ただ、結局のところ、例えば幼児教育などに関しても、はっきりした効果を示すデータがあるという話は聞いたことがありません。要するに、全くのムダである可能性もあるわけです(確実に無意味と断定できるような調査結果もありませんが)。だとすれば、幼少教育だの何だのと言っているのはバカバカしい話でありまして。
 で、学力格差を解消する最も良い方法としては、「学力と頭の良さには全く因果関係がなく、したがって良い塾に行ったり学力の高い学校を(選択制などで)希望するのは無駄である」という認識を世間に広める他ありません。わざわざそういうことをするのはバカらしいという認識が広まれば、学力格差なるものは自然に消失します。
 しかし、これの邪魔をしている勢力が存在するのが困りもの。「全国学力テスト 適度な競争があってよい」「トヨタなどが中心となって私立中学校の海陽学園を立ち上げた」(概略。どちらも読売新聞)。学力テストに関しては、外国では廃止が検討されている段階まで来ていますし、海陽学園は「成金向け中学」であるばかりか、文部科学省がらみのスキャンダルまであります。
 現代日本で言うところの「学力」と頭のよさは関係ない、ということにすら気づかない人間が学力学力と言っているのです。何と学力の低い国、日本

 EJB 3.0もようやくおおむね習得できたようですので、ここで一旦終わりまして、JSPでも書いてみようと考えました。それにしてもEJB、不可解な点が多すぎます。何かといえばすぐにトランザクション例外を投げてきますし、他にも今まで動いていたものが(コードや設定には手を加えていないにもかかわらず)いきなり動かなくなったり、出現していた例外がしばらく放置しておいたら出なくなったり。単純なコードでもこのような現象が発生することがありますので、コーディングの問題ではないでしょう。とにかく不安定なのです。
 ということで、プロンプトを使ってクエリの動作を確認しつつ、JDBCでSQLを直書き。SQL文をガシガシ打てることがこれほど幸せなものとは考えもしませんでした。EJBなどのマッピング技術は、もともと作業の簡素化のために導入されたものであるはずなのですが、JDBC直打ちの方が明らかに簡便で分かりやすく、不可解な例外を投げてくることもありませんから安定性もあります。
 人によっては「マッピングされている方が簡単」という人もいるのでしょうが、そこはバカとシークェルは使いようというやつで、Persistenceなどでマッピングを行うと、どうも薄皮1枚かぶせて触っているようで具合が悪いです。裏で行われている作業も見えにくいですし、何かといえば例外投げつけてきますし。
 そこで今回の企画、「JSPでRSSリーダー」に参ります。まずRSSリーダーとは何ぞや。ご存知の方も多いでしょうが、普段閲覧するブログが1つ2つならともかく、数が増えてくると見て回るのが大変になります。さらに、ブログというのはいつ更新されるか分からないものです。すべては管理者の気まぐれなのです。
 ということは、毎日巡回して骨を折るか、はたまたたまに回って最新の記事を見逃すか。これを回避するための機構が「RSS」です。データを更新したら、そのサマリーをRSSにまとめておきます。すると、そのRSSを見るだけで、ブログが更新されたのか、されたとすればどのような記事なのかが分かるというわけです。
 とはいえ、RSSはXMLファイルであり、人間が巡回して読んで回るのでは余計に手間がかかるばかりです。そこで、この役割を担うのが「RSSリーダー」なのです。よく読むブログをリーダーに登録しておけば、人間がわざわざ巡回しなくても、リーダーが更新を代わりにチェックしてくれるのです。
 今回、それをJSPで作ることにしましたが、JSPならブラウザ上で動くため大変使いやすく簡便です。その分、常駐して定期的にRSSを読み込んだりはできませんが、それでもブログの更新をまとめてチェックするのには有用です。
 さて、RSSリーダーを作ろうとすると、データの取得から保持、XMLパースまで行わなければならず、なかなか大変なのですが、悲しいかなそこはB型、思い立ったらスパッと作ってしまわなければ気が済みません。とりあえず自分が欲しいと考えた機能は全部実装し、作ってしまいました。例によってソースが長くなりすぎましたので、XMLを読み取るキモの部分だけ。
private final String RSS = "http://purl.org/rss/1.0/";
private final String RDF = "http://www.w3.org/1999/02/22-rdf-syntax-ns#";
private final String DC = "http://purl.org/dc/elements/1.1/";

try{
	c.setAutoCommit(false);

	String rss_url = // RSS の場所を示す URL

	// RSS を読み込み
	InputStream is = new URL(rss_url).openStream();

	ByteArrayOutputStream baos = new ByteArrayOutputStream();

	byte buf[] = new byte[16384];
	int r = 0;
	while((r = is.read(buf)) > 0){
		baos.write(buf , 0 , r);
	}
	is.close();

	byte b[] = baos.toByteArray();

	// XML 構築用にストリームを作る
	InputStream bais = new ByteArrayInputStream(b);

	// XMLを構築
	DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
	dbf.setNamespaceAware(true);	// 名前空間を使う設定。忘れずに
	DocumentBuilder db = dbf.newDocumentBuilder();
	Document d = db.parse(bais);

	bais.close();

	// ルートを格納
	Element root = d.getDocumentElement();

	// まず諸情報を読む
	// /channel
	Element channel = (Element)root.getElementsByTagNameNS(
		RSS , "channel").item(0);
	// /channel/title
	String blog_title = channel.getElementsByTagNameNS(
		RSS , "title").item(0).getFirstChild().getNodeValue();
	// /channel/link
	String blog_link = channel.getElementsByTagNameNS(
		RSS , "link").item(0).getFirstChild().getNodeValue();

	// /channel/description
	// description は空白かもしれないので・・・
	Node n_description = channel.getElementsByTagNameNS(
		RSS , "description").item(0).getFirstChild();

	String blog_description = "";
	if(n_description != null)
		blog_description = n_description.getNodeValue();

	// /channel/about
	String blog_about = channel.getAttributeNS(RDF , "about");

	// /channel/items
	Element items = (Element)channel.getElementsByTagNameNS(
		RSS , "items").item(0);
	// /channel/items/Seq
	Element seq = (Element)items.getElementsByTagNameNS(RDF , "Seq").item(0);
	// /channel/items/Seq/resources
	NodeList resources = seq.getElementsByTagNameNS(RDF , "li");

	// あまり意味はなさそうだが resource を ArrayList に落とす
	ArrayList abouts = new ArrayList(15);
	for(int i = 0; i < resources.getLength(); i++){
		Element resource = (Element)resources.item(i);
		abouts.add(resource.getAttributeNS(RDF , "resource"));
	}

	// /item
	NodeList nitems = root.getElementsByTagNameNS(RSS , "item");
	for(int i = 0; i < nitems.getLength(); i++){
		Element item = (Element)nitems.item(i);

		// /item/about
		String about = item.getAttributeNS(RDF , "about");

		// /item/title
		String title = item.getElementsByTagNameNS(
			RSS , "title").item(0).getFirstChild().getNodeValue();
		// /item/link
		String link = item.getElementsByTagNameNS(
			RSS , "link").item(0).getFirstChild().getNodeValue();
		// /item/description
		String description = item.getElementsByTagNameNS(
			RSS , "description").item(0).getFirstChild().getNodeValue();
		// /item/date
		String date = item.getElementsByTagNameNS(
			DC , "date").item(0).getFirstChild().getNodeValue();
	}
}catch(Exception e){
	return "処理中にエラーが発生しました : " + e;
}
 そこまで厳密に組んではいませんが、とりあえず動きます。実際には上記で取得したデータをJDBCでデータベースに保存しています。データベースにさえ保存しておけば、あとはそれをどのように読み取って整形しても自由です。
 そういうわけで、ブログ別表示機構(ユーザーが決めた順番に整列するタイプと、最終更新が近い順に整列するタイプの2種類)を作り、新しい順に記事一覧を表示するタイプの機構も作り、リスト表示する機構も作りました。結構便利です、これ。
 ところで、MySQLではBLOB及びTEXTカラムを使うことができるのですが、この2つはケース依存比較を行うか否かと説明されています。ところが、実際にはTEXTは文字列を解釈し、BLOBは解釈しないものと厳密に定められているらしく、TEXTにバイナリデータ(正確には設定された文字コードに登場しない文字データ)を登録することはできません。逆に、BLOBに対して文字列データを登録した場合、「SET NAMES」などでDB側の文字コードを変更すると取得時に化けます。
 このように、実装途中には色々と問題は出ましたが、結局完成はしました。戦記の他、「うるる雑記帳」(るうさん)と「Endless Ultimate Diary」(coolmintさん)のRSSも登録してはみたのですが、「ブログ@うにうに画像倉庫」のRSSはXMLパーサが例外を投げてくるため、登録することができません
 例外の内容を見てみると、何でも、本来使えないはずの文字をXML内で用いているらしいのです。これはJavaのXMLパーサが投げている例外ですから、私にはどうしようもありませんし、かといってブログ執筆者の方に責任があるわけでもありません。tok2のRSS生成の実装が悪いのです。
 JavaのDOMといえば、XMLパーサの中でも代表的なものであるはずですが、それに対応していないというのはこれいかに。
 ついでに、このブログのRSS生成機構に「encoded」ノードを追加してみました。それに伴い、descriptionからは改行も含めたあらゆるタグを取り除くことにし、encodedではあらゆるタグが残されます。しかし、場合によっては開始タグだけ残って終了タグが切り捨てられてしまう可能性もあるわけですか。危ないです。

 SQL.66。むむ、いい加減ネタが枯渇してきたようです。

師団のリザ「サーラさん、お願いです、通してください」
騎士サーラ「なりません。この先にはイリアスさん、シェインさんなどがおいでです。そして、重要な案件を検討中であり、相手が確実に仲間であると確認できない限りは、何人たりとも絶対に通すなとのご指示です」
師団のディーン「といいますと、我々は仲間でないとおっしゃるのですか?」
騎士サーラ「いいえ。しかし、とても残念なことではありますが、以前に魔法幻影問題が起きて以来、顔見知りを100%信頼することはできなくなっています」
師団のリリィ「それなら、どうすれば通してくれるの?」
騎士サーラ「幻影はシークェルの魔法を使えないようですから、シークェルの魔法の腕前を示していただきます。私の出す問題(ちなみにイリスのシェリー、魔道士イリアス、騎士サーラの合作)に答えることができれば、ここをお通ししましょう」
師団のクレス「して、その問題とは?」
騎士サーラ「それは・・・」

 師団ではSQLを用いて簿記を管理していますが、ある日イリスのシェリーが誤った操作を行い、勘定科目の一部を削除してしまい、リレーションを破壊してしまいました。幸い、消失したテーブルにカスケードをかけたテーブルはなく、被害は最小限で済んだのですが、どの残高がどの勘定のものか分からなくなってしまいました。
 さらに、「当座」といった特殊な勘定科目以外は、ほぼすべての勘定が貸借のどちらの残高かが決まっている関係上、勘定科目のリレーションを吹き飛ばしたせいで、残高が貸借のどちらに属するかも不明瞭となりました。
 伝票など書類を調べれば分かるでしょうが、それらは膨大な量になっており、全部調べたのでは到底追いつきません。かといって、他に参照できるデータもありません。次の情報から、見事にそれぞれの勘定科目を導き出してください。
1.金額(単位 : 十万ヤミ)
勘定A	94
勘定B	125
勘定C	87
勘定D	32
勘定E	70
勘定F	62
勘定G	55

2.削除され、リレーションが破壊されてしまった勘定科目
裏書手形 , 割引手形 , 受取手形 , 仕入 , 売上 , 買掛金 , 貸倒引当金
 なお、聞き込みを行った結果、次のような情報が得られました。

イリスのシェリー「師団では評価勘定を採用しており、手形の手元有高はゼロです。すなわち、受取手形の額は裏書手形と割引手形の合計額になる(裏書手形 + 割引手形 = 受取手形)はずです」
聖騎士シェイン「シェリーさんが誤って、今期の引当金に莫大な額を設定してしまったそうですが・・・。確か、設定時には売掛金の残高はほとんどありませんでした。また、手形残高は引当金の設定時よりほとんど変わっていません。いくらなんでも、偶発債務の額より大きな引当金を設定はしませんから、貸倒引当金の額が受取手形の額より大きくなることはないでしょう」
剣聖ハードゥン「プレミアム騎士サーラ人形を仕入れた。騎士サーラ人形はマスコットの中でも人気が高く、よく売れるのだが、今回はプレミア版だ。全額を掛け(買掛金)で入れたのだが、今期の仕入れはこれが初めてのようだ。しかし、買掛金は前期からの繰り越しが多少あるから、少なくとも仕入より買掛金の額の方が大きくなるのではないか」
イリスのシェリー「確かに、前期に革命記を発注しましたから、買掛金はそれなりに膨らんでいます。しかし、今回のサーラさんの人形の売上は、すでに買掛金全額を上回っています。本当に人気なのですね、サーラさんは」
魔道士イリアス「もう品切れ?全く、どうしてああ人気なのかしら・・・。え?環状線がどうしたって?・・・勘定科目?そんな難しいことは私には分からないわよ!・・・なに?今の話?何とハードゥンが仕入れたサーラ人形があっという間に全部売れたらしいのよ。今期の売り上げはこれが最初かしら。売上額なんて分からないけど。ま、仕入れ値よりは高いんじゃない?」
弓兵アマンダ「前期、出撃のための武具(備品)を購入する際に、手形を裏書して渡したけど・・・。額面?さあ・・・。あまり覚えてないけど、武具を人数分そろえるとなかなか値が張るから、割引手形より裏書手形の方が多いかな」
イリスのシェリー「アマンダさんの話で思い出しました。先の武具の購入額より、今回仕入れたサーラさんの人形の方が、合計額は大きかったように記憶しています。つまり、裏書手形の額は仕入より少ないはずです」

騎士サーラ「これらの情報より、それぞれの勘定科目の金額を求めていただきます。ただし、3度まで答えることを許可します。3度とも間違った場合、いかなる理由があろうとも、この先にお通しするわけには参りません」

師団のリザ「こんな問題、無理ですよ・・・。どうしましょうか」
師団のディーン「重要な話なのだから、是が非でも何とかしなければ・・・」
師団のクレス「戦うしかないか・・・?」
師団のリリィ「・・・勝てるの?」
師団のクレス「それは分からないが、こちらは4人だ。いっせいにかかれば・・・」
剣聖ハードゥン「・・・待て」
師団のリザ「あ、ハードゥンさん・・・。私たちは重要な用事があり、なんとしてでもサーラさんに道をあけてもらわなければならないのです。何とか、一緒に戦・・・」
剣聖ハードゥン「・・・断る。そもそも、君たちや私が何百人集まったところで、サーラ君が相手では勝ち目などない」
師団のディーン「では、どうすれば・・・」
師団のリリィ「やっぱり、どうしようもないわ」
師団のクレス「やはり、ここは・・・」
剣聖ハードゥン「・・・黙るのだ」
師団のリザ「ハードゥンさん・・・?」
剣聖ハードゥン「こんな時、技術者は黙ってクエリで語るものだ・・・」

 3度まで答えられるという今回の問題。しかし、3度間違えると、2度と答えを受け入れてくれないといいます。シークェルを使い、スマートに答えが出せるでしょうか。

模範解答
 技術者は黙ってクエリで語れ。ハードゥンさんが言えば貫禄あるのですから。ということで、クエリで語ってしまいましょう。まずテーブルを作成し、データを追加します。
CREATE TABLE n(i INT , p INT) ENGINE=HEAP;

INSERT INTO n VALUES(1 , 94) , (1 << 1 , 125) , (1 << 2 , 87) , 
(1 << 3 , 32) , (1 << 4 , 70) , (1 << 5 , 62) , (1 << 6 , 55);
 では、クエリを作るとしましょう。裏書手形、割引手形、受取手形、仕入、売上、買掛金、貸倒引当金の各勘定に、それぞれA〜Gまでのアルファベットをつけて考えてみます。
 さて、勘定にこそ難しい名前が並んでいますが、実際にはそれほど難しいクエリではありません。単純な数字の比較に終始しているだけに過ぎません。同じ値段の重複を防ぎつつ、条件を1つずつ総合していくと、次のようなクエリが完成します。
SELECT COUNT(*) 
FROM n a , n b , n c , n d , n e , n f , n g 
WHERE BIT_COUNT(a.i | b.i | c.i | d.i | e.i | f.i | g.i) = 7 AND 
a.p + b.p = c.p AND g.p < c.p AND d.p < f.p AND f.p < e.p AND 
d.p < e.p AND b.p < a.p AND a.p < d.p;

// Result
3
 3つ存在することが分かります。普段ならああ、まだ3つも残っている。絞りきれないとガッカリするところですが、今回は3度まで答えることができます。つまり、以下のパターンのどれかが正解であることが分かります。
SELECT a.p AS '裏書手形' , b.p AS '割引手形' , c.p AS '受取手形' , 
d.p AS '仕入' , e.p AS '売上' , f.p AS '買掛金' , g.p AS '貸倒引当金' 
FROM n a , n b , n c , n d , n e , n f , n g 
WHERE BIT_COUNT(a.i | b.i | c.i | d.i | e.i | f.i | g.i) = 7 AND 
a.p + b.p = c.p AND g.p < c.p AND d.p < f.p AND f.p < e.p AND 
d.p < e.p AND b.p < a.p AND a.p < d.p;

// Result
裏書手形	割引手形	受取手形	仕入	売上	買掛金	貸倒引当金
55	32	87	62	125	94	70
55	32	87	70	125	94	62
62	32	94	70	125	87	55
 この通り。どれが正解であるかは上記の条件では絞りきれませんが、今回の問題では「答えを見つけろ」とはされておらず、騎士サーラの問題に正解すれば良いだけですから、これで一件落着ということになります。

剣聖ハードゥン「うん?サーラ君、武装を新調したのか?その剣と鎧、なかなか決まっているではないか」
騎士サーラ「そう言っていただけるとうれしいですね。私の故郷の村に腕のいい職人がいまして・・・。私が幼少のころ、剣を覚えるきっかけを作ってくれた人です。私にピッタリの武具を作ってくれるので、助かっています」
剣聖ハードゥン「ふーむ・・・」
騎士サーラ「本日、かねて注文しておいた武具を取りに行きまして・・・。あ、こちらお土産です。イリアスさんとお召し上がりください」
剣聖ハードゥン「わざわざすまぬな。・・・これがその武具か。確かにつくりが良いな・・・。で、サーラ君、実家には立ち寄ったのか?」
騎士サーラ「いえ、本日は武具を受け取るだけでしたので、それだけ受け取ってすぐに帰路につきました」
剣聖ハードゥン「そうか・・・」
騎士サーラ「では私は出撃する用事がありますゆえ、これにて」
剣聖ハードゥン「うむ、十分気をつけるのだな」

魔道士イリアス「ふーん、サーラがねぇ・・・。何でも、ひとたび実家に足を踏み入れると、ケガをするから騎士などやめとけとか、恋人はいないのかとか、たまらないらしいわ。ほら、あの辺って村だから」
剣聖ハードゥン「うーむ、サーラ君が・・・」
魔道士イリアス「当のサーラは、剣こそ私の最愛の恋人です、とか言い放ってたけどね」
剣聖ハードゥン「サーラ君が言うと貫禄あるな・・・」
騎士サーラ「ハードゥンさん、ただいま戻りました。あ、イリアスさんもいらっしゃいましたか」
魔道士イリアス「・・・サーラ、何なのよ!また顔に傷なんか作って!」
騎士サーラ「あ、そうですか?・・・この程度、騎士の勲章です」
魔道士イリアス「はぁ・・・。つくづく、サーラって一体・・・」

 このように、サーラさんは変な人なのです。
カテゴリ [開発魔法][社会問題] [トラックバック 2][コメント 0]
<- 前の記事を参照 次の記事を参照 ->

Trackback(2)
自己紹介バトン。(from Endless Ultimate Diary) - 2006/06/24(Sat)20:20:59
ミクシィで友人から「自己紹介バトン」を回されました。ミクシィ上でも答えるつもりですが、折角なのでこちらにもこっそり持ち帰ってきました。コピー用に質問内容を羅列しておきま..

ブラインドタッチバトン(from ブログ@うにうに画像倉庫) - 2006/06/24(Sat)15:28:31
神無川雫様より、WEBバトンが回ってきました。タイトルが解らなかったので、とりあえず勝手に名付けました。参考記事は【こちら】です。【ルール】 キーボードを見ず、携帯の人は親指を見ずに答えを入力してください! 誤字・脱字はそのまま、「BackSpace」や「クリア」..


- Blog by yamicha.com -