yamicha.com's Blog - Presented by yamicha.com
Blog yamicha.com's Blog - 2017/09 の記事
[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
カテゴリ表示
 カテゴリ 社会問題 に当てはまるもののみを表示します。

 存在する記事 733 件の中から 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年参院選
2010/07/14(Wed)00:19:30
 2010年の参院選は、自民党が改選第一党の大健闘となりました。
自由民主党 51
民主党 44
みんなの党 10
公明党 9
共産党 3
社民党 2
たちあがれ日本 1
新党改革 1

 まずは本選挙の評価点ですが、ひとまず例によって幸福実現党が当選にかすりもしなかったのは幸いでした。二大政党制の是非を問うたり、民主党政権へ物申す以前に、このような政党が下手にのさばった日にはたまったものではありませんので、最低限の良識は示せているといえるでしょう。守護霊に話を聞いて外交するような政党から議員を出すほど国民はバカではないのです。
 各党の多くのタレント候補があっさり落選した点も、悪くない結果であるといえます。特に民主党は歌手や落語家など多くのタレントを擁立していましたが、その大半が落選しました。実際のところ、比例では落選はしても候補者名の票は政党に加算されるため、タレント候補本人が落選したからといって直ちにタレント戦略が奏功しなかったとはいえませんが、少なくともタレント候補の大半はあまり票を獲得できなかったと評することはできますし、何より政治に無知で名だけは売れているどうしようもない人間が議員になるのは阻止できます。
 また、一体何を血迷ったのか、シルバー新党ことたちあがれ日本が擁立した杉村氏は、比例候補9名のうち下から4番目の順位しか獲得できず、当選候補の片山氏に4倍近い差をつけられてあえなく落選しています。得票にして31146票ですが、むしろ3万人もの人が氏に投票したこと自体が驚愕です。一体何を考えているのでしょうか。
 他方、本選挙には非常に残念な部分もあります。まず何より悔やまれるのは、民主党候補で柔道の谷氏が当選してしまった点です。結果的に民主党のタレント戦略は一部で大成功を収めてしまったことになり、政治家はますます国民を愚弄したタレント選挙を展開する恐れがあります。しかも獲得票数は352594票と民主比例で2位の大健闘で、同党の比例票総数の2%近くを占めています。本来、タレント候補はことごとく落選させ、政治家に対して「もはやタレントなど立てようが意味がない」と知らしめる必要があるはずなのですが、残念でなりません。また、ひとまず落選はしたものの、落語家の桂氏が47792票、歌手の庄野氏が43405票を獲得しており、残念ながら民主党にそこそこの得票をもたらしています。
 もう1つ残念なのは、新党改革が2.01%の票を獲得してしまい、得票2%以上とされる政党要件を僅差で満たしてしまった点です。政党乗っ取りによる政党交付金詐欺に対して毅然とした結果を下せれば、今後はそのような詐欺まがいの方法を用いようとする政治家も減ったはずなのですが、これは非常に残念です。ただ、「あの」舛添新党がたった1議席しか獲得できなかったばかりか、政党要件ギリギリであった点を考えれば、これはこれで十分に厳しい結果が下ったといえるかもしれません。

 以下、各党の勝因・敗因や今後の展開についても触れておきます。
 今回の選挙は自民党の勝利といえるものでしたが、私としてはこれも非常に残念でなりません。なぜなら、今の自民党は重体になった後の病み上がりであり、本来なら療養しなければならない体であるためです。
 自民党一党独裁の時代は終わり、これまでの自民党の役目も終わりました。しかし、今後の自民党には二大政党の片方を担うという新しい役目があり、そのためには自民党には必ず復調してもらわなくては困ります。そして、いずれは政権の座に返り咲くこともあるでしょう。
 しかし、私が見る限りにおいては、自民党はまだ復帰の時期にありません。今回は民主党の敵失のおかげで勝てましたが、実際の自民党はまだ重症のレベルです。敗戦の責任を党名に押し付けて「和魂党」と言い出したり、他の有力・優秀・経験豊富な草の根の議員を差し置いて元有名首相の「世襲」息子を積極的に表に出すようなことをしている限り、まだ復帰は早すぎます。一方、これらのような行いを決してしない政党に生まれ変われば、政権を担えるだけの土壌が整ったといえます。
 この状態で無理に復帰したところで、自民党は再び安部・福田・麻生各氏と似たような醜態をさらすだけです。そしてそれは、国民をさらに深く幻滅させる結果へとつながります。できればこの参院選では引き分け、次の参院選への布石を作りつつ党を立て直すのが、おそらく自民党にとっての最適なパターンでした。
 「和魂党」などと正気の沙汰ではない案を言い出した谷垣執行部のことですから、これから何をやりだすか不安でなりませんが、ここはあえて自制的に行動し、まずは党の状態を回復するのが良い結果を生むはずです。まだ重症のうちに下手な行動を取れば、それは直ちに安部・福田・麻生体制の再来とみなされ、即座に幻滅されてしまうのは確実です。
 一方、政権交代後初の選挙であっさり敗北してしまった民主党ですが、敗因として消費税があるのは間違いないでしょう。ただし、消費税を最初に言い出した自民党が勝利し、消費税を上げるべきでないと主張していた弱小政党の多くが苦戦した以上、消費税を言い出したこと自体が直ちに敗北に結びついたわけではないのは明らかです。
 菅氏の失敗はおそらく2つあります。まず1つ目は、消費税増税を法人税減税とセットにしてしまった点です。なぜ政権交代が成し遂げられたかといえば、自民党の体たらくに加えて同党があまりにも経団連と深く癒着しており、国民は自民党を通して経団連に「NO」を突きつけた側面がありました。そして、民主党には経団連に支配されない政策が望まれていました。
 ところが、菅氏はよりにもよって「消費税を上げて法人税を下げる」と言い出してしまいました。これが激しい幻滅を呼んだのは想像に難くありません。国民は政治家が考えているほど愚かではなく、国家財政が消費税なしにはどうにもならない段階まで来ていることは多くの人が認識しているはずですが、それなら当然消費税は不足している財源に充当されなければなりません。雇用や所得の問題が山積する一方、大企業は未曾有の利益を上げるなどした状況に矛盾を感じ、衆院選で民主党に世直しの一票を投じた人は、どれほど幻滅したことでしょうか。
 その後、菅氏は法人税減税を優遇措置の廃止でまかなうこと、消費税見直しの際には所得税の最高税率引き上げも検討することなどを主張しましたが、あまりにも後付けの印象が強く、本当にそれをするのかどうかも疑わしい始末で、なおさら幻滅を招いたはずです。大体このような案は十分な試算が必要なはずで、行き当たりばったりにやってもろくな結果を生みません。
 そして菅氏のもう1つの失敗は、消費税に関する主張があまりに変移しすぎてしまった点です。世の中には短期的利益のみを重視する人もいますので、「消費税」を言い出すだけでもある程度の支持を失うのは避けようがありません。しかし、逆に消費税の必要性について十分理解している人も存在しますので、そのような人からの支持は獲得できます。そして、最近はあえて消費税を言い出したとしても、支持の拡大が狙えるバランスになりつつあります。
 ところが、菅氏の発言はあまりにも揺れ動いており、これが不安を与える原因となりました。しかも最後には「消費税を上げる際には必ず衆院解散で信を問う」と大幅に後退した主張を始めてしまい、すぐにでも消費税問題に着手して一刻も早く財政再建すべきと考える人々にとどめを刺してしまいました。当然、消費税を嫌う人々からの支持がこれで戻るわけもなく、その結果がこの参院選です。
 すなわち、消費税増税分の全額を福祉などに回すことを明言し、法人税については減税するなら優遇措置の廃止で財源を確保し、消費税には絶対に手をつけないと約束、さらに所得税最高税率見直しも最初から主張し、しかもこれは必ず消費税とセットであると最初から言っていれば、ここまで最悪の状況にはならなかったどころか、かなりの善戦が期待できたはずなのです。明らかに菅氏の大失態でした。
 また、これは菅氏ではなく鳩山・小沢体制時の問題ですが、タレントの擁立がかなり民主党支持を減らしてしまった可能性は十分にあります。例えば柔道の谷氏ですが、知名度ゆえに大量の得票があった一方、多くの人が幻滅して民主党を見限った可能性は非常に高いといえるでしょう。これは落語家・歌手・野球選手なども同様です。
 その点、みんなの党は堅実な人選で差別化を図った好例でした。二大政党がタレントに走り、元野球選手や杉村氏を擁立する狂気を示したたちあがれ日本、党首自身がパンダである新党改革など、弱小政党もタレントで力の弱さをカバーする一方で、みんなの党はタレントめいた人が少ないながらも大躍進を果たしました。しかも比例当選者の多くが堅実な顔ぶれです。タレント競争に乗らないことが逆に好感を持たれたと推測しても、誤りではないはずです。
 民主党に限らず政治家は、いい加減にタレント選挙は無駄だと学ぶべきでしょう。谷氏を擁立するなどした民主党にも、負けじとタレントを立てるばかりか元人気首相の世襲息子を重用する自民党にも、この認識が必要です。
 他に民主党が敗北した原因としては、やはり小沢氏が挙げられます。菅氏が代表に就任し、選挙態勢に突入した後にも、小沢氏が余計な口出しをしたせいで党内が混乱し、それを見た国民が民主党に幻滅する結果となりました。菅氏が消費税その他で踏み込んだ発言ができなかったのも、小沢氏が原因の1つとしてあるはずです。
 しかも、今回の参院選惨敗を受け、小沢氏サイドからは菅氏の責任を問う声まで出てきている始末です。一体何の冗談なのでしょうか。前代表の政策運営を散々支配して党の人気を落とし、菅氏が就任した後には内紛を起こしてさらに傷を拡大し、案の定敗北したら責任問題を口にするのですから、あきれて物も言えません。
 したがって、民主党は小沢勢力に党運営を乗っ取られないように注意が必要です。確かに民主党現体制は敗北しましたが、それは小沢氏によるところが非常に大きいのです。ここで小沢体制が再び完成しようものなら、今度こそ民主党は存亡の危機に立たされるでしょう。
 政党以外では、経団連にも気になる動きがあります。会長の米倉氏曰く、「民主党は消費税が原因で敗北したのではない」というのです。そのような側面があるのは事実ですが、他ならぬ経団連会長がそれを言い出す点が引っかかります。米倉氏の手腕は今のところ未知数ですが、この分ではなかなか油断のならない人物かもしれません。
カテゴリ [社会問題] [トラックバック 0][コメント 0]

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