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

いろいろスパム対策は行っているもののやはりまだスパムが届くので NG ワードの設定を簡単に行えるようにした。こんな感じ。

NG ワード設定

これまで一つのテキストフィールドにカンマ区切りで入力しないといけなかったのを、フィールドを分けて単語ごとに入力できるようにした。

モダンなやり方はしてなくて全部サーバーサイドの Ruby でやってる。動的に新規登録フィールドを増やしたりはできない。新規登録したいときは都度都度フォームを保存する必要があるが、十分速いので実用上は全く問題ない。

同様に、スパマーの餌食になっている過去記事のコメント欄を閉鎖する機能も便利にした。

コメント欄を閉じる記事の設定

仕事では全然プログラミングしていないので久々にコードを書いた。

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

シダの新緑

最近、ブログに Amazon アソシエイトの広告が表示されなくなっていた。記事の新規公開時だけでなく、最新の価格情報を取得するため 24 時間のみキャッシュして都度新しいデータをとるようにしていたが、商品が 30 日間売れなかったため API へのアクセス権を剥奪されてしまったようだ。アフィリエイト報酬がもらえないのもさみしいが、それよりも記事に商品の画像を表示出来ないのが悲しい。結構頑張って仕組みを作ったのに。

ドキュメントには以下のように書いてあった。

Note that your account will lose access to Product Advertising API 5.0 if it has not generated referring sales for a consecutive 30-day period.

API Rates · Product Advertising API 5.0

これはかなりきびしい。 30 日間でものが売れないことなんてザラにある。 ものが売れない -> API のアクセス権剥奪 -> 商品情報取得できない -> ものが売れない の負のスパイラルに陥ってしまうので基本的には抜け出すことはできない。

Google Adsense といい、個人の泡沫ブログで小銭を稼ぐのがどんどん難しくなっていく。

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

最近 Vim をインストールし直したところ起動時にエラーが出るようになった。 deoplete.nvim (補完プラグイン)関係のエラーだ。

Error detected while processing VimEnter Autocommands for "*"..function deoplete#enable[9]..deoplete#initialize[1]..deoplete#init#_initialize[10]..<SNR>134_init_internal_variables[34]..VimEnter Autocommands for "*"..function deoplete#enable[9]..deoplete#initia│D, [2020-10-24T06:03:29.034369 #21401] DEBUG -- :   Option Load (1.9ms)  SELECT  `options`.* FROM `opti
lize[1]..deoplete#init#_initialize[10]..<SNR>134_init_internal_variables[28]..neovim_rpc#serveraddr

何度か python3 をインストールし直したりしてみたが直らず途方に暮れていたところ、 brew edit vim してみて理由がわかった。普通に brew install python3 すると python@3.8 がインストールされるが、 Homebrew の Vim は python@3.9 に依存してた。なので Vim 内から呼び出される python3 は python@3.9 である必要があるようだ。 python@3.9 は keg only で /usr/local/bin 以下にシンボリックリンクを張ることができないのでシェルの設定ファイルでパスを通してやる必要がある。自分は fish の設定ファイルに以下のように記載した。

set -g fish_user_paths "/usr/local/opt/python@3.9/bin" $fish_user_paths

これで起動時のエラーはおさまった。が、 Vim が依存する python3 と Homebew で入る python3 のバージョンが異なっているのはハマりポイントだと思った。

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

Vim の設定に関してはペパボ時代に同僚のみなさん( glidenote さん、 banyan さん、 linyows さん)から色々学んでほぼほぼ不満がない状態になっている。正規表現拡張の eregex.vimrails.vimprojectionist.vimvim-surround など tpope プラグインと Shougo プラグイン( unite, vimfiler あたり)で普段のユースケースはカバーされているが、 EasyMotion というプラグインの存在と、同じ人がメンテしている incsearch.vim というものがあることを知って入れていみた。カーソル移動を楽にする Vim プラグインのようだ。これまで ⇧wf⌃d などで高速移動はできるといえばできるが、空白や単語の切れ目ではない位置を狙った移動では結局 hl を連打してしまっていた。 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 でサイト全体を作り直してみたい。

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

Chart

Rechars という React のチャートライブラリを利用して、 Archive ページにカテゴリーごとに記事を集計してグラフ化する機能を作った。

グラフの Bar にカーソルを載せると Tooltip が表示されて、具体的な件数がわかる。

Chart Tooltip

カテゴリごとに表示・非表示を切り替えることも可能。グラフ下のカテゴリー名( Legend )をクリックして切り替えられる。

Chart Show-Hide Toggle

ただし残念なことに Bar を非表示にしたときに Legend の表示を変化させるのが難しくてできていない。

仕事で使ってる Looker とか Redash であれば Legend をクリックして表示・非表示を切り替えることができ、それに連動して Legend の色をトーンダウンさせたりする機能が付属しているが、利用した Recharts にはその機能がなかった。 Bar の表示・非表示切り替えも標準サポートされていなかったので、 GitHub の Issue の情報を頼りに無理矢理実装した。

コードはこんな感じ。結構汚い Hack で、 Bar の表示・非表示を、表示用のキー文字列に空白を追加するかしないかで切り替えている。

  // クリックされたアイテムが `this.state.disabled` 配列の中にすでに存在していれば除外し、
  // 存在してなければ追加する
  selectBar(event) {
    let dataKey = event.dataKey.trim()
    if (this.state.disabled.includes(dataKey)) {
      this.setState({ disabled: this.state.disabled.filter(item => item !== dataKey) })
    } else {
      this.setState({ disabled: this.state.disabled.concat([dataKey]) })
    }
  }

  render() {
    return (
      <ResponsiveContainer height={500}>
        <BarChart
          data={this.state.data}
          margin={{
            top: 20, right: 20, left: 0, bottom: 20,
          }}
          style={{ fontSize: '14px' }}
        >
          <CartesianGrid strokeDasharray="3 3" />
          <XAxis dataKey="year" />
          <YAxis />
          <Tooltip labelStyle={{ color: '#000', fontWeight: 'bold' }} itemStyle={{ margin: '0 2px 0 4px', padding: '0' }} />
          {// Legend クリック時のコールバックに `this.selectBar` を指定する }
          <Legend onClick={this.selectBar} />
          {/*
            `this.state.categories` 配列と `this.state.disabled` 配列の内容を比較し、
            `this.state.disabled` に追加済のカテゴリーは dataKey に空白を追加することで非表示に
          */}
          {this.state.categories.map((category, index) => {
            let dataKey = this.state.disabled.includes(category) ? category + " " : category
            let color = this.colors[index % this.colors.length]
            return(<Bar key={index} dataKey={dataKey} stackId="a" fill={color} />)
          })}
        </BarChart>
      </ResponsiveContainer>
    );
  }

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

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

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

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

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

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