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
さよなら参画またしても失格
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]
<- 前の記事を参照 次の記事を参照 ->

- Blog by yamicha.com -