2週間前と同じように体調不良になった。普通に帰宅して体温を計ると38度弱だった。とにかくだるいので夕食を食べてすぐに寝た。

朝は平熱にとりあえず戻った。

  1. トップ
  2. 体調不良

既に死ぬ気があるのに、来年までこれやってたら確実に死ぬしかなくなる。その前にどうにかして辞めないといけない

昨日は帰宅後微熱(というほどでもないぐらい)。身体はそこまでだるくないが頭痛がひどい。

  1. トップ
  2. 体調不良

予測付き体温計

テルモ 電子体温計 【スピード検温式 平均20秒】 -

5.0 / 5.0

もらったものだけど、もっとはやく買えば良かった。20秒ぐらいで測れるので体温を測るのが全く苦ではなくなる。実測体温計の計測時間 (10分ぐらい) は、風邪をひいていると特に、永遠とも思えるぐらい長く感じられるけれど、これならそんなことなく気軽に測ることができる。風邪になりそうなときとか、なんでもないときでも気軽に測れるので、体温計の出番が多くなった。

ずいぶん前に風邪をひいたときに予測なしの電子体温計を買って以来、うちに一応あるのに別のを買うのもなと思っていたけど、予測付きは完全にライフチェンジングなのでさっさと買うべきだったと思った。

関東の聖地と神社 (楽学ブックス) -

4.0 / 5.0

出雲大社 (楽学ブックス) - .

.

4.0 / 5.0

伊勢神宮 (楽学ブックス) - .

.

4.0 / 5.0

日経ホームマガジン 伊勢神宮と出雲大社 (日経ホームマガジン 日経おとなのOFF) -

4.0 / 5.0

このへんのを買った。「辰宮太一」さんが書いている上3つは文章の宗教色が強くて (宇宙とかなんとか)、「いやそういうのいいし」という人には少し読みにくい気がする。そのへんをさっぴいて読む限りではためになる。いずれにしても、これらは文よりは写真を見るのが楽しいと思う。

やはり神社関係の写真は「安定」「威厳」というのを感じさせる構図になっている。加えて、やはり神社は自然の中にあってこそであるので、それらをうまく入れこんでいて勉強になる。特に伊勢神宮は天照大神という太陽神を祭っているわけだから、太陽をうまく収めるのは必須だなと思った。

「あわなそうだな」ということでも試しにやってみろ、やってみないとわからない、ということを言う人はとてもよくいるけど、アホだと思う。「あわなそうだな」ということを押しつけられたとき、やってみないとわからないかも、と思って試してみるのもアホだと思う。

物事を新しくはじめて「あいそうか」「あわなそうか」と、その結果の「あってた」「あってなかった」の組み合せなんて以下しかない。

  • 「あいそうだな」と思って実際「あってた」
  • 「あわなそうだな」と思った結果「あってない」
  • 「あわなそうだな」と思ったけど「あってた」
  • 「あいそうだな」と思ったけど「あってない」

そもそも最初から「あわなそうだな」と直感的に思うほどの苦手意識を感じているのに、結果として「あっていた」というのは、根本的にクリアのハードルが高い。

求めるのは結果として「あってた」ということだけだ。結果の頻度から考えて「あわなそうだな」ということをやるのは時間の無駄で、ただの被虐的性癖だ。

「試しにやってみろ」とか言う人は、何らかの成功体験を持っているのかもしれないけど、それは成功体験でもなんでもなくて、単に選択ミスをしたことを認めたくなくて「どんなことでも経験になる!!!」とか思い込みたいだけだ。本人の内面においては、そういう「どんなことでも経験になるんだ……」と思い込むことは健康上悪くないと思うけど、他の人にも同じような失敗をさせようとする人ってのは限りなく愚かで害でしかない公害みたいな存在だと思う。

やってみないとわからないかも、と思いながらやってみることをやめよう。

  • Lightroom が快適に使える Mac
    • Mac Mini?
  • SIGMA 35mm F1.4 (EF)

洗濯機の脱水のたちあがり設定を、揺れを最大限許容するほうに変更した。

毛布を洗うときにかなり何度も脱水に失敗してすすぎからやりなおしたあげく、最終的には失敗してピーピーいっていたので、面倒だし多少の揺れ騒音は許容したほうが良いという判断をした。

Gmail のメールを OAuth 経由で読むことができることを今更ながら知った。なぜかずっと「Gmail はユーザ名・パスワード認証しかできなくて不便だな〜 パスワード書きたくないな〜 OAuth できたらな〜」と OAuth ができないものだと思いこんでいた。

で、簡単に読めるモジュールがあるかなあと思ったけど、ちょっと見た感じではないので自力で書いてみた。

Gmail + OAuth の基礎知識

概要としては

  • OAuth のアクセストークンを得る
  • メールアドレス (アカウント名) + アクセストークンを使って SASL XOAUTH2 フォーマットの文字列を作る
  • IMAP を使い、AUTHENTICATE コマンドで上記文字列を送って認証する

という感じで、OAuth は使うけれど、WebAPI で Gmail が読めるわけではなく、最終的には普通に IMAP を喋る必要がある。

ログインまでは比較的簡単で、ドキュメントを読めばあまり問題なくできた。

日本語で検索をする

SEARCH X-GM-RAW という、Gmail のウェブ版のシンタックスでメールを検索する、という機能があるのだけれど、これを使うのにかなり難儀した。というのも、マルチバイト文字列を使う場合どうすればいいかドキュメントがなく、なんとなく適当に書いても動かない。

結論からいうと、マルチバイト文字列で検索したい場合

  • IMAP の仕様上の「literal」で送る必要がある
    • literal は {bytes} をコマンド引数で指定したあと、任意のバイト列を送れる仕様 (IMAP は 7bit プロトコルだが、ここだけは 8bit が通る)
  • literal の文字コードは UTF-8 でいい
  • CHARSET UTF-8 をつける必要がある

でもって、最終的に該当部分の IMAP のリクエスト/レスポンスは以下のようになる

> NIC4 UID SEARCH CHARSET UTF-8 X-GM-RAW {47}
< + go ahead
> subject:アクティビティ  newer:2013/06/01
>
< * SEARCH 241354 241543 241544 242493
< NIC4 OK SEARCH completed (Success)

答えさえ知ってれば難しくはないけど、かなりハマった……

  1. トップ
  2. tech
  3. Gmail のメールを OAuth で読む (Perl)

短縮 URL なんかだと、Base58 (Base64の中から、表示上まぎらわしい文字を削除したもの) を使ってただの数値を短かくする工夫をしていたりするが、それをもうすこし汎用的に使いたいので書いてみた。

実用性に疑問があるので CPAN にあげてはいない。

経緯

ある文字数制限のあるフィールドに、できるだけ邪魔にならないように数値を埋めこみたいと思った。任意の数字なので、特に bigint になると数字そのままでは文字数がばかにならない。そこで Unicode を使ってエンコードすることを思いついた。バイト数的には不利なのだけれど、文字数による制限であれば、Unicode 文字はたくさんあるのでもっと短くなると考えた。

使う文字セットはなんでもいいけど、ぱっと見で脳が読もうとしない、意味を理解しないものがいいと思い探していたところ、点字だと、なんと丁度 256 文字あるし、ぱっと見がかっこいいのでそれでまず Base256 というのを作った。

ちなみにこれだと '9235113611380768826' という数値 (19文字) は、'⢀⠩⢶⣦⡚⢹⣀⠺' という文字列 (8文字) にエンコードできる。

ただ、Base256 だと汎用性がなく、なおかつ Unicode の点字の文字セットを使うというのだとあまりにもニッチすぎるので、任意の文字セットを使えるようなものならまだマシかと思い BaseN を作った。

  1. トップ
  2. tech
  3. 任意の文字セットで数値をエンコードできる Encode::BaseN

土曜日、神田明神、富岡八幡宮、水天宮を見てまわった。

どれも都会の神社の様相で、鎮守の森はないか、あっても小さい。水天宮は改築中らしく、移転していた。

とりあえず行くだけ行ったが、今回行った神社はあまり面白さを感じなかった。

東京都の別表神社はあと東郷神社だけ行ってない。

妙楽寺 (あじさい寺) に行ってみたけど、あまり人もいないし、静かで良かった。あじさいも大変たくさん咲いていた。

  • たくさんの人を同時に幸せにしたいとは思わない
  • 社会的によいことと思えることをしたい
  • 金以外に直接的に自分が幸福になることをしたい
  • ストレス > 得られる幸福 となるようなことは一切したくない

幸福感がない状態が続くと連鎖的に不幸な感じになる。

  • 普通に生きてるのになんでこんな思いをするのだろうと感じる
  • 自分よりもさらに何もできない意識だけ高いみたいなやつがのうのうと生きているのに、自分はなぜこうなっているのだろうと思う
  • この先どのような選択をしたとしても同じような思いをする予想が見えるようになる
  • 「つらいのはお前だけじゃない」とか言われるのを想像して余計イライラする
  • 嫌なやつがした言動、特に特定のフレーズがそいつのドヤ顔と共に何度も思いかえされる
  • 普段嫌なことに対してさらに負のフィードバックがかかり続ける
  • 努めてとりうる選択肢・可能性を列挙してみるが、結局のところ逃げ出すか死ぬかにいきつく
  • 逃げ出すにも元気が必要でめんどうだし、そのことを考えるの億劫になる
  • 結局自分でどうにかするしかないので異様な孤独感を覚える
  • 根本的な元気が不足するので、何も手がつかなくなる。よってさらに無能感が高まる
  • 向きあって希望のある現実がないと感じる

ひとまず楽天カードの情報を Zaim に突っ込むまでスクリプトにしてみた。Amazon のも入れれるようにしたい。

動作

初回起動時に OAuth を設定する必要がある

  • 楽天カードの「売上情報」メールをパースして入力している
  • 一度入力された情報は何度スクリプトを動かしても多重登録はされない
    • Zaim 上のコメントに点字符号 [⠃⢶⠒] を埋めこんで管理している (Gmail 上の UID をエンコードしたもの)
    • 同一日付内に該当メールから入力されたエントリが1件でもあれば無視するようになっている
  • カテゴリ・ジャンルは自動で推測して入れてる (payment_guess.conf に定義あり)

Zaim の API のメモ

Zaim の OAuth は oob (out-of-band いわゆるクライアントアプリケーション認証) に対応していない。callback に HTTP HTTPS のURIしか受け付けないので http://oob/ とか適当に指定しておくしかない。それで認証すると http://oob/ から始まるリダクレクト先URLが画面に表示されるので、クエリパラメータを頑張ってコピペしてやる必要がある。

それと Android 版の Zaim しか使っていないと気付かないんだけど、Zaim にはアカウント(口座のほうの意味)機能があって、現金・クレカ・PASMOとかを別々に管理できる。アプリだけを使っているとアーキテクチャを理解できないのでウェブ版を設定項目を含め一通り見たほうが良い。

最初、/v2/{account,category,genre} というデフォルトのものを返すAPIを使っていたが、これらのIDだと POST /v2/home/money/payment は、成功はしつつも、バグってしまう (ウェブ版で 500 がでる)。結局、/v2/home/{account,category,genre} を使うのが正しいみたいだ。(デフォルトを返すAPIはどういうとき使うのを想定してるんだろう)

また /v2/home/money/payment に place を指定すると {"error":true,"message":"This consumer key does not have a permission for the action.","extra_message":null} が返ってきてしまう。何かが悪いっぽいけどどうしたらいいかわかってないので、ひとまず指定しないようにした。

経緯

Google Spreadsheet で家計簿をつけていたが、いかんせん意識が低くなってくるとスプレッドシートを見る気がなくなるという問題があった。また、結構頻繁に辻褄あわせをする必要があるため面倒くさい。

基本的現状の運用だと

  • 現金で「消費したときに記録する」という行動の習慣化はできている
  • 今月あといくら使えるか、今週あといくら使えるか、などをうまく可視化できていない

みたいな感じになっている。それらを解決するために自分でウェブアプリを書いていたんだけど、最近は Zaim の Android アプリも普通に便利に使える感じなので、自分で作るより ASP なものを使ったほうがメリットが多そうと判断した。

本当は、直接 Google App Script から Zaim に OAuth を繋ぎたかったんだけど、どうしても OAuth エラーになって進まないので、諦めて Perl で書きなおした。

Perl で書きなおす途中でGmail を読むのにハマったり、上記の通り Zaim の API で結構ハマったりした。

  1. トップ
  2. tech
  3. Gmail のメールからクレカ請求を Zaim へ自動入力

写真を撮っていると気付くことは多い。人の目には回りの風景が思いのほか写り込んでるとか、太陽の光の圧倒的強さとか