portal shit!

（※タイトルは ChatGPT に考えてもらいました）

Apple CarPlay はとてもよくできたサービスだと思うけど、ネットであまり使っている情報を見かけない。自分の観測範囲が狭いだけかもしれないが、デジタルガジェット好きな人が大抵東京近辺に住んでて車を運転する習慣がないからではないかと思っている。なので今日は CarPlay の便利さについて書いてみたい。

自分は 3 年前のハワイ旅行でレンタカーで使った CarPlay に衝撃を受けて車を買い換えることにした。

ハワイ旅行、レンタカー借りてうろついてるのですけどめっちゃ良い。怪しげな予約サイトとiPhoneとGoogleマップのおかげでコミュ障のおっさんでも車借りれてCarPlayのGoogleマップで目的地まで案内してもらえて便利。アカカ滝やマウナケア中腹までガイドに頼むことなく独力で行けました。 pic.twitter.com/v0MJIMqKni

— morygonzalez (@morygonzalez) February 10, 2020

いまも車の純正カーナビは使っておらず、車を運転するときは CarPlay で Apple マップか Google マップを使っている。ナビゲーションはもちろんのこと、届いたメッセージを読み上げてくれたり、音声入力で返信したり、 Hey Siri できたり、電話をかけたり受けたりできる。もちろん音楽や Podcast も聴ける。運転中に iPhone でしたいようなことが大抵できるようになってる。車に純正で付いてるカーナビだと精々 Bluetooth で iPhone につながってハンズフリー通話したり音楽を再生したりくらいしかできないが、 CarPlay を使うと車が iPhone の外付けデバイス的な感じになる。

CarPlay のなかでも Apple マップがめちゃくちゃよくできてて、例えば休みの日に 11 時からショッピングセンターで予定があったとして（カレンダーに予定と場所の情報が入れてある）、 10 時半に車に乗って iPhone を車につなぐと iPhone にプッシュ通知が来て「ショッピングセンターへのナビゲーションを開始しますか？」と表示される。ようわかっとるやんけと思いながら通知をタップするとナビゲーションが始まる。

運転をしていると交差点が近づいてきたときに Apple Watch が震えて右折しなければならないことを教えてくれる。カーナビで音声ナビゲーションさせることもできるし、音声は出さずに Apple Watch 経由でナビゲーションしてもらうこともできる。 Podcast を聞き入っていたのにナビの音声に邪魔されるということがない。

カーナビとして使うとき、Google マップじゃなくて Apple マップ使うようになってきた。 iOS との統合され具合（車に乗って繋いだ途端、カレンダーの予定の目的地に行くかと聞かれる）とか、 Apple Watch に曲がるべき交差点で通知が来たりとか便利。来年もっと進歩するっぽいけど現行版でも十分すごい

— morygonzalez (@morygonzalez) November 13, 2022

目的地に着いて駐車場に車を止めると駐車位置が Apple マップ上に反映される。ショッピングセンターの広大な駐車場で自分の車の駐車位置がわからなくなり延々さまようということがなくなる。

CarPlay で Apple マップ使うとマップ内に車の駐車位置が表示されることに気がついた。広大なショッピングセンターの駐車場で自分の車探すときに便利そう。 pic.twitter.com/nXeYkn75mu

— morygonzalez (@morygonzalez) May 5, 2021

うっかりガソリンを入れ忘れていて燃料警告灯が付いてしまった。すると iPhone にプッシュ通知が届いて「ガソリンスタンドを探しますか？」と表示される。通知をタップすると地図上で最寄りのガソリンスタンドが表示される。

CarPlay 、車の燃料残量警告灯が付いたら iPhone のマップアプリからプッシュ通知が来て「ガソリンスタンドを探しますか？」と表示された。すごすぎる。

— morygonzalez (@morygonzalez) November 13, 2022

このように Apple マップは車とつながることでハチャメチャにユーザーの状況に適した提案をしてくる。めちゃくちゃかゆいところに手が届く感じ。ガソリン切れそうになったときに通知が来たときは便利すぎて正直引いた。

フツーの車が近未来デバイスみたいになったみたいな感じになるので、 CarPlay に対応しているカーナビを搭載している車を持ってる人は今すぐ純正カーナビ使うのやめて CarPlay で Apple マップ使い始めた方がよいし、これから車を買おうとしている人はナビが CarPlay 対応しているかどうかはチェックした方がよい。車がデジタルガジェットの一部になる感覚を味わって欲しい。

普段は Vim などのテキストエディターで文章を書いていて、ブログの投稿画面にはできあがった内容をコピペするだけだったので、投稿画面の使いやすさやは気にしたことがなかった。画像のドラッグ・アンド・ドロップ・アップロードや、オン・ザ・フライでプレビューをできるようにしたが、テキスト自体の書きやすさを改善しようとはしてこなかった。

大筋はテキストエディターで書いたとしても、最後に推敲したり、推敲していて気が付いたおかしなところの修正は投稿画面で行うことが多い。やっぱり投稿画面の書きやすさは重要だ。特に長大な内容を編集しているときにテキストエリアが狭いととても使いづらい。ある程度大きさがあり、画面内に大量の文字が表示されるテキストエリアが好みだ。

Lokka が開発されていた 10 年以上前は解像度の小さいディスプレイが主流で、 Lokka の管理画面は小さいサイズのウィンドウで閲覧することを想定したテキストエリアのサイズになっている。今日の高解像度ディスプレイで見ると不便なので画面一杯にテキストエリアが広がるようにした。

iPad からも投稿しやすいように投稿画面のレイアウトも修正した。本文のテキストエリアが広がったためスクロールしないと「スラッグ」以降の入力欄にアクセスできなくなったので、ある程度横幅のあるウィンドウのときにはこれらを右側に配置するようにした。

加えて、フォームを書きかけで保存したかどうかがはっきりせず、未保存の内容があるのに保存せずページから離脱してしまうことがあったので、変更点があるときは背景色を変えてわかるようにした。これにより記入内容を保存せずページを離脱してしまい、内容が失われるという悲劇を回避できるようになった。やり方は適当に検索して出てきた Stack Overflow を参考に、ページを読み込んだ時点で JavaScript でフィールド内の要素を JSON.stringify して data attribute に格納し、その後各フィールドの input イベントを監視して変更があるかどうかをチェックしている。

class FormObserver {
  constructor() {
    this.initializeFields();
    this.observeFieldsChange();
  }

  initializeFields() {
    const fields = Array.from(document.querySelectorAll('div.field'));
    for (const field of fields) {
      const inputElement = field.querySelector('input[type="text"], textarea, input[type="datetime-local"], select option:checked');
      if (inputElement === null) {
        continue;
      }
      field.dataset.serialize = JSON.stringify(inputElement.value);
    }
  }

  observeFieldsChange() {
    const fields = Array.from(document.querySelectorAll('div.field'));
    for (const field of fields) {
      const inputElement = field.querySelector('input[type="text"], textarea, input[type="datetime-local"], select');
      if (inputElement === null) {
        continue;
      }
      inputElement.addEventListener('input', () => {
        if (field.dataset.serialize != JSON.stringify(inputElement.value)) {
          inputElement.dataset.changed = 'true';
          field.classList.add('edited');
        } else {
          inputElement.dataset.changed = 'false';
          field.classList.remove('edited');
        }
      })
    }
  }
}

input イベントを監視すると動作がもっさりするのではないかと心配したが、そんなことはないようだ。普通に使えている。

いまのところ管理画面の HTML レンダリングはサーバーサイドで Ruby で行っているが、これ以上凝ったことをやるなら React などを使って JavaScript で HTML を組み立てる方式にしていく方が効率が良さそうだ。

偶発的に puma のバージョンを上げたところ Encoding::CompatibilityError: incompatible character encodings: UTF-8 and ISO-8859-1 が多発して厳しい感じになった。

このブログでは puma は v4 系を使っていたが、調べると最近 v6 もリリースされたようで v5 系に上げてみることにした。すると忘れていたのだが puma は v5 系から daemonize する機能が削除され、デーモン化は systemd を使うべしということになっていた。プロセスのデーモン化は puma にやってもらわないと capistrano で deploy するときに面倒なので以前は v5 に上げるのを諦めて v4 を維持していたのだった。

ゴールデンメンテナンスウィーク

Mac の Homebrew のライブラリ群を久しぶりにアップデートした。 tmux と fish のバージョンを上げたら tmux が動かなくなってめっちゃ焦った。いろんなものを同時にバージョ...

portalshit.net

capistrano3-puma が systemd に対応していたのでえいやっと puma を v5 に上げて deploy してみたところ、冒頭の Encoding::CompatibilityError: incompatible character encodings: UTF-8 and ISO-8859-1 が多発してページが全く表示されなくなってしまった。

一方で管理画面やアーカイブページは表示に問題がなかった。どうもファイルの読み込みが発生するページ（このブログではキャッシュを多用していて、ファイルに書き出したキャッシュを読み込んでいる）でエラーが発生しているようだった。

自分で fork した sinatra-cache.gem でファイル読み込みする部分で encoding オプションを指定してみたりしたが問題が直らない。 Haml や Sinatra のバージョンも古いのでこれらも上げてみようかと試みたが、そうするとより盛大にエラーが出てしまう（ Haml を v6 にすると html_safe している出力もさらにエスケープされて HTML がぶっ壊れる）。

気になるのはローカル環境（ Mac ）ではこのエラーが発生しないこと。「これは環境起因では？」と思い至ってガチャガチャやってみたところ修正することができた。

Lokka では Encoding.default_external を参照しつつ String#force_encoding しているところがある。「ひょっとして Encoding.default_external の値がローカルとサーバーで異なるのでは？」試してみたところ、ローカルでは #<Encoding:UTF-8> となる Encoding.default_external の結果が、サーバーでは #<Encoding:ISO-8859-1> となっていた。

以下のブログを参考に、環境変数 RUBYOPT でエンコーディングを指定して puma を動かすことでエラーを回避できた。

WindowsでEncoding.default_externalをUTF-8にするには - すがブロ

Ruby製のツールを扱う際にデフォルトエンコーディングがUTF-8じゃなくて人生厳しい場合がある やりたかったこと 自分が使ったわけじゃないんですけど、compassを使うときにSASSファイル等はUTF-8なんだけどWindows環境でcompassを使ってビルドしようとするとデフォルトエンコーディングの違いからWindows-31Jじゃないプギャーと言わるらしい。 一般的なやり方と回避方法 当然ググったりしてみるんですけど、そうするとターミナル上でset LANG=ja_JP.UTF-8したり環境変数にLANGを登録しておけば良いと書いてある。 だがしかし、どうもRuby1.9系ではそれで…

sugamasao.hatenablog.com

systemd 経由で puma を動かすときに環境変数を設定するのは結構難しい。最初は puma が RACK_ENV=production で動かず困ったが、 systemd 用の設定ファイルで EnvironmentFile のパスを指定し、環境変数用のファイルの中で各種環境変数を定義してやる必要があった。こんな感じ。

systemd の設定ファイル

[Unit]
Description=Puma HTTP Server for portalshit (production)
After=network.target

[Service]
Type=simple

WorkingDirectory=/var/www/deploys/portalshit/current
# Support older bundler versions where file descriptors weren't kept
# See https://github.com/rubygems/rubygems/issues/3254
EnvironmentFile=/var/www/app/.config/systemd/user/portalshit_env
ExecStart=/var/www/app/.rbenv/bin/rbenv exec bundle exec --keep-file-descriptors puma -C /var/www/app/portalshit/config/puma.rb
ExecReload=/bin/kill -USR1 $MAINPID
StandardOutput=append:/var/www/deploys/portalshit/shared/log/puma_access.log
StandardError=append:/var/www/deploys/portalshit/shared/log/puma_error.log

Restart=always
RestartSec=1

SyslogIdentifier=puma

[Install]
WantedBy=default.target

環境変数の定義ファイル

RACK_ENV=production
RUBYOPT=-EUTF-8

puma v5 に移行しようとしている方の参考になれば幸いです。

サウナイキタイのサ活と Google マップのクチコミには結構乖離があることに気が付いた。自分が行ってめっちゃ気に入って、サウナイキタイでも好意的なサ活が多い佐賀の KOMOREBI の評価が Google マップでは低い。サウナにも水風呂にも入らないのに物価の安い九州（温泉に 500 円で入れる）で風呂に 1100 円払えと言われたら高すぎると感じる人もいるのだろう。しかも混んでるし。

佐賀の湯処 KOMOREBI(佐賀県佐賀市)

佐賀の湯処 KOMOREBI(佐賀市)のサウナ情報はサウナイキタイでチェック！佐賀の湯処 KOMOREBIでは90度のサウナ、14.6度の水風呂、ロウリュ、外気浴が楽しめます。サウナ好きユーザの感想・口コミ(8333件)を参考にして佐賀の湯処 KOMOREBIでサウナを楽しもう！写真、地図、料金、アクセス、駐車場情報も充実。

sauna-ikitai.com

Google マップ

★★★★☆ · スーパー銭湯

www.google.com

Google マップのクチコミはとても便利だけど、一つの施設で二つ以上の役務を果たしてる場所や客を選ぶタイプの店は評価が下がると思う。本当は自分の好みにピッタリの施設が低評価となっている可能性がある。なので評価が低いからと切り捨ててしまうのではなく、自分と似た属性の人からのクチコミを探し出して読むと実際のところの雰囲気がわかるかもしれないが、それは難易度が高すぎる。

今日のプラットフォームサービスには不幸なマッチングを回避する仕組みが必要なのだと思う。あなたはサウナ好きだからこの施設は満足できますよとか、ここは常連向けですよ的な情報が簡単にわかるようになるとか。

ただ一方でそれは Instagram で自分のようなおっさんに微エロのリール動画ばかり表示されるようなレコメンデーションとアルゴリズムによる支配がいろんなサービスに広まるということであり、それはそれで残念ではある。

インスタグラムのホームに差し込れたり検索タブでお薦めされるリール、おっぱいがボヨヨンとしてるような微エロなやつが多い。「お前は禿げで愚鈍な中年おやじだからこういうエロっぽいのが好きなんだろ？」と言われてるみたいで嫌な気持ちになる。 pic.twitter.com/YTWxm7xdj0

— morygonzalez (@morygonzalez) April 23, 2022

40代おじさんの集まりに行ったら、インスタグラムでおっぱいボヨヨンか小動物の動画ばかりおすすめされて腹が立つ、機械学習とか使ってもこんな偏見まみれのレコメンドしかできんのか、ホェースブックはよ潰れてほしい、という話で盛り上がった。

— morygonzalez (@morygonzalez) August 5, 2022

もう一つの選択肢としては、釣り SNS や登山 SNS が出来たように、レビューサイトも専門分化させていくアプローチが考えられる。自分のようなアルゴリズムやレコメンデーションにあらがいたいウェブ縄文人にはそういう進化の方が向いているかもしれない。

というようなことを思ってたら一つ前の記事に言及しつつ伊藤直也さんが似たようなことを書いていた。

最近のはしらないけどかつての2ちゃんねるとか Reddit とかは、ある程度の規模のコミュニティが、大きくなってくると自然に分割されて分散されていく構造を持っていて、これはいいなと思っていた

— naoya (@naoya_ito) January 16, 2023

2ch みたいにごちゃごちゃカテゴリーがサイドバーに並んでいるのには普通の人には難しすぎるので、釣り掲示板がツリバカメラになり、登山掲示板がヤマレコや YAMAP になったんだろう。考えてみるとサウナイキタイもサウナに特化した SNS ・情報サイトだ。

サウナイキタイに話を戻すと、サウナイキタイはローカルルール満載の町銭湯に対する評価が甘いという特徴もある。サウナイキタイでベタ褒めされてる施設（「番台のおばあちゃんが優しい」、「常連の方達とほのぼの交流」などなど）が Google マップではボロクソに書かれてたりする（「番台は意地悪ばあさんそのもの」、「彫り物を入れたヤクザや半グレの常連でサウナが占有されていて入れない」などなど）。ネガティブなことは書かないというコミュニティポリシーの影響なんだろうか（以前、サ活でドラクエ集団がいたと書いたら公式アカウントから警告された）。サウナイキタイだけ見て福岡の銭湯サウナに行ったら刺青を彫った怖い人から凄まれながら入浴しなければならないという体験をしそうだ。

レコメンデーションにしても専門分化にしても塩梅が難しい。レコメンデーションはやり過ぎるとただの偏見にしかならない（ 40 代男性はおっさん → おっさんはエロが好き → 微エロ動画見せとくか）し、専門分化して蛸壺化しすぎると一般的な感覚と離れたレビューが集まるようになってしまう（怖い人だらけの銭湯サウナが高評価）。昔のインターネットではこんなことに悩むことはなかった。

昔のインターネットは良かったとばかり言ってもどうにもならないが、インターネットを飯の種とする者の一人として人が増えたいまのインターネット特有の問題をどうにかしたい。

ソーシャルメディアやニュースサイトに毎日新しいコンテンツが次々に投稿されるので、インターネット上の総情報量は増えていっているはずだが、 20 年前と比べてアクセスできる情報の種類は減っているのではないかと感じる。いま何か情報を得ようとしたときに Google は以前ほど便利ではなくなってきている。 Google がキュレーションした情報にしかアクセスできないからだ。誰にもフィルタリングされていない生の情報にアクセスしようとしたら Twitter 検索の方がよっぼどよいと感じるくらいだ。

昨年末、 40L の登山用バックパックをニュージーランドのショップから購入した。日本でも売っていた商品だが、国内の正規取扱店では売り切れてて個人輸入で購入するしかなかった。商品名で Google 検索しても日本語のページしかヒットしないし、在庫ありとして表示される楽天や Amazon のページには怪しい業者が定価の何倍もの価格でふっかけて販売しているケースがほとんどで、 Google から直接海外のショップのページに辿り着くことができない。メーカーのウェブサイトから各国の取り扱い店をたどってようやく販売しているページを見つけてメールで問い合わせて購入することができた。

15 年くらい前、日本から patagonia.com にアクセスすると patagonia.jp にリダイレクトされて、アメリカで 10000 円くらいで売られているものが日本では 1.5 倍の 15000 円くらいになってて日本人はぼったくられている、というようなことを書いている記事がバズってた（ちなみにいまも patagonia.com を開こうとすると patagonia.jp にリダイレクトされる¹）。当時は日本人が価格差に気がつけないようにしているのは邪悪だということで攻撃されていたのはパタゴニアだけだったが、現在では Google が似たようなことをやっていて、インターネット全体でパタゴニアと同じようなことが起こっている。日本人（日本の IP アドレスから日本語設定のブラウザーを利用している人）が海外のショップから直接物を買おうと商品名で Google 検索しても、海外のサイトはほとんどヒットしない。日本人は日本語のウェブページしか見させてもらえない。

日本語のページであっても、すべてが検索結果に表示されているわけではない。何か商品について調べようと Google 検索しても結果に出てくる店は決まっていて、 20 件程度表示されたあとにそれ以降の情報を探すことができない。楽天や Amazon 内の情報のほか、 BASE や STORES 、カラーミー、 Shopify などといった割と利用者が多いカートを採用しているページは Google ショッピングの一覧に表示されるが、そうではない自前の CMS で構築されているような地方のショップのサイトなんかは結果に出てこない。

昨シーズン、ARC'TERYX の Motus AR Hoody というパーカーを買ってとても使い勝手が良かったので、今シーズンも色違いを買おうと探してみたら主要なサイトではすでに売り切れていた。一昨年も GRiPS のサイト（カラーミーで構築されている）に掲載されたタイミングでは買い逃していてネットの海をさまよって何とか辿り着いた地方のショップのサイト（メジャーなカートシステムではない独自システムのサイト）で購入することができた。まさかそんなことあるまいと思いながら今シーズンもそのサイトを訪れて探してみたところ、何とよそでは売り切れて定価の 2 倍とか 3 倍の値段で売られている Motus AR Hoody が定価で販売され在庫が残っていた。こういう例は一度や二度ではなく、何度か経験した。

インターネットに情報が増えすぎて、 Google としても検索結果に表示するページは絞るしかないのだと思う。すると Google にとってクローリングしやすく、サイトの更新を追っかけやすいサイトばかりが検索結果に表示されるようになる。サイトのレスポンスが遅かったり、構造がいまいちイケてないサイトは検索結果に出てきづらくなる。その結果、同じようなページばかりが検索結果に表示され、一部のサイトにだけトラフィックが集中して独自サイトにはアクセスが集まりづらくなってきている可能性がある（だから自分が買ったショップのページでは Motus AR Hoody のような人気商品が売れ残っていた）。

インターネットは情報の非対称性を下げて、より取引を効率化するものだと信じてきてが、どうやらそうではないようだ。一部のページにだけアテンションが集中し、むしろ情報の非対称性が高まっている。あっという間に定価で売られていた商品が売り切れてモノの値段がつり上げられ、一方でアテンションを集められないサイトでは売れ残ってセールになっている。経済学のセオリー通りなら、市場の原理が働いてギリギリに近い競争均衡価格で商品は取引されるはずだが、実際には逆の現象（正規販売店による定価販売と一部の転売業者による価格つり上げ販売）が起こっている。

EC サイトだけでなく、ブログや個人のウェブサイトでも同じような問題が起こっているのではないかと感じる。 Google のコアアルゴリズムアップデートで自分のブログも随分 Google 検索からの流入が減った。

Adsense 広告を消した

表示していた Google Adsense の広告を外した。自動広告をオンにすると本文の途中など意図しないところに広告が掲載されまくってしまって大分読みづらい。かといって記事下に入れる程度だとま...

portalshit.net

実際には存在するのに、 Google から不遇されて存在しないことになってしまっているウェブサイトがインターネット上にはきっとたくさんあるだろう。

昔のインターネットのような、検索結果をたどればたどるほど新しい情報と出会えていた頃が懐かしい

年が明けてからやるのはどうかと思うが、タイミングがなかったので今さらながら 2022 年のふりかえり。

ランニング

2022 年はよく走った。これまでも何度か走ってると書いていたが、ちゃんとグラフにしてみると 2022 年の 8 月までは大して走っておらず、 2022 年の 9 月から本腰を入れて走るようになったようだ。

オレンジ色の線が 2022 年のもので、9 月から傾きが急になっている。 9 月は月間 110km 走った。月間 100km はフルマラソンに出られる基準のようなのでこの頃は調子こいていた。

ランニングの頻度を上げるのに役立ったのが計画表だった。それまで漫然と走っていたが、漫然と走っていると月間 100km も走れないことに気がついた。自分は一回 5km 走っているが、それを気が向いたときに週 2, 3 度やるだけだと月間 50km くらいにしかならない。きちんとランニングした日と距離を確認していかないと目標には辿り着かない。ログは Apple Watch で取得しているが、統計データとしては見られない。なので HealthFit というアプリを使っているが、 HealthFit では目標設定ができないので Numbers でシートを作って管理することにした。これは元はてなのディレクターの二宮さんの記事の真似。

強い気持ち - 二宮日記

Webディレクター解体アドベントカレンダー最終日の記事です。今から4年前にも、アドベントカレンダー最終日の記事を書きました。それは、ディレクターにとって気持ちが一番大事だという、些か青臭い話です。 あれから4年、早いものですね。今読み返すとちょと恥ずかしいほどエモいこと言ってますけど、まあでも、今でもそう思ってます。やっぱり物事を前に進めるって言うのは、スキルとかテクニックとか、そういう技術だけでは補えないものがありますよね。 特にサービス開発って、絶対すんなり行かないじゃないですか。絶対途中で何かありますよね。何のハプニングもアクシデントもインシデントもない大規模プロジェクト、今まで1つでも…

ninomiyateppei.com

こちらが年間の週次のランニング計画。

こちらが月間の日次のランニング計画。

月間のシートに日次の目標と実績値を入れると、年間の週次のシートに自動反映される仕組みになってる。これによって自分は一週間に何 km 走る予定で現在目標に対してどのくらい達成しているのかを確認できるようになる。

37signals の本を読んで、計画を立てるのはアホだ、数値目標なんて意味がない、未来を先読みすることはできない、という発想に影響されて計画を立てたりするのは何となく良い印象を持っていなかったけど、月間何キロくらい走りたいとか、ベンチマークとなる具体的な数値目標がないとなかなか実績は積み上がっていかないと思う。もちろんまだ走ったことがない状態でいきなり月間 100km のような目標を立てるのは愚かだと思うが、そこそこ走れるようになってきたら（自分の力がわかるようになってきたら）計画を立てたり数値目標を設定したりするのは悪くないことだと思う。

9 月にがむしゃらに走ったおかげか、最近は走るペースが一段速くなっていて、 1km を 5 分台で走れるようになってきた。今年はちょっと色気を出して初心者向けのトレランの大会に出てみようかと思ってる。

登山

4 月に脊振山系全山縦走、 11 月に九州脊梁に行った。夏に北アルプスを予定していたが、ちょうどコロナにかかって行くことができなかった。何にせよ最近は山に登るのよりも近所を走る方が楽しいので山への足が遠のいた一年だった。登山時の体力作りで走り始めたのに本末転倒している。

仕事

一昨年は結構でかい成果を出せたが 2022 年はぱっとしない一年だった。反省したい。

生活

iPhone を買い換えて 11 から 14 Pro になった。カメラが三つになって望遠の写真を撮れるようになったのが便利。 Dynamic Island も便利。タイマーかけてるときに常に Dynamic Island で残り時間を確認できるのは相当便利。 164800 円払ってよかった（ 36 回ローン）。

サウナにハマってぼちぼち行っていた。サウナーの人たちのように一週間に何回も通うというほどではないが、金曜日の仕事帰りにサウナまで走って行ってサウナに入って帰るというのを何回かやった。花金感が出て良い。

2020 年に車を買い換えたがあまりドライブしてない。アメ車なので燃費が悪い、コロナなので出かけづらい、などいろいろあるが、せっかく車を買い換えたのに使わないで置物になってるのはもったいないので有効活用したい。

そういえば 2022 年は YouTube をよく見た。 YouTube Premium に入ったので広告が表示されなくなり、邪魔が入ることなくとてもなめらかに動画を視聴できるようになった。 Netflix はあまり見ていなかったので解約し、 YouTube で素人が上げる動画をよく見た。ストーリーのない、ただ料理をしているだけとか、ただ穴蔵を掘っているだけの 15 分くらいの動画を見るのがちょうどよい。 Netflix の動画は長いし、ことあるごとに金、暴力、セックスを意識させられるので見るのがきつい。こってりしすぎている。

ブログ

Tantivy を導入して全文検索できるようにした。検索も見た目を変えてインクリメンタルサーチできるようにしたりした。年に一回くらいはバズる記事を書きたいが、 2022 年は不作だった。反省したい。

総括

仕事や生活、ブログは本当にぱっとしなかった。その代わり走ることを頑張っているのかも知れない。ランニングや登山は、大して頑張って生きていないのに走ったり山に登ったりするとめっちゃ頑張ってるかのような錯覚を得られて自己肯定感が高まる。仕事などでもちゃんと成果を出しつつ走ったりできたら良いのだけど自分の場合は逃避になってるような気がする。しかし走るのをやめたら仕事で成果を出せるかというとそうでもないし、遺伝的に糖尿病のリスクがあるので発症しないように死ぬまで走り続けるしかない。 2023 年は運動しつつ仕事やブログ書きでも一定の成果を上げたい。あともうちょいサウナに行きたい

watchOS 9 と iOS 16 が出て2ヶ月程度使った。だいぶ生活に馴染んできたので感想を書く。

watchOS 9

ワークアウトのカスタマイズ

watchOS 9 でワークアウトがとても良くなった。ランニングワークアウトのカスタマイズができるようになったのがよい。これまではフリーのほか距離走やペース走くらいしか選べなかったが、 watchOS 9 からインターバル走のような、ランニング中の行程をあらかじめ設定できるようになった。

心肺能力を鍛えるにはインターバル走が有効と言われている。例えば 400m を 7 ~ 8 割程度の力で走ってそのあとの 400m をジョグで休む、を繰り返すような走り方だ。とはいえちゃんとした整備された運動場を使えるわけではない一般人がそれをやるのは難しい。距離を測れないからだ。しかし watchOS 9 のランニングカスタマイズ機能により、インターバルの通知をしてくれるようになった。予め自分で 400m のインターバルを 4 回繰り返すと設定しておけば、 400m 走った（ワーク）あとに 400m ジョグする（回復）ように通知で教えてくれて、回復の 400m が終わればまたワークの開始地点をお知らせしてくれる。走ってる最中もあと何メートルワークなのか、回復なのかがわかる。とても便利だ。

インターバル走の前後にウォーミングアップやクールダウンの区間を設定することもできる。大抵走るときは家を出て 1km くらいはゆっくり走ってウォーミングアップ的な走り方をしている（家を出た瞬間インターバル走をしたら死んでしまう）。この区間をウォーミングアップ行程（走り始めの 1200m に設定してる）として設定し、インターバル走 ( 400m ワーク + 400m 回復 ) × 4 走ったあと 600m クールダウンして 5km というような走り方をしている。

watchOS 9 をインストールしてから週 1, 2 回くらいインターバル走をするようになったが、おかげでコロナにかかったあと平均以下になってしまっていた VO₂max が平均より上に戻った。

ワークアウトのカスタマイズについてより詳しくは Apple の以下のページを参照。

Apple Watchユーザガイド - Apple サポート (日本)

Apple WatchおよびiPhoneのApple Watchアプリについて知っておく必要のあることは、Appleが作成したこのガイドにすべて書かれています。この最も信頼できるガイドは、Apple Watchを使い始めるときの手助けとなり、Apple Watchに搭載された数々のすばらしい機能を知るために役立ちます。

support.apple.com

心拍数範囲

ランニング中に心拍数範囲を確認できる機能も便利だ。走っている最中、いまのペースが有酸素運動なのか、無酸素運動なのか、それとも限界近くの高負荷状態なのかがぱっと見でわかりやすくなった（色で確認できる）。

減量したい人は有酸素運動をする必要があるので、ペースを上げすぎて無酸素運動にならないようにしないといけないが、心拍数を数字で見せられてもそれが自分にとっての有酸素運動なのか無酸素運動なのかはわからない（どの心拍数から無酸素運動になるかは人それぞれで異なる）。心拍数の範囲表示は普段のヘルスケアデータから範囲を計算して目安を表示してくれるのでとても簡単に使える。注意点としては有酸素運動とも無酸素運動とも書かれず 範囲3 とか 範囲4 のような表示になっているのでこういうのに興味がない人はどの範囲の割合が増えれば良いかわからないかもしれない。色が黄緑になる範囲3が減量したい人には最適ゾーンだということを教える仕組みがあっても良いかなとは思った。 Withings の Health Mate アプリは目標体重を聞いてきたりするが、 Apple Watch のワークアウトも何のために運動したいのか（目標）を聞いてもよいかも。

Apple Watchユーザガイド - Apple サポート (日本)

Apple WatchおよびiPhoneのApple Watchアプリについて知っておく必要のあることは、Appleが作成したこのガイドにすべて書かれています。この最も信頼できるガイドは、Apple Watchを使い始めるときの手助けとなり、Apple Watchに搭載された数々のすばらしい機能を知るために役立ちます。

support.apple.com

ランニングの詳細な分析

ランニングパワー、上下動、接地時間、歩幅がわかるようになった。 watchOS 8 ではケイデンス（ 1 分間にどれだけ足を動かしているか）しかわからなかった。上下動と接地時間はなかなか参考になるデータで、上下動を減らせればそれだけ効率的に力を前に進むことに使えているということになるし、接地時間が短ければそれだけ速く足を回転できているということで、ケイデンスの改善につながる。足を速く動かす（ケイデンスを上げること）を意識して走ったら自然と上下動が減り（ 10cm → 8.6cm くらい）、接地時間が短くなった（ 280ms → 250ms くらい）。しかもそんなに飛ばした感じはしないのにタイムもまぁまぁ良かった。自分はこれまで無駄にエネルギーを使っていたんだなということがデータで示されてなるほど感がある。フォームを改善するメリットが体感できてめっちゃ便利。

iOS 16

ワークアウト

ワークアウトの詳細を確認しやすくなった。以前書いた HealthFit についての記事で、標準のワークアウトでは心拍数の分布を確認できないのが不便だと書いていたが解消された。

watchOS 9 で取得できるようになったランニング時のパワーや上下動、設置時間などを GPS の軌跡上でなぞりながら確認することもできる。詳細な分析データを見たければ外部アプリを使わなければならなかったのが、そこまで凝らない人であれば純正のワークアウトアプリだけで足りるだろう。

ただし最近 HealthFit には Similar Workouts という機能が追加されて、同じコースの過去の記録と比較できるような機能が追加されてパワーアップしている。これが 1000 円くらいの買い切りで使えるのはめっちゃ便利なので引き続き HealthFit はおすすめです。

‎HealthFit

‎If you love working out with Apple Watch, but you need more advanced fitness stats, HealthFit is for you. By analyzing the workout data stored in Apple Health, HealthFit provides the kind of indispensable tracking and insights you normally only get from premium subscription services. But if you sti…

apps.apple.com

Apple も純正で「レースコース」なる機能を年内にリリースすると予告されているが、今年も残り 4 週間を切っており本当に年内に出るのかは謎。

服薬

ヘルスケアアプリ内の服薬機能がめっちゃ便利。 10 月下旬ごろから 11 月中旬まで謎の体調不良に陥ってしまい、解熱剤などの薬を飲んだが、どの薬を何時に飲んだかを記録できてめっちゃ便利だった。「そろそろ薬の時間ですよ」とお知らせしてくれる機能もある。もう紙のお薬手帳いらないのでヘルスケアアプリ内の服薬機能に統合されて欲しい。一度薬局ですすめられたダウンロードしたお薬手帳アプリは登録しても系列の薬局でしか使えない微妙なアプリだった。

結論

iOS 16 も watch OS 9 もめっちゃ良くなっているのでまだアップデートしていない人は早くアップデートした方が良いと思う。特に Apple Watch を使って運動している人はめっちゃおすすめ。 iPhone と Apple Watch の統合され具合も素晴らしい。 iPhone 使ってる人は Apple Watch も使わないとその便利さの 75% くらいしか享受できていないのではないかと思う。 Apple Watch まで導入することで 100% iOS の恩恵に浴することができるのではないかと思う。もうちょい Apple Watch が安くなって普通の人も買いやすくなると良いんだけど。