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
カテゴリ表示
 カテゴリ 開発魔法 に当てはまるもののみを表示します。

 存在する記事 737 件の中から 1-5 件を表示しています。
毎年恒例の先送り表明の日
2010/08/16(Mon)00:08:39
 靖国神社の代替となる無宗教の国立追悼施設の建設構想について、菅氏は「党内外でもかなり議論がある。今すぐどうという結論ではなく、そういう議論の在り方を見ておきたい」と述べ、11年度の予算への調査費計上を見送る考えを示しました。なお、本構想は政権交代前の民主党の政策集にも盛り込まれたものでしたが、昨年の鳩山政権も菅氏と同様の理由で調査費の計上を見送っています。
 鳩山政権ともども、意見が分かれているからと拙速を避けて様子を見るのは結構ですが、それでは一体いつになれば機は熟したと判断されるのでしょうか。中立的な追悼施設の建設に関しては、かねてから構想や議論が存在したはずですが、いつまで経っても同じ言い分の繰り返しで進展が全く見られず、終戦記念日のたびに靖国関連のバカ騒ぎが繰り返されるのには、失望を禁じ得ません
 確かに、中立的な追悼施設の建設は最善の策であるとは言いがたい面があります。現状の「党内外での議論」を見るまでもなく、各立場の人々から様々な異論が出ることは避けられません。しかし、あらゆる意見の人々を納得させる最適解というものがおよそ存在しない以上、本構想は今のおかしな状況を改善するための次善の策として現実的なものですから、下手に引き伸ばすよりも実現を目指すべきです。
 非常に不幸なことに、現状の靖国は完全に政治の道具として用いられています。しかも、中国など一部の諸外国が靖国参拝問題を外交問題化しようと試みるだけならまだしも、日本の自称「保守」政治家が靖国参拝をパフォーマンスや支持固めに利用しており、そのような意味でも靖国参拝は政治問題と化してしまっています。一部外国が勝手に参拝を批判しているだけならまだしも、日本の政治家が「対外強硬」を演出するためにあえて靖国参拝を利用しているのですから、外交問題化に行き着くのは当たり前です。
 そして、「戦没者の追悼」をこのような浅ましいパフォーマンスの道具として利用する者がいるせいで、政治問題とは無関係に以前から靖国参拝を行っていたり、本当に純粋な思想から靖国参拝を希望するような者までもがとばっちりを食い、政治家らの純粋な参拝や戦没者追悼が困難な状況となっています。一部の自称「保守」政治家の軽薄な行動により、純粋な思想の者が不自由し、「追悼」と称して戦没者が政治利用される現状は、極めて嘆かわしいと言わざるを得ません。
 また、靖国神社は「遊就館」なる資料館を持っており、太平洋戦争に対して保守的な主張を展開していますが、実際にはご都合主義にもほどがある、極めていい加減な施設でした。戦後日本の「自虐史観」や外国の干渉を排して「正しい」情報を伝えている施設のはずが、米国から文句がついたと見るや内容を修正してしまい、さらにはダブルスタンダードを避けるためか、後には中国の言い分も受け入れざるを得なくなりました。私は必ずしも同施設の歴史観に賛同する気はありませんが、私個人の思想はどうあれ、同施設の行動にはあきれるしかありません。
 無論、神社がいかなる主張をするもその神社の自由ですし、また外国の指摘に従ってホイホイと主張を変えるのも自由ではありますが、靖国神社の場合は追悼施設としての性質がその主張に権威や注目を持たせてしまい、その上かつて外国から文句がついたように、その行動が時として政治・外交問題化もしかねないという側面があります。同神社がいかなる姿勢の持ち主であるかは前述の通りですが、今後とも同神社に「権威」を持たせ続けることは、果たして適切といえるでしょうか。
 さらに、靖国参拝はすでに政治・外交問題化しており、一部政治家の「参拝」なる利のない行動によって国益を損ねかねない点も問題です。「参拝への文句は内政干渉」との声も聞かれますが、「内政干渉」と言い張るのは主張者の自由ながら、そう言い張ったからといって国益へのダメージを避けられるわけではありません。国の利益を守るためにどうしても譲れない部分がある場合には、外交関係の悪化も辞さずに頑として信念を通すのは大事なことですが、本件に害はあっても利はありません。
 しかも、ある政治家が純粋な信念に基づいて参拝を行い、一部外国がそれに言いがかりをつけているというならまだしも、日本の一部政治家がわざと外交摩擦を作り出して対外強硬を演出する手段として、あえて靖国参拝を行った経緯がある以上、日本の政治家と一部外国の政治家の双方が靖国参拝を外交問題として利用している側面があるわけですから、他国が一方的に言いがかりをつけているともいえません。一部のパフォーマンス政治家が本件を外交摩擦演出の道具に仕立て上げてしまったせいで、政治や外交など無関係に本気で参拝や追悼を望んでいる公人は、どれほど迷惑していることでしょうか。
 これらの問題を解消し、戦没者を政治や人気取りに利用しようとする一部の嘆かわしい政治家にそれをやめさせ、純粋な追悼や参拝を望んでいる公人が何の懸念もなくそれを行えるようにする方法としては、やはり中立的な追悼施設が最も現実的な案でしょう。首相や閣僚がアピールのために参拝したり、議員が徒党を組んで集団で参拝したりといった、戦没者をパフォーマンスに用いる不純で浅ましい参拝をなくし、純粋に参拝・追悼したい公人が静かにそれをできるようにするために、速やかな実現が望まれます。

 Quercusが通常のPHPと異なる点として、JNDIからデータベース接続を取得できましたが、QuercusではJavaのメソッドを用いることもできるようです。また、必要ならPHPの標準出力を受け取ったり、何らかの設定を受け取ったりも可能となっています。
 ドキュメントによれば、Javaのメソッドを使用する際には以下の手順に基づきます。
  1. 使用したい機能を含んだJavaのクラスを作り、それをWEB-INF/classes以下など見える場所に配置。クラスはcom.caucho.quercus.module.AbstractQuercusModuleを継承。
  2. WEB-INF/classes/META-INF/servicesにcom.caucho.quercus.QuercusModuleなるファイルを作成し、用いるJavaクラスを列挙。
  3. PHP上でメソッド名をそのまま書く。
 つまり、Javaの適当なクラスに「hello」なるメソッドを書いたら、PHP側では「hello」という関数として使用できます。何か嫌な予感がしますが、案の定ドキュメントではしっかり(メソッドhello_testのJavaDoc部分)
Notice the careful use of the naming
convention hello_test.  This is done
in order to prevent name collisions
among different libraries.
 と書かれてしまっています。ひとまずPHP関数の命名規則にでも従っておいた方が安全かもしれません。
 なお、com.caucho.quercus.QuercusModuleを配置するのは(project_root)/WEB-INF/classes/META-INF/services(JPAを使う場合にpersistence.xmlを置く場所)でなくてはならず、うっかり展開したQuercusのディレクトリに最初から存在する(MANIFEST.MFが置いてある)(project_root)/META-INFにつられてそこにservicesディレクトリを作り、その中にcom.caucho.quercus.QuercusModuleを置いたとしても、全く動作しません。マヌケな間違いといえばその通りですが、作業している側としては正しいと信じ込んでいるだけに、実際にこれに陥ると非常に迷います
 今回は簡素に、次のような構成で作成しました。
/WEB-INF
 /classes
  /META-INF
   /services
    com.caucho.quercus.QuercusModule
  /com
   /yamicha
    /php
     Test.java
     EnvTest.java
(メソッドを呼び出す適当な.phpファイル)
 com.caucho.quercus.QuercusModuleには使用するJavaクラスを列挙します。ドキュメントのサンプルは1つのクラスのみを使用する例となっていますが、2つ以上の場合は改行区切りで動作しました。
com.yamicha.php.Test
com.yamicha.php.EnvTest
 Test.javaでは、適当な2つのメソッドを記述しています。
package com.yamicha.php;

import com.caucho.quercus.module.AbstractQuercusModule;
import java.util.List;
import java.util.ArrayList;

public class Test extends AbstractQuercusModule{
	public String test_repeat(String str){
		return str + str;
	}
	public List<Long> test_map_plus(
		List<Long> datas , int v){
		List<Long> result =
			new ArrayList<Long>(datas.size());
		for(int i = 0; i < datas.size(); i++)
			result.add(i , datas.get(i) + v);
		return result;
	}
}
 文字列はString型で受け渡しできるとして、問題は整数です。ただ単に普通の整数を受け渡すのであれば、この通りintでも問題はないようですが、Listを使用する場合はList<Integer>ではエラーとなってしまいました。PHPの整数型の大きさはプラットフォーム依存とのことですが、Quercusの内部ではlongが使われているようです。
 EnvTest.javaでは、com.caucho.quercus.env.Envを使用しています。ドキュメントのサンプルからも読み取れる通り、PHP上でのメソッド引数は第一引数のEnvを除いたものとなります。APIリファレンスによれば、Envにはかなり色々な機能があるようです。PHPにかかわる一部機能はともかくとして、HttpServletRequestなども取れてしまうのは何ともメタ的です。
package com.yamicha.php;

import com.caucho.quercus.env.Env;
import com.caucho.quercus.module.AbstractQuercusModule;
import java.util.List;
import java.util.ArrayList;

public class EnvTest extends AbstractQuercusModule{
	public void test_show_list_content(Env env , String color ,
		List<String> label , String[][] sources){
		env.println("<table border=\"1\">");

		env.println("<tr>");
		for(String l : label)
			env.println("<td bgcolor=\"" + color +
			"\">" + l + "</td>");
		env.println("</tr>");

		for(String[] source : sources){
			env.println("<tr>");
			for(String s : source)
				env.println("<td>" + s +
					"</td>");
			env.println("</tr>");
		}

		env.println("</table>");
	}
}
 PHPの配列の受け渡しは配列型でもListでも行えるようですが、多次元となると配列型で行うのが無難そうです。さすがにList<List<String>>は通用しませんでした。
 後はこれらをPHP上から適当に呼び出すのみです。
<html>
<head>
<title>Quercus Java-PHP</title>
</head>
<body>

<?php
print "Eggs Beans" . test_repeat(test_repeat(" Spam"));
print "<br />";

print_r(test_map_plus(array(6 , 22 , 54 , 118 , 246) , 10));

test_show_list_content("#CCDDFF" ,
	array("名称" , "動作環境" , "言語名") ,
	array(
		array("Quercus" , "Java" , "PHP") ,
		array("Jython" , "Java" , "Python") ,
		array("JRuby" , "Java" , "Ruby") ,
		array("A#" , ".NET" , "Ada") ,
		array("IronPython" , ".NET" , "Python")
	)
);
?>

</body>
</html>
 見た目はPHPでも、型に失敗するとClassCastExceptionを投げてきたりするのが何ともJavaです。
カテゴリ [開発魔法][社会問題] [トラックバック 0][コメント 0]

財政構造改革を財政健全化の推進に変更する世論調査
2010/08/08(Sun)07:20:26
 7日、内閣府は「国民生活に関する世論調査」の結果を発表しました。その結果によると、「景気対策」を望む声は昨年から6.8%増の69.3%にのぼり、不況によるダメージを裏付けるものとなっています。「医療・年金等の社会保障の整備」は69.6%でした。また、「財政健全化の推進」(昨年までの選択肢名は「財政構造改革」)は昨年調査の16.9%から急増して25.5%となり、借金やバラマキが続く財政問題への関心の高さもうかがわせます。
 まず、この世論調査では「財政健全化の推進」を選んだ人が大幅に増えていますが、確かに25.5%という数字自体は国民の財政への関心を表すものです。しかし、「16.9%であった前回調査から10%近くも増えているから、選挙での争点化やバラマキなどによって関心が大幅に高まっている」と結論するのは早計に過ぎます。
 この選択肢は、前回までは「財政構造改革」と呼称されていました。「財政構造改革」と「財政健全化の推進」は広義には同じものですが、言葉の意味合いは微妙に異なります。財政構造改革が必ずしも財政健全化であるとは限りませんし、財政が健全であっても財政構造改革は可能です。また、財政健全化が直ちに財政の構造を改革するものであるとも限りません。現状日本での財政健全化といえば、借金を返したりプライマリーバランスを立て直したりといった意味合いが強くなりますが、財政構造改革はその点があいまいです。したがって、受ける印象はかなり違ってきます。
 また、「財政構造改革」は規制緩和などの構造改革のニュアンスを含む印象を受けるのに比べ、「財政健全化」はそれほどでもありません(「財政構造改革」とは別に、調査項目には「規制緩和などの経済構造改革」の選択肢もありますが、「経済構造改革」と「財政構造改革」は完全に切り離せるものではありませんし、受ける印象を払拭できるものでもありません)。派遣やタクシーなどの規制緩和がもたらした結果や、安部政権下の無賃残業合法化騒ぎなどを見せつけられ、これ以上の規制緩和は逆に大きな被害をもたらすと考える人が相当数存在することは想像に難くありません。つまり、これ以上の規制緩和は国民や国家のためにならないと考える一方、借金を返したりバラマキをやめたりはしなければならないと考えている人は、「財政構造改革」は選ばず「財政健全化の推進」なら選ぶ可能性があります。
 すなわち、「財政健全化の推進」への関心が国民の間にある程度存在するのは事実ですが、果たしてそれが昨年に比べて有意に増加しているのか、またどの程度増加しているのかは不明です。もしかしたら選挙などの影響で本当に大きく増えているのかもしれませんし、実際には全く増えていないのかもしれません。これでは統計のやり方としてあまりにまずいと言わざるを得ません。
 そのような当てにならない統計であるにもかかわらず、一部マスコミなどは「民主党のバラマキに危機感を覚える人が増えた」などという結論を強引に導き出していますが、恣意的にもほどがあります。なぜなら、「財政構造改革」を選んだ人の数は2007年の調査で15.9%、2008年で19.2%、2009年で16.9%と推移しており、麻生政権の金配り後の調査である2009年ではむしろ数が減っているためです。もしバラマキに対して国民が「財政構造改革」を選択するならば、この推移には説明がつきません。他方、国民はバラマキに対して「財政構造改革」はあまり選択しないものの、「財政健全化の推進」は選択するならば、2009年の調査と比べるという行為自体が意味を成しません。仮にもマスコミを名乗るなら、もう少し正当・正確に分析すべきでしょう。
 しかし、昨年に比べた結果はどうあれ、バラマキなどに対する問題意識を持っていたり、国の財政に危機感を持っている人は少なくないのは確かです。景気対策や社会保障など優先順位が高いであろう政策が並ぶ中で、「財政健全化の推進」を1/4もの国民が選んだことを無視するわけにはいきません。財政健全化のためには増税や歳出削減が必要ですが、景気対策を7割もの人が要望する中で、財政健全化の要望がこれだけあるのは、決して少ないとはいえません。
 そして、民主党の政策にせよ自民党の金配りにせよ、バラマキ政策が財政健全化に悪影響を与えるのは事実です。この不況下にありながら、財政健全化を望む声が一定数あることに真摯に耳を傾けるならば、財政を悪化させる割に意味のないバラマキは当然ながら回避すべきです。
 特に子ども手当は槍玉に上がることが多い政策ですが、民主党は満額支給こそ困難と見ているものの、11年度からの増額は検討しているようです。子ども手当に伴って児童手当などが廃止されるため、児童手当を受けていた家庭の負担増を避けるには増額が必要との判断のようです。増額幅はまだ決まっていないようですが、1兆円単位の財源が必要になると予想されています。
 しかし、この増額策は言うまでもなく矛盾しています。何しろ、児童手当などを受けている人は今後はそれを受けられなくなり、一方であらゆる対象世帯に対して同一額が増額されるのです。これで児童手当受給世帯の収支がほぼゼロになるのは良いとしても、一切の手当や控除を受ける必要がなかった余裕ある世帯の収支はどうでしょうか。帳尻合わせの方法としては最悪と評価せざるを得ません。
 子ども手当は理念だけを見れば極めて優れた政策です。子どもへの財源割り当てが極めて乏しいとされる日本において、配偶者控除など矛盾に満ちた不公平な支出を廃し、それを子どもに対して振り向けるという理念は、高く評価されてしかるべきです。唯一かつ最大の汚点は、それを配るという意味も理念もない方法を用いてしまったことに他なりません。
 子どもへの支出としてまず行うべきは、何を置いても教育の充実以外にありません。教育自体が国の礎である上、最近は貧富の差によってろくな教育が受けられないという悲劇も多く発生しています。格差を埋め合わせる意味でも、教育の充実は極めて重要です。他にも子育て支援や保育所の充実など、子どもへの財源でできることは数多くあります。また、直接給付が必要な家庭に対して直接給付を行うのに反対する気はありませんが、全部の家庭に対してそれを行う必要はどこにもありません。
 ちなみに、先の世論調査には「教育改革・青少年対策」や「少子化対策」という選択肢もあり、近年では毎年30%前後の人がこれを選択しています。政府が何をすべきかは明白というものです。

 Java EE上で簡単にPHPが動いてしまうQuercusですが、さすがはPHP 5に準拠しているだけはあり、mysql_などの関数の他にPDOを使用したデータベースへのアクセスさえ可能です。しかも、単にデータベースを使用できるだけなら普通のPHPと変わりませんが、(関数とPDOのどちらの方法を用いる場合でも)JNDIから接続を取って使用できるというすさまじい機能を備えています。
 やり方はすべてQuercusのREADMEに書いてあり、これに従って作業を行っていけば、かなり容易にデータベースを使用できます。ただし、このREADMEには間違っている箇所があるため、実際に作業する際には注意が必要です。
 以下、READMEより"IV) JDBC Connections"のセクションを引用しておきます。
IV) JDBC Connections
--------------------
Quercus is able to use database connections from a DataSource configured
using JNDI.  Application servers typically provide a mechanism for making a
connection pool DataSource available with JNDI.

Quercus database connection methods accept the JNDI name directly:

  $conn = mysql_connect("java:comp/env/jdbc/myDatabaseName")

  OR

  $pdo = new PDO("java:comp/env/jdbc/myDatabaseName");

If the web.xml contains a configuration for a JDBC database, then Quercus will
ignore the arguments to PHP database functions and will connect directly to
the preconfigured database.

    <init-param>
      <param-name>database</param-name>
      <param-value>jdbc/myDatabaseName</param-value>
    </init-param>

Quercus will use the above database for all calls to the database like the
ones below:

  $conn = mysql_connect("localhost", "user", "pass");

  OR

  $pdo = new PDO("mysql:host=localhost", "user", "pass");

Consult the documentation for your application server for instructions on
configuring a database and making it available with a JNDI name.
 どうやらweb.xmlを編集しなければならないようです。
 そこでweb.xmlを開いてみると、ご丁寧にも書き方の例がコメントアウトされた状態で用意されています。以下のコメントがある部分です。
    <!--
      Tells Quercus to use the following JDBC database and to ignore the
      arguments of mysql_connect().
    -->
 これの下にあるinit-paramのコメントアウトを解除し、以下のようにJNDI名に書き換えます。
    <init-param>
      <param-name>database</param-name>
      <param-value>jdbc/MySQL</param-value>
    </init-param>
 サンプルが用意されていたおかげで、簡単に下準備が終了しました。
 後は実際に使ってみるだけですが、ここで注意点があります。READMEの次の部分には誤りがあり、実際に私も引っかかってしまいました。もしPDOの使用経験がなかったら、おそらく修正方法も分からないままになっていたでしょう。
Quercus database connection methods accept the JNDI name directly:

  $conn = mysql_connect("java:comp/env/jdbc/myDatabaseName")

  OR

  $pdo = new PDO("java:comp/env/jdbc/myDatabaseName");
 通常、PDOは"DB名:場所"の形式で接続先を指定します。localhostのMySQLに接続するなら、"mysql:host=localhost"といった具合です。そもそもPDOは様々なRDBMSに対して使用できるのですから、接続の際の情報にRDBMS名が含まれていなければ、使用するRDBMSがMySQLか、PostgreSQLか、はたまたOracleかmssqlかDB2か分からないのですから、接続できるわけがありません。したがって、"mysql:java:comp/env/jdbc/myDatabaseName"のようにデータベース名を記述しなければ接続ができません。mysql_connectを使用する場合には、READMEの書き方のままで問題なく接続できます。
 それでは実際に使用してみます。まずは適当なテーブルを作成し、データを登録します。
CREATE TABLE quercus_runtime(
id INT , name VARCHAR(32) , PRIMARY KEY(id));

CREATE TABLE quercus_lang(
id INT , name VARCHAR(32) ,
base VARCHAR(32) , runtime INT ,
PRIMARY KEY(id) ,
FOREIGN KEY(runtime) REFERENCES quercus_runtime(id) 
ON UPDATE CASCADE ON DELETE CASCADE);

INSERT INTO quercus_runtime VALUES
(1 , 'Java') ,
(2 , 'Parrot') ,
(3 , '.NET');

INSERT INTO quercus_lang VALUES
(1 , 'Quercus' , 'PHP' , 1) ,
(2 , 'Groovy' , 'Groovy' , 1) ,
(3 , 'Jython' , 'Python' , 1) ,
(4 , 'JRuby' , 'Ruby' , 1) ,
(5 , 'Rakudo' , 'Perl 6' , 2) ,
(6 , 'A#' , 'Ada' , 3) ,
(7 , 'IronRuby' , 'Ruby' , 3) ,
(8 , 'IronPython' , 'Python' , 3);
 後はこれをPHPから読み込んでみます。
 まずはmysql_...を使用してアクセスしてみます。前述の通り、mysql_connectを使用する場合であれば、そのままJNDI名を書くだけで接続できました。
<html>
<head>
<title>Quercus Database</title>
</head>
<body>

<table border="1">
<tr>
<td bgcolor="#CCDDFF">ID</td>
<td bgcolor="#CCDDFF">実装名</td>
<td bgcolor="#CCDDFF">元の言語</td>
<td bgcolor="#CCDDFF">動作環境</td>
</tr>

<?php
$c = mysql_connect("java:comp/env/jdbc/MySQL");

$q = mysql_query("SELECT l.id AS 'id' , l.name AS 'name' , " .
	"l.base AS 'base' , r.name AS 'runtime' FROM quercus_lang l " .
	"INNER JOIN quercus_runtime r ON l.runtime = r.id " .
	"ORDER BY l.id");

while($result = mysql_fetch_row($q)){
	print "<tr>";
	foreach($result as $r){
		print "<td>$r</td>";
	}
	print "</tr>";
}

mysql_close($c);
?>

</body>
</html>
 以下は同じものをPDOで書いた場合の記述です。こちらはRDBMS名を省略するとエラーとなりました。当初はREADMEの通りに書き、動かずに困り果てましたが、プリペアドステートメントなどが平気で使えるPDOが何とか動作するのは助かります。
<html>
<head>
<title>Quercus Database</title>
</head>
<body>

<table border="1">
<tr>
<td bgcolor="#CCDDFF">ID</td>
<td bgcolor="#CCDDFF">実装名</td>
<td bgcolor="#CCDDFF">元の言語</td>
<td bgcolor="#CCDDFF">動作環境</td>
</tr>

<?php
$c = new PDO("mysql:java:comp/env/jdbc/MySQL");

$s = $c->prepare("SELECT l.id AS 'id' , l.name AS 'name' , " .
	"l.base AS 'base' , r.name AS 'runtime' FROM quercus_lang l " .
	"INNER JOIN quercus_runtime r ON l.runtime = r.id " .
	"ORDER BY l.id");
$s->execute();

while($result = $s->fetch(PDO::FETCH_NUM)){
	print "<tr>";
	foreach($result as $r){
		print "<td>$r</td>";
	}
	print "</tr>";
}

$c = null;
?>

</body>
</html>
 無事にデータが取得できれば成功です。
カテゴリ [開発魔法][社会問題] [トラックバック 0][コメント 0]

無理知国災再び
2010/08/02(Mon)01:36:31
 ねじれ国会、小沢氏の暗躍など波乱含みの民主党ですが、ここで見逃せない動きが登場してきました。国民新党の亀井氏が、菅氏に対して無利子非課税国債の導入を進言したというのです。今のところ菅氏は「勉強する」とだけ返答し、まだ具体的な話は出ていないようですが、今後の民主党及び菅氏の対応によっては導入がなされる可能性も否定できません。なお、同案は麻生政権時にも導入が検討されましたが、その際には見送りとなりました。
 亀井氏は消費税増税に慎重な立場を取っており、無利子非課税国債によって増税をせずに財政再建に必要な財源を手に入れようとのもくろみがあるようですが、あまりにも安易な帳尻合わせの一言に尽きます。相続税の免除自体にも問題点が多く、消費税増税には国民からの反発を受けても、相続税免除を引き換えにした借金であれば怒らないと考えているのであれば、国民をバカにするにもほどがあります
 相続税について詳しく知りたい方には相続税法を読んでいただくとして、要点を簡単にかいつまんで記述すれば、まず相続資産には最低でも6000万円(基本5000万円に加え、相続を受ける者1人につき1000万円)の控除がなされ、それを超過した部分に対して相続税がかかります。また、税率も金額が少ないうちは10%に過ぎず、最高税率である50%が適用されるのは課税部分のうち3億を超過した部分のみであるなど、極めて累進性の高いものとなっています。すなわち、大半の一般家庭にはあまり縁がなく、資産家の相続には大きな影響を持つ税であるといえます。
 無利子非課税国債は、この税を免除あるいは軽減することと引き換えに無利子での借金を行うものです。わざわざ言うまでもありませんが、これは相続税にあまり縁がない一般家庭にとってはメリットのない代物である一方、大量の相続税を取られる資産家にとっては明らかに有利な政策です。同債が実際に運用されるとなれば、不公平感を軽減するために一定の制限は設けられるはずですが、いかに制限を強化したとしても大量の相続税支払いが必要な層に対してのみ有利な選択肢を提供することに変わりはありません。
 また、世の中の大半の税は「富の再分配」の意味を多分に含んでおり、特に相続税は単に収入を分配するという意味合いだけでなく、「金持ちの子は金持ち」という富の偏在・格差の固定化を軽減する機能も併せ持っています。格差の固定化は不公平感を増大し、社会から活力を奪ってしまう恐れもある重大な問題ですが、果たして亀井氏はそこまで考えた上でこのような案を提示しているのでしょうか。
 また、無利子非課税国債は確かに「国民資産」を無利子で活用できる方法ではありますが、借金はあくまで借金です。そもそも「無利子」という言葉が曲者で、無利子を我慢してもなお十分な利益のある条件でなければ同債を買う人などいないことを忘れてはいけません。同債分の財源を上手く弱者に振り向けられれば、弱者にもメリットのある政策にならないとは言い切れませんが、無利子とはいえ結局は借金であること、無利子と引き換えにそれ以上のメリットを提供しなければならないことなどを考えれば、単なるおためごかしに終わる可能性が極めて高いといえるでしょう。
 すなわち、無利子非課税国債は消費税に比べて負担が軽いようでいて、簡単に検証するだけでもこれだけの重大かつ多量の問題が存在し、逆進的であるとはいえ課税額が購買力にある程度比例し、しかも生活用品の減免や補助などによる弱者の負担軽減を図る余地がある消費税に比べ、公平あるいは軽負担であるとは到底いえません。ある意味、国民に見えにくいところでコソコソと細工をして帳尻を合わせようとする無利子非課税国債より、批判覚悟の消費税の方がまだ正当であるとさえいえます。
 さらに何より不安なのは、仮に無利子非課税国債が導入された場合、実際には「明日の相続税」をツケにしたものでありながら、「今日」の便利さのために際限がなくなってしまいかねない点です。特に亀井氏は消費税増税をせずに同債を発行すべしと主張していますが、これでは収支は当面プラスには近づきません。そうして無利子の借金に慣れてしまうと、無利子の借金返済のために泥沼的に無利子の借金を行い、気づいた時には国内資産は枯渇し、しかも格差が対処のしようがないほどに固定化され、社会は活気・流動性をなくし、国民の不公平感も極限まで増大するという、最悪としか形容しようのない状況にも陥りかねません。
 そして、単に亀井氏が無利子非課税国債を計画しているだけであれば、亀井氏の妄想に過ぎないとして片付けることもできますが、もし菅氏が乗り気になれば妄想では済まされません。麻生政権でもこの案が出ていたように、自民党内にもこれを主張する者は存在し、両党の協力によって実現される可能性が否定できないためです。
 言うまでもなく、菅氏はこの案を安易に採用すべきではありません。数々の短所からして好ましい案とはいえませんし、仮にどうしても実現する必要があるとしても、多くの短所を上手く回避する綿密な計画が必要となるためです。そして、この案を本気で検討している姿勢を見せようものなら、本問題は確実に小沢氏の暗躍、消費税増税して法人税減税問題に次ぐ菅氏・民主党の泣き所となるでしょう。
 亀井氏や国民新党の立場はともかくとして、菅氏は責任ある与党として消費税増税の話もしており、それ自体は悪いことではありません。しかし、それとセットの法人税減税に関しては、かなりの批判があると見るや、あわてて「優遇措置廃止による財源捻出」に方針転換し、さらには突如として所得税の最高税率見直しも検討、最後には「消費税を上げる際には改めて信を問う」と大幅に主張が後退するなど、氏の税制発言はひたすらに混迷を深め、参院選敗北の原因となりました。この上さらに「消費税を上げずに無利子非課税国債」などといい加減かつ政権与党として無責任なことが言えるわけがありませんし、かといって消費税増税で弱者にも少なからぬ負担を求め、その一方で相続税は優遇するなどと言い出せば、民主党がいっそうの失望を集めるのは確実です。しかも、民主党や菅政権がこのようなことを言い出したとなれば、所得税最高税率引き上げ、法人税の優遇措置廃止による財源捻出なども、消費税への批判をかわすための口約束と判断されても仕方がありません。
 無利子非課税国債問題に関しては、負担や問題点が消費税よりは見えにくい上、問題を理解するためには相続税法や富の分配に関する若干の知識が必要となり、政治家の間には「消費税より通すのが楽」という意識があるのかもしれません。しかし、国民をあまり侮ってばかりいると、じきに手痛いしっぺ返しを受けることになるでしょう。

 このほどGlassFish v3 PreviewをOracle GlassFish v3 Open Sourceに取り替えてみました。昨年の間のPreviewとその後のPreviewでは全くといって良いほど変わっており、昨年のPreviewではJPA 2.0の機能をほとんど使えなかったばかりか、Adminコンソールすら相当貧弱であったところを、後期PreviewはJava EE 6の仕様をほとんど満たしたものとなっていましたが、それだけに正式版にはさほど目新しさがありません。
 しかし、ドキュメントにOracle GlassFish Server 3.0.1 Scripting Framework Guideなる怪しい項目が加わっており、何とJRuby on Rails、Grails、Jython、PHPの使い方が書かれています。PHPに関しては、以前にやや面倒なBridgeを使ったことがありましたが、先のドキュメントによれば「warをダウンロードして配備する」というお手軽仕様である模様です。Java EEでPHPが平然と動く(しかも公式ドキュメントに記載)のは面白そうですので、動かしてみないわけにはいきません。
 以下、極めて簡単に動かす手順の覚え書きです。ドキュメントに記載されている方法よりいい加減ですが、デバッグや実験には便利です。
  1. このサイトからQuercusをダウンロード。表記は"war"だが、なぜかzip形式で入手できる。
  2. これを任意の場所に解凍。ディレクトリ名には分かりやすいものを使用。Java EEやGlassFish専用の作業場ディレクトリがあるなら、そこに解凍するのがよい。
  3. Adminコンソールを開き、これをディレクトリごとデプロイ
  4. 後は"Launch"(言語が日本語なら「起動」)。成功メッセージが表示されれば成功。Quercusはindex.phpの内容をパースして表示している。
 Java EEの上にPHPが乗っかっているような操作性で扱えて分かりやすいです。
 index.phpの動作が確認できたら、次は自分のPHPコードを動かしてみなくては話になりません。以下のような適当なコードをhello.phpとして保存し、
<html>
<head>
<title>Hello Quercus</title>
</head>
<body>

<ul>
<?php
$arr = array("GlassFish" , "Quercus" , "PHP");

foreach($arr as $a){
	print "<li>Hello <b>$a</b>.</li>";
}
?>
</ul>

</body>
</html>
 「(サーブレットのURL)/hello.php」を開いてみると、無事にhello.phpの内容がパースされて表示されました。やはり本物のPHPを動かしているような感覚で、なかなか使いやすそうです。
 これでひとまずPHPが動くのは分かりましたが、それではフォーム値はPHPのやり方で処理できるのでしょうか。実際に試してみました。
<html>
<head>
<title>Hello Quercus</title>
</head>
<body>

Q:I like Spam.<br />
Q:I love Spam.<br />
Q:Spam is very delicious.<br />
Q:Do you like Spam?<br />

<?php
if(isset($_POST["answer"]) && $_POST["answer"] != ""){
	print "A:<b>" . $_POST["answer"] . "</b>";
}else{
	print <<<EOF
<form method="POST">
Your answer: <input type="text" name="answer" size="20">
<input type="submit" value="Say">
</form>
EOF;
}
?>

</body>
</html>
 適当に入力して送信してみて、入力したテキストが表示されれば成功です。
Q:I like Spam.
Q:I love Spam.
Q:Spam is very delicious.
Q:Do you like Spam?
A:I DON'T LIKE SPAM!
 どうやら引数も普通のPHPと同様に処理できるようです。
 他にもPHPには様々な機能があり、$_FILEの扱い、チェックボックスの"name[]"のテクニックなどがQuercusでも使えるかは気になるところですので、この辺の調査も必要そうです。
カテゴリ [開発魔法][社会問題][経済・知的財産] [トラックバック 0][コメント 0]

さよなら参画またしても失格
2010/07/25(Sun)21:11:19
 男女共同参画会議は、2011年度から実施する「第3次基本計画策定」の素案を作成、菅氏に答申しました。主な内容としては、選択的夫婦別姓を実現する他、選挙の候補者の女性比を定めたり、職場の女性の割合を法律で定め、また女性の管理職登用や育児休暇に積極的な企業に優遇措置を設けるものとなっています。ただし、夫婦別姓については国民新党が慎重な姿勢を見せています。
 まず選択的夫婦別姓の導入ですが、これは即座に行ったとしても何の問題もありません。国民新党をはじめとする自称「保守」が根強く反対意見を主張していますが、その理由は「家族の一体感が損なわれる」の一点張りであり、しかも根拠は一切示されていません。すなわち、何の根拠もない理由を盾にして、意味の分からない反対のための反対を繰り返しているだけに過ぎません。いい加減、夫婦別姓に反対さえすれば保守の格好ができるなどという考えは捨て去るべきです。
 無論、「家族の一体感が損なわれる」なる言い分の根拠とそれが生み出す被害の甚大さが説明され、あるいはそれ以外に極めて重要な理由が示されれば、私も夫婦別姓に反対する可能性は十分にあります。しかし、別姓問題が提起されて以後、少なくとも反対論を展開する主要な政治家が、それをしたという話は聞いたことがありません
 一方、夫婦別姓の規定がないことにより、事実婚を選択せざるを得なくなったり、名前の変更による混乱や手間が発生したり、さらには親の離婚・死別や再婚で子どもの名前までころころ変わりかねないなど、制度を変える根拠となるだけの現実的かつ実害のある問題はすでに多く存在しており、「一体感」なる一切の根拠が示されておらず、夢物語か妄想の産物と言っても過言ではない言い分では全く対抗できない状態です。
 また、夫婦が別姓を選べないのは国民の自由を制限する行為ですから、別姓反対派には「〜のような理由により、夫婦が別姓を選ぶ自由を侵害するのはどうしてもやむを得ない」という説明を行う義務があります。それができない、あるいはその理由が国民の自由を制限するだけの合理性を持たないのであれば、制限を存続することはできません。なお、本案が夫婦別姓義務化であれば、導入派も「なぜ同姓とする自由を侵害するのか」を説明しなければなりませんが、現在検討されているのは選択的夫婦別姓、すなわち自由を拡大するのみの案ですから、その必要はありません。
 したがって、現段階の議論からすれば選択的夫婦別姓には何の問題もありません。唯一問題が提起されることがあるとすれば、反対派が「家族の一体感が損なわれる」論の根拠を提示するか、またはその他の重大な理由を提示し、しかもそれが国民の自由を制限することもやむを得ないほど甚大な事象であると示された時のみです。夫婦別姓議論はかなり長きに渡って行われていますが、これだけの期間を経てもまともな反論がなされていない以上、今後も国民の自由を制限した状態のまま長らく反論を待つ必要はないでしょう。
 しかし、候補者や職場、管理職の女性割合に関しては、極めて前時代的で無思慮なやり方であると評するよりありません。数十年前なら一定の意味があったかもしれませんが、21世紀の成熟した日本がやることではありません。自民党など自称保守政党・政治家には「保守」をノスタルジーと勘違いしているような部分が見受けられましたが、民主党政権下のバラマキ政策を見るにつけ、こちらは社会保障や国民の生活向上を数十年前の価値観で考えているような印象がぬぐえません。
 人間というものはおよそ様々な考え方を持っており、例えば夫婦別姓問題一つ取っても、別姓に賛成する男性がいれば反対する女性も存在するのですから、今どき「女性の視点」なる定義不明なものを政治に導入するために、候補者の女性比率を定めるなどという行為はバカげています。ただ、「視点」などの言い分は無視したとしても、「女性の政治家を増やす」試み自体は必ずしも悪いことではなく、そのような意味で女性政治家を増やす方策に反対する気はありません。
 しかし、確かに今のところ政治家の女性比率は少ないとはいえ、実際には「女を売る」かのような露骨な擁立が行われたり、政策そっちのけで女性をウリにする選挙戦略がなされている現状があります。しかも、なぜかその戦略は少なからず奏功する傾向にあります。もし女性政治家を本当の意味で活躍させようとするのであれば、このようなやり方の是正こそ先でしょう。
 また、職場の女性比率などに関しては、これは本当に2011年からの計画なのかと疑いたくなります。いちいち女性比率に頑強にこだわるよりは、まず山積みの労働問題、すなわち賃金問題であったり、無賃残業・みなし役員問題であったり、派遣・非正規問題であったり、公益通報問題であったり、性別その他に対する昇進差別や偏見であったりといった諸問題を改善するのを優先すべきでしょう。また、共同参画政策としては女性優遇ではなく均等を目指すべきです。下手に比率を義務付けるよりは、おそらくその方が早道です。
 例えば、もし「寿退職」などの珍妙な風習を減らしたければ、まず不公平極まりない配偶者控除や第三号制度をとことん撤廃することです。現行制度が女性の退社を奨励している以上、まずはそれを撤廃し、そのような風習をなくしていけば、企業も退社されるリスクを考えて女性を不利益に扱う必要がなくなります。また、「出産退職」のような悪しき問題を解消したければ、男性の育児休暇を充実し、その取得率を大幅に高めるとともに、休暇取得者への不利益な扱いを厳しく禁じ、男女の差を実質的になくすことです。派遣・非正規は女性を安く便利に使用する温床となっていますし、他にも多くの問題が発覚している以上、共同参画以前の労働問題として総合的な対処をしなければなりません。
 つまり、無理に女性優遇措置を実施するのであれば、逆に均等を目指した方が有効な可能性が高いばかりか、優遇が足かせになる状況すら珍しくない現状を考えれば、均等に舵を切った方が妥当というものです。
 ただ、どうしても優遇措置が必要な場面があり、他に有効な手段が乏しいようであれば、優遇によって対処することも仕方がないでしょう。しかしその場合、出口戦略を明らかにしておく必要があります。要するに、女性差別に対して男性差別で対抗しているのが優遇措置なのであって、実際には極めて不健全な状態なのです。さらに、そうして男性差別措置が実施されている以上、それに均衡するだけの女性差別があって当然ということになれば、逆に差別が固定化する結果となります。しかも、その措置によって既得権益を得た者が優遇措置の撤廃と差別の是正に難色を示せば、結果的にずるずると優遇措置を解除できなくなり、差別が半ば公然と肯定される状況にもなりかねません。したがって、優遇措置には出口戦略が絶対に必要なのです。
 結局、理由もなく夫婦別姓に頑強に反対したがるノスタルジー政党にもあきれさせられますが、「平等」や「均等」を履き違えている現政権の男女共同参画会議の素案にも失望を禁じえません。

 に@StaticMetamodelなしのCriteriaを使用しましたが、今回は@StaticMetamodelを使用してみます。比較のため、行う操作は前回と全く同一とします。
 ファイル構造は次の通りですが、太字のものが新しいソース、斜字が修正するソースで、他は前回と全く同じですから割愛します。追加した2つのソースは両方とも@StaticMetamodelです。
/WEB-INF
 /classes
  /com
   /yamicha
    /criteria
     Maker.java
     Product.java
     ProductAccess.java
     ProductServlet.java
     ProductMetamodel.java
     MakerMetamodel.java
  /META-INF
   persistence.xml
 @StaticMetamodelの中身は、何らかのプロパティであればSinglerAttribute<クラスの型 , プロパティ型>、OneToManyであればListAttribute<クラスの型 , 相手クラスの型>、といった具合です。その他、書き方のサンプルはチュートリアルにあります。データ注入のタイミングの関係か、サンプルではvolatileがつけてあるため、ここでもそれにならっています。
 ProductMetamodel.javaであれば、こうなります。
package com.yamicha.criteria;

import javax.persistence.*;
import javax.persistence.metamodel.*;
import java.util.*;

@StaticMetamodel(Product.class) public class ProductMetamodel{
	public static volatile
		SingularAttribute<Product , Integer> id;
	public static volatile
		SingularAttribute<Product , String> name;
	public static volatile
		SingularAttribute<Product , Integer> price;
	public static volatile
		SingularAttribute<Product , Maker> maker;
}
 まず最初のフィールドで、Product.classにはidなるプロパティがあり、それはInteger(ボクシングの関係で実際にはintを使用)型であることが分かります。同様に、String name、Integer price、Maker makerがあるらしいと分かります。
 同様にMakerMetamodel.javaも作成します。
package com.yamicha.criteria;

import javax.persistence.*;
import javax.persistence.metamodel.*;
import java.util.*;

@StaticMetamodel(Maker.class) public class MakerMetamodel{
	public static volatile
		SingularAttribute<Maker , Integer> id;
	public static volatile
		SingularAttribute<Maker , String> name;
	public static volatile
		ListAttribute<Maker , Product> products;
}
 こちらはInteger idとString name、それからList<Product> productsがあることが分かります(結局MakerMetamodelはサンプル中では使いませんでしたが)。

 @StaticMetamodelを作成しておくことで、いちいち
EntityType<Product> product_entity = m.entity(Product.class);
SinglerAttribute<Product , Integer> price =
	product_entity.getSingularAttribute("price" , Integer.class);
 このように取得していたものが、
ProductMetamodel.price
 これだけで取れるようになります。その分@StaticMetamodelのクラスを書かなくてはいけませんが、おそらくIDEによる生成前提ですから問題はないのでしょう。
 ProductAccess.javaは次のように変わります。
package com.yamicha.criteria;

import javax.ejb.*;
import javax.annotation.*;
import javax.persistence.*;
import javax.persistence.metamodel.*;
import javax.persistence.criteria.*;
import java.util.List;
import java.util.ArrayList;

@Remote @Stateless(name="ProductAccess" , mappedName="ejb/ProductAccess")
	public class ProductAccess{
	@PersistenceContext(unitName="MySQL") private EntityManager em;

	public void regist(){
		Maker san = new Maker("San Microsystems");
		Maker olacre = new Maker("Olacre");
		Maker mesql = new Maker("MeSQL AB");
		Maker bae = new Maker("BAe Systems");

		san.getProducts().add(new Product(
			"GrassFish Application Server" , 640000));
		san.getProducts().add(new Product(
			"Soralis" , 750000));
		olacre.getProducts().add(new Product(
			"Olacre DataBase" , 1200000));
		bae.getProducts().add(new Product(
			"AeroLogic Application Server" , 720000));
		mesql.getProducts().add(new Product(
			"MeSQL" , 250000));
		mesql.getProducts().add(new Product(
			"MeSQL Enterprise Support" , 550000));
		olacre.getProducts().add(new Product(
			"Olacre Application Server" , 800000));
		san.getProducts().add(new Product(
			"Blade Server" , 1060000));

		san.link();
		olacre.link();
		mesql.link();
		bae.link();

		em.persist(san);
		em.persist(olacre);
		em.persist(mesql);
		em.persist(bae);
	}
	public List<Product> getProducts(int price){
		CriteriaBuilder cb = em.getCriteriaBuilder();

		CriteriaQuery<Product> pq =
			cb.createQuery(Product.class);
		Metamodel m = em.getMetamodel();
		Root<Product> p = pq.from(Product.class);
		pq.where(cb.lt(p.get(ProductMetamodel.price) , price));
		pq.orderBy(cb.asc(p.get(ProductMetamodel.price))).select(p);
		pq.select(p);
		return em.createQuery(pq).getResultList();
	}
	public List<Maker> getMakers(int price){
		CriteriaBuilder cb = em.getCriteriaBuilder();

		CriteriaQuery<Maker> query =
			cb.createQuery(Maker.class);
		Metamodel m = em.getMetamodel();
		Root<Product> p = query.from(Product.class);
		query.where(cb.lt(p.get(ProductMetamodel.price) , price));
		Join<Product , Maker> join =
			p.join(ProductMetamodel.maker);
		query.distinct(true).select(join);

		return em.createQuery(query).getResultList();
	}
	public void clear(){
		em.createQuery("DELETE FROM Product p").executeUpdate();
		em.createQuery("DELETE FROM Maker m").executeUpdate();
	}
}
 確かに、
query.where(cb.lt(p.get(product_entity.getSingularAttribute(
	"price" , Integer.class)) , price));
 この不毛ぶりに比べればマシなのですが、面倒なものは面倒です。
カテゴリ [開発魔法][社会問題] [トラックバック 0][コメント 0]

国辱技
2010/07/10(Sat)11:16:15
 大相撲の野球賭博問題で、一時は開催が危ぶまれていた名古屋場所は開催され、NHKは生中継をやめて20分程度のダイジェスト放送を流すこととなりました。放映権料をどうするかはまだ未定のようです。また、本問題をめぐっては、相撲協会が公益法人の地位にあることに政府からも疑問の声が出ており、一般法人化される可能性も否定できない状況となるなど、相撲協会にとっては厳しい局面が続きそうです。
 相撲協会にしてもNHKにしてもそうですが、これらの組織は本件における最大の被害者が誰であるのか分かっているのでしょうか。この視点から今回の問題を検証すれば、これらの組織がいかに独善的な物の考え方しかできていないか、いかに狭い視野から物事を見ているかが分かるはずです。
 賭博にかかわっていない力士や関係者にとっては、今回のゴタゴタは非常に残念なものであるはずですし、問題を起こしていない関係者やファンのためにも名古屋場所は開催したいとの考えは理解できなくもありません。また、世の中には多くの相撲ファンも存在し、これらのファンの声に応えるためにも何らかの方法で放映はしたいというNHKの決定も分からないではありません。
 しかし、今回の問題で最も大きな被害を受けているのは、問題にかかわっていない力士や関係者でもなければ、相撲ファンでもありません。角界の問題やNHKの対応によって何のいわれもない被害を負わされるのは、実は相撲とは全く関係のない一般市民なのです。
 今のところ相撲協会は公益法人として活動しており、また相撲は「国技」とされているため、相撲協会は国から様々な便宜を受けています。当然、この便宜はもとをただせば国民の肩代わりによって成り立っているわけです。したがって、たとえ相撲ファンでなかったとしても、日本の一般市民である限り、本件は決して無関係な問題ではありません。むしろ、日本全体で見れば熱心な相撲ファンよりも相撲への興味に乏しい人の方が多いはずですから、このような人はどちらかといえば「サイレントマジョリティー」に属するといえるでしょう。言うなれば、多数派の国民が少数派のために、相撲協会への便宜に協力している図式となります。
 さらに、NHKは年間30億ともされる高額の放映権料を相撲協会に支払っており、相撲協会の収入の数割を占めるとされるほど貴重な収入源となっていますが、当然これは「みなさまの受信料」から支出されています。そして、NHKはテレビを視聴できる全世帯を受信料徴収の対象としており、未払い世帯に対する裁判をちらつかせたこともあるほどですので、最近はインターネットの普及でテレビの価値は大きく低下したとはいえ、まだ「国民皆契約」とみなしても差し支えない状況です。無論、その中には相撲に興味がない人も、それ以前に生中継など見られるわけがない人も、非常に多く含まれています。したがって、この場合に最も損をするのは、間接的に相撲協会を潤しつつ何の受益もない、生中継など見ない人ということになります。
 無論、相撲にあまり興味がない人や、生中継を見ない人が多数派だからといって、直ちに相撲には便宜を図るべきではない、あるいは放送すべきでないと主張する気はありません。しかし、そこで大問題が発覚したとなれば話は別で、さすがに今の状態を考え直さないわけにはいきません。
 しかも、今回の問題には暴力団がかかわっていたわけですから、相撲に関係ない市民の負担がめぐりめぐって暴力団を利し、その暴力団が市民を苦しめるという図式が成り立ちます。このことを考えれば、相撲協会の立場やNHKの方針が今までのままであって良いはずがありません
 NHKが生中継の中止を決めた後、視聴者からは多くの意見が寄せられ、中継すべきとの意見が多くを占めたといいますが、この結果を鵜呑みにするようでは、「サイレントマジョリティー」の存在を完全に無視していると指摘せざるを得ません。前述の通り、本件における最大の被害者は相撲とは関係のない人々です。生中継ではなくダイジェスト番組を放送するにせよ、相撲協会に放映権料が渡りかねない決定である点に変わりはありません。まして、現状では捜査に非協力的な者も存在し、しかも暴力団とのつながりも払拭できているとは限らない状況であるのを忘れてはいけません。放映権料を無償にする取り決めを行うか、あるいは相撲とは何の関係もない大多数の人々に対して「なぜ相撲を放送しなければならないのか」をしっかり説明できない限り、ダイジェストであろうと放映をすべきではありませんでした。
 相撲協会にしても同様です。問題に無関係の力士や関係者、相撲ファンの気持ちを考えるのも結構ですが、同協会には「最大の被害者」について考えているらしい様子が全く見受けられません。実際には、相撲ファンや関係者より何より先に、相撲に関係ない人に大迷惑をかけたことを自覚しなくてはならないのです。相撲協会としては一般法人化は回避したいようですが、公益法人であることによって受ける便宜が誰によって提供されているものなのか、そして収入のかなりの部分を占める放映権料の出所がどこなのかを考えれば、「最大の被害者」を無視するような行動は取れないはずです。それというのに、未だに捜査に非協力的な者がいたり、組織改革に抵抗する者が存在するとは、情けないにもほどがあります。
 相撲協会は当然、組織の大改革を行わなくてはならず、この「最大の被害者」に顔向けができないような行動を取るべきではありません。そして、相撲協会がそれをできないようであれば、国は「最大の被害者」のために相撲協会を一般法人化して一切の便宜を取りやめるべきですし、NHKも「みなさまの受信料」を「最大の被害者」に対して胸を張って説明できないような用途に使ってはいけません。

 JPA 2.0のウリといえば、おそらく悲観的ロックとCriteriaでしょう。しかし、悲観的ロックの実装は(不完全とはいえ)比較的早く行われたようですが、Criteriaは古いGlassFish v3 Previewでは実装されていない始末で、APIドキュメントにも書いてあるものを実行できない状態がしばらく続いていました。
 そうなると、どうしても面白いものを期待してしまうのが人情というものです。ところが、これがなかなか厄介な代物でした。確かにJPQLよりは実行してみてからのミスは防げそうですが、どこぞの言語の類似機能などと比べてしまうとひたすら面倒さが目立ちます。チュートリアルでは@StaticMetamodelを使用する方法とそうでない方法が紹介されていますが、今回は後者を用いました。コードを書く量は減るものの、やたらと冗長です。
/WEB-INF
 /classes
  /com
   /yamicha
    /criteria
     Maker.java
     Product.java
     ProductAccess.java
     ProductServlet.java
  /META-INF
   persistence.xml
 今回は@StaticMetamodelを使用していないため、JPAにかかわるクラスは@Entityのみです。
persistence.xml

<?xml version="1.0" encoding="UTF-8"?>

<persistence version="1.0" xmlns="http://java.sun.com/xml/ns/persistence">
<persistence-unit name="MySQL" transaction-type="JTA">
<provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
<jta-data-source>jdbc/MySQL</jta-data-source>
<properties>
<property name="eclipselink.jdbc.driver" value="com.mysql.jdbc.Driver" />
<property name="eclipselink.ddl-generation" value="create-tables" />
<property name="eclipselink.ddl-generation.output-mode" value="database" />
<property name="eclipselink.target-database" value="MySQL" />
<property name="eclipselink.logging.level" value="FINE"/>
</properties>
</persistence-unit>
</persistence>

// Maker.java
package com.yamicha.criteria;

import javax.sql.*;
import javax.persistence.*;
import java.util.*;

@Entity @Table(name="criteria_maker" , schema="yamicha")
	public class Maker implements java.io.Serializable{
	private int id;
	private String name;
	private List<Product> products;

	public Maker(){
		products = new ArrayList<Product>();
	}
	public Maker(String n){
		this();
		name = n;
	}

	@Id @GeneratedValue @Column(name="id") public int getId(){
		return id;
	}
	@Column(name="name") public String getName(){
		return name;
	}
	@OneToMany(cascade=CascadeType.ALL , mappedBy="maker")
		public List<Product> getProducts(){
		return products;
	}

	public void setId(int i){
		id = i;
	}
	public void setName(String s){
		name = s;
	}
	public void setProducts(List<Product> p){
		products = p;
	}

	public void link(){
		for(Product p : products)
			p.setMaker(this);
	}
}

// Product.java
package com.yamicha.criteria;

import javax.sql.*;
import javax.persistence.*;
import java.util.*;

@Entity @Table(name="criteria_product" , schema="yamicha")
	public class Product implements java.io.Serializable{
	private int id;
	private String name;
	private int price;
	private Maker maker;

	public Product(){
	}
	public Product(String n , int p){
		this();
		name = n;
		price = p;
	}

	@Id @GeneratedValue @Column(name="id") public int getId(){
		return id;
	}
	@Column(name="name") public String getName(){
		return name;
	}
	@Column(name="price") public int getPrice(){
		return price;
	}
	@ManyToOne @JoinColumn(name="maker" ,
		referencedColumnName="id")
		public Maker getMaker(){
		return maker;
	}

	public void setId(int i){
		id = i;
	}
	public void setName(String s){
		name = s;
	}
	public void setPrice(int i){
		price = i;
	}
	public void setMaker(Maker m){
		maker = m;
	}
}
 ProductAccess.javaでCriteria APIを使用しています。
package com.yamicha.criteria;

import javax.ejb.*;
import javax.annotation.*;
import javax.persistence.*;
import javax.persistence.metamodel.*;
import javax.persistence.criteria.*;
import java.util.List;
import java.util.ArrayList;

@Remote @Stateless(name="ProductAccess" , mappedName="ejb/ProductAccess")
	public class ProductAccess{
	@PersistenceContext(unitName="MySQL") private EntityManager em;

	// サンプル登録メソッド
	public void regist(){
		Maker san = new Maker("San Microsystems");
		Maker olacre = new Maker("Olacre");
		Maker mesql = new Maker("MeSQL AB");
		Maker bae = new Maker("BAe Systems");

		san.getProducts().add(new Product(
			"GrassFish Application Server" , 640000));
		san.getProducts().add(new Product(
			"Soralis" , 750000));
		olacre.getProducts().add(new Product(
			"Olacre DataBase" , 1200000));
		bae.getProducts().add(new Product(
			"AeroLogic Application Server" , 720000));
		mesql.getProducts().add(new Product(
			"MeSQL" , 250000));
		mesql.getProducts().add(new Product(
			"MeSQL Enterprise Support" , 550000));
		olacre.getProducts().add(new Product(
			"Olacre Application Server" , 800000));
		san.getProducts().add(new Product(
			"Blade Server" , 1060000));

		san.link();
		olacre.link();
		mesql.link();
		bae.link();

		em.persist(san);
		em.persist(olacre);
		em.persist(mesql);
		em.persist(bae);
	}
	// 指定した価格を下回る製品を
	// 価格の順番に並べて返す
	public List<Product> getProducts(int price){
		CriteriaBuilder cb = em.getCriteriaBuilder();

		CriteriaQuery<Product> pq =
			cb.createQuery(Product.class);
		Metamodel m = em.getMetamodel();
		EntityType<Product> product_entity =
			m.entity(Product.class);
		Root<Product> p = pq.from(Product.class);

		pq.where(cb.lt(p.get(product_entity.getSingularAttribute(
			"price" , Integer.class)) , price));
		pq.orderBy(cb.asc(p.get(product_entity.getSingularAttribute("
			price" , Integer.class)))).select(p);
		return em.createQuery(pq).getResultList();
	}
	// 指定した価格を下回る製品を持っているメーカーを返す
	public List<Maker> getMakers(int price){
		CriteriaBuilder cb = em.getCriteriaBuilder();

		CriteriaQuery<Maker> query =
			cb.createQuery(Maker.class);
		Metamodel m = em.getMetamodel();
		EntityType<Product> product_entity =
			m.entity(Product.class);
		EntityType<Maker> maker_entity = m.entity(Maker.class);

		Root<Product> p = query.from(Product.class);
		query.where(cb.lt(p.get(product_entity.getSingularAttribute(
			"price" , Integer.class)) , price));
		Join<Product , Maker> join = p.join(
			product_entity.getSingularAttribute(
			"maker" , Maker.class));
		query.distinct(true).select(join);

		return em.createQuery(query).getResultList();
	}

	public void clear(){
		em.createQuery("DELETE FROM Product p").executeUpdate();
		em.createQuery("DELETE FROM Maker m").executeUpdate();
	}
}
 タイプセーフではあっても、面倒この上ありません。SQLクエリに直すなら、ただこれだけの操作です。
// getProducts
SELECT * FROM criteria_product WHERE price < ? ORDER BY price;

// getMakers
SELECT DISTINCT m.* FROM criteria_maker m 
INNER JOIN criteria_product p ON m.id = p.maker 
WHERE p.price < ?;
 ProductServlet.javaで結果を表示します。
package com.yamicha.criteria;

import javax.servlet.annotation.*;
import javax.ejb.*;
import javax.annotation.*;
import javax.servlet.*;
import javax.servlet.http.*;
import javax.persistence.*;
import java.io.*;
import java.util.List;
import java.util.ArrayList;

@WebServlet(name="productservlet" , urlPatterns={"/*"})
	public class ProductServlet extends HttpServlet{
	@EJB(beanName="ProductAccess") private ProductAccess pa;

	public void doGet(HttpServletRequest request ,
		HttpServletResponse response) throws IOException{
		doPost(request , response);
	}
	public void doPost(HttpServletRequest request ,
		HttpServletResponse response) throws IOException{
		response.setCharacterEncoding("UTF-8");
		response.setHeader("Content-type" ,
			"text/plain;charset=UTF-8");
		PrintWriter out = response.getWriter();

		pa.clear();
		pa.regist();

		out.println("価格が 600000 より安価な製品:");
		List<Product> products = pa.getProducts(600000);
		for(Product product : products){
			out.println(product.getName() + "\t" +
				product.getPrice());
		}

		out.println();
		out.println("価格が 700000 より安価な製品を持つメーカー:");
		List<Maker> makers = pa.getMakers(700000);
		for(Maker maker : makers){
			out.println(maker.getName());
		}

		out.close();
	}
}
 @StaticMetamodelを使えばまだマシ(Metamodelクラスを書く手間はありますが、IDEによる生成を前提とするなら矛盾はなし)ですが、できることならもう少し簡素に書けたなら、の一言です。
カテゴリ [開発魔法][社会問題] [トラックバック 0][コメント 0]

[1] [2] [3] [4] [5] 次のページ->
- Blog by yamicha.com -