portal shit!

去年（ 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 でたまにバズったときだけ読んでもらえる、ソーシャルメディアの肥やしにしかならない。

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

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

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

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

https://blog.kksg.net/posts/slack-status-emoji/

blog.kksg.net

必要なもの

• Touch Bar のある MacBook Pro
• 9m さんの gist と Slack の API Token
• BetterTouchTool

準備

1. Slack の API Token を発行する

その仕事、Slack で。

Slack のことを学べるようサポートします。役立つ記事やビデオのコレクションを参照して、質問の答えをすばやく見つけましょう。

slack.com

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 "🍺" "退勤しました"

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

3. 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 をカスタマイズする

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

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

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

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

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

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

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

今後の課題

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

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

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

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

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

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

http://www.itoshima-kanko.net/cat/nigi_beach/

www.itoshima-kanko.net

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

はじめに

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

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

コインパーキング一覧

ライオンパーク今宿

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

駐車料金

駐車可能台数

5 台

出し入れのしやすさ

△

フラットパーク今宿

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

駐車料金

駐車可能台数

7 台（軽・小型専用）

出し入れのしやすさ

△

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

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

駐車料金

駐車可能台数

5 台

出し入れのしやすさ

〇

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

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

駐車料金

駐車可能台数

3 台

出し入れのしやすさ

◎

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

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

駐車料金

駐車可能台数

25 台

出し入れのしやすさ

〇

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

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

駐車料金

駐車可能台数

3 台（うち一台は軽専用）

出し入れのしやすさ

〇

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

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

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

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

Jekyll のデプロイ手順を改めた

だいぶ前の記事では Jekyll は Git の hook を使って公開してると書いてた。 Gitのhookを使って...

portalshit.net

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

インスタンス変数

一個前の記事（Rubyがエレガントだって言われるのがわかってきたような気がする | tech.portalshit.net - CakePHP, Rails, JavaScript）をcxxさん...

portalshit.net

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

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

ちなみに取り込みは以下のようなコードを書いて 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