日々の破片

_ ストーミーウェザーと有頂天時代（その顔は黒いか）

どちらが先かは記憶が定かではないが、多分、ストーミーウェザーが先だと思う。

ストーミーウェザーは、僕の記憶では、第二次世界大戦中に、米軍の黒人兵のために、彼らを慰問するために作成された映画だ。それまでハリウッドのコードでは、召使いと奴隷以外の役回りで黒人を出演させることはなかったのが、黒人兵に対する慰問という大命題のおかげで、初めて黒人が主演で黒人がほとんどの重要な役を占める映画として作られた（はずだ）。

記憶では、ボージャングル（ビル・ロビンソン）の一代記になっていて、蒸気船の小僧として雇われたボージャングルがタップの才能を認められてショービジネス界に君臨するまでを描いていた。途中、キャブキャロウェイがズートで歌いまくり踊りまくったり、タイトルのストーミーウェザーはリナホーンが歌うのではなかったかな。一度聴いたら少なくとも冒頭のストーミウェザーのザーの下降ジャンプは忘れることができない名曲だった（というか覚えているのだが、キャブキャロウェイも歌っていたような記憶があるのは何だろう）。

なぜかわからないが、蒸気船の小僧として雇われたボージャングルが、他の船乗りに言われてタップを踏むシーンは記憶に残っている。一通りタップを踏むと、相手がwell educatedな足の持ち主だ！ と誉めるのだが、そのwell educatedという言い回しが気に入ったからだと思う。

このある時代を見事に切り取った傑作映画は、僕が確かユーロスペースで観るまで、日本では公開されなかったいわゆる封印映画だった。確か、記憶では、GHQが、黒人ばかり出てくる映画というものを恥じた（つまり国辱映画と考えた）だか何だか、つまるところ、通常のハリウッドコードを公開基準としたかららしい。

ストーミー・ウェザー [DVD](リナ・ホーン)

この時期、他にもGHQが国辱映画として封印した映画がいくつか公開されて、そのうち1つはジョンフォードのタバコロードだった。プアホワイトというのはこういうものだという映画なのだから、こちらはわからないでもない（先進的な民主主義の豊な国アメリカというものを価値観として押し付けるにはいささか問題があるというのは、GHQの立場に立てば理解できる）。

タバコ・ロード [DVD](チャールズ・グレープウィン)

それにしてもジョンフォードは大した監督だ。

で、おまけとしてキャブキャロウェイが来日して横浜のブントホテルでショーをやったのでわざわざ妻と観に行ったとか、2人組のタップダンサーがオリエンタルバザーの前を歩いていたとか、いくつかの記憶もある。

で、ボージャングルという名前を記憶しきったところに、RKO時代のアステア・ロジャースの有頂天時代がテレビで流されたので観たわけだ。もしかするとそのときはスウィングタイムというタイトルだったかも知れない。

すると、アステアが顔を黒く塗ってボージャングルのダンスを披露するシーンがあった。

その時、ストーミーウェザーの成立事情は知っていたのだと思う。それで、白人の観客たち（特に映画を観るしかない地方在住の人たち）は、どれだけ人気を博そうとボージャングルを観ることはできない（映画という手段はないわけだから）、それで代替物としてアステアが顔を黒く塗ってタップを踏むのかな、と納得したのを記憶している。

ただ、妙に荒々しさを強調した踊りで（もちろん、アステア固有の優雅な踊りとは趣を異にしている）、両脚を┌┐型に開いたジャンプを多用していて、それはストーミーウェザーで観たボージャングルの（これまた）優雅なタップ(とはいえ、既に老齢になっていたので本人が踏むタップはとても少なかったような記憶がある)とはえらく印象が違って、政治的な意図が透けて見えなくもなくて鼻白む思いをしたのは覚えている。

どう考えても、本来であればアステアはアステアとして、ライバルとしてボージャングルが彼自身で出演するのが映画としては正しかったのではなかろうか（だがそれはコードがある以上あり得なかったものだ）。

有頂天時代 THE RKO COLLECTION [Blu-ray](フレッド・アステア)

（というわけで、アステア・ロジャースの作品としてはトップハットのほうが遥かに好きだ）

というようなことを思い出す昨今の黒塗り顔についてのいろいろ。

_ 低レベルプログラミング

翔泳社の野村さんから低レベルプログラミングをいただいたのでレビュー（完全に読んだわけではなく、自分および少数の購買予定者のためのアジェンダ用にレビューしたというところ）。

著者はレニングラードの（こんなところで懐古趣味をひけらかしてもしょうがないが、そういう性格だからしょうがない、つまり聖ピョートルの都市のことだ）ITMO（と書いて国立情報技術機械光学研究大学、らしいのだが光学って本当なのか工学の誤記なのか謎）の先生で、多分、この本は副読本なのではなかろうか。どういう先生かというと、この先生のチームは、ACM-ICPCの国際大学対抗プログラミングコンテンストで6回優勝しているそうだ（少なくとも2017年の優勝は間違いない。というか3位は京城、7位が北京で、東京が12位なのか。韓国もすごいな）。

本書の目的がまえがきにある。7つの目標だ。

・アセンブリ言語で自由自在に書くことができる

・Intel 64のプログラミングモデルを理解する

・C11で、保守が容易で堅牢なコードを書ける

・コンパイルのプロセスを理解し、アセンブリリストを解読できる

・コンパイルされたアセンブリコードのエラーをデバッグできる

・適切な計算モデルを使うことで、プログラムの複雑さを大きく減らせる

・性能が重視されるコードを書ける

おお。少なくとも3は自信がないし、7と8は知りたい。

というわけで、なるほどACM-ICPCで優勝しそうな内容だ。

問題ががんがん入っていて、解答はGitHubにある（英語ですと書いてあるが、Apressの本だからロシア語というわけはないよなぁ）。

レポジトリには、すぐに使えるDebianのVMXへのリンクがあるので、すぐに実習ができるとのことだ（VMWareがあれば）。というか、これはうまい仕組みかも知れないと思った。

目次を見ると全体は4部構成。

1部はアセンブリ言語とコンピュータアーキテクチャ。

レジスタ、プロテクションリング、ハードウウェアスタック。なぜか10ページを使ってレガシーとしてリアルモードとプロテクトモードなどを説明、仮想メモリについていろいろ（効率とかメモリマップトファイルとか）、コンパイル処理、割り込みとシステムコール、計算モデルとしては、有限状態マシン、Forthマシン（スタックマシンのことだよな？）で、課題としてForthコンパイラとインタープリタ。はて、なぜこれが計算モデルの章なのだろう。

2部はプログラミング言語C。

基礎、型システム、コードの構造、構文のセマンティクスとプラグマティクス（意味と実際、なのだが、実際？ 実態ではないのかなぁとか思う）。唐突にアラインメントの話。

そして良いコードを書くにはとして、選択、カプセル化、不変性、アサート、エラー処理、メモリー割当、柔軟性など。C11で。課題として画像の回転と、カスタムメモリアロケータ（これは面白そう）。

3部はCとアセンブラの間。

変換処理の詳細。つまり関数コールのシーケンス、volatile、非局所ジャンプとsetjmp、inline関数、restrictポインタ……（最適化の変換処理のことか）

共有オブジェクトとコードモデル。この章は再配置とPIC、GOTとPLT、プリローディング。どうでも良いけど、章題と実態がおれの感覚とはずいぶん違うな（これまでのところもそうだ）。

性能。最適化、キャッシング、SIMD、SSE/AVX。

マルチスレッド。難しいのはなぜか？ 実行順序。強弱メモリモデル。volatile、メモリバリア、pthreadsの紹介（？）、セマフォ、Intel64の強さについて。ロックフリー。C11のメモリモデル。

付録。gdbの使い方。makeの使い方。システムコール（read、write、open、close、mmap、munmap、exit。性能テストの情報。参考文献。

520ページほど。

1部はどちらかというとトピックの紹介。アセンブリのリストはある。

たとえば有限状態マシンでは、最後に正規表現のNFAによる説明が2ページほどあって、問題117「よく知っている言語を使ってgrepに似たプログラムをNFAの構築によって実装してみよう。参考情報：Russ Cox. Regular expression matching can be simple and fast (2007)」

という感じ。

一方、Forthはそれなりの長さのサンプル実装（アセンブリ）を示してForthマシンを説明している。課題はForthインタプリタの実装（当然、アセンブリ。sete、setl、setz、cpo。呼び出し先の退避にはr13,r14,r15を使え。ということからx64の話とわかる。自信がなければGforthでしばらく遊べ。

1部が150ページくらい。

2部がC11。セマンティクスのところは後でちゃんと読む（ぱっと眺めたところ、おれはちゃんと理解していない（知識として言語化されていないという意味）ことがわかった）。プラグマティクスの意味（言語仕様外だが、プログラムの振る舞いに影響するもの）。アラインメント、パディング。

13章の良いコードを書くには、は、ソフトウェア工学の話になるようだ。

3部。

変換処理：calling conventionの概念を再考して理解を深め、コンパイラがソスコードをどのように変換するかを詳述。

保護機構として、スタックに埋め込むセキュリティクッキー。アドレス空間のランダム化（なるほど）。DEPはわかる。

共有オブジェクト：ELFを思い出そう。から始まる。ffiの世界だ。

性能：高速化の神話。性能テストは特殊化されているし。プロファイルをしろ。コンパイラ作者はばかではないというか鬼のように賢いから、みんながよく書くコードパターンが恐ろしく最適化されている。手作業で最適化するのは不健全（コードが読みにくくなるし、保守は難しくなる）

まず、アルゴリズムの選択が重要。

具体的なコンパイラの戦略：スタックフレームポインタ省略。末尾再帰。共通式の除去。定数伝播。戻り値の最適化。分岐予測の影響（お、おう）。このへんまではわかる。実行ユニットの影響。リード・ライトのグループ化、わからん。後で読む。キャッシング、プリフェッチ。なんでプリフェッチのところでバイナリーサーチが出てくるんだ？ メモリアクセスパターンが予測困難だから。valgrindのcachegrindモジュールを使って調べる。プリフェッチによってLast Levelキャッシュのミスが改善されている。なぜだ？後で読む。

キャッシュバイパス。巨大行列のアクセスでいかにシーケンシャルにアクセスするようにするか。ここでもvalgrind。

この章はおもしろい（しろそう）。

マルチスレッドがどう難しいか。

C11のメモリモデル。弱い。アトミックのサポート。メモリオーダリング。問題407：ミューテックスがあるとき、なぜ条件変数が必要なのか。問題408：メモリオーダリングでIntel64が保証するのは何か。といった問題が並ぶ。

付録。gdbってemacsで実行するのだと思っていたら（というか、そうやって実行しているのだが）、自分のXのGUIを持っているのか。知らんかった。

makeの説明はなんで？ というレベル。

システムコール。

システムコールをアセンブリで発行するのは簡単だ。対応するレジスタを正しいパラメータ値に初期化して、syscall命令を実行するだけである。

そりゃそうだ。

低レベルプログラミング(Igor Zhirkov)

というわけで、すごくまっとうな本でした。

追記：本書の内容例

あ、そうか。これは怖いな。setjmp前後でアクセスする変数はvolatile必須じゃん。 pic.twitter.com/FhDgku6F93

— arton (@arton) 2018年1月20日

_ 新国立劇場のこうもり

エレートのこうもり。

2011年、2015年に続いて3回目。

いやぁ、実に良いなぁ。

指揮はエシュヴェ。ウィーン風なのだろうが、ワルツが小学校のトライアングルの形の指揮のような正三角形ではなく、ほとんど2拍子で（そのため、どれがワルツでどれがポルカかときどきわからなくなる）緩急自在、オーケストラ（東京交響楽団）がちゃんとついてくるのが素晴らしい。2幕の途中でずっとボーっと低音の木管が鳴るところがあるのだがこのあたりも実に良いものだった。

冒頭、今回はコウモリ博士の手引きで歌手（アルフレード）が登場するのをきちんと確認できた。1幕最後にロザリンデに博士の手紙が届くところは、最初意味がわからなかったが、今となっては良くわかる。

2幕でアデーレがイーダと、だまされたと怒るところで、今回はっきりと、博士の陰謀に単に巻き込まれただけとわかったが、それにしては（物語上）すさまじくアドリブがきくので、これは確かに女優向きではある。幕がしまったあと、公爵と所長のどちらがパトロンになるかで揉めそうだ。

前回こうもりを見てから、今回までの間に、メリーウィドウやチャルダーシュの女王とか他のオペレッタも観たので、オペレッタのコンテキストは艶笑譚だと知ったわけだが、そういう見方をすれば、確かに、エイゼンシュタインが靴はどこだ？ と聞くところで、アデーレとロザリンデが同時に私のベッドの下と答えるところから、アデーレの立ち位置はすごく微妙だな、とか公爵の館でアデーレを認めたエイゼンシュタインの怒りが相当下司いとかどうでも良いところで見えてくる。

公爵は、去年薔薇の騎士でオクタヴィアンを歌った人。衣装あわせてものすごくフォトジェニックで素晴らしいのだが、どうも声が響かない（オーケストラに食われる）。それでも壁の手前で歌う前半は良いのだが、大広間が出て来て反響が減るととたんに全然聞こえなくなる。いっぽう、アデーレは立派なものだし、それ以上にエレートが常に響き渡るのはすばらしいな。

3幕、弁護士の鬘を投げ捨てて机の上に立ち上がって、おれはエイゼンシュタインだ！ から始まるところは実に素晴らしい（前回も印象的だった）。1幕の悲しい悲しいから、心は乱れて夜が待ちきれなくてうきうきのところは何度見ても楽しい楽しい。

アルフレードが牢屋の中でヴェンチェーラ（トゥランドット）だのヴィットーリア（オテロ）だの歌ったあげく引っ張りだされて星は光りぬと歌いっぱなしで、これがなかなか聴かせる。星は光りぬでは拍手。1幕はリゴレットはわかった。鳥の歌は小鳥も白鳥もわからん。白鳥は当然のようにローエングリンだとは思うが。絵姿の歌はわかったけど。

ルナールとシャグランは西新宿2丁目と4丁目に住んでいるらしい。

心の底から楽しかった。

_ Let's Note用互換電源アダプタ

仕事用のLet's note（LTEモデルなのでどこでも利用できるのがとても良いし、タッチパッドの誤反応がないのが素晴らしい）を家に持ち帰っていたので、ちょっと使おうと思ったのが12/25くらいで、電源アダプタを職場に置いてきたことに気づき、案の定12/26の夜にはバッテリーがやばくなってしまった。とはいえ取りに行くのは面倒なので家用に1個買うかと何気なく調べたら10000円くらいする。仕事用のノートPCなんだからこれくらい当然だろうというパナソニック坊やの得意そうな顔が目に浮かんだ。

家に転がっている各種ACアダプタが使えないか見たが、どれもこれもまったく適合しない。おれが持っているのはCF-SZ6CFMQRというやつで、これは16V 4.06Aだが、パナソニックしか使ってないんじゃないか？

パナソニック CF-SZ6QFMQR Lets note SZシリーズ(-)

で、アマゾンで見たら純正品はバルクでも7500円する。で、互換アダプタを見ると大体3000円前後なのだが、使えるんだか使えないんだか怪しさ爆発物しかない。

さらにいろいろ見ていくうちに、どうもMR.SUPPLYというところはまっとうな商売をしてそうだなという気になった。その分、高めで4000円くらいする。

アマゾンだと★1個とかあるけど、CF-SZ用と書いてあるのに、CF-NXでは使えないから★1というようなすっとぼけたやつなので無視して買った。

MR.SUPPLY パナソニック Panasonic CF-SZ専用ACアダプター 16V 4.06A AC アダプター CF-AA6412CJS(-)

とりあえず、純正品ではないという文句がにょきにょき出てきたが、「2度と表示しない」チェックボックスがあったのでチェックして閉じた。

で、ちゃんと充電できるし、充電中も利用できる（比較的安価な純正品で、充電専用というのがあって、それも一瞬候補にしたが結果的にやめて良かった）。発熱もないし、少なくとも購入してから1か月たったがまともに利用できている。というわけで購入して良かったとは言える。

でもなぁ、パナソニックには、こんなところで追加商売しないで、USB-C PDを採用して欲しいところだ。

_ はじめよう！ システム設計

技術評論社さんから（というか、羽生さんから、かな？）「はじめよう！ システム設計」をいただいた。

いきなりあとがきから読んだわけだが、問題意識が興味深い。

2017年はIT投資に企業の目が向いた年として規定される。AI、IoT、RPAの3つのキーワードと（個々人は貧乏街道まっしぐらだが資本はどんどん膨らんでいる）経済状況が背景にある。

ところが、SIerは人材流出の結果としてプロジェクトの全体構想を立案し着実に遂行する能力をほぼ失い、個々のPMの属人的な能力、つまり経験と知見だけで動くようになった結果、失敗が多い。

一方の発注側は、ITは虚業という言葉に散々踊らされた結果のIT軽視のツケと、これまでのコスト部門の弱体化（というか低予算化戦略）の結果として、これまた人材がいない。

結果として口が巧みなコンサルタントによる実現不可能な夢をトップがもって突っ走りまっしぐらに罠にはまって身動きが取れなくなるような傾向があるように見える。

問題は、企画から実現までのつなぎにある。すでにさまざまな実装技術は世にあり、個々の人間の能力は低くはない。問題は、上流と下流の分断がかってないほどでっかな亀裂となっていることだ。

というわけで、関係者をすべて素人とみなして、for the rest of usのための薄い（内容が、ではなくて物理的に、なんだが別の意味になっちゃうな）システム設計の本を作ろう。

というモチベーションらしい。なんか正しい認識だと思える。

システムとして目次をみるかぎり、プレゼンテーション-ビジネス-データベースという3層構造を基本においているようだ（これ自体はまあそりゃそうだと思う。ただし呼称はUI、バック、DBと非専門語としている。DBではモデル設計、その他ではモジュール分割や各層間の責務によるインターフェイス設計など。

あとがきでは、本書のターゲットはユーザー企業側としているようだが、むしろ（ということはないけど）、ユーザー企業の担当者に対してシステムの開発方針などを説明する立場の人間が読むと効果的なのではないかと思った。

はじめよう! システム設計 ~要件定義のその後に(羽生 章洋)

_ NET Fringe

東銀座で.NET Fringe。

組み込み用のCLRの話とか（GHIというボードメーカー）、シリアライザがすべてのボトルネックとか（最速のJSONシリアライザ）、Application Insignttとか(ApplicationInsights-aspnetcore、というか以前ASP.NETのWebアプリケーションを作るときに、Wizardに言われるままにApplication InsightというでっかなBlobをパッケージに入れてしまったが単なるzipのスタブにしか使わなかったのが悔やまれる）。

Lambdaでいくつかプロダクトコードを書いている関係上、Give＆TakeしようとC# on Lambdaをトークセッションに入れてもらった。

Takeしたいのは、

・2018/1から.NET Core2.0に対応したが、過去資産を2.0化するメリットは？ => ある。速度など。JSONシリアライザ（そういえばWizardの生成した構成ファイルからnewtonsoftの名前が消えていたような）（2.0のAWSドキュメントにバッチデプロイの方法が出ているのを見つけたのでこれも大きい）

・async/awaitさせている間にリクエストを受けたスレッドがレスポンスを返した場合はどうなるのだろうか？ => Lambdaの既定時間（確か5分）で打ち切りになると考えるのが自然。

・最大のメリット？（分割損やワイア使ったRPCとなる呼出しオーバーヘッドに対して） => スケーラビリティについてあまり考えなくて済む

体調はあまり良くなかったが、結構いろいろ得るものがあって参加できてよかった。

_ nginx-unicorn-railsで大きなファイルを扱う

大体400MBくらいのファイルをクライアントから上げてもらってそれをRails側で処理する必要が出てきた。

仕組み上、400MBの送信がクライアント－nginxとnginx-Unicornで必要となる。このときnginxとUnicornが同じマシンであればこの間の通信は無駄なので避けたほうが良い。

というわけで検索したらRailsで大きなファイルを扱う際のポイントという記事を見つけたのだが、今は2018年だ。nginx-upload-moduleはapt-getでインストールできるが、実際に動作しているnginx（）では動かなかった。検索すると、自分でソースにパッチしてmakeすれば良いというようなのは見つかったが、それはデプロイを考えた場合避けたい。

さらに検索するとNginxを使ってファイルアップロードを高速化する方法というのが見つかった。

こちらは、nginxにリクエストボディをファイル出力させて、それをRails側で利用する（出力したファイルのファイル名はリクエストヘッダで受け取る）ことにしていて、筋が良さそうだ。

しかし、想定がリクエストボディに直接ファイルの内容を出力（ブラウザーを介さずプログラムtoプログラムでのファイルアップロード）ことを想定しているように見える（あと、nginx.confとRails側でヘッダ変数名の書き間違いがあるのでそのままで使えない）。

以下のようにした。

まずnginx側でリクエストボディをそのままファイルとして残すことは変えない。

  location /upload {
    limit_except POST          { deny all; }
 
    client_body_in_file_only   clean;
    client_body_temp_path      /tmp/;
    client_body_buffer_size    128K;
    client_max_body_size       500M;
 
    proxy_set_header            X-File $request_body_file;
    proxy_set_body              0;
    proxy_pass_request_body     off;
    proxy_pass http://unix:/tmp/sockets/unicorn.sock;
  }

client_body_in_file_only clean;で仮にRails側の処理中に例外ですっ飛んでもnginx側でファイルを消させるようにした。Rails側で消せるのであれば、client_body_in_file_only on;で良い。proxy_set_bodyでUnicornに転送するリクエストボディは0にした（意味わからないが、offとすれば良いと書いてあるのを見てoffと記述したらリクエストボディにoffという文字列が送られてきた。proxy_set_headerでContent-Length:0としてみたが、それだとrackがIOエラーで死ぬ（リクエストボディが残っているからだ）。どうにかproxy_set_bodyで空文字列を設定できないかと試したが無理っぽいので意味はないが0としてみたが、?とか*とかのほうが良かったかも。proxy_pass_request_body off;はどうも有効ではないが、残してある。 Unicoornへ送るリクエストボディの設定については、nginxのproxy_moduleの説明だとproxy_pass_request_bodyとproxy_set_headerで良さそうなのだが実際にはうまく動作しなかった。

これを書いていて、ふとrackのバグじゃないかと気づいたが、上の設定で落ち着いているのでとりあえずこのままだ。

参考：proxy_moduleの説明のproxy_pass_request_bodyの記述例(rackがうまく処理しない)

 location /x-accel-redirect-here/ {
    proxy_method GET;
    proxy_pass_request_body off;
    proxy_set_header Content-Length "";

とりあえず、これでnginxは/uploadに対しては、/tmpに00000001.tmpみたいな名前のファイルを作って、リクエストヘッダのX-File変数に実ファイル名を入れてくるのでRails側でファイル処理が可能となる。

問題は、該当ファイルのパーミッションがwww-dataのrw-------となることだ。

Railsをsudoersで動かしているのでsystem "sudo chmod a+rw #{request.headers['X-File']}"で逃げた。

次はこのファイルの読み方だが、ブラウザーがファイルをアップロードしてくるのでマルチパートで読む必要がある。調べると、multipart-parserというGemがあった。SAXのように読みながらイベントを通知するタイプのようなので、それなりの速度は維持できるだろう。2012年に更新されてから静かだが、1度作れば落ち着くタイプなのでむしろ更新が無いのは良い知らせだろう。

が、使い方がさっぱりわからん。

しょうがないので、unit testのソースを見て使い方を調べる。ParserとReaderの2つのクラスのいずれかを使って処理を記述すれば良いということがわかった。バウンダリーを与えてReaderを作り（Parserをそのまま利用するより楽そうだ）、readerのon_errorとon_partにブロックを与えて全体を処理し、各パートの中身はon_partのブロックパラメータのon_dataで行えば良いということがわかった。

試しにユニットテストを実行してみた。すると、テストが通らない。

見るとfixtureがおかしい。しょうがないのでプルリクを投げた（今日マージされたのでこれ書いている）。

コントローラは以下のように処理する。

require 'multipart_parser/reader'
...
# ファイルアップロード受信処理
def upload
  # バウンダリーを与えてReaderのインスタンスを生成する。
  reader = MultipartParser::Reader.new(extract_boundary(request.headers['Content-Type']))
  # SAXというよりも、XHRの使い方に似ている。
  reader.on_error do |msg|  # エラーの場合のイベント処理
    logger.debug("on_error:#{msg}")
  end
  # パーティションを見つけた場合のイベント処理
  reader.on_part do |part|
    logger.debug("on part:#{part.filename}, #{part.name}, #{part.mime}");
    # RailsのCSRF対策用パラメータ
    if part.name == 'authenticity_token'
      # パーティション内の読み取りでon_dataイベントが通知される
      part.on_data do |token|
        unless valid_authenticity_token?(session, token)
          # 403を返したほうが良いかも知れないが412を返す（まともに使えば出るはずないのでいい加減）
          render html: '412 Precondition Failed', status: 412
          return
        else
          logger.debug('good token')
        end
      end
      # パーティションの終了通知
      part.on_end do
        logger.debug('end of authenticity_token part')
      end
    else #ここではauthenticity_tokenとfileしか見ないが、他のパラメータもあればその処理もあるはず
      file_model = FileModel.new(part.filename)
      part.on_datda do |file_line|
        # ファイル処理
        file_model.add(file_line)
      end
      part.on_end do 
        logger.debug('end of file')
        file_model.do_fantastic
      end
    end
  end
  # ファイルパース開始
  File.open(request.headers['X-File'], 'r').each_line do |line|
    # 1行単位にリーダーに与える
    reader.write(line)
  end.close
  head :no_content
end
 
BOUNDARY_MARK = 'boundary='
 
def extract_boundary(ctype)
  ctype[ctype.index(BOUNDARY_MARK) + BOUNDARY_MARK.length..-1]
end

_ 皆殺しの天使

28日は、東劇のMETライブビューイングで、アデスの皆殺しの天使。

アデスの作品は、テンペストに続いて2作目。どちらもMETライブビューイングだ。

アデスが人気があるのはわかる。現代のドラマツルギーに沿って、さまざまな音楽技法を駆使して、題材の選択もうまく現代のオペラを作っているからだ。100年前だとプッチーニというところだろう。

ブニュエルは大好きだが、機会があればメキシコ時代の作品ばかり見て、なぜかスペイン帰還後の作品は見てない（鐘が鳴って、首が転がり落ちる作品をテレビの名画劇場で観た記憶はあるが、というか鐘のシーンだけは記憶にあるが、それだけだ）。したがって、皆殺しの天使で知っているのは、ゴダールがウィークエンドで引用したという、ジャンピエールレオーが羊の群れに巻き込まれるシーンの、羊だけだ。

昇天峠 [DVD](リリア・プラド)

（メキシコ時代はスティールを眺めるだけでおもしろい）

で、わくわくしながら始まる。

ブルジョワジーの晩餐会で、指揮者、ソプラノ歌手、ピアニスト、大佐、わけのわからない姉弟（弟は潰瘍持ち）、医者、その患者、アメリカ人の冒険家とかがぞろぞろ来る片側で、召使いやコックが次々と出て行く。1人だけ執事のフリオが取り残される。

何度か繰り返しがある。純潔なルチアを演じたと称賛されたソプラノは陰でヴァルキューレ、どこが純潔なものですか、と散々こき下ろされている。疲れているので歌わない。

4時になり、5時になる。

館の主人の妻が大佐を誘惑する。しかし部屋に留まる。

誰も部屋から出ない。

フリオがやって来る。ソプラノが入るな！と止める。しかし他の客が入れ！と命じる。

弟が、ティースプーンではなくコーヒースプーンでなければならないとわめきまくる（この歌手はカウンターテノール）。しょうがなく、フリオ、部屋を出ようとして勢いよく弾き返される。出られない。

ラッセルが死ぬ。私は幸福だ。皆殺しを見ずに済む。死体を大佐と医者がトイレに運ぶ。

アメリカ人はだらしがない。

幕間。

オンドマルトノの説明。LAのスタジオで勉強した。幽霊音のほかいろいろ大活躍。トゥランガラリラ交響曲では幽霊音なんか出てこないので、まさかそういう使い方で大活躍とは知らなかった。ベントが効きまくるからだ。

他には1/32縮尺のヴァイオリン。ヒッチコックの鳥っぽい。ヒュンヒュンヒュンヒュンに使っている。

羊は食われる。

熊がやってくる。おおーと皆、その姿にひれ伏す。だが熊は入ってこない。賢明だ。

最後、野蛮人と理性ある人間の対立となる。野蛮人は館の主人を殺せ！と迫る。蜘蛛が死ねば蜘蛛の巣は崩れ去る。教養人に残るのは、医者、主人、大佐。ソプラノ歌手。

館の主人が、自分は犠牲になることを宣言する。

そのとき、ソプラノ歌手が気づく。この人物配置は見たことがある。そして歌を歌う。

解放される。

やはり抜群におもしろい。音楽も良いし、歌手も良い。高音で歌われる。

ブニュエルの作品に比較的忠実（ただし、登場人物は相当減らしたらしい）だそうだ。

1962年の映画ということは、経済大成長直前のフランコ政権だから、単純には政治劇と考えることはできる。国際的に孤立したスペインが館の中だ。独裁者であるフランコが自分からやめない限りこの状況は打破されない。しかし、もっともまともなのがフランコである、とも読める。

ブニュエルのことだから、すべては思い付きの可能性のほうが高い。カトリックは嫌い（劇の上ではまともそうな神父だが、姉が神父に息子を預けていることについての良からぬ噂が飛び交う。夫は忠告したそうだ、とか）。

閉塞状況こそが人生だという寓話だというのはわかりやすい解釈だ。繰り返しは人を堕落させる。芸術の力によって繰り返しに終止符を打ち、閉塞した精神を解放する。

つまりは娯楽作品であり、アデスは見事に娯楽性を維持したままオペラ化したのだと思う。実に良い作品を楽しめた。