portal shit!

connpass で募集されていた勉強会に参加したところ、イベント終了後にイベント管理者から一方的にメールマガジン的なものが送られてくるようになった。勉強会直前の確認メッセージや次回の勉強会の告知ならよく他のイベントからも届くが、そうではなく主催者の私信的な内容だったのでこのようなメールは不要だった。大抵の一斉送信メールにはフッターなどに購読解除ページへのリンクなどがあるが、 connpass から届くメールにはそのような文言はなかった。

最初なぜこのような私信メールが届き続けるのかわからなかったが、自分が管理者になっているイベントで確認してみたところ、管理画面からイベント参加者に任意のメッセージを一斉送信することができるようだった。 connpass はイベントに参加登録すると自動的にイベントのグループに追加されるので、グループの管理者はグループメンバーにメッセージを一斉送信する仕組みがあるようだ。勉強会に参加しただけで一方的にグループのメンバーにされてしまうのは違和感がある。

とりあえず今回はメールマガジンは受信したくないと思ったので該当のイベントページから主催者に「勉強会に参加したときにこのようなメールを送り続けるという説明はなかった、メールマガジンを受信したくない」旨の問い合わせを行い、あわせて connpass にも「勉強会参加後に定期的にメールが届くようになった、同意なしにこのようなメールを送り続けるのを規約上容認しているのか」を問い合わせた。イベント主催者の方からは即座に返信があり、今後メールが届かないようにしてもらえた。 connpass の方（運営元のビープラウド社）からは一週間後に返信があり、自分でイベント主催者とやりとりしろという旨の文章と利用規約ページへのリンクが貼ってあるのみで、自分が尋ねた規約上容認しているかどうかへの回答は書かれてなかった。

そもそも自分が情弱だったのだが、勉強会参加後に自動的に登録されるグループから退会すれば主催者からの一斉送信メールは届かなくなるようだ。自分の場合には当該グループから退会すればよかったのにイベント主催者に苦情めいた問い合わせを行ってしまい申し訳なかった。ただ退会ボタンはぱっと見 disabled されており、到底クリックできるようには見えないし、そもそも退会することでメールが届かなくなるかどうかはわからない（ヘルプページをよく読まない限り退会することで何が起こるのかわからない）。

そもそもメールのみの受信設定を行えるような画面があってもよいと思うのだが、調べてみたところ新しいイベントが公開されたときや資料がアップロードされたときの通知設定は行えるが、イベント主催者からのメッセージを受け取らないようにする設定項目は存在しなかった。

connpass 内全体の各グループで適用される受信設定も同様で、イベント主催者からの恣意的なメッセージを受け取るかどうかの設定項目はなかった。

いらないものを拒否する手順への説明が記されておらず、自分の意図に反して送られてき続けるメールは全て迷惑メールだと思うが、運営元に問い合わせる限りはこれらは規約違反でもなくイベント管理者は自由に行えるようなので、 IT 勉強会を主催している各社の採用担当の皆さんは一度でも勉強会に参加したことがあるカモの皆さんに求人メールを定期的に送り続けてやれば良いのではないでしょうか。

イヤーパッドカバーがぼろぼろになっても自分で取り替えたりしながら割と大事に使ってきた SONY の MDR-1RBT のヘッドアームが折れて使えなくなってしまった。落としたりぶつけたりして壊したというより経年劣化でプラスチックがもろくなっていたっぽい。

音を出すという機能は生きているのに頭に装着するという機能が壊れて使えなくなったのは残念。修理もできるようだが家からかなり離れた車でしか行けないようなところにある郊外の電器屋に平日か土曜の日中に持ち込まないといけない＆修理料金が高いっぽいので修理するか逡巡してる。天神にソニーストアあるのにここで修理頼めないのは極めて謎。タカビーな Apple でも Apple Store に持ち込んだら古い Mac でも見てくれるのになぁ。あまり修理はして欲しくないのかも知れない。

しょうがないのでいまは iPhone に付いてくる Apple の純正イヤフォンを使ってる。ワイヤレスヘッドフォンに慣れきってたので有線は引っ張られる感じがして使い心地が悪い。 Anker の安い Bluetooth イヤフォンもあるにはあるが、電池のもちがよくないし何より自分は耳垢がしめってるネチョ耳クソ野郎なのでインイヤータイプのイヤフォンはあまり長時間付けたくない。頭の上に載っけるタイプのヘッドフォンが一番使い心地よかった。

ヘッドフォン、仕事道具という認識なかったけど失ってみて集中したいときなどに結構依存していたことがわかる。ワイヤレスヘッドフォンは偉大だった。

今年の目標はとにかく金を貯めることにしようと思った。 いい歳なのに恥ずかしいくらい金がなくてちょっと風が吹いただけで生活が破綻しそうな予感がある。贅沢はしてないつもりだけどとにかく金がない。とりあえず三ヶ月間は給料がなくても生活していけるくらいの金は貯めたい。

💸金がない原因

車を買ってからずっとこの調子で、車を買ったことで維持費や保険料がかかるようになったことに加え、車によって行動範囲が広がったことが問題だと思う。郊外に引っ越して飲みに行く機会は減ったが、しょうもない外食をする機会が増えた。幼稚園の支払いも高い。うちは子供一人しかいないのにとにかく園納金の支払いが厳しい（年間40万円くらい）。子どもが二人以上いる普通の家庭はどうやってやりくりしているのだろう。生命保険や固定資産税の支払いも厳しい。一戸建てに引っ越したことで電気代も高くなった。郊外に家を買ってしまった以上車を手放すのは無理だし、子どもを幼稚園に通わせないわけにもいかない。電気代に関しては嫁さんが一晩中暖房をつけたまま居間でテレビを見ながら寝るのでこれをやめてもらえれば多少は改善されるだろうが、寝室で寝て欲しいと言っても「お前の頭皮と息が臭いしあたしには長谷川博己や山田裕貴が出てるドラマを見ることくらいしか楽しみがないんだよ👿」と言われるので自分ではどうすることもできない。加えて車、家、保険、教育費などもライフステージに起因する出費なのである程度はしょうがないものなのかも知れない。

💰対策

とりあえず自分に出来る範囲で以下のことをやるようにしたい。

👀保険の見直し

生命保険、親が選んだやつに惰性で入り続けてるけど明らかに損している気がする。特に医療保険は無駄がでかい気がする。解約して県民共済とかにした方がよさそう。今年分の保険料は払ってしまったので今年中にデカめの手術して保険金もらったあと解約したい。そもそも金があれば医療保険は入る必要ないと思うし金貯めて保険とか入らなくても大丈夫な状況にしたい。

🚫🍻金がかかる飲み会には参加しない

会社持ちの無料の飲み会にしか行かないことにする。二次会にも行かない。酒飲みに行ったらその時は楽しいけど飲みすぎて翌日破滅するし凄まじい勢いで金がなくなる。友達が減るのはしょうがないとあきらめるしかない。

🚫🍺第三のビールの六缶パックを買わない

家に缶ビールがあることでついつい飲んでしまう。酒がなければないでなんとかなる。どうしても飲みたいときにその日飲む一、二本だけ買うようなスタイルに改める。第三のビールとはいえ金がかかることには変わりはない。宵越の酒は持たないようにする。

🍜弁当がない日はスーパーのカップ麺で済ませる

弁当を作ってもらえなかった日の昼食代は 100 円以下に抑える。不健康になるかも知れないが早死にしたら住宅ローンがチャラになるし保険料も払わなくて済むようになるのでむしろ好都合だと思うことにする。

🚫🏪コンビニで買い物しない

前の会社は給料高い人が多くて、みんな朝の出社時に 500 円くらいするスターバックスのコーヒー、昼飯食ったあとに 300 円くらいするスターバックスのコーヒー、三時のおやつに 400 円くらいするスターバックスのコーヒーを買ってた。自分はスターバックスのコーヒーは買えなかったけど周りに流されてコンビニコーヒーを買う癖がついてしまった。セブンイレブンのコーヒーは一杯 150 円でも量が少なくて二回くらい飲みたくなってしまい一日で 300 円使ってしまうことになる。毎日買ったら月 6000 円になる。一生懸命頑張る自分へのご褒美、みたいな感じで朝から高いコーヒー飲んだりよい昼飯食ったりするという考え方もあるとは思うが、自分はそんなに仕事頑張ってないし稼ぎもよくないのでこういう思考とは距離を置くべきだと思う。ときどき朝食にコンビニで総菜パン買って食べるのもやめる。

🚫💻GitHub の有料プラン解約

なんかうぇぶさーびすを作って一発当てようと自分にハッパかけるつもりで Developer Plan に加入してるけど大したコード書いてないし人様に見せられないコードの置き場所は GitHub から Bitbucket に変える。

🚫🛒コストコに行かない

一昨年の 9 月に会員になって去年の 9 月に失効した。余裕ができたら更新したいと思っていたけどコストコ行くと 2 万とか平気で使ってしまうので貯金が目標金額に到達するまでコストコ断ちすることにする。

🙅🏻‍♂️抵抗

逆に嫁さんにやめろといわれて抵抗しているのは以下。

🖥さくらVPSの解約、もしくは下位プランへの変更

プログラマーなので自由に使える Linux サーバーがないと厳しい。このブログはファイルシステムを結構使うようにしてあるので Heroku だと多分動かない。 AWS は逆に高くなる。

いまはメモリ 2GB プランを使っているので下位プランへ契約変更するという手もあるが、いま動かしてるアプリケーション（ puma × 2）だけでも結構メモリが足りないと感じることがあるのでさらにスペックダウンするのは厳しい。実験の場を失うことで長期的には年収を下げることにもつながりかねない。

そもそもサーバー代は Google Adsense と Amazon Associate で 2/3 くらいはまかなえてるのでここは手を付けないことにする。

🎞Amazon Prime 解約

解約してしまうと 2000 円分買わないと送料無料にならないとかいろいろ厳しい。 350 円のものが欲しいだけなのに送料無料にするために 1650 円の大して必要ではない何かを買わざるを得ないシチュエーションはとてもストレスがたまる。せっかく Apple TV で見られるようになった Amazon Prime Video を見られなくなるのも残念。このくらいは死守したい。

正月早々汚らしく金の話をしてしまって最悪だけど、 @taketin さんや @kitak 、 @t32k さんなどといった元同僚の富裕層の皆さんのように用事もないのにヒルトンに泊まったり、一回買って売ったイヤフォンをもう一回買い直したり、わざと虫歯になってセラミックの歯を自慢したりできるような身分になりたい。バカすぎてブロックチェーンとかはわからないので今年は金を貯めることだけを目的にやっていきます🤑

cho45 さんの以下の記事を参考に関連記事を表示するようにしてみた。

TF-IDFとコサイン類似度による類似エントリー機能の実装 | tech - 氾濫原

lowreal.net

ほとんど cho45 さんの記事に書いてある SQL を実行しているだけだけど、関連記事の表示用に Lokka 側に Similarity というモデルを追加して、以下のようなスキーマにしてる。

Similarity テーブルの更新は cho45 さんの記事にあるように SQLite で行った計算の結果を反映することで行う。以下のような Rake タスクを定義した。

desc "Detect and update similar entries"
task similar_entries: %i[similar_entries:extract_term similar_entries:vector_normalize similar_entries:export]

namespace :similar_entries do
  require 'sqlite3'
  desc "Extract term"
  task :extract_term do
    require 'natto'
    nm = Natto::MeCab.new
    db = SQLite3::Database.new('db/tfidf.sqlite3')
    create_table_sql =<<~SQL
      DROP TABLE IF EXISTS tfidf;
      CREATE TABLE tfidf (
        `id` INTEGER PRIMARY KEY,
        `term` TEXT NOT NULL,
        `entry_id` INTEGER NOT NULL,
        `term_count` INTEGER NOT NULL DEFAULT 0, -- エントリ内でのターム出現回数
        `tfidf` FLOAT NOT NULL DEFAULT 0, -- 正規化前の TF-IDF
        `tfidf_n` FLOAT NOT NULL DEFAULT 0 -- ベクトル正規化した TF-IDF
      );
      CREATE UNIQUE INDEX index_tf_term ON tfidf (`term`, `entry_id`);
      CREATE INDEX index_tf_entry_id ON tfidf (`entry_id`);
    SQL
    db.execute_batch(create_table_sql)

    entries = Entry.published.all(fields: [:id, :body])
    entry_frequencies = {}
    entries.each do |entry|
      words = []
      body_cleansed = entry.body.
        gsub(/<.+?>/, '').
        gsub(/!?\[.+?\)/, '').
        gsub(/(```|<code>).+?(```|<\/code>)/m, '')
      begin
        nm.parse(body_cleansed) do |n|
          next if !n.feature.match(/名詞/)
          next if n.feature.match(/(サ変接続|数)/)
          next if n.surface.match(/\A([a-z][0-9]|\p{hiragana}|\p{katakana})\Z/i)
          next if %w[これ こと とき よう そう やつ とこ ところ 用 もの はず みたい たち いま 後 確か 中 気 方 頃 上 先 点 前 一 内 lt gt ここ なか どこ まま わけ ため 的 それ あと].include?(n.surface)
          words << n.surface
        end
      rescue ArgumentError
        next
      end
      frequency = words.inject(Hash.new(0)) {|sum, word| sum[word] += 1; sum }
      entry_frequencies[entry.id] = frequency
    end
    entry_frequencies.each do |entry_id, frequency|
      frequency.each do |word, count|
        db.execute("INSERT INTO tfidf (`term`, `entry_id`, `term_count`) VALUES (?, ?, ?)", [word, entry_id, count])
      end
    end
  end

  desc "Vector Normalize"
  task :vector_normalize do
    db = SQLite3::Database.new('db/tfidf.sqlite3')

    load_extension_sql =<<~SQL
      -- SQRT や LOG を使いたいので
      SELECT load_extension('/usr/local/Cellar/sqlite/3.21.0/lib/libsqlitefunctions.dylib');
    SQL
    db.enable_load_extension(true)
    db.execute(load_extension_sql)

    update_tfidf_column_sql = <<~SQL
      -- エントリ数をカウントしておきます
      -- SQLite には変数がないので一時テーブルにいれます
      CREATE TEMPORARY TABLE entry_total AS
          SELECT CAST(COUNT(DISTINCT entry_id) AS REAL) AS value FROM tfidf;

      -- ワード(ターム)が出てくるエントリ数を数えておきます
      -- term と entry_id でユニークなテーブルなのでこれでエントリ数になります
      CREATE TEMPORARY TABLE term_counts AS
          SELECT term, CAST(COUNT(*) AS REAL) AS cnt FROM tfidf GROUP BY term;
      CREATE INDEX temp.term_counts_term ON term_counts (term);

      -- エントリごとの合計ワード数を数えておきます
      CREATE TEMPORARY TABLE entry_term_counts AS
          SELECT entry_id, LOG(CAST(SUM(term_count) AS REAL)) AS cnt FROM tfidf GROUP BY entry_id;
      CREATE INDEX temp.entry_term_counts_entry_id ON entry_term_counts (entry_id);

      -- TF-IDF を計算して埋めます
      -- ここまでで作った一時テーブルからひいて計算しています。
      UPDATE tfidf SET tfidf = IFNULL(
          -- tf (normalized with Harman method)
          (
              LOG(CAST(term_count AS REAL) + 1) -- term_count in an entry
              /
              (SELECT cnt FROM entry_term_counts WHERE entry_term_counts.entry_id = tfidf.entry_id) -- total term count in an entry
          )
          *
          -- idf (normalized with Sparck Jones method)
          (1 + LOG(
              (SELECT value FROM entry_total) -- total
              /
              (SELECT cnt FROM term_counts WHERE term_counts.term = tfidf.term) -- term entry count
          ))
      , 0.0);
    SQL
    db.execute_batch(update_tfidf_column_sql)

    vector_normalize_sql = <<~SQL
      -- エントリごとのTF-IDFのベクトルの大きさを求めておきます
      CREATE TEMPORARY TABLE tfidf_size AS
          SELECT entry_id, SQRT(SUM(tfidf * tfidf)) AS size FROM tfidf
          GROUP BY entry_id;
      CREATE INDEX temp.tfidf_size_entry_id ON tfidf_size (entry_id);

      -- 計算済みの TF-IDF をベクトルの大きさで割って正規化します
      UPDATE tfidf SET tfidf_n = IFNULL(tfidf / (SELECT size FROM tfidf_size WHERE entry_id = tfidf.entry_id), 0.0);
    SQL
    db.execute_batch(vector_normalize_sql)
  end

  desc "Export calculation result to MySQL"
  task :export do
    db = SQLite3::Database.new('db/tfidf.sqlite3')
    create_similar_candidate_sql = <<~SQL
      DROP TABLE IF EXISTS similar_candidate;
      DROP INDEX IF EXISTS index_sc_parent_id;
      DROP INDEX IF EXISTS index_sc_entry_id;
      DROP INDEX IF EXISTS index_sc_cnt;
      CREATE TABLE similar_candidate (
        `id` INTEGER PRIMARY KEY,
        `parent_id` INTEGER NOT NULL,
        `entry_id` INTEGER NOT NULL,
        `cnt` INTEGER NOT NULL DEFAULT 0
      );
      CREATE INDEX index_sc_parent_id ON similar_candidate (parent_id);
      CREATE INDEX index_sc_entry_id ON similar_candidate (entry_id);
      CREATE INDEX index_sc_cnt ON similar_candidate (cnt);
    SQL
    db.execute_batch(create_similar_candidate_sql)

    extract_similar_entries_sql = <<~SQL
      -- 類似していそうなエントリを共通語ベースでまず100エントリほど出します
      INSERT INTO similar_candidate (`parent_id`, `entry_id`, `cnt`)
          SELECT ? as parent_id, entry_id, COUNT(*) as cnt FROM tfidf
          WHERE
              entry_id <> ? AND
              term IN (
                  SELECT term FROM tfidf WHERE entry_id = ?
                  ORDER BY tfidf DESC
                  LIMIT 50
              )
          GROUP BY entry_id
          HAVING cnt > 3
          ORDER BY cnt DESC
          LIMIT 100;
    SQL

    search_similar_entries_sql = <<~SQL
      -- 該当する100件に対してスコアを計算してソートします
      SELECT
          ? AS entry_id,
          entry_id AS similar_entry_id,
          SUM(a.tfidf_n * b.tfidf_n) AS score
      FROM (
          (SELECT term, tfidf_n FROM tfidf WHERE entry_id = ? ORDER BY tfidf DESC LIMIT 50) as a
          INNER JOIN
          (SELECT entry_id, term, tfidf_n FROM tfidf WHERE entry_id IN (SELECT entry_id FROM similar_candidate WHERE parent_id = ?)) as b
          ON
          a.term = b.term
      )
      WHERE similar_entry_id <> ?
      GROUP BY entry_id
      ORDER BY score DESC
      LIMIT 10;
    SQL

    results = {}
    Entry.published.all(fields: [:id]).each do |entry|
      db.execute(extract_similar_entries_sql, [entry.id, entry.id, entry.id])
      db.results_as_hash = true
      similarities = db.execute(search_similar_entries_sql, [entry.id, entry.id, entry.id, entry.id])
      results[entry.id] = similarities
    end

    Similarity.destroy

    results.each do |entry_id, similarities|
      if similarities.present?
        similarities.each do |s|
          conditions = { entry_id: s["entry_id"], similar_entry_id: s["similar_entry_id"] }
          similarity = Similarity.new(conditions)
          similarity.score = s["score"]
          similarity.save
        end
      end
    end
  end
end

やってることとしては、全エントリーを拾ってきて本文を MeCab で品詞分解して名詞だけを取り出し記事ごとの term 一覧を作り、そこから TF-IDF を求めてベクトル正規化し、最後に関連していそうなエントリを探し出して similarities テーブル（こちらは SQLite のテーブルではない）を更新している。詳しいアルゴリズムはバカなのでわからないが、 cho45 さんが書いているやり方を Lokka のスキーマに素直に適用した感じ。

結構この処理は遅いので parallel.gem を使って高速化できないか試してみたが、スレッドによる並行処理ではあまり速くできなかった。 4 コアある CPU のうち一つが 100% で処理を実行してもまだ 3 コアは余っている。プロセスを増やして並列処理するのがよさそうだが、分散をプロセスレベルで行おうとすると MySQL server has gone というエラーが出る。 DataMapper が MySQL とのコネクションをロストするようである。 ActiveRecord であれば reconnect するだとか回避方法があるようなのだけど DataMapper は情報が少なく、対応方法が見つけられなかったので一旦並列処理はあきらめた。

何回か動かしてみて大体正しく関連記事を表示できてそうなのでさくらの VPS で稼働させたいところなのだけど、関連記事の更新はいまのところ手動でやっている。本番 DB の entries テーブルを dump してきて Mac に取り込み、 similarities テーブルを更新して今度はローカルで similarities テーブルを dump して本番にインポートするという手順をとっている。

これにはいろいろ理由があって、一つには利用している mecab-ipadic-neologd （新語にも対応している MeCab の辞書）が空きメモリ 1.5GB 以上でないとインストールできずさくらの VPS にインストールできなかったから。もう一つには cho45 さんのブログにもあるけど SQLite で LOG や SQRT を使うためには libsqlitefunction.so の読み込みが必要で、 load_extension() できるようにしないといけないが、そのためには sqlite3 をソースからビルドする必要があり若干面倒だった（ Mac では Homebrew で sqlite を入れた）。

関連記事の更新は自分が記事を書いたときにしか発生しないのでいまの手動運用でもまぁ問題ないが、このブログは Docker でも動くようにしてあるので Docker イメージを作ればさくら VPS でも問題なく動かせそうな気はする。正月休みにでもチャレンジしたい。

感想

関連記事表示、結構面白くてちゃんと関連性の高いエントリーが表示される。例えば人吉に SL に乗り行った記事の関連記事にはちゃんと山口に SL に乗りに行ったときの記事 が表示される。いまのところ Google Adsense の関連コンテンツよりも精度が高いようである。

無限に自分の黒歴史を掘り返すことができるのでおすすめです。

fish-shell に移行 してこれで .zshrc のお守り業から解放されたと思ってたが、最近異常にシェルの新規セッションの開始が遅くて死にそうになってた。特にやばいのが git mergetool したときで、これは内部的には沢山の fish のプロセスが起動して diff を調べて最終的に vimdiff で表示しているように見えた（僕は git config editor=vim です）。下手するとちょっとしたコンフリクトを修正するために vimdiff が起動するまで 15 分くらい待たないといけないことがあって、 20 年くらい前の Photoshop 作業の現場[^{1]みたいな感じになってた。これはかなりやばくて、生産性ががた落ちになる。} vimdiff が開くまでに待っている間に他のことやり始めて、気がつくと平気で夕方になってたりする。

fish-shell のバージョンを 2.7.0 に上げたことが原因かと思って、かつて快適に使えていた fish のバージョンに下げたりしてみたが解決しなかったが、以下の記事にたどり着いて $fish_user_paths への値の push をやめたところ解決した。

fish shellの起動が遅くなった時の解決方法 - Qiita

TL;DR fish shellの起動に3〜4秒ぐらいかかるようになった。 config.fishの$fish_user_pathsの設定方法に問題があった。 この問題の原因と解決方法をまとめた。 何が起きたか fish shellを起動してコマンドが入力できる...

qiita.com

fish-shell での PATH の通し方として以下のようなのがよく出てくる。 Homebrew で keg only なやつを入れたときにも表示される。

set -U fish_user_paths $HOME/Library/Python/2.7/bin $fish_user_paths

しかしこれをやると $fish_user_paths にどんどんパスが積まれていってしまう。どうもこれが原因で遅くなるようだった。自分の環境でも echo $fish_user_paths してみたところかなり酷いことになっていた…。

↑の Qiita 記事では set -U fish_user_paths するときに第三引数を消せとあったが、それでは根本的な問題の解決にならない（ Python やら Ruby やらいろんなものの実行ファイルを PATH に通したいはず）。自分は以下の方法で解決した。

set -x PATH /usr/local/bin $PATH

bash や zsh で export PATH=/usr/local/bin:$PATH とやるのと同じオーソドックスなやり方だと思う。

これだけではこれまでに散々肥えた $fish_user_paths は残ったままなので適当に set -U fish_user_paths '' とかやってあげると空になって起動が速くなる。

fish-shell の set -U はセッションをまたいでグローバルかつ永続的に設定される変数定義の方法っぽいので下手するとその環境で fish を使い始めてからずーっと残ってしまう可能性がある（端末を再起動したらリセットされるかも知れないけど）。

まとめ

• set -U は基本的にしない
• $fish_user_paths は設定ファイルの中では使わない
• PATH を通したいときは set -x PATH を使う

[^1]: 何らかの処理を実行して処理が完了されるまでにめっちゃ時間がかかるのでその間にたばこを吸いに行くことが可能だったらしい

追記 2020-05-23

set -x PATH /usr/local/bin $PATH がよいと書いていたが、 tmux を起動すると $PATH に重複してパスが登録されてしまう。ファイナルアンサーとしては以下。

$ set -g fish_user_paths /usr/local/bin $fish_user_paths

• set -U は使わないではなく set -g する
• $fish_user_paths は設定ファイルの中でも使ってオッケー
  • パスを通したいときは set -g fish_user_paths /usr/local/bin $fish_user_paths とやる
    set -x PATH /usr/loca/bin $PATH をやると tmux のセッションの中でパスがダブるため

旅行や街歩きに出かけたとき、移動軌跡が地図上に表示されるとその時何をしていたのかが思い出せて便利になると思う。例えば知らない街に旅行に行った数日後にこんな状況になったことはないだろうか。「昼飯を食ったあとに食器屋に行って良い皿を見たんだけど迷って買わなかったんだよなぁ、あれはなんて店なんだろう、ネット通販やってるかな🤔」。自分はよくある。こういうときに位置情報付きの行動ログが残ってれば店名を探り当てやすくなるし、目当ての商品にたどり着ける可能性が高まる。

自分は今のところ Twitter 、 Instagram への投稿と Swarm へのチェックインを IFTTT 経由で Day One に自動投稿しているので、それらの情報が手がかりにならないでもないが、それでもそのときの自分が Twitter なり Instagram なり Swarm なりに何らかの情報を投稿していないと Day One には何も残らない。やはり何らかの行動ログ的なものが記録されている方がいい。

とはいえ旅行や町歩きのときに意識的に行動ログの取得を開始するのは難しいと思う。旅行中、街を散策する前に iPhone を取り出して何らかのアプリケーションを起動し「開始」ボタンを押したりできるだろうか？ 気がついたときには随分行動してしまったあとで「今から記録をとってもね😔」という感じになるのが現実だろう。この手のツールはバックグラウンドで勝手にログをとっといてくれるのが重要だと思う。

何か良いアプリはないものかと App Store で調べてみたところ、 SilentLog というやつが見つかった。評価は良かったがバッテリーの減りが速いとある。インストールしてみたところ確かにバッテリーの減りが速くなる。よくよく考えたら Google Maps のタイムラインや Day One でもバックグラウンドでの位置情報の取得はやってるので似たようなことを複数のアプリでやるのは効率が悪い。

とはいえ移動したログを一番かっちょよく見られるのは SilentLog だった。こんな風に一日のタイムラインを手軽に振り返ることができる。朝家を出て電車に乗り、9時から18時まで職場で仕事をしてなどがすぐわかる。休みの日に出かけた場所も意識せずに記録されていく。その日 iPhone で撮った写真も表示される。

特に良いのが1日の行動ログをほかのアプリやサービスに書き出せること。 Google Maps のタイムラインはエクスポート機能がないし、 Day One の Activity Feed は一定期間たつと消えてしまうので残しておきたいなら意識して記事を作成しないといけない上に、記事にしたとしても位置情報の履歴は残らない。

その点、 SilentLog は行動ログが地図上に表示された画像を手軽に書き出せる。とても便利なのだが、この機能を使うには App 内課金で有料チケットを購入する必要があるようだった。 240円/30日で年払いだと 1900 円とのこと。

位置情報の収集や書き出し、気持ち悪いと感じる人には気持ち悪いこと極まりないだろう。またもし個人を特定できるかたちで流出して誰かに見られてしまったら非常にまずい（浮気中の人など）。加えて SilentLog を作っている会社 はユーザーの位置情報データを売っているようである。おそらく「年収 XXX 万円くらいの 30-40 代の男性が毎週何曜の何時に新宿駅に何人くらいいる」みたいなデータをデパートとかに売ったりするのだろう。 DMP の位置情報版といったところか。個人を特定できないようにはなってると思うがあまりよい気持ちはしない。

とはいえ自分でも忘れるような行動の履歴をスマートフォンアプリが取っておいてくれてあとで振り返られるというのは絶対に便利だと思う。日記は書いておくと便利だけど書くのが非常に面倒くさい。行動のログから自動で簡易的な日記にしてくれてバッテリーの消耗が穏やかなアプリがあったらうれしいなぁ。（結構個人のプライバシーを尊重する） Apple がそういうのつくってくれないかな。

先週、 Alfred で通貨換算をやる方法（💵 Alfred で手軽に通貨換算 💴 ）について書いたけどその続き。

Numi という Alfred に似たソフトがある。 Soulver と違い多言語対応はしておらず、自然言語による入力は日本語未対応なのだが、 Soulver もまともに使えるのは英語利用時だけなので実質的には機能に差がない。タブを使えたりする分、 Numi の方が高機能かも知れない。さらに Numi は今のところ無料である（ベータ版のため）。ベータ版とはいえほとんど困ることなく利用できている。

このソフトがすごいのが、 Alfred Workflow を入れると Numi による計算を Alfred から n <式> と入力することでできるようになるということ（ただし Numi.app を起動しておく必要あり）。こんな感じ。

いちいち Numi.app に切り替えて新規ドキュメントを作成し、ということをしなくて済む。とても手軽に計算できる。通貨換算のほかに、単位の換算もできる。 Google Fincance の Converter サービスを使うやり方よりも高機能だ。

このソフトを知ってから Soulver を使う機会がめっきり減ってしまった。 Alfred からも計算できるし、結果を残しておきたいような複雑な計算をするときは Numi.app に切り替えて使うこともできる。文章を書いたり考え事をしているときにささっと計算できて頭の切り替えコストが低い。 AWS を利用しているプログラマー諸氏なら EC2 インスタンスの料金なんかを計算するときにもとても便利だと思う。おすすめです。

この記事は Alfred 3 Advent Calendar 2017 - Adventar 12 日目の記事でした。明日は（明日も） @tsurusuke さんです。