※1. この記事は「KLab Engineer Advent Calendar 2023」の 6 日目にエントリしています

以前つくった Haskell 製の LINE Bot を家族の所属するグループ LINE に参加させて日常的に活用している. ごみ出しの項目確認や買い物リストのメモなど, 家族間のコミュニケーションや生活の流れの中でぱっと済ませたい諸々の事柄を LINE という定常的に利用するツールの中で自動化することで, 当初よりも細かい点で便利になった感触がある. これは LINE Notify のみでは実現できない双方向のやりとりや LINE というプラットフォームを最大限活用できる拡張性によるものだ.
ところで, 我が家のインフラの一部は東京ガスに依存しているわけだが, 東京ガスは, その毎月の請求額の確認通知を指定のメールアドレスあるいは myTOKYOGAS と連携の LINE へ送信するサービスを提供している. 私は以前からどちらのサービスも利用していたが

1. メールに気付かず, 請求額の把握が遅れる
2. LINE への通知が自分宛てのみとなるので, 自分を経由して家族と情報共有する必要がある

という問題があった. 2 については, 家族全員がそれぞれの LINE アカウント上で myTOKYOGAS と連携すれば良いのでは？と思うかもしれないが, これはサービスの仕様上単一のアカウントのみ連携ができるようになっているので不可能である. 別の方法としては, LINE Notify をグループ LINE に招待しその API を叩くようにすれば, わざわざ LINE Bot に機能追加をしなくても済むが

• 情報によって異なる発信源からメッセージが飛んでくるのは統一感がなく”気持ち悪い”
• 別口の API を一度実装してしまえばこの用途以外でも様々な目的に対して流用できる

という点から LINE Notify を利用して実現しようとはせず, 自分で実装することとした¹. 本エントリの扱う機能追加についての差分は下記の PR のとおりである.

最近ブログを更新していないことに気づいたのと

日本語で Haskell Servant の具体的な活用例を示すことにはそれなりの価値があるかもということ, 同じようなことを実現して生活を楽にしたい方がいるかもということ, など文章生成 AI に尋ねてもどうもはっきりとした解答が得られなかったときのために, あるいは文章生成 AI にこのエントリが食われるために？備忘録を兼ねて綴ることとした.

普段業務外では LINE 株式会社 (以下 LINE 社) が提供する LINE というメッセンジャーアプリ上でやり取りをすることが多いので, そのインタフェース上で色々と動かせたりするとそれなりに便利かもと最近思い始めた. そこで, 筆者の考える基本的な機能を備えた LINE Bot を一旦作ってみることとした. 本エントリはその備忘録である. 下記のリポジトリに成果物を公開している.

基本構成

今回は個人利用/小規模であり特別な費用を発生させたくなかったので, Oracle Cloud Infrastructure (以下 OCI) の Always Free 枠である Ubuntu インスタンス上にサーバを構成した¹. 同インスタンス上では Jitsi Meet² という別のウェブサービスを nginx を用いて運用していたので, それをそのままリバースプロキシとしても利用し, Bot サーバへの通信を HTTPS 化した. これらはサブドメインに従ってリクエストを振り分けているが, それぞれの SSL 証明書を作成するのは手間がかかるので, 今回は (let’s encrypt の) ワイルドカード証明書で管理することとした. ドメイン管理には Google Domains を使っているが, TXT レコードを随時更新する API が用意されておらず, 現状手動更新が必須となっている. これは追々なんとかしたい³.

技術書典 11 に出展の KLab Tech Book Vol.8 第七章にて『ミニマル Git を自作しよう』という記事を執筆した. 技術書典 11 オンラインマーケットから電子 + 物理本セットは 1000 円, 電子版のみは無料で頒布されている.

この本に関する公式的な案内は『技術書典11で同人誌を頒布します & 既刊PDFダウンロードページ』にて掲載中である. 本記事は, その記事執筆に関するレポートである.

※1. この記事は「KLab Engineer Advent Calendar 2020」の 16 日目にエントリしています
※2. 普段のこのブログの文体は常体ですが, 本記事においては Advent Calendar 用に敬体を使用します

はじめに

この記事の公開日の 1 日前¹に, プログラミング言語 C++ の新バージョン ISO/IEC 14882:2020, 通称 C++20 が国際標準として公開されました. これにより, いくつかの新しい言語機能や標準ライブラリが追加されます. その中でも, とくにコンセプトという言語機能は, テンプレートメタプログラミングが話題として盛んであった時代²から待望されていた言語機能のうちの 1 つなのではないでしょうか. この標準化によって, C++17 までで行う必要のあった多くの型制約のためのテンプレートメタプログラミングは, よりそれ専用の言語機能であるコンセプトを使う形に置き換えられるであろうと思われます. そのようなわけで, 今後徐々に出番を失っていくであろうテンプレートメタプログラミングを将来懐かしめるよう (?), テンプレートメタプログラミングによってコンパイル時に Lazy K ソースコードをパースして評価するインタプリタのようなものを書いてみました. 本記事では, これに関する実装と理論について紹介します. (型無し $\lambda$ 計算について既知のものとします)

旧個人ページ及び, 旧ブログを本ウェブサイト (roki.dev), 本ブログ (roki.dev/roki.log, roki.dev/roki.diary) に移行した. 以下では, 移行した経緯や技術的概要, 本サイトおよびブログの方針について (ゆるく) 紹介したい.

移行に至った経緯

移行前の旧ブログ¹の構成では, static site generator である pelican を使っていた. 以下に, それを使ってそこそこの期間の運用をした上での実状, 感想を挙げる.

• テンプレートやプラグインが充実しており, 設定も非常に少ない記述から簡潔に行えるようになっていて, 主観的な感想として pelican は使い勝手の良いツールであった. 自分の場合は, nikhil-theme を元に拡張して利用しており, いくつかの機能の追加実装や bug fix, 依存関係の更新作業などを行っていた
• 記事の執筆は Markdown で行い, D3.js や emscripten を導入していたので, 記事内で簡単なシミュレータや計算の視覚化などでヌルヌル動かしたり, 遊んだりできるようにしていた
• 執筆時には MathJax が意図通り描画できているか等で瞬時にプレビューを見たかったため, 記事内の更新に合わせて記事のリビルド, ブラウザの自動リロードがされるスクリプトを作り, それを実用していたのでブログ記事執筆時のストレスもそこまではなかった
• 全体のブログ記事管理の仕組みとして, draft から release ブランチに merge & push すると, Bitbucket Pipelines が走り², ブログのビルドと GitHub pages へのデプロイが実行されるようにしていたので, 管理コストや記事公開のための作業も少なく, その点は快適であった
• その他の細かい作業 (旧ブログ記事) を行うことで”色々とそれなりに”便利にしていた

…とこれまでを振り返ると, あまり不満はなかったのではないかというような気がしてくるが, 全く不満がなかったかというとやはりそうではない.

• 元テンプレートの Bootstrap のバージョンが低い
• MathJax が重い
• テンプレートが膨大
• 標準 (プラグイン) の検索機能が日本語に未対応
• リンクのバリデーション機能がない
• 無料 GitHub アカウントでもプライベートリポジトリが使えるようになり, Bitbucket と GitHub 間を横断させる必然性がなくなった (GitHub Actions も使えるようになったことで, ブログ管理のすべてを GitHub のみで一元管理できる)
• 記事や記事内で使うスクリプトを校生するもの (textlint の linter 等) と, ブログそのもの (Jinja2 テンプレート, ビルド, デプロイ, ライブプレビュー, プラグイン管理…) は全くの別物なので, これらの管理を分離したい

無論, 元のブログでも修正, 更新, 機能追加でこれらをすべて満たそうとすることはできるが, もうそこまでするならいっそのことリニューアルしてしまったほうが…🤔となってしまった.

ブログの他にも, 個人 (プロフィール) サイトを公開しており, それにおいては Typescript + React を使って構築していた³. こちらは特に何か変わったこともしていないので, 特筆すべきトピックもないのだが, そこまで DOM 操作をするわけでもないプロフィールページにこれらの技術を用いたのはオーバースペックだったし, bundle.js の重さからしてもあまり理にかなっていなかったように思う.