| @ブログ

インデックスページをいじって各カテゴリーの最新記事 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 でたまにバズったときだけ読んでもらえる、ソーシャルメディアの肥やしにしかならない。

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

| @Mac/iPhone

Touch Bar

リモートワーク中心の世の中なので Slack の Status で離席していることやミーティング中であることが分かると便利なはず。というわけで自分はなるべく Slack の Status を更新するようにしているが、 Slack アプリ内での Status の更新は面倒くさい。メニューを押して絵文字選んでひと言アップデートを入力とか毎度やってられない。ボタン一発で Status を更新したい。

MacBook Pro の Touch Bar は評判が悪い。自分もあまり便利だと思わないのだけど、一つだけ便利な使い方があって、それがこの Slack の Status アップデートボタンを配置するというもの。 Touch Bar に配置されたボタンを押すだけで食事中であることや退勤済であることを Slack の Status として表示できるようになる。めっちゃ便利。

なお、オリジナルのアイディアとソースコードは 9m さんのものです。

必要なもの

準備

1. Slack の API Token を発行する

2. 9m さんの gist を clone し、手元で動かせるようにする

$ ghq clone https://gist.github.com/af5894ced5cc1ac38bfd2687cad7c780.git slack_status
$ cd clack_status
$ bundle install
$ echo "SLACK_TOKEN=XXXX" > .env
$ bundle exec app.rb "🍺" "退勤しました"

ちゃんと設定できてれば以下のようになる。

コマンドラインから Slack Status をアップデートしている様子

3. Automator を開き、クイックアクションを設定

新規作成で「クイックアクション」を選ぶ。

Automator を開き「クイックアクション」を新規作成

アクションの中からシェルスクリプトを選ぶ。

シェルスクリプトを選ぶ

実行したい処理をシェルスクリプトで書く。

実行したい処理をシェルスクリプトとして記載

自分は以下のようにしている。

export PATH="~/.rbenv/shims:$PATH"
export LC_ALL=ja_JP.UTF-8
export LANG=ja_JP.UTF-8
cd /Users/morygonzalez/src/gist.github.com/slack_status
bundle exec ruby app.rb "🚽" "放尿 or 脱糞中です"

なお、赤枠で囲った「ワークフローが受け取る項目」は「入力なし」にしておかないとちゃんと動かないので注意。

入力なしを選択

設定完了したら名前を付けて保存する。自分の場合は Slack トイレ などのような名前にしている。この作業を追加したいコマンドの数だけ繰り返す。

4. キーボードショートカットの割り当て

システム環境設定 -> キーボード -> ショートカット -> サービス の順に進む。正しく Automator でアクションを設定できていれば「サービス」の一覧に表示されるので、割り当てたいショートカットキーを割り当てる。

ショートカットの設定

5. BetterTouchTool で Touch Bar をカスタマイズする

タッチバーに表示されるボタンのアイコンとラベル文字を選び、タップしたときにショートカットキーが実行されるようにする。

BetterTouchTool で Touch Bar をカスタマイズ

こうすることで Touch Bar から Automator のクイックアクションが実行され、めでたく Slack の Status がアップデートされるようになる。

ちなみに自分の Touch Bar はこんな感じ。

Touch Bar の様子

ほこりをかぶってる Touch Bar を是非有効活用してあげてください。

Touch Bar がないパソコンを使っている人向けの情報

Touch Bar のない Mac を使っている人はこのやり方を使えないので Slack の Google Calendar 連携機能を使うと良いと思う。設定に Status Sync という項目があるのでこいつを On にすると、 Google Calendar で予定が入っている時間になると Slack の Status を自動で更新してくれる。

Google Calender の Status Sync

会議中であることくらいしか共有できないので Touch Bar にいろんなボタンを配置するのに比べたら不便だけど、カレンダーに予定を入れておくだけで Slack の Status を更新できるようになるのは便利。

今後の課題

良くありがちなのが「仕事中」の Status のまま退勤してしまうというやつ。夜中や週末も仕事している異常な人になってしまう。スマートフォンからも同様にめっちゃ手軽に Slack の Status をアップデートしたいけどまだソリューションを見つけられていない。情報お持ちの方いたら教えてください。

| @旅行/散歩

幣の浜

今年は 3 回海水浴に行った。毎年野北海岸というところに行っていたが、今年は芥屋にほど近いにぎの浜というところに行った。福岡の海にしては透明度が高く、晴れた日には水中を魚が泳いでいる様子を見ることができた。

幣の浜から見える火山

幣の浜は無料の駐車場があってサーフィンのメッカのようだった。晴れて波が穏やかな日は海水浴客も多いが、台風前の荒れた夕方なんかはサーファーの人たちでごった返す。

混雑したビーチ

ハワイのノースショアに行ったとき、子どもから大人まで誰もがサーフィンを楽しんでいたのが印象的だった。日本のビーチだと日焼けした茶髪のイケメンしかサーフィンしてはいけない感じがあると思う。ハワイでは中年の太ったおっさんやよぼよぼのじいさん、学校帰りの中学生っぽい子どもまでみんなが自転車や徒歩でサーフボードを運び、サーフィンしに来ていた。海の家や有料の駐車場なんかはなくて、道沿いの空いてるところに縦列駐車して誰もが自由に海で遊べるようになっていた。

塩釜跡

芥屋の幣の浜には日焼けした茶髪のイケメンだけではなく、普通の家族連れのお父さんや色白のお宅っぽい感じの男性、原付バイクで来た近所の大学生風の人など、典型的なサーファーのイメージと異なる人たちがサーフィンをしに来ていた。駐車場も無料で海の家の人からショバ代を取られることもなく自由だった。誰もが気軽に海で遊べる感じがハワイっぽいなと思った。

砂浜 Kindle

ただしハワイと違って弊の浜はゴミが多く、割れたガラス片などもあって危ない。ハワイは砂浜の至るところにゴミ箱が設置してあったし、ゴミを定期的に回収しに来る業者っぽい人もいて砂浜がとても綺麗だった。この点で言えば有料の海水浴場の方がある程度ゴミ拾いがされていて安全かもしれない。

幣の浜の夕暮れ

| @雑談

長垂海浜公園近くのコインパーキング

長垂海浜公園には無料の駐車場はありません。有料のコインパーキングを利用する必要があります。料金、駐車可能台数、停めやすさをまとめています。

2023 今宿花火大会 8/3 20:00 ~

今日(2023/08/03)は今宿花火大会です。注釈にも書いていますが今宿駅前のコインパーキングは一つマンションになっていて停められる車の台数が減っています。ゆっくり来ると停められない可能性があります。

またナフコなど近隣店舗駐車場への駐車は迷惑駐車であり、花火大会終了後には閉店しているお店もあるため車を出せなくなる可能性があります。コインパーキングの利用か、電車での来場がおすすめです。

なお、今宿タイムスによると屋台の出店は7店のみで混雑が予想されます。食事は済ませてから来場されるのが良いでしょう。花火の開始時間は20:00です。

はじめに

長垂海浜公園の松林

福岡市西区の今宿にながたれ海浜公園という砂浜や遊具のある広い公園があります。波が穏やかで海を眺めてぼーっとするには良い公園なのですが(魚釣りをしている人もいます)、駐車場がありません。従って近所に住んでる人だけが訪れるスポットになっています。しかし最近、公園近くにいくつかコインパーキングができ、車でもアクセスしやすくなりました。公園と海に近いコインパーキングを五つほど紹介したいと思います。

なお JR 筑肥線の今宿駅前に広めのコインパーキングがいくつかある*1ので、運転に自信のない方やこれから紹介する駐車場が満車の場合はそちらを利用しても良いと思います。今宿駅から長垂海浜公園までは歩いて 10 分程度です。

コインパーキング一覧

名前 最大料金 駐車可能台数 停めやすさ
ライオンパーク今宿 600 円 5 台
フラットパーク今宿 600 円 7 台(軽・小型専用)
三井のリパーク 今宿駅前一丁目第2 500 円 5 台
今宿駅前1丁目パーキング 500 円 3 台
國﨑真クリニック提携駐車場 300 円(曜日時間限定) 25 台
ワイズパーキング今宿駅前1丁目 500 円 3 台(一台は軽専用)

ライオンパーク今宿

今宿ライオンパーキング今宿ライオンパーキング

唐津街道沿い。 5 台駐車可能です。街道沿いなので車の出し入れはしづらいと思います。右折入庫は難易度高いです。頭から突っ込んで出庫のときにニッチもサッチも行かなくなる可能性あり。必ずお尻から入庫したいものです。

駐車料金

時間帯 料金 最大料金
7:00 ~ 19:00 100 円 / 60 分 600 円
19:00 ~ 7:00 100 円 / 60 分 300 円

駐車可能台数

5 台

出し入れのしやすさ

フラットパーク今宿

フラットパーク今宿フラットパーク今宿

唐津街道沿い。一つ目の今宿ライオンパーキングのすぐ近く。 7 台駐車可能ですが小型か軽専用となっています。横幅が狭いので大きめの車で入庫してしまうと出し入れに難儀しそうです。

駐車料金

時間帯 料金 最大料金
8:00 ~ 20:00 100 円 / 60 分 600 円
20:00 ~ 8:00 100 円 / 60 分 300 円

駐車可能台数

7 台(軽・小型専用)

出し入れのしやすさ

三井のリパーク 今宿駅前一丁目第2

三井のリパーク 今宿駅前一丁目第2三井のリパーク 今宿駅前一丁目第2

唐津街道から少し入った住宅街の中にあります。広めの月極駐車場のうち、手前のオレンジ色の線の部分がコインパーキングで、 5 台止められます。時間あたりの駐車料金は 300 円と天神と同レベル。入庫したら最大料金を支払うつもりで利用するのが良いでしょう。前の道の車通りが少なく、駐車場も広いため出し入れはしやすいと思います。

駐車料金

時間帯 料金 最大料金
0:00 ~ 24:00 300 円 / 60 分 500 円

駐車可能台数

5 台

出し入れのしやすさ

今宿駅前1丁目パーキング

今宿駅前1丁目パーキング今宿駅前1丁目パーキング

三井のリパーク 今宿駅前一丁目第2すぐ近くのコインパーキングです。民家の前庭部分がコインパーキングにしてあり、 3 台駐車可能です。時間あたりの料金はやはり高めです。こちらは紹介するコインパーキングの中で最も出し入れしやすいと思います。運転に自信のない方におすすめ。

駐車料金

時間帯 料金 最大料金
0:00 ~ 24:00 300 円 / 60 分 500 円

駐車可能台数

3 台

出し入れのしやすさ

國﨑真クリニック提携駐車場

國﨑真クリニック提携駐車場國﨑真クリニック提携駐車場

医院併設の駐車場。日・祝日は最大料金の設定がありますが、平日と土曜日の昼間は最大料金の設定がないためご注意ください。100円/20分で非常に高額になる可能性があります。

駐車料金

時間帯 料金 最大料金
7:00 ~ 20:00 (月〜土) 100 円 / 20 分 なし
20:00 ~ 7:00 (月〜土) 100 円 / 60 分 300 円
7:00 ~ 20:00 (日・祝日) 100 円 / 60 分 300 円
20:00 ~ 7:00 (日・祝日) 100 円 / 60 分 200 円

駐車可能台数

25 台

出し入れのしやすさ

ワイズパーキング今宿駅前1丁目

マリブ今宿シーサイドテラスマリブ今宿シーサイドテラス

海辺のシェアオフィスSALTが入居するマリブ今宿シーサイドテラスの駐車場です。こちらも終日 1 時間あたり 300 円で、 500 円の最大料金が設定されています。 3 台駐車可能ですが一台は軽専用です。ちょっと駐車スペースが狭いかな? 人気のパン屋、ヒッポー製パン所に最も近いです。

駐車料金

時間帯 料金 最大料金
0:00 ~ 24:00 300 円 / 60 分 500 円

駐車可能台数

3 台(うち一台は軽専用)

出し入れのしやすさ


以上、長垂海浜公園近くのコインパーキング情報でした。自分自身、今宿で住む場所を探していたときに車を停めて街をゆっくり見て回りたいと思っても車を止められる場所がなく難儀しました。長垂海浜公園や長垂海岸に遊びに行きたいという方のほか、今宿に引っ越しを検討されている方も街探索の際にお役立てください。長垂海岸では以下のような夕日が眺められます。是非海の近くに車を停めて夕日を眺めに来てください。

長垂海岸の夕暮れ

*1: 2021-08-01 更新: 駅前のコインパーキングが一つ減りました。マンション建設中です。また駅前のコインパーキングは以前は 60 分 100 円程度でしたが、現在は 60 分 200 円〜に値上がりしてきていますのでご注意ください。

| @技術/プログラミング

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

現在の 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 でサイト全体を作り直してみたい。

| @ブログ

75 件ほどあった tech.portalshit.net の記事を取り込んだ。実家に住んでいた 10 年前に始めた技術ブログで、最初は Rails 製の Mephisto 、その次に Jekyll で構築した。まだ GitHub Pages の仕組みが存在する前で、自前で用意したさくら VPS に git push すると自動でビルドして記事が公開されるような仕組みを作ったりしてた。

職業プログラマーになろうとしてもがいてた頃にやってたブログで、いま読み返すと「頑張ってたんだな」感があっていなたい記事が多い。

だいぶ放置していて、いまは S3 で静的サイトとして公開していたのでそのまま放置でもよかったが、 10 年前と違って何でも一カ所にまとめて書いておきたいという気持ちが強くなって取り込むことにした。ブログはトピックを混ぜずに一つのトピックにフォーカスした方がよいと 10 年前は考えていたのだけど、最近の世の中のブログ記事の読まれ方は変わってきていて、一人の人のブログをフィードリーダーに登録して読むというより、 SNS をだら見していて流れてきた記事を適当に消費するというスタイルに変わってきているので、一つのブログに一つのテーマという書き分けは不要になったと感じる。

tech.portalshit.net を取り込んだおかげで Archive ページのグラフに占める技術記事の割合が増えた。

Tech category Bar extension

ちなみに取り込みは以下のようなコードを書いて SQL の INSERT 文に変換した。

require 'yaml'
require 'pathname'

files = Dir.glob(File.join(__dir__, '_posts', '*.markdown'))
files.each do |file|
  content = File.read(file)
  _, header, body = content.split('---')
  header_yml = YAML.load(header)
  title = header_yml['title']
  tags = header_yml['category']
  tags = tags.is_a?(Array) ? tags.map(&:downcase) : [tags&.downcase]
  slug = Pathname.new(file).basename.to_s.sub(/\d{4}\-\d{2}\-\d{2}\-(.+?)\.markdown/, '\1').gsub('_', '-')
  body = body.strip.gsub(/\n/, "\\n").gsub('\'', '\'\'')
  created_at = File.birthtime(file).to_s.sub(' +0900', '')
  updated_at = File.mtime(file).to_s.sub(' +0900', '')
  puts <<~EOS
    INSERT INTO entries(title, user_id, category_id, slug, markup, type, draft, body, frozen_tag_list, created_at, updated_at) VALUES('#{title}', 1, 6, '#{slug}', 'redcarpet', 'Post', 0, '#{body}', '#{tags.join(',')}', '#{created_at}', '#{updated_at}');
  EOS
end

| @技術/プログラミング

DataMapper のドキュメントを見たくてググったが出てくるのは Stack Overflow ばかりで公式サイトが検索結果に出てこない。 GitHub の DataMapper のリポジトリ( Archive されている)経由で見に行ってみると、なんと ROM ( Ruby Object Mapper ) のページにリダイレクトされた。

ROM は Hanami で使われる ORM で、 DataMapper よりもさらに ActiveRecord と使い心地が異なる。

Qiita の以下の記事を読むと使い方のイメージが湧く。

軽くてシンプルなのだろうがだいぶ特殊だ。

Lokka の使い手は少なくとも Heroku が使える人で、そういう人ならば ActiveRecord の方が Rails の本やドキュメントで学びやすいはずだ。というわけで早めに、真剣に ActiveRecord への移行を考えなければならない。