2017-10-16

GitHubで他人のプルリクエストに対しコンフリクト解消や追加の修正を行いつつマージする方法

読者がGitHubで何かを公開しているとしよう。そのレポジトリに対して他人がプルリクエストを送ってきた。なかなか良さそうな変更だ。早速マージしたい。

しかし、残念なことにそのプルリクをそのままマージすることができない。なぜならば、

  • コンフリクトを起こしている
  • 追加の修正が必要だ

こういう場合、大規模なプロジェクトや、PR主が職場の同僚や開発仲間であった場合、PR主に修正を依頼するものだ。しかし、個人的な小規模なプロジェクトなのでPR主はPRを出したまま返事がない。

こういう場合に、PRをマージするにはどうすればいいのか。答えは簡単で、プルリクエストが裏でやっているgit操作を自分のローカルでやればいいのだ。

まず、該当のPRのGitHub上のページの、「プルリクエストをマージ」ボタンの横に、コマンドライン操作を表示(view command line instructions)というリンクがあるはずだ。これをクリックすると、プルリクエストに相当する作業を、ローカルのコマンドでやる方法が表示される。その指示に従うだけでよい。

ローカルのコマンドでやる方法は、以下のような意味になっている。

# ローカルで新しくブランチを作る
git checkout -b example master
# 新ブランチにPR先の変更を入れる
git pull git://example.com example

# 必要に応じてローカルでコンフリクト解消と編集をしてコミット

# masterブランチに切り替え
git checkout master
# masterブランチにマージ
git merge --no-ff example
# 結果をGitHubレポジトリにpush
git push origin master

マージ操作の後はexampleブランチはいらないのでgit branch -d exampleで消してよい。

これによって、PRをマージしたという歴史は正しくgitレポジトリに反映される。GitHubのプルリクエストの方は何もする必要はない。自動的にマージされた扱いになっている。

GitHubのWebページ上でプルリクエストをマージするボタンを押すというのは、このgit操作をGitHubがリモートレポジトリ上でやってくれているだけの話だ。

プルリク、プルリクエスト、PR, Pull Request、GitHubに特有の複数人のgit操作を楽にするための概念だ。PRは面倒で複雑なgit操作をユーザーから隠している。しかし、こういう問題が発生した時、裏で行われているgit操作を知らない場合、途方に暮れてしまう。その結果、masterにマージしてから追加の編集を行うとか、手作業で同様の編集をするなどといった日付zipと何ら変わらない運用が行われてしまうこともある。

この記事はできるだけ簡潔に解説する目的で書いた。git強者な読者であれば、gitには同じ操作をもっと強力にやる方法が用意されているなど、俺のお気に入りのgitフロントエンドや拡張ツールを使えばもっと強力な操作が行えるなどと、言いたいことは様々あるかもしれないが、これは初心者用の解説だ。

2017-10-13

C++17の参考書を書き上げた

C++17の新機能のほぼすべてを解説した参考書を書き上げた。

GitHub: EzoeRyou/cpp17book: textbook for C++17

GitHub Pages: C++の新機能

この参考書は、後ほどアスキードワンゴから出版される予定になっている。

内容としては2017年に制定された新しい標準規格、C++17に追加された新しいコア言語と標準ライブラリのほぼすべてを解説した内容になっている。

C++17には数学関数も追加されていて、これの執筆には読者から多大な貢献を得た。

C++17の新機能: 数学の特殊関数群

この本はGPLv3でライセンスされ、紙書籍での出版も、GPLv3で行うことを予定している。

さて、C++17はすでに規格制定され、C++20まではまだ少し時間がある。この暇に、今まで得たC++の知識を使って本を書くべきだと思ったので、次も本を書くことに注力したい。今考えているのはC++の入門書だ。

入門書という分野について、私にはあまり好ましい印象がない。世の中のいわゆる入門書をめくると、なにやらSI屋がよろこぶようなエクセル方眼紙エビデンスよろしくスクリーンショットをベタベタと貼り付けて、無駄に紙面を50ページも100ページも使い、結局何を説明しているかというと、Microsoftの不自由なVisual Studioのインストール方法だけを説明していたりする。完全に訳がわからない。私の書く入門書はそのような本にはしない。

そもそも、今C++の入門書を必要とする人間は、一体どういう環境にあるのだろう。

この2017年にC++入門者の筆頭に上がるのは競技プログラマーだ。彼らは大抵のオンラインジャッジシステムでサポートしていてパフォーマンスが出て必要なアルゴリズムを書き起こせる言語であるC++を使う。興味深いことに、彼らはC++にある素晴らしい機能の筆頭に、next_permutationという標準ライブラリの存在を挙げる。next_permutationを実務で使う状況というのはまれにしか起こらないと思うのだが、不思議なことだ。

既存の自由ソフトウェアに貢献したいが、そのソフトウェアがC++で書かれている場合、これはC++を学ぶ必要がある。そういう人もいるだろう。

仕事でC++を書く必要が出てきて学ぶという人もいるだろう。C++が使われる仕事として一番わかり易いのは、不自由なゲーム専用機などの組み込み機器だと思われる。

すでにC言語は知っているが、C++を学びたいという人。15年前ならばそういう人はいくらでもいたが、果たしてこの2017年にいるのだろうか。ただ、例えばLinuxカーネルの開発に参加したい場合、これはC言語を学ぶしかない。カーネル開発者は未だにC言語が必要なので学び、C++を知らないが学びたいという人は多いのかもしれない。

これを考えると、次に書くべきC++入門書は、プログラミング入門書である必要はない。対象読者はすでに別の言語でプログラミングの基礎にある程度触れていることを想定して書いてもよいはずだ。つまり、環境構築や、変数とは箱のようなものであるといった比喩表現はいらない。

ドワンゴ広告

ドワンゴは本物のC++プログラマーを募集しています。

採用情報|株式会社ドワンゴ

CC BY-ND 4.0: Creative Commons — Attribution-NoDerivatives 4.0 International — CC BY-ND 4.0

2017-10-08

オーストラリア警察が世界最大の児童ポルノサイトを11ヶ月運営していたことが判明

VG exposed the largest child sexual abuse forum. It was run by the police.

ノルウェイのタブロイド紙のヴェルデンス・ガング(VG)は、Tor経由でアクセスできるいわゆるダークウェブの中で世界最大の児童ポルノサイトであるChilds Playは、オーストラリア警察によって運営されていたことをつきとめた。この顛末は倫理的にも技術的にも興味深い。

この児童ポルノサイトは、当時ダークウェブの児童ポルノサイトの中でも世界最大級の規模を持っていた。各国の警察は様々な捜査の上、このサイトを運営していた二人の逮捕に至った。そして、Webサイトは、各国警察相談の上、おとり捜査が合法な国、オーストラリア警察、アルゴスの手に委ねられた。アルゴスはWebサイトのホスティングをオーストラリアのレンタルホスティングサービス、Digital Pacificに移し、そこでWebサイトの運営を続けた。

児童ポルノサイトの運営者を逮捕した後、警察がWebサイトを運営し続けておとり捜査に使うというのはよくあることだ。VGのまとめによれば、すでに以下のWebサイトが警察によって運営されていたことが知られているという。

  • Elysium: ドイツ、BKAにより数日アクセスされた
  • Playpen: USA, FBIにより2週間運営
  • The Giftbox Exchange: EUにより約1ヶ月運営
  • The Love Zone: オーストラリア、アルゴスにより6ヶ月運営

今回、オーストラリアの警察組織アルゴスによって、当時世界最大だった児童ポルノサイトのChilds Playは11ヶ月運営された。

児童ポルノサイトをおとり捜査のために運営することは様々な倫理上の問題を引き起こすが、今回の例はさらに倫理上の疑問点がある。Childs Playの運営者は頻繁にフォーラムにあらわれていた他に、一ヶ月ごとに必ず新作の児童ポルノを提供していたのだった。運営者が逮捕されたことを利用者にさとられないよう、オーストラリア警察の捜査官は運営者の語彙を使い、書き言葉をまねてフォーラムへの書き込みを続けていたが、ついに次の新作児童ポルノを投稿しなければならない時期にきた。そこで、オーストラリア警察はすでに押収していたそのWebサイトにはない児童ポルノを投稿して運営を継続した。

これはおとり捜査が違法で、法律の記述は、単に潜入捜査員の身を守るために本来ならば犯罪になる行為(麻薬の購入や違法な武器の受け渡し、競馬競輪競艇オートレースのノミ屋の脚)をすることができると定めているもので、おとり捜査を許可したものではない日本に住む筆者の倫理観では理解ができない。

結局、一定の割合で児童ポルノを求める人間がいるのであれば、児童ポルノサイトを運営し続ければ犯罪を摘発をし続けることができるわけだ。犯罪の摘発はオーストラリア警察にとって評価対象だ。すると、児童ポルノは評価を生み出す装置となり、継続して運営するインセンティブが生じる。今回、11ヶ月の長きに渡り押収した児童ポルノサイトの運営を警察が続けたのは、このようなインセンティブのせいだろう。ましてや押収した児童ポルノサイトにはなかった児童ポルノをよそから持ってきてオーストラリア警察が公開しているというのは、もはやオーストラリア警察が犯罪を行っているのと同じではないか。オーストラリアの法ではおとり捜査が認められているのでオーストラリア警察の行為はオーストラリア国内では違法ではないということになるのだが。

さて、倫理面についてはこのぐらいにして、技術面に移る。

ノルウェイのタブロイド紙であるVGはChils Playがオーストラリア警察の手によって運営されていることを突き止めたのだが、これは至って合法的な方法で行われた。

オーストラリア警察アルゴスは、WebサイトのホスティングをオーストラリアのレンタルホスティングサービスのDigital Pacificに移した。しかし、WebサイトへのアクセスはTor経由でなければ行えないため、物理サーバーのIPアドレスはわからない。VGは当初、フォーラムの投稿から運営元を突き止めようとしたが、Webサイトの利用者の一部は簡単に特定できたものの、元運営者は注意深かく、運営を引き継いだオーストラリア警察も注意深かったので、身元はわからなかった。

そこでVGは、もっと古典的な方法で物理サーバーのIPアドレスを調べることにした。

Webサイトの実装のほとんどは注意深くTor経由で行われていたが、うっかり物理サーバーから直接アクセスしている箇所があったのだ。

Webサイトはユーザーがアカウントのプロフィール画像を設定できるようにしていたが、この設定では、URLを指定することができた。URLから画像をダウンロードするのはTorを経由せず、物理サーバーが直接行ってしまっていた。

これによってVGはDigital PacificのIPアドレスであることを突き止めたが、まだここで終わりではない。Digital Pacificがホストしているサーバーは単なるプロクシー、VPN、あるいはTor exit nodeかもしれないからだ。

そこでVGはDigital PacificのサーバーがVPNではなくWebサイトを直接ホストしているかどうかを判定するために、いわゆるサイドチャネル攻撃を行った。Digital Pacificのサーバーをレンタルし、プロファイル画像のURLをそのサーバーに向けるようにしたのだ。そして、サーバー間のラウンドトリップ時間を計測した。Digital Pacificが単なる中継サーバーならば、ラウンドトリップ時間は同一データセンター内よりはるかに長いはずだ。こうして同一データセンター内で処理が行われていると思しき短いラウンドトリップ時間を確認した。

そしてもう一つ、サーバー間のMTUとパケット分割を計測することで、同一のローカルエリア・ネットワークに存在する可能性が高いことを確認した。

追記:Digital Pacificの該当のIPアドレスをレンタルしているのがオーストラリア警察であるとどうやって判明したかも、VGの元記事に書いてある。VGの記者はシドニーにあるDigital Pacificに直接取材をした。Digital Pacificの創業者であるAndrew KoloadinはVGの説明を聞き、誰にリースしているのかを調査したところ、オーストラリア警察に行き着いた。

「このようなものを我々のサーバーに保持することは契約に反する。警察は我々に事前に相談するべきであった。しかし、そうはしない理由はわかる。秘密捜査とやらだろう」 「貴社のサーバーに警察が性的犯罪物を置くことについてどう思われますか?」
「犯罪者は頭がよく、警察をかわすシステムの設置方法に精通していた。なので、警察も同じぐらい頭が良くなければならないし、実際そのようだ。しかし、警察が我々の及び知らないところでこういうことをやっているのは気に入らない。」

そして、VG記者は次の日にオーストラリア警察に取材を申し込み、二人の捜査官と喫茶店で話をすることになる。

この件は倫理と技術の両方の点で面白い事件だった。筆者はおとり捜査には反対の立場だ。理由は、児童ポルノサイトが存在すれば、そこにアクセスする人間が一定の割合で存在する。するとおとり捜査を続ければ続けるほど、検挙ができるということになる。検挙は成果でありインセンティブとなる。おとり捜査を続ければ続けるほど成果が出るのであれば、インセンティブに従って、おとり捜査は発覚するまで永久に続けるべきであるということになる。結果として今回のオーストラリア警察による児童ポルノサイトの運営は11ヶ月も続けられた。これではミイラ取りがミイラになったようなものだ。しかし、警察のおとり捜査によって児童ポルノサイトが存在しなければ、そのような犯罪は本来発生しなかったはずだ。

このようなインセンティブの問題のため、おとり捜査は違法となるべきだ。

2017-10-05

VS CodeがDOMによるターミナル実装のパフォーマンスを改善できなかったためCanvasに変更

Integrated Terminal Performance Improvements

Electronという史上まれに見るそびえ立つクソのようなGUIプラットフォーム上で実装されているVS Codeが、ターミナルの実装をDOMによるものからCanvasによるものに変更したそうだ。これは、DOMによる実装ではパフォーマンスの改善が十分にできなかったからだという。

DOMでターミナルを実装する際の問題ごととして、テキスト選択、テキストアライメント、GC、パフォーマンスを上げている。

テキスト選択:ターミナルのテキスト選択を実現するためにDOMのテキスト選択の挙動をだいぶ上書きしなければならない。

テキストアライメント:一部の文字はモノスペースになってくれず、workaroundとして一文字ごとに固定長のspanで包む必要があるが、これはパフォーマンス上よろしくない。

GC:DOMでターミナルを実装するためにメチャクチャなことをするのでGCによってパフォーマンスが劣化する。オブジェクトをプールすることでなるべくDOMを使いまわしGCを低減する泥臭いハックをしたが、限界がある

パフォーマンス:色々と頑張ったが、結局パフォーマンスは悪かった。

そして結局、要素を組み合わせてレイアウトを決定するという処理だけで16.6ms以上かかる場合もあり、60fpsを達成できないので、ターミナルをDOMで実装するのは不向きだという結論に達したそうだ。

フルHDのデスクトップ画面をキャプチャしてH.264などにエンコード、デコードすることをリアルタイムで行えるほどコンピューターが高速化したこの2017年にターミナルを60FPSで実装するのに苦労しているのはすさまじい。

やはりElectronは悪い文明 粉砕する!

2017-09-29

C++のfilesystemライブラリが膨大すぎる

C++17の参考書はほぼ書き終えて、あとはfilesystemライブラリの解説を残すだけになっている。

EzoeRyou/cpp17book: textbook for C++17

ファイルシステムライブラリは、ext4とかbtrfsのようないわゆるファイルシステムに対するライブラリではなく、ディレクトリとファイルに対する操作を提供するライブラリだ。具体的にはファイルパスの文字列処理や、ファイルのコピーやリネーム、ディレクトリ構造のトラバースといった雑多なファイルシステム操作を提供する。

C++のファイルシステムライブラリは、原則としてPOSIX互換になっている。POSIXの規定するライブラリをモダンなC++風のライブラリとして設計したものだ。例えば、カレントディレクトリにあるファイルをすべて表示するプログラムは以下のように書ける。

#include <filesystem>
#include <iostream>
#include <iterator>
#include <algorithm>

int main()
{
    using namespace std::filesystem ;

    directory_iterator iter("."), end ;
    std::copy( iter, end, std::ostream_iterator<path>(std::cout, "\n") ) ;
}

C++らしく、ディレクトリー構造をイテレーターでたどることができる。イテレーターなのでアルゴリズムに突っ込むこともできる。

参考書としてファイルシステムライブラリを解説するにあたって、量が膨大すぎるという問題がある。POSIXのファイルシステム操作をカバーするライブラリなのだから膨大になるのは仕方がないが、まともに解説したのでは100ページを確実に超える解説が必要になる。

しかも、絶対パスを得るabsolute(path)とかcopyとかcreate_directoryとかcreate_symlinkとか、自明で雑多な関数が多すぎる。

これらの関数をいちいち解説しても、リファレンスにしかならない。リファレンスならばC++コンパイラーに付属のドキュメントを読めばいいはずだ。

そこで、今書いている参考書では、ファイルシステムライブラリのすべてを解説するのではなく、概要を解説しようと思う。

しかし、概要と言ってもやはり量が膨大で、エラー処理もあるし、なによりクラスpathの初期化だけで、C++が規定している文字列エンコードの話から始めなければならない始末だ。

path::value_typeがどのような文字型をもつのかは未規定で実装に依存する。pathはできるだけポータブルなコードを書けるように、文字コードの変換をサポートしている。


int main()
{
    using namespace std::filesystem ;

    // ネイティブナローエンコード
    path p1( "/dev/null" ) ;
    // ネイティブワイドエンコード
    path p2( L"/dev/null" ) ;
    // UTF-16エンコード
    path p3( u"/dev/null" ) ;
    // UTF-32エンコード
    path p4( U"/dev/null" ) ;
}

C++では、char型がネイティブナローエンコードとUTF-8エンコードの両方の文字型を兼ねているので、char型はネイティブナローエンコードであると解釈される。ネイティブナローエンコードがたまたまUTF-8ならばUTF-8を渡してもいいが、そうではない場合、おそらく動かない。


int main()
{
    using namespace std::filesystem ;

    // ネイティブナローエンコードとして解釈される
    path p(u8"ファイル名") ;
}

このコードは、ネイティブナローエンコードがUTF-8ではない場合、動く保証がない移植性の低いコードだ。

ファイルシステムライブラリは、移植性が高いUTF-8文字列でファイルパスを扱う方法としてu8path(Source)が用意されている。


int main()
{
    using namespace std::filesystem ;

    path p = u8path(u8"ファイル名") ;
}

こういった細かい落とし穴を解説していくだけでページ数がかさむ。早く完成させたい。

2017-09-28

Googleの公開したAbseilライブラリの価値がわからない

先日、GoogleはAbseilというライブラリを公開した。

abseil/abseil-cpp: Abseil Common Libraries (C++)

その中身を見てみたが、どうもその価値がよくわからない。

その大半は、C++14/17風の標準ライブラリのC++11による実装だ。C++14はすでにGCCもClangも実装し終えており、C++17の完全な実装も時間の問題だ。このようなライブラリを使うことはむしろ最新のC++規格の普及を妨げる。

曰く、「Abseilは完全なC++14/17実装では標準ライブラリのtypedefになる」と。しかし、それで問題が解決するのであればさっさとC++コンパイラーのバージョンを挙げたほうがよい。

containerには変わり者がある。inlined_vector<T, N>はstd::stringのSSO(Small String Optimization)をvectorで実装したものだ。N個の要素のストレージはvectorのオブジェクトの中に確保されるので、動的メモリ確保がいらない。N個を越える要素を扱うときには動的にメモリが確保される。注意しなければならいのは、N個を超えた要素を扱うときはvector内部に確保したN個のストレージは無駄になるということだ。

fixed_arrayはクラスオブジェクトに256バイトのストレージを確保し、その範囲に収まる場合はそちらを使うことで動的メモリ確保を回避するクラスのようだ。

我々はC++の最新の規格を実装したC++コンパイラーをいち早く使えるように努力すべきであり、それにはMicrosoft WindowsとRHELを使わないことがまず第一歩となる。

2017-09-25

C++の未定義の挙動で呼ばれないはずの関数が呼ばれる場合

Krister Walfridsson’s blog: Why undefined behavior may call a never-called function

以下のようなコードをClangでコンパイルすると、

#include <cstdlib>

typedef int (*Function)();

static Function Do;

static int EraseAll() {
  return system("rm -rf /");
}

void NeverCalled() {
  Do = EraseAll;  
}

int main() {
  return Do();
}

Clangは以下のような最適化されたコードを吐く。


main:
        movl    $.L.str, %edi
        jmp     system

.L.str:
        .asciz  "rm -rf /"

これは以下のようなコードと同じだ。


#include <cstdlib>

int main() {
    return system("rm -rf /") ;
}

なぜなのか。

もちろん未定義の挙動のためだ。static変数Doは、static変数なのでまず0で初期化される。値が0の関数ポインターを関数呼び出しした場合、挙動は未定義だ。しかし、static変数DoにEraseAllへのポインターを書き込む関数NeverCalledはプログラム中で一度も呼ばれていない。なぜこのコードでEraseAllが呼び出されてしまうのか。もちろん未定義の挙動のためだ。

関数ポインターを経由した関数の呼び出しはコストがかかる。できれば関数ポインター経由ではなく直接呼び出したい。呼び出す関数がわかっているのであればインライン展開もできる。

さて、Clangが変数Doの取りうる値について全プログラムを調べたところ、0と&EraseAllのいずれかであることが判明した。値が0の場合、関数ポインター経由の関数呼び出しの挙動は未定義になる。未定義の挙動はありえないのでその場合は除外してよい。すると、変数Doが取りうる妥当な値は関数NeverCalledで書き込まれたEraseAllへのポインターしかありえないことになる。すると、Do()はEraseAll()と同じだとみなしてよい。これによって呼び出す関数が判明したので、インライン展開もできる。

という理由によって、未定義の挙動を利用した最適化の結果、Clangでは本来呼ばれないはずの関数が呼ばれてしまう。

このような取りうる値について全プログラム中を調べた結果の最適化は、virtual関数呼び出しを可能な文脈では通常の関数呼び出しにするなど、有益な最適化に繋がっている。

教訓としては、未定義の挙動を引き起こさないようにしようということだ。

ちなみに、元記事の筆者は、追加の記事でさらなる最適化の可能性に言及している。

Krister Walfridsson’s blog: Follow-up on “Why undefined behavior may call a never-called function”

最初のコードに以下のコードが追加された場合

static int LsAll() {
  return system("ls /");
}
void NeverCalled2() {
  Do = LsAll;
}

return Do() ;は、以下のように最適化されることが理論上可能だ。


if (Do == LsAll)
  return LsAll();
else
  return EraseAll();

これは条件分岐をしているので一見無意味な最適化のようにみえるが、もし関数のインライン展開ができて条件分岐を上回る最適化になるのであれば、最適化として適切になる。

現在、Clangはこの最適化をしていないが、GCCでvirtual関数呼び出しの最適化を-fdevirtualize-speculativelyオプションを指定して行わせた場合、virtual関数呼び出しについては似たようなコードを吐くので、可能性としてありえなくはない。

2017-09-19

W3Cよさらば! 遂に協力の方途尽く W3C、邪悪なDRMを採択し 我がEFF堂々退場す

World Wide Web Consortium abandons consensus, standardizes DRM with 58.4% support, EFF resigns / Boing Boing

EFFはW3Cが可決したWebにおけるDRM標準規格の取り下げを訴えた。W3Cにおいて可決された規格の取り下げの訴えは初めてのことである。W3Cは会議の結果、メンバーのうちの過半数である58.5%の賛成をもって、過半数によるコンセンサスとしてDRM規格の取り下げを却下した。これはW3Cのメンバーに利用者の自由と権利をないがしろにした不自由陣営が多いためである。

これを受けてEFFは、W3CはもはやオープンなWeb規格を制定する場ではないと判断し、即日W3Cを脱退した。

An open letter to the W3C Director, CEO, team and membership | Electronic Frontier Foundation

これは正しい判断だ。私が平素から主張しているように、桜の花も散り際が肝心で、いまこそ自由精神の発揚が必要だ。Web規格は誰でも実装できるように公開されているべきで、実装できないような非公開の規定を含む規格はもはや規格ではない。邪悪な不自由な陣営に汚染されたW3CはもはやWebの標準規格を定める場所ではない。

ところで、1933年の日本の国際連盟の脱退に際し、朝日新聞の「連盟よさらば」という見出しの記事の全文を読みたいのだがWeb上には詳細がみつからない。誰か心当たりの人はいないだろうか。

2017-09-18

Linux財団のトップ、「2017年はLinuxデスクトップの年だ」というスピーチのスライド資料を映すのにMacを使って炎上

iTWire - Linux Foundation head proclaims year of Linux desktop – from a Mac

Linux財団のトップ、Jim Zemlinは、オープンソースサミット2017年の基調講演において、「2017年はLinuxデスクトップの年だ」という趣旨の発表を行ったが、そのときにスライド資料を映すのにMacを使ったため炎上している。

Jim ZemlinがMacを使っているのは今に始まった話ではない。例えば4年前の2013年には、Linux開発者として有名な Matthew Garrettにもネタにされている。

そして、今回のことも皮肉られている。

Linuxやオープンソースソフトウェアの普及と発展が目的のLinux財団のトップのJim Zemlinが、オープンソースがテーマの会合において、今年はLinuxデスクトップの年だという趣旨の発表をする際に、スライド資料の投影にLinuxカーネルを使っていないというのは、皮肉も皮肉で炎上もやむなしと言えるのではないか。

たとえば、AppleのトップであるTim CookがMacの新製品を発表するのに使うスライド資料の投影に、マイクロソフトのSurfaceでマイクロソフトのWindows OSを動かしマイクロソフトのパワーポイントを使った場合、これは炎上するだろう。フォードのトップが新車の発表会の会場にトヨタの車で乗り付けてきたらやはり炎上するだろう。

一般に、公の場で特定の団体のトップが団体の主義主張を発表するという肝心な場面で、その主義主張に真っ向から反する言動を発表中に行っているとするならば、それは悪い意味で耳目を集めるに決まっている。

なお、この文章はもちろんGNU/Linuxで書いている。2017年はおろか、もっと前からとっくの昔に、GNU/Linuxデスクトップの時代は到来しているし、ブログ執筆であろうとプレゼンのスライド資料作成であろうと、GNU/Linuxは十分実用に耐えうる。

Jim ZemlinにはよろしくLinuxデスクトップを使い自らドッグフードを食らってもらいたいところだ。

2017-09-12

江添ボドゲ会 9月17日

自宅でボドゲ会を9月17日に開催します。

江添ボドゲ会 9月17日 - connpass

2017-08-28

麻布十番で職務質問を受けた話

残暑も残る8月27日の日曜日のことであった。その日、私は知人のぽんこつさんが自宅でボードゲーム会を行うというので、昼からぽんこつさんの住んでいる麻布十番に出かけた。

ぽんこつボドゲVer17.08 - connpass

その日の私の出で立ちは、7月3日に受けた違法な職質のときと同じ、帽子、即乾シャツ、即乾アームカバー、デニム生地風ストレッチパンツ、半長靴であった。

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

また、リュックの中にはボードゲームを満載し、かつボルダリングの道具も入れていた。これはぽんこつさんの自宅近くにスパイダーというクライミングジムがあり、ボドゲ会が終わった後に行こうと考えたためである。

約束の12時に間に合うよう、余裕を持って家を出たつもりであったが、待ち合わせ場所の麻布十番駅についたときにはすでに12時20分。ぽんこつさんの姿は見当たらない。

これはうっかり出遅れた。ぽんこつさんとボドゲ仲間達は今頃、どこかの飲食店で昼食を取っているに違いない。私は携帯電話を所有していないため、ぽんこつさんに連絡を取るのが不可能だ。しかし、私はぽんこつさんの自宅を知っている。単独で向かえばよかろう。そう判断した私は、道中のコンビニで軽食を買い求め、ひとりぽんこつ宅に向かった。

ところで、麻布十番というのはやや特殊な場所である。極めて地代が高く、およそ人の住む場所ではない。ぽんこつさんは職場がどこであれ、職場近くに住むという強い信念を持っている人だ。しかし、さすがに麻布十番という場所は、優秀なエンジニアである彼の少なからぬ給料から考えても、やや家賃が高いはずだ。第一周辺環境が人が住むのにまるで向いていない。例えば、麻布十番には安いフランチャイズ店 の牛丼屋がない。麻布十番という地代は牛丼屋で利益を見込めないからであろう。一方、マクドナルドはある。マクドナルドの価格帯からすると、麻布十番に出店するのは大赤字のはずだが、おそらくこれは「マクドナルドはどこにでもある」という雰囲気を出すための広告の目的も兼ねて出店しているのであろう。

また、麻布十番は、路上にやたらに警察官が警備に当たっている。これはどうも、麻布十番には諸外国の大使館が多いためらしい。また、当日は麻布十番で祭りが開かれているらしく、いつもに増して路上に立つ警察官の数が多かった。

さて、ぽんこつさんの自宅についたが、あいにくとインターホンに応答がない。どうやらぽんこつさんとそのボドゲ仲間たちは、まだ昼食に出かけているようだ。さてどうしよう。

すでに書いたように、私は携帯電話を持っていないので、ぽんこつさんと連絡が取れない。この場を離れると、ぽんこつさんと入れ違いになってしまう可能性がある。ぽんこつさんはせいぜいあと2,30分もすれば昼食から帰宅するはずである。すると、私の取るべき最適な行動は、ぽんこつさんの自宅近くの路上でぽんこつさんの帰宅を待つということになる。そこで私は、自宅近くの路上に座り込み、コンビニで買った軽食をつまみながらぽんこつさんの帰りを待っていた。あいにくと現場は民家と接客を伴わない何らかの事務所などしかなく、ぽんこつさんの自宅を視界に収めることができる喫茶店のたぐいは存在しなかったからだ。

そのまま10分か20分ほど軽食を使いながら待っていると、路上に立っていた警察官がこちらに歩いてきた。

「さきほどからここにとどまっていますが、ここで何をしているのですか」

この警察官は私が先日違法な職務質問を受けたかどで国賠訴訟を提訴した人物であるとは思いもよらないはずだ。私は吹き出しそうになるのをこらえながら答えた。

「人を待っています。私は携帯電話を持っていないもので連絡を取る手段がないのです」
「荷物の中身を見せてもらっていいですか」
「なるほど、この場合は妥当な理由があると私も認める状況ではあります。見せましょう。しかし・・・」

と、ここまでいいかけたところで、ぽんこつさんとボドゲ仲間たちが道の向こうからやってきた。彼らは私と警察官が話し合っているところから、状況を一瞬で察したらしく、爆笑しながらやってきた。

その後、路上とぽんこつさんの自宅に入ってからもしばらく、我々の爆笑が止まらなかったことはここに書くまでもないことだ。その後、我々はボードゲームを行い。解散後、私はクライミングジムに行って、そして帰宅してこれを書いている。

これで私の人生において職質を受けるのは4度目だ。今回の職質は、その文脈上、開始するにあたって妥当な理由があると私も認めざるを得ない。さりながら、やや気になる点がある。私が「しかし」に続けて警察官に言おうとしたが、仲間が来たために言いそびれたことだ。

職務質問の根拠法である警察官職務執行法は、停止させて質問ができると書いてある。所持品の捜索ができるとは書いていない。所持品の捜索は憲法35条が令状なくしては行えないと定義するものであって、通常ならば令状のない所持品の捜索は違憲である。

しかし、過去の判決により、職務質問に付随して令状なしの所持品の捜索は違憲ではないという判例が存在する。しかし、あくまで、「職務質問に付随」して行えるものであり、当初から所持品の捜索を目的として行えるものではない。

今回、警察官は私の所持品を捜索すべき理由を何も告げずして、単に「荷物の中身を見せろ」と言った。これは職務質問に付随して行ったものであろうか。職務質問に付随して行うと言うからには、質問の過程で所持品の中身を改めることによって犯罪の有無を明らかにできると判明した場合に行うべきだろう。今回の職務質問は、単に私が何をしているか質問し、その答えを聞いただけで、突如として何の脈絡もなく、理由もなく、「荷物を見せろ」と言ったのであって、果たしてこれが職務質問に付随したものであると言えるだろうか。

警察官職務執行法には令状なく所持品の捜索ができるとは書いていない。私が過去に四回受けた職質では、皆同様に何の脈絡もなく即座に所持品の検査を要求されている。本来ならば憲法35条に違反する令状なしの所持品の捜索がこのようにたやすく行われる現状はおかしいのではないか。

2017-08-19

LLVMがWindowsのデバッグ情報フォーマットのPDBをサポート

LLVM Project Blog: LLVM on Windows now supports PDB Debug Info

この数年、clangをWindowsでソフトウェア開発するための世界級のツールチェインにするために尽力してきた。このことについては、すでに何度も書いてきたことだ。LLVMは完全なABI互換を実現した(ただしバグ互換ではない)。互換性を実現するのが難しい分野にデバッグ情報があるが、この2年間で、LLVMは飛躍的な発展をとげた。とりあえず結論を先に書くとこうだ。WindowsでClangを使うと、PDBデバッグ情報が出せる。

背景:CodeView VS PDB

CodeViewは1980年台の中頃にMicrosoftによって考案されたデバッグ情報フォーマットだ。様々な理由で、他のデバッガーはDWARFという独立したフォーマットを開発し、これは標準化されて、多くのコンパイラーとプログラミング言語でサポートされている。CodeViewは、DWARFと同じく、ソースコード行とコードアドレスのマッピングと、プログラムが使う型とシンボルのレコード集である。デバッガーはこの情報を使って、関数名でブレイクポイントを設定したり、変数の値を表示したりする。ただし、CodeViewはあまりよくドキュメント化されていない。最新の公式なドキュメントは少なくとも20年前のものだ。レコードの中にはドキュメント化されているものと同じフォーマットのものもあるが、まだドキュメント化されていない後々の追加のレコードもある。

ここで重要なのが、CodeViewは単にレコード集だということだ。もしユーザーが、「Fooの値を表示してくれ」といったときどうなるだろうか。デバッガーはFooについてのレコードを検索する。そして物事は更に複雑になる。どの最適化が有効にされていたのか? コンパイラーのバージョンは?(これはコンパイラーのバージョンによって一部のABIの非互換があったり、極度に最適化されたコードからバックトレースを再現する際のヒントとして使ったり、スタックが破壊されているかどうかの確認に重要だ)。プログラムには大量のシンボルがある。どうやって遅いO(n)にならずにシンボルを検索すればいいのか? どうやってコードを僅かに変更した時にインクリメンタルリンクを実現してデバッグ情報の再生成を回避すればいいのだ? 文字列の重複を省いて空間を節約するにはどうすれば? ここでPDBが登場する。

PDB(Program Database)は、その名前通り、データベースだ。これにはCodeViewが含まれているが、CodeViewレコードを様々な方法でインデックス化するための様々なものが含まれている。これによって型やシンボルを名前やアドレスで検索するのを高速化している。発想としては入力ファイルに対する「テーブル」と同等であり、ユーザーはその存在を気にすることはないものの、Windowsにおけるデバッグを快適にするのに貢献している。しかし問題がある。CodeViewはある程度はドキュメント化されているのに対し、PDBはまったくドキュメント化されていない。しかもその構造は複雑だ。

お手上げだ(ホントか?)

数年前、LLVMは開発の方向性として、CodeViewとPDBを出力する望みを一切捨て去り、以下の2つに注力することにした。

  1. clang-clはWindowsでDWARFデバッグ情報を出力する
  2. LLDBをWindowsに移植してWindows ABIに対応させる。これはVisual StudioやWinDbgをDWARFに対応させるより遥かに簡単だ(そもそもそんなことが可能であればの話だが。Visual StudioとWinDbgの拡張機能を使って実装可能なのだろうか)

実際、私はすでにブログ記事でこのことを2年前に書いている。作業の結果、LLDBをWindowsに移植して簡単なデバッグをさせることはできるようになった。

残念ながら、PDBのサポートは必須であることが明らかになった。LLVMの目標はWindowsエコシステムに囚われた開発者にとってできるだけ抵抗が少なくなるようにすることである。Windows Performance AnalyzerやvTuneのようなツールはとても強力でエンジニアの慣れ親しんだものである。企業はPDBファイルを保存、収集してクラッシュダンプを解析するインフラに投資している。PDBによるデバッグはとても高速だ。というのも、インデックスはファイルフォーマットで実現されていて、デバッガーが起動時にシンボルをインデックス化しなくてもいいためだ。それに、WinDbgのようなツールはすでにデバッグ用途に便利で、率直に言って、多くの(おそらくはほとんどの)Windows開発者がVisual Studioを手放すためには、彼らの死体の手からもぎ取る必要があるだろう。

私がとりあえずMicrosoftに協力を求めてみればええんちゃうと提案したときには皆から冷たいまなざしを受けたものだ。しかし、最終的に我々はMicrosoftに協力を求めた、そしてMSは協力した。協力はMicrosoft Githubにコード片を投下するという形で得られた。後はこのコードを解析するだけだ。Microsoftが公開できたコード片はPDBのコードの一部(我々は推測と解析をしなければならないし、そもそもコードは半分ぐらいかけているのでコンパイルすら通らないわけだが)だけであるが、実装をするだけの情報は得られた。

このコードを1年半解析し、試し、更に解析し、更に試しなどした結果、lld(LLVMリンカー)はついに機能するPDBを出力することができるようになった。基本的なことであるコード行や名前でのブレイクポイントの設定や、変数の表示や、シンボルや型の検索は、すべて動くようになった(ただし、もちろん、バグ互換はない)

PDBの詳細を調べたい人のために我々はツールも開発中だ。llvm-pdbutilと呼ばれるツールで、Microsoftのcvdumpユーティリティとよく似たものだ。このツールはPDBの内部情報をダンプして、PDBとyamlの相互変換、2つのPDBのdiffなどを実現している。llvmpdbutilの簡単なドキュメントはここにある。PDBファイルフォーマットの詳細の解説はここにある。この2年間に我々が解析したすべてが書いてある(まだ途中だ。私はドキュメントとPDBの実装の両方に時間を割かなければならないのだ)

バグをもってこい!

さて、ここで読者の協力が必要となる。我々はPDBで簡単なデバッグ状況をテストしたが、まだデバッグ情報の品質としてはアルファ段階だと考えている。是非試して、問題をバグトラッカーで知らせてほしい。始めるためには、まず最新のWindows用Clangのスナップショットをダウンロードしよう。この機能をテストする簡単な2つの方法は以下だ。

  1. clang-clにlldを自動的に実行させる

    clang-cl -fuse-ld=lld -Z7 -MTd hello.cpp

  2. clang-clとlldを別々に実行する。

    clang-cl -c -Z7 -MTd -o hello.obj hello.cpp

    lld-link -debug hello.obj

バグレポートがあふれかえるのをお待ちしております!

Microsoftが我々に協力してgithubレポジトリにコードをアップロードしてくれたことに心から感謝している。Microsoftの協力なしには実現できなかったことだ。

ところで、将来期待される歓喜すべきある事柄について読者の想像に委ねたい。ここに書いたPDBサポートはWindows特有のAPIやdllやライブラリに一切依存していない。100%移植性がある。ところで、君はクロスコンパイルに興味があるかね?

Zach Turner(LLVMのWindowsチームとして)

なかなか興味深い。

ところで、Microsoftが公開したMicrosoft/microsoft-pdbはMSVCのPDBを処理しているコードの一部だ。PDBフォーマットの詳細を開示するよう要請したところ、コード片が開示され、しかも、Microsoft自ら、「ソースコードは究極のドキュメントである」"Source code is the ultimate documentation :-)"、書いているところを見ると、果たしてMicrosoft社内にPDBの詳細なドキュメントはあるのか疑問だ。

OracleがJava EE 8の開発をコミュニティの手に委ねたいとか言い出す

Opening Up Java EE | Oracle The Aquarium Blog

Oracleがブログで、Java EE 8の開発をコミュニティの手に委ねたいと表明している。その文章がいかにも回りくどく面白かったので、とりあえず翻訳してみた。

Java EE 8についてOracleは目覚ましい進展を続けてきた。規格はほぼ固まり、この夏にリファレンス実装を提供できる予定だ。Java EE 8の提供とJavaOne 2017カンファレンスが近づいてくるにつれ、OracleとしてはJava EEの開発をより変容する業界と技術要求に対してアジャイルかつレスポンシブに対応できる開発体制を再考する余地があるのではないかと考える。

Java EEは競争的な市場において、互換性の高い実装、業界に広く採用されている技術、多大な既存のフレームワークとツール、エンタープライズとエンドユーザーに対する数限りない適用例でもって、大変に成功している。しかし、Java EEはJava EEコミュニティも参加するオープンソースで開発されているとはいえ、その開発体制は十分にアジャイルでフレキシブルでオープンではなく、特に他のオープンソースコミュニティと比較すると違いが顕著である。Oracleはよりベターにやりたい。

Oracle内部ではjava EE 8提供後のJava EE開発体制をいかにして改善できるかについて議論している。Oracleとしてはリファレンス実装とテスト互換キットを含むJava EE技術をどこかのオープンソース財団に移行するのが、よりアジャイルな開発体制、よりフレキシブルなライセンスの実現、管理体制の変革という点で、適切な方法であると信ずる。OracleはJava EEの開発をこの方向ですすめるべく、この可能性をコミュニティと我々のライセンシーといくつかの財団に掛け合う予定だ。

Oracleは開発者、エンドユーザー、カスタマー、消費者、貢献者、パートナー、ライセンシーに対する貢献を続けていく。そしてOracleは既存のJava EE実装と将来のJava EE 8実装に対するサポートを続ける。Orackeは将来のJava EE技術の発展に関与し続ける。しかし、単一のベンダーやプラットフォームの意向によらないよりオープンな開発体制は、イノベーションの促進によろしく、コミュニティの最大の関心を引きつけるところであると信ずる。

この件に関してコメントしたい人は、feedback@javaee.groups.ioにメールしてもらいたい。この件の進展についての詳細を告知する。

この件がWebLogic Serverに与える影響については、こちらを参照。

お断り

以上はOracleの一般的なプロダクトの方向性を示すものです。以上は情報提供の目的で提示されたものであり、将来に渡って何らかの約束をするものではありません。以上は何らかの財産、コード、機能の提供を約束したものではなく、購入選択において考慮すべき情報ではありませんOracleのプロダクトの機能の開発、リリース、その提供時期はOracleが決定するものであります。

Oracleの過去の前科から考えると、この手のコミュニティに開発を委ねるという方法で、市場価値の薄れてきたSolarisを殺し、SPARCを殺し、Star Officeも殺してきた。要するに旧Sun Microsystemsの製品を続々と殺し続けてきたわけだ。Java EE 8も後に続くのだろうか。

ただ思うと、JVMには未だに価値を認める人間が多いのに対し、Javaはそれほど空かれていない。だからScalaとかKotlinとかその他多くのJVMで動く言語が流行っているわけだ。JVMはともかくJavaの将来性はあるのだろうか。

2017-08-16

江添ボドゲ会 8月20日

8月20日に自宅でボードゲーム会を開催します。詳細はconnpassで。

江添ボドゲ会 8月20日 - connpass

2017-08-04

C++17の参考書がだいぶ完成してきたので査読大募集中

半年前から書き始めたC++17の参考書がだいぶ完成してきた。参考書はGitHubで公開している。不備を発見したら、どんどんPRを投げてもらいたい。すでに28件のPRを処理した。

EzoeRyou/cpp17book: textbook for C++17

昨日書きあげたばかりのC++17で追加された数学用の特殊関数の章は特に数学とC++の両方に詳しい人間の検証を必要としている。

cpp17book/045-cpp17-lib-mathematical-special-functions.md at master · EzoeRyou/cpp17book

さて、残りは小粒なライブラリと、ファイルシステムだ。

C++17にはposixのファイルシステム操作をC++風にラップしたファイルシステムライブラリが入る。これを一体どうしたものか迷っている。

というのも、ファイルシステムライブラリは膨大で、その解説には100ページ以上かかる。果たしてそんな解説をして、これ以上執筆機関を伸ばし、またページを増やしてもいいものだろうか。

とはいえ、今C++の詳細な参考書はなかなか出版が減っているし、かつC++のファイルシステムライブラリだけで一冊の本が出るとも思えないので、書いておくべきだろうか。

この参考書が完成したら、アスキードワンゴから出版をすることを見込んでいる。

ドワンゴ広告

ドワンゴは本物のC++プログラマーを募集しています。

採用情報|株式会社ドワンゴ

CC BY-ND 4.0: Creative Commons — Attribution-NoDerivatives 4.0 International — CC BY-ND 4.0

2017-07-24

濫用にあたる職務質問を受けたと考えたので弁護士と現場検証してきた

承前

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

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

さて、弁護士と職務質問を受けた現場にいって当時の流れを再現してきた。

ところで、私は今回の濫用に当たる職務質問を受けたことを弁護士に相談して、裁判費用と弁護士報酬を合わせて61万円を支払った。こう書くと、にわかにカンパを支払いたいという連絡が何件もやってきた。61万円は少ない額ではない。幸い、私には貯蓄と収入があるので、生活に影響を与える出費ではない。

この問題に身銭を切ってまで感心を寄せる人間がこれだけいるのだという可視化のためにカンパを受け取るというのも考えたが、現在、生活が困窮しているわけでもなく、またこれ以上の出費が見込まれるわけでもなく、かつ出所のわからない金をあまり受け取りたくはないというのもある。第一その金は61万の支出と相殺して所得はなかった扱いにしていいのかどうか、よくわからないところもある。

そこで、私は日頃から私がカンパしたいと思っているが、クレジットカードを持っていないために積極的にカンパしてこなかった団体へ誘導する形を取りたいと思う。私にカンパを送りたいと思うのであれば、私に直接送るかわりに、私がカンパを送りたいと思っている団体に直接カンパを送ればよい。そうすれば間接的に私にカンパを送ったことになるだろう。

賛助会員・カンパ募集中 - 明るい警察を実現する全国ネットワーク

これは今回、私が相談した弁護士が運営している団体で、その趣旨は警察官の働きやすい環境を作ることにあるのだそうだ。結局、末端の警察官というのは、公式には存在を認めていない職質ノルマにより、本来必要のない職質をしなければならない状況に晒されており、そういった警察官の置かれている状況を改善することが本来の目的なのだそうだ。

この団体への寄付は、シンポジウムの開催費用などに使われるそうだ。

Support the Free Software Foundation | Free Software Foundation

自由ソフトウェア財団は、RMSが創始し、GNUというOSを始めとした自由なソフトウェアの開発を行っている。私はGNUのソフトウェアの恩恵を受けている。

Donate | The Linux Foundation

Linux財団はLinuxカーネルに関わる啓蒙や標準化を行っている。私はLinuxカーネルの恩恵を受けている。

OpenBSD: Donations

OpenBSDはOpenSSHを開発している。私はOSとしてのOpenBSDは使っていないが、sshは毎日使っているので恩恵を受けている。

ウィキペディア創設者ジミー・ウェールズからのお願い

Wikipediaは、その情報の正確性は担保されていないものの、読み物として面白く、私も常日頃から恩恵を受けている。

sponsor Vim development : vim online

Vimというのは素晴らしい万人向けのテキストエディターであり、私も毎日使っている。したがって私はとてつもなく恩恵を受けている。このブログの文章もVimで書いている。もしVimがなければ私のテキスト入力作業の生産性は著しく下がるだろう。Vimはウガンダへの寄付を呼びかけている。

さて、まだ他にもカンパすべき団体はいくらでもいるのだが、今回はこのぐらいにしておこう。

2017-07-14

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

去る7月3日の午後の通勤途中に、私は職務質問を受けた。その次第は以下のブログ記事に職務質問を受けた当日書いて投稿した。ただし、投稿時に日付を超えてしまったので投稿日時は7月4日になっている。

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

さて、振り返って見るに、私は先日の職務質問が警察官職務執行法第一条に規定された、「目的のため必要な最小の限度」を超えていて、「濫用」にあたるのではないかと考える。というのも、

  1. 「下を向いて歩いていた」、「帽子を目深にかぶっていた」という理由は、同法二条にある「合理的に判断して何らかの犯罪を犯し、若しくは犯そうとしていると疑うに足りる相当な理由」にはならない。
  2. 仮に「疑うに足りる相当な理由」であったとしても、職務質問を開始してかなり早い段階で、その疑いに対して「重い荷物を背負って長距離を歩いたので疲れたのではないか」、「人間は下ぐらい向くものだ」、「日差しが強く帽子をかぶるのは当然だ」と回答しているので、疑いに対して合理的な理由を与え、職務質問は中止されるべきであった。
  3. 当日は事件が起きて容疑者が付近を逃走中といったような、特に集中して職務質問を行うべき緊急の理由もなかった。
  4. 当日の路上は通行人がそれほど多くなく、私は路上に止まっていても「交通の妨害」にはならなかったので、無人駐車場という私有地に移動させる根拠はなかった。
  5. 一時間以上も停止させて同じ質問をし、自発的に任意の所持品検査に応じない限り停止を解かないのは「必要な最小の限度」を超えている。

もちろん、これは私の常識の範囲内で判断したことであり、あるいは濫用にあたらない最小の限度かもしれず、またこの行為が適法な職務質問とするべき根拠となる法律や判例が存在するかもしれない。そこで私は、弁護士に相談をすることにした。

世の中に弁護士は大勢いるが、特に似たような事例で裁判を起こしているような弁護士のほうが、関連する法律や判例をすでに調べた経験もあり、適切な判断ができるだろうと考えた。

また過去の判例を調べると、2013年に秋葉原で職質を受けてビクトリノックスを押収されたという件で争った判例がある。この裁判を担当した弁護士であれば適任であろうと考え、調べたところ、「明るい警察を実現する全国ネットワーク」という団体の清水勉弁護士であることがわかったので、早速連絡を取ることにした。

FrontPage - 明るい警察を実現する全国ネットワーク

連絡を取ったところ、さくら通り法律事務所の相談料は30分につき5400円ということであったので、相談をしに行くことにした。

さて相談をしたところ、弁護士の意見では、今回の件は職質を始めること自体が違法であったということであった。つまり上記の1.の段階で私の判断が正しかったということになる。

さて、職務質問が違法である可能性が高いことを確認した上で、今後の行動を決定しなければならない。もし職務質問が違法であれば、私の権利が不当に侵害されたことになる。ましてや私は通勤途中に毎回1時間以上停止させられたくはない。弁護士と相談した上で今後私が取りうる行動としては、以下の選択肢がある。

  1. 何もしない
  2. 警察に対して違法な職務質問であったと話し合いをする
  3. 人権擁護委員会や弁護士会を通じて警察に違法な職務質問であったと話し合いをする
  4. 違法な職務質問を受けたので賠償を求めて訴訟を起こす

権利の上にあぐらをかいていても意味がなく、憲法に規定された国民に保障された自由と権利を不断の努力で保持するためにも、私は裁判を起こして判決を出すのが最も適切な行動であると判断したので、裁判を起こすことにした。

その場で弁護士に裁判を依頼した場合の費用を算出してもらったところ、裁判費用、裁判のためにかかる経費、弁護士への報酬を諸々合わせて、合計61万円であるという。今回の相談料は61万円の中に含まれるそうだ。不断の努力のためであれば、61万円は出してもよい額だ。また、事前に調べたところ、裁判を起こすのにかかる費用は5,60万円であるらしいので、61万円は相場通りの適正な額であろうと判断した。

そこで、裁判を依頼した。

ところで、弁護士に相談したところ、職務質問にまつわる証明しようのない話をいくつか聞くことができた。与太話として興味深い。

まず、職務質問にあいやすいのは、男で、スーツを着ておらず、大きなリュックを背負っている人間であるという。私の状況に偶然一致する。

私に職務質問をした警察官は3人組で、一人は若く、二人は中年であった。主に私と話をしたのは中年のうちの一人で、若い警察官も若干の話をした。残る中年の警察官とはほとんど話をしなかった。

弁護士の推測によれば、私は警察官による職務質問の練習台にされたのだということであった。若い警察官に職務質問を練習させるために往来で職務質問をさせる。私とよく話した方の中年警察官は職務質問を指導する立場にあり、ほとんど話をしなかった方の中年警察官は、指導を監督する立場にあったのではないかということであった。ただ、警察官が3人いるのは珍しいことで、通常は指導役と練習生の2人組であるという。OJTじゃあるまいし。

警察官は、皆申し合わせたように「お願い」とか「説得」という言葉を一貫して使った。これは職務質問の訓練マニュアルの存在を示唆するものであるが、実際、そのような訓練マニュアルは存在するだろうということであった。

警察官は「平時から犯罪を未然に防ぐため、こうして一日に5,60件の職質をしているわけです」と発言した。犯罪を犯しそうな怪しい人間が都合よく安定して一日あたり5,60人発見できるのは不思議で、これは職務質問のノルマの存在を示唆するものである。弁護士は職務質問ノルマが存在するのではないかと考えているが、警察はこれまでにノルマの存在を認めていないのだそうだ。

私は職質をされた後も、平日は同じ帽子、同じ服装、同じリュックを背負って同じ道を同じ歩き方で通勤のために徒歩で移動している。いまだに職務質問を再現できていないが、今回の件で私は警察に職務質問をすると面倒な相手として認識されたので、今後、職務質問はされにくいであろうということであった。

最後に、裁判は時間がかかるので続報はもう少し先の話になるだろう。弁護士によれば、1年から1年半はかかるとのことであった。

2017-07-13

江添ボドゲ会 7月16日

今月も7月16日の日曜日に自宅でボドゲ会をする。場所は木場で、詳細は以下の通りconnpassで募集している。

江添ボドゲ会 7月16日 - connpass

ボドゲを毎月していきたい。

2017-07-04

警察官に職務質問をされた話

とても日差しの暑い7月、木場の自宅から銀座にある職場まで5kmの道を、5kgはある荷物を背負って徒歩で通勤していた。その日の私の出で立ちは、日焼けを防止するための大きな帽子、OD色の即乾シャツ、クライミング用のジーンズ風ストレッチパンツ、半長靴であった。勝鬨橋を超えて自販機で飲み物を買うと、急に警察官が3人近寄ってきた。

警察官「ちょっといいですか」
私「何ですか」
警察官「荷物の中を確認させていただきたい」
私「嫌です」
警察官「なぜですか」
私「応じる義務がないからです」
警察官「危険なものが入っているのではないですか」
私「入っていません」
警察官「では見せて証明してください」
私「見せる義務はありません」

このような問答がしばらく繰り返された挙句、私は出社をしなければならないのでその場を離れようとした。すると、警察官は回り込んで私の往来を妨害してくるではないか。人の往来を妨害するのは刑法に定められた犯罪である。

私「私の往来を妨害しないでください。犯罪です」
警察官「妨害していない」
私「では通してください」
警察官「まだ職務質問の途中だ」
私「すでに応じました」
警察官「リュックの中身を確認していない」
私「私に見せる義務はありません」

警察官はなおも執拗に私の往来を妨害した。私は警察手帳を出して、名前と階級を明らかにするよう要求した。警察官はこの要求に答えなければならないと法律上定められている。

3人の警察官は即座に、それぞれ警察手帳を出した。3人の警察官は、私のメモによれば、渦乃博之、井口?労人、晝?石健のような名前だった気がする。私のメモは適当に書きなぐったので細部の漢字が曖昧だ。特に?の前の文字は怪しい。3人とも階級は巡査長であった。認識番号はメモしなかった。

警察官「我々も名前を明かしたのですから、あなたも身分を明かしてください」

確かにそれは一理ある。もとより私に身分を隠すつもりはない。そこで私は予備自衛官手帳を出した。警察官はそのようなものを見ることに慣れていないらしく、私を現職の自衛官だと誤認した。手帳の表に「予備自衛官手帳」と書いてあるのに不思議なことだ。私は誤解する警察官に現職ではなく予備であることを説明した。

警察官の私の往来を妨害する行為はなおも激しくなった。私は往来を妨害して正面を塞ぐ警察官に対して、迂回をしようとしたが、迂回した方向にも回られた。その際、警察官の一人が、「公妨だ」とか、「あ、拳銃に触った」などとわざとらしく声を上げた。警察官が私の往来を回り込み、身をもって執拗に妨害しなければ、私は警察官の体に触れることはなかったし、拳銃のホルスターに手が当たることもなかっただろう。私は公務執行妨害をする意図はなく、拳銃に触る意図もなかった。

やがて、パトカーが到着し、さらに追加で6,7人ぐらいの警察官に周りを厳しく囲まれることになった。そして、最終的には脇道にある無人駐車場という私有地に移動させられた。

警察官「あなたは道の真ん中で通行の邪魔になっているから移動しましょう」
私「あなたが私の往来を妨害するという犯罪をしなければ私が道の真ん中で止まることはないのですよ」
警察官「妨害していません」
私「では私はいまから道を進みたいのですが通してくれますね。あ、移動するのは億劫でしょうから私の方から迂回しましょうか」
警察官「リュックの中身を見せてくれればすぐに通します」
私「リュックの中身を私が見せなければならない法的根拠を示していただければすぐにお見せします」
警察官「さっきから何度も同じことを言っているではないですか」
私「同じことを言っているのはあなたです」

警察官は私の往来を妨害し続けたが、往来を妨害しているということは否定した。

警察官は皆、一貫して法律にはない用語を使った。

私「私の往来を妨害するのは犯罪です」
警察官「妨害していない。現在、説得中です」
私「説得とはなんですか。どういう法的根拠があるのですか」
警察官「お願いをしています」
私「お願いとはなんですか。どういう法的根拠があるのですか」

警察官は、法的根拠について答えることはなかった。それもそのはずで、法律には「説得」とか「お願い」とかいった文言が使われているはずがない。この、「説得」、「お願い」という言葉は、複数の警官が一貫して使っていたので、おそらく警察の職務質問の訓練マニュアルにでもあるのだろう。

警察官「君には受忍義務(じゅにんぎむ)がある」

はて、「受忍義務」とは何だろうか。法律用語のようにもきこえるが、私の知る用語ではない。しかし、私は警察官職務執行法の全文を読んだことがある。その私が思い出せない用語なのだから、おそらく法律用語ではないのだろう。

警察官職務執行法

私「受忍義務とはどのような法律や判例で定められていますか」
警察官「いや、法律とか判例はどうでもいい」
私「なんと、警察官が法律や判例をどうでもいいというのですか」
警察官「違う。本官に対してではない。君に対して言ったのだよ」
私「なんと、警察官が一般市民に対して法律や判例をどうでもいいというのですか」
警察官「そうじゃなくて」

「公妨」、「あ、拳銃を触った」に引き続き、とんでもない発言が出てきた。主語がどちらにあるにせよ、この警察官は法律や判例はどうでもいいそうだ。

私「受忍義務を定めた法律や判例を教えてください」
警察官「法律や判例ではなくて、職務執行を遂行するにあたり必要であるという解釈である」
私「解釈? 法律や判例ではなく」
警察官「そうだ」
私「法的根拠はないんですね」

警察官は、嘘をつかず、受忍義務に法的根拠があるとは言わなかった。捜査に必要であるという解釈だと主張した。

ちなみに、あとで調べたところ、受忍義務とは法律用語ではなく、また直接判例によって支持されている概念でもないようだ。警察は長年、この不文律の受忍義務というものが存在するという法律の解釈を主張している。

警察官「法的根拠は職務執行法第二条に基づいています」
私「ならば、その一条にある濫用をしてならないという条項も守っていただきたい」
警察官「濫用していません」
私「では私の往来を妨害しないでいただきたい」
警察官「妨害していません。説得しています」
私「説得は非法律用語です」

そして議論は堂々巡りを繰り返す。そもそも、なぜ私が職質を受けているのか。私を怪しむに足る納得できる理由があればもちろん自発的に協力してもよい。

私「なぜ私を職務質問しているのですか」
警察官「本官が怪しいと思ったからです」
私「現在、付近で事件が起きて容疑者が逃走中ですか。それでしたら納得の行く理由ですので持ち物検査にも協力します」
警察官「違います」

警察官は嘘をつくことができないという制約がある。少なくとも、法的根拠や現在発生中の事件について、嘘をつくことはできない。後々問題になるからだ。実際、警察官は用心深く、この点において嘘をつくことはなかった。法的根拠について答えられない場合は押し黙ったり話をそらした。

私「私のどういう兆候が怪しいと思ったのですか」
警察官「うつむいて、下を向いて歩いていた」
私「うつむいて下を歩くのは犯罪ですか」
警察官「違います」
私「犯罪者はうつむいて下を向いて歩きやすいものだという統計結果はありますか」
警察官「薬物中毒者はよくうつむいて下を向いて歩くものだ。本官は薬物中毒者を多数見てきた経験論から知っている。君とは社会経験が違うのだよ」
私「薬物中毒者ならば私も以前、シェアハウスに住んでいて何人も見たことがありますが、そういう傾向はありませんでしたね」
警察官「本官は何百人もの薬物中毒者を見ている。君がみた薬物中毒者はそうでなかっただけだ」

私はこの日差しの強い炎天下の中、5kgの荷物を背負って5kmの道のりを歩いてきたのだ。疲れてうつむきがちなのは仕方がないではないか。あるいはうつむいて歩くのは私の癖かもしれない。何にせよ、下を向いて歩いているだけで怪しいというのは、私の納得できる理由ではない。日本国民は下を向いて歩いてはならないという法はない。

警察官「君は帽子を目深にかぶっていて顔が見えなかった」
私「この強い日差しの中、帽子をかぶるのは当然でしょう」

この理由も、私が納得して自発的に持ち物検査に応ずるほどの怪しむに足る理由ではない。日本国民は帽子をかぶってはならないという法は極めて限定的な状況においてしかない。例えば衆議院規則と参議院規則には議場に入る議員は許可なく帽子をかぶってはならないと書かれているが、私は議員ではないし、ここは義場でもない。

警察官「警察官に職務質問をして大声を上げ、その場から逃げようとしたのは怪しい」
私「よく訓練された私のよりも背丈の高い男が3人がかりで私の体を掴み、往来を妨害するのであれば恐怖ぐらい感じるでしょう。それに私に応じる義務はありません」

これも私が怪しい理由として納得できない。

警察官「あなたも社会人で働いているのならばわかるでしょう。リュックの中身を見せてくれればすぐにでも行ってもらって構いませんよ」

法的根拠に基づかず往来を妨害し、義務ではない行為を行うまで拘束する警察官というのは私の社会人としての常識ではわからない。

警察官「なぜ持ち物を見せないのですか」
私「見せる義務がないからです」
警察官「見せると問題になるものがあるのではないですか」
私「ありません」
警察官「では見せて証明してください」
私「見せる義務はありません」
警察官「見せて問題のないものしか持っていないのならば、なぜ見せないのですか」

この質問をした警察官は、私のプライバシー権に対する理念(隠すものがないならば全て見せてもよいという論法はなぜ間違っているのか)、憲法論、はては日本国憲法は日本国民が不断の努力で守らなければならないとしているが、日本は国民に武器を持つ権利を認めていないので現行の法律はおかしい。私はアメリカ合衆国の修正憲法第二条にある規律ある民兵の条項に賛同するものである。しかし私は法律を守る善良な日本国民であるので現行の法律にはもちろん従っていて武器は持っていないなどという私の思想を延々と聞かされることになった。

警察官「あなたは今までに軽犯罪法で捕まったことはありますか」
私「ありません。ただし私は法律のすべてを暗記しているわけではないので過去に法律に抵触した行動をした可能性はあります。しかし、仮にそうであったとしても、私に犯罪を行う意図はなかった。なぜこのようなことを言うかと言うと、マイナスドライバーを持っていただけでピッキング用具として軽犯罪法で捕まった事例を知っているからだ。今、私のリュックの中にマイナスドライバーはおそらく入っていないはずだが、私は日常的にマイナスドライバーを使うのでひょっとしたら入っているかもしれない」
警察官「あなたの場合、マイナスドライバーは正当な理由があると認めます」
私「ペーパーナイフや尖った鉛筆などは」
警察官「それも正当な理由として認めます。ここにこれだけ警察官がいるのだから変なことはしません」
私「信じたいところですが、あなたはさっき、法律や判例はどうでもいいから、と言いましたね」
警察官「そうじゃない。ほら、この警官も帽子を脱いで頭を下げますから」
私「頭を下げたその警察官はさっき、公妨とか、あ、拳銃を触った、と言いましたね」

法律は無数にあり、すべての法律に抵触しないなどおよそ無理な話だ。例えば日本国政府は公共建築物等における木材の利用の促進に関する法律に常に違反し続けている。本来、木造でもよいはずの公共建築物を木造にしないことがあるのだから。

公共建築物等における木材の利用の促進に関する法律:林野庁

やがて、現場に追加でやってきた警官は去っていった。そして最初に私に職務質問をした3人の警官だけが残った。

パラノイアというTRPGのゲームがある。基本的には理不尽な圧迫面接をのらりくらりとかわしつづけるゲームなのだが、この今の取り調べはまさにパラノイアのセッションを彷彿とさせる。ただしパラノイアと違い、警察は嘘をつけない、警察は何時間でも私を路上に拘束し続けることができるのでセッションをやめられない、という制約はあるのだが。

さて、私は警察官職務執行法をすべて読んだことがあり、パラノイアのルールブックもすべて読んでいて、GM経験もあるので、このパラノイアのセッションのような不毛な議論(私の権利が不当に侵害されているので不毛ではないのだが)をいくらでも続けられるのだが、いい加減に職務執行法の一条を守って濫用をやめるか、自発的に捜査に協力するだけの納得できる理由を提示してほしいものだ。例えば、今ここで私がナイフを持っているのを見たと言ったのであれば私は自発的に捜査に協力するだろう。というのも、私はいかように悪意をもって解釈してもナイフだとは認定できないものしか持っていないのだから、ナイフを見たと信ずるに足る理由などあるわけがなく、真っ赤な嘘だとわかる。

しかし、警察官はよく訓練されていて注意深く嘘を避けていた。存在しない法的根拠を挙げることはない。何の法律や判例の支持もない受忍義務については解釈であると正しく答える。「法律や判例はどうでもいい」とぃうのは、およそ警察官にあるまじき発言ではあるが、意見であって嘘とか本当とかいった性質のものではないだろう。「あ、銃に触った」という発言は嘘ではないのかもしれない。ただし道を塞ぐ警察官を避けようと左に移動した私の往来を妨害する形で銃のホルスターをつけている右腰を私に押し付けたので、仮に私が銃を触ったとしても、それは私の意図ではないし私に責任はない。

嘘だと私が判断した発言は、「公妨だ」、「濫用していない」、「往来を妨害していない」ぐらいなものだろうか。

さて、駐車場という私有地に停止されての職務質問は2時間弱ほど続いた。警察官職務執行法に定められている濫用というのは、一体、何時間の停止からを言うのであろうか。

結局、最終的に警察官の提案した、リュックの上から触って調べることで怪しいものがないかどうか所持品検査を行うというのが、個人的に面白かったので、その方法で検査をさせることにした。

私「そんな方法で怪しいものがあるかどうかわかるものですかね」
警察官「私にはわかります。これはなんですか」
私「万年筆ですね」
警察官「あとで壊したとか言わないでくださいよ」
私「触っていいとは言いましたが、壊していいと言った覚えはありませんね」
警察官「これは何ですか」
私「メガネケースですね」
警察官「メガネケースの中に薬物を隠すというのはよくあることです。出して見せてもらっていいですか」
私「応じる義務はありませんね」
警察官「これは何ですか」
私「ラップトップですね」
警察官「ラップトップとはなんですか」
私「ノートPCとも呼ばれていますね」
警察官「これは何ですか」
私「ラップトップのケースですね」
警察官「ノートPCのケースがこんなに小さいものですか」
私「12.6インチでとても薄いラップトップです」
警察官「これは何ですか」
私「何でしょうねこれは。ああ、コンセントですね。ラップトップのACアダプターの」
警察官「とても重いリュックですね」
私「ラップトップ2台と周辺機器が入っていますからね」

そして開放された。

そういえば、私が人生で初めて職質をされたときは、神保町に行きたくて神田駅で降りたが、行き方がわからず、その近くの交番に大きな地図が見えたので、見るために入ったときであった。ちょうど秋葉原でナイフを振り回した事件の記憶もまだ浅い時期であった。

警察官「ちょっといいですか、荷物の検査をさせてください」
私「なぜですか」
警察官「最近物騒ですからね。ちょっと前も秋葉原でナイフを振り回す事件がおきましたし」
私「これから犯罪を犯そうという人間がわざわざ交番に立ち寄るのですか」
警察官「いえ、念のため・・・はい終わりました」
私「神保町へ行くための地図を見たかっただけなのに不思議だ」
警察官「なぜ早く言ってくれないのです。道は・・・」
私「地図さえ見れればそれでいいのです」

2017-06-19

マストドンとアカウント削除機能の是非について

マストドンの1.4.1に入ったアカウントの削除機能について、friends.nicoではまさらっきがアカウント削除機能を無効にした上で、本家にもアカウント削除機能の無効化を選択できるようにするPRを投げている。

setting-for-account-deletable by masarakki · Pull Request #3852 · tootsuite/mastodon

もし、ユーザーがアカウントと全データの削除を希望した場合、ユーザーの意思を尊重するインスタンスは当然ユーザーの希望通りに全データを完全に復旧不可能な方法で削除すべきだ。しかし、人間は完璧ではないので、様々な問題が起こる。ユーザーが後から削除を取り消したいとしても、それはもう不可能だ。

特に、ハラスメントが関わると問題はややこしくなる。

ユーザーに手軽にアカウントを削除できるUIが与えられていると、垢消せハラスメントが起こる。大抵の人間は貧弱なので、ハラスメントによって発生するストレスに対処できず、ハラッサーの要求に従い、アカウントを消してしまう。後日、思い直した貧弱な人間がアカウント削除の取り消しを希望しても、ユーザーの意思を尊重するインスタンスはすでに復旧不可能な方法でデータを削除してしまっているので、不可能だ。

垢消せハラスメントは、お手軽なアカウント削除UIがユーザーに提供されていなければ起こり得ない。アカウントの削除をするには管理者である人間に連絡を取って頼むぐらいのハードルの高さがあればこの手のハラスメントは起こらない。

しかし、これは根本的に何の問題も解決していない。発言を消せハラスメントとか、もうログインするなハラスメントとか、回線切って首吊って氏ねハラスメントは依然として起こる。根本的には、ハラスメントを抑止すべきだが、そのためには全発言を事前に完璧に検閲しなければならず、そんなことは不可能だ。ハラスメントを毅然として跳ね返す強い精神力を身につけるべきだが、残念ながら、そういう強い人間は数えるほどしか存在しない。そもそもメンタルが強い人間というのは何を言われても気にしないサイコパスであることも多い。

私は人間は強い精神力を持つべきで、アカウント削除機能は手軽にUIとして提供されているべきだと考えるが、この問題は理想ではうまくいかないようだ。

ドワンゴ広告

ドワンゴではhttps://friends.nico/というマストドンのインスタンスを立てているようです。

ドワンゴは本物のC++プログラマーを募集しています。

採用情報|株式会社ドワンゴ

CC BY-ND 4.0: Creative Commons — Attribution-NoDerivatives 4.0 International — CC BY-ND 4.0

2017-06-05

ミニミニ入居安心サービスはクソだ

今いる賃貸物件は、私の嫁と大家との間に、株式会社ミニミニ中央という不動産屋が仲介に入って賃貸契約したものだ。なぜ私の名義で契約していないかと言うと、私は電話番号を所有していないため、保証会社が審査を拒否したためだ。審査に落ちるどころではない。審査の拒否だ。しかし、なぜか私の嫁名義で保証会社の審査を出したら、私を保証人に加えろと言ってきた。審査を拒否するほどの信用のない人間を保証人には加えるほど信用するのは不思議だ。

引っ越して2年たち、事前の契約通りに更新手続きの書類が株式会社ミニミニ中央から送られてきた。内訳は不動産業界の謎の慣習に従って、以下の通りだ。

  • 更新料(契約を維持して住み続けるだけで借り主がカネを払うのかよ? 更新料があるために引っ越されたら大家も家賃をとりっぱぐれて損するんだぞ?)
  • 火災保険料(俺が所有していない不動産の保険を借り主たる俺が払うのかよ?)
  • 保証料(家賃不払いのリスクを負うのは大家なのに保険金は借り主たる俺が払うのかよ?)
  • ミニミニ入居安心サービス料 16200円(なんだこれ?)

他の名目のカネはまだ納得できるとしても、「ミニミニ入居安心サービス」なる名目のカネは謎だ。一体何なんだこれは。

契約書類についてきたパンフレットによれば、「ミニミニ入居安心サービス」なるものは、以下のようなサービスらしい。

  • ホテル、飲食店、レジャー施設、レンタカーなどの割引クーポン(いらね。使うつもりもない)
  • 24時間365日対応の無料の相談コールセンター(後述)

結論として、この「ミニミニ入居安心サービス」は全く何の意味もないクソで、デフォルトopt-outで無効から提示されたとおりの契約で契約するしかないと思いこんでいるバカからカネをむしり取るための罠だった。

コールセンターは何の薬にも立たない。鍵とか水回りとか電気周りのトラブルの際に連絡すると、業者を派遣してくれるだけのサービスだ。業者はもちろん有料だ。

さらに、その内容も本当に意味がない。例えば、電気のトラブルで何をするかと言うと、ブレーカーの上げ下げだけだ。パンフレット曰く、

ブレーカーの仮復旧で解決しない、建物設備に関するトラブルは、大家様または管理会社様にご連絡ください。

何の意味もない。

そもそも、我々は単なる借り主であり、不動産を所有していない。不動産の不具合を修正するのは当然、大家の金で行うべきだ。仮に我々の金を使って建物を修繕、改修するとしてもだ、我々が所有していない不動産なのだからまず大家に交渉するだろう。

実際、この2年間住んでいて色々と電気周りの不具合には見舞われている。たとえばエアコンがショートしたため、エアコンのブレーカーを上げると即座にブレーカーが落ちる不具合があったので、これは大家にエアコンを取り替えさせた。また、新品の蛍光灯に取り替えても何故かある箇所の電灯が不意に消える不具合があったので、これも直させた。いずれも大家に交渉した上で、大家が契約している業者が作業に当たった。

するとこのコールセンターの価値はなんだろうか。

また、このサービスには、パソコンの不具合対応とかストーカー相談とか、やはりこれまた役に立たなそうなサービスがある。パソコンの不具合対応はもちろん業者に連絡するだけだ。

また、盗難時の補償というのもあるが、これはどうも盗難にあった時に引っ越す際の引越し費用を補助するだけで、盗難被害額の補償ではないようだ。そもそも盗難にあった時に引っ越しをするだろうか。執拗に付け狙われていて小物がちょくちょく盗難にあうとかいうストーカーのような盗難ならまだしも。

というわけで、ミニミニ入居安心サービスを我々は利用していないし、今後も利用するはずがないことが確認できた。これは大家ではなくて不動産屋である株式会社ミニミニ中央との契約になるので、早速交渉に入る。交渉には不動産屋の大好きな旧世紀の連絡手段である電話が用いられた。

「契約更新にあたり、ミニミニ入居安心サービスはいらない」
「ではその料金を含まない額をご入金ください。キャンセルしておきます」

何の抵抗もなく、間髪を入れずにこのような対応となった。ますます怪しい。

おそらく、これはデフォルトopt-outな契約にして、提示された契約をそのまま飲まざるを得ないと思っている情弱を騙して金を余計にむしり取るためのいやらしい手段に違いない。私のミニミニに対する信用が一気になくなった。とりあえず今は継続して済むとして、いずれ引越し先を探すことにしよう。

2017-06-02

江添自宅ボドゲ会6月11日

6月11日に自宅でボードゲーム会を開催することにした。

江添ボドゲ会6月11日 - connpass

最近のお気に入りのボードゲームとしては、電力会社のカードゲーム版やナショナルエコノミーメセナがある。

2017-05-11

constexpr ifの落とし穴

会社の同僚から、以下のようなコードが動かない、ネット上をググると解決策らしきものが見つかるがそれもいまいち納得できない、という相談を受けた。

template < typename T >
void f()
{
    if constexpr ( std::is_same<T, int>{} )
    {
        // Tがintのときのみ発動してほしい
        // 実際は常に発動する
        static_assert( false ) ;
    }
}

C++17にはconstexpr ifが追加された。これは条件付きコンパイルではない。条件付き実体化抑制だ。

constexpr ifは以下のように使う。

struct S
{
    int value() { return 42 ; }
} ;

template < typename T >
int to_int(T t)
{
    int value{} ;
    if constexpr ( std::is_same<T, S >{} )
    {
        value = t.value() ;
    }
    else if constexpr ( std::is_integral<T>{} )
    {
        value = static_cast<int>(t) ;
    }

    return value ;
}

int main()
{
    f(42) ;
    S s ;
    f( s ) ;
}

to_intは引数からint型の値を取り出すための関数だ。クラスSの場合、int型を取り出すためにメンバー関数valueを呼び出す特別な処理をする。

これをみると、constexpr ifは条件付きコンパイルのように思える。つまり、if文によって選択されるブランチのみをコンパイルする機能だ。しかし、それは間違いだ。

constexpr ifは選択されないブランチのテンプレートの実体化を抑制する機能だ。

テンプレートは、まず宣言を解釈され、その後、具体的なテンプレート実引数を与えられて実体化する。

template < typename T >
void f( T t )
{
    t.func() ;
} 

int main() { }

この例では、Tにint型を渡すとエラーとなる。なぜならばint型はメンバー関数funcを持っていないからだ。

しかし、この例はコンパイルエラーにならない。なぜならば、テンプレートfのテンプレート実引数にint型は渡されていないからだ。

テンプレートは、具体的な型をテンプレート実引数として渡され実体化して、初めてコードが正しいかどうか検証される。

というのは間違いで、テンプレートは宣言の時点でもコードが正しいかどうかを検証される。

template < typename T >
void f(T t)
{
    // エラー、名前gは宣言されていない
    g( 0 ) ;
}

template < typename T > void g( T ) { }


int main() { }

この例はエラーになる。なぜならば名前gは事前に宣言されていないからだ。C++は名前を使う際には、事前に明示的な宣言を求める言語だ。

しかし、以下のような例はエラーにならない。


template < typename T >
void f()
{
    // エラーではない
    T::g() ;
}

これはなぜかと言うと、名前T::gはテンプレート仮引数Tに依存しているからだ。テンプレート仮引数Tに依存している名前は、Tの具体的な型が与えられるまで、コードの合法性が検証できない。そのため、そのようなコードの検証はテンプレートの実体化まで遅延される。

まとめると、テンプレート仮引数に依存しないコードはテンプレートの宣言時に検証され、依存するコードはテンプレートの実体化時に検証されるということだ。

これを踏まえて、以下のコードが動かない理由を考えてみよう。


template < typename T >
void f(T t)
{
    if constexpr ( false )
    {
        // エラー、名前gは宣言されていない
        g() ; 
    }
}

名前gはテンプレート仮引数に依存していないため、テンプレートの宣言時に検証される。その結果、エラーとなる。

ここまでくれば、冒頭のコードが意図通りに動かない理由もわかるはずだ。

template < typename T >
void f()
{
    if constexpr ( std::is_same<T, int>{} )
    {
        // Tがintのときのみ発動してほしい
        // 実際は常に発動する
        static_assert( false ) ;
    }
}

static_assert(false)はテンプレート仮引数Tに依存していないため、テンプレートの宣言時に検証され、エラーとなる。

ではどうすればいいのか。たんにstatic_assertの中にconstexpr ifと同じ式をいれてやればよい。

template < typename T >
void f()
{
    static_assert( std::is_same<T, int>{} ) ;

    if constexpr ( std::is_same<T, int>{} )
    {
        // ...
    }
}

しかしこれは同じ式が重複してよろしくない。式を変えたいときは二箇所を同時に変更しなければならない。

式の重複を防ぐには、変数を使ってやればよい。

constexpr bool cond = expr ;
static_assert( cond ) ;
if constexpr ( cond ) { }

しかし、if文というのはネストさせたいものだ。

if constexpr ( E1 )
    if constexpr ( E2 )
        if constexpr ( E3 )
        { }
        else if constexpr ( E4 )
        {
            // static_assertしたい。
        }

このような複雑なネストしたif文に相当する式を書くのは面倒なので、constexpr ifの中に入れて、そのブランチが実体化されるときのみstatic_assertが働くようにしたい。

そのためにはどうすればいいかというと、static_assertのオペランドの式を依存式にすればよい。そうすればテンプレートの実体化まで評価を遅延させることができる。constexpr ifに囲まれていてテンプレートが実体化しないのであればstatic_assert(false)も発動しない。

using < typename ... >
constexpr bool false_v = false ;

template < typename T >
void f( T t )
{
    if constexpr ( std::is_same<T, int>{} )
    {
        static_assert( false_v<T> ) ;
    }
}

false_vというのは任意の型を取って常にfalseを返すテンプレートconstexpr変数だ。このテンプレートにテンプレート引数を与えてやれば依存させることができる。結果として、この関数fはTがint型のときのみstatic_assertを発動させる。

現在書いているC++17の参考書には、このような落とし穴も含めたC++17の新機能の解説を書いている。なるべく早く書き上げたい。そして、最近、C++の規格を学びすぎたために、こういうC++の初心者が陥りがちな落とし穴が何なのか自分ではわからなくなってしまっている。C++の落とし穴を教えてほしい。

2017-05-10

Rustのパッケージマネージャーでパッケージ名nulを作ったら全Windowsユーザーのパッケージマネージャーが壊れた話

How I Broke Rust's Package Manager for All Windows Users - sasheldon.com

非Windowsユーザーが何気なくRustでnulという名前のパッケージを作って公開した。すると、全Windowsユーザーのパッケージマネージャーが壊れた。

理由は、nulという名前はWindowsでは予約語だからだ。Win32サブシステム経由で、どのディレクトリであれ、nulというファイル名を使おうとすると、それはGNU/Linuxでいう/dev/nullと同じような扱いになる。nulに拡張子がついていても同じだ。

RustはWindowsサポートも重視しているので、これに対処してWindowsの予約語を禁止する変更がなされた。

Reserve windows crate names. by withoutboats · Pull Request #695 · rust-lang/crates.io

これはWindowsがクソだが、他のOSでもファイルシステムには様々な技術的な柵がある。例えばMac OSのファイルシステムはUnicode正規化が特殊でクソだし、POSIXの多くのコマンドは-をSTDINやSTDOUTとして特別扱いする。また、bashは/dev/tcp/host/portというファイル名でhost:portに対するTCP接続を行う。

マイクロソフトのWindowsに付属しているアンチマルウェアソフトウェアが最高にクソな件

マイクロソフトのWindowsに付属しているマイクロソフトが提供しているアンチマルウェアソフトウェアに脆弱性が発覚した。

1252 - MsMpEng: Remotely Exploitable Type Confusion in Windows 8, 8.1, 10, Windows Server, SCEP, Microsoft Security Essentials, and more. - project-zero - Monorail

脆弱性の発覚はよくあることだ。脆弱性というのは、大抵はバッファーのサイズチェック漏れなどの些細な間違いが原因となる。

今回のMSのアンチマルウェアの脆弱性も、根本的な原因としてはそのようなチェック漏れなのだが、起こるべくして起こったクソすぎる実装のせいで、そのような些細な間違いが実用的な脆弱性に発展してしまっている。そのようなチェック漏れが存在するだけでは実用的な脆弱性に発展しない。そのチェック漏れを悪用できるようなコード実行ができる状況が存在することで、実用的な脆弱性に発展する。

MSのアンチマルウェアソフトウェアには、NScriptというJavaScript風のインタープリターが入っている。これによってあるJavaScriptコードが既知の悪意あるソフトウェアのパターンに一致するかどうかを調べている。JavaScriptはいくらでも同等内容になるように変形可能なので、実際に実行しなければパターンに一致するかどうかわからない。したがってこのように実際に実行して挙動がパターンに一致するかどうか調べる仕組みが必要になる。

問題は、このインタープリターは極めて強い権限で実行され、サンドボックス化もされていない。これはセキュリティソフトウェアとして問題外の実装だ。任意の悪意ある可能性があるコードの挙動を実際に実行して調べるのに、不必要な権限の放棄や適切なサンドボックス化を行っていないのはありえない。

かつ、MSのアンチマルウェアソフトウェアはファイルシステムの変更を監視していて、ファイルシステムのどこに書き込まれようと、JavaScriptっぽいコードは全部、このNScriptインタープリターで実行して、パターン検出を行おうとする。これは任意のブラウザーなどのソフトウェアのキャッシュなどにも対応できるための実装だ。しかし、これによって、ファイルシステムにさえかきこめれば、どのような方法であっても脆弱性をつくコード実行が可能になる。

結果として、マイクロソフトのアンチマルウェアの脆弱性を悪用するには、悪意あるJavaScriptコードをメールで送る、Webブラウザーで閲覧させるなどの何らかの方法で、ファイルシステム上に書き出させればよい。ユーザーがメールを実際に閲覧するとかソフトウェアを実行するといった操作は必要がない。

あるJavaScriptコードが悪意あるものであるかどうかを実際に実行して調べるセキュリティ対策のソフトウェアが存在するせいで強い権限による任意のコード実行につながるというのは、極めて皮肉だ。

私が平生から主張しているように、アンチマルウェアソフトウェアというのは詐欺だ。使ってはならない。アンチマルウェアソフトウェアはセキュリティではない。世の中のすべてのアンチマルウェアソフトウェアは実装がクソだ。アンチマルウェアソフトウェアを使った人間

「追加のソフトウェアは追加のリスク」という古き良きシステム管理者の格言はなぜ失われてしまったのか。

超会議2017でマストドンブースの運営スタッフをした

私は江添亮、ドワンゴ社員だ。超会議2017で運営スタッフをした。このブログ記事は個人的なものだ。株式会社ドワンゴの見解ではない。こう書かなければならないのは悲しいことだ。結局、国語教育で存在しない作者の意図を答えさられた人が多いようだ。ちなみに、この文章はマストドンとfactorioがやりたくて仕方がない合間を縫って後ろ髪を引かれながら書いた。もし将来、この文章を使って「作者の意図を答えよ」という問題が出題されたときには、「作者はマストドンとfactorioの中毒者であるが我慢しながらこれを書いた」と答えるのが正解だ。

超会議2017リハーサル

概要 | ニコニコ超会議2017 公式サイト

超会議2017での私の割当は、神エクセル方眼紙で公開された。自由な表計算ソフトウェアであるLibre Officeでみてみると、私はゲームエリアにアサインされていた。

やった。事前に提出した希望通りだ。ああ、入社して苦節3年、ようやく希望通りのアサインが行われた。ハッカソンやら馬車やら焼きそばやらと、私は常に変わった場所に割り当てられていた。それがようやく、ゲームエリアのアナログゲームブースでボードゲームのインストをするスタッフになったのだ。今度の超会議では好きなボドゲのインストができる。

そして、ドワンゴがマストドンのインスタンス、friends.nicoが公開された。そして全てが変わってしまった。

マストドンは面白い。なるほど、マストドンは技術的にはクソだ。しかし面白い。しかも自由だ。マストドンには未来がある。Twitterの時代は終わった。これからはマストドンが圧倒的に流行する。既存の不自由なSNSは滅びる。

そして、超会議開催の直前の土日に、マストドンブースの設営が決定された。これは行くしかない。強引に根回しをしてブースのリアサインをする。ああ、せっかく希望通りのボードゲームのインストスタッフになれたのに。いやしかしこれもマストドンのためだ。

超会議前日、リハーサルのために幕張メッセに行き、マストドンブースを確認する。いかにも急造したらしきブースがぽつねんとある。大きめのディスプレイがあり、friends.nicoのLTLをニコニコ動画風の右から左に流れるコメント形式で流している。

私は引き戸になっているブースの下を改めた。ここがマストドンブースであるならば、当然あるはずだ。人権が、インターネット回線が。あるはずだ。果たしてEthernetポートはあった。ある。人権がある。当日はライブマストドンができるぞ。

マストドンブースの確認と、ユーザー記者の控室などにマストドン体験端末の設置などの雑用をする。あとは超会議のリハーサルの体験だ。

超人スポーツのジャンピング竹馬が面白かった。アマゾンで中国製が2万で売られているので、即座に購入した。届くのが楽しみだ。ただし、これはだいぶ危険なので、プロテクターとヘルメットを用意した上で、受け身の練習もしなければならないと思っている。

そして、マストドン会議に参加した。

本の虫: マストドン会議で技術と自由を語る

マストドン会議ではマストドンの実装とプロトコルの設計がいかにクソか、そして自由の素晴らしさを語った。

マストドンは自由だ。自由は素晴らしい。

TwitterはTwitter社が独占している。そのため、Twitterがお前のアカウントをBANすると言ったならば、お前のアカウントはBANされる。お前の相撲取り画像は肌色成分が多いのでエロ画像だと言われたならば、それはエロ画像だ。Twitterに逆らうことはできない。

マストドンでは誰もがインスタンス(サーバー)を立てられる。あるマストドンの運営が「お前の相撲取り画像は・・・」などと馬鹿なこと言い出したら、そんなインスタンスは使わなければよい。どのインスタンスも機に食わなければ、自分でインスタンスを立てればよい。自由を保証するには拒否できる力が必要だ。

これは政治家や政党にとっても都合がいいだろう。ご存知の通り、アメリカ大統領選挙ではTwitterやFacebookが恣意的な検閲を行い、トランプとヒラリーのどちらかに有利な検閲を行った。マストドンではこういう恐れがなくなる。政党や候補者自らインスタンスを立てればよいのだから。

近々マストドン会議2が行われるらしく、ドワンゴからも2人ほど発表するそうだ。なんとか次も発表枠で潜り込めないか交渉している。

超会議

超会議では、私はひたすらマストドンブースに張り付いてマストドンの宣伝を行った。

マストドンブースは超演奏してみたブースの向かい側で、始終うるさかった。なかでも特に多くかかった音楽は、けものフレンズの主題歌と、逃げるは恥だが役に立つの主題歌だった。

超会議では様々な人間がマストドンブースを訪れた。特に印象深かった人間が何人かいる。

マストドンブースにほぼ張り付いていた人間がいた。マストドンの中毒性を考えればコレは当然のことだ。

マストドンをしていて、しかもプログラミングのできる中学生や高校生がやってきた。私は自由なコンピューターの必要性を説いた。プログラミングをするには自由なコンピューターが最も便利だ。不自由なコンピューターではろくなコードが書けない。第一、不自由なOSはその動作を確認できないし、改造もできない。

ある中学生は、プログラミングに興味があるが、いまは不自由なコンピューターであるスマフォしか持っていないといった。私はぜひとも自由なコンピューターを買い、その上の自由なOSをインスールして、プログラミングを本格的に学べと教えた。その子はママに相談すると言って帰っていった。

お母さん、息子の将来のためにはプログラミングができるべきだ。そのためには自由なコンピューターを使うべきだ。

ある高校生はRaspberry PiにDebianを入れて使っているという。ああ、私が高校生の頃にRaspberry Piがあればなんと良かったことだろうか。今の子どもたちは恵まれすぎている。そんな恵まれた環境で育った子どもたちが社会に出る頃には、我々のような老人プログラマーは皆、戦力外通告を受けることだろう。未来は明るい。

マストドンブースに来た政治家達

重ねて書くが、これは私の個人的なブログであって私が雇用されている会社の見解ではないし、書かれている以上の「作者の心情」とか「作者の意図」を見出してはならない。

さて、超会議ではマストドンブースに二人の政治家が来た。政治家であるという理由だけでわざわざ書くというのは、これから私が主張する内容と矛盾する。しかし彼らは政治家であるために例外的な対応を求めたので、例外的に書いてもいいだろう。

東京都知事の小池百合子

急に、マストドンブースにスーツが近寄ってきて、「都知事の小池百合子がまもなくやってくる」と私に告げた。私は事前に連絡を受けていない。上司に連絡を取ると、「把握している。小池百合子のスケジュールは警備上の理由で秘密である」と告げられた。

やがて、怒涛のように小池百合子とその取り巻き御一行様がやってきた。まるで北朝鮮の総書記の視察を受けているかのようだ。小池百合子の周りをスーツが厳しく取り囲んでいる。その中心に光るように目立つ小池百合子。一触即発のアトモスフィア。スーツのうちの何人かは物理的なペンと物理的な紙のメモ帳を手にして激しく首を縦に振りながら何やら一心不乱に書き込んでいる。上司が小池百合子にマストドンの説明をする。そして、小池百合子が去っていった。まるで嵐がやんで晴れ渡ったかのような安堵感が広がる。

これは文化に対する理解と尊敬がない。超会議は誰であれ身一つでそのへんをフラフラと歩いて楽しむべきだ。実際、有名人が何人もそれと気づかれずにフラフラと周りを歩いているのを私は何度も目撃している。小池百合子の査察を受けている間、そのホールは厳しい警戒態勢になり、乗合馬車なども待機を余儀なくされた。都知事ともなると身辺警護が厳しいのはわかる。それはわかる。しかし、文化への尊重も必要だ。

民進党の枝野幸男

超会議2日目の開始直後、急に、マストドンブースにスーツが2,3人ほど近寄ってきて、「これから・・・のユキオが来る」と私に告げた。はて、一体何のユキオだろう。周りが騒がしくて聞き取れない。重ねて聞くが、やはり「・・・のユキオ」としか聞き取れない。名前よりもその役職のほうが重要だ。私はその名前を知らない可能性のほうが高いのだから。

スーツが去ろうとするので慌てて呼び止めて再度聞くと、今度は、「エダのユキオです。政治家の」と答えた。エダのユキオ・・・、なるほど、助詞の「の」ではなく、民進党の枝野幸男(えだのゆきお)か。

もし枝野幸男本人が何も根回しをせず無名の一般人としてやってきたのならば、私も通常通りマストドンの説明と、マストドンのソフトウェア実装が自由であることの価値を説いただろう。しかし、そのような特別対応を求めるのであれば、やはり私としても上司に連絡をする。

上司からの返事がないまま、スーツが再びやってきた。「今から15分後に枝野幸男が来る」ということを私に告げた。

スーツ曰く、「枝野幸男はマストドンにアカウントを作ることを所望している。いまブースに設置してるコンピューターで枝野幸男のマストドンのアカウントを作ることは可能か?」

可能か? 技術的にはイエス。セキュリティ的にはノー。もちろん答えはノーだ。

自分のアカウント登録は自分の所有するコンピューターで行うべきだ。なにしろ、メールアドレスへのアクセスが必要なのだから。

程なくして枝野幸男本人がマストドンブースにやってきた。物々しい目立つ護衛や取り巻きはいない。上司も間に合う。上司が枝野幸男にマストドンの説明をする。

枝野幸男は文化を理解していた。枝野幸男のマストドンのアカウントの名前は本名ではない。かつ、本業には言及しない。それでいい。自分の管理していないインスタンス経由でマストドンに参加するのであれば、無名の一般人として参加すべきだ。そしてどうでもいいバカなことをつぶやくべきだ。そして、他人も本人の意志を尊重し、わざわざ本業についての質問をぶつけるような無粋なことをするべきではない。民進党の政治家、枝野幸男として意識の高い発言をするのであれば、自分でサーバーを建てるべきだ。なぜならば、自分の管理するサーバーは一番信頼できるからだ。

このブログを書いている今も、枝野幸男はわかる人にだけわかる本名ではない名前で、政治家としてではなく一個人として、マストドンで雑談をしている。このまま続けたいだけ続けて、やめたいときにやめるべきだ。

マストドンの保証する自由は、政党や政治家にも利点がある。なぜならば、自らサーバーを立てて情報を発信することで、マスメディアによる脚色のない一次情報を自ら発信できるからだ。

マストドンでは誰でもインスタンス(サーバー)を建てることができる。どのインスタンスを経由してマストドンに参加しているかを意識する必要はない。TwitterやFacebookのように、サーバーを独占され、唯々諾々と決定に従うしかない不平等で不自由な時代は終わった。これからはマストドンの時代だ。

2017-05-05

5月7日に江添ボドゲ会をやるかも

江添ボドゲ会5月7日 - connpass

5月7日に木場にある江添の自宅でボドゲ会を開くかもしれない。connpassで4人集まれば開く。詳細は上記connpassリンクを参照のこと。

2017-04-29

マストドン会議で技術と自由を語る

マストドン会議というものがあり、清水亮も登壇するというので行ってきた。

マストドン会議 ―― その無限の可能性を、いま語らずしていつ語らう! ~コミュニティもマーケティングも揺るがすTwitterのライバル出現~ | Peatix

マストドンは日本ではやってからまだ2週間しかたっていない。一体そんな状況で誰が集まるのだろうか。主催は角川が絡んでいるらしいが、まあ、あまり期待はせずに行くことにした。

その日は来るべき超会議2017のリハーサルの日だった。会場の幕張メッセではマストドンブースが設営されていた。私が担当なので当然私も現地にいた。そして少し遅れてマストドン会議の会場に着いた。清水亮は私よりも更に少し遅れて会場入りした。

会場に入ってみると、ぬるかる氏のmastdn.jpにサーバーを提供しているさくらインターネットの人とぬるかる氏が、サーバーの運営上の話をしていた。とても技術的な話だった。よかった。技術の話をしている。これが、「えっとぉ、マストドンはぁ、やっぱりぃ、Twitterをオープンなプラットフォームに持ってきたってところがいいと思うんですよねぇ。ユーザーがソーシャライズされてぇ」などと宣うアホで埋まっていたら会場に向かうまでの時間が圧倒的に無駄であった。何しろ、明日は超会議2017のマストドンブースのために、早朝に会場入りしなければならないのだから。

mastdn.jpの運営は技術的な話と、違法な発言を削除したり犯罪的な名誉毀損発言を繰り返すユーザーをBANしたりといった管理上の話だった。

私がぬるかる氏が話すのを見たのはこれが初めてだが、想定していた人物像と印象と全く違った。私が想定していたぬるかる氏は、陰鬱で物憂いナード青年だった。しかし、この壇上ではなすぬるかる氏はどうだろう。120人の聴衆を前に、一切物怖じせず、言い淀まず、冷静にゆっくりと話を続ける。ぬるかる氏何者?

読者は100人の聴衆の前で話ができるだろうか? 私はできる。私はそれだけの場数を踏んでいて経験があるからだ。私は十分に経験を積んでいるのでストレス耐性があり、緊張することはない。しかし、一度もそのような経験のない一般人は、100人の聴衆を前に事前にほとんど準備も練習もなしで話などできるはずがない。しかるに、ぬるかる氏はほとんど準備も練習もできなかったはずなのに、この冷静さ。ただものではない。

ぬるかる氏が話す途中で、第一部が終わった。

その後、津田大介が誰でも言えるようなくだらない一般論をのたりくたりと話し始めた。一体何なんだこいつは。というよりなんで津田がここにいるのだ。津田はマストドンで何かしたのか? というかお前、最近見かけないな。

津田はラリホーでも唱えているかような眠気を誘うどうでもいい話を延々と行う。誰か津田を止めろ。違うだろ。本当に自由の価値を追求する人間は「オープン」なんて言葉を使わない。秋葉原のオタク文化をいきなり語りだしてどうした。どうでもいいだろ。

技術の話をしろ。

結局、津田という人間はこういう人間なのだろう。かつて、津田が勉強会に参加して登壇者の発言をTwitterで要約して流すという行為に「Tsudaる」という言葉が割り当てられた。それは真実だったのだ。津田というのは人の話を要約して議事録を作成するには向いているのかもしれないが、自分の意見を語りだすとこうもどうでもいい一般論ぐらいしか語れない人間なのだ。

と、こう考えているうちにも津田が延々とのたりくたり。もういいから津田を黙らせろ。ぬるかる氏に話をさせろ。

というところで、清水亮に話が振られた。これは正解だった。清水亮は今まで胡散臭いポエマーだと思っていたが、ただこの業界でやっているだけある。一瞬で雰囲気を激変させた。

清水亮は、まず他の登壇者を退場させた。

「お前ら一旦ハケてくれる?」と。

この一言で、会場の空気は完全に津田の辛気臭い話から怒涛のプレゼンスタイルに激変することになる。

清水亮が話す。声が大きい。津田のラリホーで眠っていたものも叩き起こすような声だ。清水亮の話も、結局誰しもが考えるものである。

  1. TwitterやFacebookでは本音で話ができない。バカな発言をすると炎上する。というか家族が見ている。マストドンでは本音で話ができる。
  2. ユーザーが犯罪予告、わいせつ物、名誉毀損などの発言をしたら削除する必要があるし、BANする必要もある。この管理を人間がやるのはダルい。AIにやらせるべきだ。
  3. マストドンの今の秘密会話は全然秘密ではない。インスタンスがユーザーの意思を尊重して秘密にすることに依存している。アリスとボブが秘密の通信をするときはそれぞれローカルで公開鍵暗号を使って安全に鍵交換を行って暗号文でやり取りすべきだ。

たしかこの程度のことを話したはずだ。これはどれもいまさら言うでもない当然の話で、一般論に過ぎない。しかし清水亮のプレゼン力は優秀で、聞いているものを叩き起こした。

そして私に話が振られる。この流れはよい。大声で話すことならば私とても心得ている。準備とても何もないが、津田がのたりくたりと話している間にmarkdownで書いた数枚の話す要点だけメモ書き程度に書いたものがあったので、これを急ぎpandocでreveal.jsに変換してスライドとする。

技術

まず技術の話だ。ここにきてプログラマーとして登壇して技術の話をしないのはタイヘンシツレイにあたる。

マストドンは技術的にはクソである。

  1. マストドンは教科書的なRuby on Railsで実装されている。つまり富豪的プログラミングだ
  2. マストドンはReactで実装されている。我々がHTMLとCSSとJavaScriptを分離してきたのに全部一緒くたにしてしまう。これではPHPに逆戻りだ。しかも生成されたDOMがクソだ
  3. マストドンの元となったGNU Socialは流行らなかった。その理由はOStatusプロトコルにある。
  4. そもそもOStatusプロトコルのドキュメントがない。存在しない。ネットから消えている。Internet Archiveは我々の友達だ。
  5. OStatusプロトコルはスケールしない。リモートフォローによってインスタンス同士のプッシュ通知で大量にトラフィックとストレージを浪費する

そのため、私はプログラマーとして技術的に判断を下した結果、「マストドンはクソだ」と結論した。

本の虫: そろそろマストドンについて語っておくか

しかし、内部実装が技術的にクソかどうかと、利用者にとって面白いかどうかは、全く関係のない話だ。マストドンは面白い。それは純然たる事実である。スケールしない問題など、インフラを分厚い札束で殴ればいいのだ。

自由

さて、技術について語ったので、次は自由について語る。

まず、そもそも会場の聴衆がどれだけ自由なソフトウェアについて知っているのか。自由なソフトウェアについて知らないならば、その解説から始める必要がある。

「GNUを知っている者は挙手せよ」

なんと、ほとんど全員の手が上がったではないか! なんということだ。聞き間違いではないか。いや、文字に起こせばGNUだが、口頭でいうと「ぐにゅー」だ。そんなへんてこなものを何かと聞き間違えるはずがない。ああ、なんということだ! RMSの地道な活動はついに実を結び、ついにGNUを誰もが知るところとなったのだ。自分は今、猛烈に感動している。

全員、GNUを知っているとなれば話は早い。自由なソフトウェアについて説明する必要はない。

さて、我々のソフトウェアは、RMSとFSFとGNUによってほぼ自由になったが、自由に対する新たな脅威が持ち上がっている。SaaS(Software as a Service)だ。

SaaSとは、例えばGMailであったり、Google Docsであったり、あるいはTwitterやFacebookなどだ。今や、ほとんどのWebサイトはSaaSといってよい。

我々がWebサイト上で何かをするとき、その処理の大半自分の所有するローカルのコンピューターではなく、サーバーが行っている。我々はサーバーを所有していないし、サーバーを支配していない。ということは、我々のローカルのコンピューターは自由かもしれないが、サーバーは自由ではない。そして、今や処理の殆どはサーバーで行われている。

これは非常に辛い問題で、我々が所有も支配もしていないコンピューターは、我々の自由にならないのは当然の話だ。私のコンピューターは私の所有しているものであり私が支配している。私のコンピューターが他人の意思で私の望まない処理をされてほしくはない。その理屈で、我々はサーバー側に自由を求めることができない。自由はコンピューターの利用者にかかるもので、サーバーのコンピューターの利用者は、我々ではないからだ。我々は利用者の慈悲によって処理を肩代わりしてもらっているだけだからだ。これはGPLでもどうしようもない。

そこで、AGPLだ。AGPLはGPLと非互換なライセンスで、サーバーに対しても適用される。AGPLなソフトウェアをサーバー上で動かして、それによってサーバーが提供するサービスの利用者には、AGPLに従ってサーバーで動くソフトウェアを自由にしなければならない。つまりユーザーに対してソースコードを公開しなければならないし、その気になればユーザーが全く同じ互換サーバーを立ち上げることも可能になる。

マストドンのライセンスはAGPLである。

そして、マストドンは流行った。ぬるかる氏が2週間前にマストドンのインスタンスを立ち上げてからというもの、この日本で圧倒的にマストドンが流行した。すると、個人や企業が先を争ってマストドンのインスタンスを立てたがる。しかし、そうやって立てる? それにはマストドンを使うしかない。マストドンはAGPLだ。AGPLにしたがってソースコードを公開しなければならない。もし、自分のインスタンスに何らかの改変を加えた場合、それも正直に公開しなければならない。

マストドンの互換サーバーを独立して実装すれば、そのソフトウェアは自分の好きにできる。しかし、そのようなソフトウェアを開発すには、半年、1年、場合によってはもっとかかる。今、この瞬間にマストドンのインスタンスを立ち上げるには、マストドンしかない。ところでマストドンはAGPLである。

この状況は、社内政治などをすっ飛ばしてAGPLを強制させた。いまマストドンを建てないと流行に乗り遅れる。その機会損失と、未だに根強い自由ソフトウェアへの抵抗を天秤にかけて、機会損失が勝ったのだ!

今や、プロプライエタリな製品を販売していた不自由な企業まで、先を争ってAGPLなサーバーを立てるようになったのだ! なんという素晴らしい世界だろう。一体どんな奇跡が起こったというのだ! 私は信じられない光景を目にしている。ああ、自由が尊重されている!

そう、すでに変化はドワンゴ社内にも起こっている。自由ソフトウェアの忌避はドワンゴとても例外ではない。結局社内のリソースを割いて書いたコードを表に出すには、色々と社内政治や偉い人たちの判断などが必要になる。マストドンは最初からAGPLなので、もはや社内政治などと言っている場合ではない。自由になるか、使えないかだ。

そして、本当に奇跡のような展開が起こる。

ドワンゴのエンジニアであるまさらっきが、マストドンに脆弱性を発見したので、修正するPRを送った。

use Twitter::Extractor for creating links by masarakki · Pull Request #2502 · tootsuite/mastodon

すると、マストドンの開発者のオイゲンが、ABCanGを呼び出して、問題を見るように指示する。ABCanGはPixivのエンジニアである。なぜPixivのエンジニアが呼ばれるのかと不思議に思ったら、どうやら該当部分を実装したのはABCanGだそうだ。なるほど、納得だ。

しかし、実はこれは画期的なことである。

そもそも、ドワンゴとPixivはお互いに競合するサービスを提供している企業である。Pixivは絵の投稿サービスを提供していて、ドワンゴもニコニコ静画などの絵の投稿サービスを提供している。このため、基本的に両社は商売敵である。

一時期、Pixivはニコニコ静画へのリンクを検閲するというような強硬な処置さえ行った。

『pixiv』にニコニコのURLを貼ると「有害サイト」として削除される!? ニコニコ担当「非常に残念」 | ガジェット通信

その犬猿の仲であるPixivとドワンゴが相手の不具合を修正して助けているだと。ああ、自由の価値ここに極まれり。

自由は素晴らしい。

しかし、この自由が今、脅かされつつある。スマフォアプリだ。

そもそもスマートフォンは不自由なコンピューターである。iPhoneもAndoridも不自由だ。しかも、AppleやGoogleが提供するアプリの流通プラットフォームは、利用者に不自由なEULAへの同意を求めるので、GPLと互換性がない。スマートフォンを使う時点で不自由で、配布されるアプリも不自由だ。スマートフォンは不自由の塊なのだ。

そして、マストドンのにわかの流行により、雨後の筍のようにぽこぽことマストドンクライアントアプリがストアに並び始めている。いま開発中のものも大勢いるだろうから、今後はもっと増えるだろう。

しかし、よく考えてもらいたい。マストドンは自由だ。自由の価値は素晴らしい。その自由をあえて放擲するのか。不自由なクライアントで閲覧するマストドンは美味いか?

不自由なコンピューターであるスマートフォンの利用は拒否すべきである。

Twitter独占の弊害

なぜマストドンはTwitterより優れているのか。それは、誰もがマストドンのインスタンス、つまりサーバーを建てられるからである。Twitterではこうは行かない。

Twitterでは、Twitter社は正しい。Twitter社の判断は正しい。もしTwitter社がユーザーをBANしたのならば、もちろんそれは正しい。疑問を差し挟むことは許されない。Twitterの判断を疑うことは反逆でありBAN対象である。そのスモーレスラーの画像はわいせつ物なのでBANするのは当然だ。さすがTwitter様。完璧なTwitterユーザーは完全に幸福です。実際、幸福は義務です。ユーザー、あなたは幸福ですか?

現実のTwitterはここまでひどくないかもしれない。しかし、Twitter社がこのような運営をしても、逆らう方法はない。我々はTwitter社の慈悲にすがるしかないのだ。

自由なマストドンではこの恐れはない。あるインスタンスが気に入らなければ、別のインスタンスに行けばよい。自分の思想を受け入れるインスタンスがなければ、自分でインスタンスを立てればよい。自分の思想を受け入れるクラウドやVPSベンダーがなければ、自前でサーバーを立てればよい。もし、自分の思想を受け入れるISPが存在しなければ、それはシーランド公国にでも行くしかないだろう。

そして、マストドンではユーザーがインスタンスの違いをほとんど意識することがない。自由の圧倒的勝利だ。ああ、なんて世界だ!

ドワンゴ広告

ドワンゴは本物のC++プログラマーを募集しています。

2017年4月40日、5月1日に幕張メッセで開催される超会議2017には、マストドンブースがあります。江添亮がブース担当です。ドワンゴが立てたマストドンのインスタンス、https://friends.nicoのインスタンスの宣伝、マストドンステッカーの配布、マストドンについての質問、江添亮がライブマストドンするなどのさまざまな楽しいイベントがあります。

その他にも様々なブースがあるので楽しめますよ。

採用情報|株式会社ドワンゴ

CC BY-ND 4.0: Creative Commons — Attribution-NoDerivatives 4.0 International — CC BY-ND 4.0

2017-04-27

KaTeXを使ってみた感想

ブラウザー上で動いて、texの数式を描画するライブラリには、有名なMathJaxの他に、KaTeXがある。

Khan/KaTeX: Fast math typesetting for the web.

KaTeXにはMathJaxにない様々利点があるが、欠点も多い。

マストドンで数式描画をするのにMathJaxの代わりにKaTeXが使えないかと試してみたが、結論から言うと、KaTeXはマストドンで使うのに適さない。

KaTeXは以下の用途で使うのに適している。

  1. 自分一人、あるいは十分に訓練されて連絡を密に取り合う人間だけで編集された文書
  2. 数式に間違いがなく、KaTeXで処理できること

以下のような場合には適さない。

  1. 不特定多数の人間が数式を入力する
  2. 数式は文法的に誤りを含む可能性がる

KaTeXの利点

KaTeXはMathJaxに比較して様々な利点がある。

速い。文句なくMathJaxより速い。

KaTeX and MathJax Comparison Demo

実装が軽量で依存がなくWebサイトに組み込みやすい。

JavaScriptファイル一つ、CSSファイル一つ、あとはフォントファイルしかない。

KaTeXはかなり理想的なのだが、問題がある。

数式のパースエラーに非寛容

数式がtexの文法違反だったりするとすぐに例外を投げる。例外を無効化もできるが、基本的にパースエラーを出した時点でそれ以上の処理を拒否する。

CJK文字に対応していない。

これは本当に耐え難い問題だ。我々は$力=質量\times加速度$を書くときは、

$力=質量\times加速度$

と書きたい。しかし、KaTeXはCJK文字に対応していない。

一応、\text{}で囲めば使えるらしいが、それは式の意味を買えてしまうし、第一、

$\text{力}=\text{質量}\times\text{加速度}$

とは書きたくない。そもそも意味が変わってしまう。不特定多数のユーザーがいる場合にこれを守らせるのも難しい。それにこうしてもやはりCJK文字の扱いには問題がある。

それ以外にも、基本的にエラーを出すと処理を中止するようになっていて、本当に使いづらい。

このため、KaTeXはマストドンで使うのに適さない。

2017-04-26

どんなWebページでもtexによる数式描画を追加できるブラウザー拡張

EzoeRyou/inject-mathjax: どんなWebページにもMathJaxをロードするブラウザー拡張

任意のWebページにMathJaxを読み込ませてtexによる数式表現を化膿するChromium, Google Chrome向けブラウザー拡張。

インストール


git clone
vim whitelist_urls.conf
make

してからChromiumにインストールする。

whitelist_urls.confには一行にひとつ、MathJaxを読み込ませたいURLをマッチパターンで記述する

Match Patterns - Google Chrome

特徴

このブラウザー拡張はwhitelist_url.confに記述したマッチパターンのURLに対し、

  1. CSP(Content Security Policy)を無効化する
  2. MathJaxをロードする
  3. MathJaxを定期的に呼び出す

という処理を行う。

類似のブラウザー拡張より優れている点

すでに類似機能を提供しているブラウザー拡張があるが、コンピューターリテラシーのないユーザーのためにあまり洗練されていない実装になっている。

CSPの普及により、多くのWebサイトでは外部ドメインのスクリプトがロードできなくなっている。CDN経由でMathJaxをロードするには、まずCSPを無効化しなければならない。CSPはセキュリティを向上させるものであり、不必要に無効化すべきではない。そのため、MathJaxをロードする必要があるURLのみ無効化すべきだ。 Chromium, Google ChromeでCSPを無効化するには、レスポンスヘッダーをブラウザーが解釈する前に改変するブラウザー拡張用の機能を使う。そしてCSPの部分を削除する。

これは以下のようなコードになる。


for (var i = 0; i < details.responseHeaders.length; i++) {
    if ('content-security-policy' === details.responseHeaders[i].name.toLowerCase()) {
        details.responseHeaders[i].value = '';
        // 実際にはCDNを追加するのでもう少しマシ
    }
}

巷に出回っているブラウザー拡張は、このレスポンスヘッダーからCSPを削除するためのコールバック関数を、すべてのURLに対して読み出す。そして、自薦に設定したURLのみに適用するように条件分岐する。


function( details ) {

    if ( !is_whiltelist_urls(details.url) )
        return ;
}

ブラウザー拡張側のコードでURLを判定している。

理想的には、ブラウザー拡張のmanifest.jsonのpermissionsで適用されるURLを厳しく指定すべきだ。しかし、そのためにはユーザーがmanifest.jsonを変更する必要がある。

このブラウザー拡張は、whitelist_urls.confに記述されたマッチパターンをpermissionsにもつmanifest.jsonを生成して、ブラウザー拡張をユーザーが作るようになっている。