| @料理/食事

メスティンで卵かけご飯

どういう文脈か知らないのだけどメスティンがはやってるらしい。メスティンというのはスウェーデンのトランギアという登山用クッカーなどを作ってる会社の製品で、日本ではイワタニ・プリムスが販売してる。自分は登山の会社に勤めているので 3 年くらい前からメスティンというものの存在は知っていたが、かたちが変だしあまり便利そうに見えなくて使ってなかった。今年の春にアルコールストーブを買って以来、チタンとかウルトラライトなハイキング用品に興味が出てきて、メスティンは UL ハイカーの間でも定番のアイテムだということを知った。いつか欲しいと思っていたが Amazon では正規品は在庫切れで、怪しい業者が 4000 円くらいで出しているものしか買えなかった。たまたま 9 月頃、定価で注文受付しているタイミングに遭遇し定価で購入できた。

昼休みにベランダで炊飯

その後家で練習炊飯して山やキャンプでも使ってみた。

キャンプで卵かけご飯

山頂で炊飯

アルコールストーブで炊飯する場合、炊飯時間はアルコールストーブの燃料容量に依存する。自分が持っているエバニューのアルコールストーブは 60ml 入るが、火力が強くて一気に燃料を使い果たす。多分 10 分くらいしか持たない。そのため事前に米を水に浸して水を染み込ませる必要がある。これをやらないと米に芯が残っておいしくない。さらにメスティンでの炊飯は炊飯後にタオルなどで包んで蒸らしの時間を設ける必要がある。ちょっと手間がかかるのだが、ちゃんと浸水して炊き、蒸らしも行うととてもうまいご飯が炊ける。炊飯器で炊いたのとは別次元のうまさになる。米の一粒一粒が主張してくる感じ。単なる固めのご飯とは違う、圧倒的な米粒の存在感を感じられる。一合炊いてペロリと食べてしまえる。糖尿病の危険が危ない。

メスティンでツナマヨかけご飯 1

メスティンでツナマヨかけご飯 2

他にも缶詰をぶち込んで簡易炊き込みご飯もできるし、スパゲティを茹でて食べることもできるみたいだ。定価なら値段も 1700 円くらいで安い。

以下はトランギアのメスティンでいまは定価ではないが、定期的に定価でも販売されるっぽいので欲しい人は時々覗いてみて下さい。

| @ブログ

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

カテゴリーごとに最新記事 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_CONCATFIND_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 でたまにバズったときだけ読んでもらえる、ソーシャルメディアの肥やしにしかならない。

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

| @登山/ランニング

山頂でコーラ

8 月の最後の日曜日に脊振山から金山まで縦走した。 2 年前の糸島四座縦走(未遂)以来の長い日帰りソロハイクだった。歩いた距離は平坦地の距離も合わせて 21km 。くたくたに疲れて思わず山行中にコーラを 3 本飲んでしまった。

いつかは脊振山系全山縦走(福岡県と佐賀県を隔てる県境の山系で西端の十坊山から東端の基山まで 70km ある)をやってみたいと思っていたけど、今回脊振山・金山を縦走してみて自分は到底そのレベルに到達することはできないなと思った。脊振山から金山へ縦走していて、途中のところでくたくたに疲れて地面に座り込んで休憩してしまった。山ではがんがん登山するよりも、ほどよく休んでコーヒーいれて飲んだり、冷凍焼売を蒸して食べたりだとか、ピクニック + ハイキング的なものの方が自分の性分に合っている。

鬼ヶ鼻岩で焼売

帰りの交通機関の時間を気にしながらの登山は目的が達成できたときはうれしいが、ゆっくり写真を撮ったり食事したりすることができず少しせわしない。かといって車を使った登山をするのは負けた感じがするし、車を使わない縦走ならではの下山後の酒というご褒美がなくなってしまう。となるとある程度歩く登山の場合は日帰りではなく山に泊まることを考慮すべきなのかもしれない。

脊振山へのルートは沢が多くもみじが美しかった。新緑の季節や秋に訪れると最高だろう。

もみじの美しい谷

金山も山頂は眺望がイマイチと聞いていたが、脊振山・金山間の縦走路は稜線歩きの快適な道が多く、脊振山まで車で来て鬼ヶ鼻岩くらいまで歩いて引き返す、というような感じだと家族連れでも楽しめそう。

九州自然歩道

白砂の眺望の良い場所

鬼ヶ鼻岩からの景色

猟師岩山・金山間は歩く人が少ないのか笹藪が茂っているし、結構痩せ尾根があって万が一転倒すると簡単に落命しそう。

金山までの縦走路

予定では金山から花乱の滝コースで下山する予定だったが時間が押してしまい、バスの時間に余裕がある坊主ヶ滝ルートで下山することにした。

当初の予定ルート(花乱の滝方面から下山)

実際のルート(坊主ヶ滝方面から下山)

ただし坊主ヶ滝ルートは罠があって、登山口までの時間は確かに短いが、バス停まで 40 分程度舗装路を歩く必要があって結局バスに間に合わず、本数の多いバス停までさらに 1km 程度歩いた。疲れた体にはこたえた。

日暮れ後の田んぼ

バスで西新まで移動して、一人しめやかに祝杯を挙げた。ラーメン一杯 290 円の店で 1300 円くらいお金使った。

西新のラーメン屋で

| @WWW

山に行ったときに山頂でコーヒー入れて飲むの好きで、その様子を「純喫茶 山頂」などと言って Twitter に投稿してた。

そしたら嫁さんに同じようなことを動画でもっとイケてる感じでやっている人がいることを教えてもらった。

Tasty がその人の動画を一本にまとめてるのが以下。

Falke Omdal さんという、ノルウェー人のアウトドア写真家のようだ。フィヨルドを見下ろす崖の上に腰掛けてコーヒー入れたり、カヌーでどっか行ってコーヒー入れたり、山の上にテント張って焚き火でお湯わかしてコーヒー入れたりしてる。山で焚き火台使わず地面に直で焚き火するの、日本でやったらめっちゃ怒られそう。

Falke さんがすごいのは、山にハリオやケメックスのコーヒーサーバーや、ガラスのコップを持って行ってるところだ。登山用品はとにかく軽い方が良いし、かさばるものは避けられがちだ。軽くて小さく、重ねられる丈夫なものが好まれる。ガラスの容器やコップは重いしかさばるし割れやすいので全然登山向きではない。でもやっぱりコーヒーは金属製の容器よりもガラスのサーバーにドリップする方がうまそうに見える。

地面直の焚き火にしろ山でガラス容器を使うことにしろ、登山で常識とされていること(少なくとも日本では)から自由な発想で山での時間を過ごしているところがとてもうらやましい。

ちなみに自分もこの前家の近くの山に登ってみたときに真似して動画撮ってみたけどあまりいい感じにできなかった。簡単そうに見えるけどちゃんと三脚で固定したり、コーヒー入れる人とは別に撮影する人が必要だと思った。編集のテクニックも必要だ。長い動画をアップしてもあまり見てもらえないっぽい。必要な部分だけを残してつなげ、 30 秒くらいで終わる動画にしないと見てもらえなそうだ。

| @ブログ

#100DaysToOffload 7 月のふり返り

7 月 10 日に #100DaysToOffload に挑戦する宣言をしてからしばらくは調子よく記事を書けていたが、後半にだれてしまった。 11 記事以上書かなければならないところ、 9 記事しか書けなかった。

宣言後に最初に書いた記事は、昨年末のセールで買った新しい Kindle Paperwhite についての記事。ホーム画面がリッチになって目移りしてしまい本が読めなくなったというチラウラ記事だが、 Twitter で nagayama さんからリプライをもらって設定で回避できることを知った。情報を発信するところに情報が集まってくる良い例だと思った。

一番反響があったのは、エンジニアの求人を出している会社の顔ぶれが変わってきているという記事。一昔前は受託開発をやっている会社かウェブサービスをやっている会社が雑にエンジニア( HOW )を募集していて、何( WHAT )をやるかはエンジニアを採用したあとに顧客や状況に応じて考えるという感じだった。いまのエンジニア求人は何か解決したい課題があって起業された会社( WHAT )がエンジニア( HOW )を採用しようとしている感じ。 WHAT と HOW の主客が逆転しつつあるのでは、ということをまとめて書いた。

Numbers に関しての記事は、 Vim 、 Day One 、 Notion 、 WorkFlowy 、 Journler 、Yojimbo 、 Evernote などこれまでいろんなドキュメントエディター・オーガナイザーを使ってきて実現できなかったことが Numbers を使うとできるということをまとめようとして書いたが若干不完全燃焼感があった。例として出した登山の計画がニッチすぎたかもしれない。一般的な旅行の予定を Numbers で立てる、みたいな感じで紹介すればよかったかも。そういや Numbers のテンプレートに旅行計画ありますね。 Mac ユーザーで表計算ソフト使ってる人はわざわざ MS Office 入れて Excel 使ってるかもしれないけど Numbers はもっと評価されてよい。

Z6 の良さについては、オペミスで吹っ飛ばした過去写真の整理をしていて改めてその良さを伝えたいと思い立ち書いてみた。 NIKON は株価が低迷しているが、 Z は本当によいのでおすすめ。撮った写真をすぐに Bluetooth でスマートフォンに転送しつつ位置情報も付与してくれる機能が特に気に入っている。ちなみに NIKON は公式には Z 6Z 7 という Z と 数字の間にスペースを入れた名称にしているが、ググラビリティが最悪なので正式に製品名を Z6Z7 (スペースなし)にした方がよいと思う。

家の近所の長垂海浜公園の駐車場についての記事は本当にしょうもない記事という感じがあふれているが、たまにこういうのを書きたくなる。近所に住んでいる人間でないとわからない情報をインターネットに載せて社会貢献したいと思い、わざわざ夜に散歩してたときに写真を撮って回って記事化した。この手の記事は短期的にはアクセスが伸びないが後からじわじわと伸びてくる予感がある。 Garage Band でのアナログレコードの録音方法の記事 は 10 年以上前の記事だけどいまでもコンスタントにアクセスがある。

ブログは書かなくなると更新が滞ってしまうので、あまりクオリティの高いものを書こうと思わず、もっとライトな感じで更新していきたい。

なお、この記事を含めて 2020 年の記事は 40 記事なので、残り 5 ヶ月で 60 記事書かないといけない。一月あたり 12 記事は結構大変だ。

| @Mac/iPhone

Numbers.app

公共交通機関を使って登山に行くときは結構綿密に登山計画を立てる。登山口まで行けるバスはコミュニティバスのようなものが多く本数が少ないため、乗り継ぎや行程の時間管理に失敗すると登山できなくなったり帰れなくなったりする。特に長い距離の縦走を日帰りでやろうとすると時間の管理がシビアになる。コミュニティバスの最終時刻は精々 18 時くらいなので、その時間までに確実に下山しないといけない。もし下山できなかった場合はタクシーを呼んで大金を払って帰るか山で野垂れ死ぬしかない。なので準備が大事だ。

YAMAP やヤマレコに登山計画を立てる機能はあるが、あくまでそれは登山中の行程管理であって、行き帰りの公共交通機関の情報を含めた行程ではない。何時に家を出ると乗換駅には何時頃着いてバスはどれに乗れば良いか、バスの乗り換えはどこですればよいか、といった情報は登山計画には書けず自分で管理するしかない。

他にも、バスの時間を一本遅らせたときに後ろの行程にどのくらい影響が出るかを確認したいが、登山の行程と交通機関の行程が分離されていると影響を把握しづらい(手動で後ろの行程の時間をずらしていく必要がある)し、バスの時刻表や地図を埋め込んでおきたいが、画像の貼り付けやリンクには対応していない。

登山では(登山に限らず旅行などでも)プランA とプラン B を考えて、その日の体調や天候に応じて行程を変更するということがあり得ると思う。複数の計画を並列で眺めて比較検討したりするのも登山計画系のサービスではできない。

旅の計画とはつまるところタイムテーブルの管理であり、それはエクセル的なものが使いやすい。スタート時間を 5 分遅らせると後ろが何分遅れるかが簡単にわかる。この計画は何時間かかるのか、というのも勝手に計算してくれる。エクセル的なものであればリンクを埋め込んだり画像を貼り付けたりもできる。

ただ、 Microsoft Excel や Google Spreadsheet の弱点として、一つのシート(画面)に表示できるのは一つの表までだ。一つの画面で複数の表を並べて情報を整理したりできない。画像やリンクを埋め込むことはできるが、あくまで表情のどこかに置くという感じで使い勝手が悪い。セルの中に文字列が隠れてしまったりする。

Numbers は一つのシート(画面)に複数の表を表示できる。これにより関連する複数のデータを並べて情報を整理することができる。それぞれの表はグリグリ動かすこともできる。画像やリンクは表の一部としてではなく、独立したオブジェクトとしてシートの中に埋め込むことができる。こんな感じ。

Numbers

例えるなら表計算機能付きのスクラップブックといった感じだ。たいていのデジタルデータを取り込めて自由に配置でき、コメントを書いたりデータを表に集計して絞り込みしたりグラフ化したりもできる。

いろんなデータを取り込めると言えば Notion が思い浮かんだので同じようなことを Notion でやってみようとした。見た目はおしゃれだし画像やリンクの埋め込みは Notion の方に分があるが、表は作れるものの時間の計算ができない。行程管理において時間の計算ができないのは致命的だ。

Notion

SIer がドキュメント管理に Excel を使うのを嘲笑する風潮があるが(自分もかつて Excel で画面仕様書を作らされていて死ぬほど嫌だった)、何でも Excel で書くのは一理あるのかもしれない。

ただ、上に書いているように Excel には欠点があるので Mac が使えるなら断然 Numbers の方がよい。 Excel のようなマクロはないので高度な処理には向かないが、個人が普通に使う計算はできる。

Numbers のような機能を持ち、チームで共同編集もできる SaaS が出てくると市場を席巻できる気がする。 Miro などがそれに近いかもしれないが、ドローやダイアグラムに特化していてちょっとした計算や条件に応じたデータの絞り込みなどはできない。

話をもとに戻すと、個人が旅行計画のような図や写真、表を一元管理して情報を整理するような用途には Numbers が最適です

| @散財

自粛期間中、宗像にある GRiPS というアウトドアショップのホームページをずっと見てた。

GRiPS は冷やかし入店や子連れ入店お断りの店で非常に怖いところなのだが品揃えは良くて、商品紹介を兼ねたブログにはハンモックハイキングの様子がたくさん載せてあり、めっちゃハンモックハイキングに興味出てきて給付金で AXESQUIN のウキグモ Light を買ってしまった。

ウキグモ Light 、表裏逆に取り付けてしまっている…

ハンモックハイキングの良いところはテントや寝袋がいらないところだ。テント泊でないおかげでグラウンドシートやマット、ペグ、ポールなどが不要になりそれだけ身軽になる。しかもテントで寝るよりハンモックで寝る方が快適らしい。もちろんハンモックを張るには木が必要なので森林限界を超えた地点で野営することはできないが、九州の山は全部森林限界以下なので問題ない。

そのほかにも GRiPS のブログに影響されてしまい、ウルトラライトハイキングに興味出てきてアルコールストーブなどを買ってしまった。

VARGO ヘキサゴンウッドストーブと EVERNEW アルコールストーブ。天気が悪くて山に行けないのでベランダでラーメン茹でて食べた。

登山時の熱源にはガスバーナーを持っていたが、ガス缶はかさばること、残容量が読めず残りわずかになってきたら満タンの缶と残り少ない缶の二つを持つ必要があること、またそもそもガス缶が登山用品店でないと購入できないことがデメリットだった。アルコールストーブはコンパクトでパッキングしやすいし、残量が確認しやすく必要なだけの量を持っていくことができる。また足りなくなったら近所のドラッグストアでサクッと購入できるので、わざわざ燃料を調達するために街のアウトドア用品店まで出かけなくても良い。

色々道具がそろってきたので近所の山でオーバーナイトハイクをやってみたいのだけど梅雨に入ってしまって出かけられずもどかしい。

さらにいまはエバニューのチタンクッカーと蒸し皿が欲しいところ。↓の記事を見たら絶対に真似したくなる。

山で小籠包やってみたい。