2018-10-14

消費税について考えたこと

「消費税10%は100円が110円になると考えるのではなく、1000万円が1100万円になると考えるべきだ」というつぶやきを目にした。しかしこれは言っていることが同じだ。

私はむしろ、消費税とは手取りに対する税金ではないかと考えている。貯蓄をしない家計では、消費税は実質手取りに対する税金だ。貯蓄をしない家計にとって、消費税10%とは、手取り20万円が18万円になることだ。

もっとも、この考え方にも問題はある。というのも貯蓄をしない家計は賃貸住宅に住んでいるだろうが、不動産の貸付料である家賃には消費税はかからない。手取り20万円の家計で家賃6万円の場合、14万円が12万6千円になるということだ。

消費税と言えばイタリアは先進国だ。1973年という昔から12%の消費税を導入し、1997年には20%に引き上げられた。そのイタリアでは、表に出ず消費税を脱税した地下経済とマフィアが発展した。

消費税が10%ともなると、日本でも地下経済と、地下経済の信用取引を履行させるためのヤクザが発展するだろうか。

日本ではヤクザの人権を剥奪する法律によりヤクザの人口が急激に減りつつある。また個人間の送金手段は経済に悪影響を及ぼすほど厳しく規制しているので地下経済も発展しにくい。

とはいえ、消費税があまりにも高くなれば地下経済は発展するだろうし、地下経済が発展したならば、その信用取引を確実に履行させるための機関としてヤクザが必要になり、ミカジメ料を支払うようになるのでヤクザも再び興隆するだろうか。

ということを考えながら、消費税制度の解説を眺めていたところ、興味深い定義を発見した。

「郵便切手類、印紙、証紙、物品切手の譲渡は非課税取引」

興味深い定義だ。すべての取引が地下経済に潜ることはできない以上、我々は表の取引もする。であれば、一部の取引を切手や印紙による取引とするのは現実的ではないだろうか。素晴らしいことに地下経済にする必要すらない。単なる非課税取引をしたにすぎないのだから。

具体的に考えよう。君は牛を二頭持っている。今君は牛を一頭売る契約をしたので契約書作成の税金を収めるため収入印紙を貼る必要がある。君は残りの牛一頭のミルクを売って現金を得て消費税を払い、残りの現金で収入印紙を買う。もし、君がミルクと収入印紙を直接交換したならば、消費税を支払う必要はない。

すばらしい。我々は現金ではなく収入印紙で支払うことによって消費税を節税することに成功した。消費税を支払わない分、ミルクの値段を下げるか、利益を上げることができる。

こう考えると、消費税の存在は貨幣経済に対する足かせであるように思えてくる。

しかし収入印紙は日本国に対する支払いにしか使えない用途の限定された通貨だ。現金という汎用的な通貨ではない。この問題をどうすればいいのだろう。

収入印紙には需要がある。需要があるものは汎用的な通貨である現金と交換できる。例えば金券ショップでは、収入印紙は額面の95%ぐらいで交換できる相場だ。ところで今の消費税は8%である。収入印紙で取引して収入印紙を現金化した場合の損失が、消費税率を下回る場合、これは得をしたと言えるのではないか。しかも合法だ。つまり収入印紙での取引は合法的な節税になるのではないか。

私は経済学にも消費税制度にも詳しくないのだが、この解釈は正しいのだろうか。

2018-10-07

Steven WeinbergのTo Explain The Worldを読んだ

邦訳では「科学の発見」という題名がついているSteven WeinbergのTo Explain The Worldを読んだ。

著者のSteven Weinbergはノーベル物理学賞の受賞者でイスラエルの熱烈な支持者だ。

冒頭で「本書で筆者は過去を現代の基準で批判する愚を犯す」と書きながら、この本は科学がどのように発展してきたかを解説している。

本書はまず、古代ギリシャにおける万物を構成する元素の説について取り上げる。古代ギリシャの哲学者が、元素は水だとしたり、火だとしたり、水、火、土、空気の4種類だと主張している歴史を取り上げる。

ここまではまあいいとして、プラトンの提唱した説を取り上げて悶絶する。プラトンは四大元素である火、水、土、空気について、とても小さい元素が存在し、5種類ある正多面体をそれぞれ割り当てた。たとえば火は正四面体で、水は正二十面体といった具合だ。その仮説を立てるのはいいとして、割り当ては一体どういう理由で行われたのか。プラトンは単にそれが理想だからとしか語らない。

科学というものは、まず観測し、観測結果から仮説を立て、仮説が観測結果に従うことを検証するものだ。

しかし古代ギリシャでは、科学は科学ではなく哲学で、単に理想を追求するものでしかなかった。なので万物を構成する元素は元素は火や水といったわかりやすい理想的なものになり、元素は5種類ある正多面体であるとし、完全数を尊びといった、現実の観測結果より理想を追求し、理想が現実に従わないことは無視されていた。

その後、本書の大半は天体の運行の予測を通じた科学の発展に費やされる。

天体の運行には規則性があり、古代から占星学などの存在により、天体の運行を正確に予測する需要があった。

古代ギリシャ時代から地球が中心で月、惑星、太陽、その他の恒星は全て地球の周りを回っている説が主流であった。

古代ギリシャ時代にはすでに地球を中心とした天体の運行を予測する数式モデルが考案されていたが、他の天体はすべて地球を中心とした真円で回るなどと定義されていたため、現実の観測とは大いに異なっていた。しかも、それぞれの天体が謎の理由で割り当てられた正多角形に内接する真円で回るなどという、これまたプラトンのように理想を追求したモデルであった。

天体は地球を中心に真円で回転するモデルを使うと、惑星はある時期だけ逆方向に回りだしたりする。惑星が大抵の言語で語源からして、惑う星であるのも、これが原因だ。

そこでプトレマイオス説が考案された。この説では、天動説で現実の観測結果に近似させるために、あまりにも無理やりな天体のモデルを考案した。天体は太陽を中心に真円で回っている。この真円を従円と呼ぶ。天体は従円を線上を中心としてさらに真円で回っている。この真円を周転円と呼ぶ。

プトレマイオス説は複数の真円を組み合わせ、真円の大きさをパラメーター化することで、惑星の運行を現実に近似させることを試みた。その結果、かなりの制度で現実の観測に近似した天体モデルを作ることに成功した。

プトレマイオス説は科学だ。観測から観測結果に従う数式モデルを作ったわけで、これは科学と言える。

プトレマイオス説は哲学者からは理想ではなく天体の予測のための方便であるとされていた。天文学者(この時代の天文学者は占星学をかねる)は積極的に使っていた。というのも、プトレマイオス説は現実の観測結果の近似していて、予測に役立つからだ。

その後、様々な天文学者がプトレマイオス説により複雑な周転円を追加することで、さらに現実の観測結果に近づける努力が行われた。

太陽を中心として天体が公転している地動説は以前にも理想として提唱されたことはあったが、現実の観測結果を説明できる具体的な数式モデルはコペルニクスによってまず作られた。ただし、コペルニクスの数式モデルは精度が悪かった。というのも、コペルニクスは天体は太陽を中心に真円で公転していると定義したが、実際には太陽は中心ではなく、天体の公転軌道は真円ではないからだ。

本書は中東の科学についても解説している。中東の科学はイスラム教の普及によって妨害されるまでヨーロッパより進んでいた。ギリシャ時代の学説は中東からもたらされる形でヨーロッパに再発見された。その後イスラム教の普及により中東の科学の発展は阻害された。

そしてガリレオ・ガリレイの時代までやってくる。ガリレオ・ガリレイは優秀な望遠鏡を発明し、望遠鏡によって精密な天体観測をした。その結果地動説を唱えるわけだが、その上でパトロンであるローマ教皇を天動説を信じているなどと批判したので宗教裁判にかけられて地動説を封印する。後世に残る逸話によれば、このときガリレオは「それでも地球は回っている」とつぶやきながら法廷を後にしたと言われる。

宗教裁判の後、ガリレオは晩年まで自宅に軟禁状態におかれるわけだが、ガリレオの科学への情熱は冷めていなかった。ガリレオは落下する物体の速度について研究していた。落下する物体の速度を観測するのは当時としては難しい。というのも、速度が速すぎるために正確な観測ができないためだ。

ガリレオはこの落下速度の問題に対し、科学的な観測方法を考案する。緩やかな傾斜面を転がる球を使うことで速度の計測を可能にした。時間の計測には水時計を使った。傾斜角を変えることでガリレオは速度は傾斜角に比例することを示し、傾斜角を転がる球は落下速度の計測の代わりに使うことができることを示した。もちろん現実には、球と傾斜面の摩擦にもエネルギーが使われるが微々たるもので当時実現可能な観測方法としては十分なものだった。ガリレオは傾斜角を転がる球を机の端から飛ばし、その軌道が放物線であることも観測している。

本書はニュートンの説明に移る。ニュートンによって科学革命はクライマックスを迎えるわけだが、しかしこのニュートンという人物はなんという奇人だろうか。ニュートンは生涯、イングランドのごく狭い地域より外に出ることはなかった。ニュートンは潮の満ち引きについて多大なる関心を持っていたにもかかわらず、生涯一度も海を見ることはなかった。中年に至るまでニュートンは身近に女を寄せ付けることがなかった。母親とて例外ではない。50代になってから親戚の美しい娘を家政婦として雇っているが、この2人の間に男女関係はなかった。ニュートンは科学以外にも、非科学的な錬金術や宗教について多大な著作を残している。

ニュートンの研究者の間でよく言われることには、ニュートンは最初の科学者ではない。ニュートンは最後の魔法使いである。時代が魔法から科学に変わる節目の時期にあって、魔法から科学への橋渡しをした人物だ。

ニュートンの法則を記述したPrincipiaは、単に重力を説明し得たために偉大だというわけではない。ニュートンはPrincipiaによって、物理的現象は簡単な数学的原則と、その原則の応用で説明できることを示したのだ。

中国の悪意あるハードウェアの細工を見破る方法

中国で生産されているハードウェアに悪意あるチップが取り付けられておりAppleやAmazonが被害にあっているとする報道があり、真偽について議論がある。

これに関連して、Hacker Newsで興味深いコメントが寄せられていた。

I have worked in card payment industry. We would be getting products from China ... | Hacker News

俺はカード支払い業界で働いている。中国から送られてくる製品にクレジットカード情報を送信する装置が取り付けられていることがある。これは国家による攻撃ではない。装置は生産ラインの途中で取り付けられている。大抵は賄賂を受け取った従業員によるものだ。装置が組み立てられた後は、改造防止の機能が動くので、改造を検知させずに装置を分解するのは不可能だ。

この問題が発覚してから、我々は製品の重さを計測することにした。我々も製品を分解することはできないからだ。分解したならば改造検知により装置は動かなくなる。

攻撃者は重さの計測に気がついたので、製品内部の必須ではないプラスチックを引っぺがして装置を追加することによって増加した重さの調整をしてくるようになった。

結局、我々は特別な土台を使い製品の角運動量(訳注:慣性モーメントか)を計測するようになった。とても高価な装置で角運動量を計測する。俺が作った土台を使って2つの角度から角運動量を計測している。2つの製品の角運動量がどの角度からでも一致するならば製品は同一というわけだ。すべての角度から角運動量を計測できないが、今のところ破られていない。

角運動量ではなく慣性モーメントだろうという用語の甘さや、慣性モーメントは3軸を使って全角度を測定できるのではというツッコミが入っているが、この話自体はよくあるものらしい。

なんでそんな製造段階で悪意ある細工が混入した製品を送ってくるところと取引を続けるんだというコメントに対し、この製品を製造しているのは今や中国をおいて他にないとか、中国の商習慣では信頼を前提としない契約による取引に応じてくれないとか、中国と取引するには製品の欠陥は自前で発見できなければならない、発見できないのはマヌケな顧客であり欠陥品で十分だとみなされる、などの中国のお国柄を指摘するコメントが続いている。

2018-09-20

健全なP2Pネットワークの信用のためには全利用者の参加が必須であるという話

「Zaifが5966BTCやられたようだな」
「ククク、あれは後発取引所ゆえ保有量が最弱」
「85万BTCを溶かした余の足元にも及ばぬ」

また一つ暗号通貨の取引所が失敗した。人はいつになったら学ぶのだろうか。中央権威のないP2Pネットワーク上の信頼は、利用者全員が参加することでしか担保できぬと。

信じられないことに、暗号通貨の利用者の中でも、なぜ暗号通貨が信用できるか、というより暗号通貨の何を信用しているかを理解しているものは少ない。皆暗号通貨と日本円などの国家通貨の交換レートしか気にしていない。国家通貨との交換レートなど、暗号通貨の実現している技術的な価値に比べればチリほどの価値もない。暗号通貨の価値は、中央権威のない通信越しに偽造できない通貨の取引を実現したということにある。

問題を簡単にするために、暗号通貨とは違う例で考えよう。

アリスとボブが仕切りを隔てて音声による会話しかできない状況に置かれている。この状況で、アリスとボブはコイントスによる勝負をする。コイントスは投げたコインが表か裏のどちらを上にして落ちるかで勝敗が決まる。アリスが表で勝つのであれば、ボブは裏で勝つ。アリスが裏ならばボブは表で勝つ。

アリスとボブが賭ける表裏を音声による会話で選択したとして、一体どうやって信頼できるコイントスをすればいいのだろうか。アリスとボブのどちらか一方がコイントスをして結果を相手に伝える場合、音声による会話しかできないので、相手はコイントスの結果を信用できない。アリスとボブ以外に勝負の審判をしてくれる都合のいい第三者はいない。

実は、この状況でアリスとボブがどちらも信用できるコイントスを行うことは数学的に可能だ。

では問題を変えよう。ここに60億人の人間がいる。全員、音声による会話しかできない。60億人のうちのある一人のアリスが、ある一人のボブに自分の持っている通貨の支払いたい。支払った後のアリスは通貨を失い、ボブは通貨を得る。しかし全員音声による会話しかできないのに、どうやったらそんな取引が信用できるのだろうか。

これも、数学的に信用できる方法がある。bitcoinを始めとする暗号通貨が行っているのはこれだ。

信用を担保するには、60億人が全員同じ方法で数学的な計算を行い、不正がないことを確かめなければならない。もし、30億人と一人が不正のための計算に協力したならば、アリスが支払ったはずの通貨はアリスの手元に残り、ボブの手元には通貨がない常態にすることも可能だ。しかし、そのような参加者の過半数を超える大規模な計算は難しい。

ただし、この方法で信用できるのは、ある暗号通貨の取引だけだ。暗号通貨と日本円の取引とか、物の取引は暗号通貨の信用の範囲外だ。

残念ながら、世の中の暗号通貨利用者の大半はズボラで、自ら信用を担保することを考えていない。こういうマヌケ共は、自ら信用のための計算をせずに、取引所と呼ばれる他人に計算を任せる。本来ならば証明された数学と計算力を信用すればよいはずの暗号通貨を、他人の信用に置き換えてしまう。こうなるともはやその計算を任された取引所が権威となり、単一障害点になってしまう。その結果、取引所が失敗すると任せていた全員が失敗する。

人はいつ学ぶのだろうか。

そういえば、CloudflareがIPFSのゲートウェイを提供するという興味深いニュースがあったので、今はIPFSについて学んでいる。今学んだ限りでは、名前解決であるIPNSを除けば、IPFSが喧伝していることはBitTorrentプロトコルに対するフロントエンドで実装できそうで、あまり目新しい価値はないように思える。そして、Cloudflareのような大手がゲートウェイを提供し、皆が自前でフルノードを動かさずにゲートウェイに依存することで、健全なP2Pネットワークの信用が損なわれてしまうだろう。

2018-09-17

Linus、今までの行いを謝罪し一時的にカーネルメンテナーの立場を退いて人の気持ちを勉強してくると発言

完全に背景事情を調べ上げたわけではないのだが、どうもLinusが毎年参加しているLinuxカーネルの会議に、Linusがスケジュールを間違えて参加できなくなるという事態が発生した。当のLinus本人はもう20年も続いている会議だし自分がいなくてもやっていけるだろうと楽観視していたが、会議自体がLinusの都合にあわせてリスケジュールされた。

LinuxにおいてLinus Torvaldsといえば第一人者であり極めて重要な存在で、そのLinusが毎年参加している重要な会議にLinusが参加できないとあれば、その他のあらゆるコストを度外視して根回し調整を行い、Linusが参加できるようにイベント全体のリスケジュールを行うのは人間の感情から考えて当然である。しかし当のLinus本人は他人の感情が読めず、そこまでの大事になるとは考えていなかった。その認識の差が今回の騒動に発展した。

Linux 4.19-rc4 released, an apology, and a maintainership note - Linus Torvalds

[ その他の長々しい話 ]

いつもの発表とは違う先週のことについて。メンテナーとカーネルコミュニティについての、公になっているカーネルサミットによるものと様々なプライベートなやり取りの議論について。議論の一部は俺がメンテナーサミットのスケジュールを間違えたから起こったわけだが。

こういう議論は今週になって初めて始まったわけでもない。メンテナーとコミュニティについては長年議論してきたわけだ。プライベートでもメーリングリストでもたくさん議論されてきた。カンファレンスでも毎回トークがあるし、これも、一般向けのものと、廊下を歩きながら話す種類のものがある。

先週がいつもと違ったのは、俺の反応と、俺が反応しすぎたためだ(判断は読者に任せる)

要するに議題は2つある。

ひとつは俺がメンテナーシップサミットのスケジュールでヘマをやらかしたことに対する俺の反応だ。いや、実際日付を間違えたのは失敗だったが、でも正直なところ、俺がここ20年ぐらい参加していたカーネルサミットに今回ぐらい参加しなくてもいいんじゃないかと思っていたのだ。

実際には、サミットがリスケジュールされたし俺の「俺なしでもやれるんじゃない」って意見は覆されたわけだ。だがこの状況が別の議論の呼び水になった。これが議題の2つめにかかってくるわけだが、俺は気がついたんだよ。俺って人の気持ちが読めないんじゃないのってことに。

要するに「鏡で自分の顔を見てみろよ」って瞬間だな。

というわけで、俺がついに気がついたこととして、俺が毎年のカーネルサミットを今回ばかりパスするのは面白くもないしいい兆候でもないってことと、俺は今の今までコミュニティの気持ちを汲み取れていなかったということだ。

何というかな。無視できるってものは、だいたい俺が首を突っ込みたくないものなんだな。

これが俺という人間の現実だ。俺は他人の感情を読み取るのが得意ってタイプの人間じゃないし、そのことはみんなも当然気がついていただろうから驚きはないだろう。俺以外はな。俺が長年、他人の気持ちを読み取れずにいて、大人でない環境を作り出していたってのは良くないことだ。

今週、コミュニティ内の人間は俺が人の感情を理解できていないということについて批判してきた。俺の反論は大人気なかったし良いものでもなかった。特に俺個人の問題としたことについてだ。俺がよりよいパッチを追求することについて、これは俺の中では当然のことだ。これはどうもよろしくない態度だと気がついたわけで、正直すまんかった。

こうくどくど書き連ねているのはつまり俺が誤りを認めて、おいおい、お前は態度を改めなければならんぞ、という辛い思いをかみしめているのであって、俺の態度で気分を害したりカーネル開発から抜けてしまった人間にあやまりたい。

ちょっとここらで休みを取って、他人の感情を理解する方法と、適切な応対の方法について、誰かから学んでくる。

別の視点で考えると、カンファレンスに呼ばれた時、俺はよく、カーネル開発の厄介な問題点はたいてい技術的な問題ではなくて、開発フローと態度の変化の問題なのだというトークをよくする。

この厄介な問題点というのは、パッチを管理する方法とか、やり方の大規模な変更とかだ。「パッチとtar-ball」によるリリース(15年前に「Linusはスケールしない」という厄介な議論が持ち上がった原因)から、BitKeeperを使う方法に変わり、それも無理になってきたのでgitを使う方法に変わった。

そういう厄介な問題点は、ここ10年ぐらいなかったわけだ。だが今週、それに匹敵する厄介な問題点が見つかった。

これを4.19-rc4のリリースに結びつけると(いや、実際関係しているのだが)、4.19はなかなかよいものになると思うよ。このリリースサイクルは「落ち着いた」期間になるし、Gregに話はつけておいたので、Gregが4.19を取り仕切ってくれる。その間に俺が休みを取って、俺の態度について修正してくるわ。

これは「俺はもう燃え尽きた。もう逃げ出したい」っていう休みじゃない。Linuxのメンテナーを辞めたいなどとは思っていない。実際逆だ。俺はこの30年近く関わってきたプロジェクトをまだ続けたい。

これは前にもあったように、"git"という小さなツールを書くためにカーネル開発をちょっと停止するひつようがあったように、今回もちょっと休憩して、誰かに手伝ってもらって、態度を改め、俺のツールとワークフローの問題を修正するということだ。

実際のところ、修正の一部はツールで解決できるかも知れないのだ。例えば、メールフィルターをかまして、俺が罵詈雑言を含むメールを送信しようとしたら差し止めるとか。ほら、俺はツールの信者だからさ、一部の問題は、簡単な自動化で防げるかもしれないだろ。

俺が本当に「鏡を見た」とき、明らかに俺に必要なのは変化だけではないわけだが、いや、ほら・・・何か提案があったらメールで送ってくれよな。

メンテナーサミットで会えるのを楽しみにしているよ。

Linus

2018-09-10

TempleOSの作者Terry Davisが列車に引かれて死んだ

Man killed by train had tech following | The Dalles Chronicle

Man killed by train had tech following By Neita Cecil As of Friday, Septem - Pastebin.com

両親と喧嘩をして勘当され路上生活をしていたTerry Davis(Terrance Davis)が8月11日に列車に引かれて死んだことが確認された。享年48歳。

Terry DavisはTempleOSの作者だ。

TempleOS

読者の多くはTempleOSを知らないだろう。TempleOSとはx86-64 Ring-0上で動作するOSだ。プロセス分離はなく、メモリ保護もなく、そもそも仮想メモリではなく物理メモリアドレスを直接使うOSだ。コンセプトは古き良きCommodore 64の現代版だ。あの頃のPCはメモリアドレスは直接メモリアドレスであって、仮想メモリによってどこか不定の物理メモリアドレスにマッピングされたりなどしなかった。

TempleOSはキリスト教の影響を受けておりキリスト教の聖書やキリスト教に由来するゲームが多数入っている。

TempleOSはHolyCで書かれている。HolyCはC言語に似た文法を持っている。TempleOSのシェルはHolyCのJITコンパイラーになっていて、シェルに書き込むと、HolyCがJITコンパイルされ実行されるようになっている。

作者は統合失調症を患ったOS開発者で、大抵のインターネット上のフォーラムからは出禁の扱いを受けていた。なぜならば、Terry Davisの発言には必ず人種差別と罵詈雑言が含まれていたからだ。彼にとってほとんどの人間は「ニガーでCIAのスパイ」だと認識されていた。

Terry Davisは統合失調症の症状が強く現れてからは職を辞め、両親と同居して、キリスト教の神の神殿をコンピューター上に再現するTempleOSを開発していた。

何年もそういう状況であったが、2017年に両親とだいぶひどいいさかいを起こし、ホームレスになっていた。

ホームレスになった後も定期的に動画が上がったりなどして生存が確認できていたが、ここ最近、死亡説が噂されていた。それが確認されたことになる。

悲しい

GitHubからDXVKレポジトリが消失

GitHubのDXVKレポジトリが500を返すようになった。

https://github.com/doitsujin/dxvk

DXVKはDirectX 10/11の自由なVulkan実装だ。DXVKによってWineやProtonはDirectXの使われたWindows用ゲームをGNU/Linuxで実行することができる。DXVKにより不自由なMicrosoft Windowsはとうとうゲーム用OSとしても完全に敗北し、その座をGNU/Linuxに明け渡すことになる予定だが、どうしたことだろう。

DXVK github not found and valve's copy throws error? Whats happening? : linux_gaming

どうやら、DXVKの作者のGitHubアカウントが謎の理由でBANされたそうだ。

DXVK github not found and valve's copy throws error? Whats happening? : linux_gaming

作者によってすぐにGitLab上でDXVKが公開された。

Philip Rebohle / dxvk · GitLab

Redditでは「そういえばGitHubはMicrosoftに買収されるんだよな」というジョークが書き込まれているが、ジョークで済むだろうか。

追記2018-09-10 9:14: 復活した。

2018-09-03

江添ボドゲ会@9月8日

自宅ボードゲーム会を以下の要領で開催します。

江添ボドゲ会@9月8日 - connpass

2018-09-02

DNAの読み取りについてプログラマーが誤解していること

世の中にはDNAの読み取りを使った技術が実用されすぎている。DNAを使った生物の共通祖先の判定、人間の出アフリカ以降の移動の推定、特定の病気にかかりやすい遺伝子を持つかの判定、親子鑑定、刑事裁判におけるDNA鑑定などなど。

あまりにもDNAの読み取りを使った技術が実用化されすぎているため、世間ではDNAの読み取りは簡単なものだと考えている。プログラマーとて例外ではない。

大抵のプログラマーはヒトDNAの読み取りを以下のように考えている。

「一本の長い磁気テープを先頭から末尾までシーケンシャルにリードする」

より現実的に例えると以下のようになる。

  • 長さ30kmの長大な磁気テープをだいたい長さ1cmのテープ片に切断する
  • 上記1cmのテープ片を数百本複製する
  • 上記複製した数百本の1cmテープ片をマイクロメートル単位のテープ片にズタズタに切り裂いて混ぜ合わせる
  • 上記混ぜ合わせたマイクロメートル単位のテープ集合からランダムでテープ片を手当たりしだいに読み込み、組み合わせパズルを解いて元の1cmの磁気テープ分の正しいデータ配列を決定する
  • 残りの29.999999kmのテープについても同様に1cmづつ処理する

マイクロメートル単位のテープ片をランダムに読み取って組み合わせパズルを解き、元の1cmのテープ分のデータ配列を決定するのはソフトウェアにより実装されている。読者はそのようなパズルを解くプログラムをバグなしで実装できるだろうか。

ただし、より例え話を現実に近づけると、1cmのテープ片をマイクロ単位のテープ片に切り裂くのはランダムではない。この1cmのテープ辺には数百-2ビットから数千-2ビット程度のデータが記録されている。テープをマイクロメートル単位に切り裂くカッターは、テープの末尾の2ビットの値がn回目に出現したmであるときに切断するという条件付きカッターだ。これにより、00, 01, 10, 11のいずれかの2ビット値の1回目の出現、2回めの出現、3回目の出現といった単位でテープをカットできる。

マイクロメートル単位のテープ辺を読むリーダーはあまり融通が聞かない。すでに読んだテープ辺と同一内容のテープ編を何度も読み込むことになるし、同一内容のテープ辺は同じ回数読み込まれるわけではない。読み込みエラーが発生して任意の2ビットが別の値になってしまうかもしれない。なのでできるだけ何度も読み込み、まれにしか現れない異端データを読み取りエラーと判断して除外する処理も必要だ。

これを考えると、プログラマーとしての私は、DNA読み取りを使う技術が信頼できなくなってしまう。私のDNAを読み取った結果、特定の病気になりやすい遺伝子が含まれているとか、ある人物と親子関係にあるとか、犯行現場に残されていたDNAと一致したなどと言われても、その結果は信頼することができない。なぜならばDNAを読み取るという処理が極めて大雑把で信頼できない確率的な統計処理だからだ。

現実のDNA読み取りはどうしているかと言うと、30億塩基配列ほどあるヒトDNAを、数百塩基から数千塩基のサイズに分割し、たまたま高温に耐える都合のいい細菌から得たDNA複製酵素と一緒に容器の中に放り込み、定期的に温度を上げ下げする装置を使い、ポリメラーゼ連鎖反応を起こしてDNA片を複製する。そして特定の塩基配列に対してのみ反応してDNAを切断する酵素を使い、n回目に4種類ある塩基(アデニン、グアニン、シトシン、チミン)の特定の一種類が現れたDNAをそこで切断させる。そうやって切断されたDNA片を片っ端から読み込み、組み合わせパズルを解く。

実際、アメリカではDNA鑑定の結果が証拠として信頼できないとして、DNA鑑定に使われたソフトウェアを検証するために開示請求がなされたこともある。

せめてプログラマーだけでもDNA読み取りの正しい理解をしてほしいものだ。

ssh経由のtmuxの中で動くvimのウインドウサイズ変更にマウスを使う方法

私はマウスが好きだ。

30行以上、100列以上の文字が表示できる端末を使っている私にとっては、マウスは必須である。画面上に表示される任意の1文字にカーソルを合わせたい場合、キーボードだけでカーソルを移動させるのはとてもつらい作業である。一方、マウスならばその場にカーソルを動かすだけでよい。

端末を分割して複数の画面にする時、それぞれの画面のサイズをその場で微調整するには、キーボードで画面サイズの数値を指定するよりは、やはりマウスで直感的にドラッグしたい。

例えばvimだ。以下のようにすると

:set mouse=a

Vimはマウスを扱えるようになる。端末の任意の文字にカーソルを合わせるのにマウスを使えるのみならず、マウスでスクロールやマウスで範囲選択もできる。

Vimは画面を複数のWindowに分割できる。

:split
:vsplit

このとき、マウスを有効にしているとウインドウの枠をドラッグすることでサイズを直感的に変更できる。

tmuxも重要なソフトウェアだ。

tmuxは.tmux.confに以下の設定をすれば、

set -g mouse on

マウスを使えるようになる。マウスでスクロール、範囲選択ができるし、

Ctrl-b "
Ctrl %

で作ったtmuxのpaneのサイズもドラッグで直感的に変更できるようになる。

ところが、tmuxのなかで実行したvimのウインドウのサイズをマウスで変更できないことに気がついた。

調べた結果、これは.vimrcに以下のように書き込めばできる。

set mouse=a
set ttymouse=xterm2

どうやらxterm2にあるドラッグ中もマウス入力を通知し続ける機能を使うそうだ。tmuxも対応している。

これで問題は完璧に解決したと思ったが、もう一つ問題に出くわした。ssh先のリモートで実行したtmuxの中で実行したvimではマウスによるウインドウのりサイズができない。

これは.tmux.confに以下のように書けばできる。

set -g mouse on
setw -g alternate-screen on

man tmuxをみるとデフォルトでonになっているはずだが、なぜかUbuntu server 18.04ではonになっていないようだ。

これで以前からやりたかったssh越しにも違和感のまったくない環境を作ることができた。

2018-09-01

ポータブルオーディオプレイヤーは二極化している

今のポータブルオーディオプレイヤーは二極化している。格安のゴミみたいな製品と、オーディオフィリ向けのクソみたいな製品があり、その中間がない。

最近、減量のためにジョギングを再開した。ジョギングは一回あたり1時間ほど行うのだが、これが思いの外ヒマだ。この時間を有意義に使いたい。走っている最中にできることは音を聞くぐらいなものだ。音楽に興味はないが英語の朗読を聞くのは有意義なことのように思われる。例えば筆者はまだシェイクスピアのハムレットを読んだことがない。ハムレットを読むには時間がかかるが、ジョギング一回あたりの1時間を使えば、何度か走るだけでシェイクスピアを通して聞くことができる。

そこで早速、ジョージ・オーウェルの1984やシェイクスピアのハムレットを朗読した自由な録音をダウンロードした。

LibriVox

元々が低音質なソースであるのだから、それほど高級な製品はいらない。そこで、アマゾンでよく購入されていた適当な格安ポータブルオーディオプレイヤーであるAGPTEK A01Tと、格安BluetoothイヤホンであるSoundPeats Q30を購入した。

さっそくハムレット朗読のmp3ファイルをコピーするが、なぜか再生の順序がファイル名の文字列順にソートされない。どうやら、FAT32のファイルのディレクトリーエントリーの順番で再生されるようだ。そこで仕方なく、以下のようにして問題を解決した。

ls | while read file ; do mv $file path-to-mp3-storage/$file

いざ聞いてみると、今度は片耳にしか音が聞こえてこない。どうやらこの格安ポータブルオーディオプレイヤーは、モノラルmp3ファイルに対して片耳しか出力しないようだ。残念ながらモノラルmp3ファイルを再エンコードなしでステレオにすることはできないので、以下のようにして無駄にステレオにした。

ls | while read file ;< /dev/null do ffmpeg -i $file -ac 2 -b:a 320k path-to-mp3-storage/$file

当初動かずに困惑したが、ffmpegが標準入力を食べてしまうことが原因だった。

そしてGNU Parallelを使ったほうがよかったことに実行した後に気がついた。

mp3のエンコード速度はそれほどパフォーマンスを重視していない私のラップトップでも175倍速だった。たしか私がmp3プレイヤーを使っていた15年ほど前はせいぜい20倍速に満たない程度だった気がするのだが、いい時代になったものだ。私の一つ上の世代は、mp3をリアルタイムデコードするためにCPUをオーバークロックしたと聞く。

本の朗読を聞くために買ったのだからあまり期待はしていなかったものの、この格安ポータブルオーディオプレイヤーはあまりにもひどい品質だ。おまけに、文字コードの対応もひどい。どうやらいまだにUCSに対応していないらしく、本体の言語設定をした文字に引きづられる。例えば言語をEnglishに設定するとASCII以外が文字化けし、日本語に設定するとシフトJIS外の文字が文字化けするようだ。これは解せない。ファイルシステムであるFAT32はファイル名をUCS-2で管理しているのだから、文字化けを起こすのはわざわざ何かとてもバカなことをしているとしか思えない。

不思議なことに、このポータブルオーディオプレイヤーにはFMラジオとかテキストリーダーとか万歩計とか録音とか動画再生などの様々な機能がありながら、ファイル名によるソート機能すらない。

ではもっとマシなポータブルオーディオプレイヤーはないものか。実は今ポータブルオーディオプレイヤーは二極化しているのだ。

ひとつには私が買ったような数千円で変えるクソのような格安の粗悪品。もう一つには、最低数万円から数十万円もするようなオーディオフィリ向けのバカのような高級品だ。中間層の市場はスマフォが完全に支配してしまったため、ポータブルオーディオプレイヤーは格安と高級品に二極化してしまったのだ。

では高級なポータブルオーディオプレイヤーとはどのようなものだろうか。安いものでも数万円から、高いものになると30万円ぐらいする。30万円だ。嘘ではない。本当だ。曰くハイレゾ、曰く超高性能DAC、曰くUSB Audio/DACに両方とも対応。厳選された高性能で高品質なキャパシタ、コイル、メッキなどなど。

ちょっとまってもらいたい。人間の可聴域は若者でもせいぜい20kHz程度であり、だからこそせいぜい40KHzのサンプリング周波数で20kHzまでの音を再現できるようにしているのだ。ハイレゾに意味はない。USB Audioに対応しているのはともかくとして、なぜUSB DACとして使える必要があるのだ。そして高級なキャパシタやコイルに至っては完全にオーディオフィリの領域だ。

5000円ぐらいでまともなUIを備えたポータブルオーディオプレイヤーはないものか。そもそも格安プレイヤーにすらいらない機能が多すぎる。必要なのはファイル名によるソート、シークバー、Bluetoothだ。自由にプログラミングできればなおよい。

という愚痴を漏らしていると、物好きな同僚がRaspberry Pi Zero WHを進めてきた。初代Raspberry PiのSoCを使い、WiFiとBluetoothが搭載された低電力なボードだ。Raspberry Piはその普及によって圧倒的に自由なソフトウェアスタックを得た。その性能はmp3やoggのリアルタイムデコードを難なくこなせるであろうし、Bluetoothも使える。しかも値段も2千円程度。確かに理想的なポータブルオーディオプレイヤーのように思える。

問題はUIをどうするかだ。タッチパネル付きのディスプレイをつけるのが一番いいように思える。考えてみよう。

2018-08-23

Steam Playで不自由なWindows用ゲームをGNU/Linux上で実行するにはPython 2が必要

Steam Playが発表されたので、早速使ってみた。

Steam PlayというのはWineからforkしたValveのProtonを使ったGNU/LinuxでWindows用ゲームを実行する機能だ。なぜWineをforkしているかというと、ProtonではWineにまだ入っていない変更を使っているからだ。例えばDirectXをVulkanで実装したdxvkや、同期処理をユーザースペースで行うValveが開発したWineに対するパッチesyncを使っている。

https://github.com/ValveSoftware/Proton

Steam Playを使うには、まずSteamクライアントのSettings→Account→Beta participationからSteamクライアントBetaを使う設定であるSteam Beta Updateに切り替え、Steamクライアントをアップデートする。

すると設定にSettings→Steam Playが追加されているのでこれを有効にする。Valveが検証したゲーム以外のすべてのゲームでSteam Playを有効にするには、その設定項目のEnable Steam Play for all titlesを有効にする。これでGNU/LinuxのSteam クライアントでもWindows用ゲームがインストール、実行できるようになる。

ここまではSteamクライアントで必要な変更だ。GNU/Linux側でも必要な用意がある。Steam PlayにはVulkanに対応したかなり最新のグラフィックスタックが必要になる。

詳しい内容は

https://github.com/ValveSoftware/Proton/blob/proton_3.7/PREREQS.md

に書いてある。

NvidiaのGPUを使っている場合は、不自由なバイナリブロブドライバーを396.51以上のバージョンにしなければならない。Ubnuntu 18.04のドライバーはLatest Long Lived Branchである390を使っているので、最新のバージョンをインストールしなければならない。

sudo add-apt-repository ppa:graphics-drivers/ppa
sudo apt install nvidia-driver-396

AMDとIntelのGPUを使っている場合は、最近のMesaとLLVMをインストールしなければならない。

sudo add-apt-repository ppa:paulo-miguel-dias/mesa
sudo apt dist-upgrade
sudo apt install mesa-vulkan-drivers mesa-vulkan-drivers:i386

AMDでVRゲームを実行する場合は、以下のパッケージが必要だ。

sudo add-apt-repository ppa:kisak/steamvr4pk
sudo apt dist-upgrade
sudo apt install linux-generic-steamvr-18.04

現在、IntelのGPUによるVRゲームはサポートしていないそうだ。

DirectX 11を使ったゲームを実行するには、NVIDIA 396.51以上、もしくはMesa 18.1.xが最低でも必要だ。LLVM 7も推奨されている。

OpenCLを使ったゲーム(DOOM 2016, Google Earth VR)を実行するには、Mesa 18.2.x以上が最低でも必要になる。

一部のディストロでは1プロセスあたりのfd limitが低いので、これを変更しなければならない。4096は1990年台には妥当な値ではあったかもしれないが、この2018年には少なすぎる。DebianとUbuntuでは上限が引き上げられているので問題はないそうだ。

そして最後にとても重要なソフトウェアをインストールする。Python 2だ。

sudo apt install python-minimal

こともあろうかこの2018年にProtonとgit submoduleしているffmpegがpython 2に依存している。

これでSteam Playを使う用意が整った。いくつかのWindows用の不自由なゲームを実行してみたが、いずれもよく動いている。

GNU/Linuxにおけるゲームは卵が先か鶏が先かという問題に直面していた。ゲーム開発者はGNU/Linuxゲーマーの需要がわからないのでGNU/Linux用のゲームを出さず、GNU/Linuxユーザーは対応しているゲームが少ないので仕方がなくWindowsかWineを使うので、結果として潜在的なGNU/LinuxゲーマーはWindowsゲーマーとしてカウントされてしまう。するとゲーム開発者はGNU/Linuxゲーマーの需要がわからないというデッドロック問題だ。

Steam Playによるゲームの実行は、GNU/Linuxユーザーとしてカウントされ、ゲーム開発者に通知されるしSteamの統計にも出る。これにより我々GNU/Linuxゲーマーの時代が訪れる。Microsoftの不自由で不便で非効率的なWindowsは最後の砦であったゲーム環境としても滅ぶのだ。未来は明るい。

2018-08-14

江添ボドゲ会@8月18日

江添自宅ボドゲ会を以下の要領で開催します。

江添ボドゲ会@8月18日 - connpass

2018-08-12

違法な職務質問を受けたので国賠訴訟を起こした裁判の傍聴のお知らせ

私の裁判の傍聴をしたいという人が何人かいるので、ここで証人尋問の傍聴の告知をしておく。

  • 日時: 2018年9月19日 水曜日 13時30分から16時頃まで
  • 場所: 東京地方裁判所631号法廷

傍聴をするためには、指定の日時の少し前に東京地裁に行き、金属探知機のある入り口を通過し、そのままエレベーターで6階まで上がって時間通りに631号法廷に行くだけだ。特に予約や手続きは必要ない。また、途中退出してもよいそうだ。

裁判の内容だが、私は約1年前に警察官から違法な職務質問を受けたので東京都を相手に起こした国賠訴訟だ。

本の虫: 警察官に職務質問をされた話

本の虫: 濫用に当たる職務質問を受けたと考えたので弁護士に相談して訴訟を起こすことになった話

裁判を起こすことになって初めて知ったのだが、警察というのは地方自治体の行政であるので、東京都内で生じた警察の行為について裁判を起こす場合、被告は東京都になる。

裁判は公開かつ口頭で行われるということになっているが、その実態としては、口頭で話すべき内容をすべて書面にまとめておき、あらかじめ裁判所に提出する。書面にすべてがまとめられているので、実際の期日に物理的な裁判所でやることはほとんどない。

実際に裁判所で行われる「儀式」は以下のようになる。

裁判官「原告/被告からは準備書面が提出されていますが、これは?」
原告/被告「陳述します」
裁判官「では次回期日ですがX月Y日のZ時からでは?」
原告/被告「その日は差し支えです/大丈夫です」

事前に提出した書面について「陳述」する宣言と、証拠の原本の確認と、次回期日を決めることしかしていない。

このようなやり取りが数カ月に一回発生するのが裁判だ。1回あたり5分から10分で終わる。この裁判の傍聴もできるのだが、傍聴しても退屈なので、これまで特に案内はしてこなかった。

今回は証人尋問が行われる。証人は原告である私と、職務質問の最初から最後まで現場にいたという警察官だ。当事者ではない第三者が傍聴して退屈ではない裁判というと、まず証人尋問だろう。

ところで、今回の裁判で気になる点としては、裁判官が頻繁に交代することだ。前々回でいきなり3人全員が同時に交代したかと思ったら、前回はさらに2人同時に交代した。裁判官の一部が交代するのはよくあることだが、それでも普通は一人ぐらいは最初から最後まで同じ裁判官を残すものだという。さもなければ、判決を書く裁判官はこれまでの裁判の口頭弁論も証人尋問も直接聞かず、書面だけで判断することになるからだ。一人でも最初から担当していた裁判官が残っていればその裁判官が物理的に見ているわけだから、その裁判官が知っているということにできるが、3人同時に交代してしまってはその手法も使えない。

今後の想定としては証人尋問を経て年内には判決が出る見込みだそうだ。

2018-07-31

GCCのgit移行が難航中

GCCはgitへの移行を計画しているが、GCCの既存のsubversionレポジトリをgitレポジトリに変換する作業が難航している。

GCCの移行作業を検証しているのは他ならぬEric S. Raymond(ESR)だ。

ESRお手製の変換ツール、reposurgeonはsubversionからgitへの変換ができる。

Resource page for reposurgeon 3.44

しかしGCCは30年もの歴史を持ち、そのsubversionレポジトリも複雑だ。

ESRはGCCのためにreposurgeonのバグを潰し、勢い変換しようと試みたが、意外な障害に出くわした。メモリ不足だ。

GCC's Conversion To Git Is Being Held Up By RAM, a.k.a. Crazy DDR4 Prices - Phoronix

ESRの所有する64GBのメモリを詰んだマシンではメモリ不足で処理できない。そしてDDR4メモリの値段は高騰している。GCCのビルドサーバーに128GBのメモリを詰んだものがあるからそれを使わせてくれとか、reposurgeonをPythonからGoに移植すればメモリ消費量は減らせる可能性があるが移植は困難を極めるとか、ESRに投げ銭してメモリを買わせようなどと議論をしていたのが7月はじめ。

さて、今はメモリ以外の問題に出くわしている。

GCC's Conversion To Git Is Still Turning Out To Be A Massive Headache - Phoronix

どうもGCCの膨大で複雑な歴史を正しくgitで表現する方法について議論の余地がある他、変換結果が壊れることもある。問題を解決したいが、変換自体がとても遅いため、デバッグが困難だという。

https://gcc.gnu.org/ml/gcc/2018-07/msg00322.html

トンネル出口の明かりが見えたと思ったら対抗列車が突っ込んできやがった。

もう変換はほぼほぼ終わりだと思っていたのに。俺はtrunkとブランチすべてがクリーンに変換されるのを確認したのに。捨ててもいいことに同意した失敗ブランチただ一つを除いては。

後残っているのはexecute-permission propagationとかmid-branch deleteをどうするかという問題だけで、前者はすでに解決済みだし、後者も解決に取り掛かっている。最終的には年末には、たぶん8月とか9月には、完了できるはずだったのに。

そしたらこのザマよ。俺の最新の変換がtrunkで間違った結果を出しやがった。これは実際ヤバイ問題で、GCCレポジトリがあまりにも巨大すぎるので調査するのに時間がかかりすぎる。SVNダンプファイルをreposurgeonで読み込むだけで4.5時間かかるし、フル変換に9時間はかかる。レポジトリは俺が最適化を考えるのと同じぐらい早く増大しているぜ。

しかも悪いことに、クリーンな変換ができるコミットまで戻っても失敗する。たぶん俺がへんてこなブランチコピーの対処を実装した結果こうなってるんだと思う。

パーティーに遅れてやってきた奴のために説明してやると、Subversionのダンプファイルの処理シーケンスの解釈は単純で検証も楽だ。ブランチコピー操作を除いてはな。ブランチコピーが他の操作に及ぼす影響だけはマジで闇が深い。

Subversionのコードが何をすべきかっていう正しいセマンティクスは存在するわけだが、古のSubversion開発者が理解していたことは、今や失われている。ダンプフォーマットはまともにドキュメント化されていない。今の不完全なドキュメントが存在する理由は、他でもない俺が解析したからだ。でも俺のドキュメントも疑問だらけだし、その疑問にはSubversion開発者も回答できないできる。

なのでレポジトリを変換する際にブランチコピーに関連した謎の挙動に出くわすのはよくあることだ。普通、おれは問題のコミットをbisectして、

  1. ダンプを問題が再現する最小のセグメントに切り取る
  2. content blobsをsource commitを識別できるunique small cookiesに置換する処理を行って結果が正しいことを検証
  3. topological reduceしブランチコピーもプロパティ変更でもない無価値なコミットを除去し、結果が正しいことを検証
  4. 手動で不必要なブランチをreposurgeonで削除

いつもなら、俺は今頃、問題を再現できる割と小さめのレポジトリ(今までで200コミットを超えたことはない)を作ってる。デバッグレベルを上げて変換を観察し、何が起こっているのかを観察する。そして問題を修正し、問題を再現する最小例は新たなテストケースになるって寸法だ。

これによって、ダンプファイル解析を着実に改善していき、Subversionのコードがやっていることをより忠実にエミュレートしていく。簡単な仕事ではないが、エッジケースを埋めていくほど楽になる。今まではこれでうまくいってきた。

GCCレポジトリのサイズでは、この戦略がうまくいかない。軽く計算するだけで、bisect一回で最短でも18日かかる。現実的には一ヶ月近くかかるだろう。

つまり、現状ではゲームオーバーで負けたってことだ。GCCレポジトリはでかすぎる上に変すぎる。

この問題を現実的に解決するには、俺のツールはすっげー速くなる必要がある。だいたい桁違いに早くないといかん。

ハードウェア性能を上げるのは無理だ。シングルプロセスを1.3GHz以上にあげたコンピューターはこの世に存在しないし、問題は並列化できない。

ソフトウェアの変更でうまく行く可能性はある。俺はreposurgeonをPythonからGoに移植するということについて考えている。repocutterで実験してみたところ、{Python版の40倍高速化した。reposurgeonではそんなに高速化するとは思えないが、問題を現実的に解決できるぐらいには高速化できるだろうと踏んでいる。40倍の半分だったとしても、9時間のテストランが13分になるわけだから。

この計画の問題点は、GOに移植するのは困難を極めるってことだ。めっちゃむずい。どのくらい時間がかかるかわからんが数カ月単位でかかる。

GCCはどのくらい辛抱強く待つのか決める必要があるな。現状だと、今のソースツリーの状態をそのままgitにしていちからはじめるほうがマシかもしれん。歴史は記録だけに留めるとして。

2018-07-24

しないでマイクロソフトのスタイルガイドライン準拠の翻訳

マイクロソフトは将来的に買収する見込みのGitHubで.NETのドキュメントを公開している。ハロウィーン文書が公開された頃のマイクロソフトからは考えられないほど変わったものだ。

https://github.com/dotnet/docs.ja-jp

その中にある変数名の命名規則に関するスタイルガイドラインについて書かれたドキュメントの文章がおかしい。

https://github.com/dotnet/docs.ja-jp/blob/live/docs/standard/design-guidelines/names-of-type-members.md

しないで動詞または動詞句は、メソッドの名前を指定します。

しないで名詞、名詞句、または形容詞を使用してプロパティの名前を付けます。

しないで次の例のように、"Get"メソッドの名前に一致するプロパティがあります。

しないで後に"List"または"Collection"単数形の語句を使用する代わりに、コレクション内の項目を記述する複数形の語句でコレクションのプロパティの名前を付けます

日本語として極めて不自然な文章になっていて意味がわからない。

原文は英語で書かれている。

https://github.com/dotnet/docs/blob/master/docs/standard/design-guidelines/names-of-type-members.md

原文を確認するとようやく意味がわかる。

DO give methods names that are verbs or verb phrases.

DO name properties using a noun, noun phrase, or adjective.

DO NOT have properties that match the name of "Get" methods as in the following example:

DO name collection properties with a plural phrase describing the items in the collection instead of using a singular phrase followed by "List" or "Collection."

なるほど、"DO"を間違えて「しないで」と訳してしまったのだな。"DO NOT"も「しないで」と訳されている。翻訳する上で間違えて機械的に置換でもしたのだろう。原文の文章の形をなるべく維持したまま日本語に訳すならば、"DO"を「正:」、"DO NOT"を「誤:」とでもすればいいのだろう。ただ、その場合"DO NOT"を使った文中で代替案も示してしまっているのが問題なので、これはできれば原文自体を「すべきこと」と「すべきでないこと」に分割すべきだろう。

そして間違いが20日にissueで指摘された。

https://github.com/dotnet/docs.ja-jp/issues/118

そして土日を挟んで今日、マイクロソフトから正式に回答があった。

https://github.com/dotnet/docs.ja-jp/issues/118#issuecomment-407202477

こんにちは、@megascus

言語に関するフィードバックをお寄せいただきありがとうございました。

お寄せいただいたフィードバックの内容を Microsoft の言語チームで検証いたしましたところ、残念ながら、マイクロソフトのスタイルガイドラインに従わない という理由で、承認基準に完全には適合していないという結果になりました。

記事の品質向上にご協力いただき誠にありがとうございました。引き続きお客様からの貴重なフィードバックをお待ちしています。

敬具

Microsoft DOCS International Team

そしてissueはclosedされた。

ん? である。問題は日本語の翻訳にあるのであってソースコードのスタイルガイドラインとは何の関係もない。上記の日本語を読解できるだけの日本語能力があるならば容易に気がつくはずで、まるでBOTによってなされたような回答だ。

その結果、マイクロソフト用語では"DO"は「しないで」を意味するのだとか、マイクロソフト社内では"DO"と"DO NOT"は同じ意味を持つのだとか、Google翻訳のほうがよっぽどマシな翻訳をしてくれるとか、ユーモラスなコメントが並ぶことになった。

マイクロソフト用語を使うと以下のようになる。

DO fix the document which has a translation error.

しないで誤訳を含むドキュメントの修正

DO translate with MS style guideline conformance.

しないでMSスタイルガイドライン準拠の翻訳

押すなよ、絶対押すなよ(押せ)、というダチョウ倶楽部メソッドを久しぶりに思い出してしまった。

2018-07-13

NPMのESLintのパッケージにマルウェアが混入された問題

Postmortem for Malicious Packages Published on July 12th, 2018 - ESLint - Pluggable JavaScript linter

https://github.com/eslint/eslint-scope/issues/39

要約

2018年7月12日に、攻撃者がESLintメンテナーのnpmアカウントを不正利用し、悪意あるコードが混入したeslint-scopeとeslint-config-eslintパッケージをnpmレジストリに公開した。インストール時に、悪意あるパッケージがダウンロードされ、pastebin.comからコードを実行し、このコードはユーザーの.npmrcファイルの中身を攻撃者に送信する。通常.npmrcファイルにはnpmでパッケージを公開する際のアクセストークンが含まれる。

悪意あるパッケージのバージョンはeslint-scope@3.7.2 並びに eslint-config-eslint@5.0.2であり、すでに両方共npmから非公開になっている。このパッケージが使っているpastebin.comのリンクもすでに取り下げられた。

npmは2018-07-12 12:30 UTC以前に発行されたすべてのアクセストークンをrevokeした。この結果、この攻撃により不正に取得されたすべてのアクセストークンは利用不可能になっているはずだ。

アカウントを不正利用されたメンテナーはnpmパスワードを複数の他のサイトに使いまわしており、かつnpmアカウントに2段階認証を有効にしていなかった。

我々、ESLintチームは今回の出来事について謝罪いたします。この失敗を他のメンテナーは他山の石としてnpm全体のセキュリティを高めることを願っています。

影響を受けたパッケージ

  • eslint-scope@3.7、このスコープ解析ライブラリは他の有名な複数のパッケージから依存されている。これには古いeslintと最新のbabel-eslintとwebpackが含まれる。
  • eslint-config-eslint@5.0、これはESLintチームによって内部的に使われている設定用のパッケージであって、よそではほとんど使われていない。

独自のnpmレジストリを運営している場合、これらのパッケージから悪意あるバージョンを非公開にすべきである。npmjs.comレジストリはすでに非公開にした。

攻撃手法

攻撃手法の詳細についてはhttps://gist.github.com/hzoo/51cb84afdc50b14bffa6c6dc49826b3eを参照。

推奨

今回の事例から、我々はnpmパッケージメンテナーとユーザーが今後取るべき推奨事項をいくつか提案する。

  • パッケージメンテナーとユーザーは同じパスワードを複数の違うサイトに使いまわすことをやめるべきである。1PasswordやLastPassのようなパスワードマネージャーは使いまわさなくても済むような利便性を提供してくれる
  • パッケージメンテナーは2段階認証を有効にすべきである使い方のドキュメント。Lernaを使っているのであれば、ここも参照
  • パッケージメンテナーはnpmの公開権限を持つ人間を精査、制限すべきである。
  • パッケージメンテナーはauto-merge dependency upgradesを提供するサービスの使用に慎重を期すべきである。
  • アプリケーション開発社はlockfile(package-lock.json、もしくはyarn.lock)を使い、新しいパッケージの自動インストールを差し止めるべきである。

時系列

  • 問題発生前:攻撃者はおそらくメンテナーがよそで使いまわしたメールとパスワードが流出しているのを発見し、これを使いメンテナーのnpmアカウントにログインした。
  • 2018年7月12日早朝:攻撃者はメンテナーのnpmアカウントで認証トークンを生成した。
  • 2018-07012 09:49 UTC: 攻撃者は生成された認証トークンを使い、eslint-config-eslint@5.0.2を公開した、これには悪意あるpostinstallスクリプトが含まれ、このスクリプトはローカルマシンの.npmrcの認証トークンの取得を試みる。
  • 2018-07-12 10:25 UTC: 攻撃者はeslint-config-eslint@5.0.2を非公開にした。
  • 2018-07-12 10:40 UTC: 攻撃者はeslint-scope@3.7.2を公開した。これには悪意あるpostinstallスクリプトが含まれる。
  • 2018-07-12 11:17 UTC: ユーザーがeslint/eslint-scope#39"を投稿、ESLintチームに問題を通知。
  • 2018-07-12 12:27 UTC: pastebin.comにある悪意あるコードが貼り付けられたリンクが取り下げられた。
  • 2018-07-12 12:37 UTC: ESLintメンテナーから連絡を受けたnpmチームはeslint-scope@3.7.2を非公開にした。
  • 2018-07-12 17:41 UTC: ESLintチームはeslint-scope@3.7.1のコードをeslint-scope@3.7.3として公開した。これによりキャッシュは新しいバージョンを使えるようになる。
  • 2018-07-12 18:42 UTC: npmは2018-07-12 12:30 UTC以前に生成されたすべてのアクセストークンをrevokeした。

リンク

2018-07-11

C++20の汎用エイリアス宣言の提案

P0945R0: p0945r0: Generalizing alias declarations

提案に誤りが有りすぎる。

C++のドラフトに入る見込みが高そうな提案に、汎用エイリアス宣言がある。

C++では、名前に別名をつけることがよく行われている。

型はtypedef指定子やエイリアス宣言によって別名を付けられる。

typedef int type ;
using type = int ;

関数は転送関数を書くことにより、実質別名を付けられる。

int f( int x ) ;

int g( int x )
{
    return f(x) ;
}

ただし、値は完璧に転送できないし、関数のアドレスも異なるものになってしまう。

変数はリファレンスで別名を付けられる。

int x = 0 ;
int & y = x ;

非staticデータメンバーはストレージを消費せずに別名をつけることができない

enumeratorはconstexpr inline変数によって別名を付けられる。

enum { value } ;

constexpr inline auto flag = value ;

ただしinline変数は名前空間スコープでしか使えない。

名前空間は名前空間エイリアスにより別名を付けられる。

namespace a { }

namespace b = a ;

型テンプレートはエイリアステンプレートで別名を定義できるが、デフォルトテンプレートパラメーターまで再現しなければならない。

template < typename T, typename Allocator = std::allocator<T> >
using vec = std::vector<T, Allocator> ;

ただし、この別名は別のテンプレートとして解釈されてしまう。

コンセプトは別のコンセプトを定義すれば別名を付けられる。

template < typename T >
concept newConcept = oldConcept<T> ;

名前の種類によって別名を宣言する文法が異なるし、単なる別名以上の意味を持つものもある。

この提案では、別名の宣言をエイリアス宣言に集約する。


using alias_name = name ;

型は今までどおりだが、その他

 型、今までどおり
using type = int ;

// 関数
int f(int) ;
using g = f ;

// 変数
int x = 0 ;
using y = x ;

// 非staticデータメンバー
template < typename Type, typename Value >
struct map_node : std::pair<Type, Value>
{
    using std::pair<Type, Value>::pair ;

    using key = first ;
    using value = second ;
} ;

[]{
    map_node< int, std::string> n( 123, "123") ;
    n.key ;
    n.value ;
} ;

// enum

enum { value } ;

using flag = value ;

// 名前空間

namespace a ;
using b = a ;


// 型テンプレート

using vec = std::vector ;

vec<int> v ;

// コンセプト

using newConcept = oldConcept ;

だいぶすっきりする。とくに非staticデータメンバーがよい。

2018-07-10

C++に提案されている静的例外

C++に静的例外が提案されている。

[PDF] P0709R1: Zero-overhead deterministic exceptions: Throwing values

例外はそのパフォーマンスへの影響が懸念され、一部のC++プロジェクトではコンパイラーオプションによって例外自体が無効化されていた。

これは由々しき事態だ。というのも、例外は標準C++の機能の一部であり、標準ライブラリは例外の存在を前提にして設計されている。例外が無効化されているということは、それはもはやC++ではない。C++風の別言語を使っていることになる。

なぜ例外は忌避されるのか。例外のパフォーマンスが非決定的だからだ。例外の実装はスタックからの確保ではなくヒープからの動的なメモリ確保が必要で、例外のキャッチにはRTTIによる型情報の比較が必要だ。

ifとgotoによるエラー処理のパフォーマンス特性は決定的に見積もることができるが、動的メモリ確保のパフォーマンス特性は決定的に見積もることができない。非決定的なパフォーマンス特性を持つ処理は、例えば数ミリ秒以内に必ず処理を終えなければならないような状況で使うことはできない。

この提案では、従来の例外を動的例外とし、新たに静的例外を追加して、例外のパフォーマンスを決定的にする。

まず、静的例外では例外としてthrowできる型が制約を受ける。特別に用意した何らかのstd::error型を投げる。このerror型は内部的には整数型で、デストラクターを実行する必要がなく、サイズは最大でもポインター2つ程度を想定している。標準はこのような型をrelocatableな型として規定する。

この標準のerror型はstd::error_codeを拡張したようなクラスで、様々な一般的にエラーに用いられるカテゴリーわけされた整数を返すことができる。このerror型はC++の標準の例外型は数値で表現できるようになっているので、静的例外と動的例外は標準の範囲であれば相互に変換可能になっている。

静的例外を扱う関数、静的例外関数を追加する。静的例外関数は静的例外指定によって明示的に指定する必要がある。提案では仮に、thorwsキーワードを用いる文法を提案している。


string f() throws
{
    if ( is_error() )
        throw error::something ;
    else
        return "hoge"s ;
}

静的例外関数はあたかもnoexcept(fase)が指定されたかのように振る舞う。したがってnothrow系のtraitsもそのように振る舞う。

静的例外関数が例外を外に投げる場合、例外を従来のスタックアンワインディングを伴う例外の仕組みを使わず、戻り値で返す。つまり静的例外関数はunion { R ; E ; } + boolのような型を内部的に戻り値として返す。ようするにexpected<T,E>のような型と同等の機能を提供する型を返す。

静的例外というのはerror型の値に変換できる値を投げるthrow式のことだ。それ以外のthrow式は動的例外となる。

// 静的例外
throw error::foobar ;
// 動的例外
throw "error"s ;

静的例外関数のなかで静的例外がthrowされ、その関数のローカルに対応する例外ハンドラーがある場合、該当する例外ハンドラーにgotoでとんだものと同じ挙動をする。

 string f() throws
{
    try {
        // ローカルのcatchにgotoで飛ぶのと同じ
        throw error::something ;
    } catch ( error e )
    {
        // ここにgotoで飛ぶのと同じ
    }
}

静的例外関数のローカルに該当する例外ハンドラーがない場合、errorは戻り値として返される。そのため、上の関数は実際には、union { string ; error ; }という型とどちらのunionメンバーが有効かを示すbool値を返したものとみなされる。これは従来のreturnと同じ仕組みで実装できるので、パフォーマンス特性も決定的になる。

静的例外関数が別の静的例外関数を呼び出し、静的例外によるerror型が返った場合は、その場で静的例外がthrowされたものとみなして処理する。

string f() throws 
{
    // 内部的にはerrorがreturnされる
    throw error::something ;
}

string g() throws
{
    try { return f() ; }
    catch( error e )
    {
        // ここにgotoで飛ぶ
    }
}

静的例外関数の中で従来の動的例外が投げられた場合、それが直接throw式で投げられたにせよ、呼び出した関数を通じて間接的に投げられたにせよ、直ちにその場でキャッチされ、適切な例外ハンドラーが選ばれる。

string f() ; // 非静的例外関数
string g() throws ; // 静的例外関数

string h() throw
{
    try {
        auto a = f() ;
        auto b = g() ;
        return a + b ;
    }
    // 静的例外
    catch( error e )
    {
    }
    // 動的例外
    // 従来の非決定的なパフォーマンス特性を持つ
    catch( std::bad_alloc e )
    {
    }
}

もし、静的例外関数から従来の動的例外が投げられ、関数の中に該当する例外ハンドラーがない場合、例外の型がerrorであれば静的例外としてreturnされ、それ以外であればstd::exception_ptrで束縛されてreturnされる。

string fail()
{
    throw "always error"s ;
}

string f() throws
{
    return fail() ;
}

この関数fは、string型をstd::exception_ptrで束縛してreturnする。

std::exception_ptrはC++11から追加された例外のオブジェクトを束縛できる機能だ。もう7年前の大昔に追加された機能なので読者は当然知っているはずだ。

呼び出した静的例外関数がstd::exception_ptrをreturnした場合、その場でただちに例外オブジェクトが取り出され、例外処理が行われる。もし例外オブジェクトがerror型の場合は静的例外が、そうでない場合は動的例外として処理される。

一部のC++の標準例外は、error型に変換される。例えばstd::bad_allocはerror型である(名前は仮のものだが)std::errc::ENOMEMに変換される。

非静的例外関数が静的例外関数を呼び出して例外を受け取った場合、もしerrorに対応するstd::exception型(たとえばerrc::ENOMEMからstd::bad_alloc)があるならば型を変換して動的例外がthrowされる。std::exception_ptrの中身がerror型の場合は取り出してerror型がthrowされたものとして処理される。それ以外の例外は動的例外がthrowされる。

string f() throws
{
    // 動的メモリ確保に失敗するコード
    // return std::errc::ENOMEM ; と同じ
    string s( std::numeric_limits<std::size_t>::max(), 'x') ; 
    return s ;
}

string g()
{
    // throw std::bad_alloc; と同じ
    return f() ;
}

この提案は従来の動的例外と組み合わせて使えるパフォーマンス特性が決定的な、つまりifとgotoを使うのと全く変わらないエラー処理を、例外の文法で実現する、静的例外を提案するものだ。これによりゼロオーバーヘッドの原則を満たした例外が扱えるようになる。

興味深いので入ってほしい。例外はすべてのC++で有効化されるべきだ。例外の使えないC++はC++風の別言語なので、利用者が分断されてしまう。 

2018-07-06

江添ボドゲ会@7月15日

以下の要領で7月15日に自宅でボドゲ会を開催します。

江添ボドゲ会@7月15日 - connpass

2018-07-05

プロフェッショナルIPv6の執筆経緯が興味深い

「プロフェッショナルIPv6」が出版されるそうだ。

すごいIPv6本を無料配布!:Geekなぺーじ

この本の執筆経緯が面白い。クラウドファンディングで金を集めている。

すごい技術書を一緒に作ろう。あきみち+ラムダノート『プロフェッショナルIPv6』 | クラウドファンディング - Makuake(マクアケ)

クラウドファンディングでは結果的に400万円ほど集まったそうだ。これはラムダノートと著者の連名のクラウドファンディングなので、著者の総取りというわけでもないだろうが、それにしても400万円は現代の技術書としては異例だ。

技術書とカネの話をしようと思う。私自身、技術書を出版してカネを得た経験がある。

技術書一冊の相場は数千円だ。売上一冊あたりの著者の収入は数百円だ。では著者が数百万円を稼ぐためには何冊売ればいいのだろうか。1万冊だ。問題は技術書で1万冊も売れる本は稀だということだ。1万冊売れる本というのは、技術書と言うよりはド素人に技術の仕組みをやんわりと教える本だ。詳細な解説をすればするほど、技術書は売れなくなっていく。千冊も売れればいいほうだろう。結果として、参考書を執筆して著者が得られるカネというのは数十万円だ。これでは経費を差し引くと給与所得者が確定申告に必要な雑所得の20万円すら下回る程度の利益しか得られない。そもそも技術書を執筆するためのまともなPCは数十万円するので、数年に渡って分割して経費にしなければならず、一台PCを買うだけで毎年本を出版しても数年は雑所得が確定申告が必要なレベルに達しない。

詳細な技術書を書くためには数年の時間がかかる。百万円台の収入では割に合わない。数年の執筆期間を維持するためには一千万円台の収入が必要だが、それには10万冊規模の売上が必要になる。日本で10万冊売れた技術書というのは、プログラマーたるもの読んだことがなければモグリのそしりを免れないような伝説的な本になるだろう。

ちなみに、100万冊売れた技術書は日本の全プログラマーが必携必読の書であり、このブログを読む読者は全員、手の届く範囲にその本を置いているような本になるはずだ。

さらに桁を上げるとどうなるのか。ありえないことだ。1000万冊売れる技術書などというものは存在するはずがない。それでもあえてそのような状況を発生させる条件を考えるとするならば、1000万冊売れた技術書の著者は新興宗教の開祖であり国内に何百万人もの信者を抱え、サイバークライムを救済されシリコンヘブンに行くためには免罪符として自著を購入しなければならない教義を説いているはずだ。

それにしても考えてみれば規模が小さい。現代の商業的な一般の書籍の流通に乗り、一般的な書店に並ぶ技術書の大半は千冊売れる程度なのだ。もはやコミケ以下だ。これでは技術書の執筆者は技術書を執筆するだけでは食べていけない。その結果、いま技術書を書いて生計を立てているような執筆者はいない。かの結城浩ですら、今は何をやっているかというと数学ラノベを書いている。

昔はこうではなかった。現代の感覚ではにわかに信じられないことであるが、昔は技術書を執筆するだけで生計を立てているプロの執筆者がいたと聞いている。一体どうしたらそんなことが可能になるのか。本の値段は何十年も変わっていない。むしろ最近のほうが安くなっている。一冊あたりの著者の印税も最近は安くなっているが、桁違いというほどではない。つまり昔は大抵の技術書が1万冊単位で売れていたということだ。事実、そうであったらしい。

昔は技術書が多く売れていた理由は、技術書が相対的に安かったからだ。今はインターネットの通信費用が限りないほど安価になっている。もはや日本では水と電気とインターネットは無料だと言ってもいい。紙の書籍は相対的に高い。しかし、昔は違った。通信費用は青天井に高かった。インターネットに接続するというのは、ISPの提供する基地局にモデムを介して電話をかけるということだった。そしてISPの基地局は都合よく同一市内の20km以内の場所に存在してくれたりはしない。帯域は本当に狭かった。当時の最後の時代の最高のモデムが56Kbpsだ。そもそも56Kbpsのカタログスペックがフルに出たりなどしない。たったの1MBをダウンロードするために何分もかかる、電話代は数百円かかるだろう。それを考えると、数千円で買える技術書が相対的に安くて売れるのは当然だ。

通信費が高いために、インターネット上にはそれほど情報がなかった事情もある。

現代ではインターネット上に情報が豊富にある上、最新の情報はインターネット上にしかない。本の執筆には時間がかかり、物理的に印刷して書店に並ぶには更に時間がかかる。しかも、今の技術の一次情報はすべて英語だ。すると、著者が英語を読んだ上で日本語で書くというオーバーヘッドもある。紙の本は出版された時点ですでに時代遅れなのだ。

さて、表題の本に戻ろう。今回クラウドファンディングで400万円を集めているわけだが、これはまだ低い。もう一つ桁が上がらなければ執筆に数年かかるような技術書は出せない。ただ、今回クラウドファンディングをしたことで圧倒的な宣伝効果を得たはずで、金銭以外の利益はあったはずだ。

不思議な時代だ。カネを払って宣伝をするのではなく、カネをもらって宣伝をするとは。結局、市場が小さすぎるのが悪い。

技術書の未来はどうなるのだろうか。私は今の傾向が続けば、もはや技術書などというものは滅びると思っている。そうなればプログラマーは皆日本語を捨てて余計なオーバーヘッドが排除されるので、長期的にはいいはずなのだが。

2018-07-04

C++17をすでに現場で使っているというキャディ株式会社に話を聞いてきた

CTOが「日本のC++のトップ人材の過半数が所属するイカれた会社にする」という宣言をした会社がある。なんとも壮大な話だ。C++プログラマーの業種は多岐にわたっているので、文字通りに考えると、そのような会社は自動車や旅客機の製造業であり、防衛庁の入札に参加する受注業者であり、OSや独自のプロセッサーを開発するためC++コンパイラー開発者も雇い、さらにはゲームもブラウザーも検索エンジンもクラウドホスティングもと挙げ続ければきりがないほど多方面に展開する大企業である。おそらくすでに名の知れた有名なIT系の大企業をほとんど買収すればそのような状態にはなるのではないかと思うが、金がいくらあっても足りない。

それはともかく、すでに現場でC++17を使っているという。

C++17は2017年に出たばかりの規格で、まだGCCもClangもコア言語はともかくライブラリーまでは完全に実装し終えてない状況だ。そのような状況で今C++17を使えるということは、最新の安定版のGCCやClangを本番環境で使える会社ということだ。果たして何をしているのか。

というわけで、その会社、「キャディ株式会社」に話を聞きに行った。

https://caddi.jp/: 板金加工なら【キャディ株式会社】―即日見積、5日納品、全国配送

Webサイトを見ると、板金加工をする会社だという。これだけではまだC++を使う理由がわからない。

話を聞いてみるとこうだ。

小規模な板金加工の受注生産というのは、小規模ないわゆる町工場が行っている。これまで板金加工をするには、町工場と直接交渉する必要があった。この顧客と町工場の間の交渉には、これまでほとんど技術革新がなかった。キャディはこの顧客と町工場の間に交渉に技術革新をもたらす、いわば仲介業か一次請けのような役割を果たす。

顧客は加工したいモデルデータをキャディのWebサイトからアップロードする。キャディはモデルデータを処理し、加工に必要な費用を見積もって表示する。この見積もりは一瞬で行われる。顧客が発注するとキャディは提携先の町工場に加工を依頼し、完成品を顧客に引き渡す。

顧客の送信したモデルデータから加工費用を一瞬で見積もるために、モデルデータの処理が必要だ。この処理にC++を使っている。

なるほど、C++を使う理由はわかった。ではどうやってこの比較的早い段階にC++17を使うことができるのか。その理由は簡単だった。規模の小さい新興企業だからだ。

現時点で従業員10人超、プログラマーが5人。そのような小規模な開発だからこそ可能になるのだろう。

大企業であればプログラマーとは別に専門のインフラ部署があり、インフラ屋はプログラマーとは少し違う目標を持っている。システムの安定性だ。新しすぎるソフトウェアは問題を引き起こす可能性がある。既存のソフトウェアに問題があるとしても、既知のものであり十分に情報があるので対処可能であるが、新しいソフトウェアの新しい問題は情報も少なく対処も難しい。この結果、インフラ屋はソフトウェアのアップデートに対して保守的になる。特にGNU/Linuxであればとても重要なC++コンパイラーであるGCCにはとても慎重になる。なぜならばGCCは他のほとんどのソフトウェアをコンパイルする重要なソフトウェアなのだから、GCCに問題があればシステムの全てに問題があることになる。

その結果、RHELのようなC++コンパイラーのアップデートが信じられないほどに保守的で時代遅れのディストロが使われる。

プログラマーが数人ですべてをやるような場合、この問題はない。

また、既存のコードが存在しないのも大きいのだろう。既存のコードが存在する場合、新しいコンパイラーによって不具合が修正され、その不具合に依存していたコードが壊れることがあるので、なかなかコンパイラーのバージョンを上げられない問題がある。

C++17をすでに現場で使っている話を聞くと、なんと私が過去に最新のClangを使っていて遭遇した問題に、同じく遭遇していた。

Clangは一時期、glibcのxlocale.hに依存していたことがある。これは非標準のglibcの独自ヘッダーでかなり昔からdeprecated扱いであり、最近削除された。

ディストロのパッケージにある安定版のClangを使いたい場合、私は空のxlocale.hを用意していた。パッケージ管理されたClangのヘッダーファイルを手動で書き換えるよりマシだ。

最新のClangでは修正されている。

Clangはvirtualデストラクターのある基本クラスをvirtual private派生で間接的に持っていた場合、デストラクターのアクセス指定を正しく判断できないregressionがある。Clang 3.3までは正しい挙動だったのだが、3.4から壊れてしまった。

30916 – If a class has indirect private virtual base with non-trivial public destructor, a class cannot access virtual base's destructor.

もう一年以上前にバグは報告してみたが、まだ修正されていないどころか何の反応もない。

こうして考えてみると、最新のC++コンパイラーには不具合も多い。既存の膨大なコードを修正するコストはかなり高い。常に最新のC++コンパイラーを使うのも茨の道だ。しかし、古いコンパイラーを使うということはこれ以上に莫大な既知の規格違反の不具合に対処する不思議なコードを書かなければならなくなるわけで茨の道であることに変わりはない。

ところで、このキャディ株式会社であるが、C++のプログラマーを随時募集しているらしい。応募方法はウェブサイトに記載されているメールアドレスに連絡してほしいとのことだ。

https://caddi.jp/: 板金加工なら【キャディ株式会社】―即日見積、5日納品、全国配送

2018-06-27

プログラミング入門書の執筆という手探りの活動

ここ最近、まともにブログを書けていない。最新のC++の提案も追えていない。それもこれも、C++によるプログラミングの入門書を書いているためだ。

およそプログラミングが個人でもできるようになって何十年もたとうとしているのだから、いい加減にプログラミングの入門書を書くお作法が成立しても良さそうなものだが、そういった定石は一向に確立されていない。名著と呼ばれる入門書は何冊もあるが、どれもその時代に特化した記述をしていて、その構成を模倣しても現代の入門書としては不適切だ。

結果として、入門書の執筆は自分の感性を信じつつ手探りで書き進めることになる。

よくC++の教育において批判されるのは、ポインターや配列といった低級な要素を最初に教える時代錯誤な点だ。たしかに、現代のC++はポインターや配列を使わなくても書ける。しかし、アドレスやメモリ上の連続したオブジェクトといった概念を理解しないまま優秀なコードが書けるだろうか。ポインターはアドレスを扱うには文法上の罠が多く、配列もメモリ上の連続したオブジェクトを扱うには文法上の罠が多い。

今書いているC++の入門書では、ポインターも配列も教えずに、vectorとイテレーターを教えている。しかし、コンテナーのカテゴリーやイテレーターのカテゴリーについては教えていないので、vectorとランダムアクセスイテレーターを前提にした記述になってしまう。

本当はコンテナーのカテゴリーやイテレーターのカテゴリーについて網羅的に教えたいのだが、そうすると具体的なコードがなく抽象的な分類とサポートされる操作といった文章が延々と続くことになってしまう。入門書では直接的なコードがすぐに書けるほうがよいと判断したのでvectorと実質ランダムアクセスイテレーターだけを教えているが、どうにも釈然としない思いがつのる。

プログラミングの入門書の冒頭では、どのようにしてコードを実行するかについて説明するものだ。既存の毎年改訂版が出るような使い捨ての入門書では、この説明のために、例えばVisual Studioのインストール方法の解説からはじめる。しかもご丁寧にいちいちスクリーンショットを載せ、ここのボタンをクリックしてなどといった本当に何のためにあるのかわからない解説が続く。

私が書いている入門書では、そのようなスクリーンショットは一切載せない方針にした。さらに、今年出たばかりの新しいツールに依存してしまうと、数年後に時代遅れになって使えなくなってしまう可能性が高いので、20年前に持っていっても使えるような安定したツールだけを使うことにした。その結果、使うツールはbashとGCCとGNU Makeになった。20年前から変わらないビルドシステムは、おそらく20年後もこのまま使えるはずだが、印刷される書物としてタブ文字と空白文字を区別するように説明するのはつらい。

今書いている入門書はあらゆることが手探りで進められている。例えば変数の宣言方法は以下のとおりだ。

// 整数
auto x = 0 ;
// 浮動小数点数
auto y = 0.0 ;
// 文字列
auto z = "hello"s ;

変数をいきなりこのような方法で教えるC++の入門書は今まで読んだことがないが、思うに最近の言語は強い静的型付けがないか、強い静的な型推論がある言語ばかりで、このような変数の書き方が自然になってきているので、これでよいだろう。

この調子で、最初に教える関数も以下のようになった。


auto plus = []( auto x, auto y ) { return x + y ; } ;

C++では、厳密にはこれは関数ではなくてラムダ式なのだが、こう書くことによって型を意識しないですむ。

ラムダ式を最初に教えることで、関数を渡す関数も自然に教えられるようになった。


int main()
{
    auto for_each = []( auto first, auto last, auto f )
    {
        for ( auto iter = first ; iter != last ; ++iter )
        {
            f( *iter ) ;
        }
    } ;

    std::vector<int> v = {1,2,3,4,5} ;

    for_each( std::begin(v), std::end(v),
        []( auto value ) { std::cout << value ; } ) ;
}

実際、std::for_eachは概ねこのような実装になっているのだと教えている。もちろん、これは本当のstd::for_eachの実装ではないし関数でもないので、厳密には違うが、初心者ならばこの説明でいいだろうと妥協している。

さらに一歩を踏み込んで、vectorの初期化を以下のようにできるのだが、おそらく混乱するだろうからまだやめている。これはC++17で採用されたdeduction guideによるものだ。


// std::vector<int>と同じ
std::vector v = {1,2,3,4,5} ;

今、ようやくアルゴリズムまで進んだのだが、今までに教えたことしか使っていない結果、関数はラムダ式で、コンテナーはvectorしか教えておらず、イテレーターはランダムアクセスイテレーターで、クラスはまだ教えておらず、テンプレートも当然教えていない。lvalueリファレンスだけは無理やり教えたがCV qualifiersは教えていない。

この状態で一体どこまで教えればいいのだろうか。C++を本格的に使うには、当然既存のC++のコードも読む必要があるだろうから、ポインターや配列を理解しなければならず、クラスやテンプレートも学ぶ必要がある。動的メモリ確保も必要だ。しかしこれらの概念を網羅的に解説するのはあまりにも抽象的すぎて、今想定している入門書では難しい。

今書いている入門書は本当に読者に想定していることが少ないので、C++のビルド方法からはじめ、エラーメッセージの読み方も解説したし、gdbの簡単な使い方も解説したい。

それにしても、今はC++を学ぶ対象読者の想定が難しい。一昔前ならばC言語をすでに学び終えた人間を想定すればよかったのだが、今はJavaScriptとかPythonかRubyぐらいしか触ったことのないプログラマーが増えている。彼らはコンパイルしてリンクして実行という仕組みに触れたことがない。

さらに、一昔前ならば想定することができなかった競技プログラマーという人種がいる。彼らは数学力は凄まじいがプログラミング言語には大して執着がなく、必要な計算を最小限のコードで実現できればそれでいいというとても割り切った使い方をする。プログラミング言語の文法をほとんど理解していないのに問題を解くコードは書けるというよくわからない人種だ。

そして入門書は浅く簡略化した解説を続けながらアルゴリズムまで来た。

この後はgdbの使い方、クラス、テンプレート、ポインター、動的メモリ確保、派生クラスあたりの順番で書こうかと思っている。C++の機能の依存関係の解決が辛い。すでに教えている機能だけを使う縛りを入れているので、早く機能を教えないといつまでも簡略化した説明を続けるハメになるが、いきなりポインターを教えても実感が沸かないだろうから、ポインターは相当後になる。

2018-06-14

xkcd: お客様特典

xkcd: Customer Rewards

23ドル3セントになります。

ところで、あなたの本名を教えていただけるのならば24セントお支払いたします。家族構成を教えていただけるのであれば35セント、電話番号に79セント、あなたのスマフォをこの場で貸していただいてあなたのFacebookの投稿一覧を確認させてもらえるのであれば1ドル20セントお支払します。

ポイントカードと特典は、独立した取引として考えた場合、とても奇妙なものになる。

title="うちの製品をSNSに投稿していただけるのであれば1ドル47セント、グループチャットで毎回話題に持ち出すのであれば2ドル5セント、運転中にうちの広告を通過した場合乗員一人に付き11セントお支払します。"

そういえばレシートを1枚10円で買い取るサービスが流行っているようだ。

2018-06-12

coinhiveが不正であるというナンセンスについて

coinhiveの設置者が不正指令電磁的記録取得・保管罪で略式起訴を受けたので正式に裁判して争う発表をした。

仮想通貨マイニング(Coinhive)で家宅捜索を受けた話 - Webを楽しもう「ドークツ」

高木浩光@自宅の日記 - 懸念されていた濫用がついに始まった刑法19章の2「不正指令電磁的記録に関する罪」

6月10日の高木宏光の記事では具体性がなかったのでよくわからなかったのだが、こうして具体例を目にしてみるとこの件がとてもひどいことがわかる。

裁判は多少のカネと時間がかかるがそれほど労力はかからない。数カ月に一度、提出した書類道理の陳述するという儀式をするだけのものだ。みんなもっと積極的に裁判をすべきだ。

法律の解釈は裁判をして判例を作ることで成り立っているので、おかしいと思った法律解釈には積極的に裁判をしないとどんどん悪い判例が積もっていく。

それはそれとしてcoinhiveは嫌いなので広告と同じくブラウザー拡張でブロックするべきだ。

2018-05-31

江添ボドゲ会@6月10日

下記のごとく毎月定例の江添ボドゲ会を開催します。

江添ボドゲ会@6月10日 - connpass

2018-05-29

世の中にはプログラミングを理解できない人間が存在する

現在、C++によるプログラミングの入門書を書いているので、初心者のプログラミングの学習過程にとても興味がある。私自身も初心者の気持ちを取り戻すためにHaskellを学んでみた。最初の数日は頭が痛くなるほど難しかったが、そこを過ぎてみれば後は楽になってしまった。結局、初心者の気持ちはあまりわからなかった。結局、プログラミングの基礎はすでに学んでしまっているので、

先日、FizzBuzzがわからないから教えてくれという知人がいたので、これは初心者の気持ちを知るいい機会と話を聞いてみたところ、想像を絶する世界が見えてきた。

まずこれが動かないと悩んでいたコードだ。


for ( int i = 0 ; i <= 100 ; i++ )
{
}
else if ( i % 15 == 0 )
{
    Debug.log("FizzBuzz") ;
}
else if ( i % 3 == 0 )
{
    Debug.log("Fizz") ;
}
else if ( i % 5 == 0 )
{
    Debug.log("Buzz") ;
}
else
{
    Debug.log(i) ;
}

一見するとそれらしいソースコードのようにみえるが、そもそも文法が間違っている。文法が間違っている箇所を指差しても納得しない。for文の文法を説明しようとするが聞く耳を持たない。「これが間違っているなら参考にしている教科書も間違っている」との一点張りで誤りが存在していることを頑なに認めない。参考にしているらしいスライド資料にのっているコード例と比較させても間違いの箇所を判断できない。for文の文法の説明をもう一度試みるがやはり聞く耳を持たない。

そしてソースコードの見た目を適当に書き換えてなんとか問題を「修正」しようと試みる。私はいつシェイクスピアの名作が出来上がるだろうかと考えながらその様子を見守っていた。

ややあって、奇跡的にソースコードが適切な形に「修正」された。しかし出力は期待通りにならない。当然だ。なぜならこれはUnityで、使っているのはデバッグログ用の機能であって、重複は省かれるからだ。出力は、1, 2, "Fizz"というメッセージが何件, 4, "Buzz"というメッセージが何件, 7, 8...と続く

そもそも基礎的なプログラミングの知識が十分ではないのだから、Unityはやめてもっと罠の少ないCLI環境でプログラミングの基礎を学ぶべきだと諭しても、「Unityは私がやりたいことを実現できる環境であり私のモチベ維持のために重要であるからUnityでやる」といって改めようとしない。

これは一体どうすればいいのだろう。こういう人間は教育不可能だ。この人物の経歴を見るに、どうもそれらしく見えるモックアップをでっち上げてきたアート系の人間のようだ。本人は今の時代は科学とアートは同じものでありアートを融合することでユーザービリティを考慮したUIが云々などと、まるでピタゴラス派のようなことを言う。世界は人間にとって美しい数字とか法則で定義されるべきであり、定義が観測結果に従わないとしても定義は正しいと主張したのがピタゴラス派だ。アートに引きこもっているならそれでいいのだが、それは科学ではない。コンパイラーのソースコードの解釈はこの自然界には珍しいことに冪等性を持っているのだから、見た目をでっち上げるのではなくて本質を理解すべきなのだ。たとえその本質が自分の美学に合わなかったとしてもだ。私は本棚にあったアラン・ソーカルの著書、知の欺瞞を手に取らせてみたが、あまり興味は示さなかったようだ。

こういう人間によって書かれたソースコードは一見もっともらしく見えるが、文法違反の間違ったコードとなる。どこかからか発見してきたコードをコピペしてツギハギしてそれらしい見た目のソースコードをでっち上げる。人間相手であれば、いかにも主題について理解したかのようにもっともらしくでっち上げた小論文を書いて読ませれば筆者は主題を理解していると読者を騙すことは可能だが、ことコンパイラーが相手では文法違反のソースコードを騙すことなどできない。

思うに、先天的に、あるいは幼少期の教育の結果、プログラミングに向かない学習方法に最適化されてしまった人間がいるのではないだろうか。物事の本質を完全に理解するにはコストがかかる。しかし、不完全な理解だがそれらしいものをでっち上げるにはコストがかからない。そして、人間には、それらしくでっち上げられた偽物と、本質を理解した上で作られた本物を判別するのが難しい。一方コンピューターは違う。コンパイラーはソースコードがいかに本物のソースコードらしい見た目をしていようとも、文法違反のソースコードを判別できる。コストを書けずに結果を出すためにそれらしくでっち上げる学習方法に最適化されてしまった人間は、コンパイラーに対して、それらしくでっち上げられたソースコードを食わせてコンパイラーが騙されてくれることを期待する。しかしコンピューターは騙されない。そもそも騙しようがない。コンパイラーは定義済みの規則に則って判断するだけで騙すという概念すらないのだから。

2018-05-17

ポルノ本意制の通貨が登場したことにより今後予想される問題について

ポルノ動画サイトの最大手であるポルノハブが仮想通貨Vergeによる支払いを受け付けているそうだ。

世界最大のポルノサイトが仮想通貨「verge」に対応、アクセスしてみるとびっくり! ポルノ業界が急激に進化中!

これはとても面白い事象である。というのも、この通貨はポルノと交換できることがポルノハブによって保証されているわけだ。すなわち、これは金本位制ならぬポルノ本位制である。しかもこの話は単なる空想に終わらない。ポルノハブは実際にこの通貨とポルノの交換を行っているわけで実態がある。ここにポルノ本位制の通貨が登場した。

ポルノ本位制の通貨が存在する社会はどのように変革していくのか、ポルノ本意制の通貨を使うときには何に気をつければよいのか。我々人類は通貨と経済学について長い歴史があるので、歴史から学ぶことで今後の動向は予測できる。本記事ではポルノ本位制の通貨がもたらすシュールな世界を紹介しよう。

ある通貨はポルノと交換できることが保証されているとして、一体どのようなポルノと交換できるのだろうか。ポルノはどのようなものであってもポルノであり、したがってポルノとしての価値を持つはずだ。質の高いポルノを生産するのにはコストがかかる。すると、世の中には質の悪い製造が容易なポルノが量産されるだろう。通貨と交換品の価値に差が生じた場合、人々は通貨と交換するポルノには質の悪いポルノを使い、質の良いポルノは貯蓄するようになる。これを「悪ポルノは良ポルノを駆逐する」といい、グレシャムの法則とも呼ばれている。

経済学的にポルノの価値を考えると興味深い事情がある。ポルノの価値はまだ誰も見たことのない市場に出回っていない新作ほど高い。みんな見たような市場に出回りすぎたポルノは価値が低い。これを考えると、ポルノは金のように価値が安定しておらず、消費財である。しかし金の生産量は簡単に増やせないが、ポルノの生産量は裸の人間とカメラさえあればいくらでも生産できる。しかも一人の人間に複数のカメラを使うことで並列生産も可能だ。中には車とドラゴンをポルノだとみなす人もいるが、ドラゴンの用意はやや難しい。最近は地図上にもドラゴンの住まう地と書かれる土地が少なくなったからだ。

ポルノ本意制の社会では、実経済に出回っている通貨がいつポルノとの交換を要求されるかわからない。そこで、銀行は十分な量の価値の高い未公開ポルノを戦略的に備蓄しておく。これを準備ポルノという。

なぜ実経済が存在するポルノより多い通貨を動かすようになるのだろうか。それは借金の存在のためだ。まだポルノを所有していない人間が、将来ポルノを所有する信用によって通貨を借りる。その通貨でポルノを生産し、借金を返す。このとき、生産したポルノによって借金以上の価値が生まれれば得をする。ところで、借金をしたときまだポルノは世の中に存在していなかったわけだ。しかし借金をしなければポルノは生産されなかった。したがって、実経済では常に準備ポルノ以上の通貨が動いているのだ。

現実には、市場に出回る通貨すべてを一斉に換ポルノしたときの需要を満たすほどの準備ポルノを用意することはできないだろう。皆が一斉に通貨とポルノ交換、すなわち換ポルノを要求したとき、取り付け騒ぎが起き市場が混乱する。このような取り付け騒ぎはめったに起こらないが、たまに些細な噂が拡大解釈されて発生することがある。例えば女子高生が何気なくつぶやいた、「最近ポルノハブ危ないんだって」という言葉からポルノの取り付け騒ぎが発生し、準備ポルノの少なかった弱小ポルノサイトが閉鎖に追い込まれることは十分にあるだろう。そのような自体に陥った場合、まず自殺したと噂される理事長自ら生存を主張し、巨大スクリーンでポルノを映すことにより準備ポルノは十分にあることをアピールすべきだ。

不況時には、ポルノが十分に国内に供給されない。このとき、国内にすらポルノ供給が足りていないのに海外にポルノを輸出するのはけしからんという極めて素朴で単純な考え方が国民に芽生え、そのような狭い思想の政治家が当選する。結果として、国家はお互いにポルノ輸出を禁ずるようになり、各国が経済的に鎖国し始める。

こうしたことから、ポルノ本意制はいずれ破綻し、廃止しなければならなくなるだろう。どうやって廃止するのかを歴史に学んで今から対策しておこう。国家は通貨とポルノの法定為替を一方的に定め、国民の所有するポルノ財産をすべて法定為替で強制的に買い上げるかもしれない。

そして、今と同じようにポルノと通貨は変動為替に移行し、取引所に直結したアルゴリズムトレード勢がマイクロ秒単位でポルノ価値を判断して先物取引をするようになるだろう。

他にも面白い思考実験として、フィクションの世界では水本位制がある。これはFalloutというゲームの世界の設定だ。全面核戦争の後に清潔な飲料水が貴重になり水が価値になった。しかし水を持ち運ぶのは手間なので、ある有力な水商人が水とボトルキャップを交換するようになった。なぜボトルキャップなのかと言うと、もはやボトルキャップを製造する技術や設備は存在しないからだ。つまり、ボトルキャップは偽造が実質不可能で、全面核戦争前に製造されたものしか残っていない。偽造が不可能であれば貨幣として使うには十分だ。

2018-05-14

OpenBSD、1985年に追加されたIntelの最新の誇大広告された機能を使わないことにより脆弱性を華麗に回避

“We didn't chase the fad of using every Intel CPU feature” | Hacker News

'Re: CVE-2018-8897' - MARC

前回の記事であるIntelの古いマニュアルを誤読したために生じた脆弱性では、IntelのCPUがスタック切り替えるためにss/spレジスターをアトミックに更新する汚いハックとして、ssレジスターが変更された直後の1命令は割り込みが遅延される古い仕様があるが、多くのOSはこの古い仕様を把握していなかったため、ssレジスターを変更した直後の1命令でカーネルモードに入り、かつハードウェアブレイクポイントが設定されたことにより割り込みを起こせば、カーネルモードに入った直後にカーネルのコードを1命令たりとも実行していない状況でカーネルモードとしてユーザーの割り込みが実行される脆弱性を引き起こしていた。

さて、各OSが対応に追われるなか、セキュリティに万全の体制を取ることで定評のあるOpenBSDでは特に何事もなくのほほんとしているので、MLにこのことについて質問をするものがいた。

OpenBSDが影響を受けないという理由について教えてほしいんですけど?

バカな質問ですみませんが、このFreeBSDもこの問題に引っかかっているのに、なぜOpenBSDは平気なのか不思議です。

事前に把握してたんですか?

昨日、一面記事になったような大ニュースになぜOpenBSDは引っかかっていなかったのか気になります。

これに対するTheo De Raadtの返事。

Intelの誇大広告まみれのCPU機能を全部追いかけるようなマネはしていないんでな。

We didn't chase the fad of using every Intel cpu feature.

強すぎる。

この機能というのはi386から追加されたハードウェアブレイクポイント機能のことだ。なんとOpenBSDではユーザースペースからx86のハードウェアブレイクポイント機能の使用を許可していない。ではgdbのようなユーザースペースのデバッガーはどうやってブレイクポイントを実装しているのかと言うと、古き良きソフトウェア実装を用いている。ブレイクポイントを仕掛けたい部分のコードを割り込み命令(int 3とか)とか無効命令(ゼロ除算)で置き換えておき、例外割り込みをブレイクポイントを仕掛けたい場所で発生させることによる移植性の高いソフトウェア実装だ。

ちなみに、IntelのCPUがハードウェアブレイクポイント機能を実装したのは1985年のi386にまで遡ることができる。

結果として、OpenBSDは今回の主要なOSが軒並み影響を受けた問題に対して何の影響も受けていないので、結果的に正しかったと言えるが、いやしかし凄まじい。OpenBSDのセキュリティにかける情熱を過小評価していた。

2018-05-11

Intelの古いマニュアルを誤読したために生じた脆弱性

Multiple OS Vendors Release Security Patches After Misinterpreting Intel Docs

Multiple OS Vendors Release Security Patches After Misinterpreting Intel Docs | Hacker News

8086でスタックを切り替えるには、ssレジスターとspレジスターを両方変更する必要がある。しかし、ssレジスターだけを変更してまだspレジスターを変更していないときに割り込みがかかると問題だ。そこで、8086は粋なはからいによって例外的にこの問題に対処した。ssレジスターを変更した直後の1命令では割り込みが発生しない。仮に割り込みが起きたとしても1命令を実行するまでは遅延される。

もし、ssレジスターを書き換えた直後の1命令でカーネルモードに入った場合、この粋なはからいが問題になる。カーネルモードに入ったあと、カーネルコードを1命令たりとも実行していない段階で割り込みが発生する可能性があるからだ。しかも実行はカーネルモードだ。