2020-03-29

村上原野(ボレロ村上)の思い出

村上原野(ボレロ村上)の思い出を色褪せないうちに書いておこうと思う。

村上原野の父親であり師匠であった猪風来は縄文土器による芸術家である。縄文土器の制作方法を復元した人物だ。

猪風来プロフィール | 美術館の紹介 | 猪風来美術館

縄文土器は窯を使わずに野焼きで焼き上げる。野焼きで窯ほど燃焼温度が上がらないので、低温でも焼き上がるような粘土を使わなければならない。その製法は再発見され、村上原野が縄文土器作成を学ぶ頃には、一通り完成していた。製法を復元した上で、その製法を使って芸術品を作るというのだ。

聞いた話では、猪風来は極めて形から入る芸術肌の人間で、縄文人の心を理解するために、北海道に竪穴式住居をこしらえて家族で住んでいた。つまり、村上原野の父親と母親と本人は中学生か高校生ぐらいまで北海道の竪穴式住居に住んでいたのだ。

竪穴式住居とは歴史の教科書にも出てくる様式の原始的な家だ。地面を掘り下げ、その上に屋根を設営する家だ。竪穴式住居は全国にあるのだが、北海道のような寒い地方では、寒さ対策のために地面をかなり深く掘り下げる。猪風来がかつて展示会で語っていた話では、竪穴式住居の中で座ると、ちょうど目の高さが地面すれすれになるほどだという。そうして猪風来は縄文人の心を会得した。

その後、村上原野の一家は岡山の廃校に引っ越す。廃校を作品制作の作業場と作品の保管所と美術館として利用している。

村上原野はそのような特殊な家庭環境にもかかわらず、当初は高専を卒業し、確か本人の話では製図技師か何かで数年、民間で働いていたそうだ。ただし本人曰く「やはり土をいじっている方が楽しい」ということで仕事をやめ、家業をつぐことにしたのだという。

村上原野のいでたちは、かなりガッシリとした体格で、よく日焼けしていて、母親の作った作務衣を着ている。どこから見ても偉丈夫であり、刺しても死なないほどの健康な見た目であった。

このブログの読者が知る村上原野は、ボレロ村上、もしくは中3女子という名前で知っている人物で、C++プログラマーだ。

https://github.com/bolero-MURAKAMI/Sprout

Sproutは村上原野によるC++ライブラリであり、C++におけるコンパイル時計算用のフレームワークを提供している。

このSproutを使った村上原野の作品としては、コンパイル時レイトレーシングがある。

constexpr レイトレーシング - ボレロ村上 - ENiyGmaA Code

当時の純粋なテンプレートメタプログラミングのみのレイトレーシングや、あるいはC++11時代のまだ本体はreturn文ひとつしか書けなかった頃のconstexpr関数を使ったレイトレーシングがある。

あるいは、コンパイル時音声生成がある。

constexpr で音階生成&シンセサイザー&音声合成 - ボレロ村上 - ENiyGmaA Code

生前の村上原野に、C++によるこの作品は芸術なのかと聞いてみたことがあるが、彼にとってこれらは芸術ではないらしい。

村上原野 aka ボレロ村上, 中3女子 逝去

ボレロ村上、中3女子ことC++プログラマーで陶芸家の村上原野の訃報が流れている。それによるとどうやら、2月16日未明に、陶芸作品を製作中に倒れ、翌朝に発見されたようだ。

2月15日の21時51分のtweetに体調の変化を示唆する書き込みがある。倒れたのが16日の未明とあるので、そこから6時間後ということになる。

この書き込みから急な脳梗塞ではないかと思われる。体調の変化を感じたら病院に行くべきなのだろう。

大一報はおそらく猪風来美術館のFacebookで、これは20日に公開されたとのことだが、我々プログラマーの界隈に知られるまでに9日間を要したようだ。

岡山にある猪風来美術館は村上原野とその両親が経営している廃校を利用した美術館と製作所のはずで、すぐにでも岡山に行きたい気持ちがあるのだが、あいにくと世間にはコロナウイルスが流行している。行けば至近距離で会話をしたくなるだろうから、東京に住んでいる身としては軽々と訪れることができない。早くコロナウイルスが収束してほしい。

ゲンヤよ!

2020年2月16日未明、おまえは32歳という若さでこの世を去った。最後の作品を制作中、倒れる直前粘土をひと掻きした跡そのままに、手に竹べらをもったまま息絶えた。きらめく魂、やさしい魂、躍動する魂よ、おまえのすべての命が燃え尽きたのだ。 力いっぱい、こんなに精一杯生きて、表現して、苦悩し、愛して、未来へ、新しい地平へ翔けていくはずだったおまえは、今力を尽くして、生命を生き切って、美しい魂の宿る作品を私たちに託して旅立っていった。

おまえの大きな縄文の渦はここから湧きあがり、おまえはその渦に乗りここから翔けあがり、おまえの愛した山や海や大地をめぐり、生まれ育ったアイヌモシリや遥かなアメリカの大地をめぐる。おまえの渦はしなやかに美しく螺旋を描き、無数の夢を乗せて伸びやかに繋がっていく。おまえが見た精霊たちは、今おまえの後を追って螺旋の渦をなし、ひきもきらさず列をなしている。

そして渦に乗ったおまえは何度もなんどもこの地に戻ってくるだろう。まわりの森の木々を震わし、みんなで協力して建てた竪穴住居の茅屋根を撫で、野焼きの野炉の灰を散らし、おまえやほかの人の作った縄文作品を愛で、いつも、どこでも残った私たちにおまえの記憶を喚起させるだろう。おまえの成し遂げた仕事、思索、大きな夢、愛する人たち、すべてがここにあったのだから。

おまえはここで新しいおまえの地平を切り開き生きていくはずだった。縄文のスピリットに惹かれ、現代に生きる己の感性で縄文の新時代の美を求めてひたすらに挑戦を続け、その手でやり遂げていく意欲に溢れていた。私たちは底のない悲しみの中、その夢を引き継ぎ繋いでいかなければと、今祈るような気持ちで歩み始めようと思う。

生前、村上原野を支え、愛し、共に力を携えて活動してくださった方々に感謝の思いでいっぱいです。これから私たちは心を寄せる人たちと共に彼の魂の宿る最後の作品を無事焼き上げます。そして彼の残した作品を新しい縄文芸術として世に提示していきたいと思っています。彼の縄文の渦はまだ終わっていないのですから。どうぞこれからもよろしくお願いいたします。

(猪風来・むらかみよしこ)

猪風来美術館 - ゲンヤよ!... | Facebook

2020-03-08

赤倉温泉スキー場に来ている

2月に白馬に2週間滞在してスノーボードと温泉三昧だった。白馬に2週間も滞在することになったのには長い話があるのだがまたの機会に書くとして、結果として、長期滞在して温泉に浸かりスノーボードをしてリモートワークをする価値に目覚めてしまった。3月も同じことをしたいと思ったので、人を誘って再び一週間の長期滞在をしてきた。

滞在先は赤倉温泉だ。詳しくは知らないが、この暖冬にもかかわらず全国のスキー場の積雪ランキング上位にあるスキー場だ。予約時に300cmの積雪があったので、これならば雪はあるだろうと宿を予約した。赤倉ホテルという宿だ。さぞ予約は取りづらいだろうと思っていたが、あっさりと予約を取ることができた。

宿はなかなかよかった。食事は悪くなく、宿の建物内に温泉が3箇所あり、しかも2箇所は24時間入り放題。そしてもう一つ露天風呂があり、これがやや特殊な完全な外に設置されている露天風呂で、涼しくて湯温も高く最高だった。この露天風呂、変わったことに混浴でかつ周りから丸見えなのだが、そもそもホテルにはほとんど客がいないので気兼ねする必要はなかった。ただし、例年では雪が高くつもり、完全に周囲から隠れてしまうそうで、本来は女性客も入りやすいそうだ。

肝心のスキー場だが、宿の目の前に赤倉温泉スキー場がある。当初、このスキー場にのみ行くだろうと思って、あらかじめリフト券を4日分手配しておいた。しかし、これは間違いだった。赤倉温泉の近くには赤倉温泉スキー場、赤倉観光リゾートスキー場、杉ノ原スキー場、池ノ平スキー場、関温泉スキー場がある。特に赤倉温泉と赤倉観光は隣り合ってつながったスキー場で、赤倉温泉スキー場は広くて簡単でつまらないコースばかりだが、赤倉観光リゾートスキー場の方は難しくて面白いコースが多かった。

まず移動日は滑らず、初日は赤倉温泉スキー場で足慣らし、白馬で2週間、1日滑って2日休むという筋肉を鍛えるのに理想的な頻度で滑っていたので、体には余裕があった。2日目に赤倉観光リゾートスキー場に行ったが、これまた前日の疲れがまったく気にならないほどの余裕があった。3日目は流石に連続しては辛いだろうと赤倉温泉スキー場でのんびりと滑ったが、これまた余裕があった。4日目は再びリゾートに行った。5日目は念の為に休みを入れた。膝は多少痛むが、危険な痛みではない。

これを書いている時点では土曜日だが、明日の日曜日に1日滑り、月曜日は余力があれば午前中に滑って帰ってこようと思っている。こんなにも膝と脚に余裕ができているほど体が鍛えられているとは自分でも驚いている。しかも、スノーボードの腕も上達している。白馬でスイッチができるようになったが、さらに滑走が安定した。

白馬での目的はスイッチだったが、今回の目的はGoProを持っている友人と一緒に言ったので、追い撮りと自撮りの上達を目標にした。そのために自撮り棒を購入した。結果は大成功だった。もっと難しいものだと思っていたのだが、自撮り棒を持っての滑走はほとんど滑走に影響を与えない。簡単であることがわかったので、GoProの来年のモデルが販売されたら購入を検討しようと思う。

今回使ったGoProはHERO 7だが、使う上での注意点がいくつかあった。まずGoProはバッテリーが持たない。リフト営業開始から終了までの丸一日の全滑走を撮影したいというのであれば、4K解像度や120FPS撮影は諦めた上で、予備のバッテリーを2つ以上持っていくのがよいだろう。逆に、事前に危惧していたSDカードの容量は全く問題がないことがわかった。今は512GBや1TBのSSDカードが数万円で売られている。動画のビットレートが90Mbpsであったとして、512GBあれば12時間は撮影できる計算になる。そしてGoProのバッテリーは1時間持たない。

GoProを撮影した後の注意点もある。GoProはSDカードのフォーマットにexFATを使っている。exFATのfuseではないマウントにはLinux kernel 5.4が必要だ。Ubuntu 19.10は5.3、Ubuntu 20.04が5.4になる予定となっている。

GoProが使う動画フォーマットはh.265(HEVC)の10bitプロファイルを使用している。この動画のリアルタイムデコードはとても重い。筆者はここ10年ぐらいCPUのパフォーマンスは十分すぎるぐらい向上したので、いまだにSkyLake世代のIntel CPUを積んだラップトップを今回の旅行に持参した。ところが、H.265 10bitのデコードのハードウェア支援はSkyLakeの次の世代のKirbyLakeが必要だ。KirbyLakeもそうだが、AMDやNvidiaのGPUのハードウェアデコード支援も、h.265 10bitに対応したのは2016年に販売された製品からだ。今回の撮影は2.7k 60fpsで行ったが、筆者のPCではリアルタイムデコードできなかった。前のフレームからの差分で表現するIフレームや、前後のフレームからの差分で表現するBフレームを多用するh.265の再生は、リアルタイムデコードが出来ない場合破綻する。そのために当初は単に映像を確認するためだけにffmpegでh.264にエンコードしていたが、いろいろと試した結果、ブラウザーを実行しない状態でmpvを使うとややフレームレートに違和感はあるものの、再生できることがわかった。

2.7k 60fpsでこの負荷なので、4K 60fpsはもっと負荷が高いのだろう。GoProで撮影した動画を編集するには最新の高スペックなコンピューターを容易すべきだ。最も筆者はffmpegのフィルターでできる以上の編集をするつもりはないのであまり気にしていない。今のところ考えている編集は動画の切り出しと連結、あとは別音声のmuxぐらいだ。今回撮影した自撮りと追い撮りはすぐにでも動画サイトにアップロードしたいのだが、現在滞在している宿のWiFiの帯域は20Mbps程度で2割程度のパケットロスが発生するという基本的人権がないほど貧弱な環境なので、自宅に帰ってからアップロードする予定だ。

追い撮りと自撮りについてだが、まず自撮りについては特に難しいことはなかった。単に自撮り棒をもって滑るだけだ。スノーボードは両手が自由なので様々な持ち方ができる。360度カメラではない自撮り棒に固定したカメラの場合、後ろ手で持って山側から谷側への撮影、前の手で持って谷側から自分を含む山側を撮影、前の手で持って谷側を撮影という方法が考えられる。全て試してみたが、どれも特性の違う動画ができあがる。

追い撮りは難しい。単に追いかけて被写体をフレーム内に納めるだけならそれほど難しくはないのだが、問題は距離だ。GoProは画角が広い。これは被写体をフレーム内に維持するという点ではいいのだが、実際の距離以上に被写体との距離感が出てしまう。被写体を大きく移すには近づく必要があるのだが、これも難しい。被写体は自分ではないので滑走の速度があわない。直滑走すると追い越してしまうし、丁度いい速度を保つのが難しい。撮影中、離されたので直滑走して追いつき、そして抜きそうになったので減速してまた離されることがたびたびあった。これは自分のショートターンの腕前を上げるほか、被写体と無線で連絡を取り、離されすぎた場合減速してもらうなどの連携が必要だろう。

もう一つ難しいのが、実際に見たとおりに撮影できないということだ。雪面は日光の反射で白飛びしてしまい、起伏が目立たなくなってしまう。かなり深いコブ斜面でもまるで圧雪されているかのようになだらかに見えてしまう。そして、傾斜も実際より浅く見える。これはカメラ自体が傾斜にそっているために仕方がないことではある。カメラを水平にすると撮影できるのはほとんど空だけだ。速度感も乏しい。カメラを高い位置で保持すると全く速度感がない。それなりの傾斜のある斜面を直滑走しても、雪面が白飛びすることと画角の広さのせいで、全然速度が出ているように見えない。速度感を出したければカメラを低い位置に置かなければならない。

また、今回は追われ撮りもためしてみた。これはカメラを後方に向けて滑り、被写体に追いかけてもらうことで、被写体を全面から撮影しようという試みだ。これはある程度はうまくいったが、なかなか難しい。減速やターンをするたびにカメラを左右に降ってしまうので、被写体はフレームに入るためにかなり努力して滑らなけれならない。直滑走すると被写体と撮影者の道具と技量と体重差によって速度差が出てしまうので破綻する。今回、私はスノーボードで友人はスキーだったが、私は毎回ホットワックスをしているが友人はスプレーワックスで済ませるズボラな人間であるのと、私が友人より20kg重いために、直滑走すると友人よりかなり相対速度が開いてしまう。それに、被写体一人だけで同じ姿勢を維持して直滑走し続ける動画はそれほど映像映えしないという問題もある。複数人でのレースのような面白さを追加する要素が必要だ。

手ブレ補正も一長一短がある。GoProの手ブレ補正はなかなかに優秀ではあるのだが、手ブレ補正をかけると滑走のダイナミックな動きが消えてしまう短所もある。

友人はスキーヤーなので、スキーでの自撮りや追い撮りを模索していたが、自撮りについては圧倒的にスノーボードのほうが楽だ。追い撮りもスキーでは細かい調整が聞かずに難しい。ヘッドマウントではカメラ位置が固定されてしまい、自撮り棒を動かすというダイナミックな撮影ができない。スキーで自撮り棒をもつと滑走が難しくなる。スノーボードでは手を固定して滑ることもできるが、スキーは手を動かしてバランスを取りたい特性があるようだ。

今回、自分の滑りを追い撮りしてもらう機会にも恵まれたが、やはり滑走中にバランスを取るために上半身をリーンする癖が抜けない。下半身の屈伸だけで十分にバランスをとれるところでは積極的に下半身を意識して使っていきたいところだ。

2020-02-16

C++20標準規格がほぼ固まった

2020年2月10日から15日までプラハで行われた会議により、C++20のDIS(Draft Intarnational Standard)が可決された。これはC++20となる標準規格と同じ文面であり、もうこれ以上変更はない。今後、このドラフト案に対して各NBによって可否の投票が行われる。何事もなければこのまま可決されてC++20が制定されるだろう。

今回残念なのはstd::formatだ。これはpythonにあるようなテキスト整形ライブラリだ。ただしロケールに依存している。std::formatのロケールを引数に取らないコンストラクターはグローバルなlocaleオブジェクトに依存する。今の所ロケールの影響を受けるのはtype specifier nで、数値を桁区切りにして出力する機能だ。

std::formatがlocale汚染されたことにより、std::formatは危なくて使えないライブラリになったし、ローカライゼーションの妨げになるので使ってはならないライブラリとなった。

10年前、char8_tの必要性を標準化委員会に説いたときはchar型は生のバイト列を表現するのに最適な型だなどととんでもない話を持ち出されて一笑に付されたが、その後にchar8_tの必要性は認識され、かつcharが生のバイト列を表現するのに不適切な型であることが認識され、std::byteが入った。

コルーチンも問題が多い。C++20に入ったコルーチンとはその名前で連想するようなユーザーモード実装の軽量スレッドではない。C++20のコルーチンとは3種類のキーワード、co_await/co_yeild/co_returnを使った関数をコルーチン関数と認識し、その関数に対してあらかじめ定められた変形を行い、最終的にユーザー定義のクラスの特定のシグネチャーのメンバー関数を呼び出す単なるシンタックスシュガーだ。変形ルールを考慮した上で自力でライブラリを実装すれば、例えばユーザーモード実装の軽量スレッドやジェネレーターやメソッドチェインやステートマシンや非同期I/Oといった機能を実現できる。ただし、コルーチンをサポートした標準ライブラリは存在しないので自力で実装する必要がある。そして自力で実装するのは極めてだるい。

コルーチンのためだけにコア言語にここまでユーザー定義クラスの特定のシグネチャが存在することを前提とした文法を入れるのは汚い。コルーチンのような機能は、静的リフレクションで実現すべきだ。

今現在、環境の変化でC++に時間を割くことができていないし、C++20本は出せるかどうかわからない。

2020-01-18

Erlangについて思うところ

職場の今までいた部署が潰れてしまったので、新しい部署で仕事のためにErlangを学んでいる。基礎的な文法については学び終わったので、現時点でのErlangについての雑感を書いておこうと思う。

Erlangは多数派のプログラミング言語とはだいぶ違う文法を持っている。終端記号がドットであることもそうだが、比較演算子もだいぶ違っている。多くの言語が!=を使うなか、Erlangは/=を使っている。Less than or equal toが=<であるのも多数派とは異なっている。ただし、Greater than or equal toは>=だ。一貫性がない。

終端文字はドットだが、関数の中には一つの式しか書くことができない。式はカンマで区切ることができるので、以下のようになる。

func() ->
    expr1 , % カンマ
    expr2 , % カンマ
    expr3 . % ドット

このような文法はリファクタリングの時に問題になる。というのも、例えば関数の戻り値をexpr3の評価結果に依存した別のものにしたくなったとき、

func() ->
    expr1 , % カンマ
    expr2 , % カンマ
    expr3 . % エラー
    expr4 .

うっかりドットをカンマに修正するのを忘れるとエラーになる。

そもそも関数の文法も問題だ。関数は同名の関数群をセミコロンで区切って一度に定義する文法になっている。

Name( P1 ) when ... ->
    expr ;
Name( P1 ) when ... ->
    expr ;
Name( P1 ) when ... ->
    expr . 

関数群の最後はドットで終端するが、途中の関数はすべてセミコロンで区切る。これは関数を定義する順番を変えたときに、手でセミコロンとドットを修正しなければならない。

Name( P1 ) when ... ->
    expr ;
Name( P1 ) when ... ->
    expr . % エラー、リファクタリング中の修正漏れ
Name( P1 ) when ... ->
    expr ; 

変数が再束縛できないのもコードを汚くする。というのは、結局現実のコードでは式を評価した結果を元に更に計算を行い、その結果を束縛し、途中の結果については参照しないコードがある。


R1 = expr1 ,
R2 = Do_something(R1) ,
R3 = Do_something2(R2) .

もちろん、途中の評価結果を変数に束縛する必要はないのだが、あまりにも式が長い場合は可読性のために途中でわかりやすい名前をつけたくなる。しかし、変数の再束縛が許されていないために、変数名に意味のある単語を使わない文化圏の怠惰な数学者がよく使うX'や、gitを使えないバカがよく使う2020-01-18プロジェクト企画書(最新)(第二項)(承認待ち).zipのようなひどい変数名を作り散らかす原因になる。

他にもガードにBIFしか使えないとか型がないとか型がないとか特に型がないとかいろいろといいたいことはあるし、ErlangはHaskellの爪の垢を煎じて飲んでほしいのだが、汎用プログラミング言語としてみたErlangは貧弱で、主要なプログラミング言語とは違う文法を採用し、しかも融通がきかない不自然な文法で、まことにつまらない言語だ。まるでGOやJavaのような言語と言える。

ただ、言語としてはそれほど難しい概念もないので、習得は容易だろう。

ただし、あらゆる点で言語としておそまつな点が目につく。最初はクソ言語と思っていたが、途中からこれはBrainfuckと同じエソテリック言語の仲間だと思えてきた。

そして基礎的な文法を一通り学び終えた今では、ついにあるひとつの結論に達した。Erlangは分散コンピューティング用のDSLなのだ。SQLとかシェルスクリプトと同じであって、汎用プログラミング言語として考えるからクソ言語だと思うのであって、特定の分野専門のDSLだと考えれば悪い言語ではない。汎用プログラミング言語として考えたとき、SQLやシェルスクリプトはいかにもクソ言語というしかない。しかし、SQLやシェルスクリプトの価値はそこにあるのではない。Erlangも同様に、たまたま汎用プログラミング言語としての機能を備えてしまっただけで、本来は単なるDSLであり、ツールでしかない。1980年台にネットワーク越しのリモートコンピューター群をあたかも一つのコンピューターを扱っているかのように扱えるようなツールを実現したという点で価値がある。

さて、Erlangの基礎的な文法は一通り理解したのだが、まだこれでErlangの習得が終わったわけではない。これからErlangのプロセスやメッセージパッシングなどを学ばなければならない。まだもう少し時間がかかりそうだ。

膝の痛みがなかなか治らない

スノーボードによる膝の痛みがなかなか治らない。

30を超えてから新しい運動を始めると悩まされるのが靭帯と腱の損傷だ。筋肉痛というのは数日で回復するが、靭帯と腱の回復には数ヶ月かかる。これまでにボルダリング、ダンス、スノーボードと新しい運動に挑戦し続けているが、そのたびに靭帯と腱を損傷している。

残念ながら今の日本語圏のインターネットにはまともな情報がないので、せめて自分の怪我の状況と回復時の自覚症状ぐらいは書き残しておこうと思う。

ボルダリングでは指の腱を損傷した。原因は単純で、足を滑らせて指だけで極端な荷重変化を支えてしまったのが原因だ。指の腱を損傷すると、指の曲げ伸ばしと手首、手首の下辺りに違和感を感じる。回復の自覚症状はかなり急峻だ。病院に行ったところ、抗炎症作用のある塗り薬を処方された。塗るとわずかに痛みが減る。最初の一ヶ月ぐらいはほとんど回復が見られず絶望的になるが、ある日を境に1日単位で違和感が減っていく不思議な自覚症状の変化が現れた。

ダンスでは足首が痛くなった。つま先を上げる方向に足を動かすと、足首が痛くなる。医師の診断によるとアキレス腱を痛めたそうだ。一ヶ月ほどダンスを中断して、痛みがやや収まったものの、依然として残るので病院に行ったところ、処方はロキソニンテープとジクロフェナクNa(鎮痛抗炎症剤)とレバミピド(胃薬)とアセトアミノフェン(解熱鎮痛剤)であった。薬の鎮痛効果により痛み自体は軽減されるのだが、痛みがなくなるわけではなく、回復して痛みが減ったのか、単なる鎮痛効果で痛みがわかりにくくなっているだけなのか判断に困る。そのまま更に1ヶ月ほどは自覚症状は変わらなかったが、ある時を境に急激に1日単位で症状が軽くなっていった。

そして今悩まされているのが膝だ。原因はスノーボードだと思われる。ダンスで膝を痛めなかったのはよくわからない。いかにも膝に負担の掛かりそうな動きもしたのだがダンスでは問題がなく、スノーボードに1日行っただけで極端に膝を痛めてしまった。

当初は右膝の内側に痛みがあったのだが、今は左膝も少し痛み、かつ膝の外側にも痛みがある。膝の内側の痛みしか自覚症状がなかったときに医者にかかったところ、膝関節内側側副靱帯(MCL)を痛めたのだろうということだ。処方は足首と同じだ。

肝心の治療経過だが、一ヶ月経過した今、まだはかばかしくない。未だに痛みが残っている。当初は階段を上がるととても大きな痛みがあったが、今は階段を上がるぐらいでは痛みはでない。当初は膝に負荷をかける動きをすると痛みが出ただけで、安静にしていれば痛みはなかったのだが、今は膝に負荷をかけても痛みはそれほどないが、常に膝に違和感を感じている。この安静時の違和感は安定せず、痛みがないときもあれば、痛むときもある。自覚できる痛みがないからとうっかりと地下鉄の階段を上がってしまった翌日は痛みが出ている気がするので、膝への負荷に遅延して安静時の痛みが生じているのかもしれない。

靭帯と腱の回復には2ヶ月かかるという個人的な経験則からすると、回復にはまだ一ヶ月かかる計算になる。スノーボードのシーズンは短い。特に今年は雪が少なく例年より短くなるだろう。

この記事をここまで書いてから2日立った。たまたま膝の調子が良かったのでボルダリングに行ったところ、回復の兆しを感じた。翌日も痛みがあまり膝に残らない。

改めて考えてみると、今まで靭帯や腱を痛めたときの痛みの自覚症状は、いつも同じような状況だ。まず受傷直後はそれほど痛くない。翌日から数日も痛みはあるもののそれほど痛くはない。ただし、少しでも負荷がかかったならば危険な痛みを感じるので運動はできない。その後一ヶ月以上、運動を完全に控えても痛みが収まらない状態が続く。多少の負荷をかけても当初感じた危険な痛みはないのだが、やはり痛みはあるので運動はできない。このような状態が一ヶ月以上続いて絶望するが、ある時急に回復の兆しを感じる。そうすると少しぐらいは負荷を書けても痛みは感じなくなり、運動も様子を見ながら再開できる。そして、不思議なことに運動をすると回復が早まる。

2月にはスノーボードに復帰できるかもしれない。

2020-01-05

2020年の日本には2020年にふさわしい日本語の掲示板がない

情報の流通において最も効率的なのはテキストだ。テキストを効率よく流通させる方法として、古典的なインターネットにはメール、チャット、掲示板があった。

このうち、メールは古典的なEメールがまだ生き残っている他、現代的なSNSがメールの機能を代替し始めてきた。日本では今の所LINEが最も普及しているようだ。

チャットもそうだ。古典的なIRCはまだ生き残っている。しかし現代的なSNSや、Slackのようなサービスが代替し始めてきている。

では掲示板は? 現代の日本には現代的な掲示板サービスが欠けている。

もちろん、掲示板機能を提供するWebサービスはたくさんある。しかし、日本語圏でWebサービスを提供しているものは、いずれもかなり限定的な目的に特化したものだ。例えばユーザー同士で質問と回答をしあうサービス(Yahoo知恵袋など)とか、ソーシャルニュースアグリゲーション(はてなブックマーク)のようなサービスはある。しかしテキストの流通機能としては貧弱であり掲示板ではない。

2ch/5chのような古典的な掲示板はある。しかし見たところ技術的負債と開発リソースの不足により、ほとんど当時のまま運用されているようだ。2020年に使いやすい作りではない。

私の考える2020年の品質の掲示板とは、RedditやHacker NewsのようなWebサービスだ。どちらもソーシャルニュースアグリゲーションだ。そういう意味でははてなブックマークはとてもいい線を行っている。しかしはてなブックマークは掲示板ではない。単に1行コメントが書けるだけで、他人のコメントを参照してテキストを積み重ねることができない。はてなブックマークはソーシャルニュースアグリゲーションというよりはオンラインブックマークとして設計されているので、結果として掲示板にはならなかった。

結果として、日本には2020年にふさわしい現代的な掲示板がない。ないということはどこかが作れば儲かるのではないかと思う。誰かがやってほしい。

Arch Linuxがパッケージ圧縮フォーマットをxzからzstdに変更

Arch Linux - News: Now using Zstandard instead of xz for package compression

Arch Linuxがパッケージの圧縮に使うフォーマットをxzからzstdに変更した。

Archでは圧縮レベル20を使うことにより、xzにくらべて0.8%サイズが増加するが、デコード速度が1300%向上するという。

CanonicalによるUbuntuは2018年にzstdに移行するテストをしていて、その結果による、圧縮レベル19を使うことにより6%のサイズ増加だったということだ。

zstdとはFacebookのYann Colletが2016年に発表した圧縮フォーマットとそのリファレンス実装のことだ。軽く調べてみたところ、メモリ使用量が多く並列実行に力を入れている設計と実装のようで、現代のコンピューター向けという感じがする。

2020-01-04

未来のタクシーはネットカフェになる

深夜にのんびりとRedditを眺めていたところ、以下のような1年前の記事が話題になっていた。

Mean streets: Self-driving cars will "cruise" to avoid paying to park

内容はこうだ。自動運転が実用化されたならば、車は駐車せずに自動運転で周辺を運転するようになる。なぜならば、燃料費と摩耗費よりも駐車料金のほうが高くつくからだ。

たしかに一理ある。都市部の駐車料金は高い。なぜなら土地が高いからだ。自動運転により人件費がなくなれば、後は「車の燃料費と摩耗費<駐車料金」であるならば車を運転し続けたほうが安い。

この考えを推し進めると、将来、タクシーはネットカフェになる。

ネットカフェは簡易的な個室とインターネット、マンガや映画を提供している。貧乏人はネットカフェを簡易宿として利用している。これらネットカフェの機能は、自動運転による無人タクシーで代替できる。

つまりこうだ。都市部を自動運転による無人タクシーが流している。客はこのタクシーを呼び止め中に乗る。中にはフラットに倒すことのできる椅子とコンピューターと携帯電話網によるインターネットが提供されている。またマンガや映画のストリーミングサービスも提供されている。客がネットカフェ機能を利用している間、この無人タクシーは周辺、あるいは指定した目的地まで運転する。この無人タクシーは簡易宿としても利用できる。客は椅子をフラットに倒して寝ることができる。その間もタクシーは周辺を運転する。

荒唐無稽だとも思えない。現実のネットカフェは、土地と建物を用意するのに大掛かりな費用がかかる。しかも場所は固定で、車のように柔軟ではない。

どの程度現実的なのだろうか。車の摩耗費、メンテナンス費用、通信費用、コンテンツ契約費は償却して無視するとしよう。後に残るのは燃料費だ。現在、日本のガソリン価格はレギュラーが146円/Lだ。最新のハイブリット車は20km/Lを上回る燃費を持っている。

ただ、このネットカフェとしての無人タクシーにおいて、燃費というのは「距離/燃料」ではない。本当の燃費は「時間/燃料」だ。このネットカフェとしてのタクシーは走行をしなくても常時電力が必要なので、停止していても燃料を消費する。運転は燃料消費を最小にするが、走行距離を最大にする必要はない。たとえ信号や渋滞や燃料補給によって都合よく停止している時間が長くても、燃料消費が少なければ問題はない。

もしガソリン1リットルで1時間の燃費(時間/燃料)があるのだとしたら、1時間あたり146円の費用がかかる。

あるいは、蓄電池を搭載した完全電動車とすることもできる。この場合、無人タクシーは充電拠点の周辺を運転することになる。

都心部のネットカフェの料金と比較してみよう。都心部のネットカフェの相場は、30分で300円、3時間で千円、6時間で2千円、12時間で3千円程度だ。自動運転による運転手の人件費のかからない無人タクシーとしてのネットカフェは物理ネットカフェと同じ料金で利益を出せそうだ。

では肝心の駐車場の料金はどうだろう。都心部の駐車場の料金はまちまちだが、無人タクシーは場所の利便性を考えなくてもよい。利便性の悪い場所にある駐車場は、都心部であっても夜中は500円といった安いところもある。長時間利用する客を乗せた無人タクシーは、安い駐車場が空いているのならば駐車場を使い、そうでなければ道路を燃費(時間/燃料)のよい運転で流すのがよいだろう。

高度な自動運転が実用化され、このようなネットカフェとしての無人タクシーが大量に公道を流すようになると、公道が渋滞して社会問題になるはずだ。しかし法改正は技術開発よりも時間がかかるはずで、このような未来はありうるのではないか。