| @散財

自粛期間中、宗像にある GRiPS というアウトドアショップのホームページをずっと見てた。

GRiPS は冷やかし入店や子連れ入店お断りの店で非常に怖いところなのだが品揃えは良くて、商品紹介を兼ねたブログにはハンモックハイキングの様子がたくさん載せてあり、めっちゃハンモックハイキングに興味出てきて給付金で AXESQUIN のウキグモ Light を買ってしまった。

ウキグモ Light 、表裏逆に取り付けてしまっている…

ハンモックハイキングの良いところはテントや寝袋がいらないところだ。テント泊でないおかげでグラウンドシートやマット、ペグ、ポールなどが不要になりそれだけ身軽になる。しかもテントで寝るよりハンモックで寝る方が快適らしい。もちろんハンモックを張るには木が必要なので森林限界を超えた地点で野営することはできないが、九州の山は全部森林限界以下なので問題ない。

そのほかにも GRiPS のブログに影響されてしまい、ウルトラライトハイキングに興味出てきてアルコールストーブなどを買ってしまった。

VARGO ヘキサゴンウッドストーブと EVERNEW アルコールストーブ。天気が悪くて山に行けないのでベランダでラーメン茹でて食べた。

登山時の熱源にはガスバーナーを持っていたが、ガス缶はかさばること、残容量が読めず残りわずかになってきたら満タンの缶と残り少ない缶の二つを持つ必要があること、またそもそもガス缶が登山用品店でないと購入できないことがデメリットだった。アルコールストーブはコンパクトでパッキングしやすいし、残量が確認しやすく必要なだけの量を持っていくことができる。また足りなくなったら近所のドラッグストアでサクッと購入できるので、わざわざ燃料を調達するために街のアウトドア用品店まで出かけなくても良い。

色々道具がそろってきたので近所の山でオーバーナイトハイクをやってみたいのだけど梅雨に入ってしまって出かけられずもどかしい。

さらにいまはエバニューのチタンクッカーと蒸し皿が欲しいところ。↓の記事を見たら絶対に真似したくなる。

山で小籠包やってみたい。

| @読書

Kindle Paperwhite 10th Generation

Kindle Paperwhite 初代をずっと使っていた。 7 年くらい使っていてまだまだ使えそうだったが、ページ送りが遅いのと本体容量が少なくて、新しい本を追加できなくなってきてたのでセールのタイミングを見計らって買い換えることにした。

新しい Kindle Paperwhite 、ホーム画面がダッシュボードというか商品カタログっぽくなっていて一見すると良いのだが、常に自分が Wishlist に入れている本や話題の本が表示されてしまって目移りしてしまう。自分は結構注意力散漫で本も一冊を粘り強く読むのではなく、つまみ読みしてはまた別の本に目移りし、というタイプなので、 Kindle を開く度に他のおもしろそうな本の表紙が目に入ると、それまで読んでいた本そっちのけで新しい本のことを調べてしまう。

そういうわけで折角 Kindle を買い換えたのに全然本を読了できていない。自分の場合は買い換えずに不便な初代 Kindle を使い続けていた方が良かったのかもしれない。

追記

Twitter で @nagayama さんから設定で消せるという情報をもらった。クソみたいな記事でも書くことで情報がもらえて便利だった。まさに #100DaysToOffload の効能だと思う。

| @ブログ

天山七曲峠登山道

表示していた Google Adsense の広告を外した。自動広告をオンにすると本文の途中など意図しないところに広告が掲載されまくってしまって大分読みづらい。かといって記事下に入れる程度だとまったくクリックされなくて貼ってる意味がなかった。加えて、ここ一年間で数度行われた Google のコアアルゴリズムアップデートで検索流入が 1/3 くらいになってしまって PV が激減してしまった。 Google としてはどこの馬の骨とも付かない個人がやってる泡沫ブログにトラフィックを流してインターネットの果実を分け与えるつもりはないのだろう。 Adsense 広告の読み込みでサイトの読み込み速度も少し遅くなっていたし大分すっきりした。

消した理由で一番大きいのはアルゴリズムやリターゲティングによる広告のむなしさだ。 Amazon アフィリエイトなど自分の意思でレビューしたり紹介したアイテムの広告ではない広告が自分のブログに表示される必然性はない。アルゴリズムやリターゲティングによる広告は、掲載される場所はどこでもよくて、たまたま空いてたから表示されました、というような間に合わせ感がある。自分が楽天で見た商品の広告が自分のブログに延々表示される様を見て、こういう広告を表示し続けることで自分のブログの価値が毀損されているような気がしてきた。一つ前の翻訳記事がバズって結構アクセスがあったが、翻訳元のブログには広告が表示されていないのに翻訳した自分のブログには広告が表示されていて、自分が広告を入れていることで元の記事の価値も下げているような罪悪感もあった。

元からブログで儲けようとは思っていなかったが、ブログを書くことで得られる一番の利益というか目的は、広告によって小銭を稼ぐことではなく、ブログを書くことで自分自身の価値を高めることだと思う。ブログによってインターネット上でのプレゼンスを高めて知名度を獲得したり、ブログを書いたり運用したりすることで技術的な知見を得てスキルアップにつなげられる。それらを自分の給料に上乗せできるような仕組みを作っていくことが大切なのかなと思った

| @写真

Flickr の Pro プランの有効期限が今月末で切れるので念のため全データを DL しておいた。自分は 2007 年に車上荒らしにあって PowerBook 17" を盗まれてしまい、そこに保存しておいたそれまでの人生のデジタル写真もすべて失ってしまった。一部は Flickr にアップロードしておいたので、それらを Mac 上に取り込むのが目的。 Flickr はちゃんとしていて、データの DL リクエストをすると一日くらいで画像だけでなく文章はコメント含めて全部 DL できるようになってる。 GDPR 便利。

何枚かの写真はアップロード時に縮小されてしまっていて、 5K のディスプレイで見るとかなりちっちゃい。試みに image upscale などでググってみると以下の Web サービスが見つかった。

最大 4 倍までアップスケールできる。利用にはアカウント登録が必要だった。無料っぽいので試してみた。アップロードしたのは以下の写真。この写真は 800×600 の解像度でしか落とせなかった。

VW Golf 2 GTI

それがこうなった。ぱっと見綺麗。

VW Golf 2 GTI Upscaled

ただし拡大してみると欠点がないわけではなかった。こんな感じ。

Deep Image Drawbacks

暗い部分、光が反射している部分は綺麗にアップスケールできないみたいだった。機械学習モデルが進化するとこの辺も綺麗にアップスケールできるようになるのかな。

変換の方法はファイルを都度アップロードする方法のほかに、 Google Drive にファイルを置いてディレクトリ指定で一括変換したり、REST API も用意されていて、 curl や自分でプログラムを書いて変換させることも可能っぽい。なかなか便利そう。

なおこのサービスは無料で使えるのは 5 枚までで、それ以上はサブスクリプションか都度払いでお金がかかるシステムのようだ。

Deep Image Pricing

Flickr から落とした低解像度の写真が何枚かあるので都度課金かサブスクリプションの単月契約で利用してみようかなと思ってる。

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

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

| @Mac/iPhone

リモートワークをするようになって会社から貸与されている MacBook Pro の本体キーボードを使うようになった。普段、会社には私物の 4K ディスプレイと Happy Hacking Keyboard を持ち込んで外付けキーボードと外部ディスプレイの組み合わせで仕事をしているが、在宅に切り替えるタイミングで MacBook Pro 本体だけ持ち帰り、キーボードやディスプレイはオフィスに置きっぱなしにしていた。本体のキーボードを使うようになったことで、キーが引っ込んだまま戻らなくなる例の問題に遭遇するようになった。

修理を依頼しようと Apple のサイトを覗いてみると、緊急事態宣言の影響か配送による修理受付は停止しているようだった。

しょうがないので修理は諦めて外付けキーボード使いたいのだけど、家に USB-C への変換用ドングルがなく困ってる(ドングルも会社に置いている)。 15 インチの画面もなかなか厳しいので iMac の画面を使って仕事ができないかと思ったが、自分が持っている iMac はターゲットディスプレイモードにならないモデルなので無理。

Rebuild のエピソード 266 で miyagawa さんが Mac mini から Remote Desktop で会社支給の Macbook Pro につないで仕事してるって言ってて、なるほどなと思って真似してみた。

私物 iMac から会社の MacBook Pro に vnc でつないでみる。しかし単なる画面共有だとキーボードショートカット使えなくて厳しかった( Command + Space で Alfred を呼び出そうとすると、クライアント側の Mac の Alfred が反応する)。 Apple Remote Desktop でならショートカットも使えるという未確認情報があるのだけど、値段が 10,000 円もしてちょっと試すには厳しいお値段。

一回オフィスに車で行ってディスプレイを持ち帰るとよさそうだなとは思うのだけど、またオフィスで仕事を始めるときにディスプレイを会社に持っていくのもなかなか厳しい(持ち帰るときとまたオフィスに持っていくときの二回、車で送ってもらわないといけない)。こういうことで悩まなくて済むくらいのお金が欲しい