クルマについて考えるようになって1年くらい経つけどまだ買ってなくて、とはいえカーシェアやレンタカーでそこそこ運転したことで *1 ペーパードライバーは脱出しつつある気がする。

polamjag.hatenablog.jp

去年の後半くらいの暇なときには Motor Fan illustrated という雑誌が Kindle Unlimited でだいたい全部読める (すごい) のをかいつまんで眺めていた。

https://www.amazon.co.jp/s?k=motor+fan+illustrated

クルマのメカには興味あるけど、パーツなどをカスタマイズして最高のチューンにしたいぜ、みたいなモチベーションは特になくて、自動車メーカーやサプライヤーがどういう原理のもと何を考えて自動車や部品を作っているのか、みたいな話のほうが興味あるんだなということがわかってきた。Motor Fan illustrated はそういう気持ちに応えてくれる雑誌だと感じる。

爆走することよりは、移動すること自体に喜びを感じているのかもしれない、という話をしていた。移動するだけで楽しい空間を移動することに喜びを感じる的な……。移動するだけで楽しい空間とは、首都高や風光明媚なスポットなど移動してなくても楽しい空間や、あるいは楽しい構造や線形を持つ道路というイメージ。そんでもって、屋根が開くクルマは移動の楽しさが非常に強化されるということも改めて感じていて、ダイハツコペンに行き着く (?) ことになる。

www.daihatsu.co.jp

で、般若ロボットなどと呼ばれる Robe の顔について思いを巡らせていた。まあ嫌ではないし、どっちかというと好き側な気がするんだけど釈然とはしないな〜と思っていたところにプジョーの最近のデザインが目に入ってきて、こういうことかと腑に落ちたということがあった。

プジョー 208 と COPEN Robe の顔の比較 (印象)
プジョー 208 と COPEN Robe の顔の比較 (印象)

プジョーの横のシュッとしたラインはライオンがカギ爪でシャっとやった痕がモチーフという設定らしいけど、コペンのそれがどうなのかはわからない。わからないけど、コペンの場合は爪痕の下端でフォグランプ周辺の樹脂パーツと造形が一体化しているという違いがあり、プジョーの顔と比べるといまいちシュッとした感じがしないのが引っかかっている気がする。

脈絡なさすぎだけど、プジョーのクルマを買うイメージは正直あまり無いんだけどなんとなく気になるので試乗くらいはしてみたいねっていうのが現状。実物見たことないけど 3D i-Cockpit も結構いいと思うのだよな……

www.youtube.com

*1:一般道・高速・首都高 合わせて数百キロは運転したと思う

DevTools の Web 技術でできている部分を覗き見る

この記事ははてなエンジニア Advent Calendar 2021 の 22 日目の記事です。

昨日の記事は id:shimobayashi さんの アジャイル推進活動にここ1年で吉兆がみえてきた要因について - 下林明正のブログ でした。


Chrome の DevTools の UI 部分は Web 技術でできています。Web 技術でできているので、DevTools を DevTools で inspect することもできます。

f:id:polamjag:20211222005603p:plain
example.com を inspect している画面を inspect している様子

このことを知ったのは、10MB くらいある JavaScript ファイルにブレークポイントを貼りつつデバッグしていたら DevTools が固まるようになってしまい、ブレークポイントを解除しようにもその前に DevTools がフリーズしてしまうので詰んだ……、という出来事に遭遇したのがきっかけでした。なんとかならないかと思ってごちゃごちゃ検索していたところ、次の Stack Overflow のページにたどり着きました。

stackoverflow.com

DevTools の設定や Console の入力履歴 (JavaScript の REPL のアレ)、ブレークポイントの設定などは DevTools の localStorage に永続化されています。したがって、DevTools を DevTools で inspect して、localStorage を適当に書き換えることで、そのあたりを自由に改変できます。……というわけで、Chrome の DevTools の UI 部分は Web 技術でできていることに改めて気づきます。

f:id:polamjag:20211222015552p:plain
マジです

ソースコードはこのあたり。

リポジトリルートに ARCHITECTURE.md というファイルがありそうなので眺めてみると、

https://github.com/ChromeDevTools/devtools-frontend/blob/09efec39cdd94dd63b375d2aaac08f7038a05741/ARCHITECTURE.md

  • Guiding principles
    • Web Platform Design Principles というドキュメントがあるらしく度々言及されている
    • DevTools はでかいから Load only what is necessary しようね、という話
    • DevTools ships every single day in Canary builds of Chromium-based browsers. It is therefore risky to halt development during a migration (even for a couple of weeks), as DevTools can cause Canary builds to break and effect not just end-users, but also engineers working on the web platform itself であることに気を遣おうという話
      • それはそうって感じもありますが、それ以上に尊さを感じます。実際 stable に降りてきてない機能を試すには Canary 使うしかないわけなので……
      • 闘うプログラマー的なエピソード感もありますね
    • 一方で Use flexible third_party libraries whenever necessary という話もあって柔軟
  • Startup process overview
  • 実際のフォルダ構造 (とビルドシステムとの連携) の説明

README から Chrome DevTools Contribution Guide というドキュメントが参照されていたのでこれも眺めてみます。これは Google ドキュメント

docs.google.com

"How DevTools Works" という見出し以下の箇所 に良いことが書いてありました:

DevTools is a web app that talks the DevTools Protocol over a WebSocket to a backend within Blink's C++. The devtools-frontend github wiki is the best current documentation on the various components of DevTools, including architecture, testing, etc

WebSocket! と思いコードベースを wss で検索してみたところ、いかにもそれらしいコードがありました

github.com

  • ES Class の private なフィールド (# 始まりのアレ) がめちゃくちゃ使われているのも目を引きます
    • TypeScript の private フィールドから移行するのが細切れに実施されているようでした https://crbug.com/1222126
  • というのを見ているあたりで Node.js のデバッガに DevTools を使うことができるという話を思い出した
  • これ WebSocket で実際にやり取りされてるメッセージを見たいよな〜と思ったんですが、ひとまず Remote Debugging の仕組みを使いつつパケットキャプチャを走らせると普通に確認できました。おもしろい
    • https://chromedevtools.github.io/devtools-protocol/#remote
    • 具体的には --remote-debugging-port オプションを指定して Chrome を起動しつつ、別の Chromeインスタンスchrome://inspect からそれにアタッチする、ということをやると通信が始まります。素朴に開始すると平文の HTTP + WebSocket で流れていくので、手元のマシン内で全部完結してる場合は Wireshark とかで loopback デバイスをキャプチャすると狙った状態になります

f:id:polamjag:20211222101602p:plain
適当な Web サイトを開いたときの流れの様子。React Developer Tools がインジェクトされましたという雰囲気


最初の話に戻ると、ブレークポイントの情報が localStorage に保存されている、というのはこのあたりでの出来事でした。


という感じで、普段 Web アプリケーションエンジニアとして仕事をしているうちの相応の時間は DevTools とともにあるわけですが、そんな DevTools も Web アプリケーションの一つの姿であることが垣間見れて面白かった、という話でした。

余談ですが、どうやら他のブラウザも似た感じの構造になっていそうな雰囲気を感じるので、次はこっちも眺めてみるか〜という気持ちになっています。


はてなでは、普段から Web ブラウジングをしているときに手癖で DevTools を起動してしまう Web アプリケーションエンジニアを募集しています。

hatenacorp.jp

2021 年刺さった曲

f:id:polamjag:20211208001305p:plain

今年も順不同でやっていくぞ!残り23日ほどありますが…………

優勝

CITY2CITY

CITY2CITY

もともと名二環全線開通のCMソングだったわけですが、無防備な状態でいきなりテレビからこれが流れてきたら腰を抜かすと思う。

www.youtube.com

フル尺の配信リリース is 2021 年を振り返って最も助かった瞬間

首都高C1が都心のうっかりサーキットなら、東京モノレールは東京ベイエリアのうっかりジェットコースター性があると思う

準優勝

One Last Kiss

One Last Kiss

この曲を A. G. Cook がプロデュースしてなかったら今年エヴァこんなに見てなかったのでは?という気すらする。収まるべき感じの収まり方という雰囲気を醸し出している気がするけど、めちゃくちゃ怪曲だと思う。安室奈美恵と SOPHIE がコラボした回を思い出す………。

polamjag.hatenablog.jp

今年は A. G. Cook は Apple の仕事もしていてこれも驚いた。このときの Apple Special Event はリアタイで見てなかったので後から知った……

www.youtube.com

これも思い出すね

www.nicovideo.jp


Wake Up, Girls - 素顔でKISS ME (2015 年) 以来 (polamjag 調べ) の田中秀和BPM 174 楽曲!!!!!!!!

アマカミサマ

アマカミサマ

  • 名取さな
  • アニメ
  • ¥255


田中秀和の曲を Tomggg がリミックス → 無条件で最高

ちなみにこの曲 (BPM 160) をキーロック的なやつ無効状態において +12.1% くらいで流すと BPM 180 弱で キーが 2 つ上がった状態になり ↑ のアマカミサマとハーモニックミキシングチャンス発生します

Ouverture (Happiness 4 you!)

Ouverture (Happiness 4 you!)


良い〜〜〜

Salmon Cannon

Salmon Cannon

  • NANORAY
  • ダンス
  • ¥153

NANORAY のことは DJ TECHNORCH のこのミックスで知りました、さよひめぼう さんが好きな人は絶対好きになると思う

soundcloud.com


収まるべき感じの収まり方2

GRADIUS REMIX(↑↑↓↓←→←→BA Ver.)

GRADIUS REMIX(↑↑↓↓←→←→BA Ver.)

  • Tokyo Machine
  • ダンス
  • ¥255


そうはならんやろオブザイヤー2021です

どどんぱ

どどんぱ


秋奈さん目当てだったところから見つけてしまった、作曲の Giga さんとはギガPだし Ado の 踊 の方であった、世界……

そして 踊 は意外と今年の曲でした

踊

  • Ado
  • J-Pop
  • ¥255

電音部枠そのN

CHAMPION GIRL

CHAMPION GIRL

  • 電音部,Giga,鳳凰火凛 (CV: 健屋花那)
  • エレクトロニック
  • ¥255


シンプルに最高、クラブで聴きてえ〜〜〜

Another Level

Another Level

In My Arms

In My Arms


magical mode

magical mode

ゾゾタウンの中国進出テーマソング的なやつ、の日本語版。神前暁作曲。なぜか中国語バージョンのほうがしっくりきて面白い気がするので ↓ のビリビリ動画のやつも見てみてほしいッス

www.bilibili.com


twilight

twilight

  • 電音部,Tomggg,黒鉄たま (CV: 秋奈)、白金 煌 (CV: 小宮有紗)、灰島銀華 (CV: 澁谷梓希)
  • エレクトロニック
  • ¥255

www.carsensor.net


助かった

Touhou Riddim

Touhou Riddim

  • バーチャル・ライオット
  • エレクトロニック
  • ¥255


Andrey Loud しっぽりって感じで良くて妙に気に入ってます

88 Birds

88 Birds

  • Andrey Loud & Bronxy
  • ダンス
  • ¥255

soundcloud.com


しっぽりダンサブル枠。去年くらいからこういうのばっか買っている、ヨーロッパ行きてえ

Dark Nights

Dark Nights

  • M-High
  • エレクトロニック
  • ¥204


激ダンサブル枠、というか ↑ の どどんぱ がどっちかというとこっちがわの文脈なのが際立つという感じがある

Route 246

Route 246

  • CARPAINTER
  • エレクトロニック
  • ¥255


capsule!!!!!! かつ車枠そのN……

ひかりのディスコ

ひかりのディスコ

  • CAPSULE
  • エレクトロニック
  • ¥255

www.youtube.com


助かった!!!!!

雲散霧消

雲散霧消

  • かめりあ
  • ダンス
  • ¥255


Noisia と Skrillex………

Supersonic (My Existence)

Supersonic (My Existence)


いかがでしたか?

去年の様子はこちら:

polamjag.hatenablog.jp

MacBook Pro (13-inch, M1, 2020) を macOS Monterey にアップデートしたら HFS+ な外付けストレージがまともに使えなくなって困った日記

状況を箇条書きで説明すると、

  • MacBook Pro (M1, 2020) を macOS Monterey 12.0.1 (21A559) にアップデートした
    • ……ら、Music.app のライブラリ置き場として使っていた SSD (USB 3.2 (USB-C) 接続、HFS+ on MBR) への読み書きがまったくまともにできなくなった
      • なんで HFS+ on MBR なんかを使っていたかというと、Pioneer DJ 製のデバイスが読み込めるファイルシステムはこれと FAT32 だけだから
      • Music.app (iTunes) のライブラリを外付けストレージに配置しつつ、rekordbox のライブラリも同じドライブに配置することで、CDJ にそのドライブをぶっ刺したらライブラリをまるごとロードできるという技を使いたくてこうなっている
    • 読み書きがまともにできないというのは、
      • Finder で開くと、ディレクトリの中身がロードできたりできなかったりする
      • ディレクトリの中身がロードできたときに、そのへんに転がっているファイルを適当に複製しようとすると、Finder はレインボーカーソルになって帰ってこない
        • この間 Console.app を勘で眺めてもめぼしいログは出ていない
        • eject 操作とかできる感じでもないので、SSD を引っこ抜くと Finder のレインボーカーソルは収まる
      • ls コマンドとかでアクセスしても結果が帰ってこない
      • 清水の舞台から飛び降りるような気持ちで macOS を再インストールしてもまったく状況は改善しなかった
        • セーフブート時はディレクトリの一覧を取得できる確率が高かったような気がするけど、ファイルの複製とかは同様に刺さってまったく完了できなかった
      • Big Sur のブータブルメディアからダウングレードできないかと思ったけど、ブータブルメディアを認識させたところでもう Big Sur にはダウングレードできませ〜んっていう表示になってしまった。ちゃんとしてる……
  • 似たような構成 (HFS+ on MBR) の SSD がもう一個あって (こっちは写真ファイルとかを入れてた)、そっちも同じような状況だったので、勘で APFS 化してみたところ、まともに読み書きできるようになった (??)
    • Disk Utility.app には HFS+ をインプレースで APFS 化する機能があるけど、MBR なドライブでは使えなかった……ので、そのへんに転がっていた HDD にバックアップをとりつつ、まっさらに APFS on GPT でフォーマットした
    • という一連の作業はそのへんに転がっていた Intel の Big Sur 機で実施した。なんか怖いのでしばらくこいつは Big Sur のままにしておくかという気持ちになっている
    • 最初に話題に上げた SSD に対してもこれをやったらちゃんと M1 の Monterey 機でも読み書きできるようになった。わけがわからない

で、その過程においてメインで使っていた M1 のマシンを吹っ飛ばしてしまったのでいろいろ手で戻していて、rekordbox の原状復帰で若干手間取ってしまった。ここで上の箇条書きの最初の話に戻るんだけど、

  • rekordbox は、エクスポートしたドライブにライブラリを配置するときは、ドライブルートに .PIONEER っていうディレクトリを作り、その中にライブラリファイルなど諸々を格納するようになっている
    • エクスポート先のドライブと、「データベースの管理」機能を使うときのライブラリの配置先のドライブが同じであるときは、マスターとなるライブラリの情報も .PIONEER ディレクトリに保存されている……と思う (勘)
    • んだけど、上述したように APFS のドライブはエクスポート先のドライブとしては使えない。こういうときは、ドライブルートに作られるライブラリの配置先ディレクトリ名は PIONEER (頭にドットがない) になるようだった
      • いま (rekordbox 6.5.3 時点) 僕の手元のマシンではそうでした、というだけの話です

この話にはオチはない。疲れた……

失われていた日常が取り戻されつつある……という風潮を感じるけど、外を出歩けるようになって嬉しいという気持ちは思ったより湧いてこなくて、家に引きこもるのは良いことであるみたいな価値観が失われてしまうと面倒だなという気持ちのほうが強い。都心からやや離れた場所に引っ越してしまったとか、そういうファクターはあるんだろうけど、別に引っ越してなくてもそういう気持ちにはなっていただろうと思う。

失われていた日常が取り戻されたとして、日常が失われる直前の人生を一時停止していたのをリジュームするような暮らしになるかというと、そんなことはないだろと思うわけだけど、話題によってはそういう気持ちになるものもある。クラブに集まって飲酒できるようになったよね *1、とか。とはいえ、全体としては不可逆な変化が起こっていて、結果オーライとしては歓迎したい変化のほうがたぶん多かったとも思えるので、この1年半くらいの日々よ……という気持ちにならないでもない。何が言いたいかというと、パンデミックがもっと続いてほしいと思っているわけでは当然なくて、とはいえ引きこもるのが正義みたいな世界は自分にとって極めて快適だった、一方でそれによって失われた機会、私生活みたいなものをどう評価したらいいのかはまったくわからない、みたいな感じです。この話にオチはない。

f:id:polamjag:20200529135528j:plain
2020年5月の渋谷

*1:よく行っていたほぼすべてのクラブは都による飲食店に対する諸々に完全に従っていて云々という感じだった

オープンドアポリシー

オープンドアポリシーは意味ないという主張を id:shimobayashi さんが一貫してされているのが印象に残っていたんだけど、要するにこの話じゃん、という接続が脳内で発生して妙な満足感があった。

note.com

shimobayashi.hatenablog.com

  • ドアが開いているからといって、そこに突入すると何が起こるのか理解されていないと意味がない
    • どんないいことがあるのか
      • どんな問題がどう解決するのか
    • そもそも、ドアの先にいる人は自分のことを受け入れてくれるはずと思えているか
  • 実際どうかという話ではなくて、ドアをくぐってきてほしい人に上記の事柄が理解されていて、ドアをくぐってもらえていないと意味がない、という話
    • 大在宅勤務時代の今では、このへんのコミュニケーションを雰囲気でなんとかするのはとても難しそう (それはそう)
    • 組織の文脈を知っている、あるいは察するのが得意な人はオープンドアを活用できるかもしれないが、そうでなければ難しい
      • オープンドアを活用できている人とそうでない人で格差が生まれることもギクシャクポイントだと思う
    • これを理解してもらうためにできることの一つ、あるいはドアをオープンにしておくことで解決したい問題を解決する別の方法は 1on1 のように対話的なコミュニケーションを積み重ねることである、というのは筋が通ると思うので、一周回っている感じがする

なんらか特定の問題についてひたすら考え続けた結果、その問題の根っこと思える真理を発見した気になる、ということがあって、一方でその真理に必殺技を直撃させることで一連の問題が雲散霧消するか……というとそうでもない気がする、あるいは必殺技のパワーに自信がない、ということで、どうしたらいいのか全くわからなくて途方に暮れていた。

暮れていたんだけど、いろいろ会話したりすることで次の答えがわかってきて、

  • 問題の根っこがわかっているからといって、問題の根っこを一発で解消することだけを考える必要はない
    • その根っこに向かって、枝分かれしている個々の問題に対処していけばいい、という考え方
    • 結局個々の問題に対処していくんだったら、それぞれを場当たり的に解消するのと変わらなくて、問題の根っこがわかっている必要はないのでは?という気がしていたけど、問題たちが脳内で適切につながっていたほうが、個々の問題の優先順位や依存関係について議論しやすい、というアドバンテージが考えられる
      • そのマスにたどり着くまで何が書いてあるのかわからないすごろくよりは、すべてのマスの文言が見通せるすごろくのほうが不確実性が少ないはず (本当に?)
  • また、問題の根っこがわかっているからといって、そこに一直線に向かっていく道筋を考えるのが最適とは限らない
    • 一歩進みはするものの、一歩下がって二歩進んでいるのでは?と思い始めると、損したような気持ちになってしまうけど、そうすることで進むことというものもある

書いてみると当たり前じゃんって感じだけど、根っこの問題がデカすぎるのでは???という厳しい気分に支配されると何も考えられなくなってしまうし、しかしながら真理を発見したのだからそこに一発カマしてやりたいぜ、という感情も湧いてくる。一方で、根っこの問題が本当にデカすぎるものだった場合、そのことを正しく理解していて損することはない……とも思うので、要はバランスだなと思った。この話にオチはない。