portal shit!

9 月頃、 Pebble Time Round 追悼のような記事を書いた。

Pebble Time Round の思い出

誕生日にもらったPebble Time Roundを愛用してきた経緯を振り返る。革ベルトの臭いや充電端子のサビに悩み、ナイロンベルトに替えて改善。Pebbleの買収とソフト更新停止の不安を抱えつ...

portalshit.net

この記事を書いた後くらいから Pebble Time Round の調子が悪くなり、 Apple Watch に買い換えた。

Pebble Time Round 、購入後半年くらいから充電されづらい問題はあったが、これまでだましだまし使ってきた。今年の秋頃から充電したのにバッテリー切れで死んだり、充電に異常に時間がかかるような症状（ 8 時間使って 16 時間充電する感じ）が出るようになり、ある日一切充電されなくなってしまった。もうこれは寿命かなと思って 10 月に嫁さんに黙って Apple Watch を買った。しばらくはばれずに過ごしていたけど、風呂に入っているときに洗濯機の上に置いていたところを発見されはちゃめちゃに怒られた。

Apple Watch でどう便利になったか

Pebble に比べ Apple Watch はよくできている。生活が便利になったところをまとめていく。

生活の利便性向上

通知の受け取り

Pebble は iPhone に通知が来たとき、 iPhone を操作中かどうかに関係なく一律にプッシュ通知を飛ばしてきて鬱陶しかった。 Apple Watch はそんなことなくて、 iPhone を使っている状態であればブルブル震えたりしない。プッシュ通知のプレビューも便利で、画像付きのプッシュ通知は画像を見ることができるのが便利だ。 iPhone との連携がとてもよくできている。

Apple Watch の通知 - Apple サポート (日本)

Apple Watch に通知が届くタイミングや通知方法をカスタマイズできます。

support.apple.com

Mac のロック解除

会社から貸してもらってる MacBook Pro はこれまで Touch ID でロック解除していたけど、 Apple Watch でロック解除できるようになった。 Apple Watch がロック解除済み（パスコードを入れて手首に装着済みの状態）であれば自動的にロック解除されるというものだ。 Touch Bar に指を伸ばすより Mac の前に座るだけで自動的にロック解除される方がはるかに便利だ。加えて、 Touch ID が付いていない私物の iMac もパスワードを入力することなくロック解除されるようになった。超便利だ。

Apple WatchでMacのロックを解除する - Apple サポート (日本)

Apple Watchを身に着けていれば、近付くだけでMacが察知し、自動的にログインできます。また、管理者パスワードの入力が必要なほかのリクエストも、Apple Watchで承認できます。 

support.apple.com

最近、 1Password が Apple Watch で認証する機能をリリースした。 Mac のロックを Apple Watch で解除できるなら 1Password の認証もできたら便利と思っていたが、 Big Sur になるまで Apple がこの API をサードパーティーには提供していなかった模様。それが Big Sur で開放されて、 1Password のロック解除を Apple Watch でできるようになった。ただし、 T1, T2 チップを搭載した Mac でのみこの機能は有効で、私物の iMac は 2017 年モデルで iMac が T2 チップを搭載するようになったのは 2020 年モデルからなので残念ながら 1Password の認証はパスワードの入力が必要だ。 T1, T2 チップ入りの Mac と Apple Watch を持っていて 1Password を使っている人は是非お試し下さい。

Use your Apple Watch to unlock 1Password on your Mac | 1Password Support

Learn how to set up and use Apple Watch to unlock 1Password on your Mac.

support.1password.com

マスクつけたままパスコードなしで Apple Pay

Apple Pay も便利になった。これまで iPhone の Apple Pay で支払っていたけどマスク時代になって Face ID でロック解除できずパスコードを入れるのが非常にわずらわしかった。いまは Apple Watch で Apple Pay を使えるようになったのでコンビニでマスクを外すことなく簡単に支払いを済ませられる。

Apple WatchでApple Payを使って非接触型決済を行う - Apple サポート (日本)

Apple Watchを使ってお店やアプリ内で買い物をします。

support.apple.com

家の中で行方不明になった iPhone の捜索

Pebble にもペアリングしているスマートフォン側で音を鳴らすソフトはあったが、誰が作ってるのかよく分からない得体の知れないソフトを購入してインストールする必要があって尻込みしていた。 Apple Watch には標準で iPhone 側の音を鳴らす機能が付いている。 Find My で音を鳴らすこともできるが、家の中でちょっと見つからないときにわざわざ Mac のところまで行って Find My をしたり、家族に頼んで他の iPhone から探したりするのは大げさすぎる。手元でちょっと操作しただけで iPhone 側の音が慣らせるのは便利だ。

Apple Watchのコントロールセンターを使う - Apple サポート (日本)

Apple Watchのコントロールセンターでは、バッテリー残量を確認したり、Apple Watchを消音にしたり、Apple Watchをフラッシュライトとして使用したり、おやすみモードや機内モードをオンにするなどの操作ができます。

support.apple.com

運動時の快適性アップ

iPhone なしでジョギング

iPhone を持たず単体でジョギングに出かけられるのがいい。ランニングのログ取りと音楽や Podcast の再生が Apple Watch だけで完結する。 Apple 製のソフトだけでなく、 Castro のようなサードパーティのソフトでも Apple Watch 内に Podcast をダウンロードしておいて iPhone なしで利用できる。 iPhone がなくても Apple Pay が使えるので、 iD などに対応している自販機で飲み物を買うこともできる。

自分が買ったのはセルラー回線なしの GPS モデルだ。 iPhone を持たずにジョギングはセルラーモデルを買えるような金持ちの専売特許かと思っていたがそうではなかった。ジョギング中に電話を受ける必要がなければ GPS モデルで十分だ。 Workout の GPS ログ取りも GPS モデルの Apple Watch 単体で全く問題ない。

ペアリングされたiPhoneなしでApple Watchを使う - Apple サポート (日本)

iPhoneが近くにないときでも、Apple Watchは役立ちます。

support.apple.com

ジョギング自体の快適性アップ

Apple Watch によってジョギング自体も快適になった。 Pebble 時代は Runkeeper を使っていて、 Runkeeper には Pebble 用のコンパニオンアプリがあった。ただ、 iPhone 側との接続があまりうまくいかず、 iPhone 側で Runkeeper をバックグラウンドに持っていくと Pebble との接続が切れてダメダメだった。 Runkeeper には 1km とか 5 分とか走ったときに教えてくれる機能あるけど、 Pebble に通知が来るわけではなく、イヤフォンを付けて iPhone 越しに音声で聞くしかなかった。マッチョな感じの外人女性の声で "Distance, 1 kilo meter" とか言われてもあまりテンション上がらなかったし、聞いてる音楽や Podcast の音量が下げられて上から覆い被さるようにしてアナウンスされるので使い勝手が良くなかった。 Apple Watch であれば 1km ごとにブルブルっと震えてラップタイムを教えてくれる。ちょうどいい。走ってる最中に現在のペースや心拍数、経過時間なども一発で確認できて便利。

走り始める前にランニング用のアプリを起動しなくて良いのも地味に便利で、とりあえず Apple 謹製の Workout を起動してランを始めれば良いというのも手軽。終わったら Apple Watch で記録を止めて、後から Strava に Workout のデータを取り込むことができる。心拍数付きでグラフが表示されて便利だ。

Just a moment...

support.strava.com

心拍数がわかることによる運動負荷の把握

これまでジョギングなどで自分の心拍数などを気にしたことがなかった。 Apple Watch で心拍数がわかるようになり、自分が結構無理していることがわかるようになってきた。 Health Care アプリの解説によると、心拍数は 220 - 年齢 が最高値らしい。この前何気なく登山をしていたら心拍数が 181 になっており、そんなに飛ばしているつもりはなかったのに最大心拍数になっていて驚いた。それでそこでしばらく休んで呼吸を整えたが、心拍数がわからなければ自分がいま無理をしていることを知らずそのままのペースでのぼってバテていたかもしれない。ジョギングはともかく登山ではバテてしまうとその場でへばってしまったり、疲れからくるふらつきで転倒、滑落したりしてしまうので侮れない。自分の偽りのない体力の限界を知れて便利だった。

Apple Watchで心拍数を確認する - Apple サポート (日本)

Apple Watchの「心拍数」を使って、1日を通じた心拍数を監視します。

support.apple.com

褒められる

活動の記録とリング

Apple Watch は運動すると褒めてくれるし、サボってたら「運動しませんか？」と促してくる。これはウザいと感じる人もいるだろうけど、自分の場合はうざくない。 Pebble にも似たような促し機能はあったがワンパターンだったし、メッセージ内容がぶっきらぼうでよく分からなかった。

Apple Watchで日々のアクティビティを追跡する - Apple サポート (日本)

Apple Watchで「アクティビティ」を使って、立ち上がった回数、活動量、エクササイズをした時間を追跡できます。

support.apple.com

睡眠の計測

リングについても最初自分はウザいと思っていたが、運動して閉じることができると気分がいい。睡眠についてもメッセージを表示してくれて、朝起きてしばらくすると「ピロピロリン♪」と音が鳴って挨拶してくれ、その日の天気も教えてくれる。体験が良い。

Apple Watchで睡眠を記録する - Apple サポート (日本)

手首に装着したApple Watchで、睡眠時間やアラームでの起床状況を記録できます。

support.apple.com

結論

Apple Watch に限らずスマートウォッチというかウェアリングデバイスの良さは、これまで記録できていなかった自分の行動を記録してくれるところだと思う。有名なプログラミングの格言「推測するな、計測せよ」を自分の体で行う感じだ。

users.ece.utexas.edu

ただし、ただ計測するだけでは次のアクションに結びつきにくい。 Apple Watch は計測した数値をライトに評価してくれるところが良いところだと思う。ログをとることはその他のウェアリングデバイスでもできる。それをどう評価するかが難しくて、 Pebble の場合はあまり評価をせず、どういうアクションを取れば良いのかがわかりづらかった（いつもよりよく寝たねとか、今日はめっちゃ歩いたじゃんみたいなローカルプッシュはあった）。 Apple Watch は、それが自分の健康にどういうインパクトを与えるのか、読みものコンテンツ込みで提示してくれるのが良い。それでいて押しつけがましくないところもいい塩梅だと思う。

ただやっぱり Apple Watch は高い。 iPhone 、 Mac と定期的に買い換えるもののサイクルに Apple Watch も加わるとかなり懐的には厳しい。コロナ禍で飲みに出かけたり昼飯代でお金使うことがなくなったせいで何とかギリギリ大丈夫だろうと買う判断ができたけど、通常の生活ではとてもではないけど手を出すことはなかったと思う。 Pebble Time Round と同等の値段（ 1.5 万円くらい）で気軽に買える Apple Watch が欲しいし、あったらもっとめっちゃ売れると思う。

買って良かった Apple Watch アクセサリー

以下はアクセサリー的なもののうち買って良かったやつです。冒頭の写真はこの二つを装着・利用した状態で撮影しています。

Apple Watch 用充電台

Apple Watch 、 Qi で充電できるものだと思っていたけど対応していないことを知って衝撃を受けた。なので付属の丸くくぼんでいる充電器で充電しないといけないのだけど、それだと机の上で収まりが悪い。というわけでこいつを買った。カチッと Apple Watch が固定されて、充電中は置き時計としても使えて便利。 Qi のスマートフォン充電台と一体型の商品もあるようなので、 Qi を持ってない人はそっちを検討してもいいかも。

液晶保護ケース

Apple Watch はアルミニウムモデルを買ったのでガラスがサファイアガラスではなく、またアルミニウムはステンレンスやチタンよりも傷つきやすいとのことだったので保護ケース的なものを買った。時計は結構いろんなところにぶつけるのでこういうのに入れておくと安心だと思う。装着しても Apple Watch がダサくならないので気に入っている。

去年（ 2019 年）の年末、今年行ったところアドベントカレンダーに登録したが、いろんなアドベントカレンダーに登録しすぎて記事を書くことができなかった。 11 月に入って 2020 年のアドベントカレンダーの募集が始まったみたいなので、今年のシーズンが始まる前に去年のやり残しを片付けておきたくなった。ということで 11 ヶ月遅れで「今年行ったところ」です。

2019 年に行ったところでは 10 月に訪れた平戸が一番心に残っている。このときは平戸を訪れることが目的だったのではなく、平戸の手前、旧田平町にある中瀬草原キャンプ場¹でのキャンプが目的で、キャンプに行ったついでで平戸の街に偶発的に立ち寄った。昼過ぎにテントを片付けて腹が減っていたし、このまま帰るのはもったいない（福岡から平戸までは車で 3 時間近くかかり、一泊キャンプしただけで帰るのはガソリン代や移動時間のコストパフォーマンスが悪い）と思われ、気まぐれで訪れたにもかかわらず、平戸の街は強く印象に残っている。

平戸は島であり、平戸に入るには平戸大橋を渡る必要がある。平戸大橋の下には田平港があって、昔は船で海を渡っていたようだ。平戸を訪れたあとに読んだ司馬遼太郎の『街道をゆく 肥前の諸街道』では渡し船に乗っていた。

平戸の街に入り、平戸港交流広場に車を停めた。 2 時間までは駐車料金が無料だった。ここは港であると同時に観光案内所（とても綺麗なトイレがある）でもあり、観光スポット情報を集めた。

平戸にはオランダ商館（オランダ商館の跡地に建物が復元され資料館になっている）と松浦歴史資料館（旧平戸藩主松まつ浦ら氏²から寄贈された松浦氏の私邸を資料館に改装したもの）、ザビエル記念教会がある。時間的に遅く全部回ることはできなそうだったので、まずはザビエル記念教会、その後オランダ商館に行くことにした。

ザビエル記念教会

ザビエル記念教会は丘の上に建っている。おもしろいことにこの教会に辿り着くまでの坂道にはお寺がたくさん建っており、寺町を通り抜けて坂を登り切ると教会が建っているという不思議な空間になっている。教会からは竹林越しに平戸城が見える。

教会のあとは平戸の街を通り抜け、オランダ商館を訪れた。

オランダ商館

オランダ商館は復元された建物だ。平戸が貿易港として栄えていた頃に商館は作られたが、 1640 年に幕府の意向により貿易はすべて長崎の出島に集約されることになり、商館は破壊された。破風に西暦の年が書かれていることをキリスト教に警戒感の強い幕府から咎められたと言われているが、多分こじつけで、貿易の果実を松浦氏に独占させたくなかったのかもしれない。長崎ならば天領で、貿易の利益を幕府のものにすることができる。

商館には帆船の模型や松浦家が所有していた西洋の甲冑のほか、オランダ商館の家財や、当時貿易されていた品（器や香辛料など）が展示されている。商館の建物自体の構造も解説されていて、木造建築技術しかなかった 400 年前にいかにして貿易品を貯蔵するための巨大な貯蔵庫を建築したのかや、二階の窓から物品を積み下ろしするための巻上機（リフト）の構造を知ることができる。またオランダ人と結婚した日本人や、オランダ人との間に生まれた子どもがインドネシアに追放され、ジャカルタから「日本が恋しい」と綴って日本に送った手紙（ジャガタラ文）の展示もある。

商館は平戸瀬戸を見渡せる町外れにあり、平戸城や平戸の街を一望できる。平戸大橋も綺麗に見える。

商館近くには荷物の積み下ろしに使われていた埠頭が残っている。埠頭といっても簡易な石造の階段で、こんな小さな石段を介して歴史を動かす交易が行われていたのかと思うと感慨深かった。

商館自体は復元された建物だが、商館および商館員たちが暮らした居留地と市街の間には漆喰塗りの壁が現存している。オランダ塀と呼ばれていて、防火や市民の視線を避けるために作られていたものらしい。

長崎の出島同様、オランダ商館は市街から隔絶されていたのかもしれない。長崎の街もだいぶコンパクトだが、平戸はさらに街が狭く、平戸城はもちろんのこと、町中の至る高台から商館を見ることができる。街がコンパクトなため、壁で隔てられていても完全に隔絶されているわけではない。商館と平戸の街との一体感のようなものを感じた。きっとそれは江戸初期も同じだっただろう。今日訪れてみても、長崎以上に異文化がすぐ隣にあったことを感じとれる街だと思う。

街並み

ちょうどこの日は平戸くんち最終日だったようだ。昼間は少々観光客がいたのかもしれないが、夕方になると街はがらんとしていた。平戸は福岡から遠いため、観光客の引きも早いのだろう。日本海側ということもあって、日が傾くとなんとも言えない寂しさが際立った。

街並みは木造建築を主として歴史的景観を保とうという努力が感じられる。信州の中山道沿いの宿場町のような雰囲気がある。おくんち期間中だったのでどこの家も松浦家の家紋ののれんを掲げていた。長崎も同様におくんちの期間にはのれんを掲げるが、支配者の家紋ではなく自家の家紋入りののれんを掲げる。また長崎は一部木造建築の建物もあるが、大多数は近代的なコンクリート造や鉄骨造の建物³で、歴史的な景観というのはほとんど見られない。その点で長崎生まれの嫁さんは平戸の街の景観に感銘を受けていた。

感想

正味の滞在時間が 3 時間くらいしかなく、ほんのちょっとしかいられなかったが、平戸はとても味わい深い街だと思った。オランダ、ポルトガルとの交易の歴史では長崎の陰に隠れがちだが、最初にポルトガル船が往来するようになったのは平戸だし、オランダとの交易を最初に始めたのも平戸だった。その前の時代には松浦党や倭寇の歴史もある。世界史で習う台湾の偉人の鄭成功は平戸生まれで母親は平戸の人だ。隠れキリシタンの歴史もある。キリシタン関係でも長崎市が注目を集めがちだが、江戸期に隠れキリシタンとして信仰を続けたのは五島や平戸の人たちだった。歴史のほかにも、海の美しさが挙げられる。平戸西部にある人津久海水浴場や根獅子の浜海水浴場は沖縄の海と見まごうばかりの美しさだ。

Google マップ

★★★★☆ · 浜

www.google.com

Google マップ

★★★★☆ · 浜

www.google.com

九州に住んでいてまだ平戸を訪れたことがない人は是非一度訪ねてみて欲しい。九州の日本海・東シナ海側には南国のイメージと違った、独特の雰囲気がある。 2016 年の「今年行った場所」で書いた唐津とセットで行ってみることをおすすめします。

インデックスページをいじって各カテゴリーの最新記事 4 件を配置するようにしてみた。最近の個人サイト復興ブームでみなさんインデックスページを工夫されているのを見ていて真似したくなってやった。

昔ながらのブログだとインデックスページというのは最新の記事 10 件くらいが表示されていて、「次へ」を押すと古い記事が出てくるという構成になっている。以前のこのブログもそうだった。

しかし自分自身が他人のブログで「次へ」を押して次々に記事を読んでいくということをやった記憶がほとんどない。自分のブログでだって何か目的があって特定のキーワードで検索したあとに引っかかった記事を読むという感じなので、時系列に本文とセットで記事が 10 件ずつ表示される UI というのは意味をなしていないと思った。そもそもインデックスという名称なのに最近の記事数件しか表示していないのはおかしい。インデックスというからにはすべての記事の目次になるべきだ。

このブログはカテゴリーがあるので、サイトマップを作るとするとこんな感じになると思う。

+----------+        +------------+        +-----------+
|          |        |            |        |           |
|   Blog   +---+--->+  Category  +------->+   Entry   |
|          |   |    |            |        |           |
+----------+   |    +------------+        +-----------+
               |
               |
               |    +------------+        +-----------+
               |    |            |        |           |
               +--->+  Category  +---+--->+   Entry   |
                    |            |   |    |           |
                    +------------+   |    +-----------+
                                     |
                                     |
                                     |    +-----------+
                                     |    |           |
                                     +--->+   Entry   |
                                     |    |           |
                                     |    +-----------+
                                     |
                                     |
                                     |    +-----------+
                                     |    |           |
                                     +--->+   Entry   |
                                          |           |
                                          +-----------+

第一階層がインデックスページで、第二階層がカテゴリートップ、そして各記事がある。なのでインデックスページは二階層目の一覧ページになっているのが望ましいはずだ。しかし伝統的なブログはカテゴリーという記事をまとめる概念がありつつも、インデックスページから各記事ページへ直接遷移するのが主な導線だった。常に最新の記事が時系列順に並んでいるだけでは味気ないし、常連の読者ではないコンテキストを知らない訪問者には不親切だろう。

しかも SNS の隆盛で個人のブログのインデックスページが参照される機会というのはとんとなくなってしまった。個人が書いたブログ記事は SNS 経由で読まれ、個別記事だけが読まれる。インデックスページやトップページが読まれることはほとんどない。 SNS でシェアされている URL をクリックして個別記事を読んで、それ以上そのブログのほかの記事を読むことなく離脱してしまう。前後のコンテキストは無視して、一つのコンテンツだけがつまみ食いされてしまう。そんな流れにあらがいたいと思った。

これまで関連記事を記事下に表示するなどやってきたが、気に入っていくつか記事を読んで「ホーム」（ = インデックスページ）を訪れたユーザーがもう少しブログを深掘りしてみたくなるようにインデックスページを各カテゴリーの最新記事一覧とするようにしてみた。このブログは現在カテゴリーが 13 個あるので、それぞれから 4 件ずつ記事を取得すると 52 記事になる。全カテゴリーからまんべんなく 4 記事ずつ取得して表示するのは簡単なようで結構難しい。普通の SQL ではできない。 OR マッパーではまず無理だろう。

いろいろ調べてみた結果、 MySQL では GROUP_CONCAT というのが使えそうだった。以下のような SQL を書いた。

select entries.id
from entries
inner join (
  select
    category_id,
    GROUP_CONCAT(id order by created_at desc) as entry_ids,
    max(created_at) as last_created_at
  from entries
  where entries.draft = false
  group by category_id
) as grouped_entries
on grouped_entries.category_id = entries.category_id
and FIND_IN_SET(id, entry_ids) between 1 and 4
order by last_created_at desc, entries.id desc;

GROUP_CONCAT と FIND_IN_SET という関数を組み合わせることで、各カテゴリーから作成日の降順に記事を 4 件ずつ取得できた。このクエリでは記事 id のみ取得して、もう一回 DB に記事を取得するクエリを ActiveRecord で投げる。 ActiveRecord でクエリを組み立てるときは N+1 が起こらないように関連テーブルを JOIN する。

query = <<~SQL
  select entries.id
  from entries
  inner join (
    select
      category_id,
      group_concat(id order by created_at desc) as entry_ids,
      max(created_at) as last_created_at
    from entries
    where entries.draft = false
    group by category_id
  ) as grouped_entries
    on grouped_entries.category_id = entries.category_id
    and find_in_set(id, entry_ids) between 1 and 4
  inner join categories on categories.id = entries.category_id
  order by last_created_at desc, entries.id desc;
SQL
entry_ids = ActiveRecord::Base.connection.select_all(query).rows.flatten
entries = Entry.includes(:category, :user, :tags, :comments).where(id: entry_ids)

PostgreSQL のときに最初に取得した entry_ids の並び順通りに結果が受け取れるかは怪しいが、 MySQL の場合は一回目のクエリで取得した id 順に各レコードが ActiveRecord のクエリ結果として取得できた。あとはこれをカテゴリーごとにグルーピングして View でよろしくやれば良い。

なお各カテゴリーはカテゴリー内の最新の記事の作成日で降順ソートするようにしている。例えば現在のインデックスページの最下部には音楽カテゴリーがあるが、これは音楽についての記事を最後に書いたのが一年以上前だからだ。もしいま音楽の記事を書けば音楽カテゴリーがトップに浮上するようになっている。

見た目に関しては各カテゴリーの記事最新一件は大きなサイズで表示している。最も最近書かれた記事なのでより多く人の目に付いた方がよいだろうという考えだ。またすべての記事にサムネイルというか、アイキャッチ画像を表示するようにした。画像がない記事に関してはデフォルトのサイトアイコン画像を表示するようにしている。やっぱり視覚的に情報を捉えられるのは重要だ。画像がごちゃごちゃ表示されるのを嫌う人もいるかもしれないが、テキストだけでは人間の認知というのはどうしても追いつかない。

あわせて今回、インデックスページの冒頭部にこのサイトについての説明文を載せることにした。ながしまきょうさんや r7kamura さんがやっているののパクりだ。伝統的なブログのインデックスページは初めて訪れた人のことを無視しすぎていたと思う。そのブログ自体について説明するページがあるブログは少ない。最初の記事でブログを始めた経緯みたいなことが書かれたきり、そのブログは何なのか、誰が書いているのかが書かれることは希だ。きちんとブログについての説明ページと著者についての説明ページがあっても、左右のサイドバーやトップのナビゲーションの端っこに押し込まれて見られることはない。これではいけないだろう。というわけでインデックスページの一番目立つ位置にブログと自分自身の簡単な紹介を入れた。

ブログはなぜ衰退したかを考えてみると、 Facebook や Twitter の隆盛はあるにせよ、ブログ自体に初めて訪れた人に読まれるための工夫が欠けていたのだと思う。誰も自分のブログの継続率を計測したりコホート分析したりはしない。読者が前後の記事を読んでいることを前提に書かれた記事やサイト構成では初めて訪れた人はどうやっても離脱してしまう。特に書き手が芸能人でもない一般人の場合はなおさらだ。誰も RSS フィードを購読していないし、ほとんどの読者は初めて訪れる人なのだから、そういう人たちが読んでブログのテーマや著者の人となりが分かる構成にしていかなければならないのだと思う。でないと SNS でたまにバズったときだけ読んでもらえる、ソーシャルメディアの肥やしにしかならない。

この新しいインデックスページが正解なのかどうかは分からないが、ブログ衰退の流れにあらがっていきたい。

blog.8-p.info の過去記事ページの真似をして、 Archive ページにタグを表示するようにしてみた。

タグはあまり使っていなかったのだけど、一覧で記事タイトルだけ並んだときその記事にどんな内容が書いてあるのかを把握するためにはタグが便利だなと思い直し、タグを表示させてみることにした。いくつか過去のタグが付いていない記事にタグを振ってもみた。

このブログは技術情報からポエム、日々の日記まで何でもありのごった煮ブログなので、カテゴリーによる情報分類には限界がある。現在 13 個のカテゴリーがあるが、記事数にバラツキがあり、情報分類としてあまり機能していない。カテゴリーの粒度をもっと荒くして緩い分類に変更し、そこから先はタグによって超細かくラベリングすると情報の分類としてはまともになるのではないかと思った。

いま、カテゴリーの内訳がこんな感じ。

- "雑談":303
- "技術/プログラミング":272
- "映画/ドラマ/テレビ":150
- "Mac/iPhone":134
- "WWW":113
- "散財":95
- "旅行/ハイキング":70
- "ブログ":69
- "音楽":63
- "読書":34
- "写真":32
- "料理/食事":31
- "労働":27

もっと緩い分類にして以下みたいな感じにするとよさそう。

- 雑記
- パソコン・インターネット
- 見た・読んだ・聞いた
- 出かけた・撮った・食べた

カテゴリーとタグの使い分けは 10 年以上前から悩んでいる気がする。

タグはいっぱい付けないとダメですね

現在流行しているタグによる情報の分類は、とても中途半端で使い勝手が悪い。これまでのカテゴリ分類の代用として、もしくはタグクラウドを表示して自己満足に浸る以外には、あまり役に立たない。それはこのタ...

portalshit.net

情報分類の手法でありつつコンテンツの内容そのものを指し示すものでもあるからだろう。インスタグラムで #ラーメン #からの #うどん とかやってる投稿を見るととても嫌な気持ちになるのだけど、そういうことがされるくらいにタグというものは不安定なもので、正しく使おうとか気負わず、もっと緩く使えばいいのかもしれない。

もう廃れてしまったが、フォークソノミーが勢いを取り戻して、情報の発信者ではなく受け取り側がコンテンツにタグ付けできるような世の中になるとおもしろいのかもしれない。

フォークソノミー - Wikipedia

ja.wikipedia.org

最近、エンジニアの求人の広告を見るといかにもテック企業のものが減っていると感じる。 10 年くらい前、ウェブ系のソフトウェアエンジニアの求人といえば受託をしている会社（ウェブ制作会社）か、自社でウェブサービスを開発している会社のものしかなかったと思う。自分は最初はウェブ制作会社に入り、その後自社でウェブサービスを開発している会社に転職した。さらにその後はデジタルマーケティングの SaaS / プラットフォームを作っている会社に移った。すべてソフトウェアでしかできないことをやっている会社で、インターネットがあるから事業が成り立つというような会社だった。一方で最近のソフトウェアエンジニア求人の中には、インターネットがなくても成り立つ事業領域をインターネットで効率化しようというものが散見される気がする。

もちろんこれらの企業も広義では「インターネットがあるから事業が成り立つ」と言えるのだろうけど、対象としている市場自体はインターネット以前から存在していたし、つい最近までそれで問題なく回ってきた市場だ。そういった昔ながらの市場にテクノロジーで殴り込みをかけて利益をかっさらおうというようなビジネスモデルだ。言語化が難しいのだけど、 2000 年代くらいまでの IT ベンチャーは IT が核だった。まずテクノロジーがあって、それで何をやるかを考える。 HOW の部分（ソリューション）が先にあって後から WHAT （プロブレム）を考える感じだ。一方で最近の IT ベンチャーは、まず対象とする事業領域（ WHAT ）があって、そこをいかにインターネットを使って効率化し革新するか（ HOW ）、というタイプが多い。プロブレムが先にあって、ソリューションが後から付いてくる感じだ。わかりやすい例を出すと Evernote や Dropbox は前者（インターネットがなければ成り立たない市場を対象とする）で、 Uber や Airbnb は後者（配車サービスも民泊もインターネットが生まれる以前から市場として存在した）だろう。

ソフトウェアエンジニアに求められる技術はどちらでも同じだと思うが、その企業の会社概要や経営者のプロフィールを見ると 2000 年代の会社や経営者と結構毛色が違っていて、元々ソフトウェア業界ではないところにいた人がそれまでの経験を活かして起業した、というパターンが多い気がする。リーンスタートアップやプロダクトマネジメントの観点からすると WHAT が先にあって HOW は後から考えるというフローが正しいのだけど、これらの新手の IT ベンチャーは特定・専門の領域に特化しすぎていてやっていることがイメージしづらいし地味な印象を受ける（ Uber や Airbnb は C 向けなので例外的に目立ってる）。何よりわくわく感をあまり感じない。中卒のプログラマーが天才的なひらめきでソフトを作って一発当てて金持ちになる、みたいなのの方が夢があると思う。

表示していた Google Adsense の広告を外した。自動広告をオンにすると本文の途中など意図しないところに広告が掲載されまくってしまって大分読みづらい。かといって記事下に入れる程度だとまったくクリックされなくて貼ってる意味がなかった。加えて、ここ一年間で数度行われた Google のコアアルゴリズムアップデートで検索流入が 1/3 くらいになってしまって PV が激減してしまった。 Google としてはどこの馬の骨とも付かない個人がやってる泡沫ブログにトラフィックを流してインターネットの果実を分け与えるつもりはないのだろう。 Adsense 広告の読み込みでサイトの読み込み速度も少し遅くなっていたし大分すっきりした。

消した理由で一番大きいのはアルゴリズムやリターゲティングによる広告のむなしさだ。 Amazon アフィリエイトなど自分の意思でレビューしたり紹介したアイテムの広告ではない広告が自分のブログに表示される必然性はない。アルゴリズムやリターゲティングによる広告は、掲載される場所はどこでもよくて、たまたま空いてたから表示されました、というような間に合わせ感がある。自分が楽天で見た商品の広告が自分のブログに延々表示される様を見て、こういう広告を表示し続けることで自分のブログの価値が毀損されているような気がしてきた。一つ前の翻訳記事がバズって結構アクセスがあったが、翻訳元のブログには広告が表示されていないのに翻訳した自分のブログには広告が表示されていて、自分が広告を入れていることで元の記事の価値も下げているような罪悪感もあった。

元からブログで儲けようとは思っていなかったが、ブログを書くことで得られる一番の利益というか目的は、広告によって小銭を稼ぐことではなく、ブログを書くことで自分自身の価値を高めることだと思う。ブログによってインターネット上でのプレゼンスを高めて知名度を獲得したり、ブログを書いたり運用したりすることで技術的な知見を得てスキルアップにつなげられる。それらを自分の給料に上乗せできるような仕組みを作っていくことが大切なのかなと思った

7 年間眠っていたブランチを起こして、 Lokka の ActiveRecord 化に取り組み始めた。元のブランチは hrysd さんが取り組んでいたやつだ。

[WIP] Migrate from DataMapper to ActiveRecord 5 by morygonzalez · Pull Request #256 · lokka/lokka

This branch is 素振り (practice) At first, I thought this branch must be practice. But I realized that it's so hard to resolve conflicts between active-record branch and master. #258 So I changed ...

github.com

現在の master の内容を取り込むのが大変だった。 active-record ブランチでは ActiveRecord 化と同時に様々な改良・改変が行われていて、 master の内容と思い切りコンフリクトするものがあったりして、コンフリクトの解消作業はかなり大変だった。

active-record の大きな変更点は以下。

1. カスタムパーマリンク機能の削除
2. 「もっと読む」機能の削除
3. カテゴリーをネストさせる機能の削除
4. ユーザー認証方法の変更（カラムの追加）

このうち 1 と 2 は削除された機能を復活させた。自分が使っていてなくなると困るし、特にカスタムパーマリンクは既存サイトでこの機能を使っているところがデッドリンクだらけになって散々な目に遭ってしまう。 4 に関しても、 master の認証方法と互換性を持たせないと既存ユーザーがログインできなくなるので古い認証方法でもログインできるようにした。

3 に関しては WordPress との互換性を考えると必要かもしれないが、自分で使ってなくてユースケースが思い浮かばないのでいらないかなという感じがする。そもそも Lokka は WordPress キラーとなるべく Fjord 社内で作られ始めたと認識しているが、 WordPress は相変わらず元気だし Lokka の利用状況的にも WordPress alternative を目指す必要はないと思う。

そのほか、 rake db:delete が動かなかったのを直したり bundle update をしてぶっ壊れたところを直したり、デフォルト以外のテーマが ActiveRecord 化してなかったのを対応させたり（ dm-pagination から kaminari へ移行）して ActiveRecord 5 で概ね動くところまで持ってくることができた。

ActiveRecord は良くできていて、 DataMapper だと難しかった JOIN した上での集計クエリなどが書きやすい。ドキュメントが山ほどあるのもよい。 DataMapper は情報が少ないのが一番つらかった。一方で DataMapper だと気にする必要がなかった N+1 問題を自分で解決する必要がある。 View でうかつに参照するテーブルのデータを増やすと N+1 問題が発生して途端にパフォーマンスが劣化する。

また、誰がどんな DB で利用するかわからない状況で db/schema.rb を git で追跡してよいものかというのもひかっかる。 ActiveRecord を使う以上、 migration と schema.rb からは逃げられないのだが、 MySQL で使う人も PostgreSQL で使う人も SQLite で使う人もいて、それぞれの DB でマイグレーションを実行するごとに異なる schema.rb が吐き出されるので git で追跡すべきではないのではないかと思う。どんなデータベースで利用されるかを意識せずに開発できる、という点では DataMapper の方が CMS 開発向きだったと思う。

以前の Lokka であればあまり Ruby 知らない人でもとりあえず git clone して自分の好みのテーマを追加して Heroku に push すれば動かせたが、 ActiveRecord 化することで N+1 問題など Rails に強くないと触りにくい感じになってしまった。ただ、 Sass は Ruby を捨てて C に移行したし、 Slim なんかも JavaScript フロントエンド技術の盛り上がりの陰で開発は停滞している。こういう時勢になってくるとフロントエンドに強いマークアップエンジニア兼ウェブデザイナー的な人が Ruby 製の CMS を使う動機はなくなってしまう。 CMS を使ったサイト構築でも Sass や Slim を使って HTML コーディングの生産性を上げ、 Heroku を使って簡単に deploy できる、というのが komagata さん達が最初に想定してた Lokka のユースケースだと思うけど、 JavaScript によるフロントエンド技術が強力になりすぎて、生産性の高いフロントサイド開発のために Ruby を経由する必要がなくなってしまった。

これから Lokka はどうあるべきなのだろうか。モダンなフロントエンドフレームワークは強力だ。否が応でも JAMStack に対応していくしかないだろうと思う。つまり Sinatra で作るのは API （と管理画面）だけになり、フロントエンドは React や Vue.js で作るべきだろう。ちょっとしたサイトを JAMStack で構築したいが、 API に良いのがない、とはいえ Rails は使いたくない、というケースで Lokka を使うという感じだろうか。ただ、いまは Firebase なんかもあるのでそもそも API を自前で持つ必要はないのかもしれない。どのみちかなりニッチなユースケースになるだろう。

ちなみにこのブログの Archive ページは中途半端ながら React で作っていて割といい感じに動いている。 ActiveRecord 化が済んだら React でサイト全体を作り直してみたい。