_ 昨日の汗まみれの影響でカゼがぶりかえしたら嫌だなあと思いつつ寝て起きた。 とくに悪くはなっていないようだ。とはいえ全快したとは言いがたい。 ここで油断するとまた悪くなりそうな気がするのでもう少し安静にしておく
_ ここのところつくづく思うのだが、私は記録をとりながらでないと作業ができない人間のようだ。できない、ではなくて、したくない、なのかもしれない。記録がとれる環境がない状態で作業をすることを身体が拒否する感じで、安定した記録をとるための環境が近くにないときの効率が極めて悪い。自然、何かをやろうと思ったときに記録をとる環境がないことを理由に他のこと (大抵は無駄なこと) をやろうという方向に意識が向いてしまう。
_ Slack は、メモを残しておくという点ではあいかわらず有用なんだけど、溜めたものをきちんと記録に落とすことができる環境・体制がない状態ではやはりストレスだ。 Wiki、Issue、それから日記、が、リアルタイムで更新できない環境はやはりきつい。
_ Markdown はあまり愛着がないし、リンクの際にいちいち [Link Title](page-slug) の形式にしなきゃいけないのはWikiっぽくなくて好きではない。 ただWiki内の検索ができるようなのでその点はよい。あちこちリンクすることを考えるとWikiはrepositoryごとに分散させるのではなく1つにまとめたほうがいいような気がする。
_ WikiとIssueを組み合わせるという点ではRedmineの方が慣れているし便利なのだけど、これのためだけに立ち上げるのはなあ… ということで、ぎりぎりまで我慢することにする。
_ 主にソースコードやrepositoryの中を検索するためのツールらしい。 grepより圧倒的に高速であることを売りにしているようだ。
_ 1回休み
_ 今日は涼しい。天気があまりよくないというのもあるが、25度くらいまでしか 上がっていないようだ。カゼもだいぶよくなったし、 来月に健康診断もあるので走るのを再開しようと思う。二週間ぶりくらいか
_ 前の2編はミステリとしてはスマートだけど小粒だったのに対して、最後の 表題作は意表を突く真相だった。「名探偵」が登場する小説として独特の味がある。
_ ここのところ、 システムプログラミングはRustで、もうちょっとカジュアルなやつはGo、 もっとカジュアルならPython、みたいな住み分けがされそうな流れが できているように感じる。 Cに満ち足りないものを覚えていた身としては、そういうものが出現して、 なおかつ普及しつつあるというのはありがたいことだと思う。 今までもそういう、C++を除外したときに選ぶべきCの次の言語的なものは いくつかあったし、実際それらは決して悪いものではなかったと思うのだけど、 末長く使いつづけることができなくなりそうな予感が、自分の外側にありすぎて あまり本気で取り組むということができなかったと思う。
_ で、Cのかわりになる言語としての評価軸で考えるとどうしてもCで書かれた ライブラリ/APIを扱うときの手間が少ないもの、というものが外せないわけで、 Rustは決して悪くないと思うもののC++ほどの簡便さはない。 しかしそもそもシステムプログラミングがC以外の言語で記述される 未来が来るのであれば、その点の重要性はどんどん少なくなってゆく…のだろうか。 そんな未来がすぐに来るとは思えないものの
_ 私自身は決済端末の開発に関わっている時間が多いので未だに Cを触ることは多いものの、 とくに満足しているわけではない。かといってC++にしたいと思ったことはない。 私自身も持て余しそうだし、メンテナンスできる人員が確保できるとも 思えない。 他社の端末のソースを見る機会があって、そこはC++を使っていたようだった。 それなりの人数の優秀な人達がメンテナンスしていたようで、 よくできていたように思う。とはいえ同じことをしたいとは思えなかった。 前述の、能力的な点でもそうだし、そもそも決済端末なんて登場して間もない 頃のAndroid端末にも劣る性能で出来ることも限られている機械なので、ここで 組み立てられた抽象的なモデルが生かされているようには見えなかった。 つまり大袈裟に映った。
_ 今触っている端末のソースは20世紀からメンテナンスされ続けており、 そのライフタイムの中でターゲットCPUが変わったりOSが変わったり、 相手のサーバが変わったりといったイベントを消化して現在に至っている。 優れた移植性を発揮しているわけでもないし、過去に定めたアーキテクチャに 足を引っぱられている部分は多い。一方で、ヒープが存在せず、プログラム領域や constの領域はフラッシュROMにあるものがそのまま使われるといったような アーキテクチャが長いことターゲットだったこともあり 実行前の、リンク時にはリソースの利用状況がほぼ把握できるという状態は 今でもだいたい守られている。
_ 古くさい作りであることは疑いようもないが、 昔ながらのC開発者であればそこそこのトレーニングで 開発ができるようになるというメリットもあるし、だいたい端末の開発なんてのは この先何十年もする仕事ではないし、若手にやらせる仕事でもないと 思っていたので、 これを刷新しようという気持はありつつも実際に行動に移すことはなかった。 ところがここ何年か、決済手段がいろいろ増えていったり、 端末の性能が向上していったり、といったことがあって、社内ではわりと チャレンジングな仕事になりつつある。ほんの10年前は斜陽だと思っていたし、 若手にそんな潰しのきかない仕事をさせるべきではないと思っていたのに
_ オチはとくに用意していないのだが、私が仕事でCを使う機会がもっとも多い 決済端末の世界では、そろそろ、C以外の選択肢を考えてもいい時期に来ているようには 思う。もちろん古い端末がいなくなったわけではなく (私は「昭和の端末」と 馬鹿にして呼んでいるがさすがにそこまで古くない)、 そちらではC以外の選択肢はあいかわらずない状態だけど、そちらこそ 衰退する一方だし、すでに既存のコードベースが十分に枯れているので もはや切離しても大丈夫だろう。そう考えると、すぐにでもC以外の言語に 進むことは可能な時期に来ていると言ってもいいかもしれない (もっとも最近は端末開発からも距離を置くようになってきているので 私の目論見が開発方針に影響を与えるかどうかも分からんが)。 ではそれはRustなのかGoなのか、というのが次の悩みだけど… Cでももっとうまくやる道があるとは思っているが、あえてC以外を使うとすれば… やっぱりGoだろうか。RustはC++ほどではないが人員の確保が大変そう。 なにしろCでそこそこのプログラムが書ける人が集まっているので、 Cならすんなり書けることを別の言語でも…というと乗り遅れる人も出てきそうだ。 で、現時点の、Cでの端末開発におけるエース級の人達ほど そうなりそうな気がしている…
_ そう言っている間にスマホやらタブレットやらが決済端末として 当たり前に使われていって、据え置きの専用端末なんてものが淘汰される日が 来るような気がしつつ、なかなか来ないような気もしつつ、 物事が変わる様子というのはなかなか決定的な一瞬を境に劇的な進行を遂げる、 というようにはできていないようで、気付いたら後戻りできないところに すでにいた、みたいなことに気付かされることが多いもんだ。何の話をしているのか もはや分からなくなってきたが、「金国が侵攻してきました」のメッセージが 出た後、マップがすべて真っ白に塗りかわってゲームオーバー、みたいな ことは現実にはなかなかないということだろう
_ プログラムと定数はフラッシュROMにあるものがそのまま使われる。 RAMも数MBしかないこともあり起動時にRAMにロードするといったようなことは しないらしい。なので自己書換えみたいなのはできないし、 定数をポインタ使って書換えることもできない。
_ ローダを自作して全部RAMで動くようにすることを試みたことがあった。 フラッシュROMにアプリを入れこむのは5分くらいかかるので、ローダを うまく作ればビルド→デプロイのターンアラウンドを圧倒的に短かくできる… のではないか、ということでやってみたんだが、 ただでさえ少ないRAMを消費してしまい肝心のターゲットアプリケーションが 入りきらなかった。iTRON部分だけフラッシュROMに残しておいて…といった 工夫をする余地はまだあったので、またチャレンジすることがあればそういった 点を試みることになると思うが、もうこの機械は使いたくないというのが本心なので さっさと廃れてほしいという思いの方が強い。
_ FreeNASのSSDをSanDisk SSD PLUSから Kingston の SA400S37/120G というやつに入れかえた。 SanDisk SSD PLUSを1台外して、Kingston を1台つなげて、Replaceして、もう1台のSanDisk SSD PLUSを外して、Kingston を1台つなげて、 Replaceして、という操作だけでGRUBも含めて復元できた。大変に便利だった。
_ Rancher2 を動かしているUbuntuマシンのディスクは仮で使っていた古い500GBのディスクだったので、これも4TBのディスク (WDの WD40EFRX-RT2 5400rpm 赤ラベルのNAS用) に入れかえてみた。 古いほうでDockerのコンテナ全部止めて、スナップショットとってzfs sendして、 ディスク交換して Ubuntu 18.04 Root on ZFS の step2までやった後にzfs recvして (-F と -d と -u の指定が必要。 -u を忘れてこんがらがったので1回やりなおした) 、Troubleshooting→Rescuing using a Live CD の手順を参考にマウント/chrootしなおして、あとはGRUBの入れなおしに関する手順を中心にstep 3からやりなおして、無事に起動した。 rancher/rancher がなぜか自動で起動しなかったという問題があり手で起動しなおしたが、それ以外はとくに問題なかった。ZFSだとこの手の移行がとても簡単なので、環境が整うまで煮えきらない対応ばかりをしがちな私の性格でも、仮で構築しておいて後で引越し、というようなことを躊躇なくできてよい。
_ zfs recv でとってきたプロパティはsourceがreceivedというやつになっていて、必要に応じて zfs inherit -S するようになっているんだけど、これ実行してもsourceはreceivedのままなのかな？ receivedだと困るというケースは少ないので別にいいんだが、今回のケースのように元の状態を完全に復元したいというときにはreceivedでない方がありがたい。
_ Feature #6982: zfs receive should allow receive properties to always be set - illumos gate - illumos みたいな issueが上がっていて、私が抱いているもやもやと同じなんだけど、3年前からスルーされてるみたい
_ FreeNASには3TBのディスク (RAID1) 、Rancherには4TBのディスク がそれぞれ搭載されたので、znapzendで双方にミラーをとるという運用が可能になった。Rancher (Kubernetes) 側で1TBも消費することはないだろうけども
_ SanDisk SSD PLUSが2台浮いたので、1台はUSBメモリがわりにして、もう1台は RancherのZILにでも使おうかしら…と思っている。
_ 二週間ぶりなので足の痛みなどもリセットされていてわりと快適だった。
_ 前回はVer4.0発売直前の在庫処分で当時の現行バージョンを買っていたので、4.0ははじめて。 粒子がさらに細かくなって、溶けやすさが格段に向上したと思う。今までのもたいしたものだったと思うけど、ざらざら感がまったくなくなった。 風味もだいぶ変わった。シナモンの風味だと思われる。
_ 引越しなどを経て仕事環境がだいぶ変わったので、自分の机が少し広くなったかわりに、収納棚のようなものはほとんどなくなってしまった。 なので机のまわりになんでも置くようになってしまっている。置くだけだと効率がよろしくないので、せめて棚を通行の邪魔にならない範囲で置いてみたい…となると背の低い棚ということになるんだが、あまり思い通りのセットというのがない。幅120cm、高さ60cm、奥行き40cm みたいなの メタルラックは棚板やポールをばらで買うこともできるのだが、セットより割高な感じがする。キャスターだけで2000円超えてしまうとか、 120cm x 40cm の棚板1枚で3000円超えるのはちょっと高すぎるだろう。ポールも19mmのやつで60cmだと1本800円なので4本買うとそれだけで3000円を超えることになる。
_ ホームセンターのプライベートブランド？のやつはかなり安い。半額以下だ。 カインズのやつはかなり安いし、小物も含めてまとめて揃えられるのでよさそう
_ Sleepしておいた機械をわざわざ起こしてまで再起動かけるので困る。 そして .vbox ファイルがこわれて消えるという期待を裏切らないエピソードが発生した。まあ .vbox ならバックアップがあるのですぐに戻せるが、これがディスクイメージだったら泣くに泣けない
_ 気付いたらすでに九州に近付いていた。 週開けにかけてけっこうひどいことになりそうらしい。 ひどいことになるのは今九州付近にいるやつ (13号) ではなくこれから発達するやつ (15号) らしい。 そしてその台風が過ぎるとけっこう気温が下がるようだ。 いよいよ秋か
_ local-path-provisionerはよいものなんだけど、 ZFSを使っている身としてはPVCが来るたびにdatasetを作りたい、という気持があり、 ZFSに対応したlocal path provisionerはないものだろうか、と探してみたらそのものずばりのものがあった。
_ 記録をどこでも書ける環境をめざしてあれこれ設定していたが、自作の major modeが一部動かない。どうやら表題の関数が廃止されたようだ。 string-to-number に変更。
_ けっこう前に買ったきりまともに使っていなかったのでいじりはじめた。 いろんなことができるので、何ができるのかを考えるのがしんどくなってくるが まずU2Fだけに注目してやってみることにした。
_ Yubikeyそのものは頑丈にできているようで、かなり雑に扱っても大丈夫らしい。
_ Yubikeyはキーチェーンにくっつけて持ち歩いても大丈夫なくらいタフらしいんだけど、 キーチェーンにくっつけて持ち歩く気があまりしない。 というのも普段から鍵束はズボンのポケットに入れていて、汗やら謎の湿気(？)やらのせいで 金属の鍵やキーホルダーがわりと錆を帯びていたりするので、さすがにこの環境に 置くのはためらわれる。
_ いろいろ探してはいるんだが、ホームセンターのやつはあまりバリエーションがなかったりで かえってむずかしい。部品単位で売っていないことも多いので、どうもデフォルトのセットに対して 多少のカスタマイズをする、といった程度の想定しかないように見える。
_ そういえばダイソーにもあった。あまり大きなものを作ることはできなそうだがなにしろ安い。 机の上とかちょっとした間仕切りを作りたいときはこちらでよいかもしれない。 ただ通販がないので店頭で探すほかないようだ。
_ 仕切り直しのつづき。 スタンドアロンで動かすことはできるようになったので、最終的にはKubernetesのほうに ひっこしをしたいところだが、その前にまずDockerに引っ越してみることにした。
_ 公式のイメージを元にMySQLのバージョンを5.7固定にして、filesとpublicを移動して、 MySQLのほうは/var/lib/mysql の中身をそのまま移動してみた (もちろんパスワードなどは合わせておいた) ところ、とくにひっかかる点もなく 動いてくれた。これはらくちん
_ ここまでできれば、あとはKubernetesのほうにマイグレートする手順を確立することで 望む形まで持ってゆくことができそうだ。だらだらやっていたのでえらい長くかかってしまったが、 先が見えてきてよかった。
_ 昨日の日中は、突然雨が降りだすなど不安定なのと、ちょっと風が強いかなという程度で推移した。 夕方まで会社にいたんだが出番がなかったので帰宅。暴風雨になると買い出しも不便になるので 走らずに電車で帰った。結局暴風雨は夜中になってからだったようで、 21時過ぎに事務所から住居に移動したときもとくに雨は降っていなかった。 ただその後の風はけっこうすごいことになったようで、 何十年に一度という感じの強さだったようだ。
_ 今朝はいつもより15分早く家を出た。風は強めだが雨はすっかり止んでいて、 道路もだいぶ乾いていた。そして落葉があちこちに… 地下鉄は、 東武スカイツリーライン (と最近は言うのだ、伊勢崎線のことを) の直通が止まっていたので 電車は押上折り返しになっており、 しかし本数が1/3くらいになっていたそうなのでかなり混雑はしたが とくに問題なく会社まで辿りつくことができた。 私と同様、近くて地下鉄メインの人はとくに問題なかったようだが、一方で地方の人は ろくに駅に近付けなかったりしているようだ。
_ 台風が過ぎて、今日〜明日はかなり過酷な暑さになるようだ。それが過ぎて、 週末に近付くと今度は30度を越えないような涼しさになるらしい。
_ 台風のおかげで電車や道路がいろいろだめらしい。 今日はだいぶまともになってきたようだが… そんなことを思いながら1回休み。 本社のトイレが使えなくなってしまったらしい。 上下水道停電、というもののせいらしい。というのが昨日の夕方に得た最後の ニュースだが、無事に復旧したのだろうか
_ 文庫で600ページ強、登場人物も多く複雑な話なのでなかなか骨が折れた。 そしてそれに見合うものがあったと思う。大変よかった。
_ たしかに謎は多いけどこの話の流れで 裏表紙に記されている「衝撃と感動の結末」というやつに至るのだろうか？ と半信半疑ながら、 作者の狙っているところがなかなか見えないまま この骨の折れる小説を読み進めて、まんまと衝撃を受けてそして感動してしまった。 これはすごい作品だ。
_ 真相につながらない伏線、というやつの分量がかなり大きく、 このあたりは文化の違いとかもあるのかもしれないが、 あまり日本のミステリでは見られない傾向で、 ちょっと冗長に感じてしまった。 しかしこれだけの脇道を広げながら苅りとりながらひとつの形に収束させるのは 大変だろう。あんまり見たことはないけどアメリカの長期間続くドラマなども こういう作りをしていることが多いような気がする。
_ なおこの小説の原題は「JUDAS CHILD」で、 邦題を腐すのが芸風(?)の私でもこの邦題は最高だと言わざるを得なかった。 原題にもよさがあり、邦題にもよさがある。
_ 千葉ではけっこうな被害になっているようで、まだ電車が通っていないとか 停電が続いているとかで出社できない社員が何人かいるようだ。 出社できているが、住処にダメージを受けているといった人もいるようだし、 停電が一週間近く続くというのは、局地的には2011年の地震のときよりもひどいと思う。 のだが、被害状況の把握だとか、支援だとかいう方向にあんまり進んでいないように見える。
_ 今日から妻の知り合いの方が飼っている犬が事務所に来ている。飼い主の方が旅行に行っている間 うちで預かるらしい。 Vincentというトイプードルで、心を許した人間以外にはビビりですぐに威嚇するとか、 そういう人であっても同じ空間に二人きりになったとたんに擦り寄ってくるあたりも ジョンにそっくりだ。(なおVincentとジョンが接近をしたときはジョンの方がびびっていた 気がする)
_ ジョンが私を威嚇することはないが、Vincentは私に心を許していないので 威嚇されることになる。犬歯もマイルドになっているし、 噛まれても泣くほど痛いということはないので、思い通りにいかない人間としての 存在感を示すのもよいが、 Vincentもだいぶ加齢が進んでいるので応戦のストレスで本人の身体に障りそうなのが気になる。 そして、これは同じ経験をしてみないと分からないかもしれないが、 自分の家で、他の家の犬に威嚇される、という不条理さというのは、わりと乗り越えるのが むずかしいくらいに不愉快な経験だ。Vincentを預かるのはこれが初めてではないが、 そういったこともあってVincentが事務所にいる間私は事務所には近付かないようにしている。 それはそれで、なんだか追い払われたような気がしないでもないが…
_ 事務所に行くこともなく、定時で仕事が終わったりすると、わりと時間がたくさんあるので 走ってみた。近所の公園を小一時間走って7kmほど。 信号があるわけではないしペースはかなり早いので負荷はけっこう高い。 といっても1時間で7kmなのだから、このペースでフルマラソン走っても6時間かかることになる。 これ以上早いペースでなんて走れねえよ、と思ったりもするが、 別にフルマラソンを走るあてがあるわけでもないのでよい
_ 休日を組み合わせて週2〜3回は走るようにしている。 週平均2〜30kmで、月平均60〜80kmというところだ。 ただ心身の変化としては限定的で、 もうちょっと運動量を増やさないと効果がなさそうだ。
_ といってもこれ以上走ると身体のダメージも残るようになるので、 単に距離を伸ばすだけというのは考えものだ。 1回あたりの距離を増やさないとなると、あとは回数を増やすほかないので、 今日のように平日の夜に走るようにする、が唯一の選択肢だろうか。 あとは他の運動を考えるべきなのかもしれない。 すぐに思いつくのは自転車と水泳か…
_ 自転車はもう長いこと乗っていない。普段の移動手段としてももう何年も乗っていないので、 あらためて乗ろうと思うと買いかえないといけない。しかしあまり乗り気ではない。 乗らなくなってあらためて考えてみると、 自転車というのは一瞬の不注意に対するペナルティがでかすぎると思う。ちょっと気を抜いたら こけたり何かにぶつかったり、ということが起きて、そしてそのときに大怪我をする、ということに なりやすい。過去に何度もそういうヒヤリとする場面はあって、 大きな怪我をしないで済んでいるのは運がよかったというほかない。 これからさらにいろんな能力が落ちていったときに、自転車を制御するにはこちらの クロックが足りないということになりそうだ。
_ そして村上春樹が言っていた、自転車は「器具もの」だから面倒を見るのが憂鬱だ (意訳) というのもよくわかる。メンテナンスは大変だし、遠く離れたところで故障したら… などと想像するだけで憂鬱だ。
_ 水泳はプールじゃないとできないので、 費用が継続して発生するというのが億劫だ。そしてもう長いこと泳ぐという行為をしていない。 山形にいた頃は霞城公園にあるプールに何度か行ったことがあるので、それ以来ということだと 20年くらいは泳いでいないということになる。 身体への負担の小ささと、全身を使うことに対する疲労、 それから息継ぎで呼吸を強く意識しなければいけない感じ、などは水泳の大きなメリットだと思う。
_ それにしてもやっぱり身ひとつでできるジョギングというものの気軽さは捨てがたい。 ぼーっとしていれば危ないのは自転車と変わらんとはいえ、リカバリーまでの猶予時間はまだ 今の私にとっても十分であると思える。もちろん車が通るような道であれば、 また話は別なんだろうが、車の通りがないとか、少ないコースを作ることもべつに難しくない。 そのあたりの柔軟さもやはりジョギングの魅力だと思う。 一方で身体へのダメージという点では自転車や水泳に比べるとやはり大きく感じる。
_ 台風が去って1〜2日は過酷な暑さだったけど、それ以降はだいぶ過ごしやすい。 今日は涼しいと言っていいくらいだ。間も無く文句なしの秋になるんだろう。
_ やろうやろうと言って、へたすれば10年くらい先送りにしていたShadowingをはじめた。
_ まだ1回目、30分しかやっていないのでShadowingと呼べるような代物にはなっていないが、 それでも今までやったことがない取り組みなので新鮮。そして30分喋りっぱなしというのは かなり疲れる。ジョギングして、Shadowingをするといろんなところが疲労するので、 これは入眠にはちょうどいいかもしれない。
_ Shadowingをしながら音声入力を試してみた。 なかなかの精度で入力できているが、それでも発音がいい加減なところは きちんと認識されていないので、まずこれを見ながらフィードバックするというのがいいかな、 と思った。とはいえ認識されていないなりの、辻褄を合わせようとするような動きをするので、 音声認識的にはそのように聞こえた、のか、と言われるとちょっと違う気もするが…
_ しかしまあ音声認識的に期待通りの結果が出たのであれば、相手にそのように 聞こえている (少なくともそのように理解する蓋然性が高い) ことは期待してよいような気がする。 相手に負担をかけることをよしとするわけではないが、 他の方法で発音の精度を上げることができるあてがあるのであれば、 Shadowingでその点の完璧さを目指さなくてもいいかな、というような 割切りがあってもいいとは思っている。
_ 小野さんがボードゲーム店の店主になったという話は別の記事で出ていた。 それはどういうことなんだろう、と気になっていたところ表題の記事が出た。 お店は三郷のIKEAのすぐそばらしい。 小野さんもともとは学校の先生だったのか。そしてDPZにはもう書かないのかな… 小野さんの記事には 伝説級というのか、この手のWeb記事では革命的なものが多かったと思う。
_ DAMと略すらしい。大量の音・映像・画像素材をどうやって管理したものか、というので 悩んでいる。動画編集をする場合にもあったほうがよいし、 ShadowingやSpeechのトレーニングをするときに録音した音を できる限り蓄積しておきたいというのもある。
_ 2月に引っ越ししてからいろんなものの整理がついていなかったので 片付けやら何やらをした。会社のほう。
_ 会社に行く前に図書館に本を取りに行った。家から見ると会社と図書館は正反対の方向なので、 普通に考えればいったん出発した駅に戻って再出発… ということになるんだが、 同じところを二度通ることが嫌いな私は遠回りになっても別のコースをとりたいと 思いがちなのと、そういえば最近JRにまったく乗っていないな、と思ったので、 立石→青砥まで徒歩→日暮里まで京成→巣鴨まで山手線→神保町まで三田線、という 無駄なルートで移動してみた。JRは…ほんとに何ヶ月ぶりか思い出せないが、 わずか8分の乗車時間でも普段と異なる混雑ぶりと、乗っている人達の多様性を 思い知らされるのだった。自身に危険が迫っていない状態で自分のいる場所を移動するのは 恥辱みたいな文化なのだろうか…などと思ってしまった。少し譲ればいろんな人の乗り降りが スムーズにできるのに
_ BTOマシンについてくるものに不満があるわけではないが導入された。 入力端子が豊富なのはありがたい。HDMI2本、ディスプレイポート3本？ ただ、VGAがなくなってしまった…
_ でこのモニタは普段はノートPCにつなげて使うつもりなので、VGAではなくて HDMIにすることになるが… 元々のモニタをVGAでつなげてトリプルディスプレイなんか できるんだろうか？ と思い試してみたところ、そもそも接続できなかった。 ノートPC側の、HDMIとVGAの端子が物理的に近接しているので、干渉してしまい両方を さすことができない… わざとそうしているとしか思えんのだが
_ 先日入れかえたばかりの4TB HDDの具合が悪い。ディスクI/Oがまったくできなくなり、 再起動したところzpool import の段階で止まる。同じPCで起動したUbuntu のBoot CDで importしようとしても同じ動きなので、これはドライブが悪いのか本体が悪いのか…？ という ところで週末を迎えたので別のマシンでimportを試みることにした。
_ と思ったらVirtualBoxにUSBアダプタ経由でつなげたドライブを露出させることができない。 なぜだろう… 続きは明日
_ ……どうもOracle VM VirtualBox Extension Pack なるものを入れないとUSB1.1までしか 使えないらしい。そうなのかー
_ やっぱり物理マシンを用意してそこでマウントを試みてみた。で、 やっぱりzpool importに失敗する。
Sep 14 11:34:43 ubuntu kernel: [ 1088.446827] INFO: task zpool:6803 blocked for more than 120 seconds. Sep 14 11:34:43 ubuntu kernel: [ 1088.446834] Tainted: P C OE 4.18.0-15-generic #16~18.04.1-Ubuntu Sep 14 11:34:43 ubuntu kernel: [ 1088.446836] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Sep 14 11:34:43 ubuntu kernel: [ 1088.446839] zpool D 0 6803 6087 0x00000000 Sep 14 11:34:43 ubuntu kernel: [ 1088.446843] Call Trace: Sep 14 11:34:43 ubuntu kernel: [ 1088.446865] __schedule+0x2b7/0x880 Sep 14 11:34:43 ubuntu kernel: [ 1088.446871] schedule+0x2c/0x80 Sep 14 11:34:43 ubuntu kernel: [ 1088.446881] taskq_wait+0x80/0xd0 [spl] Sep 14 11:34:43 ubuntu kernel: [ 1088.446892] ? wait_woken+0x80/0x80 Sep 14 11:34:43 ubuntu kernel: [ 1088.446944] dmu_objset_find_dp+0x16f/0x230 [zfs] Sep 14 11:34:43 ubuntu kernel: [ 1088.446996] ? zil_claim+0x250/0x250 [zfs] Sep 14 11:34:43 ubuntu kernel: [ 1088.447072] spa_load+0x1ea7/0x2120 [zfs] Sep 14 11:34:43 ubuntu kernel: [ 1088.447079] ? snprintf+0x45/0x70 Sep 14 11:34:43 ubuntu kernel: [ 1088.447090] ? nvpair_value_uint32+0x2a/0x30 [znvpair] Sep 14 11:34:43 ubuntu kernel: [ 1088.447139] spa_load_best+0x5d/0x280 [zfs] Sep 14 11:34:43 ubuntu kernel: [ 1088.447145] ? zpool_get_rewind_policy+0x18b/0x1a0 [zcommon] Sep 14 11:34:43 ubuntu kernel: [ 1088.447191] spa_import+0x220/0x730 [zfs] Sep 14 11:34:43 ubuntu kernel: [ 1088.447243] zfs_ioc_pool_import+0x13c/0x150 [zfs] Sep 14 11:34:43 ubuntu kernel: [ 1088.447292] zfsdev_ioctl+0x1e0/0x610 [zfs] Sep 14 11:34:43 ubuntu kernel: [ 1088.447307] do_vfs_ioctl+0xa8/0x630 Sep 14 11:34:43 ubuntu kernel: [ 1088.447312] ? handle_mm_fault+0xe3/0x220 Sep 14 11:34:43 ubuntu kernel: [ 1088.447316] ksys_ioctl+0x75/0x80 Sep 14 11:34:43 ubuntu kernel: [ 1088.447320] __x64_sys_ioctl+0x1a/0x20 Sep 14 11:34:43 ubuntu kernel: [ 1088.447325] do_syscall_64+0x5a/0x120 Sep 14 11:34:43 ubuntu kernel: [ 1088.447328] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Sep 14 11:34:43 ubuntu kernel: [ 1088.447332] RIP: 0033:0x7f421e8b05d7 Sep 14 11:34:43 ubuntu kernel: [ 1088.447332] Code: Bad RIP value. Sep 14 11:34:43 ubuntu kernel: [ 1088.447342] RSP: 002b:00007fff7b124888 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 Sep 14 11:34:43 ubuntu kernel: [ 1088.447346] RAX: ffffffffffffffda RBX: 00007fff7b127ec0 RCX: 00007f421e8b05d7 Sep 14 11:34:43 ubuntu kernel: [ 1088.447347] RDX: 00007fff7b127ec0 RSI: 0000000000005a02 RDI: 0000000000000003 Sep 14 11:34:43 ubuntu kernel: [ 1088.447349] RBP: 000055d5d7b02660 R08: 0000000000000003 R09: 0000000000000000 Sep 14 11:34:43 ubuntu kernel: [ 1088.447350] R10: 000055d5d7b01010 R11: 0000000000000246 R12: 00007f42100019d8 Sep 14 11:34:43 ubuntu kernel: [ 1088.447351] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000008トレースはいつもzil_claimの中なので、これはディスクドライブの問題と考えていいのやら？ という感じだ。続きは明日!
_ FIDO U2F が発展したものがWebAuthnという名前になったらしい。 あまりしっくり来ない名前だな…というか途中で噛んだみたいな名前だな
_ 木曜と金曜の夜は自宅の近くを走った。そして今日も同じくらいの距離を同じくらいの ペースで走ったのだが、ちょっと筋肉痛になったかもしれない。 だらだら走るのと最近のペースでは筋肉の負担が違うということなのか。 だらだら走っている限りでは15kmとか走っても別に筋肉痛が起きることはないのだが
_ 住居には冷蔵庫はないので、冷たいものを買って置いておくことはできない。 なので必要に応じて外に買いに行く。とはいえ建物出てすぐに自販機がいくつもあるので ソフトドリンクであればとくに不便はない。100円で炭酸水が買えるので、 走って帰ってきて、家に入る前にその炭酸水を買っておいて、シャワー浴びたら ぬるくならないうちに飲み切ってしまう、というような生活を3日続けている。 酒も飲まないし余計なものも喰わないし、これはこれで健康的でよいのかもしれない。 夜中ちょっと腹が減るけど我慢できないほどではない。
_ 初日 (9/12) はtranscriptを一緒に読んでいるだけ、という状態だった。 使っている素材が、Slow speed → Natural speed の順番で喋ってくれるので、 昨日 (9/13) は、slowのときだけtranscriptを読まずに音だけを頼りにShadowingするように してみた。 今日 (9/14) は、Natural speedのときもShadowingするようにしている。 少しは真似事になってきたかもしれない。
_ 過去何度も書いてきた通り、声を出すことを徹底的に忌避してきたけど、 できなかったことができるようになることは単純にうれしい。 やっている最中は眠くなりにくく、やり終わった後はけっこう疲れているので 寝る前にやるにはぴったりだ。
_ 筋肉痛は寝て起きたらおさまっていた。ただ疲労はけっこうある。
_ 会社の最寄りの駅についたらいつにない人の量と流れで、どうやら マラソンがあるらしく道路の横断ができない＝横断したかったら地下を通れということで そういうことになっているらしい。マラソングランドチャンピオンシップというものらしい。 昼過ぎまでこんな調子らしい。
_ …… 会社の建物からだと見降ろすように観戦できるようだ。しかし私はマラソンを観戦するために 出社したわけではない
_ そういえば件のディスクをFreeBSDでインポートしようとしたら
This pool uses the following feature(s) not supported by this system:
org.zfsonlinux:userobj_accounting (User/Group object accounting.)
と怒られた。-o readonly=on ならインポートできるらしい。やってみよう
_ んー普通にimportできたな。readonlyだけど… readonlyだとscrubもできないので、 ああマウントできたね、で止まってしまうんだけど、なんかトレースを見ても起きている 様子を考えても、ドライブの故障には見えないんだよなあ
_ それに昨日のスタックトレースなんかおかしいよな、途中にsnprintfがいたり
_ どうもこのへんの話のように見えるなー。ルートファイルシステムもZFSにしているし…
_ しかし別のマシンでimportしようとしても同じようにだめなのは変な気もする。 それに、この話題は本当に今現在起きている問題らしく、 scrubのスケジュール実行が時限爆弾のような状態になっているようだ。おそらく私の ケースもそうなんだろう
_ Proxmox V6 Servers freeze, Zvol blocked for more than 120s | Proxmox Support Forumは、リアルタイムに困っている人達の会話になっている。
_ マラソンの人だかりは12時前にはすっかりなくなってしまった。 こんなに綺麗になくなるとは
_ しかしこんな混乱はオリンピックになったら毎日のようにあるということなんだなあ〜 言われるまで気づかなかった
_ そして街宣車がうるさいいつもの週末に戻った。 街宣車同士でコールアンドレスポンスをしているので、近くを通りかかると 驚きのうるささだ。ラウドスピーカー越しに大声を出すというのはさすがにどうかと思う
_ 気のせいか、これを始めてから字幕なしでの聞き取り能力が上がったような気がする。 ShadowingはListeningの能力向上によいとは聞いたことがあるが、いくらなんでも まだ6〜7時間しかやっていないのにいきなり体感できるほどの効果があるとは信じられん…ので、 気のせいなのかもしれないが
_ 1分ほどの文章をひたすらShadowingする、というのを繰り返しており、 それをGoogle Docsの音声認識でひたすら入力させ続けている。やはりいい加減な 発音、とくに子音がいい加減だと認識率がいきなり落ちるので、今の私にとっての フィードバックとしては悪くない気がする。
_ 試しにGoogle Homeの喋ってる声とか、Shadowingしているときの元の音声などを 聞きとらせてみたところ、 1分ほどの英文で、1〜2箇所修正が必要かな、という程度なので、 ほぼ完璧というべき認識結果になっている。 英語の音声認識の精度ってここまで高いものなのか…と衝撃を受けた。これだけ精度がよければ 音声入力を中心に生活している人が多いというのも分かる気がする。
_ 今の私自身の能力だと、7〜8割くらいはきちんと認識してくれているが、たまに まったくとんちんかんな認識結果になっていたりする。 音声認識での精度がもうちょっと上がるように発音が改善できるのであれば、 今後の展開にとってだいぶよいので、そのあたりの努力の優先度を上げたほうがいいのかも しれない。具体的にはShadowingと同じように年単位で保留にしていた The Jinglesを取り組むというやつ
_ ドライブをとり外して別の機械でimportしようとしても同じような症状で 固まってしまうので、Root Filesystemだから、というのはあてはまらないのかもしれない。
_ FreeBSDでもreadonlyならimportできることが分かっているので、 その環境でzfs sendができるかな？ というのを試してみた。 2回やって2回とも途中で再起動がかかってしまう… んーpanicもせずにいきなり再起動がかかるというのはかなり不可解だ。
_ ドライブの製造元 (Western Digital) が診断ツール (Western Digital Data LifeGuard Diagnostics) を出しているので、それを 走らせてみた。8時間ほどかかったが結果としては問題なさそうだ。
_ ドライブ交換当時 (9/3) のバックアップが残っているし、それ以降は特にいじっていないので それを戻してやりなおすなど回避策はいくらでもあるが、そういう手段が常にとれるとは 限らないし、起きていることを完全に理解できているわけでもないので、もう少し この状態でできることを考えてみるつもりだ。
_ さすがに5日連続だと負荷が高すぎたようで、先日のカゼ期間内に回復した 脛の痛みが復活してしまった。
_ The Jingles (レベル85) をはじめた。CDにお手本があるのでそれの 真似をすればよいのだろうけど、これを〜セットやってね、みたいな 話なので繰り返し再生ができる環境でないとやりづらい。 なのでPlayItSlowlyを復活させた。
_ 1日分のトレーニングがだいたい5分くらい、なので、何かフィードバックを得る前に 終わり、みたいな感じがする。のだが、このトレーニング自体がけっこう負荷が 高いようなので、単に時間を増やすだけでは喉への負担が増えるだけなんだろう。 なので言われるままに30日間進めてゆくほかないのかな。
_ The Jingles は系統立ったプログラムになっているようなのだけど、 その説明が断片的で理解しづらい。シリーズA,B,Cというのがあって、 シリーズAの中に例文としてジングルズA〜Iまでがある、というような感じ？ 書籍の説明ではシリーズAのことしか書いてないので、BとCの具体的な 内容は分からない。 書籍のページを見る限りでは、 レベル87でもジングルズGまでしか扱っていないように読めるので、 それ以上は書籍では扱っていないという話なのかもしれない。 まあそういう心配はひと通りこなしてからだな…
_ ZFS on Linuxのバージョンを上げて試してみるか… ということで Ubuntuのベータ版ISOで試してみた。 元が18.04 (Kernel 4.18.0-15-generic, ZoL v0.8.1-1ubuntu9) なのに対して 19.10 (Kernel 5.2.0-15-generic, ZoL v0.7.5-1ubuntu16.6) になっている。 ZoL 0.8でimportのロジックに改良が入ったらしいので少しは変わるのだろうか？ と思ったが 症状は変わらないようだ。そしてreadonlyならimportできたので 試しにimportしてzfs sendを試してみた… ら、やはり刺さる。 刺さる場所は変わっているが、刺さることには変わらない。 ひょっとしてこのpoolは回復不可能なダメージを受けてしまったのだろうかねえ
_ ファイルシステム破損というつながりだと、 It's Looking Like The EXT4 Corruption Issue On Linux 4.19 Is Caused By BLK-MQ - Phoronix なんていう話があって、 4.19とか4.20とか5系でファイルシステムが破損することがあるらしい。なんて物騒な
_ zfs sendが刺さっているときの様子をもうちょっと見てみたら、 スタックトレースの直前に
PANIC: blkptr at 000000000c0cf49e has invalid TYPE 105というメッセージが。ううむ
_ そしてあらためて18.04でimport (readonly) しようとしたら、こっちではimportできなかった。
_ それにしてもsendもできないような壊れかたされるとは。こまったもんだ。 しかしここであきらめてはトラブルシューティングのスキルが上がらないし そもそもこの状態でちょっと前のバックアップ戻してまた同じことが起きてもつまらないし、 そもそも、そもそも、まだあんまり本格稼動できていない機械なので今のうちに できることをやっておこうと思う。
_ そういやzdbをまだ走らせていなかったので走らせてみた。 なんか進みかたがおかしい‥ SATA⇔USBアダプタ経由なのが悪いのか、そうでもないのか… と悩んでいる間にzdbがOOM Killerで落とされてしまった (T-T)。しょうがないので もともとつなげていたPCに戻して試すことにする
_ … さっきとはblkのIDが異なるが同じようなエラーが出るなあ
error: blkptr at 0x7f0f3944c540 has invalid TYPE 105
_ 今度は「malloc(): memory corruption」だそうだ。 live cdでローカルにファイルを落とそうとしていたのでメモリがあふれたかな… netcat で再度試してみることにする
_ …netcat でも同じだった。ぐぬぬ
_ Ubuntu 19.10 (beta) で試してみたところ、 だいたい同じような箇所で「malloc(): invalid size (unsorted)」となった。 うーん
_ ところでなんでzdbを使うと「修復」ができるんだ？ということを理解できていない。 以前から何度も読んでいたはずの ZFS のトラブル続きを読み直してみて理解した。 zdb の -AAA とかそういったものの意味も理解した。理解した上で現在起きていることを 考えてみると、原因はともかくこの状態から使える状態に戻すくらいなら 過去のバックアップから戻すことを考えたほうが現実的なのかもしれない。 zdbが完走しないような状態では話にならん
_ 今回問題になっているサーバはこまめにバックアップをとる前提で運用しようとしているし (つまりまだしていない)、 ノートPC などディスクが1発しかない環境ではpoolそのものがアクセスできない 状態になったときに打つ手がなさそうだ。さっさとznapzendの環境を復活させないといかん。 壊れたpoolをどうにか読めるようにして中身を救うことが著しく困難だったとしても 別にZFSの価値が減じるわけではないし、 poolが健全である限りはsend/recvでバックアップやリストアができるメリットは変わらないので、 やはりZFSからは離れられんなあ〜と思う。 しかし今回壊れた理由が何なのかよくわからんので困るというのも変わらんので もうちょっと情報収集は続けたい。ディスクの故障ではなさそうなので、少し時間をかけてもよいだろう… あと、ここまで容易に回復不能なダメージを受けているところを見ると 自分用サーバでバックアップこまめにとろうとしている (つまりまだとっていない) とはいえ シングルディスク構成はきついのかもしれない。ただ今回のケースがRAID組んでたら 防げたのかどうかもいまいち分からんが…
_ そういえば「Wiiの間」で公開されいてた「修理 魅せます」というコンテンツの中で、 ジーンズの修復をする若い方が、どんどん履いてどんどん壊してください、 壊れたらまた直しますのでといったことを言っていて、かっこいいなあと思ったのを 記憶している。ZFSもznapzendでバックアップがすぐに戻せる環境ができていれば、 どんどん壊れていいよすぐ直すので、と言えないこともないのかもしれないが、さすがに そこまで割り切れた感情になるのはむずかしい…なにしろ消耗品ではないからな
_ ZFSといえばOpenIndianaでしょう、と本心ではないにしろ思ったので 試してみようと思ったのだが、ダウンロードに3時間くらいかかっており、 そうこうしているうちにzdbが時間のかかる処理を始めてしまったので落としてきただけで 終わってしまいそう
_ 昨日は走るのを休む日としており、家に帰ってきてから時間があったので いろいろやろう…と思いつつ眠気に勝てず21時過ぎには寝てしまい、そして寝苦しくて 起きたらまだ0時ちょっと過ぎだった。外の気温は20度前後みたいだし、 室温も25度までしか上がってないのに妙に蒸し暑く感じられる
_ それっきり眠れなくなってしまったので、The JinglesとShadowingをやって、 わんわん動画を見たりしながら酒を飲んで、4時過ぎにまた寝た。せっかく早く寝たのに 結局よく寝た気がしない
_ FreeNAS 11.2-U6 が降ってきた。という通知をSlackで受けとったので入れる。 通知の設定は自宅のFreeNASでもしているのだが、そっちからの通知は来ないな…
_ おかしくなったZFS on Linuxの機械については、動作しているPCのメモリの具合を memtest86+ で確かめてみた。7回passしてエラーなし…なので問題ないかなあ？
_ 3週間ぶりに指の様子を見てもらった。痛みは、たまに思い出すように、という感じで ほとんどなくなったということを伝えたところ、指の動きを見て、 今後は塗り薬と保温で様子見ということになった。なので注射は2回で終わりらしい。
_ 塗り薬は能書きによると炎症を抑えて痛みを抑えるためのものなのでそれでよいのだろうが、 保温というのはどういうことなんだろう。冷やさないように、 ということは繰り返し言われており、また、フロは冷やさない・温める、に加えて 水圧もよい影響をもたらす、という説明を受けた。日常的に冷やさない、となると サポーターをつける、なんてのが思い浮かぶけど、サポータは締めつけがあるので 血流が悪化して、それは冷やすのと同程度にうまくない、のかもしれない。 それ以前になぜ温めるとよいのか、冷やすとまずいのかを知る必要がありそうだ。
_ 先日から何度か書いていた通り、同じメーカーのリュックがいろいろ ダメージを受けておりこれ以上使うのは困難になってきたので、同じメーカーのトートバッグに 買い替えた。色は同じ。
_ 持ち手が長くなったので肩かけができるようになっている。高さ (深さ) がかなり 減っているので、容積もかなり減った。半分？はおおげさだろうか…でも体感上はそのくらいに 感じられる。リュックの頃は、普段から入れているものたちと同じくらいの量のものが一時的に 増えても普通に受け入れることができたんだけど、トートバッグのほうは普段持ち歩いている ものたちだけでけっこう満杯感がある。単に物を持ちすぎというのもあるが
_ そしてものすごい撥水性があるようだ。リュックも買ってすぐはこんな感じだったのだろうか。 だとすれば洗ったりとかなんだとか、やっている間に落ちていってしまう＝元に戻すには 再度なにかを吹きつけなければいけない、のかもしれない。
_ ジョギングのときにはリュック (Osprey Talon 18) の他に、胸にかけられる ポーチを使っている。EMU SERVE というブランドらしい。 鍵とスマホを入れつつ、ペットボトルをホルダーに収めて 走っている。そんなに上等なものじゃないのでゴムは伸びきってホルダーも 半壊しているような調子で、といっても機能を損っているわけではないのでそのまま 使っていたんだが、昨日ついにジッパーの持ち手部分が折れてしまった。 ジッパーは2方向から閉められるようになっているので、1つ壊れてももう1つで開け閉めは 可能なんだが、そっちも時間の問題だろう。
_ 透明な窓がついていてスマホを収納した状態で画面を見たり操作したりすることが可能… なんだが、そちらの機能は結局一度も使わなかった。出し入れが面倒だし、 汗で曇るし、ちょっと取り出して操作してすぐに戻す、という程度で私は十分なので、 それなら普通に収納していたほうがよい。
_ 多少不具合があっても根本的な機能を損っていないならそのまま使う、 という考えかたでやっているせいか、ある日突然壊れて打つ手がなくなる、というケースが多い。 すでに壊れはじめているものを使い続けておきながら「ある日突然」はないだろう、と 我ながら思うのだが… 革靴も少しずつダメージが蓄積しているので修理に出したいし、仕事で使っているカバンも だいぶぼろぼろだ。ジョギングに使っている靴はもう1000kmを越える距離走っているので 底はだいぶ磨り減ってしまっている。
_ そうそう昨日のジョギングは雨の中走ったので靴の中が完全に濡れてしまい、 なので風呂場で軽く濯いで干したところ、取り外し式の靴底の裏面にジョンの毛が何本か 刺さっていた。ジョン (の毛) は本当にどこにでもあるのでユビキタスというやつなのかもしれない
_ 自分のことができない期間に入りつつあるようだ。ここ2ヶ月くらい意図的に 距離を置いてきたが、その影響による部分もあるのかもしれない。 平均への回帰というやつか… 自分も周囲もまるで成長していないので嫌になってくる
_ 時代背景がそう読ませるのか、横溝正史の作品を思い出させるようなテイストがあった。 いわゆる連作短編というやつで、最後の書下し作品で大きく様子が変わって…という感じ。 どうもこういう「連鎖式」的な小説としてはかなり初期のものらしい。
_ 最後の書下し作品は、最初の段落から違和感を覚えるような、 今までの作品とのずれが出てきており、なんだこれ、と悩まされることになる。 それ自体はとてつもない真相に結びついたわけではないが、数十年の時間経過と 時代の変化を強く感じさせる結末はよかった。
_ 「私たちが星座を盗んだ理由」は、面白いが消化不良気味の話が多かったのに対して、 こちらはかなり面白く感じた。短編が5つ
_ 「見返り谷から呼ぶ声」。最初の1ページで抱いた印象から直感的に出てきた真相の形があって、 それは文字通りカンとしか言いようがないのだけど、読み進めてゆくうちにそれを 否定する要素がまったく見つからないばかりか、その真相を暗示する叙述に溢れているので そういった点での驚きはなかった。それでもラストは鮮烈な印象を残した。よい。 よいのだが、直感的に導くだけでなく、叙述の中からそれと確定することができていたわけではない。 このねたであれば当然気をつけなければいけない人数に関する叙述で 気付かなければいけなかったようだ。ペアを組む話や、約半分、といったあたり
_ 「千年図書館」。終盤あの話なのか、というのはすぐ想像がつくのだけど、 途中描かれていたものが何だったのか、といったことを理解できておらずそのまま インパクト大のラストに辿りついてしまった。
_ 「今夜の月はしましま模様？」。なんか雰囲気が軽いが辿りついた結末が途方もなくて ちょっと悪趣味感があった。
_ 「終末硝子」。これが一番よかった。 男爵の行動の意味については予想がついた…と思ったのだが、 終末の圧倒的な記述に翻弄されて、最後の一行で度肝を抜かれた。この人の 長編・短編すべての中で一番よかったかもしれない。
_ 「さかさま少女のためのピアノソナタ」。短かめ。で、ものすごい謎があるわけではないのと、 前の作品のインパクトがでかすぎて印象が薄い。
_ 面白かったが掴みどころのない小説だった。SF寄りの設定やそれによって生じる 不思議な現象は興味深いのだけど、それによってものすごい真相が導かれたという感じはない。
_ SF小説やアニメの科学的不整合を指摘して酷評するなんていう「SF警察」みたいな人を 指して、こういうのばっかりになったからSFが衰退したんだ的な話になっているようで、 SFファンやSF作家のわりと多くの人にとって共通の感覚らしい。
_ 個人的にはそういう指摘そのものはあんまり気にならない。さすがに見る価値がないとか 目が腐るといったような、科学的不整合という一点を理由に価値が消滅するかのような 表現で批判するのはどうかと思うけど、SFである以上科学的整合性に疑いがあるようでは だめだろうという感覚はある。ミステリでアンフェアじゃだめだろ、くらいの感覚。 私がSFやSFファンを煙たく思う瞬間は、科学的整合性に気配りを十分にしている作品を、 そうと理解できずに読んでいる経験の浅い読者に対してとやかく言うとか、 聞かれてもいないのに語り出すとか、そういった手合いを目撃したときだ。 このあたりの居心地の悪さというか、悪印象というか、もっと言うと反感といったものは 私にとってはジャズに対するものに近いものがある。もっとも こんなことを言っている人間をお仕置きしたくなる 気持は分からんでもない
_ 本もだいたい読んでしまい、荷物が多くてFireも持ってきていなかったので 久しぶりにAndroidのKindleとTalkbackで読書。 なんかいろいろ変わっている。以前使っていたのは古かったのかな。 ページ送りしつつ読み上げする操作方法を思い出せずうろ覚えでやってみたが 何度やってもうまくいかず、調べてみたら右スワイプダブルクリックでいいらしい。 わりと判定が厳しいので→PP くらいのつもりで入力したほうがいいようだ
_ 以前のTalkbackだと英語の設定にしていると日本語の部分はまったく読んでくれなかったが、 今は普通に日本語の部分も読んでくれるようだ。こりゃーべんりだなあ
_ 台風が近づいている。今度は17号らしい。このあたりはものすごい雨にやられる感じではないが そのかわり気温がかなり上がるようだ。
_ ふろ上がりに「季節の中で」をいい気分で歌っていたらGoogle Homeが反応して Spotifyで曲を流そうとしたので怖くなった (有料会員じゃないので結局流れなかったけど) 。 が、落ち着いて考えてみると 「め〜ぐる〜めぐる〜き〜せつのな〜か〜で〜」 の前半部分が Ok, Google として 認識された後に、「季節の中で」を聞かせろという指示であると 後半認識されているということなのかもしれない。んなあほな
_ ↓→ でグローバルコンテキストメニューを出して、そこでTalkbackを止めることができたような 気がするんだが、 その機能が見つからない。そこからメニューを辿ってタッチガイドだけを止めることはできるんだが 操作が煩雑だ。Volumeの+と-を同時押しするなんていうのはまだ残っているようなのだけど…
_ グローバルコンテキストメニューから「次のアイテム以降を読み上げる」を選ぶことで Chromeで見ているページの読み上げもできる。これは以前はできそうでできなかったか、 著しく使い勝手が悪かった記憶があるのでうれしい。 ただアイテムとアイテムの繋がりが少しぎこちなく、そしてハイパーリンクなどの要素も 「アイテム」になっているようなので、リンクの多いページはちょっと不自然に聞こえる。 Talkbackの用途を考えれば、そこにリンクがあることをアピールしなければいけないのだろう。 そう考えるとこのアピールで十分なのだろうかという逆の感想も浮かんでくる
_ -DCMAKE_TOOLCHAIN_FILE=ahyahya.cmake などとしてクロスビルド時の指定をすればよいのは 分かったのだが、冒頭のCコンパイラの検出の段階で失敗する。
_ コンパイルを試みる行を単体で実行してみたところとくに問題なく成功する。で、 その直前のメッセージ表示↓
@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --progress-dir=/cygdrive/c/local/libvncserver/build/CMakeFiles/CMakeTmp/CMakeFiles --progress-num=$(CMAKE_PROGRESS_1) "Building C object CMakeFiles/cmTC_011e1.dir/testCCompiler.c.o"で、exit codeが0以外になっているようだ。その行も単体で実行する限りでは問題なさそうなのだが…
_ ？？ /usr/bin/cmake.exe という指定方法だとだめらしい。
$ cat Makefile
all:
@echo ahyahya.echo
@/usr/bin/echo ahyahya./usr/bin/echo
@cmake -E cmake_echo_color ahyahya.cmake
@/usr/bin/cmake -E cmake_echo_color ahyahya./usr/bin/cmake
@/usr/bin/cmake.exe -E cmake_echo_color ahyahya./usr/bin/cmake.exe
$ which cmake
/usr/bin/cmake
$ make
1 [main] make 32476 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report this problem to
the public mailing list cygwin@cygwin.com
ahyahya.echo
ahyahya./usr/bin/echo
ahyahya.cmake
Makefile:2: recipe for target `all' failed
make: *** [all] Error 127
_ Process Monitorで見てみると、うまくいかない方は -1073741701 というexit statusで終わっている。 Hexだと0xc000007bで… あれ、makeはx86のCygwinで、cmakeはx64なので… そのせいか。
$ uname -a CYGWIN_NT-6.2-WOW64 G-03392 1.7.11(0.260/5/3) 2012-02-24 14:05 i686 Cygwin $ /cygdrive/c/cygwin/bin/cmake.exe -E cmake_echo_color abcde /usr/bin/cmake.exe: error while loading shared libraries: cygidn-11.dll: cannot open shared object file: No such file or directory32bit版はとある組み込み向けのSDKがいっしょに入れたやつで、クロスコンパイラも こっちに入っているのだが、なにしろ古いし、あまり中身をいじりたくない。
_ …… ビルドが途中で止まってしまったが目的のライブラリは出来上がっているのでよしとする。 32bit版Cygwinの中で64bit版のCygwinのアプリを起動させるための準備がいろいろ足りていないだけだった。 たとえばPATHが通っていないとか、 64bit版Cygwinの、/usr/share/cmake-x.yy.zz にあるソース類が、 32bit版Cygwinで入れているToolchainから見えなかったりとか、 そういったあたりを解決する必要があったようだ。
_ EMU SERVE というブランドのポーチがだめになってしまったのでかわりを買った。 前のもののよさがいまいち自覚できていなかったが、新しいのを使ってみると 前のもののよさがいろいろ見えてくる。 EMU SERVE のやつは3点で固定するので、きつく締めなくてもあまり揺れがない。 ペットボトルも胸のあたりにあるので邪魔にならない。など。 今回購入したものは腰で固定するか、たすきがけのようにするらしい。 しかし3点固定ではないので、たすきがけにすると重たい部分が下に落ちてしまいそうな気がする。 今回買ったのは3点固定ではなく、スマホ用の窓みたいな大袈裟なものもないので、 かなりコンパクト。
_ ゴムやジッパーの質感は元のと大差がないので、おそらく同じように壊れることになると思う。 EMU SERVE のものは2015年10月に買ったようなので、4年もったことになる。 おそらく、だめになってからかなり長い間使っていたので、わりと早く壊れたという印象が ありつつも、長持ちしたという真相になるのかもしれない。
_ 前回の台風 (15号) で、実家の屋根が実は大きなダメージを受けていたことが 先週になって判明したらしく、週末に応急処置だけをしてもらったらしい。 もともとほとんどメンテナンスらしいこともしていなかったため老朽化が進んでおり、 けっこう大がかりな修復作業が必要になる、かもしれない、という話らしい。 保険がきくようだし、それによって負担額も変わってゆくのだろうけども、 修復をしてくれる方々も、保険会社の方々も、現時点で超多忙らしく、 結果として出遅れた我が家の対応が決まるのはけっこう先の話になりそうらしい。
_ このままここ (この会社) にいていいのだろうか、みたいな逡巡は 常にあり、それは周囲に対する不満のあらわれだったりすることももちろんあるし、 自身がこの先この会社でどういった人生像を描いてゆくのか、ということに 対する迷いみたいなものがあらわれていることでもある。
_ 苦痛や迷いが差し迫った強度を持っているときというのは、十分な時間をかけずに 妥協を含んだ選択をしてしまいがちだし、 そういう気分が落ち込んでいる状態というのは判断力も鈍っているだろうから、 満足のゆく選択をすることはなおさら難しいと思う。 一方で、そういった境遇が少し落ち着いてしまったりすると、生来の 変化を嫌う性格が前面に出てきて、ちょっと前の苦痛や負の感情なんかも 急速に忘れていってしまう、なんてことになる。
_ もうちょっと、「1. 辞めて転職をする可能性を留保しつつ働くこと」や 「2. 現職に留まる可能性を留保しつつ転職先を探すこと」ができないもんかな、 と思ってしまう。 2については考えかた次第なのかもしれないし、 「今よりよいところが見つかったら転職する」という多くの人にとって 自然な感情で転職サービスなんかを利用していればいいのかもしれないが… しかし先に短期的に先に進む気がないことを明言してなおそういうサービスを 利用する価値があるのだろうか、という気持も一方ではある。私だって 公募的な性質のあるサービスから紹介された人を面接することになった場合に、 上記のような意図を伝えられたら、ん？と思ってしまう。
_ 結局のところ、その「今よりよいところが見つかったら転職する」というやつを、 日頃から続けていって、タイミングが合えば完遂する、 という形をとらざるを得ないのだろうか。それは多くの人が私にアドバイスをしてきた 内容と一致するような気もする
_ どっちにしても転職が成立することで利益が発生する 世界に求める内容ではないのかもしれん。実現するにはそれなりの世渡りが 必要な気がするが、本来の利用方法でない以上そのための努力が有意義であるとは 思えない
_ 10日ほど経過した。おかげさまで習慣になったので この先も続けることができると思う。ここに至るまで何年もかかっており、 そのための準備をしたわけでもないので無駄な逡巡だったと思うほかないが
_ Shadowingは、シャドーイング100本ノック！という プレイリストが手軽そうなのでそれを試している。 #1 を一週間くらいやって、現在は #2 をやっている。1日20分〜30分、で、 休みの日は昼と夜で2回やることもあるので、現時点で10時間弱くらいは 取り組んでいることになるだろうか。#1 をはじめてやったときの手探り感を 考えると、少しは進歩したと言えるのかもしれない。 1本1週間、時間にすると3〜4時間、 というのは十分な時間をかけているとは言えないのかもしれないが、 1週間くらいでほぼ暗唱に近い状態になるし、その状態で繰り返していても 音声認識的な精度がアップするわけでもないし、そもそも飽きるので、 このあたりが妥当なところだろうか、と思っている。 この先 #100 までやるかどうかはわからない。他の素材に浮気するかもしれない。 仮に #100 まで1本1週間のペースでやるとすると完遂までおよそ2年か。 取り組みを始めるのが簡単なので、他の教材で挫折したり、 いろいろあってある程度の期間さぼったりした後の復帰のときにも 使えると思うので、3年で全部やる、みたいな感覚で取り組もうかな
_ The Jinglesは85を取り組んでいる。Shadowingの前に5分くらい。 気をつけなければいけない個所がかなり多いので、 指示通りにきちんと出来ている気がしない。なので1周目はdry runのつもりで とにかく先に進んで、2ヶ月かけて2周することを考えている。 その後に86に進むかどうかはそのときに考える。
_ これまでの取組を尊重しないばかりか理解しようともせずに、 自分ならどう実現してゆくのかも考えずに、 感覚だけで物を言って行き詰まる人間はもう何度も見てきたし、 そういった人達の浮足立った調子を批判する芸風だったはずの人が 大臣になった途端にこれか
_ 分類した後にそれをどう生かすか、まで見てみたい気もするけど、 分類と整理に苦心している跡も見えるし、その気持はよくわかる。 分類することの必要性は私自身も常に感じている。 同じプロジェクトの中にいる技術者の、何に価値を感じて、 何を成功と定義していて、何を苦痛に思うのか、といったものが、 ものすごくばらばらだ、ということを感じる場面があるからだ。 同じ仕事に取り組んでいるはずなのにここまで価値観が異なるのか、 というのは考えようによっては恐しいことだと思う。
_ また、 プロジェクトをマネジメントする側には、そういった価値観の多様性に 気付いていない人も多く、修復不能な亀裂が生じた後でも相手が何を問題にしているか 理解できない、または重大な問題であると理解しようとしないケースがある。 そういうことが身のまわりで起きると、 残された人達の健康が万遍なく損われてしまう。
_ もう何度挫折したか分からないが懲りずにFeed Aggregatorで記事を読むことにした。 今までと異なる点としては、英語で記事を読みたい、というだけでなく、 日本語の記事を読む機会を減らしたい、というのも動機に含まれるというのがある。
_ 朝日と産経という両極端のスタンスを持つ新聞のオンラインサイトを読むという 生活を続けていたのだけど、どうも客観性に欠けるというか、 事実と願望が混じってるように見える記事や論説が多すぎて、 バランスをとるために両極端のものを見ているつもりでもなんだかすっきりしない。 そして目に入るだけで気が滅入るようなくだらない記事が多すぎて精神衛生上よくないので、 これをやめようというのが動機のひとつになっている。
_ 日本のニュースを英語で読めるサイトというと、Japan TodayとかJapan Timesなど 少数しかないので、そのあたりをフォローしつつ、CNNとReutersとAl Jazeeraを読む、 といった感じでしばらくは運用してゆこうと思う。なおそういったサイトに 気が滅入るようなくだらない記事がないのかというと、たぶんあると思うんだけど、 私の場合、英語だとそのあたりの感受性がだいぶ落ちるので、精神衛生上は比較的ましだと思う。
_ で、Feed aggregatorには表題のものを使ってみることにした。普段はブラウザで見ていて、 移動中もスマホで見ることができて、双方で購読状況を共有できて、といったあたりが 選定基準だった。もともとFeed Aggregatorを生活の中に入れるのに苦労したり挫折したりしてきた 歴史があるので、無料アカウントだとちょっとしか登録できませんだとか、 フィルタが貧弱ですといったような制限は気にしないことにした。
_ 仕事中に飲むものに困って、あまり飲みたいとも思わないインスタントコーヒーなんかも 飲んだりしていたものの、もう少し自分が飲みたいものを用意してどうにかしようという 気分になってきたので、ハーブティ (ワイルドストロベリー) と紅茶 (QUEEN ANNE) を 持ってきた。QUEEN ANNEは、 事務所を借りて少ししてから買ったものなので、 もう2年半も前のものだ。カビが生えていたり変なことにはなっていないが、香りはだいぶ 弱くなってしまっている気がする。
_ 組み込み端末はフレームバッファ (/dev/fb0) がとれるので、 DDMSみたいに遠隔でスクリーンショットをとることができるようにして資料や マニュアル作りの際に便利に使っていたのだが、今度は動画をとってみたくなった。 スクリーンショットを連続でとって送れば動画になる、というのはあたりまえだが、 1フレーム600KBくらいあるのでこれでそれなりのフレームレートを確保するのはむずかしい。 となると圧縮しながらストリーミングできるようなエンコーダーを仕掛けて…と考えると、 組み込み端末はけっこう貧弱なのでエンコードが足を引っ張るような気がする。
_ などと考えた末、VNC (RFB) なら遠隔に画面を飛ばすことができるわけだし、 作りかたによってはタッチやキーイベントをやりとりする、なんていう制御も可能になるだろう。 動画にしたければvnc2flv が使えるだろうし、 クライアントを工夫すれば端末側の各種イベント、キーパッドの押下や タッチ操作、カードリーダーへのアクセスをそれっぽくクライアント側でモニタリングしてみたり、 PC側から擬似的にアクセスさせるようにしたり、と、いろいろ応用の幅が広がりそうな気がする。
_ フレームバッファ (/dev/fb0) ベースのVNCというとfbvncというのがあるんだが、これはクライアントだけみたいなので サーバを入れたい私にはそのままの形では使えない。 なのでlibvncserverをきちんと使うしかないかなーと思いながら試行錯誤して、 CMakeでクロスビルドすることができるようになったので、 組み込み端末にVNCを入れる実験ができるようになった。 というのが長い前置きだ。 examples の中に入っている androidvncserver.c というやつが自分のやりたいことの 原型とほとんど一致しているので、これを都合のよいように移植してみた。 ひとまず端末側の画面が出てくるところまではさほど困難もなく実現できた。 そのままだと画面の更新を送信しそびれることがあるようなので、 1秒に1回画面全体を送信するようにした。
_ 画面の上半分しか表示されていないというのが大きめな問題点としてある。 色がおかしいとか、ずれているということもなく、ただ下半分が出てこない。 rfbGetScreen に与える heightを倍にすると、ひとまず画面全部を表示させることは できるんだが、それと同じサイズの黒い部分がVNCクライアント側に出てくる感じ
_ お手本にしたソースのissueに同じ症状の件が 上がっている。 とくに何か対応をしている形跡はないが… libvncserverの中身をきちんと理解しようとしていないのできちんと理解してから調べることにする
_ RFB (Remote Frame Buffer) は RFCになっている。 サーバ→クライアント に対してできることはあんまり多くないようだ。 サーバ側で起きていることをイベント的にクライアントに知らせたいと思っているんだけど、 手頃なものが見当たらない。まあ遠隔操作のためのプロトコルなのでそんなもんなのかもしれないが… どうしてもこの枠組みの中でやりたかったら ServerCutText を流用するような 感じになるのかなあ？ libvncserver だともうちょっと他の方法もありそうな感じがするが
_ 最近の口内炎はなかなか長生きでそしてでかい。たまに目が覚めるような痛みを訴えるときがあり、 たくさんすれちがった口内炎のひとつでしかないとはいえ、わざわざ記述したいと思う程度には 深いつながりになっているようだ。
_ 「シャドーイング100本ノック！」は、同じ人の安定した発音で練習できて、しかも無料で 利用できるので大変よいと思うのだけど、ただ書いてある通りに喋っていないことがあって、 単語を飛ばしたりセンテンスまるごと飛ばしたり、というのが散見される。#1 からすでに そんな感じで、実際にShadowingを始める前段階の、表示されている文章を読みながらついてゆく (こういうのを overwrappingとか parallel reading いうらしい) の段階でかなり戸惑う。 #3 はその傾向が とくにひどかったので飛ばして #4 に入った。
_ どうせ繰り返すなら喋っている内容に関心があるやつの方がいいんじゃないのか、ということで スピーチ系のShadowingをちょっとだけ試してみたんだけど、テンポが一定でないなど 練習にはあんまり向いていないかもしれない、という印象。スピードが速すぎるというのは 再生側でどうにでもなるのであまり問題はない。
_ Wikipediaの記事によると、 リテンション能力向上のために1〜2秒遅れてついてゆく、という訓練もあるらしい。 この能力があるかないかでTEDICTやディクテーションの効率はだいぶ違う気がするのだけど、 少なくともTEDICTを繰り返しているだけではこの能力はさほど酷使されないようだし (自動ループ再生やっているせいかもしれない)、訓練する方法がないもんかと思っていたので Shadowingに慣れてきたらそっちもやってみることにする。 「K/Hシステム」の人達が書いた本ではリテンションの訓練方法として、 一定の塊の英文を聞いてからそれを復唱する、というものが出ており、それはちょっと 負荷が高すぎるなあ〜 と思っていたところだった