| @登山/ランニング

Apple Watch でトレランするならフットパスが便利

Apple Watch でトレラン(ランニング)する人のための記事を以前書いた。アプリを組み合わせれば Apple Watch が Garmin 相当になるという記事だった。

その記事ではトレラン中の地図&アクティビティトラッカーとしては WorkOutdoors が良いと書いていたが、フットパスというアプリを発見してしまってこっちの方が地図が見やすく操作も簡単で高機能だった。 Apple Watch でトレランするならフットパスが激しくおすすめだ。

フットパスは、スマートフォンのアプリを開いて指先で地図上をなぞるといい感じにルート(ウォーキング、ランニング、ハイキング、サイクリング、ドライブなどに対応)を提案してくれるというのがウリだが、正直この機能は日本の道路では使いづらい。きちんと区画整理されている欧米の街だったら使いやすいかもしれないが、ぐねぐね細い道が入り組んだ日本の道路では「そこじゃないんだよな」というルートが提案されることがある。

指なぞりルート作成機能はいまいちなのだが、自分が感心したのは以下だ。

  1. ゴール時刻の予想タイムを出してくれる(フットパス上で計画したルートだけでなく、 GPX を取り込んでも表示してくれる)
  2. 行動中の Turn-by-turn navigation (もうすぐ右ですとか、分岐を直進とか教えてくれる)
  3. Mapbox Outdoor Style の地図のほか、国土地理院地図を選ぶこともできる(国産アプリ以外ではめずらしい)
  4. 行動中に登りが残り何メートルあるか確認できる機能(地形を視覚的に確認できる)
  5. ウェブサイト footpathapp.com の使い勝手

ゴールタイム予測

Footpath App
何時頃ゴール地点に着くかを予測してくれる。

何時頃ゴール地点に着くかを予測してくれる。モーダルウィンドウ内の太字部分(「 15'00"/km 」と書いてあるところ)を左右に短くスワイプするとペースを変更出来て、任意のペースで何時間でゴールできるか確認することができる。

登山用の計画アプリだと「何月何日の何時に登山開始」みたいに日時を入れないと予想時間が表示されないが、これだと日時を指定することなく「いまスタートしたら何時頃下山できるか」がぱっとわかる。

スマートフォンアプリ側で計画を調整して Apple Watch に転送して開始すると、活動中は現在のペースだと何時頃ゴールできるかをリアルタイムで推測してくれる。

ゴールタイム予測

Turn-by-turn navigation

Turn-by-turn navigation

地図を表示しながらの Turn-by-turn navigation

いわゆるカーナビのような機能。 Garmin の Forerunner 9XX シリーズに付いてる機能を Apple Watch で利用できるようになる。 WorkOutdoors ではナビゲーション機能はなく、ルートを外れたときと復帰したときにアラートがなる仕組みだった。正直なところトレイルでカーナビのような機能はいらないのではと思っていたが、実際に使ってみるととても便利だった。ルートを間違ったことを事後的に教えてもらっても便利だが、なるべくならルートを間違うこと自体を予防したい。もうすぐ分岐があることを事前に教えてもらえると、分岐にさしかかったときに注意するのでテキトーに走って間違ったルートに進むということがない。

標高断面図

標高断面図 全体

標高断面図 部分

これからどれくらいの登りが控えているのかを確認できる。これがめっちゃ便利。予定しているコース全体で見ることもできるし、直近のセクションに拡大して確認することも可能。予定している累積獲得標高のうちすでに何メートル登ったか、残りは何メートル登るのかが一目でわかる。これは登山を始めた当初から欲しい情報だったのでスーパー便利だ。

パソコン向けウェブサイト

footpathapp.com

パソコン向けのウェブサイトがまたよくできていて、ルートに任意のポイントを設置することが可能。前回トレランのレースに出たときはエイドステーションにマーキングしておいて関門時刻を書いておいた。こうすることでエイドまであと何キロメートルかがわかり、精神的に楽だった。

もちろんウェブサイトでルートを作成、編集することもできるし、 GPX ファイルを取り込むこともできる。

注意点

自分が知る限り、 Apple Watch でトレランするならフットパスが最高なのだが注意点がいくつかある。

1. 日本語訳が良くない

「他のワークアプリで使用する」というトグルスイッチを有効にしたら、ログが自動的にワークアウトに追加されなかった。この項目の意味はフットパスを地図アプリとしてのみ使い、ワークアウトのログは純正アプリで取るケースを想定していそうだが、この日本語では意味がわからない。

2. GPX インポートしたとき、本来通りたいところではないところにルートが引かれる

地図アプリの定番 SDK に Mapbox というものがある。フットパスも Mapbox をベースにしているが、 Mapbox も独自のルート情報を持っているようで、 GPX ファイルを取り込んだときに勝手にルートが Mapbox 上のルートに置き換えられてしまう。 Mapbox 上のルートは間違っていたり、現在使われていないところが残っていたりするのでちょっとやっかいだ。

3. Apple Watch Ultra でないとナビゲーション通知が事前に届かない

Apple Watch Ultra であればちゃんと分岐の前で通知が来るので便利なのだが、 Series 6 だと通過後に通知が来ることがあった。

4. UI がもっさりしている

デジタルクラウンを回すことで距離モード、ペースモード、標高モードを切り替えられるが、この切り替えがスムーズに行かずストレスを感じる。

5. ランニング向けの情報が不足

純正のワークアウトアプリであれば、ランニング中に心拍数ゾーンを確認できたり、ケイデンスや上下動を確認できたり、任意の地点でセグメンテーションしたりすることもできるが、フットパスにはそれらの機能がない。フットパスは地図アプリとして使い、ログは純正ワークアウトアプリで取れということかもしれないが、それだと GPS を使うアプリを同時起動することになって電池の持ちが悪くなりそうだ。

6. サブスクリプションに登録する必要がある

年額 2600 円のサブスクリプションに入らないと機能が使えない。自分は全然払う価値があると思うが、サブスクリプションに抵抗がある人は買い切り 1200 円の WorkOutdoors をどうぞ。

まとめ

いくつか注意点がありはするものの、フットパスに出会ってから山を走るのが快適になった。トレランのレースに出るとまわりは Garmin や Polar 、 Sunto などを使っている人ばかりで、「やっぱり Apple Watch で山を走るのはダメなのかな?」と不安になっていたが、いまは全く不安を感じなくなった。

電池持ちのよい Apple Watch Ultra とフットパスがあれば、日常生活では Apple Watch の便利な機能(タッチレス決済、 iPhone や Mac のロック解除、音を鳴らして iPhone を探す、 Apple Music で音楽を聞く)を享受しつつ、ルートを確認しながら安全に山を走ることができる。めっちゃおすすめです。

Footpath app

| @ブログ

嘉穂アルプス 屏山

最近結構走ってるから iOS のフィットネスアプリとか HealthFit でめっちゃログや統計を確認してる。

前月との比較 直近 12 ヶ月間の月ごとの走行距離 日毎の積み上げの前年比
前月との比較、直近 12 ヶ月間の月ごとの走行距離、日毎の積み上げの前年比

いま自分は月間 100km 以上走ることを目標にしている。月間 100km はガチラン勢からしたら大した距離ではないのだが、油断して 3, 4 日走るのをサボったり雨が降ったりすると達成が難しくなるので、前月の同日と比べて進捗はどうかを確認してる。

同じような感じで進捗や達成状況を確認できる機能がブログにも必要なのではないかと思って、自分のブログのアーカイブページで年を選ぶとその年の月ごとの投稿数をグラフで表示するようにした(これまでは年で絞っても年ごとのグラフしか表示されてなかった)。

これで去年の同月に比べてどうかとか、その時期にどんな内容(カテゴリー)の記事をよく書いていたのかがわかるようになった。ランニングと同じように自分の頑張り状況が可視化されるようになった。


そもそもブログを書くことの意義とは何だろうか。大まかに二つあって、以下のように整理されるのではないかと思う。

  1. バズる記事を書いてアクセスを集める
    • 集めたアクセスで自分の認知度を高める
    • 集めたアクセスをマネタイズする(広告)
    • 世の中を変える
  2. 自分の内省のために書く
    • 読書や学習で得た知識を貯めておく
    • 考えを整理する

1 の観点でいうとアクセス数が重要なのだが、いまどきブログで小銭を稼ごうとか世界を変えようとかしてる人はいないはずで、ほとんどのブログは著者自身のために書かれてる(↑の 2 の方)と思う。自分のために文章を書きたい人にとって、書いた内容と密度や頻度、また過去に書いた記事を簡単に振り返ることができることの方が重要なはずだ。

なのに、たいていのブログサービスはアクセス解析機能はあるが、過去の自分の執筆状況を統計的に確認できる機能はない(少なくとも ameblo とはてなブログと livedoor Blog にはなかった)。アクセス数は Twitter で影響力のある人にシェアされたとか外部要因で増えることもあるから、それだけで自分のブログアクティビティを正確に測るのは難しい。

同じような話を以前にもブログに書いている。

振り返りの観点でも既存のブログはあまり良くない。たいていのブログはそもそも自分で書いた過去記事を読むのも大変だったりする。時系列に全文表示されてページネーションして辿らないといけない。

検索機能もいまいちだ。自分の考えたことを貯めておく場としてはちょっと貧相すぎる。

世の中に一般的に出回ってるブログは著者自身のためというより、いかにアクセスを集めて広告でマネタイズするかに主眼が置かれているから、内省や情報の取り出しやすさはあまり考慮されていないのだろう。いかに PV を上げるか、いかに滞在時間を長くするか、いかに回遊させるかが大事になってくる。

しかし先ほども書いた通り、芸能人や著名人を除き、ブログは自分のために書いている人が多いはずで、アクセス数を集めることよりも書き手の体験にフォーカスしたブログがあってもよいのではないだろうか。

ランニングはアプリを使ってログを取ることでいろんなデータが可視化されめっちゃモチベーションが上がる。「今月 100km 走っちゃった〜」とか、「 1km のペースが 6 分切れるようになってきた〜」とか。前年同月との進捗比較も面白い。

ブログでも「今月は 10 記事書けた〜」とか「 1000 文字以上の記事を 5 記事書いた〜」みたいな達成感はあるんじゃないかと思う。つまり、 GitHub の Contribution グラフのブログ版みたいなやつが必要だと思うのだ。

GitHub Contributions Graph

ランニングだと時計だったり Strava などのサービスが走るモチベーションを喚起してくる。一方でブログは誰も書くのを促してくれない。

ブログを書く人が少なくなったのは SNS のせいという面は間違いなくあるけど、ブログ自体の進化が足りないのだと思う。もっと書き手の脳みそをハックして、著者に書きたいと思わせるような仕組みがないとブログは衰退していくばかりなんじゃないだろうか。

突き詰めると、ブログの主なマネタイズ手法が広告しかないのが根っこの問題な気がする。読み手に広告を見せることで収益化するのではなく、書き手の使い勝手や満足度を高めることで収益化できる可能性(書き手に対して機能課金する)はないのだろうか。ランニング系のサービスやアプリは実際そうやって収益化してる(うまく行っているかはわからない)。

| @登山/ランニング

Apple Watch でトレイルランニングするためのアプリ

Apple Watch トレラン のようなキーワードで検索すると、「 Apple Watch はトレランでは使えない」、「ランニングウォッチとしては微妙」というようなレビューが見つかる。自分もそうだと思ってたんだけど、それらのレビューは純正のワークアウトアプリか Strava アプリ、 NIKE のアプリくらいしか試してないようだった。果たして本当に Apple Watch はトレイルランニングで使えないのだろうか?

※この記事で紹介しているアプリよりももっと良いアプリを見つけたので以下の記事も是非読んでみて下さい。

Garmin などランニング特化の時計でできること

Twitter を見てると Garmin の時計を付けてランニングをしてる人たちがその日のトレーニングの様子とか体調をキャプチャで載せてる様子が観測できる。

どうも Garmin だと心拍数と睡眠時間などから「今日は体調良くないですよ」(トレーニングレディネス)とか、今日の運動メニュー(おすすめワークアウト)とか、フルマラソンなどのレースの予想タイム(レースウィジェット)を教えてくれるっぽい。

Apple Watch にも Apple 純正のアクティビティトラッカー(ワークアウトアプリ)あるし、心拍数を計測する機能も睡眠トラッキング機能もあるけど、その日のトレーニングがどうだったのか、体調がどうなのか(その数字が何を意味するのか)は自分で解釈・判断しないといけない。

加えて Garmin の上位機種( Forerunner 955 など)では地図とルート表示およびナビゲーションが可能で、山の中でスマートフォンや紙地図を取り出すことなく予定のルートと地図を確認できるようだ。つまり

  1. オフライン地図表示&ナビゲーション
  2. 運動回復支援機能

↑の二つが Apple Watch にはない機能で、 Garmin 勢うらやましいなぁと思っていたが、いろいろ調べてみると以下の二つのアプリを入れることで Apple Watch を Garmin 相当にすることができるようだった。

  1. WorkOutDoors
  2. Athlytic

オフライン地図表示&ナビゲーションアプリ WorkOutDoors

WorkOutDoors

Apple Watch には Apple 純正のワークアウトアプリがあって、普段走るときはこれを使っているが、メトリクスを計測するのみで地図でのナビゲーション機能はない。レースコースという、過去の自分のルート・記録と比較しつつ走れる機能はあるが、同じルートを何回か走ってからでないとレースコースとしてワークアウトに表示されない。

しかしルートを表示する機能は初めて行く山域や知らない場所を走るときにこそ必要で、 WorkOutDoors はそれを実現するアプリだ。ワークアウトアプリにはできない、任意の GPX ファイルを読み込ませてルート表示することができ、特定の範囲の地図をダウンロードしてオフライン表示することも可能だ。

しかも純正のワークアプリと同等のアクティビティログの取得も可能で、きちんとランニングのデータが保存される。 GPS ログや心拍数に加え、 watchOS 9 から取得できるようになったランニングパワーや上下動もちゃんと記録される。

実を言うと最初自分はこのアプリを iPhone で GPX ファイルを閲覧するためにインストールしていたが、あまり便利ではなく(使い方が難しかった)すぐ使わなくなっていた。しかし改めて Apple Watch でアクティビティトラッカー件ルートナビゲーションアプリとして使えることを知ってまさにこういうのが欲しかったということに気が付いた。ルートを外れたときの警告機能もあるし、心拍数などのメトリクスを Apple Watch で計測しながら道がわからないところを走るならこれ一択という感じがする(土地勘があるところなら Apple のワークアウトアプリの方がシンプルで使いやすい)。

WorkOutDoors はハチャメチャふにカスタマイズ可能

さらにこのアプリがすごいのがめちゃくちゃ細かくカスタマイズできるところで、画面表示やレイアウトだけでなく、画面を複数回タップしたときの挙動までカスタムできる。自分はソフトウェア開発者なのでこういう複雑な UI には強い方だと思うけど、これは普通の人には使いこなせない複雑さだと思う。しかしランニング意欲と IT リテラシーの両方が高い人からするとめっちゃうれしい使い勝手の良さを備えている。

watchOS 9 でワークアウトアプリがだいぶ進化して、ランニング中に表示するメトリクスの内容を自分でカスタマイズできるようになったが、いまにして思うとこのような機能は WorkOutDoors アプリでは以前から搭載されていたようで、ワークアウトアプリは WorkOutDoors の後追いをしているとも言える。純正ワークアウトアプリの方がデザインが洗練されていて使いやすいが、少々込み入った作業が必要でも自分に本当に必要なデータ(ペース、心拍数、累積獲得標高などなど)を厳選したい人にはうってつけだ。

WorkOutDoors は有料ソフトだがサブスクリプションではなく一回だけの買い切りで値段も安く良心的( 1100 円)。トレランでも Apple Watch を使いたい人にはおすすめです。

運動回復支援アプリ Athlytic

Athlytic

Garmin の時計でいうところのトレーニングレディネスとおすすめワークアウト機能のようなものを提供してくれるのが Athlytic だ。

Apple 純正のヘルスケアアプリで睡眠時間や安静時心拍数などを知ることができるが、どう理解すれば良いかがわからない。昨日の睡眠時間は 6 時間で、そのうちレム睡眠が〇時間です、なんて言われてもそれが良いのか悪いのかがわからない。

Athlytic は睡眠の状況と心拍数からその日の体調をはじき出し、今日は休んだ方がよいとか、激しいトレーニングしてもオッケーとか教えてくれる。

Athlytic Athlytic Athlytic

このブログでたびたび話題にしている HealthFit というアプリでも回復具合を表示してくれるが、睡眠時間や安静時心拍数からではなく、トレーニングをしているかしていないかで判定している。元の TSB モデルというもの自体がそういうものなので仕方がないが、トレーニングしてないから体調が良いかというとそうでもなくて、あまりよく眠れてなくて体が重いこともあるので、 Athlytic のようなアプリが欲しいと思っていた。本当はあんまり体調良くないときに張りきって高負荷のトレーニングをして怪我したら最悪だ。 Athlytic を使うことで客観的に自分の体調を把握できるようになる。

なお買い切りの WorkOutDoors と異なり Athlytic は年間 3400 円のサブスクリプションだ。調べたところ同種のアプリはほかにもあって、値段が安いものや無料のもののあるが、 iPhone 側にはほとんど UI がなくて Apple Watch で情報を見なければならなかったり( Training Today )、体調の判定だけでおすすめのワークアウトを教えてくれる機能はなかったり( CHIPR )するので、少々出費は必要だが Athlytic を使うのが良さそうだ。

でも Apple Watch はバッテリーもたないですよね?

バッテリーに関してはやっぱり Garmin に負けてしまう。自分の 2 年半使った Apple Watch Series 6 はワークアウトを動かすと 6 時間くらいで電池が切れてしまうので、登山やトレランで Apple Watch を使う場合は Ultra を買うしかないだろう。また Apple Watch Ultra であったとしても二日に一回は充電が必要なのは避けられない。

しかしトレランの 100 マイルレースで Apple Watch Ultra を使って完走したという情報もあるので、 Apple Watch Ultra で節電モードをうまく使えばウルトラマラソンや 100 マイルレースでも Apple Watch Ultra は使えそうだ。

これまで泊まりの登山や 100km 、 100 マイルのトレランレースでは Apple Watch は候補に入ってこなかったと思うが、 Ultra によって 20 時間以上のワークアウトを記録できるようになったので、ランニングのときのためだけに Garmin を使う必要がなくなったとも言える。 WorkOutDoors や Athlytics のようなアプリが本領発揮できるような環境が Apple Watch Ultra によって整ったということだ。

おとなしく Garmin 使えばよくない? 何で Apple Watch にこだわるの?

この動画見てください。

Garmin は長時間のアクティビティには確かに向いてるかもだけど、日常生活が厳しい…。アメリカですら Garmin Pay は使い勝手が良くないと言われているのに日本だったらもっと使えないですよ。音楽を聞くのだって Amazon Music と Spotify しか対応してなくて事前に楽曲をダウンロードしておく必要があって不便。

一方で Apple Watch は日常の使い勝手はとてもよく、 Apple Pay でコンビニやスーパーで買い物できるのはもちろんのこと、 Mac のスクリーンロックを解除したり、 Siri で Apple TV を操作したり、運転中には Apple マップのナビゲーション通知を受け取ったりできる。最近の車だと Apple Watch が車の鍵になったりもするようだ。

運動好きだけどデジタルガジェットも好きで、 Apple エコシステムの提案する快適な生活を捨てがたいという人は Apple Watch を使うしかないでしょう。金持ちだったらランニング用に Garmin を買うこともできるだろうけど、トレーニングレディネス(睡眠や日常の心拍数変動から算出)のことを考えるとトレーニング中もそうじゃないときも同じ時計を使っていることに意味があるので、日常は Apple Watch 、走るときは Garmin という使い分けはあんまり意味がない。同じものをずっと身に付けていた方がよい。

まとめ

WorkOutDoors と Athlytic というアプリを使うことで Garmin のような機能が手に入る。これまで日常生活での快適さを諦めて Garmin 使ってた人も Apple Watch Ultra に乗り換えて WorkOutDoors と Athlytic をインストールすれば Garmin を使ってた頃と近しい感じでトレーニングできる。

様々なアプリが App Store にあって自分好みのアプリを探してインストールすることができるのが iOS / watchOS の強みなので、純正のワークアウトアプリだけ使って「 Apple Watch はトレランでは使えない」という評価を下すのは早計だと思う。適したアプリを探して入れてやれば Apple Watch はトレランでも使えます。 40km くらいまでの短いレースであれば普通の Apple Watch でもバッテリー切れにはならないはず。活動時間が 6 時間を超えてくるような距離( 50km 以上?)のレースでは Apple Watch Ultra が無難でしょう。

なお、このゴールデンウィーク期間中、 Amazon で Apple Watch Ultra がタイムセール対象になっているようだ(人気のないバンドカラー、サイズのみ)。自分も正直買おうか悩んでいてここ 4 日くらいカートに入れたり出したりを繰り返している。よろしければご検討ください。

| @Mac/iPhone

ossan.fm playing in Castro, a CarPlay podcast client

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

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

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

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

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

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

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

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

このように 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 を維持していたのだった。

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 を動かすことでエラーを回避できた。

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 に移行しようとしている方の参考になれば幸いです。

| @WWW

博多駅前

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

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

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

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

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

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

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

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

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

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