SVX日記

　 この歳にもなると着々と老眼も進行し、近眼で見えない「遠く」と、老眼で見えない「近く」が狭まってくる。そうなって初めて「老眼ってそういうことだったのか」などと感心するわけなのだが、その一方で、腕を伸ばした指の先の前後のわずかな範囲だけが(屋内用メガネでの)スイートスポットになってしまっていることにも気づく。まぁ、普段の作業環境がその状態なので、それはそれで構わないのだが、問題はノートパソコンだ。キーボードを適正な位置にすると、画面の位置がその範囲から外れるのだ。

　 微妙に「近すぎて見えない」という「老眼の影響」エリアに入ってしまう。それはメガネのせいでもあるので、外すこともできるのだが、そうすると「遠すぎて見えない」という「近眼の影響」エリアに入ってしまう。この場合に取りうる選択は「メガネをして顔を遠ざける」「メガネを外して顔を近づける」なのだが、前者だと腕の長さが足りない。まぁ、関節をはずして腕をのばし、その激痛を波紋エネルギーでやわらげてもいいのだが、単純に画面が遠くなると字が小さくなる問題もある。したがって後者を選ばざるを得ず、ものすごい猫背姿勢になってしまうのだ。

　 いや、待てよ。ノートパソコンの距離がスイートスポットになるメガネを作るという手もあるか……14インチあれば距離が近くなる分、22インチと同程度の面積にはなるが……いやいや、さりとて両立ができるわけではないし屋内での生活において中距離がより見えづらくなってしまう。うーむ、ごく一般的なアイテムであるノートパソコンは年寄り向けではなかった、なんて気づかなかったなぁ。

　 さて、それはレンズ的な話であるが、今回は画素的な話だ。緑内障という「視野が欠ける」という病気がある。カメラでいうと一部の「画素」が死んでしまうという症状であると言える。

　 面倒なのは不思議なことに「それが自覚しづらい」ということだ。誠に不思議なことに人間の脳には「補完してしまう」能力があり、多少は視野が欠けてもそれに気づけないようなのである。「そんなアホな、自分なら絶対に気づくわ」と思うかも知れないが、それはほぼあり得ない。というのも、すべての人間には「盲点」という「仕様上の視野の欠損」が備わっているからである。「盲点 チェック」などとググってみれば、その不思議を体験できるはずである。

　 で、記録を辿ったところ、ちょうど20年前に眼科に検査に行った日記があった。その時は「問題なし」ということだったが、この20年で進行していたりはしないだろうか。簡易的にでもその時と同じような検査をしてみたいものだが……意外や意外、似たような動画が見つからない……ということで作ってみた。

　 最近は「我が辞書に自己責任という言葉はない」というお方が多いので、詳しいチェック方法は敢えて書かないが、以前に自分が眼科で実施したのはこんな感じの検査であった。で、今回これで自分で検査した限りでは、特に問題はなさそうであった。

　 ちな、今回、動画の作成に使ったのは、ほぼ自製のツール。過去にメトロノームを作ったのとほぼ同じ要領である。

#!/usr/bin/env ruby
# coding: utf-8
 
require 'bundler/setup'
 
require './TrueLegacyGraphicsCairo'
 
# 1920 x 1080 = 16 : 9 = 480 x 270 = 16 x 9
# $ ffmpeg -y -r 24 -i checkRyoku.d/%06d.png -i ../cuickdtm/midi/checkRyoku.wav -vcodec libx264 -s 480x272 -r 24 -b 600k -acodec libmp3lame -ac 2 -ar 48000 -ab 125k checkRyoku.mp4
 
Dir.mkdir(path = 'checkRyoku.d/') rescue true
 
fps = 24
 
(16 * 9 * fps).times {|n|
#   n > 36 and break                            # for DEBUG
    print(n % (10 * fps) == 0 ? n / fps : '.')
 
    win = LegacyGraphics.new(0, 0, 0, 0, 270, 480, 16, 8, 0, { :file => path + '/%06d' % n, :type => 'png' })   # png/pdf/svg/ps
 
    win.circle(240, 135, 3, '#800000', 'f')
 
    sec  = n / fps                              # 秒
    usec = n % fps                              # 秒以下(0-23)
    if(usec < 3)
        y = sec / 16                            # 縦位置
        x = sec % 16                            # 横位置
        win.circle(x * 30 + 15, y * 30 + 15, 2, '#00C000', 'f')
    end
 
    win.close
}

<DSP OFF>
<MIDI midi/checkRyoku>
<WAVE midi/checkRyoku:M:44100>
 
! clear
! t60
! @13
 
# 16 x 9
! A2 4 A2 4 A2 4 A2 4 A2 4 A2 4 A2 4 A2 4
! A2 4 A2 4 A2 4 A2 4 A2 4 A2 4 A2 4 A2 4
 
※繰り返しx8
 
<END>

　 ほぼ自製のツール、っつうか、8bit時代には標準搭載されていた機能を復刻したようなもんだよな、これ。8bit風グラフィックライブラリlegacyGrp、8bit風ミュージックライブラリcuickdtmの最新版を置いておく。なんか前回のエントリに引き続き、物件更新祭りやな。

　 老眼の進行を感じていることもあって、ディスプレイをひとまわり大きくしてみようかと思い立った。

　 これまで使ってきたディスプレイは「DELLの2209WA」というヤツで、安さに驚いて買った記憶があるが、もう14年近くも、ほぼ何の不満なく使ってきた。ファクトリモードで稼働時間を見てみたら23391時間。正味3年弱。実に人生の20%をこれ見て過ごしていたことになる。実に素晴らしいプロダクトだ。つうか、それに2万円しか払ってなかったことに申し訳ない気がするくらいである。誠に申し訳ございません。DELL様、仏様。

　 現在もまったく問題なく動くのだが、イザ壊れたら影響が大きいので、とか、バックライトが蛍光管だから消費電力がね、とか、誰に向けてでもなく言い訳をしつつ、今日からバックアップに回ってもらうことにした。

　 で、次期ディスプレイとして選択したのが「DELLのS2721NX」というヤツである。そりゃ、DELL続投しかない。だけど、12,800円。申し訳ないとかいいつつ、またそんなローエンドかよ。つうても、それで十分なんだものなぁ。

　 早速、使い勝手を試してみる。

　 なかば冗談で縦画面を試してみたのだが、迫力はあるものの、垂直同期の都合でスクロール時に横向きに気持ちの悪いティアリングが起きる。60Hzでは60Hzの、75Hzでは75Hzの、だ。これはちょっと実用に耐えないな。

　 こっちは悪くない。横に伸びた分を有効に活用できているし。つうか、14年前とやること変わってないのはどうなのよw。

　 それはそれとして、主な仕様の違いは以下。

　 27インチだとフルHDよりも高い解像度を持つ製品が多いのだが、それは考慮の上で選択しなかった。単に価格の問題ではなく、老眼対策という意味では解像度の向上でフォントの品位が上がることの価値は低いし、リモートデスクトップ用途だと通信帯域が厳しくなるし、レゲーの用途にもまるで意味がないためである。

　 イザ使ってみると、ドットピッチが1.1倍になっているおかげで、PC側の設定を変えずとも文字が少し大きくなり、字は読みやすくなった。しかし、縦のドット数がそう変わらないのは想定内だが、横のドット数は増えてもあまり恩恵を感じないな。うーむ、思い切ってもっと大きいのを選ぶべきだったか。

　 ちなみにサイズは大きくなっているが、重量は軽くなっているので、モニタアームの調整は必要なかった。技術の進歩だなぁ。

　 せっかくなので、ファクトリモードに入ってみた。

　 おっと間違えた。それはファクトリモードではなく、ファクトリオモードだ。

　 ボタンの配置は違うが、入り方は2209WAと同じだった。稼働時間は2時間弱。むふーん。どうぞこれからよろしくお願いいたします。

　 一段落してしまった気分でしばらく放置してあった自作のレースゲームだが、近所のサーキットを走ってみたくなったので開発を再開することにした。

　 まずは画面切り替えを故意に遅延していたのを是正する。厄介なのは地図タイルをネットワーク越しに得る都合上、故意でなくても少なくない遅延があることだ。処理を集中することなく、段階的に処理が進むよう、こんなコードを書いてみた。

draw: ->
    n = 0; while(n < @tile_reqs.length)
        tile_req = @tile_reqs[n]
        unless(tile_req[3])
            tile_req[3] = new Image                     # Image インスタンスを生成
        else unless(tile_req[4])
            tile_req[3].src = tile_req[2]               # Image.src を設定
            tile_req[4] = true
        else if(tile_req[3].complete)                   # 読み込み完了？
            @constructor.pats[0] = tile_req[3]
            @put_source_plane(@constructor.pats, 0, tile_req[0] << 8, tile_req[1] << 8) # ソースプレーン(回転前)に転送
            tile_req[5] = true                          # キューから削除せよ
        if(tile_req[5]) then @tile_reqs.splice(n, 1) else ++n

　 要するに1フレームで複数の処理をすることを避け、分散させるわけだ。まだ試作段階なので、分散のアルゴリズムにはチューニングの余地があるが、とりあえずそれほど大きくはツッカカることなく走り続けられるようになった。

　 例によって、録画の都合で15FPSになっているが、実際は60FPSで動いている。マップの更新遅延と多少のガクつきは実際にあるが。

　 そこで改めて表題の問題だ。現状スペースキーを押すと固定速度で前進走行するようになっていて、それは0.3という適当な値を与えている結果なのだが、いったい時速何kmで走っているのだろう。別に「ゲームなんだから考えません」という方向性もあろうが、以前に書いたように「実際に遊んだときに実際のF1のラップに近いタイムが出るようにしたいと思っている」のであれば、その辺をキッチリさせる必要があるのだ。

　 まずは、0.3で走っている現状の速度を求めてみよう。どうやるか。実際にコースを一定距離走らせ、経過時間を求めて算出すればいい。そうなると長い直線を持つコースが望ましいが……そうだ、昔、自分が働いていたつくばの土木研究所の試験走路を走らせてみよう。

　 それより、ぼちぼちコースを選択するインタフェイスも欲しくなってきたな。URIにクエリで与えられると実用的だが、CoffeeScriptの場合どう受け取るんだろう。こうやんのか。

query = new URLSearchParams(window.location.search)
switch query.get('course')
    when 'silverstone'
        lng_d1 =   -1.022485; lat_d1 =   52.069097; v =  91 # シルバーストン
    when 'marinabay'
        lng_d1 =  103.864217; lat_d1 =    1.291532; v =  58 # マリーナベイ
    when 'doken'
        lng_d1 =  140.072549; lat_d1 =   36.115692; v = 184 # 土木研究所
    else
        lng_d1 =  136.540617; lat_d1 =   34.843099; v = 164 # 鈴鹿

　 なんか懐かしいなぁ、って思いながら車を走らせていると、視界が恐ろしく狭いことに気づいた。試験走路から一般道に出て、当時の寮に帰ってみようと思ったのだが、どこを走っているのかわからず、帰れない。仕方ないので、より小縮尺のグーグルマップをすぐ右に別に開いて、それを参照しながらドライブしてみた。つうか、これは「ラリーX」じゃないのかw？ それにしても、これだけでもだいぶ楽しいな。気づくと土浦学園線、土浦ニューウェイを通って土浦駅まで走っていってしまっていた。何をやってんだオレわw。

　 試験走路に戻ろう。とりあえず、わかりやすい目印を決めてそこまで走ろう。スタート地点からそこまでの距離を、グーグルマップの「距離を測定」機能で求める。1.03km。で、ストップウォッチを片手に、車を走らせる。29秒。「1.03km / 29s x 3600s = 127.9km/h」。おぉ、おおよそ時速100kmだったんだな。

　 んが、ここからが問題。時速100kmになる「値」はいくつなのか。0.3より少し小さいはずだが、ここは安直に比率で求めるのではなく、理詰めで求めたい。

　 まずは0.3が127.9km/hになった理由を求める。0.3は256分率表現で76.8。60FPSなので4608/s。ズームレベル20なので4ビット右シフトして288ピクセル/s。24ピクセルが2mなので24m/s。時速にすると86.4km/h……あれ？ いや、地図の側を緯度補正して24ピクセルを2mにしてるんだから、速度の方も補正しなければならないのか。「86.4km/h x 256 / 178 = 124.26km/h」。おぉ、だいたい同じになった。計算は合っていそうだ。

　 これを逆にして100km/hから求めればいい。「100km/h * 178 / 256 =69.53km/h」。秒速にすると19.31m/s。24ピクセルが2mなので232ピクセル/s。ズームレベル20なので4ビット左シフトして3708/s。60FPSなので61.8。256分率表現なので0.241。ということになる。んが、毎回こんな計算をするのは無駄なので、計算順序を入れ替えて定数にまとめてしまう。「0.3472 * 178 *1.0 / 256 = 0.241」緯度が変わったら178を変更し、200km/hにしたければ1.0を2.0に変更すればいいわけだ。

　 念のため、土木研究所の試験走路でやった速度の算出を、シルバーストン、鈴鹿、マリーナベイでやってみたが、ちゃんと100km/hで走っているという結果が出た。よっしゃよっしゃ。

　 これができたら、あとは鈴鹿のF1の走行映像からコーナリング速度を読み取り、ハンドルの効きを調整。それができたら、予選のラップタイムに近くなるように加減速の性能を調整。という段階を踏むことになるだろう。

　 んが、その前にCourseクラスとMyCarクラスで個々に計算している緯度補正値をWposクラスに持っていくリファクタリングが先だな。まだまだ先は長そうだ。

　 ここ数年、夏は狂ったような暑さで、避暑地が気になっている。いや、本当に気になっているだけで、滅相なんて別荘もないんですが。で、避暑地の重要なスペックが「標高」である。平均的には、高度が1000m上がれば、気温は6〜7度低くなる……のだが、この数字をいつも忘れてしまう。はいここ、次の試験に出ますからね。

　 で、ロードスターで走り回っていると、峠好き、酷道好きだけあって、気がつくと高いところにいるのである。馬鹿と煙は高いトコが好き……否定はしないが、どんな高さを走っているのかチョイチョイ気になるのだ。

　 ちなみに、酷道好きのアドリブ好きなので、ナビにはコダわっている。叩き売りされていたYPF7550MLと、叩き売りされていたA330だ。どちらも携帯の電波に関係なく現在位置を表示してくれる。で、どちらにもGPS/気圧高度計は付いているのだが、常時表示しておくのが困難なところが難しくて困るところ。

　 で、仕方ないので別途高度計を購入した。なんとデジタルではなくアナログ。EMPEX(エンペックス)のアルティ・マックス4500(FG-5102)というもの。が、これがなかなかのスグれもの。気圧に依存するので絶対値は微妙だが、計測精度はかなりものだ。電源不要で、取り外して持ち歩けるのもイイ。

　 さて、こいつをどうやってクルマにくっつけるか。一応、車載も想定されていて、マウンタが付属しており、その背面には両面テープが付いているのだが、それでネチっとするのもなぁ。値は極力正面から読みたいし……

　 つうわけで、しばらく外してあったフロントカメラを復活し、そのバイザー部分にマウンタをネジ止めすることにした。久々の工作だなぁ。それなら角度も調整できるし悪くない。いい感じに付いたぞ。よっしゃよっしゃ。必要な配線は背面にスッキリとまとめた。必要な配線はないけどね。

　 さて、あとは高いところに行くだけだが……。

　 別に高いところを目指したわけではないが、真夏になる前にオープンドライブを楽しもうと、いくつかの道に対するリベンジも含め、臨時の休日を利用して1泊のロングドライブに出発した。

　 平日は休日とは混雑の場所が違う。8時過ぎの出発では遅かったか。自宅付近で渋滞に巻き込まれ、郊外に出るのに手間取ってしまった……が、その後はいつものコースで中津川……と、思ったらその直前で363号が通行止めだ……が、険道にはよくあること。根の上の別荘地を抜け、迂回路となる険道で中津川へ。あれ、この道はWRCのSSだった道じゃなかったかな？ 無事、木曽高速という異名を持つ19号へ乗る。

　 渋滞のロスを取り返すように快走。大桑の先で、新しく整備された木曽川右岸道路に入ってみる。交通量はほぼゼロ。寝覚の床に用のない人にはこっちが早いな。上松からは上松御岳線へ。再び、そこそこの険道。裏を回る形で道の駅三岳に到着。ちょうど昼時だが、この道の駅にはレストランがなかった。休憩所があるので、弁当を買って昼飯。一息つく。

　 スイッチバックしたら、最初の目的地である王滝村へ。王滝村って、地図で見ると行き止まりに位置していて、敢えて向かわなければ訪れない場所という感じがしたので、今回、敢えて目的地のひとつに選んでみた。行ってみると、御嶽山の登り口という感じの場所で、なんだか島っぽい雰囲気だ。とりあえずドン詰まりに行って納得したいので、まずは山の上を目指す。

　 ズンズンと登っていく。道は悪くない。しばらくしてスキー場に着くが、まだ上がある。というか、ゲレンデを横断するようにクネクネしながらテッペンまで行ける。リフトに乗らずにリフトの頂点より上までクルマで行けるとは面白い。標高は2200m。涼しい。お揃いの電動スポーツ自転車で登ってきたという初老の夫婦がいた。そういうのもあるのか。

　 納得したので下へ。次は西端を目指す。中途半端なところでゲートに阻まれるが、なかなかに奥が深い。途中、はるか上空を横切る立派な白いトラス橋の下をくぐったが、何と橋には床板がない。道路橋ではなく水道橋なのだ。スゲェもんがあるんだな。

　 納得したので戻る。戻りは御岳湖の南を通り、なぜかまた道の駅三岳へ。そこから御岳ロープウェイを目指す。が、登り始めてからナビがしきりに戻れとうるさい。不審に思ってナビの地図を見ると先の道が切れている。なに？ 奥に抜けられない？ 事前に調べた限りではそんなことはなかったはずだが……と思った矢先、予定外の道に入ってしまった。倉越パノラマラインというらしい。かなり激しい下りのコースだ。結局、それで山を下りたが、実際には御岳ロープウェイを通っても奥に抜けられたようだ。どうも、スキー場の閉業で、その中の道が通れるようになったような雰囲気。時々あるパターンだな、それは。ナビの地図が少し古かったせいか。

　 次はそのまま北上して野麦峠へ。そこそこの険道。野麦峠といえば「あゝ野麦峠」だ。雪の山道から転落する映画だったような。しかし交通量はほぼゼロだな。スイスイだ。

　 が、それを抜けた辺りでちょっと時間が怪しくなってきた。宿には18時過ぎには着きたい。というのも、周囲のスーパーで晩飯を調達予定なのだが、妙に閉まるのが早かった気がするのだ。というわけで、以前に冬季クローズで通れなかった上高地乗鞍林道(林道奈川安曇線)は今回もパスして安房峠(あぼうとうげ)へ向かう。まぁ、また来りゃいいさ。

　 安房峠は今回の目的地のひとつ。以前は冬季クローズで通れずトンネルを抜けたが、今回は直前で坂道を登っていく。おぉお、スゲェなこれは。つづら折りの間が長い。数も多いのでちょっとダレるし、その先もだいぶ距離がある。こりゃ、よほどの物好き以外、790円を払ってでもトンネルを通るはずだわ。まぁ、そのよほどの物好きなんで峠道を通るけれどもさ。

　 峠道を抜けると、前回に来た時に柵が閉まっていることを確認したゲートが現れ通過となる。今日のメニューは終了だ。今日の宿泊地である栃尾温泉に向かう。そして到着前に大誤算。2店あるスーパーがどちらも閉まっている。どうも18時終了だったようだ。早いにしても程がある。甘く見すぎていた。

　 宿でチェックイン手続きをしながら近くのコンビニを尋ねると、クルマで1時間とのこと……ほぅ、1時間ねぇ……って、1時間ッ!? いまは19時前。弁当を買って帰ってきたら夜食じゃねぇか。が、仕方なくクルマを出すとすぐソコの酒屋が開いているのを発見。カップ麺やつまみ程度ならあるだろう、と思って行くと、カップ麺やつまみ程度ならあった。しゃーない、晩飯はそれで手を打とう。

　 飛騨高山中華そばというカップ麺と、味付けうずら卵、金麦というシンプルな晩飯を済ませ、入浴、その後やきとり缶と桃チューハイをアドインして早めのお休みである。いやー、今日はたくさんの道を回収できたので満足だわい。

　 宿泊を挟んでのロングドライブを何度かしているが、いつも早く目覚めてしまう。今回は4時半に目を覚ましてしまい、2度寝したのにも5時半だ。しゃーない、顔を洗って朝飯にしよう。つうても、昨日の買物の残りのカップヌードルのみだけど。

　 7時前に出発。ちょっとイキナリすぎるので躊躇したが、宿のすぐ上の洞谷流路工の上まで行ってみる。ストリートビューがないところに行くのは、少し価値が高い。例によって進入禁止の柵の前まで行き、納得し、戻る。

　 下りて洞谷流路工を横切る橋を渡ると、なかなかに幾何学的な構造物が眼前に。土石流を防ぐいわゆる砂防ダムか。昨日の王滝村も過去に大きな自然災害を経験しているが、ここもらしい。実際に訪れてみなければ知ることはなかっただろう。こういうのも、行く当てのないロングドライブの楽しみだ。

　 西に向かい、白川郷を目指すが、41号は何度も通っているので、岐阜県道76号国府見座線を通ることにしたが、これが大当たり。大坂峠の先は、崖を駆け下っていくような楽しいつづら折り。しかも景色も路面も最高。室戸スカイラインを思い出すな。下りた先、41号の手前のコンビニで握り飯とコーヒーを調達。

　 しばし41号を北上、471号に逸れて、360号で天生峠(あもうとうげ)を目指す……が、途中「通れます」という表示の多いこと。どんだけ頻繁に通行止めになってんだよw。酷道レベルはそう高くない。気分良くクネクネしていると、急に広めの駐車場が現れた。そこがまさに天生峠でハイキングコースの拠点らしい。ベンチに座り、握り飯とコーヒーで二度目の朝食。

　 峠を下りるとそこは白川郷、で、間髪入れずにホワイトロードだ。以前、トヨタ白川郷自然學校へ向かった道だ。今日はその先へ行く。どうも今年の開通は昨日だったらしい。しかし高い。1700円だ。そのせいか、貧乏くさいクルマはいないし、噛みしめるようにゆっくり走っているクルマが多い気がする。

　 展望台でしばし散策。固まり気味なカカトをほぐす。しかし、高い金を取るだけあって見どころ満載な道だ。やたら駐車場が多く、そのすべてに見どころが用意されている感じ。が、その都度に駐まっていたら日が暮れるので、残りは全スルー。実は、昨年の11月末頃に開通して間もない冠山道路を通りに向かった時、通行止めのホワイトロードの柵を確認しに来ているのだが、ちゃんとそこを通過し、スキー場を抜け、瀬戸の町に出た。

　 そこから157号で南下してもいいのだが、それはその時に通った道なので、少し北上して道の駅一向一揆の里へ。ここもその時に来た場所だ。土産の米と、笹寿司を調達したら、今回は石川県道44号小松鳥越鶴来線で勝山を目指す……が……ん!? 視界の隅に「大日川ダム天端道路は通れません」と映ったような……この先はダムの東を抜けているんだよな……と、念のためナビでダム付近の道をアップにしてみると、西から東に天端道路を抜けるコースになっている。んなぁ!? まぁ、酷道巡りをしていると「通れない」は珍しくないんだが。しかし、少し戻る形で西に抜ける道、石川県道109号阿手尾小屋線で416号に抜けられそうだ。険道レベルはそう高くなかった。

　 が、そこから新俣峠(しんまたとうげ)に向けてが意外な展開。416号の酷道レベルが意外にも高い。一定間隔で退避所はあるものの、道は狭く荒れている。そしてナビでは先の道が切れている。またかよ。しかし、実際には繋がっている確信がある。と、すれば、それは極端な酷道か、新設された走りやすい道かのどっちかだ？ そして境界の弁天橋へ。後者だ。センターラインはないが、退避所がいらないくらいに広くて路面がよい。これまた、崖を駆け下っていくような楽しいつづら折り。そういえば、最近になって長年の不通区間が整備されたというのはココだったのか。つうても、この交通量で冬には通れない道の片側だけ快走できてもなぁ、などと勝手に思いながら勝山市に到着。

　 勝山では予定どおりに給油。タンクの底まで使えばギリ帰れそうだが、燃料メータがゼロのまま100キロ以上走るのは精神衛生上悪い。185円。ここんとこ高いちゃー高いが、リッター20キロも走るからね。以前乗っていたテンロクのエクサが12キロだったことや、インフレ、そもそも単なる遊びでコロがしていることを考えりゃ、文句をいうのはお門違いだ。

　 そして今回のクライマックス。温見峠(ぬくみとうげ)越えだ。以前に「今度は逆方向に走りに来るかな」などと書いたが、個人的に「行きと戻りは別の道」という考えを持っている。必要な運転操作も、見える景色も違ってくるからだ。

　 157号で大野市を抜けると、157号は「麻那姫湖(まなひめこ)」方面と表示されている。そこに「岐阜」の文字はない。それは圧倒的に正しいw。あれは一般人が通るべき道ではない。ズンズンと進むが、意外なほど快走路が続く。あれ、もう峠まで10キロしかないぞ……と思った辺りで待望の酷道区間が現れた。やはり逆走だと印象が違う。前回、少し怖かったのは温見峠に近い部分で、山肌に沿って荒れた路面を降りる区間だったのだが、今回は登り。あー、なんか、ヤバくなってきたぞ、と思った矢先……

　 同好(たぶん)発見w。いや、そのクルマでここには来んやろw。つうか、一瞬ロードブラスターの鏡のシーンかと思ったわ。ちょっと広い部分だったので、スムーズに離合できたが、しばらくニヤニヤが止まらなかったではないか。しばらくして温見峠に到着。登山客が下りてきていた。しばし笹寿司を食べて休憩。朝が早すぎると食事の時間がぶっ壊れるな。そしてその先へ向かう。

　 ここからが本当のクライマックス……と構えていたが、そうでもない道が続く。明確ではないが、待避できる場所が頻繁にある。酷道を走る場合、常に直前の待避可能な場所を脳内にホールドしながら走るのだが、更新間隔が短い。やはり逆走だと印象が違うのか。いや、そもそも後半はそれほど酷道レベルは高くなかったような気もするな。

　 そういえば157号は長らく不通だった間、猫峠が迂回路だったらしいが、今回はそっちを通ってみるのもアリか。いや「行きと戻りは別の道」だから、157号の全区間の回収を優先すべきか……と考えていたら、今日は猫峠が通行止めだった。なんだ、そんなら迷うことないニャン。そのまま157号を回収するニャ〜ン。

　 が、やはり157号は甘くなかった。最後に西に向かう倉見渓谷の区間は記憶以上の激辛だった。以前に来た時は身構えて入って即クライマックスだったが、今回はちょっと油断していたところからのクライマックスなので始末が悪い。やはり逆走だと印象が違う。待避可能の場所を脳内にホールドする時間が長すぎる。対向車が来ないことを祈りつつ、早く抜けてしまいたいけど、飛ばせば崖から「落ちたら死ぬ」というジレンマ……どうにか抜けたが、正直かなり消耗しましたわ。散々に酷道を走ってきたが五指に入る怖さだ。ここはアカン。

　 「道の駅ねお」で心底の一息。ふと、休憩所のパンフレットを眺めていたら「温見峠ルート」の紹介があり「倉見渓谷は避けるべき、猫峠経由が望ましいです」との記述が。え!? 迂回路だった猫峠の方がお勧めなの!? 本線よりマシな迂回路なんてアリか……言われてみると距離は1.5倍くらいあるが、確かにマシっぽい感じだ。次があるならそっちを通ろう。

　 あとはよく走る道。本巣市役所から長良川堤防道路まで裏を斜めに抜ける道を試しつつ何事もなく帰宅。総走行距離750kmオーバ。いやー、今回もよく走ったな。完全に法定労働時間基準オーバだ。オドメータは6万を超えた。しばらくドライブは夏休みか……いや、高地ならイケるのか!? さて、次はドコ行こうかしらん。

　 「ナイショの話」のレッスンが始まったので、比較のためにレッスン前の状態を残しておこうかと思い、久々に「うたスキ動画」というサービスを試してみた。以前と違いYouTubeにアップするように変わっている。行きつけの近所のカラオケボックスで利用できるのだが……

　 ……録画を有効にすると採点バーが出なくなるので、結局、冒頭のカウントの入りのタイミングは取れなかった。なんだよもぅ。まぁいいけど。最初の「ワン、ツー」はあきらめよう。

　 しかし、言い訳するわけではないが「うたスキ動画」で録ると、PCMレコーダの空気録りとはだいぶ違った感じになるんだな。エコーも強くかかる。なんつうかコレオレジャナイ感……これは、マイクの使い方による違いなのだろうか。まぁ、それも込みで数ヶ月でどれくらい成長するのか……成長しないのかw。

　 それにしても、気づけばいったい何を目指しているんだ、オレは。当初はシャウトしたくて歌を始めたはずだったんだが。それはそれでそれっぽく歌えるようになってきたけれども。

　 ちなみに「野球を観る/やる」と同じく「歌を聴く/歌う」は、対象をより楽しむための別のアプローチだと思っている。突き詰めて歌ってみなければ気づけないことは、たくさんあるんだぜ。

　 そう気になるほどでもないがロードスターのルームミラーの縁が汚れてきた。表面じゃない。鏡の錆か？ 6年半経つものの、ちょっとショボくないか？ とは思うが、同じ症状の方を発見。

　 車のパーツだから高いんだろうな、と思って調べたら意外。税込み2629円。安ッ!! これが自動防眩ルームミラーだと3万もするらしい。うわーNR-Aでよかったぁ……って、アレ？ そもそも自動防眩ルームミラーだったら錆びてないかもしれんわな。

　 別にまだ交換するほどでもないが、ちょうどモノタロウのクーポンがあったのでポチる。そう。自分は逆張り野郎なので、何の工夫もなくまったく同じ純正のミラーと交換するのであった。つまらんパーツレビューやねぇw。パーツナンバはKD53-69-220B。ちな、交換にはトルクスの20番が必要になる。ナゼにトルクス？ 自分は手元にあったけど。あ、イジり止め対応のトルクスである必要はない。

　 余談だが、オープン状態で夕暮れになると、防眩レバーで上を向けても明るい空が映って後方が見えない。なので「普段は上に向けて使い、夜に下を向ける」といい。黒い背面パネルが映るので問題なく後方が見える。これマメな。

　 たいして面白くもないこの記事、みんカラへの投稿用に書いたものなのだが、何が気に食わないのか上記の内容だと理由も告げずに投稿に失敗しまくるので、こっちに転用した。アホゥが。

　 これが普通だとも思わないのだが、なんだかヤルこと満載である。仕事もあるが、主に遊び。いや、両者が混じっているものが多いかな。

　 なので、遊んでいるヒマがない……あれ？ 遊ぶこと満載で遊んでいるヒマがない？ なんかおかしな状態だが、なにしろ最近は生き急ぐかのように何かに取り組んでいる。

　 実はロードスターでのドライブは心を空にする手段のひとつかもしれない。ボーっとするためだといえば、運転に集中しろ、と怒られるかも知れないが、それは違う。運転に集中することがボーッとすることなのだ。小脳の運転マクロをフル活用しつつ、運転以外のことを何も考えない状態。運転の操作は最小、効率は最大。詰め将棋ならぬ詰め運転。人馬一体。タルケン化だ。スマホイジりしてて信号で後の車を堰き止めたり、前の人を30cmに圧縮してしまうようなヨソゴトクソ運転では決してない。

　 しかし、家でPCの前に座っていてもマジックポイントがゼロになってしまう時があるのだ。どうにも何も考えたくない。そんな時は宿屋で回復するのが常套なのだが、生憎とまだ夕方だ。そんな時はゲームをする。ゲームと言っても、ドルアーガとかスパルタンXとかアルゴスの戦士とかブラックドラゴンとかはダメだ。ガンバる必要があるのにガンバれずに頓死して心労の度を深くしてしまう。いや、グラディウスくらいまで杵柄ってると、もう小脳だけでクリアしてしまうから話は別だけれども。

　 そんな時、最近は「Vampire Survivors」である。任天堂スイッチのヤツ。このゲームは、ブログ記事かなんかで絶賛されていて買ってみたものなのだが、実に頭を使わない。敵の少ない方に進むだけ。本当に何も考えずにできるので、脳の疲れが癒せるのだ。実際、居眠り半分でクリアしたこともあるくらいだ。このゲームを好きな人には悪いけど、単に時間を無駄にするのにうってつけなのだ。ハッキリ言ってクッソつまらん。プレイする価値は一切ない。要するにパチンコっぽいゲームデザインなのだ。そこに「闘い」がない。そういうのが好きな層には面白いのだろうね。

　 でも、今日は時間を無駄にしたい気分でもないんだよな。というわけで、体験版のゲームでもして時間を潰すか、とeショップに入ってみた。で、そこで偶然に見つけた「INSIDE」というゲーム。デモ動画を観ると面白そう。しかも230円。だいぶ前に遊んだ「FORMA.8」に雰囲気が似ているな。つうか、この雰囲気のゲームは少なくないけどね、最近。

　 んが、ヤリだすとムッチャ好みだった。止まらない。晩飯で中断したが、一気にエンディングまで。ほとんどの謎は軽く、全部ノーヒントで行けた。オレスゲーというよりは、そうプレイヤに感じさせるレベルに調整した開発がスゲーと思う。終盤にはカタストロフィ的な展開がありカタルシスも感じさせてくれる。よくわからんが、その程度がまたイイ。そして最後はどこかでデビルマン(断言)。

　 数箇所を除いて、ほぼ眼前の状態だけがヒントのパズルなので、もう少しアッチャコッチャしたかった気もするが、その謎の軽さこそが、今のマジックポイントがゼロの自分の精神状態にピッタリだったようにも思える。しかも、エンディングまでのプレイ時間も絶妙すぎだぜよ。

　 終わった後はネットでヒトリ感想戦。これがまた楽しい。そしてそれが恐ろしく以前(2016年)に作られたゲームだと知って驚き、さらに似たような前作「LIMBO」がある事も知る。こっちもセール。今日までやん。240円と10円高いが、とりあえずポチっとこう。

　 では、早速プレイ……したりはしないんだな。再びマジックポイントがゼロになった時のために取っておくのである。急がないのだ。大人なのでねw。

　 ちょっと前からISOイメージの中身をHTTPで公開するコンテナを作っていた。slairという名前が付いている。

　 スレイヤと読むが、ドラゴンスレイヤではなく、ドラゴンズレアのモジりで、ソース(コード)の棲処を意味する「Source's Lair」。略して「's Lair」。元々はソースコードの閲覧が主な用途だった名残だ。で、3回目のリニューアルなので「's Lair III」まぁ、大層な名前の割には大したものではないけれど、歴代、LinuxOSのインストール、各パッケージのアプデ、ソースコードの調査などの作業を大幅に効率化してくれるので、職場で重宝されてきたサービスである。

　 リニューアルする主な理由はコンテナ化だ。それに伴い、pvにISOを置くだけで勝手にマウントしてHTTPアクセスできるようになる機能を加えた。ISOイメージの中身へHTTPアクセスできるということは、dnfのリポジトリサーバが務まるということだ。インストール後の、各パッケージのアプデに便利だ。んぁ？ そこでフト思った。コンテナビルドの時のdnfによるパッケージインストールもそこからやらせられたりしないか？ それが可能になれば、コンテナビルドが爆速になる気がするんだが。遠いオフィシャルリポジトリへのアクセスが不要になるのだから。

　 それをしたいなら、コンテナビルドで「dnf install」の実行の前に、/etc/yum.repos.dの中のrepoを置き換えるスクリプトを書いてやればいい。こんな感じに。

#!/bin/sh
 
rm /etc/yum.repos.d/*.repo
 
cat <<EOF >/etc/yum.repos.d/slair.repo
[slair]
name=Fedora 40 - x86_64
baseurl=http://hostname/indexes/discs/Fedora-Server-dvd-x86_64-40-1.14/
gpgcheck=0
EOF

　 そのスクリプトをリポジトリサーバのすぐ横に置いて提供してやることにするならば、Dockerfileの冒頭はこんな感じに。

FROM fedora:40
 
ADD http://hostname/indexes/misc/setup_repo_rhelXX.sh /setup_repo_fedora40.sh
RUN bash /setup_repo_fedora40.sh
 
RUN set -x \
    && dnf install -y \
        ruby \
        procps-ng \
        iputils \
        iproute \
        diffutils \
        less \
    && rm -rf /var/cache/dnf/* \
    && dnf clean all
 :
 :

　 そしてイザ「docker-compose build」ッ、速ッ!! パッケージリストの読み込みが瞬時に完了……アレ？ ビルド失敗……なんで？ 必要なパッケージがない!?

　 今回、FedoraのServer版のISOを使ったのだが、中身を見ると大半のパッケージが入っていない。あぁ、そうか。Everything版のISOじゃないとな……と、思ったら、だいぶ前にその提供は終わっていたのであった。ちぇ……とはいえ、同じことをRHELでやる場合には問題なくできるはずなので、今回はそれでヨシとしよう。作った物件のgitリポジトリを以下に公開しておく。

https://itline.jp/git/slair
https://itline.jp/git/sinatra_skelton

　 同じことをRHELでやる場合には問題なくできるはず、なので、職場の環境でやってみることにした。が、RHELのコンテナイメージって、どうやって提供されているのだろう……Red Hatのサイトに置いてあったっけ？ ログインしてダウンロードしてdocker importするとか？ と、思ったら、なんと一般に公開されているので普通にdocker pullできるらしい。「ubi」で検索すると出てくるのがそれだ。「Universal Base Image」の略らしい。特段の契約なしに使ってもライセンス上の問題はないようだ。太っ腹だな。

# docker search ubi | grep 'ubi9[ -]'
docker.io    docker.io/redhat/ubi9                            Red Hat Universal Base Image 9
docker.io    docker.io/redhat/ubi9-minimal                    Red Hat Universal Base Image 9 Minimal
docker.io    docker.io/redhat/ubi9-micro                      Red Hat Universal Base Image 9 Micro
docker.io    docker.io/redhat/ubi9-init                       Red Hat Universal Base Image 9 Init
redhat.com   registry.access.redhat.com/ubi9                  rhcc_registry.access.redhat.com_ubi9
redhat.com   registry.access.redhat.com/ubi9-init             rhcc_registry.access.redhat.com_ubi9-init
redhat.com   registry.access.redhat.com/ubi9-micro            rhcc_registry.access.redhat.com_ubi9-micro
redhat.com   registry.access.redhat.com/ubi9-minimal          rhcc_registry.access.redhat.com_ubi9-minimal

　 双方に各4タイプあるが本家の無印を使っておけばいいだろう。

# docker pull registry.access.redhat.com/ubi9

　 とりあえず、自分が一番良く使うsinatra_skeltonのベースイメージを「fedora:39」から「ubi9:latest」に置き換えてビルドしてみるか……て、アレ？ なんだか素でもdnfの処理が速くないか？ 100以上のrpmパッケージを導入するってのに、なんだかサクサクな気がするぞ。

# docker-compose build --no-cache
  :
Red Hat Universal Base Image 9 (RPMs) - BaseOS  1.1 MB/s | 515 kB     00:00    
Red Hat Universal Base Image 9 (RPMs) - AppStre 2.6 MB/s | 2.0 MB     00:00    
Red Hat Universal Base Image 9 (RPMs) - CodeRea 784 kB/s | 274 kB     00:00    
  :
Total                                           5.6 MB/s | 116 MB     00:20     
  :
real	1m34.461s

　 まぁでも、せっかくなのでslairを使うパターンも試してみよう。repoを置き換えるスクリプトはこんな感じに。

#!/bin/sh
 
rm /etc/yum.repos.d/*.repo
 
cat <<EOF >/etc/yum.repos.d/slair.repo
[Slair-BaseOS]
name=Red Hat Enterprise Linux 9.4 - BaseOS
baseurl=http://hostname/slair/indexes/discs/rhel-9.4-x86_64-dvd/BaseOS/
gpgcheck=0
[Slair-AppStream]
name=Red Hat Enterprise Linux 9.4 - AppStream
baseurl=http://hostname/slair/indexes/discs/rhel-9.4-x86_64-dvd/AppStream/
gpgcheck=0
EOF

　 Dockerfileの冒頭はこんな感じに。

FROM ubi9:latest
 
ADD http://hostname/slair/indexes/misc/setup_repo_rhel94.sh /setup_repo_rhel94.sh
RUN bash /setup_repo_rhel94.sh
 
RUN set -x \
	&& dnf install -y \
		ruby \
		rubygem-bundler \
		ruby-devel \
		redhat-rpm-config \
  :
  :

　 おぉ、速い。けど、ほとんど変わらない。ダウンロードは少し速いが、ビルド全体だと何秒か遅い。が、誤差程度だ。slairいらんやん。

# docker-compose build --no-cache
  :
Red Hat Enterprise Linux 9.4 - BaseOS           4.2 MB/s | 2.1 MB     00:00    
Red Hat Enterprise Linux 9.4 - AppStream        6.3 MB/s | 7.0 MB     00:01    
  :
Total                                           6.3 MB/s | 120 MB     00:19     
  :
real	1m38.762s

　 ubiのコンテナでubiのリポジトリにアクセスするのは問題ないが、RHELのオフィシャルISOを食わせる場合は、ライセンス上サブスクリプション契約が必要になる。上記は職場環境での試行なので問題ないが、自宅では実施できない。ということで自宅では素のubiを試してみた。

# docker-compose build --no-cache
  :
Red Hat Universal Base Image 9 (RPMs) - BaseOS  1.2 MB/s | 515 kB     00:00    
Red Hat Universal Base Image 9 (RPMs) - AppStre 3.5 MB/s | 2.0 MB     00:00    
Red Hat Universal Base Image 9 (RPMs) - CodeRea 479 kB/s | 274 kB     00:00    
  :
Total                                           9.2 MB/s | 116 MB     00:12     
  :
real	1m21.979s

　 自宅でも、むしろ速いやんけ。やっぱ、slairいらんやん。こんなことなら、これからベースイメージにはubiを使おうかしらん。

　 改めてFedoraのdnfが遅い理由を確認してみると、ダウンロード速度が遅いのもあるが、リポジトリのカタログが大きいことが主たる原因のようだ。まぁ、Fedoraでしか使えないパッケージは多いからこれは仕方ない。

Fedora 39 - x86_64                              2.1 MB/s |  89 MB     00:41    
Fedora 39 openh264 (From Cisco) - x86_64        1.4 kB/s | 2.6 kB     00:01    
Fedora 39 - x86_64 - Updates                    2.5 MB/s |  39 MB     00:15    

　 つうわけで、これからはubiメインで、不足する場合はfedoraを使うというのがよさそうである。プシュー。

　 どうでもいいが、直前の記事を書いた時点では、特段UBIの存在を意識していなかったのに、今回の記事に奇跡的なネタ表題が付けられて満足……つっても、このネタを拾える人がどれだけいるのか……。

　 しばらくソフトウェアばかりで、ハードウェアをイジってなかったので、久々にコテを温めて部品のテストをしてみた。

　 部品というのは、いわゆる音を拾う「マイク」なのだが、2022年の年末頃に共立電子から通販で取り寄せて、そのまま放ってあったものだ。SM-9410Aというマグネチックマイク。いやぁ、寝かしたもんだなぁw。扱いはダイナミックマイクと同じでいいんだと思う。小型のマイクがひとつ欲しかっただけなんだが、特価品として買ったのでジャラジャラと20個もある。

　 一応、クルマ関連の工作をするつもりで手配したもので、今回のテストもそのためだ。ミニプラグをハンダ付けして、PCMレコーダで録音テストをしてみる。「アー、アー、ただいまマイクのテスト中、アー、アー」。とりあえず成功。

　 やっぱりダイナミックマイクは出力が小さいので、ラインレベルに渡すにはアンプが必須らしい。各種コネクタやシールド線など、ひさびさに大須に買い出しに行くかなぁ。