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

MySQL だけでお手軽に全文検索ができるということを知らなかった。 MySQL 5.6 から入っていたようだった。 Tantivy および Tantiny を使ったやり方を以前記事に書いてサイトで実装しているが、 MeCab によるトークナイズでは二文字の熟語がセットになって四文字になっているようなパターンを取り逃すことがあった（「関連記事」は「関連」と「記事」に分割され、「関連」や「記事」というキーワードで検索したときにはヒットするが「関連記事」で検索するとヒットしない）し、記事追加時の検索インデックス更新処理が不要（ MySQL にレコードが追加されたときに勝手に更新される）なので試してみることにした。

やり方は以下の記事を参考にした。

最初にデータベースに全文検索用のインデックスを作成した。

ALTER TABLE `entries` ADD FULLTEXT INDEX index_entry_fulltext(title, body) WITH PARSER ngram;

その後、検索部分のコードを書き換えて以下のようにした。

class Entry < ActiveRecord::Base
  scope :search,
        ->(words) {
          return all if words.blank?
          where('MATCH (entries.title, entries.body) AGAINST (? in BOOLEAN MODE)', words)
        }
end

めっちゃ簡単。

このブログは記事数が 1500 記事くらいなのでぶっちゃけ LIKE 検索でも実用的な速度（ 100msec 以内）で結果を取得できるが、 FULLTEXT インデックスを使うと 10msec 程度で結果を取得できる。

ただし Tantivy と比べて劣る点もあって以下は注意が必要。

  1. なぜかわからないが Vim で検索すると何もヒットしない。また Rails で検索すると Rails について触れていない記事もヒットする。 ngram によるインデックスというのはこんなものなのかもしれない。検索ワードが日本語のときはいい感じに結果が表示される。
  2. 複数のテーブルにまたがるデータを一個の検索インデックスにまとめることができない。例えば Tantivy のインデックスは記事のタイトル、本文、カテゴリー、タグをインデックス対象としているが、 MySQL の FULLTEXT インデックスだとテーブルごとにしかインデックスを作れないので（当たり前）、複数のテーブルにまたがる検索をするときにはテーブルを JOIN するしかない。 OR マッパーを使っている場合には利用しづらい。

1 の問題に関しては、 MySQL 5.7 からインデックス生成時の PARSER に MeCab などを指定できるようになったのでそうすると回避できるかもしれない。ただし MeCab のインストールや設定を行う必要があるので要注意。

2 の問題に関しては全文検索システムを入れた方が良さげ。 Tantivy であれば非常に簡単に導入できる。

現状、このサイトでは右上の検索窓から検索したときのインクリメンタルサーチとアーカイブページでの絞り込みは Tantivy を、インクリメンタルサーチの結果で必要な情報が得られなかったときの「全文検索する」と 404 Not Found ページの検索は MySQL の全文検索を使うようにしている。

二つの検索

| @WWW

Basecamp で従業員の大量離職騒動が起きていた。原因は社内で社会問題についての議論を禁止するという制度変更への反発。

この制度変更の背景にはさらにややこしい問題があったようだ。

この騒動を経て、以前 HEY を使ったときの感想として書いた以下の記事のことを思い出した。

ソフトウェアに必要なのは理念ではなく機能だ。そのことは Jason Fried も書いている。

6. No forgetting what we do here. We make project management, team communication, and email software. We are not a social impact company. Our impact is contained to what we do and how we do it.

ただ、 Jason Fried も DHH も本、 Twitter 、ブログで業務の一環かのように他社のソフトウェアやビジネスモデルに難癖を付けたりと舌鋒鋭い。その一方で従業員に社内で社会問題を議論をさせないのは矛盾しているような気がする。

以前書いた記事では、 Flickr は理念のみで機能が不足しているということを指摘した。 Basecamp の HEY については理念だけでなく、それを裏付ける機能があると支持した。しかし今回の騒動を見るに、理念の部分がだいぶ強すぎたと感じる。理念に引き寄せられて opinionated な人たちが集まったが、理念を表明して良いのは経営者だけで従業員は仕事だけして下さいと言われると反感を買うのは当然だろう。

理念や社会に対する意見があることは結構なことだと思う。しかしそれを声高に表明して回ることはソフトウェア会社の仕事ではないと思う。ソフトウェア会社の仕事はただ一つで、その理念に基づいたソフトウェアを作ることなはずだ。

そもそもソフトウェアで社会を変えられるのだろうか。自分はそうは思わない。世の中がソフトウェアをきっかけにして変わるだけだ。ソフトウェアは人々の内側にあった曖昧模糊とした欲求を具現化して解消しただけに過ぎない。 Uber で車と時間を持て余している人がお金を得られるようになったし、全然タクシーがつかまらなくて困っていた人はふっかけられることなく車で移動できるようになった。これは元々潜在的に存在していた需要と供給を顕在化させて結び付けただけだに過ぎない。どんなに画期的なソフトウェアやサービスも、人々に必要だと思われなければ意味がない。

崇高な理念や信念があったとして、それをいかにソフトウェアに吹き込むかがソフトウェア企業のやるべきことだ。自分は Rails エンジニアとしてソフトウェア業界に橋頭堡を築いたので DHH のことは尊敬しているけど、 Basecamp には人々に求められる良いソフトウェアを作ることにフォーカスして欲しいし、自分もそういう姿勢でソフトウェア開発に携わっていきたい。

| @Mac/iPhone

"Your Computer Isn't Yours" という記事が先週バズってた。

概略を説明すると、 Catalina の頃から Apple が Mac ユーザーのアプリ起動ログを勝手に収集していたが、 Big Sur の公開日にログ集約サーバーがダウンしてしまい、そのせいで Mac を使えなくなる人が続出して問題が発覚したというもの。 Rebuild の Episode 288 で触れられているので興味がある人は聞いて下さい。

この記事については日本語の翻訳もあってはてブで 500 ブックマークくらいついていたが、どうも機械翻訳されただけのようだったし、一部訳が違うのではと思われるところがあったので自分でも訳してみた。訳を原著者の Jeffrey Paul 氏にメールで送ったので恐らくそのうち本家に日本語訳が追加されると思う。

Your Computer Isn't Yours

2020-11-25 9:16 追記

日本語訳追加してもらいました。

起きていることをまとめると以下のような感じだ。

  1. Apple は Mac ユーザーのアプリ起動データを IP 付きで Apple のサーバーに集めている（ログ送信）
    • 各アプリの署名有効期限チェックやマルウェア対策のためということになっている
    • Mac から Apple への通信は暗号化されていない
      • ISP や CDN （ Akamai ）、ネットワークを盗聴している他人が内容を確認可能
    • この通信はユーザーが自分の意思で無効化できない（「Mac解析を共有」をオフにしても送信される）
  2. Mac （特に Big Sur でしか動かない Apple Silicon Mac ）を使いたければ利用ログ送信を甘受するしかない
    • Big Sur から、上述のログ送信や Apple 製のアプリは VPN やファイヤウォールを無視するようになった
    • OS の挙動を変更しようとすると Mac が起動しなくなる
  3. iCloud Backup は iMessage の秘密鍵も一緒にバックアップするので Apple がメッセージの内容を読むことができる
    • 自分自身が iCloud Backup 利用していなくても、メッセージの送信相手が iCloud Backup を使っていると自分が送ったメッセージが iCloud 上に保存される
  4. Apple はプライバシー保護を売りにしながらユーザープライバシーをなおざりにしている
    • iMessages/iCloud Backup のバックドアを放置している
    • 過去にアプリ開発者には HTTPS を強制しながら自分たちは OCSP の通信を平文で行っている
    • ログ送信の件について対応を発表したが、対応時期を明確にしていない

その結果、以下のような状況に陥ることが懸念されている。

  • Apple が集めている情報は NSA や FBI に筒抜けになる
    • Apple はアメリカ軍の諜報機関や FBI にユーザーログデータなどの閲覧を令状なしで認める協定を結んでいる
    • iCloud Photo や iMessage の内容を Apple だけでなく軍や FBI も見られるようになっている
  • ユーザー保護を隠れ蓑に Apple が力を増大させる
    • マルウェアから守る、を大義名分にして、ユーザーがどのアプリを動かせるかを Apple がコントロールできる可能性がある
    • 原理的には Apple が気に入らないアプリを起動できなくしてしまうことが可能

モバイルアプリの利用状況の収集は多分いろんなアプリがやっている。 Mac で Apple が集めている程度以上の情報を集めているアプリも多いだろう（位置情報を取得しているアプリなど）。なので最初この件については過剰に反応しすぎなのではないかと思っていたが、よくよく考えてみると自分の感覚の方が麻痺していたのかもしれない。アプリの利用履歴を IP アドレス付きで送るということは、どこで何をしているかがアプリ開発者に筒抜けだ。そしてそのログを公権力が自由に閲覧可能だとしたらいい気持ちはしない。

アプリと Apple の場合で決定的に異なるのは、アプリはそのアプリが起動している間（あるいはバックグラウンドでのログ送信を許可されている間）だけログを送信するが、 Mac に関して言うとずっーっと起動しっぱなしで使い続けるものなので、ログデータからユーザーの行動履歴・生活様式がわかってしまう。地図アプリで検索した場所の情報も送られていたということなので、 Jeffrey Paul 氏が書いているように、その人がこれから行く予定の場所もわかってしまう。

GDPR や様々なプライバシー保護は、アプリを作りサービスを運営する側としては正直厳しいなと思うところはあるけど、 Apple がアメリカ軍と結んでいる PRISM のような取り決めが存在すると、様々な個人情報が政府機関に流れてしまって、アメリカのサスペンスドラマのように個人の位置情報を携帯の使用履歴からいとも簡単に割り出せるようになってしまう。それはやはり恐ろしい世界だ。

プライバシーの侵害のみならず、プラットフォーマーである Apple の匙加減次第で、ユーザーが使えるアプリが決まるという状況も好ましくない。たびたび iOS の App Store で起こる Apple の恣意的な審査基準改変などはその一端だ。 Hey の件で Apple とやり合った DHH は痛烈に Apple を批判するとともに、かつて邪悪な Microsoft に対抗するための救いとも言えた Apple が以前の Microsoft 以上に邪悪になってしまったのが嘆かわしいと Twitter に書いていた。学生の頃、 Mac を広める活動をやって大学のクラスの半分の同級生のラップトップを Mac にしたというエピソードや、 Rails の開発でも Mac を激推ししたという話は胸熱だった。応援してきた Apple が Evil になってしまい、人一倍残念に思っているのだろう。

Apple はかつて "The computer for the rest of us" というコピーで Macintosh を宣伝していた。しかし今日、 Mac は彼らのコンピューターになってしまったのだ。

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

Vim の設定に関してはペパボ時代に同僚のみなさん（ glidenote さん、 banyan さん、 linyows さん）から色々学んでほぼほぼ不満がない状態になっている。正規表現拡張の eregex.vim 、 rails.vim 、 projectionist.vim 、vim-surround など tpope プラグインと Shougo プラグイン（ unite, vimfiler あたり）で普段のユースケースはカバーされているが、 EasyMotion というプラグインの存在と、同じ人がメンテしている incsearch.vim というものがあることを知って入れていみた。カーソル移動を楽にする Vim プラグインのようだ。これまで ⇧w や f 、 ⌃d などで高速移動はできるといえばできるが、空白や単語の切れ目ではない位置を狙った移動では結局 h や l を連打してしまっていた。 EasyMotion は冒頭の数文字を検索すると飛び先をアンカー表示してくれて、高速にファイル内を移動できるというもの。 Unite のファイル内ジャンプ版という感じかな。

さらに調べると incsearch.vim の方は Vim 本体に取り込まれたみたいで必要ないらしいのだが、 ⇥ で検索にヒットしたカ所を移動したりする機能は incsearch.vim の機能っぽいので両方セットで使ってみることにした。 EasyMotion は incsearch と組み合わせて使うことでかなり便利になるっぽい（ブリッジに haya14busa/incsearch-easymotion.vim が必要だ）。こんな感じ↓（画像は incsearch-easymotion のリポジトリから拝借）

incsearch-easymotion demo

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

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 への移行を考えなければならない。