2016-10-31(月) [長年日記]
■ jpholidaypコマンドを使って平日だけ弁当を自動注文するようにした
職場で運用してる(自作の)たまご屋弁当の注文サービス、毎朝出社する前に自宅から注文していくようにしてるんだけど、今月は何度か忘れてしまって、こういう簡単な習慣すらも忘却してしまうのが老いなのか……とがっくりきているわけですが(←ただのうっかり者だろう)。
RTMに繰り返しタスクを入れておくのも良いが、せっかくサーバサイドをRestful APIで作ってあるんだから、自動化すればいいんである。
課題は2つ。
- 営業日のみ注文したい(土日と祝祭日は避ける)
- 弁当が不要な日には手動でキャンセルしたい
ふたつめの課題は単純で、注文したことを通知すればいい。以前作ったpushmeコマンドを使ってPushBulletに送りつけるようにした。意図しない注文がされたらすぐにキャンセルすれば良い。問題なければ無視するだけ。
ひとつめの課題は、日本の不規則な祝祭日を考慮するのが面倒なんだけど、k1LoW/holiday_jpというデータを使ったemasaka/jpholidaypというコマンド(要Python)があったのでありがたく利用*1。
こんな感じのコマンドを毎朝実行するcronで回せばよくなった*2:
#!/bin/sh if jpholidayp; then echo "週末なので弁当は注文しませんでした。" | pushme bento else charge={curl -s -d "date=`date +%Y%m%d`" https://example.jp/hoge` echo "弁当を注文しました。残金${charge}円です。" | pushme bento fi
あー、気が楽になった(←サービスがエラーになった場合を考慮してないぞ!!)。
*1 同じような(というか関係者が同じ?)holiday-jp/holiday_jpというプロジェクトもあってどっちも更新されてるっぽいのが気になるんだけど……。
*2 jpholidaypコマンドはcrontabの中で使うことを想定してるっぽいけど、run-partsを使って楽をしているのでコマンドの中で使った。
2016-10-30(日) [長年日記]
■ スマホのSDカードをTranscendの128GBにした
ほとんどのデータをクラウド上に置くようになって、スマホ本体のストレージはそんなに必要ないから、ずいぶん以前に買った16GBのやつを使っていた。最近ちょっと大きめの動画を持ち歩きたくなって、それがどうにもギリギリ入るか入らないかみたいな容量だったので、ここらで一気に大容量にすっか、という気になった。
というわけで、安くて安心、みんな大好きTranscendのAmazon限定128GB microSDを購入。安くて怖いくらい。
B01AC1GPVO
いままで使ってたカード*1の中身をPCに吸い出してから、新しいカードをリーダに入れたもののぜんぜん認識しなくて「まさかの不良品か」と思ったら、リーダが128GBに対応していなかったというオチで*2、あわてて近所のビックカメラで新しいリーダを買ってきたという。以前のは6種類くらいのメモリカードを読めるタイプだったけど、最近はもう、microSDで統一できてしまっているので専用品を買った。
そんなわけでようやくコピーできて、スマホに挿せばこっちは問題なく認識してくれた。最近のAndroidの外部SDカードは/storageの下にカードのID(?)みたいな文字列のディレクトリがあるという方式なので、いろんなパス名が変わってしまうのが難点だ。というかめんどい。まぁさすがにしばらくは容量アップする必要ないからいいけどさ。
なんにせよ、カードを買い換えるだけでストレージをドンと増やせるAndroidはすばらしいですねぃ。
■ コートを買い替えた
冬の通勤用コートがかなりくたびれていたので、ひさびさに買い替えた。えーと、これ買ったのいつだっけ……13年前!? 物持ち良すぎだろう。ちなみに当時の日記のリンク先はなくなっていて、会社ごと消滅したかと思いきや、いまは三菱商事で扱っているようだ。買収されたのかな。
それはそうと、近年ジャケットなんかをちょくちょく買っていた伊勢丹のPaul Stuartがいつの間にか撤退していたので(またですか……)、今回はMARGARET HOWELLのシンプルなコートにした*1。こんどのは新素材とか使ってないけど(笑)、あんまり防寒性能が高すぎると満員電車でかえってつらいので、薄くて動きやすそうなのを。これでまた10年(以上)戦えるだろう。
*1 かみさんもMARGARET HOWELLユーザなので「潰さないでね」と念を押されている。左手に宿るこの力を意識して抑え込めるくらいなら苦労はしないのだが。
2016-10-29(土) [長年日記]
■ GitHubのProjects for OrganizationsでtDiaryのリリース管理をしてみる
GitHubがProjects機能をリリースしたときはピンとこなかったんだけど(だってIssuesだけで十分では?)、Organizations単位でProjectsが使えるようになったときいて、これは使えそうだと思った。
tDiaryは3ヶ月ごとに肉の日リリースをしているけど、そのたびに4つのリポジトリから5つのパッケージを生成する。ようするに少なくとも4ヶ所に分散したIssues(とMilestones)を参照しなくちゃいけなくて、これがかなり面倒だったのだ。
というわけで、次の5.0.3向けのリリース作業をProjctにしてみた。リリース候補のIssuesやPRをここに集めておけばいい。けっこうよさげ。
ちょっと面倒だなーと思ったのは、個々のIssues画面からそれを特定のProjectsに追加するルートがなさそうな点だ。Issueを見ながら「これは次のリリースに入れよう」みたいな流れは多いと思うんだけどなぁ。Milestonesではこれができるんだけど、想定してる使い方からはズレてるんだろうか。