Hatena::ブログ(Diary)

映画は中劇 このページをアンテナに追加 RSSフィード Twitter

2018-04-08

[] 土俵上の「女人禁制」の撤廃を求めます

本場所、巡業その他における土俵上の「女人禁制」の撤廃を求めます。それは性別についての差別だからです。

書きたいことは以上で終わりですが、愛想がないのでもうちょっと続けます。

4月4日の舞鶴巡業で、来賓の舞鶴市長があいさつ中に倒れました。この際、土俵上で救命措置をおこなった女性に対して、行司や年寄が土俵を降りるよう求めました。

さらには6日の宝塚巡業で、土俵に上がってあいさつすることを要求した宝塚市長の中川氏に対して、相撲協会は、氏が女性であることを理由に拒否しました。

いずれも明白な差別です。もちろん、これらの差別事件は何の脈絡もなくいきなり起きたのではなく、「女人禁制」自体の差別性がこの二日間に露呈した、ということです。

6日の中川発言については、舞鶴の事件に便乗し、政治的に利用したものであるとして、批判する声をいくつか目にしました。以下では、この点について論じたいと思います。

まず、中川氏自身が差別の当事者である、ということを認識する必要があります。現に差別を受けた人に対して、状況やタイミングがどうこうであるから声を上げることを慎め、と求めることは不当です。

また、中川氏は自治体の長であるという点で影響力の大きな政治的主体でもあります。今このタイミングで、氏がなにも声を上げないとしたら、消極的にであれ、「女人禁制」を支持することになります。あっちかこっちかであって、中立はあり得ません。この点をあいまいにせず、態度をはっきりと示した中川氏はえらいし、その要求、発言の内容も正当なものだと思います。

「なにも声を上げないとしたら、消極的にであれ、『女人禁制』を支持することにな」るということは、当然ながらファンである私自身にも跳ね返ってくることです。どうしましょう。五月場所で署名集めでもしようかしら。

相撲興行は、その時々の世間に阿って伝統をでっち上げたり *1 、弾圧を避けるためになかったことにしたりして *2 、300年間のらくらと人気を取ってきた文化です。「女人禁制」を撤廃することくらいはわけもないことで、それによって何が失われるわけでもありません。

*1:横綱の地位、土俵入りの所作などなど。

*2:行司の装束、あるいは「女人禁制」それ自体。

2018-03-04

[] 梁英聖『日本型ヘイトスピーチとは何か』(2016)

梁英聖『日本型ヘイトスピーチとは何か』(2016)を読了しました。タイトルは「ヘイトスピーチ」ですが、中身は現代日本におけるレイシズム全般を扱っています。自分の中でモヤモヤしてた部分について、きわめて明瞭に整理の方向付けをしてくれています。

日本型ヘイトスピーチとは何か: 社会を破壊するレイシズムの登場

日本型ヘイトスピーチとは何か: 社会を破壊するレイシズムの登場

モヤモヤしてた部分とは、次の二点です。

  • a. 世界的な右傾化の中で、日本では、alt-right的な跳ねっ返りではなく、既存保守勢力がそのまま極右にスライドしている。差別扇動という点で典型的には石原慎太郎。門閥→極右という点で典型的には安倍晋三。こりゃなんだ?
  • b. 「ヘイトスピーチの法規制」について。これは原理的に表現の自由と衝突するし、橋下「日本人に対するヘイトスピーチ」、あるいは石破「デモはテロ」やトランプ「fake news」のように、用語の簒奪によって、反動に利用される危険がないか。確立された法や規範の上で戦う方が良いのではないか。

a. 日本における極右化の特徴的様態について

まずはaについて。

丸山眞男「日本ファシズムの思想と運動」は、1930年代〜の日本において、独伊とことなって、お歴々による国家主義が草の根のファシズムを最終的に圧倒した、ということを指摘しています。現在の極右化の様態についても、同じように考えられるのだろうと思いつつ、それではあまりに大雑把だし、そもそも丸山の立論もあまり明確ではない。モヤモヤ。

本書は、日本においてレイシズム自体を規定・禁止する法がなく、また規範も確立していないこと、また植民地出身者の諸権利および国籍を剥奪した上で、「入国管理のための1952年体制がそのまま外国人政策を代用する」(p. 128) 構造が続いていることを指摘しています。

また関連して、戦争責任・植民地支配責任がまともに総括されなかったため、歴史否定を批判する規範も成立していない (pp. 271-274)。そもそも真相究明自体が不足している(pp. 301-302)。

つまり、体制自体に差別が根ざしているので、alt-rightが出るまでもない、というのが主たる指摘です(p. 267)。

b. 「ヘイトスピーチの法規制」の是非について。

ついでbについて。

aの議論を踏まえると、ヘイトスピーチについて「確立された法や規範の上で戦う」ことは無理筋か、少なくとも不充分だ、ということは納得できました。在日コリアンの反差別運動は、原則から差別的な制度の中で、限定的な権利獲得闘争にとどまることを強いられています (pp. 127-128)。

また、「ヘイトスピーチ」という概念自体が、米国の特殊な文脈から発しており、注意が必要であることも指摘しています。いわく、米国では公民権運動の中で、差別行為を規制する一方、言論は差別的なものであっても擁護する法・規範が形成されました。これは、反差別運動の側からすると、武器としての言論がつぶされることを懸念したためです。「ヘイトスピーチ」は、この米国に固有の二分法に対する異議申し立ての中で提出された概念です(pp. 215-218)。

このような状況では、ヘイトスピーチ規制以前に、そもそも「人種差別撤廃条約の理念にもとづいた反レイシズム法を作らせることが重要」 (p. 289)。

まとめ

以上、自分の従来の関心にもとづいてまとめましたが、本書は個別の暴力の事例から、戦後民主主義の構造まで、広範な射程を貫徹した構成で論じる、きわめて意欲的な本です。最後の章は、著者が代表を務める反レイシズム情報センター(ARIC)での経験を元に、具体的にレイシズムをなくしていくための実践についての試論でしめられています。ジャンルによらず、魂のこもった本に出会うことはまれですが、この本はまさにそれです。

正直言って、読んでいる間は暗澹とした気持ちにならざるを得ないのですが、すべての人にとって必読の本だと思います。

2017-12-28

[][] ForkJoinPool vs ThreadPoolExecutor

12月27日のJJUGナイトセミナーLT大会に参加しました(LT資料)。

会場片付けの際、マルチスレッド処理に関して発表された @hiroga_cc さんと、ForkJoinPoolThreadPoolExecutorの使い分けについて、少しだけおしゃべりしました。その場では頭がこんがらがってしまったので、改めて整理します。

要旨

ForkJoinPoolは、次のようなジョブが効率的に実行できるように設計されたExecutorです。

  • 各タスクがIOをともなわない、CPUヘビーな処理であること。
  • 各タスクの処理が、新しいタスクを産み出すような、再帰的タスク構成であること。

上記の条件を満たさないジョブに対して、ForkJoinPoolが使えないというわけではありません。ただし、タスク発生状況に応じてに応じてスレッドの生成・破棄を制御したい場合などは、ThreadPoolExecutorの方が適しています。

構成と動作

ForkJoinPool, ThreadPoolExecutorとも、下記の点では共通しています。

  • マルチスレッドで、並列にタスクを処理するための仕組みである。
  • ワーカースレッド群と、タスクキューの組み合わせで構成される。

異なる点はタスクキューの構成と取り回しです。ForkJoinPoolでは、ワーカースレッドが可能な限りブロックせずに動作し続けられるように、各ワーカースレッドにひもづいてタスクキューが用意されます。具体的な構成・動作の差異は次のとおりです。

  • ThreadPoolExecutor
    • 全ワーカースレッドがひとつのタスクキューを共有する
    • タスクの投入は共有のタスクキューに対して行う (→ 競合しやすい)
    • ワーカースレッドは共有のタスクキューからタスクを取得する (→ 競合しやすい)
  • ForkJoinPool
    • 各ワーカースレッドが自分のタスクキューを持っている
    • ワーカースレッド内で発生したタスクは、自分のタスクキューに投入される (→ 競合しにくい)
    • ワーカースレッドは、まず自分のタスクキューからタスクを取得する (→ 競合しにくい)
    • 自分のタスクキューにタスクがない場合のみ、他のスレッドのキューからタスクを盗む (work-stealing) (→ 競合しやすい)

ForkJoinPoolでは、ワーカースレッド内で発生したタスクをさばききるまで、自分のスレッドにひもづいたタスクキューだけにタスクの投入、取得を行います。このため、スレッド間競合にともなうブロックなしに計算が続けられます。

IO

タスクの処理がIOをともなう場合、上述したようなForkJoinPoolの利点は消し飛びます。IOは各スレッドが共有するリソースであるため、複数のスレッドが同時にIOを行うと、そこで競合が発生するからです。またIOは、タスクキューの取り回しに比べてはるかに時間のかかる処理であるため、上述したForkJoinPoolのメリットはかき消されます。

上述のとおり、このような場合にForkJoinPoolが使えないわけではありませんが、ThreadPoolExecutorの提供する機能の方が望ましいことが多そうです。

IOによってスレッドがブロックすること自体を避けたい場合は、NIONettyによるノンブロッキングIOを組み合わせることも選択肢となります。

2017-11-30

[] 日馬富士関の引退に寄せて

横綱日馬富士が、酒席で貴ノ岩を殴り、その責を負って引退しました。引退はしかるべき対処でしょう。 *1 また、九州場所を全休した貴ノ岩の軽快を祈ります。

日馬富士は、ものすごく直接的に胸を衝く相撲を取る人でした。決して大きくない体と、気迫と魂を相手にまっすぐ全部ぶつける人でした。攻勢一辺倒の横綱といえば他には朝青龍ですが、朝青龍の相撲が、生の歓びの横溢する祝祭的な感じを与えたのに対して、日馬富士の相撲は、土俵に命が掛かってるんだ、という戦慄を与える種類のものでした。

横綱昇進前後の、絶好調と絶不調が交互に訪れる不安定な成績は、遊びのない取り口の必然的な帰結だったのでしょう。絶不調の場所で、それでも綱の体面を保つため、星を稼ぐ窮余の策が当たってすぐの左上手投げで、しかしこれが絶品でした。場所によっては勝ち星のほとんどを左上手投げ一本で稼いで、しかもめったに失敗しなかった。そうこうしている内に、出し投げ主体の曲線的な組み立てへと間口を広げて、安定して綱が張れるようになったのは本当に立派だったと思います。

全身に故障を抱えて、千枚通しのような、鋭いってなもんじゃない立ち合いを十五日間続けられなくなった後でも、ここぞの一番では爆発的な相撲を取ってくれました。弟弟子である照ノ富士の初優勝が掛かった白鵬戦、あるいは新横綱稀勢の里との対戦などなど。九度の優勝、三度の全勝という成績も大変なものですが、それだけでは計り知れない印象を残した横綱でした。

妹が大ファンなんですよね。心配になるくらいほっそい安馬の時代から応援していて。当時から負けん気と向こうっ気はすごかったけど、まさか横綱を張るまでになるなんて思いもしなかった。

*1:昔なら許されたが今では、ということですらない。玉錦と同時代の関脇新海は、同様に酒席で同僚を殴った廉で引退しています。

2017-11-19

[] JJUG CCC 2017 Fallの記録

11月18日に開催されたJJUG CCC 2017 Fallに、スタッフとして参加、およびセッションでしゃべってきました。

一日中セッション部屋担当で、なんかアナウンスしたり、「N分前」の紙を出したり、Twitterのハッシュタグを賑わしたりしていました。

AsciiDocとPlantUMLでドキュメント作成 by 梅澤雄一郎さん #ccc_a1

軽量マークアップ言語であるAsciiDocと、ドキュメント生成系の基盤一式について。

Kinkのマニュアル生成にはreStructuredText+Sphinxを使っているのですが、記述の素直さという点ではAsciiDocに軍配が上がるようです。機能面で便利だと思ったのはコード内にアンカーが付けられるところ。

「GitHub Flowを使いたいがためにGitを使っている」には大賛成です。商用システムの開発において、分散SCMの利点はブランチ・マージがしやすいところにあります。ブランチ・マージを効率的・安全に回すフローを定義して、フローを支援する環境を整備しなければ、宝の持ち腐れどころか、野放図なバージョン管理(管理?)という害悪をもたらすだけだと思っています。

Apache Cassandraを使ったJavaアプリケーションの作り方 by 森下雄貴さん #ccc_a2

CassandraのサンプルアプリケーションであるKillrVideoを題材にして、今風のシステム間連携のやり方を見ていこうぜ、というセッション。

GuavaのEventBusというクラスの存在を知りました。プロセス内のPub/Sub型メッセージバスみたいです。なんか便利かも。

Spring Bootの本当の理解ポイント by 多田真敏さん #ccc_e3

Springコンテナの仕組みと、Spring Bootの役割。Spring Bootは、Springの世界でCoC (Code over Configuration, 設定よりも規約)を実現するための設定ファイル群だよ、という話でした。

スライドも話も実に分かりやすく、ツボをおさえて、さすがはプロの講師、という感じでした。直後の登壇者としては大プレッシャーです。

Java SE 9の紹介: モジュール・システムを中心に by 宮川拓 #ccc_e4

自分のセッション。Java SE 9のモジュール・システムの話+おまけ程度にその他のアップデート、という内容です。どうにもごちゃっとした話をしてしまったなあ、と思いつつ、しかし実際問題ごちゃっとした領域なわけで、もやもやしています。

モジュール・システムについて、理想形を話すのであれば綺麗にまとめられるはずなのですが、聴衆の期待を考えると、むしろ導入時につまづきの石になるだろう部分に重点を置きたい。つまづきの石について話すためには、既存の仕組みとのあいだの弥縫策や、ワークアラウンド的な道具立てについて、ひととおり触れなきゃいけない。分量も多くなるし、ややこしい話にもなる。結局、ひととおりブチ込んで頑張ってしゃべる、という方針でのぞんだのですが、果たしてよかったのかどうか。

目にする反応は総じて悪くなかったので、救われました。

また、一点スライドの補足。

p. 47に「Oracle JDKでは、外部モジュールの非公開メンバへのリフレクションが可能」とありますが、これはOpenJDKでも同じ動作です。「HotSpot系の」とすべきところでした。 *1

速いソートアルゴリズムを書こう!! 松原正和さん #ccc_m8

1. クイックソート+ワークメモリによる安定ソート化変種、 2. マージソートの分割を3分割にすることによる高速化、 3. マージソートの省メモリ化、という3つのアルゴリズムについてのお話でした。

マージソートって3分割でも計算量変わらないんですね。へーと思ったけど理屈は分かっていない。

Design Pattern in Presto source code by 曾臻さん #ccc_m9

  • スライド: まだ公開されてない?

分散クエリエンジンであるPrestoの実装を題材として、Template MethodパターンとVisitorパターンを紹介する、という内容でした。

「Visitorパターンはデータ構造があまり変わらず、適用する処理が多岐にわたる場合に有効」というような整理がされていて、なるほど、と思いました。Visitorインタフェースはデータクラスに依存するので、データ構造の変更には弱いわけですね。

Javaで使えるもう一つのコンパイル方式 - AOT by 西川彰広さん #ccc_m10

JDK9 on Linuxでは、ネイティブバイナリへのコンパイル (Ahead-of-Time Compilation) ができるよ!という話。

AWS LambdaやCloud FunctionsのようなServerless環境や、その他コンテナ環境では、プロセス起動が速いことが重要だけど、この点Javaは弱かった。AOTコンパイルであらかじめバイナリを作っとくことで、若干マシになる、ということです。モジュール・システムの導入にも、同様の問題意識が反映されているものと認識しています。

ただ、サーバサイドJavaは、エコシステム全体が常駐型プロセスを指向しているので、処理系の工夫だけでは足りない面もありそうです。

DBのTCPプロトコルとJDBC by Yohei Yamanaさん #ccc_m11

MySQLとPostgreSQLの、リモートクライアント接続プロトコルの中身の話。

SQLってそのままポコンとDBMSに送られるんですね。クエリエンジンはDBMS側にあるんだからそりゃそうか。あとでYamanaさんに伺ったところ、クライアント側でも最低限のチェックはしているけど、結局サーバ側に行かないと十分な解析・チェックはできない、とのことでした。

Java x ArduinoのIoT アーキテクチャパターン by 山本ユースケさん #ccc_m12

  • スライド: まだ公開されてない?

楽しいArduinoデモ。LEDをチカチカさせたり、プレゼン用マウス的なものを作ったり。

Arduinoのプログラムは独自言語で書くのでJavaは使えません。しかし、FirmataというプロトコルでArduinoデバイスをホストコンピュータから叩くことができ、firmata4jというJava実装もあるよ、という話でした。

総括

一緒に部屋担当についたボランティアスタッフの方々の活躍により、かなりスムースに運営できたと思います。ありがとうございます。おかげで、スタッフとしての参加でありながら、上述のとおり聴講者としても満喫してしまいました。知恵熱が出そうです。

それから、朝晩ちょっとした荷物を運んだだけで、上半身がえらい筋肉痛です。ふだんいかに運動していないか思い知らされます。

*1:Slideshareがスライド再アップロードできない仕様になっているため、訂正できませんでした。

2017-11-10

[][] 自動モジュールと無名モジュールのアクセス権とアクセシビリティ

Java SE 9のモジュール・システムには、古いコードベースからの移行のために、二種類の特殊なモジュールが存在します。自動モジュール (automatic module) と、無名モジュール (unnamed module) のふたつです。

自動モジュールは、典型的には、モジュール・レイヤーを構成するモジュールのうち、module-info.classを持たないものです。たとえば、モジュールパス上に存在するJARファイルのうち、module-info.classを持たないものは、自動モジュールとして読み込まれます。JARのマニフェスト (META-INF/MANIFEST.MF) にAutomatic-Module-Name属性が存在する場合、その値が自動モジュールの名前となります。Automatic-Module-Name属性がない場合は、JARファイル名にしたがってモジュール名が決定されます(cf. ModuleFinder.ofのJavadoc)。 Automatic-Module-Name属性の有無は、モジュール名以外には影響がありません。

自動モジュールのアクセス権とアクセシビリティは次のように定義されています(cf. ModuleDescriptorのJavadoc)。

  • 同一モジュールレイヤー上のすべてのモジュールをreadする。
  • すべての無名モジュールをreadする。
  • すべてのパッケージをexportする。
  • すべてのパッケージをopenする。

無名モジュールは、モジュール・レイヤーに属さないモジュールです。たとえば、クラスパス上のクラスファイルは、無名モジュールに属します。

無名モジュールのアクセス権とアクセシビリティは次のように定義されています (cf. JVMS9 §5.3.6)。

  • すべてのモジュールをreadする。
  • すべてのパッケージをexportする。

module-info.javaでは、自動モジュールに対するrequires文を含むことはできますが、無名モジュールに対するrequires文は不可能です。したがって、たとえば、クラスパス上のクラスをコンパイル時に触ることはできません。実行時に、たとえばリフレクションを通じて触るためには、たとえばModule.addReadsを用いたアクセス権の変更が必要です。

2017-11-08

[][] 実行時におけるJava SE 9モジュールとクラスローダーの関連

Java SE 9のモジュール・システム(Jigsaw)はコンパイル時と実行時の両方で機能します。実行時には、Java SE 8以前から存在するクラスローダーの機構とうまく帳尻を合わせて、既存のアプリケーションを壊さないようにする必要があります。結果として、両者の関係は微妙で奇妙なものとなっています。

下記の図は、クラスローダー、モジュールその他の関連をIDEF1X記法で示したものです。

http://d.hatena.ne.jp/miyakawa_taku/files/2017-11-08_class_loaders_and_modules.png?d=.png

クラス、パッケージ、クラスローダー

これらの部品は、Java SE 8以前と同様に、Java SE 9でも機能します。

(1) クラスローダーがクラスを定義すると、そのクラスは、クラス名とクラスローダーにもとづいて、実行時パッケージに紐付けられます。

(2) 実行時パッケージは、パッケージ名と、パッケージ内のクラスを定義するクラスローダーの対によって指し示されます。

モジュール、モジュールローダー

(3) Java SE 9では、実行時パッケージは実行時モジュールに紐付きます。

(4) モジュールにはふたつの種類があります。名前付きモジュール *1 と無名モジュールです。

(5) ModuleLayer.defineModulesの呼び出しによってModuleLayerが作られると、引数として渡されたConfigurationにもとづいて、名前付きモジュール群が作られます。名前付きモジュール群はモジュールレイヤーに紐付けられます。

(6) 名前付きモジュールは、ModuleDescriptorにもとづくパッケージ群を持っていて、両者の関連は互いに不変です。

(7) 名前付きモジュールは、ModuleLayer.defineModulesメソッドで指定されたクラスローダーに紐付けられます。

同名のパッケージを含む複数の名前付きモジュールを、ひとつのクラスローダーに紐付けることはできません。パッケージは複数のモジュールにまたがれないためです。このような状況を防ぐため、ModuleLayer.defineModulesメソッドは不変条件をチェックして、違反があればLayerInstantiationExceptionを投げます。たとえば、クラスローダーがorg.example.Fooクラスを既に定義している場合、ModuleLayer.defineModulesメソッドは、このクラスローダーにorg.exampleパッケージを含む名前付きモジュールを紐付けられません。

(8) クラスローダーには、ひとつの無名モジュールが紐付いています。クラスローダーがクラスを定義するとき、そのパッケージが、クラスローダーに紐付けられたどのモジュールにも紐付けられていない場合、そのパッケージはクラスローダーの無名モジュールに紐付けられます。ここで、無名モジュールはどのモジュールレイヤーにも属さないことに注意してください。

クラスローダーとモジュールレイヤーの間の関連には、直接の制限はありません。たとえば、ひとつのクラスローダーが、複数のモジュールレイヤーにまたがってクラスを定義することも可能です (JVMS9 §5.3.6) 。ただし、そのような構成に実際上の利点はなさそうです。

[][] Runtime relationship between class loaders and Java SE 9 modules

The Java SE 9 module system, or Jigsaw, works at both compile-time and run-time. At run-time, Jigsaw must work well together with the old class loader mechanism, without breaking existing applications. It has resulted odd and subtle relationship between them.

The diagram represents the relationships among class loaders, modules and related components in the IDEF1X syntax.

http://d.hatena.ne.jp/miyakawa_taku/files/2017-11-08_class_loaders_and_modules.png?d=.png

Classes, packages and class loaders

These components exist from Java SE 8 and earlier, and work the same way on Java SE 9.

(1) When a class is defined in a class loader, the class is bound to a runtime package determined by the name and the defining class loader.

(2) A runtime package is determined by the pair of the name and the class loader, which defines classes beloging to the package.

Modules and module layers

(3) On Java SE 9, a runtime package is bound to a runtime module.

(4) There is two subtypes of modules: named and unnamed *2.

(5) When a ModuleLayer is created invoking ModuleLayer.defineModules, a set of named modules are crated in accord with the configuration, and bound to the ModuleLayer.

(6) A named module has an immutable set of packages, which is specified in its ModuleDescriptor.

(7) And the named module is bound to a class loader specified by the invocation of ModuleLayer.defineModules.

A class loader cannot be bound to by multiple named modules which contain an overlapping set of packages, because a package cannot split across multiple modules. Hence ModuleLayer.defineModules checks invariants to avoid such situation, and throws LayerInstantiationException if any violation is detected. For example, if a class loader has already defined the class org.example.Foo, ModuleLayer.defineModules cannot map a module which contains the package org.example to the class loader.

(8) A class loader has an unnamed module. When a class is defined in a class loader, and its package is not bound to any named module bound to the class loader, the package is bound to the unnamed module of the class loader. Note that unnamed modules are not bound to any module layer.

There is no direct restrictions for the relationship between class loaders and module layers. For example, a class loader may define classes in multiple module layers (JVMS9 §5.3.6), though there is no practical use case for such a configuration.

*1:「名前付きモジュール」という用語は、ModuleDescriptorのJavadocで暗黙的に定義されています。

*2:The term “named module” is implicitly defined in Javadoc of ModuleDescriptor.