シェルスクリプトの代替

要約:決定版はとくにない。

kzys氏のシェルスクリプトを書かないという記事は面白かった。 https://blog.8-p.info/ja/2021/09/15/bash/

シェルスクリプト、ごくたまに書くことはあるが、ほんともう細かい話とかはすべて忘れているし、覚える価値を感じない。いまさら覚える必要のない技術だなと感じる。が、その一方でなかなか代替品がないようなニッチでもある。

自分は必要に応じてPythonかRubyか、といったあたりを使うことが多いが(perlはもう書けなくなった)、なかなかこれという感じには思い至らない。なにがいいんだろうね?という。

前提条件:インタラクティブな環境(REPL)はなくてもいい。そこはもう既存のシェルでいい。自動化したシェルスクリプト的なタスク記述を目標とする。bashの置き換えという意味では「どこにでもインストールされていることを前提にしないといけない」という問題もあるが、そこも問わない。自分が個人的に、またはチーム内の人に使ってもらうぐらいの規模で考えるので、コマンド一発でインストールできるか、コンテナイメージで実行できるぐらいであればもう良い。それ以上のことは検討しない。bashには勝てません、で終わってしまうので。

Python / Ruby

こうした言語をそのまま使うというもの。GoogleではPythonがよく使われていると思う。たとえばChromiumのビルドシステムGNでは補助スクリプトはすべてPythonで書くことになっている。ちょっとした処理をしてフラグを生成したものを渡してコマンドを起動して、その結果をちょっと整形して、といったことをやるには気軽だ。もっと気軽には自分はRubyで書いたりもする。

欠点。まずコマンド起動の部分が関数呼び出しになるのでまあまあ面倒くさい。パイプしたりするのもちゃんと書くのはじゃっかん面倒。そのため、標準出力をそのまま文字列として変数に渡す、みたいなことをしがち。

言語内DSL

Rubyとかの言語機能を使って言語内DSLでなんとかしようという話。Rubyの shell.rb とか。https://ruby-doc.org/stdlib-2.6.3/libdoc/shell/rdoc/Shell.html PerlにもPythonにもいろいろある模様。

またはzxもこれと近いね。https://github.com/google/zx。zxはtagged template stringsを使ってるのがオシャレだな。

欠点。なんか言語機能のabuseっぽくてちょっと嫌。けっきょくスクリプト起動のための依存関係が増えて嬉しくない(shell.rbはその点、標準ライブラリに入ってるので楽。しかしこれを標準ライブラリに入れるのはすごいな)。コマンドと変数名がかぶるとおかしなことになる。パラメータの展開とかいろいろ不安を感じるものも多い。などかなあ。

ワークフローエンジンまたはmake

makeを使うという主張もあった。一種のワークフローエンジン・タスク管理ツールを使うという手もある。Python Invoke http://www.pyinvoke.org/ とかもそれに近いですね。タスクの順番や依存関係とかを簡潔に書ける。外部コマンド実行はpure Pythonなどよりはマシかな。そういや昔、そういうのを使うプロジェクトに関わったことあるなあ。

欠点:書きづらいタイプのタスクもけっこうある。条件分岐とかしだすと、まあできるんだけどとたんに面倒になったり。パイプやコマンドの出力結果の加工とかも考えるとMakeはそれ単体では成り立たない気がする。言語内ワークフローエンジンは言語の機能を使えばまあアリではあると思う。

独自スクリプト言語

上記の欠点をあげつらうならもういっそ独自言語でもいいのかな、という気もする。PowerShell https://docs.microsoft.com/en-us/powershell/ とか、Oil https://www.oilshell.org/ とかのアプローチ。外部コマンド実行やパイプ、典型的な構造データ(JSONなど)の処理は言語処理系内でできるようにすればいい。

欠点:新しい言語や処理系を覚えないといけない。JSONの処理がたとえばビルトインでできても、やっぱりYAMLやXML、TOMLも扱いたいです、みたいになったときに困るかもしれない。

結語

というわけで、これが絶対いいっていうのはないんだよな、と思う。個人的には言語内DSLがいいかなあと思うが、その出来にもよるしね。

8月に読んだ漫画

ふとまとめてみる。計41冊か、思ったより読んでるな。気が向いたものだけ軽くコメント。

『兎〜野生の闘牌〜』 1-9巻

なんとなくネットでみかけた麻雀漫画の古典。自分が高校生のときにも友達が勧めてた気がする。まあまあ面白いんだけど、根本的に自分は麻雀に興味がなさすぎなんだよな。じゃあなんで読んだのかっていう話なんですが……。

『Thisコミュニケーション』4

あいかわらずひどい話で面白かった。デルウハが本名デ・ルーハだったのはぜんぜんわかってなかった。作者のイントネーションの感覚、特異では。

『マッシュル』7

『鴨乃橋ロンの禁断推理』3

『Dr. STONE』22

最終巻なのか?というほどの盛り上がりの果ての展開がとても良かった。面白いなあ。

『僕のヒーローアカデミア』31

昨今の展開が広がりすぎて読んでてもよくわからなくなってきたので、一段落してくれて助かる。でもまあ惰性で読んでる感はある。

『逃げ上手の若君』2

最初どうなのかなと思ったけど、松井優征はやっぱり上手いなと思わせるものがある。

『おとなりに銀河』2

『二月の勝者』12

『転がる姉妹』2

第1話のインパクトがすごかったけど出オチじゃなくて普通に面白く続いていてよい。

『最果てから徒歩5分』2

『愚者の星』6

『ほしとんで』1-5

ふと見かけた俳句漫画。まあまあ面白いかなと思いながら読んでいたら唐突に打ち切りっぽい終わり方で終わって驚いた。

『猫奥』3

猫漫画。とても良いです。

『定額制夫のこづかい万歳』3

『望郷太郎』5

『相続探偵』1-2

『海が走るエンドロール』1

夫が亡くなったおばあちゃんが突然、美大に入って映画製作しはじめるというまんが。面白い。

『東独にいた』1

『太陽と月の鋼』3

『SHIORI EXPERIENCE』1-6

地味な高校教師に突然ジミヘンの幽霊が乗り移って……という漫画。漫画として達者でけっこう楽しめる。

『地図にない場所』1-2

安藤ゆき、かなり好きなのに新連載はじまってたの気づいてなかった。教えてよ! 本作も面白いけど、今のところは過去作のほうが好きかな。今後に期待。

転職した

Facebookなどではステータス更新を済ませたが、6月末にグーグルをやめて新しくスタートアップに転職した。すでにそのスタートアップで働いて、いま2週間くらいというところ。

グーグルには13年以上勤務した。いろんな面でずいぶんお世話になりました。自分の意思でやめたけど、実際のところ、とくにすごく嫌なことがあってやめた、というわけではない。ややこしいこととかが皆無というわけではないけれど、あの規模の会社としてはずいぶん頑張っているだろうし、総合的にとてもいい会社だと思う。部下のいないヒラエンジニアとしても待遇もよかった。やっていたプロジェクトも意外と(?)インパクトのある製品だったし。

今回は、たまたま自分にとって絶妙なタイミングでお声がけいただいたのと、こういうシリコンバレーのスタートアップに入るのは得がたい経験だろうしいい機会かもしれないなと思った、という次第です。

新しい会社は、まだ入って2週間なのでなんとも言えないけれど、いまのところは楽しくやっている。フルリモートの会社なので在宅勤務を続けていて、身の回りの環境の変化はあんまりない。この転職の都合による引っ越し等も必要ない。ミーティングが激減したので会話量が減ったかなあというのが一番大きな変化かなぁ。

そんなかんじです。今後ともよろしくおねがいします。

ところで新会社はまだぜんぜん小さな会社なんですが、今はエンジニア(とくにバックエンド系)を採用強化中とのことです。フルリモートな会社なので、日本からでも(たぶん)働けます。興味のある人はリンク先の下の方のフォームから、ぜひ応募してみてください。

アンディ・ウィアー “Project Hail Mary”

マット・デイモン主演で映画化された『火星の人』(原題:The Martian……映画の邦題は『オデッセイ』)のアンディ・ウィアー先生の新作長編、”Project Hail Mary” を読んだ。

面白かった!

主人公は記憶を失った状態で、機械に繋がれた生命維持装置のようなもののなかで目が覚める。ここはどこか、なぜ自分はここにいるのか? そもそも自分は誰なのか? それすらわからないなかで。同じく生命維持装置につながれているがなんらかの事情で死んでしまった二人の死体のほかは誰もいない、完全なるコンピュータ制御の部屋。少しずつ戻ってきた記憶と、様々な実験・観測から、人類存亡の危機と、Hail Mary計画の詳細が次第に明らかになってくる……といったあらすじ。

『火星の人』のような軽妙な語り口は健在で、読みやすいページターナー。それでいてけっこう予想しない方向に話が転がっていく。今回はSF設定もいろいろあって、描写が細かいがゆえに人によってはかえって「いやそれはさすがにそうはならんやろ」という感じになる気もするし、ちょっと雑な部分もあると思うが、個人的には楽しめた。

この面白さってなんだろう。『火星の人』もそうだったが、なんというか、科学に対する信頼感というか、未知の現象を科学で解き明かしていくことの楽しさというか、そういう部分があって、面白さがその土台の上に立っている感じがあるよね。ある意味では理系な人々に対する慰撫でしかないとも言えるんだが、でもやっぱりそこがいいんだよな。そういう面では、『Dr. STONE』とかと相通ずるようなところがある。

しらんけど人気あるだろうし、邦訳はすぐ出ることでしょう。お楽しみに。

F#でray tracing

先日F#に入門してみた。F#は.NET環境で動作する関数型言語で、OCamlの方言程度のものといった雑な認識だったんだけど、入門してみてその認識は改められた。OCamlとはぜんぜん違う、ML系の別個の言語だといっていい。

F#はML系列の言語だが、独自の構文規則があって、とくにインデントに意味をもたせているところがユニーク。これによって余計なセミコロンなどがかなり省略できるのは面白い。let … in 構文みたいなのもinなしで書かせられるし、またF#はOCamlと同じで、リストの区切りがセミコロンになっている([1; 2; 3] のように書く。[1, 2, 3] は [(1, 2, 3)] と同じと解釈され、タプル1つのリストとなる)が、リストの各要素で改行すれば要素区切りのセミコロンすら省略できる。

F#は.NETに標準添付されていて、特別なインストールを必要としないというのも面白い。.NETをインストールすれば インストールは完了している。dotnetコマンドでdotnet fsiを打てばreplも立ち上がる。

さて、入門といってチュートリアルドキュメントを適当にいくつか眺めただけではちょっと面白くない。練習がてらなんかしらのプログラムを書いてみたいところだけど、とくに書きたいプログラムのアテもない、というわけでRay tracing in a weekendというやつをF#でやってみた。もとのコードサンプルはC++で書かれているが、これをF#で書いてくことの面白さみたいなものもあるだろう。たぶん。

速度を出すことは目標ではないので遅いだろうし、実装もしょぼいとは思うが、書いたものは想定通りに動いて、the next weekまで修了したので目標を達成できたとおもう。じつはray tracing実装は初めてだったので、そこもまぁ良かった。

で、書いてみることでいろんな言語機能を使ってみたりして楽しく、F#の良さも楽しめたと思う。F#はOCamlと違ってオペレータのオーバロードもできるので、ベクトル同士の足し算とかを + で書けるように定義できたりしてラクだったりした。

一方書いていてこれはいまいちだなあと思ったところもいくつかあった。最大のものは、意外とオブジェクトが相手だと型推論がちゃんとしてくれないこと。具体的には、たとえば乱数オブジェクトから乱数を引いてランダムな3次元ベクトルをつくる関数、

let random_vec rnd = Vec3(rnd.NextDouble(), rnd.NextDouble(), rnd.NextDouble())

みたいなのを書いてみたとすると、

error FS0072: Lookup on object of indeterminate type based on information prior to this program point. A type annotation may be needed prior to this program point to constrain the type of the object. This may allow the lookup to be resolved.

みたいなエラーが出てくる。適当に型推論してくれることはなく、オブジェクトを引数に取る場合はかならず型を指定しないといけない。

let random_vec (rnd: Random) = new Vec3(rnd.NextDouble(), rnd.NextDouble(), rnd.NextDouble())

これはちょっといけてない。レコード型などほかの型なら推論してくれるんだけど……。ちなみにOCamlはこういうのの型推論もよろしくやってくれる(NextDoubleというメソッドを持つオブジェクトなら良い、みたいに推論してくれる)。これは言語そのものというより、バックエンドである.NETのオブジェクトの構造を反映しているからだろう。ほかにもインタフェースにキャストしてあげたりといった面倒が意外とあった。

まぁでも久々に関数型言語で遊べてそれなりに楽しかったな。また何か使う機会をうかがいたいところ。

移転したコーヒー屋に行ったらデルモンテ工場跡地があった

好きでよく通っていたChromatic Coffeeというコーヒー屋が移転していた。この移転の話もこれはこれでちょっとややこしく、変な話なのだが、この記事の本筋とは関係ないのでひとまずおくとして、移転したのだ。

あたらしい場所はサンノゼのCalTrain駅からやや南にいったところ、正直あんまり足を踏み入れたことのない場所だ。治安がわるいとかではまったくないだろうが、shelter-in-place(自宅待機命令)の関係で営業しているのかもよくわからない。コーヒー豆は通販できるのでまったく営業していないわけじゃないだろうが、よくわからん。

というわけで行ってみた。8月頭のことなのでちょっと前のことだけど。

行ってみたらコーヒー屋が入居していたのは工場跡地を改装したようなノコギリ状の建物だった。周囲は大きなアパートが多い。もともと工場があったエリアの再開発地域なのだろう。ほかの入居店舗は自転車屋や氷屋、ビアバーなど。コーヒー屋としては営業はしていて注文もできるが、店内での飲食はもちろんできない。豆のローストはこの場所でやっているようだ。そこでコーヒー豆を一袋買い、ついでに妻と飲み物を一杯ずつ頼んだのだが、さてどうしたものか。駐車場の日陰で立ちのみをしている人もいるけれど、とおもって携帯電話の地図を見てみるとすぐ近くに公園があるっぽいので、そこにいってみることにしたのだ。

さてそのDel Monte公園という公園についてみたのだけど、道のむこうに見覚えのあるロゴがある。思わず二度見したが間違いなくデルモンテだ。デルモンテっていえばなんだろう。ケチャップか、トマトジュース? あれ。あのデルモンテのロゴだ。なんか貯水タンクみたいなやつにでかでかと描いてある。

IMG_20200802_155540

かなり近寄って撮った写真なので角度の関係でロゴがとても分かりづらいけど、よーくみるとおなじみのデルモンテのロゴが見て取れると思う。

デルモンテは日本だとキッコーマン傘下のブランドだが、もとはカリフォルニアの会社だ。もともとモントレー(シリコンバレーから南に行ったところにある街。今は水族館で有名)の近くに、かつてデルモンテホテルというリゾートホテルがあった。このホテルに卸す食料品を扱うということで(当時の)有名リゾートホテルの名前をつけたブランドがデルモンテなんだそうだ。そういう事情があるから、モントレーとサンノゼはそれなりに離れているとはいえ、関連する施設があってもおかしくはない。おかしくはないが気にはなる。

コーヒー片手に周辺を散策したら、史跡を紹介するパネルが道端に設置されていた。それによると、たしかにここはもともとはデルモンテの缶詰工場でフルーツ缶詰とかを作っていたものらしい。人口の多いサンノゼ近郊であり、線路の近くという地の利もあったため、けっこう大規模な工場があったのだそうだ。はじまったのは1893年(19世紀!)で、それが1999年まで工場として残っていたというから、けっこう最近だ。シリコンバレーともてはやされてドットコムバブルで湧いていたころ、いっぽうこのへんには缶詰工場があったりしていたのだ。

もちろん「けっこう最近」といっても20年以上前のことである。工場の跡地はやがて再開発され、いまではアパートになったり公園になったりしている。アパートになっているが、いわれてみれば工場跡の面影が残る構造だ。妙に広々とした入り口の道、意味もなく立ち並ぶコンクリの柱や建物の感じ。そしてなぞのデルモンテのロゴ入りタンク。

IMG_20200802_161521

公園もデルモンテの名を残しているだけじゃなくて、路肩の構造物が果物のかたちをしていたりして名残りがある。

コーヒー屋を追っかけに来ただけだったのだけど、なかなかおもしろいものを見た。近隣住民のみなさんもいっぺん行ってみると面白いと思う。

zig言語でtomlパーサを書いてみた

数ヶ月前にzig言語というやつの存在を知って、これはちょっと面白そうだなと思ったので、勉強がてらなにかやってみよう、と思っていた。ある日、tomlのパーサはどうだろうかと思い立ってしばらくやっていて(Ghost of Tsushima で作業が中断したりしつつ)、まあまあ出来上がってきたと思うので、現在のところのソースコードをgithubに置いておいた(https://github.com/jmuk/zig-toml)。

というわけで、zig言語をちょっと書いてみた感想を残しておく。なお、利用したのはzig 0.6.0なので、今後いろいろ変わってくる可能性もあることは強調しておきたい。

zig言語のよいところ・興味深いところ

型の扱いがzigでは興味深いところだった。zigはかなりいろんなところでcomptimeというマーカをつけてコンパイル時にコンパイラが事前処理をするようなことができる。これでたとえば、C言語であればマクロ展開させるようなコードも自然に書けるしわかりやすい。

さらに型もコンパイル時の値として扱うことができ、型によって処理を変えるような関数もかんたんに書ける。さらには、型を受け取って型を返す関数によってテンプレート・総称型を実現している。たとえば、

fn List(comptime T: type) type {
    return struct {
        items: []T,
        len: usize,
    };
}

のように書ける。これはちょっとかっこいい。型レベルの情報(たとえば構造体のフィールド名など)はコンパイル時には展開できて、ちょっとしたリフレクション処理のようなこともできる。リフレクションはコンパイル時にしか発生しないので、実行コードはおかしな遅さにはならない。

また、エラーになりうる型、オプショナルな型などはいくつか特別扱いしている点も面白い。null安全性なども担保されているし、Go言語などと違い、エラーの場合にはエラーだけが返るようになっていてわかりやすいし、エラーが値でありながらtry構文などにより帯域脱出っぽいようにも書けるのもよさそう。

zigには(たぶんGoの影響で)defer文があるのだけど、errdeferという「エラーのときだけ実行される」処理というのが書けるのはかなり素晴らしいと思うというか、正直Goにもこれがほしい。これもエラーが特別な値でありエラーになりうる型を特別視しているところとうまく結びついている。

困ったところ、微妙なところ

メモリ管理はやっぱり大変。zigはGCのない手動メモリ管理言語であり、Rustのようなオーナーシップのようなものもない。C言語と同じでメモリ管理は手動で頑張る必要がある。どこでメモリがアロケートされ、誰がオーナーで、どの操作でオーナーシップが移りうるのか、といったことは言語レベルでいっさいサポートがない。こういう言語で書くのは久しぶりで、面倒さはやっぱりある(defer / errdefer でかなり軽減されているはずだが、それでも)。

メモリ管理については、zigはアロケータというオブジェクトが標準で定義されていて、好きなアロケータを扱えるようになっている。これはいい面もある。ある種のオブジェクトをひとまとめのアロケータで管理してまるごと破棄したり、その範囲を越えたアロケーションを禁止したりできるし、たとえば、既存のアロケータをラップしたリーク検知アロケータも標準から提供されていて、これを使ってテストコードを書けばコードのメモリリークはかなり容易に検出ができる(ただ、どこでリークしたかという情報までは取れないので修正の厄介さはそれほど軽減されていない気がするが……)。

一方これは、どのアロケータがどのオブジェクトのデータを割り当てたのかということがまったく自明でないことを意味する。たとえばツリーのようなデータ構造が不要になったので破棄したくなったとして、再帰的にノードをたどっていって順次廃棄していくというコードを書くだろう。でも、ノードによって異なるアロケータから割り当てられていたということも原理的にはありうるから、ノードごとにただしいアロケータに対して廃棄するような再帰処理を正しく書くのは、わりと自明ではない。

実際、標準のデータ構造でも、データ構造からアロケータへのポインタを持っていることが多い。リソース開放用のメソッドは deinit と呼ばれる関数で行われるが、このメソッドはパラメータを取らず、自分自身が参照するアロケータにリソースの開放を依頼するかたちになっている。私もこの構造に従ったし、それはそれで便利なんだが、なんだかありとあらゆるデータ構造がアロケータへの参照を持っているというのはいいことなんだろうかという疑問がないでもない。もう少しうまい仕組みはないものか。

defer / errdefer については自分がGo言語にひっぱられすぎている面もあるが、ちょっと戸惑ったところもあった。zigのほうがわかりやすいというか直感的ではあり、defer / errdefer はそのスコープを抜ける時にしか発動しない。その一方、

while (i < input.len) : (i+=1) {
  var v = Value{.Table = Table.init(self.allocator)};
  errdefer v.deinit();
  ....
  if (xxxx) {
    break;
  }
  results.append(v);
  if (yyyy) {
    return i+1;
  }
}
return ParseError.FailedToParse;

のように書いた時、このコードがエラーを返してもvが開放されることはないので困ったということもあった。関数全体としてはエラーだが、errdeferの設定したスコープではエラー終了していない(正常にbreakしている)ためにerrdeferは実行されない。breakのかわりにその場でreturnでエラーを返すとerrdeferが実行される。ちょっとわかりづらいと思った(zigに慣れていないだけかもしれない)。

ほかにも、標準の文字列リテラルは[]u8でしかないというのはけっこう戸惑いがあった。ちょうどいい文字列型のようなものは存在しないし、文字列リテラルからかんたんに利用する方法もない。std.ArrayList(u8)がわりと使えるが、ArrayListは対象の文字列をつねに所有しているので作るなら毎回コピーするしかない。使いやすいユーティリティ関数も少ないし、もうすこしできの良い文字列型がほしい。

また、先述したように総称型が「型を受け取り型を返すコンパイル時関数」なのはかっこいいんだけど、これは裏を返すと、ある型に対して「これはArrayListの型である」かどうか、というチェックは書けない。ArrayList自体はコンパイル時関数であって、いま手元にある型Tが、どのコンパイル時関数から生成されたものなのかなんてことはわからない。tomlパーサのようなものを書くとき、呼び出し側が指定したデータ型の構造に応じてパース結果を埋めていくみたいなことをしたいわけだけど、そういう理由により、ライブラリの定義する型をうまくあてはめるのはかんたんではないという印象を持った。

もうひとつ、エラー型が単純なenumなのは正直納得がいかない。tagged unionもありにしてほしい。パースエラーが発生した時、エラーの発生箇所を埋め込みたいんだけど、できない。パーサーオブジェクトに「最後のエラーの箇所」みたいなプロパティを与えるみたいな方法がありうるだろうけれど、どうしてもアドホックになってしまう。まあtagged unionにした場合、エラーオブジェクトをアロケートしている途中で発生するエラーみたいなややこしい問題がありうるだろうから、この設計方針はわからないでもないのだが、しかし不便じゃないか?

けっきょく、面倒なので ParseError.FailedToParse だけを返すコードになっていて、どこでエラーになったかは検出する方法がないようにした。そのほうが実装が楽だから……なんだけど、テストが失敗したときなどはわりとつらい目にあってしまった。

tomlについて

tomlは(主にCargo.tomlで)ちょっとだけ書いたことがあるくらいで仕様のことはあんまり詳しくなかったので、パーサを書くのはtomlの詳細についてもいい勉強にもなった。人間にとってわかりやすい仕様だしあんまり長くなく、複雑度が低くて良いというイメージであったが、人間にとってわかりやすい仕様は、パーサを書きやすい仕様ではないという学びもあった。

とくに面倒なのは重複するキーの禁止と、[]で設定するテーブルとインラインテーブル・インラインアレイで設定されるものの再定義が禁止されるという仕様。単純にキーに対してオブジェクトをトラバースしていくだけなら実装が単純なんだけど、このパターンは上書きになってだめ、このパターンはむしろ許される、みたいなルールがいくつもあって、けっこうわからない。仕様に書いてある例をテストケースに移して確認することにしたけど、当初の実装方針だとぜんぜんだめなパターンもけっこうあって難しかった。

Mt. Umunhumに登った

妻に教えてもらうまで知らなかったのだが、Mount Umunhum という山がある。南側サンタクルーズ山脈のなかの山で二番目に高い(標高1,063メートル)。また、山頂に直方体の建物があるのも特徴で、教えてもらってわかってみれば、たしかにたまに山を眺めてみると、山頂にあきらかな人工物が建っているやつがあってあきらかに異様なかんじがある。それがUmunhum山だ。

山頂の建物は元アメリカ空軍の施設で、今は閉鎖されている。入れはしないが、かなり近くまで行けるらしい。

山頂の施設のすぐちかくまでは車で行ける(空軍の施設があったぐらいなので、そのころに整備されたのだろう)。また現在は近隣エリアはSierra Azul Open Space Preserveになっていて、歩いて登るハイキングロードも整備されている。

これを登ってきた。ルートは https://www.alltrails.com/trail/us/california/mount-umunhum のもの。往復約7.7マイル、高低差が約1100ftくらい。結論としてはだいたい4時間ぐらいかかりました。

IMG_20200510_144000

歩きはじめ。この四角いところまで歩いて登るということだ。

IMG_20200510_144621

山道はだいたいずっとこんなかんじ。道は整備されていて歩きやすい。

IMG_20200510_154509

途中、なんらかの廃墟があった。20世紀前半ころにはこの辺に住んでいた人もいたのだという。めちゃくちゃ辺鄙な場所だが……。ただ、隣接するAlmaden Quicksilver County Parkは、かつて金鉱のために辰砂を採掘していたらしく、こういうところにも人が住んでいたのだようだ。

IMG_20200510_161024

かなりちかづいてきた。ほぼゴール。

IMG_20200510_164158

例の直方体。間近で見るとでかい。

ちなみにこの建物がなんだったのかというと、冷戦時代のミサイルや敵機を監視するためのレーダー基地だったのだという。当時は上にでっかいアンテナがついていたらしい。1957年に建設され、冷戦のかなり初期から運用されていたものらしい。80年代には役割を終え、廃棄された。それからずっとこのままらしい。アンテナだけ撤去されたのが何故なのかはよくわからない。

IMG_20200510_183638

帰りに気づいた、トレイルの脇で遺棄された車。ぼろぼろになっている。

途中の道は鳥の鳴き声はよくしたが、あまり動物は見かけなかった。リスがいたのと、鹿は一匹だけ見かけた。鹿はそれなりにいるようだ。

それにしても冷戦時代の遺物がこんなふうに残っているんだなぁ。なんとなく感心してしまった。

ところでいままでカタカナ化してこないできたが、Umunhum山、なんて読むかわかるだろうか。ぜんぜんわからないので我が家では「ウムンフム」とかテキトウに呼んでいた。グーグル地図では「ユマンハム」となっているが、これが正しいとも限らない。

それで調べてみたらKQEDの紹介動画が出てきたが、hは読まずに「ユマナム」と読むものであるらしい。語源は現地のネイティブアメリカンであるオローニ族(Ohlone)の言葉のようだ。

動画ではいろいろほかのことも説明してくれている。たとえば、空軍がこのレーダー施設を運用していたころは、近隣に隊員やその家族のための宿舎があり、ちょっとした街のようだったこと。ところが空軍が撤退してからはそのままじつに30年以上放置されており、ちょっとした廃墟の街と化していたこと。ついに片付けの予算が連邦政府からおりたのが2009年のことで、その作業中であること……。もしかしたら将来、この直方体の建物もなくなるのかもしれない。老朽化したら危険なのは確かだろうし。

動画では、かつてレーダー基地で監視業務についていた元隊員まで登場していて面白い。

意外なところで歴史の面白さも感じられるハイキングでした。

Shelter-in-place (自宅待機)の2週間

わたしの住むカリフォルニア州サンタクララ郡が、shelter in place order(自宅待機命令)を出しておおむね2週間が経った。なにかの足しになるかとTwitterで日記的な投稿をしていたのだが、いったんまとめておく。東京・日本とは事情が様々にことなるが、雰囲気などが伝わったり、なんらかの参考になればさいわいだ。

用語について。いろいろな用語があるのだが、ロックダウンという言葉は使わないことにしている。というのも、街のロックダウンは武漢やイタリアなどの制限のかなり厳しい命令であるかのように思えるからだ。たぶんそういうニュアンスから、アメリカでは各地域でいろんな言葉で自宅待機の指示を出しているのだとおもわれるが、ともあれカリフォルニア州ではshelter in placeという言葉が広く使われている。homeという語でないのはホームレスの人々なども対象であることが念頭にあるのだとおもうが、基本的には「自宅待機」のような意味なので、そう訳すのがいいと思っている。

制限内容については、かんたんにいえば「必要不可欠な業務(essential business)はそのまま維持される」「そうした必要不可欠なサービスや商品の買い出し、必要不可欠な活動(essential activity)をのぞき、自宅にい続けること」といった状況になっている。essential businessについては、スーパーなど食料品店、工作用具店、銀行、病院、政府機関、ガソリンスタンド、車などの修理、水道管修理、ゴミ回収などが該当するとなっている。レストランはすべて営業禁止。ただしテイクアウトの注文は受け付けてもよい。タクシーや配車アプリも可能。公共交通機関も利用可能。essential activityにはちょっとした散歩やジョギング、ハイキングなどの余暇的活動も含まれる。ただし外出先ではsocial distancingを保つこと(2-3メートルは離れること)。友達などと集まるのも禁止。

こうした制限はそれなりにリーズナブルだし、封鎖というものものしい言葉よりはゆるいとおもう。

ただ実際にはゆるゆるというわけにはいかない。店によって、業態によって、ものすごく影響がある。営業時間を短縮した店もあるし、こんなんじゃやってけないと一時閉店した店もある。営業をつづけていても店内立ち入りを制限したり、注文はオンラインでしてピックアップのみの営業になったりすることもある。

たとえばスーパーは濃厚接触を避けるために入場制限をしていて、入場列がおおく見られるようになった(ぜんぜん並ばないスーパーもあるけど)。入場列も2mとかずつ離れて並ぶ必要がある。レストランについては、これを機にテイクアウトをはじめた店もあるが、残念ながらやはり一時閉店を決めた店もある。ある日には営業していても次の日には急に閉まることもある。ハイキングはオッケーといっても人が混み合えばsocial distancingを保つことはむずかしく、けっきょく国立公園や州立公園などは閉鎖されてしまったりもする。制限の内容から現実を想像するのはなかなかむずかしい。テック企業の従業員であるわたしみたいな人間は比較的のんきに生活できているほうだとおもうが、そういう人間であってもけっこうなストレスはかかる。もっと直接的に影響があるなら推して知るべしだ。

スーパーなどのパニック買いや買い占め等の影響についても書いておく。shelter in place発令直後はずいぶん混雑して、スーパーからいろんなものが消えていった。買えないものもけっこうあった。ただ食料品の流通はわりにすぐに回復した。とくに生鮮食品はほぼ平常時といっていいレベルになっている。冷凍食品系は店頭在庫はいっとき空になったが、すぐ回復した。缶詰類は在庫薄。それと小麦粉がかなり売れているようだ。保存がきくし、いろんな料理に使える。それと在宅で暇になったのでパンを焼いてみる人が増えているらしい。ミネラルウォーターもけっこう品薄なようだ(うちはBRITAを使っているので影響がないが)。ドラッグストアではいわゆる風邪薬的なものが品薄なようだった。

トイレットペーパーはいぜんとして品薄がつづいている。自宅待機のために買い足しておきたい需要増が大きいのと、また各家庭の消費量が増えているためではないか、という話もあって説得力はある。ぜんぜんどこにもないというほどでもないが、買えるかどうかは運とタイミングといった状況はまだ続いている。

食生活については、夕食はこれまでも基本的に自炊していたのであまり変化がない。昼食は地元のレストラン支援もかねてデリバリーを頼んでみたり、でもまあかんたんなものをつくるほうが多いかなとなっている。朝は牛乳一杯とか、そういうふうにしている。ところで自宅待機生活による食生活の変化で太るというパターンと、逆に痩せるというパターンがあるけれど、わたしは後者。ふだん会社にあるスナック類を食べてたからかねぇ……。

以下、時系列にツイートを紹介しておこう。

3月17日。初日。あちこち散歩したり様子を見に行ったりしているが、前日までとは大差ないかんじ。お店もけっこうやっている。

18日。スーパーの在庫を眺めたりしている。状況はたいしてかわっていない。

19日。まだもつとはいえやや心もとなくなってきたトイレットペーパーがこのタイミングで買えたのは僥倖。上司もこの日の朝にCostcoにいってトイレットペーパーを無事ゲットしていたがけっこう並んだようだ。ランチは近所のラーメン屋のデリバリー。

20日。電機屋のBestBuyがふつうに開いていて入場列ができていたとおもったら、予約注文した『どうぶつの森』のピックアップ列だったのはさすがに笑った。

21日。土曜日。週末ということで気晴らしにハイキングにでかけた。Rancho San Antonioはサウスベイからは激近なわりにけっこういい。駐車場は混んでいたが、ここはいつでも混んでいるし、エリアに出てしまえば人口密度はさほどでもなく距離を取るのは容易だ。でも今後は閉まっちゃうのかもなぁ。

22日。先日とおりがかったBestBuyに入れなくなっていることに気づく。ボバティ屋も閉まってしまった。期間が長期化すると、だんだん閉店する店が増えていく。悲しみ。

23日、月曜日。ふつうに仕事。夜に散歩というかんじ。

24日。チャパグリつくってます。実はshelter in place中すでに2回めのチャパグリだった。

25日。ランチは自炊だったり外食だったりを適当に繰り返している。外食はDoordashが多い。午後の散歩が日が暮れてからになってしまったが、なんだか星が綺麗だなと思った。交通量が激減して大気汚染がずいぶん改善したという話もあったので、その影響なのかもしれない。気のせいなのかもしれない。ちなみに公園はふつうに散歩できて、園内の歩道を散歩しているひとたちがそこそこ見えるが、遊具はテープなどで封鎖されて使えなくなっている。

26日。特筆することはあまりない。写真のパスタはけっこうおすすめ。パスタとソースが一体化しており、お湯に入れるとソース分が溶けて、水気がとぶくらいまで茹で続ければ完成というもの。楽だしうまい。アメリカでもわりとめずらしいインスタント食品だとおもうけどおすすめ。

27日。やはり特筆事項なし。このタイ料理は辛すぎず、なんとも美味かった。とくにトムヤムクンはいままで食べた中でも一番美味かったかもしれない。

28日。週末。買い物にでかけた以外はとくにやっていない。

29日。日数まちがえてツイートしている。とおくからの歌声はヒマになった近隣住民がうたってるのだとおもう。Popeyesは数ヶ月前にはチキンサンドがえらい人気で大行列だったのだが、いまはもちろんそんなことはないとおもう。

30日。月曜日。ほんものの14日目。

31日。こんどは近隣住民のだれかがウクレレを弾いていたようだった。この日、shelter in placeのあたらしい命令が発令された。ただ制限内容を細かく明確化したり、これまでいきなり公園の遊具を使えなくしたりしていた行為を明文化したり、といった面がおおきいように思える。あと自宅にいろよという期間が伸びた。

4月1日。茹でるだけのパスタその2。

 

Performance of Opensource ApplicationsでAudrey Tangの章を読む

このところAudrey Tangという人がよく話題になっている。台湾のデジタル担当相みたいな大臣だという人だ。この人をとりあげた記事は日本語でもいくつかあるが、たしかにどれもおもしろい。

さてこのAudrey Tangの書いた技術文書が、Performance of Opensource Applicationsという本に収録されている。いろんなオープンソース開発者による、ソフトウェアの性能に着目した技術記事をあつめた本だ。ネットで公開されていて無料でも読める

本全体もひととおり読んでみたんだが、まあなんかそれほど感心するような内容でない章もそれなりにあった。ダメとかじゃなくて、なんというかふーーーん……で終わってしまったような……まあ読者の興味の方向性で面白さがかわるようなトピックだとおもうので、どの章がどう、という話は控える。たださいわいにして、Audreyの文章は個人的には面白い方に分類される内容だった。

この章ではSocialCalcというスプレッドシートアプリの性能改善について解説している。スプレッドシート(エクセルとかみたいな)だが、ブラウザでアクセスするウェブアプリであり、シートをみんなで共有できる。グーグルスプレッドシートとかみたいなやつ。ただしオープンソースでだれでもインスタンスを立てて動かせる。

ただユーザ数が増えたりデータが増えてくると性能的にどんどんつらくなっていったんだという。というのも、セルの計算のロジックやスプレッドシートのロジックが基本的にJSで書かれていたからのようだ。よくわからないけど、たぶんセル内の演算や関数なんかにもJSをそのまま使えるようになっていたのだと思われる。設計としてはすっきりしているけど、あまりにも更新が多いとユーザはアクセスするたびに全更新データを受け取って計算しないことにはスプレッドシートの最新状態を描画できなくて、これはいかにもつらい。

それで最終的には、Perlで書かれたサーバをNode.jsに移植し、同じコードでサーバ側でもスナップショットを取れるようにして、性能を改善した。さらにサーバサイドJSのボトルネックをさぐって性能を改善していった、という過程が説明されている。

本自体が2013年ころに刊行されており、書かれている出来事はそれよりちょっと昔だとおもわれるので、いろんな細部に時代を感じる面もある。そもそも当時のnodeってめちゃめちゃ初期だし、coffeescriptとかが熱い時代だったんだなとか。今でこそ、そりゃそんなものならNode.jsでいいでしょって思うかもしれないけど、必ずしもそれ自体がただしいかどうかは事前にはわからなかったのだろうな……といったところにも、面白さがある。

ところで、なんでAudreyがそんなソフトウェアに貢献していたんだろうか。しかもシートを数千人でシェアすると困るよね、みたいなことを言っているが、そんなに大規模にシェアすることってあるんだろうか? そういう動機みたいな話はとくに触れられていないのだけど、オープンガバメント系の運動に参加してきたがゆえにこういうプロジェクトに貢献していたんじゃないか、それがAudreyの今の姿につながっているようにも思えて、そこもまた興味深くおもえてくるのだった。