読者です 読者をやめる 読者になる 読者になる

Google翻訳でとても仕事で助かった話

Google翻訳がニューラルネットワーク応用で「さらに進化」。翻訳ソフト感うすれ、流暢さを身につける - Engadget 日本版にもあるように、新しいNMTのGoogle翻訳はこれまでの機械翻訳とは段違いの性能で評判だ。わたしも少しずつ使ってみたりしていたのだが実際に職務でインパクトがあったのでここに記録しておこうと思う。

...

ご存知の方もいると思うが、わたしはApache Mesosを使ったソフトウェアの開発を仕事にしている。これは単体のサーバーでも動作するので、開発するときはほとんど1台または2台くらいのサーバーを使っている。しかしながら、実際の環境ではもっと多くのサーバーがクラスタとなって動作する。当然、複数のサーバーで動作するときしかでない問題は多い。詳しくは省略するが、今回もその件に漏れず複数サーバーないと出ない問題に当たって、それ自体はMesosの仕様を見逃していたせいなので修正はすぐできたのだが、再現試験などの環境が家になかった(オフィスにはあったのだが)。

で、Debian上のVirtualBoxVMを4台上げて手元で再現させようとしたのだが、このとき4台のVMをNATネットワークでつなごうとすると、そもそもゲストVMがネットワークにまったく接続できない。ポートフォワードも設定したのだが、ホスト側からもゲストにTCPで全くアクセスできない(VirtualBoxGUIからはアクセスできた)。オフィスにあるMacOSのNATネットワークなら動くのなぁ、困ったなあ…。で、こりゃVirtualBoxのバグだろといろいろ調べていたのだが全然でてこない。こまった、この問題の再現と修正確認ができないとリリースできない。でも調べるの時間かかりそうだなあ…OSSだから仕方ないんだけど、ヤダなぁ…ちゃんとやったら1週間でできるかなぁ、オフィスいってMac使った方が早いんだろうけどなあ…などと逡巡していた。

いろいろやって、それっぽいエラーメッセージが出たのでそれで検索すると、次のページが引っかかった。

gist.github.com

はい全然わかりませんね。同じ漢字文化圏といってもこんなもんです。で、これを精度がよいと評判のGoogle翻訳にかけてみた。そのまんまかけてみただけなのだが、結構英語が読める。まあ英語といっても大概なんだが、よく訓練された俺達は、同じ意味不明なら日本語よりも英語の方が理解できるのだ。どうも asciidoc aware ではないらしいが、日本語に訳してもこれは全然わからない。

しかしVirtualBoxのは、名前を見て、この問題は、それがすべての可能性のリードにであることであると推測関連1 Virtualboxのゾンビがあり、例外、ないモニタポート2204がありませんログインします。
[ソース、コンソール]

まとめると、

  • VBoxNetNAT というNATネットワークを管理するプログラムはroot権限でしか動かないようだ (ユーザー権限でやると になってしまってにっちもさっちもいかなくなる→コレがだんまりの原因っぽい)
  • "VBoxNetNAT: Effective UID is not root (euid = 1000 egid = 100 uid = 1000 gid = 100)" というメッセージからわかる
  • ps してみてもわかる
  • そのあたりのコマンドに +s 権限をつけたら動くようになる(実施前にみたら、たしかに s ついてないやつが多かった)
for bin in VirtualBox VirtualBoxVM VBoxNetAdpCtl VBoxNetDHCP VBoxNetNAT VBoxHeadless; do
    chmod u+s /usr/lib/virtualbox/${bin}
done

これでVirtualBoxをふつうに再起動するとなおる。で、ポートフォワードもゲストOSのネットワークアクセスも普通にできるようになった。

まとめ

  • VirtualBoxOSS なので問題は自己解決するのが原則
  • ネット上に同じ問題でハマってる人は少なかったが、答えが中国語で書かれてていた(私は中国語が読めない)
  • Googleの自動翻訳(中→英)が自然すぎて解決策を正しく理解できた
  • 結果、自分で調査したら解決できたかどうか分からない問題が半日というか数十分で解決した
  • 仕事ができて身長が5cm伸びた

Paxos-based replicationはEventually consistentではなくstrongly consistentである

ちょっと発言力のありそうな方がテクニカルに誤りを書かれていたので、ここでひっそりと訂正しておきたい。

このスライドの43ページ目に、

The problem with Paxos-based algorithm is that replications are eventual consistent.

と、色付き文字で協調されて書かれている。このスライドで主張したいことの本筋ではないが、Spannerの性能がよいこととは関係がなく、Paxosなどのレプリケーションと、トランザクションとの関係で誤解を広めそうなので指摘しておきたい。辻マサカリと言って差し支えないだろう。

PaxosはStrongly consistentであることがMade Simpleの論文で証明されている(Strongly consistentが何かはまた別の機会にここに書こうと思う)。ちょっと長いが引用しておこう。

To learn that a value has been chosen, a learner must find out that a proposal has been accepted by a majority of acceptors. The obvious algorithm is to have each acceptor, whenever it accepts a proposal, respond to all
learners, sending them the proposal. This allows learners to find out about a chosen value as soon as possible, but it requires each acceptor to respond to each learner—a number of responses equal to the product of the number of acceptors and the number of learners.

ベタにいうと、Paxos-basedなレプリケーションでも過半数読まないと値は決まらないので、それに従ってる限り誤った値が読まれるということはない。

Eventual consistencyとは「古い値が読まれることがあっても、最終的には最新の値が読めるようになる」なので、これは真っ向から定義に反するわけだ。

ではPaxosの定義はともかく、Spannerにおける実装はどうなんだということになる。Twitterでは日本語で、似たような趣旨のことを書かれている。 SOの記事
Paxos algorithm in the context of distributed database transaction - Stack Overflow を引いて

というPaxosに伴うEventual Consistencyの問題をwrite処理にタイムスタンプを付けることで、あるレプリカが、クライアントが要求する時刻より新しいデータを返せるかを判断できるようにしたのがSpanner

と書かれている。上記の通りPaxosにはECの問題なんてないし、SOの記事にもそんなことは1ミリも書かれていないのだが、どうしてこういう誤解がされたのか、せっかくなのでSpannerの論文を当たってみよう。 2.1 の冒頭でレプリケーショントランザクションについて語られている。

Unlike Bigtable, Spanner assigns timestamps to data, which is an important way in which Spanner is more like a multi-version database than a key-value store. A tablet’s state is stored in set of B-tree-like files and a write-ahead log, all on a distributed file system called Colossus (the successor to the Google File System [15]).

ここから分かるのは、Spannerではひとつの行にタイムスタンプで複数のバージョンを保持できるようにしているということだ。そしてWALがある。ということは、Tabletに対する更新はおそらくキー毎ではなく、Multi Paxosのように1Tabletにつき一つのWALを合意し続けるような作りであることが想像できる*1が…先を読んでみよう。

To support replication, each spanserver implements a single Paxos state machine on top of each tablet. (中略by引用者) Each state machine stores its metadata and log in its corresponding tablet. Our Paxos implementation supports long-lived leaders with time-based leader leases, whose length defaults to 10 seconds.

うむMulti-Paxosそのものだな。ちなMultiPaxosの特許は10年ほど前にMSがとっていて日本の特許公報でも見つけることができる。この書きっぷりからして思いっきり侵害していると思われるがそこは西海岸の論理でそんな野暮なことはしねーんだョ〜というのが垣間見えておもしろい。

Fig 2をみると分かるが、ここでのレプリケーションはデータセンター間のレプリケーションを指している。そしてちょっとあとに重要なことが書かれいている。

Our implementation of Paxos is pipelined, so as to improve Spanner’s throughput in the presence of WAN latencies; but writes are applied by Paxos in order (a fact on which we will depend in Section 4).

PaxosのWriteはパイプライン化してWAN超えても高速に送れるようになっている。で、Writeは必ず時間順に適用されると書いてある。TrueTimeを使っているからこんな芸当ができるんだね。で、勘違いされたのはすぐ次のここだと思われる

Writes must initiate the Paxos protocol at the leader; reads access state directly from the underlying
tablet at any replica that is sufficiently up-to-date. The set of replicas is collectively a Paxos group.

つまり、readsはPaxosをすっとばしてTabletに直接行くと書いてある。もとのPaxosにあるようなlearnerを通しての読み方ではなく、近くのデータセンターのTabletを直接読む...んだったら、そりゃあ間違った値が読めてしまっても仕方ない。しかしこれは上でも説明したようにEventual consistencyではない。sufficently up-to-dateな値を読んでも正しい値が読めるのは、たまたまSpannerでTrueTimeとそれに伴う並行性制御が適切に設計されているからである(4章で説明されているように)。

そもそもConsistencyというのはそのプロトコルが規定したR/Wの組み合わせパターンのそれぞれの結果のスペックであって、PaxosでもSpannerでもそういうスペックは規定してないのだからEventual consistencyと勝手に呼ぶのは間違っていて...Spannerの論文にもそんなことはどこにも書かれていないし…ブツブツブツブツ。

*1:ちなみにこれはRiakのStrong Consistencyでもやってるやーつ

あなたの知らない time(1) の世界

The moment

自分が書いたプログラムのメモリ使用量を測定したいことがある。プログラムがOOM Killerによってお亡くなりになった場合や、ページフォルトをなくして高速化したい場合などだ。定常的に起動するサーバーのプログラムなら、sarや meminfo など(今なら Datadog とかだろうか)を使ってじーっと見つめるわけだ。もっとモダンにやるなら perf や DTrace を使ってもよいかもしれない。しかしこれらのツールは基本的にプロセスIDを渡してサンプリングして外から覗く方法だ。

わたしのユースケースはデーモンプロセスではなく、 main から入って必要な計算をして、それが終わったら main を抜けるバッチジョブ(単にコンソールから実行して終わるまで待つ、いわゆる "Hello world!" 的なやつ)だ。これだと、プログラムが起動して終わるまでそこそこの時間で終わってしまって、外部プロセスを一緒に起動するものだとタイミングを合わせにくい。それに、外部からのサンプリングでは最大使用量は分からないから、キャパシティ設計やOOM Kill防止には使えない。サンプリングのタイミングのメモリ使用量しか測定できず、サンプリングの周期を短くすれば性能を阻害してしまうし、長くしてしまえば最大使用量に近い値をとる可能性が下がる。もっと文句をいうと、VisualVM使えねえんだよ!!

うーん何かよい方法はないものか…とインターネットを放浪しているとやはりそこはStackOverflowだ。残念ながらそのページは失念してしまったが(昨日のHistoryを見返す気にはなれない)、「Javaでメモリ使用量測りたいんだけど、どうしたらいいの?」というよくある質問に「Macなら " time -lp java ... " でカンタンだよー」というJavaMacも実は全然関係ない質問だった。もっとドンピシャなやつは見つかったのだけど、用語の組み合わせからして検索しにくいものであることはご理解いただきたい(追記:別マシンのブラウザに残っていた)。

でまあ、いそいろ調べて BSD time(1)とかGNU time(1)をみているうちに Linux でも "/usr/bin/time -v " でMax RSSを調べられることがわかった。ちなみに最初は BSD time(1) のコード見てどうやってんのかなーとか調べていたが、始めから GNU time(1) のマニュアルを丁寧に読めば全部わかる話だった。どちらも getrusage(2) というPosix APIを叩いて子プロセスの情報をカーネルからとってくるようになっている。BSDは調べていないが、Linuxでは /proc/[pid]/stat から情報をとってきているようだ。なので、 malloc/free の合計とかにはなっていなくて、OSからみえるページ単位とかのはずなんだがその割にはRSSが4Kにアラインされていないのでよくわからない。そもそもRSSって何なんだ。

手元にある、4GBほどメモリを使うテストプログラムを動かしてみると、こんな感じになる。

$ /usr/bin/time -v ./a.out                                           
/sys/kernel/mm/transparent_hugepage/enabled: [always] madvise never
memory allocator performance test
2097152 of memory pointers with 2048 bytes; 4.295 GB total
time: 181.617 sec
        Command being timed: "./a.out"
        User time (seconds): 181.99
        System time (seconds): 1.11
        Percent of CPU this job got: 99%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 3:03.41
        Average shared text size (kbytes): 0
        Average unshared data size (kbytes): 0
        Average stack size (kbytes): 0
        Average total size (kbytes): 0
        Maximum resident set size (kbytes): 4838748
        Average resident set size (kbytes): 0
        Major (requiring I/O) page faults: 0
        Minor (reclaiming a frame) page faults: 1205812
        Voluntary context switches: 1
        Involuntary context switches: 2704
        Swaps: 0
        File system inputs: 0
        File system outputs: 0
        Socket messages sent: 0
        Socket messages received: 0
        Signals delivered: 0
        Page size (bytes): 4096
        Exit status: 0

ページフォルト数、ファイルIO、ネットワークIO、コンテキストスイッチ数、ページサイズからon-cpu timeまでわりと重要なものがサクッと出るので、DTraceとかperfとか重いやつをいきなり始める前にこれでマイクロベンチをとってみるのがよいだろう。ちなみに "-f FORMAT" で任意の形式で出せるし、出力をファイルに出すことも可能だ。つまりこういう風に無駄に結果をJSONに保存することもできる。

$ /usr/bin/time -f "{\"maxrss\":%M}" -o out.json lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.1 LTS
Release:        16.04
Codename:       xenial
$ cat out.json
{"maxrss":11864}                                 

ちなみに、ソースコードBSD time の方がさっぱりしてて読みやすいけど、Formattingの機能はない。GNU timeはやけにゴチャゴチャしてるなーと思ったんだけど、Formattingのためだったというのは後で気づいた。

もうちょっと真面目にやるなら、Linuxには最近 eBPF という優れたトレーシングフレームワークが入って、そのフロントエンド的なツールとして IOVisorというスグレモノがあって、こんな感じで全てのメモリアロケーションをトレースできる。これをちょっと書き換えたらMax RSSなんてお手のものだし、JVMの中身がわかっていればヒープとページの関係もよくわかる。

ちなみに、Mac OSについているBSD timeはなかなかふざけていて、manpageを見てもRSS関連は単位が明記されていない。プログラムの出力をみても分からない。参考にと書かれいている getusage(2) のmanを見ようとしたら入っていない(ちゃんとXCodeも入れてるつもりだ)。で、ヘッダにコメントであるかな?と、manpageにかかれている /usr/include/sys/resource.h を見てみようとすると

$ less /usr/include/sys/resource.h
/usr/include/sys/resource.h: No such file or directory

である。Akisute先生じゃないが、🍎📠である。自作のプログラムで検証するに、どうやらバイト単位のようだが…

$ /usr/bin/time -lp ./a.out
/sys/kernel/mm/transparent_hugepage/enabled: Bad file descriptor
Cannot open THP setting file. Maybe not Linux?
memory allocator performance test
4194304 of memory pointers with 2048 bytes; 8.590 GB total
time: 417.990 sec
real       425.90
user       153.47
sys        204.87
11523166208  maximum resident set size
         0  average shared memory size
         0  average unshared data size
         0  average unshared stack size
  44780389  page reclaims
         0  page faults
         0  swaps
         0  block input operations
         0  block output operations
         0  messages sent
         0  messages received
         0  signals received
     10802  voluntary context switches
   2338890  involuntary context switches

知っていたのにここまで読んでくれた方には感謝の念しかない。そう私が知らなかっただけ。

2016年に観たアニメのまとめ1

anime

王都炎上―アルスラーン戦記〈1〉 (光文社文庫)

王都炎上―アルスラーン戦記〈1〉 (光文社文庫)

学戦都市アスタリスク

★1
ヒロインが赤髪で識別不能シリーズのひとつ。作画は一番綺麗。2期までなんとか頑張ってみたけど残念なとこで打ち切り。。。まあ作画のクオリティ以外は月並みではあったかもしれない。原作は長く続いているので、もっと面白いとこがあったのかも?

落第騎士の英雄譚(キャバルリィ)

★1
んー、まあそれなり。魔法騎士学園最弱もの…とみせかけて最強ものなんだけど、知恵を絞れば人間なんでもできる!って価値観は好きだ。アルドノアゼロの三話までみたいな感じで楽しめる。問題は主人公しか知能がないことだが。。。

鉄血のオルフェンズ

★2
火星の気圧で人間生きてられんの?!って以外は楽しめる作品。どこまでも全ツッパなオルガとミカをみてるとハラハラしかないのだけど、わしも歳をとってしまったか。。。モビルスーツは手描き?で生き生きとなっている。戦艦はGCでマットな仕上がりに。地球外円軌道統合統制艦隊のアホっぽさがちょっと鼻についたかな…少年兵がここまで戦うのは非常に怖い時代なんだけど、阿頼耶識システムが背負った業はかわいそうで、自分の子供がこうなったら…と思うと非常に悲しい。でも観てしまった…

グリザイアの迷宮グリザイアの楽園

★2
主人公の呪われた過去が明らかになって、でも女の子に囲まれてユートピアへGo!的なハッピーエンドがみられる。やっぱり原作がアダルトコンテンツだとタブーが少ないからシナリオが尖って面白くなる。ことがある。

グリザイアの果実

★2
んー、まあなんというか、原作っぽい。最強主人公、みてて落ち着く。

ヨルムンガンドPERFECT ORDER

★2
ココの頭おかしい陰謀が徐々に明らかになる2期。映画とかのフィクションでも古くからよくあるネタなのでまあなんというか、各話の面白さに対して若干拍子抜けするんだけども、原作読むともっと面白かったりするのだろうか。

ヨルムンガンド

★2
頭のおかしい強い人たち(ほめている)が頭のおかしい悪いヤツと戦う話。そもそも武器商人の話なのでみんな悪いんだけど。戦闘シーンは静動が対照的で緊張感があってよい。

GOD EATER

★1
ゲームっすね。よわっちかった主人公が圧倒的なモンスターに立ち向かっていくお話。雨宮ツバキさんがやはり少佐…って声だけなんだけど。シナリオはゲームらしく月並みだが、作画がゲームばりにきれいなので一見の価値はある。

精霊の守り人

★2
強力な女用心棒の主人公が戦いながら、父親に命を狙われる流浪の王子を助けて国を救うお話。強くて老練で
戦いの駆け引きに優れた女というかその顔…完全にこれ少佐やないかと思ったらやはり監督は神山健治だった。SFではないので未来兵器を駆使した派手なアクション!とはいかないけど、駆け引きも含めて戦闘シーンは魅せるものが沢山あってよい。本当に必要な場面でしかチャンバラしないのもよかってた原作でいうと一巻だけで未読なんだけど、これを2期26話までかなり拡げていてはてさてマジック…

原作者が田中芳樹のファンで、光文社文庫の巻末にあとがきを寄せている。それを読むとこちらの原作も面白そうだなと思える。

アルスラーン戦記

★3
これをみて私は戦記ものが好きだったのだなと気付いた。おかげさまで文庫をとりあえず大人買いしてしまい…三国志でいう劉備みたいな、わりと何もできない主人公が頼もしい味方を集めて戦うお話。銀仮面卿はなんというか、シャア・アズナブルのような魅力があって、でもシャアのように狂気を身に纏うではなく、どうなっていくかは原作でもまだこれから感があって楽しみである。原作ではモブだったキャラが荒川弘に大抜擢されているので、原作しか読んでない人にもこれから勧められる一作。

英伝が好きな人は原作は当然だし、アニメも面白く観られることだろう。コミックスも結局買い続けている

舞Hi-ME

★1
なんつーか。。。ガンダムは出てこないけど、ガンダム納税ここまでやるか?俺頑張った感はある。登場するキャラクターはうまくテンプレを体現していて見てて飽きないし、シナリオも稀有壮大盛り上がりをみせつつ、女の子が健気に頑張る感じはまさに王道。この方向好きだけど物足りない!って人はクロスアンジュを観るしかない。

2015に観た気がするアニメまとめ

anime

前も似たようなものを書いた気がするし随分昔の話だけど、メモがたまってきたので再度。。

  • ★0は、観る価値なし。途中で切ったまたは観て損した。基本的には掲載しないが、最後までみたものは誤ってもう一度みてしまわないために掲載
  • ★1は、一度くらい観てもいいかも
  • ★2は、ちゃんともう一度見返してもいい
  • ★3は、絶対に観とけオススメ、名作、僕の好みの作品

攻殻機動隊ARISE

★1
ええ観ましたよ。攻機税払った感じ。謎のヒールが出てきて、最新のCGで、巨悪と人間の矛盾に立ち向かっていく定番ストーリー。少佐の中の人が田中敦子から変わって少し幼くなったのは誰かの好みなんだろうか。戦争帰りのスレた感じをもっと出してほしかったところ。灯台下暗しを地でいったつもりなのかもしれないけど、やっぱりなかなか笑い男は超えられないなーという。

シドニアの騎士 第九惑星戦役

★2
第二期というよりは、前作と連続的なストーリー。人工カビと彼女の登場で人類側強くなりすぎた感があって、そもそもカビとは何ぞやとか胞衣とは何ぞや、ガウナの正体は!?みたいな謎に迫ってほしかったが、原作の進行具合によるものか。

* 攻殻機動隊SAC 2nd GIG

★1
SACを観た人ならまあ惰性で見るのもよかろう。ヒールとしての合田はやはり、笑い男に比べると魅力に欠ける

シドニアの騎士

★3

これは非常によかった。人類vs謎の天敵、敗北の歴史を書き換えるSFで、グラフィックスもよかった。衛人をはじめとする人工物のマットな質感と、ガウナのキモい生身感が対照的で盛り上がる。でも宇宙空間は真空なのであのガウナの柔らかい感じ、内部気圧がかなり0に近くないと風船みたいに膨らまないのかな…かなりの低圧だとして、シドニア号の内部でも普通に潰れずに活動できてるの不思議だとか今になって心配になってくる。

個人的にはイザナよりもサマリさんですなー

機動戦士Vガンダム

★1

ユニコーンが完結したあとに宇宙世紀シリーズはやはりコンプリートしなければと思いつつ敬遠していたが、どこかのスレをみてカテジナさんの悪女ぶりは要チェックやし、せっかくバンダイチャンネル課金したしで一念発起。

全50話は伊達じゃない。富野史上唯一本人の認める駄作という評判もさすがで、これにはかなりの忍耐を要した。携帯電話がなかったり、ウッソが一人で地下のデータセンターを維持していたりと、宇宙世紀もかなり後の時代とは思えないなかなかのレトロ感もよかった。肝心のカテジナさんはやはりなんともいえないクズで、それなりに丁寧に葛藤を描こうとしたものの、馬に乗るようなノリでガンダムに乗られては数多のモブパイロットたちは涙を禁じ得ないだろう。彼女がニュータイプ的に描かれているような気もしたがそこが曖昧になっていて、単なる人類の戦争みたいになってしまっている。

こうなるとシャクティがお姫様という伏線も胡散臭くなってきて、これまでの宇宙世紀史上最大の出木杉感が演出されたスペースオペラに成り下がってしまう。ガンダムに帰依するものであれば必見だし、なんとかギリギリ一般人にも見られなくはない駄作の作り方としては参考になる。

Vガンダムシリーズのメカっぽい感じは悪くないし、時代が進歩してあそこまで小型化できたという人類の技術の発展には目を見張るものがある。

昔書いたメモがあった

アルドノア・ゼロ2クール

★0
あまり覚えてない…惰性だった

アルドノア・ゼロ

★1
最初の3話は見る価値がある。圧倒的な戦闘力、戦略での敗北を少しずつ知恵と戦術の優位でひっくり返していく様はかなりの見ものだ。宇宙人、開始時点で圧倒的な状況で、そこまでもってくる知能がありながら慢心して開始後は圧倒的な無能からサクサクと負けていくところに視聴者に絶望感を与えていくだろう。

最初の3話までは非常に面白くて続きが気になってしまう(スレインとの戦略、戦術的駆け引きが繰り広げられるのを期待…)けど、それが時間をかけて裏切られてしまう。

翠星のガルガンティア

★3
AI感を微妙に醸し出すチェインバーのウィットのきいた会話と圧倒的な戦闘力が非常に面白くて、それだけでずっと気持ちよくみていられる。転送前はヒディアーズには圧倒的に負けていたところがさらに爽快感を出している。物語後半に進むに連れて、あーきっと昔の人種差別もこんな感じだったのかなーなどと思いを馳せるけども。。。

作画はプロダクションIG、原画は鳴子ハナハルだけあって非常に安心して観ることができる。やっぱりリジットさんかな。

楽園追放

★2
どこの感想をみても尻、尻、尻…まあたしかにそうなんだけど、フル3DのCGで人物を描写するのに、表情以外に手間をかけて魅力を出していくところはたしかにそこしかない気もする。だけどまあ、物語のテーマとしてもまあまあ面白くて、人間とは何ぞや、肉体なのか、精神なのか、知性なのか、みたいな問いを改めてシャッフルしたところを評価したい。最初、アンジェラはコンピューター上に実体があり、地上に出るに当たって肉体を改めて合成するとか、フロンティアセッターの正体はアレとか、いろいろ常識を考え直して人間性を見つめ直す…というのはSF的には古くて新しいテーマであるが、それをこーゆーポップなメディア若者たちに問い直していくのは必要なことだと思う。なぜなら若者は全ての古典をカバーできるわけではないから。

ロボットアクションや戦闘シーンもスピード感があって、音楽もノリがよいです。

攻殻機動隊SAC

★3
士郎正宗のうるさいオタクSF漫画を物分りの悪い知ったかぶりのオトナ向けに上手く焼き直したのが押井守だとすれば、これはより広い層にカッコよくポップにリーチして、コンピューター、インターネット、兵器の未来を見せて親しみやすくするための意欲作。単なるハイパーSFで、勧善懲悪に複雑な伏線と伝統的なプロットを当てはめるとこうなるというお手本のような作品。笑い男の正体と動機を知ったらみんなホッとするはず。ARISEやSAC2を見なくても、これさえ見ておけばよかろう。

DVD買うならこの逆輸入Boxがオススメです。26話全部入ってこの値段。しかも元が日本語なので字幕などの問題がない。

機動戦士ガンダムUC OVA 1-7

★3

私の少年時代にリアルタイムで放送されていたガンダムはVやGという、イマイチすぎるものばかりで、大人になってから初代やZ, ZZなどを改めて観たはいいがどうにも古めかしくて納得できていなかった自分にやってきた福音がこの作品。随分前にふとしたきっかけで見始めたらしい。この作品でいちばん好きなモビルスーツはなんといってもNZ-666クシャトリヤ

HGUC 1/144 NZ-666 クシャトリヤ (機動戦士ガンダムUC)

HGUC 1/144 NZ-666 クシャトリヤ (機動戦士ガンダムUC)

これまでの宇宙世紀もの(初代、Z, ZZ, 逆襲のシャア)をユニコーンの予習のために改めて観てよいかもしれないと思えるくらい、昔からのファンに気を遣った作品。昔からの顔ぶれがありつつも、初登場の新しいキャラ、ZZから大きく成長したキャラ、沢山出てくる。…でありながらも、これまでのガンダムになかった3DCGの本格導入、モビルスーツのマットな質感、福井晴敏の描く魅力的なキャラクター、ガンダムが初めての人が観てもわりと面白くなるようにできているのではないだろうか。

映画に不満があるとすれば、インダストリアル7での戦いでクシャトリヤがコロニーを破壊したような見方になってしまっている点か。小説版を読めばわかるのだが、実際にコロニーを破壊する戦い方をしたのは未熟なロンドベル側であって、クシャトリヤはメガ粒子砲どころかファンネルも抑えて使うという徹底ぶりだった。

古代ギリシア展に行ってきたら奇しくも都知事選に思いを馳せることになってしまった

国立博物館で開催されている古代ギリシア展に行ってきた。

行ってきた

A photo posted by Kota UENISHI (@kuenishi) on


古代ギリシアの民主制

Lamport が失敗だったという The part-time parliament の話を聞いてる人とか、世界史に興味を持っている人なら当然だし、民主主義国家に住んで市民権を持っているなら、民主主義の源流は古代ギリシアにあることは常識だと思うのだが、それがどのように実施されているかを具体的にイメージできずにいた人は多いと思う。私が撮った写真ではないが、引用させてもらおう。

kleroteria - allotment machine for jury service. Agora Museum, Athens.

Jury duty in ancient Greece

この2枚の写真の右下にある丸いものが Ballot といわれる投票器だ(ancient greek ballot - Google 検索)。円盤に棒を刺したような形をしている。棒が中空になっているか、そうでないかで賛否を表現するのだが、投票するときはこの棒の先端を指で隠して持って行ったのだそうだ。いまの御札とは全然違う。

2枚の写真にある、短い溝が沢山ついた石版は、裁判員をランダムに選択するためのクジ "allotment machine" というそうだ。

pinakia - bronze allotment plates for jury duty. Agora Museum, Athens.

この写真のような銅板に名前を書いて挿しておいて、裁判員を決めるときに適当に銅板をとって裁判員を選出していたようだ。

さてこれが、都知事選に関わりそうな展示物だ。その名前をオストラコン(陶片)という。

Voting Potsherd to Banish Aristides "The Just"

古代ギリシアの都市では、僭主(デマゴーグ)が登場して政治を徒にすることがあった。それを防ぐ目的で、年に一回陶片に名前を書いて投票を行う。名前を書かれた政治家のうち、得票数が多かった者はなんと10年間その都市を追放されるのだ *1 。いわゆる陶片追放の仕組みである( Wikipedia には諸説書かれている )。これだよこれ、こういうのがほしかったのだよ。選挙はいままで通りやってほしいから、コイツを年に一回日本でやったらどうだ、などと妄想しながら都知事選の選挙公報を見たときの苦々しい記憶を思い出していたのであった。だからのこのブログを書いたのである。

アルテミス像とその他の展示

ギリシア展は撮影禁止なので写真は特にないのだが、個人的に一番気に入ったのは307のアルテミス像だ。最後のセクションで本物を拝むことができる。ネット上にはいくつか写真もある:その1その2いくつかエピソードがWikipediaにも載っていてそれがまた傑作だ。エピソードや写真ではちょっと暗く厳しい表情をしているようにみえるが、実物は明るい照明に照らされていてもうちょっとかわいい。好意的に解釈すれば憂いのある表情だ。ギリシア彫刻の男女ともにムキムキとしたマッチョな感じがなく、どちらかというと繊細というか今風の体型になっていて現代人の好みに合うだろう。

その他の展示については、アレクサンドロス大王の彫像だ。男前という風でも、野蛮でもないし、精悍な若者という風でもない、どちらかというと飄々とした表情で、今でいうとマーク・ザッカーバーグのように野心と情熱だけがそこから湧いてくる、今でいうとシリコンバレーにいそうな若者の顔だ。とアリストテレスの彫像が近くに置かれていて、髭面がジッと弟子を見つめているのもおもしろかった。

ドラクマ貨幣の実物もあったし、ドラクマの由来といわれる鉄の棒も展示されていた。ちょうど人間が片手で掴めるのが6本だそうで、鉄棒ひとつかみ分が1ドラクマの由来なのだそうだ。通貨とはつくづく、交換可能性と信用なのだなと思う。別に悪貨が入ってきても、信用の媒体を変えてしまえばよいのだな…などと思って近年やけに取り沙汰されていた某塊鎖的技術に思いを馳せるなどしてしまった。鉄の某が通貨になるんだから、まあ別になんだっていいよね。塊鎖が実用的かどうかは別だけど。

おまけ

特別展のチケットを買うと写真の本館で総合文化展(通常展示)も見ることができる。

101ND610-DSC_3716

本物の刀剣とか、

101ND610-DSC_3655

どうもまだ使われているっぽい黒電話とか、

101ND610-DSC_3663

意外にも綺麗な庭園とか、

101ND610-DSC_3666

毛の生えた兜(写真では赤っぽいが本物はもっと黒い、撮影技術ェ…)とか、

101ND610-DSC_3671

本物の日本漆で作られた江戸時代の箱とか、

101ND610-DSC_3681

愉快な能面とか、

101ND610-DSC_3704

かわいい根付とかを見ることができる。

101ND610-DSC_3713

何よりそこいらのケチな博物館と違って、展示物のほとんどは撮影可能なのがよい。

*1:財産などは没収されなかったらしいし、戻ったらまた政治に復帰することもできたようだ

GPG鍵を作って運用し、Git(hub)やMercurialで自分が書いたコードに署名をする

自分が書いたコードに署名をしておくことはプログラマの常識であり基本動作です(かくいう私もメールは署名してないけど…)。なので私も一人前のプログラマになるべく、自分が書いたコードに署名をするようにしてみた。

GPG 鍵を作ったり準備したり

GnuPGのインストール@MacOS

$ sudo port install gnupg

鍵をつくります。有効期限は2年間。もし秘密鍵が漏れた場合でも、2年経てばほとぼりが冷める。

$ gpg --gen-key
gpg (GnuPG) 1.4.20; Copyright (C) 2015 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

ご希望の鍵の種類を選択してください:
   (1) RSA と RSA (デフォルト)
   (2) DSA と Elgamal
   (3) DSA (署名のみ)
   (4) RSA (署名のみ)
選択は? 
RSA 鍵は 1024 から 4096 ビットの長さで可能です。
鍵長は? (2048) 4096
要求された鍵長は4096ビット
(中略)
鍵の有効期間は? (0)2y
鍵は木  7/12 00:41:58 2018 JSTで期限切れとなります
これで正しいですか? (y/N) y

あなたの鍵を同定するためにユーザIDが必要です。
(中略)
gpg: 鍵8CD45203を究極的に信用するよう記録しました
公開鍵と秘密鍵を作成し、署名しました。

gpg: 信用データベースの検査
gpg: 最小の「ある程度の信用」3、最小の「全面的信用」1、PGP信用モデル
gpg: 深さ: 0  有効性:   2  署名:   0  信用: 0-, 0q, 0n, 0m, 0f, 2u
gpg: 次回の信用データベース検査は、2018-07-11です
pub   4096R/8CD45203 2016-07-11 [有効期限: 2018-07-11]
 フィンガー・プリント = FF7E B3FF 4AEE ADEA 764D  2F33 BD95 145F 8CD4 5203
uid                  Kota UENISHI (h) <kuenishi@gmail.com>
sub   4096R/B99B64AE 2016-07-11 [有効期限: 2018-07-11]

kuenishi@mineva.local> $ gpg --list-keys
/Users/kuenishi/.gnupg/pubring.gpg
----------------------------------
pub   4096R/8CD45203 2016-07-11 [有効期限: 2018-07-11]
uid                  Kota UENISHI (h) <kuenishi@gmail.com>
sub   4096R/B99B64AE 2016-07-11 [有効期限: 2018-07-11]

鍵をバックアップして保存しておく。失効証明書とあわせて、この3つのファイルがマスターになるらしい。

$ gpg --export-secret-keys --armor kuenishi@gmail.com > secret-key.backup
$ gpg --export -armor kuenishi@gmail.com > public-key.backup

インポートは簡単に "gpg --import (secret|public)-key.backup" とやってよいようだ (追記: インポート後に鍵の信頼度を設定しないとずっと信用できないと言われ続ける。方法はオマケ参照)。

GitHub にGPG鍵を登録する

これを登録しておくとGithubで Verified と出てかっこいい。

$ gpg --list-secret-keys --keyid-format LONG
/Users/kuenishi/.gnupg/secring.gpg
----------------------------------
sec   4096R/BD95145F8CD45203 2016-07-11 [有効期限: 2018-07-11]
uid                          Kota UENISHI (h) <kuenishi@gmail.com>
ssb   4096R/883A16F6B99B64AE 2016-07-11
$ $ gpg --armor --export BD95145F8CD45203
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1

mQINBFeDvmgBEADkjeoWVk9AbsOeSdCxHQGtyHEiFvXn+7dEGvw3yqs7IHk4dYil
GbcTp/CcWxk2QnrG3UXleohARh+jEx5MDMfGAf3hOGCtHrQrOd4RfvEtShgRf5kP
...
-----END PGP PUBLIC KEY BLOCK-----

と出る。これをGithubに登録する。具体的には "Settings > SSH and GPG keys" のメニューから登録する。こんな感じ。

f:id:kuenishi:20160712010215p:plain

Git にGPG鍵を設定する

これも簡単。

$ gpg --list-keys
/Users/kuenishi/.gnupg/pubring.gpg
pub   4096R/8CD45203 2016-07-11 [有効期限: 2018-07-11]
uid                  Kota UENISHI (h) <kuenishi@gmail.com>
sub   4096R/B99B64AE 2016-07-11 [有効期限: 2018-07-11]

$ git config --global user.signingkey 8CD45203 
$ git config --get user.signingkey
8CD45203

署名つきコミットやタグを作る

このあたりはGitの公式ドキュメントが詳しい。まずは署名つきのコミットをつくる。 "-S" をつけると署名をGPGの設定に従ってつけてくれる。

$ emacs README.md
$ git add README.md
$ git commit -S -m "Fix docs"

次のユーザの秘密鍵のロックを解除するには
パスフレーズがいります:"Kota UENISHI (h) <kuenishi@gmail.com>"
4096ビットRSA鍵, ID 8CD45203作成日付は2016-07-11

[master 6f12b24] Fix docs    
 1 file changed, 3 insertions(+), 3 deletions(-)

コミットが署名されているかどうかは git-show で分かる。

$ git log --show-signature -1
commit 6f12b24585f997cdf405ef38e00392bfdf3f4193
gpg: 火  7/12 01:07:56 2016 JSTにRSA鍵ID 8CD45203で施された署名
gpg: "Kota UENISHI (h) <kuenishi@gmail.com>"からの正しい署名
Author: UENISHI Kota <kuenishi@gmail.com>
Date:   Tue Jul 12 01:07:56 2016 +0900

    Fix docs

普段使っている git-tag コマンドに "-s" オプションをつけることで、署名つきのタグを作ることもできる。署名は git-show で確認できる。

$ git tag -s 0.0.1 -m "First signed relase 0.0.1"

次のユーザの秘密鍵のロックを解除するには
パスフレーズがいります:"Kota UENISHI (h) <kuenishi@gmail.com>"
4096ビットRSA鍵, ID 8CD45203作成日付は2016-07-11

$ git show 0.0.1
tag 0.0.1
tag 0.0.1
Tagger: UENISHI Kota <kuenishi@gmail.com>
Date:   Tue Jul 12 01:11:34 2016 +0900

First signed relase 0.0.1
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAABAgAGBQJXg8U2AAoJEL2VFF+M1FIDkeYQAOCOtjX2q5Ai+uq5/S+Rh0uE
K4xR4VlbUriPb376fweLNglct5dgSSxU151Auq36kWAiEKkEZR3mEdtYbMmEqEXV
Srx0+4b/Z3WFCh6A9B2mjdjMNBs3gGuQJvkGEAeseHBOOoM+jyxHtZFG4032HZgw
tag 0.0.1
Tagger: UENISHI Kota <kuenishi@gmail.com>
Date:   Tue Jul 12 01:11:34 2016 +0900

First signed relase 0.0.1
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAABAgAGBQJXg8U2AAoJEL2VFF+M1FIDkeYQAOCOtjX2q5Ai+uq5/S+Rh0uE
K4xR4VlbUriPb376fweLNglct5dgSSxU151Auq36kWAiEKkEZR3mEdtYbMmEqEXV
Srx0+4b/Z3WFCh6A9B2mjdjMNBs3gGuQJvkGEAeseHBOOoM+jyxHtZFG4032HZgw
t2g1GS7BPIoas2azrKRWY9Jt4hCfEQ5TQpmbm9lbtbMDK9JRZ6mxkdoTyUdHM3c5
8chHTvXW+6yRbIEA3MKLzA+r/4crjLDOm/UqLpggRw3e0+mEpPeN40ifrq6MyBwy
82VBuAw/38qAsO2OXNeRwNbNPXPmTT4S/OQ09cAu7CjgHQ7/X6ZYb2/9w01BvAEn
5XdA4oaMeFq8/4W1W+jFSUBlrEM7YWEoE7ZPjLeln7iFND+mTfV2OU92ftOku0ou
IOP8l1/NzphLTJJR3nvqMzCzX+sONgeyfc8wT81yyOgAyR1uwgy9svyDHdEfvqM2
hulOuJ+HhzbuhLZ0rmXot+gXCGoAE7oXP4wFXHQ+NP1iTKP1flSHtXnFiUs19ikm
MspL75R29ATz7lAaWM1vv5AKivIy3Xsu7ngE69fnHa6R28frBPvfTbY+m2dxBiNd
I0npPtpAUS/FMQvZCFzACumZ5LdWCNx1uE7K2sUJv5zaMXTsTbB+XfMbvyOH0Hoe
jtP4uzxY324qTrj8gtxV
=AvrO
-----END PGP SIGNATURE-----

commit 6f12b24585f997cdf405ef38e00392bfdf3f4193
Author: UENISHI Kota <kuenishi@gmail.com>
Date:   Tue Jul 12 01:07:56 2016 +0900

    Fix docs

diff --git a/README.md b/README.md
index 19af36d..97490a4 100644
--- a/README.md
+++ b/README.md
@@ -1,11 +1,11 @@
(snip)

タグの確認は -v オプションだ。

$ git tag -v 0.0.1
object 6f12b24585f997cdf405ef38e00392bfdf3f4193
type commit
tag 0.0.1
tagger UENISHI Kota <kuenishi@gmail.com> 1468253494 +0900

First signed relase 0.0.1
gpg: 火  7/12 01:11:34 2016 JSTにRSA鍵ID 8CD45203で施された署名
gpg: "Kota UENISHI (h) <kuenishi@gmail.com>"からの正しい署名

これを git-push すると… こうなる

f:id:kuenishi:20160712011555p:plain

Verifyされた!これで私もVerified Engineerだ(??)

タグの方も無事にVerifyされている

f:id:kuenishi:20160712011709p:plain

Mercurial と Bitbucket

Mercurialには素晴らしい日本語ドキュメントがついており、使い方も簡単な ので*1、それに従うだけでよい。Mercurial は gpg というエクステンションが公式パッケージに含まれているので、これを有効化して設定するとよい。わたしの ~/.hgrc はこうなっている。レポジトリ毎に使い分けたい場合は .hg/hgrc を以下のように設定すればよいと思う。

username = UENISHI Kota <kuenishi@gmail.com>

[extensions]
hgext.gpg=

[gpg]
cmd=/opt/local/bin/gpg
key=8CD45203

署名するには hg-sign だ。tip の代わりに特定のリビジョンをつけてもいいと思う。

$ hg sign tip
signing 3116:3dacfa73a0f7

次のユーザの秘密鍵のロックを解除するには
パスフレーズがいります:"Kota UENISHI (h) <kuenishi@gmail.com>"
4096ビットRSA鍵, ID 8CD45203作成日付は2016-07-11
$ hg log -r 3117
changeset:   3117:d7d5cf15a1b3
tag:         tip
user:        UENISHI Kota <kuenishi@gmail.com>
date:        Tue Jul 12 01:22:52 2016 +0900
summary:     Added signature for changeset 3dacfa73a0f7

Mercurialの場合は、直前のコミットの署名を .hgsigs というファイルに追加した変更をコミットするという形での署名になる。

$ hg diff -r 3116
diff -r 3dacfa73a0f7 .hgsigs
--- a/.hgsigs   Mon Jul 11 23:25:41 2016 +0900
+++ b/.hgsigs   Tue Jul 12 01:25:36 2016 +0900
@@ -1,1 +1,2 @@
(snip)

署名の確認は、署名対象のコミットを引数にして hg-sigcheck を呼ぶ。

$ hg sigcheck 3116
3dacfa73a0f7 is signed by:
 Kota UENISHI (h) <kuenishi@gmail.com>

これをBitbucketに投稿してみたのだが、Bitbucketのコミットのページになんか出るということもなかったので、なんだかつまんなかった。

まとめ

  • GnuPGを使って鍵を作り、自分のコードに署名する方法をまとめた
  • Github は署名をサポートしている(Mercurial @ Bitbucket はイマイチ)
  • 署名はプログラマーの基本動作
  • できればメールも署名くらいはしたい

おまけ

Fingerprintも出しておこう!!

$ LANG=C gpg --fingerprint 8CD45203
pub   4096R/8CD45203 2016-07-11 [expires: 2018-07-11]
      Key fingerprint = FF7E B3FF 4AEE ADEA 764D  2F33 BD95 145F 8CD4 5203
uid                  Kota UENISHI (h) <kuenishi@gmail.com>
sub   4096R/B99B64AE 2016-07-11 [expires: 2018-07-11]

追加

鍵を公開鍵サーバーに登録する

$ gpg --keyserver pgp.nic.ad.jp --send-keys 382AF48A 
gpg: sending key 382AF48A to hkp server pgp.nic.ad.jp

鍵のバックアップ

$ gpg --export --armor kuenishi@gmail.com > gpg-public-key.backup
$ gpg --export-secret-keys --armor kuenishi@gmail.com  > gpg-secret-key.backup
$ gpg --gen-revoke kuenishi@gmail.com > gpg-revoke-key.backup

鍵をインポートする

$ gpg --import gpg-public-key.backup
$ gpg --allow-secret-key-import --import gpg-secret-key.backup

このままだと、インポートした鍵は信用されていないので、ローカルで信用度をつけておく

$ gpg --edit-key kuenishi@gmail.com
(snip)
> trust
pub  4096R/8CD45203  作成: 2016-07-11  有効期限: 2018-07-11  利用法: SC  
                     信用: 未知の     有効性: 未知の
sub  4096R/B99B64AE  作成: 2016-07-11  有効期限: 2018-07-11  利用法: E   
[  未知  ] (1). Kota UENISHI (h) <kuenishi@gmail.com>

他のユーザの鍵を正しく検証するために、このユーザの信用度を決めてください
(パスポートを見せてもらったり、他から得たフィンガー・プリントを検査したり、などなど)

  1 = 知らない、または何とも言えない
  2 = 信用し ない
  3 = まぁまぁ信用する
  4 = 充分に信用する
  5 = 究極的に信用する
  m = メーン・メニューに戻る

あなたの決定は? 5
本当にこの鍵を究極的に信用しますか? (y/N) y

pub  4096R/8CD45203  作成: 2016-07-11  有効期限: 2018-07-11  利用法: SC  
                     信用: 究極        有効性: 未知の
sub  4096R/B99B64AE  作成: 2016-07-11  有効期限: 2018-07-11  利用法: E   
[  未知  ] (1). Kota UENISHI (h) <kuenishi@gmail.com>
プログラムを再起動するまで、表示された鍵の有効性は正しくないかもしれない、
ということを念頭においてください。

gpg>quit

*1:ここは英語だけど…