1年間分で43000円くらいのAdobe税を今年も払ってしまった。定常的に使っていると言えるのはLightroom Classic CCくらいで、あとはものすごく稀にIllustrator > Premiere, Audition, Photoshop > Lightroom CC > After Effectsくらいの序列でなんか触るかどうかというくらいで、ソフトウェアの価値そのものというよりは、その気になればこれらをいつでも使える状態であることに金を払っているような気分になる。フォトプランで十分なのでは説がまあまあある……。来年はそうしてしまいそうな気がする。

1年間分の権利に一発で数万円を払うという点に注目すると、最近の買い物のなかだと自動車保険が近くて、決済ボタンを押すときのエイヤ感みたいなのが似てそう。

車買った #la400k

型式 LA400K で知られる現行型のダイハツ コペン ローブ。選んだ基準は以下の通り。


自動車の所有に最初に関心を持ってからだいたい足掛け1年くらい、現行型コペンのカーセンサー新着を熱心に眺めるようになってから2ヶ月くらいでフィニッシュ。他に頭をよぎったカーとしては、ロードスター・ミニコンバーチブル・トゥインゴキャンバストップ・207CC・マイクラC+Cあたり。現実路線として屋根が開かないカーではスイフト・ヤリス・N-ONEあたりも眺めていた。

ディーラー試乗も一度やってみたけど、なぜか神奈川のオリックスレンタカーコペンを普通の料金で借りられるキャンペーンをやっていて *1、それで1日ぶん回せたのが完全に決め手になったと思う。

car.orix.co.jp

ここ半年くらいで都心からやや郊外に引っ越して、関東近郊・東京通勤圏内のベッドタウンでも意外と車社会やんけ!!ということを思い知ったのもアシストポイントだったような気がする、というか、それを狙ってもいたので予定通りではある。


良かった、というか背中を押してくれた記事たち。ゼロカウンタードリフトがどうみたいな話を見ていると、ジムカーナとかやってみないと損なのでは?という気持ちになってきてしまう。さすがにロールバー付けたりするところまではいかないと思うけど……。

response.jp

response.jp

www.itmedia.co.jp

ペダルカーでしょっていうコメントを見て笑ってしまったけど、キャラクター的には褒め言葉になってしまいそうな感じすらある。ペダルカーでスーパーに買い物行くぞ!ってなったら大はしゃぎだと思うけど、そういう感じで (?) そのへんに買い物に行くだけで楽しめる車だと思う。これで ADAS 付く改良が入ったら新車で買ってしまいそうな気がするな……。

*1:定期的に店舗ローテーションしてるみたいなので、リンク切れてたらコペン レンタカーとかで探してみてください

RouterOS + 楽天ひかり クロスパス で DS-Lite だけを設定する (ひかり電話なし)

前提

  • RouterOS 6.49.3
  • 楽天ひかりの IPv6 オプションが有効化済み
  • HGW の 下りポートは Routerboard の ether1 に接続
  • DS-Lite 越しの IPv4 の通信だけが可能な状態を目指す。IPoE 越しの IPv6 通信とのデュアルスタックや PPPoE との併用はターゲットにしない

主に参考にした先人たち:

手順

説明は WebFig 前提です。ごちゃごちゃ試してて、どの順番で設定を変えたらいいかは記憶が曖昧なので、動かなかったらすみません…… (ある設定値を決めるのに別の設定を投入して何かを実行しないといけない、というパスはあるけど、それ以外は基本的に順不同で、正しい設定になっていれば動くだけのはず)

  1. IPv6 > Settings
    • Accept Router Advertisements: yes
  2. IPv6 > DHCP Client > Add New
    • Interface: ether1
    • Request: prefix だけチェック
    • Pool Prefix Length: ひかり電話なしなので 64
  3. Tool > Traceroute
    • Traceroute To: 2001:4860:4860::8888 などと入力して実行する
      • これは 8.8.8.8 の IPv6 版アドレスで、internet reachable な IPv6 アドレスであればなんでもいい
    • # 0 の行 (Hop 1) の Host 列に出ているはずの IPv6 アドレスをメモる。これが ONU から RA で降ってきてるアドレスである
  4. IP > DNS
    • Servers に 2001:4860:4860::8888 とかを入れる
  5. Interfaces > Interface > Add New > IPIPv6 Tunnel
    • Local Address そのまま
    • Remote Address が dgw.xpass.jp
  6. IP > Routes > Add New
    • Dst. Address: 0.0.0.0/0
    • Gateway: ↑ で作った IPIPv6 Tunnel

一通り試行錯誤した後だと、この一文が身に沁みる感じがあって面白かった。

(※) DS-Lite は、IPIPトンネリング(IPv4 over IPv6トンネル接続)を利用して行います。この時、ルーターIPv4パケットをIPv6カプセル化し、IPv6ネットワークに設置された AFTR(Address Family Transition Router)にIPv6パケットを転送します。AFTRにて、カプセル化されたIPv4パケットをIPv6パケットから取り出し、IPマスカレードによる変換を行い、IPv4インターネットへとIPv4パケットを転送します。 — クロスパス(Xpass)接続設定例

なんか接続できてる気がするけど設定が本当に正しいか自信がない……という場合は、Routerboard の再起動をかけてみると見落としていた箇所が明らかになったりすることもあった。


これで回線がどうなったかというと、世間のピーク時間帯 (夜 19 時〜 23 時くらい) で言えばこういう感じ。

  • before (楽天ひかり PPPoE)
    • https://fast.com の結果が下り 10Mbps 以下
    • ping 8.8.8.8 とかで 50ms 前後 + パケロス率 < 10%
  • after
    • https://fast.com 下り 60Mbps 〜 100Mbps くらい
    • ping 8.8.8.8 が 5〜15ms 程度に改善、パケロス率限りなくゼロ

ものすごくマシになったとはいえ、楽天ひかりに変える前に使ってた v6 プラスは下り速度が after の 10 倍くらいは普通に出ていたので、それと比べると、、という感じはしてしまう *1……。

10Mbps の世界はそれはそれは遅いもので、大きめの JPEG 画像が上からビーッと表示されていく様子とか久しぶりに見た、という感じであった。めっちゃ関係ないけど、旅行とかもしばらくろくに行ってないので、はじめて行ったホテルの Wi-Fi でとりあえず SpeedTest を走らせて、遅かったらがっかり……みたいなムーブとも無縁の生活が続いている。

*1:別のルーターを使っていたので単純な比較はできないけど、それでも電気屋で普通に売ってるようなやつだったので、回線の違いが結果に出てるのではないか

クルマについて考えるようになって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