2019

⚠️ circleci/orb-tools v8.27.6 を使っています。さっき見たら v9.0.0 がリリースされており、trigger-integration-workflow 等のジョブ名が変わり、互換性がなくなったことは確認しました。 先日、tfupdate の CircleCI Orb を作りました。 tfupdate とは tfupdate は terraform のアップデートを支援してくれるツールです。ローカルの .tf ファイルに書かれた、terraform と terraform provider のバージョンを最新にしてくれます。 .circleci/config.yml に組み込むと、定期的に pull request を作ってくれます。 例: https://github.com/minamijoyo/tfupdate-circleci-example/blob/cd8e5561b7eabb25aa3cd024dfcf5b868c4bda45/.circleci/config.yml タイムリーなことに、作者の minamijoyo さんが書かれた記事があります。詳しくはこちらをどうぞ。 tfupdateでTerraform本体/プロバイダ/モジュールのバージョンアップを自動化する - Qiita なぜ circleci-tfupdate-orb を作ったのか 前述の .circleci/config.yml を見ると分かりますが、かなり行数が長いです。130 行あります。 tfupdate 以外にも CI の設定はありますし、これを各リポジトリに書くのは辛いです。そのため、ほぼそのまま Orb にしたのが v0.0.2 です。 https://github.com/masutaka/circleci-tfupdate-orb/tree/v0.0.2 CircleCI Orb Registry はこちらです。v0.0.2 は circleci CLI を使って手動で Publish しました。Publishing Orbs や他の記事など、読み漁りました。 https://circleci.com/orbs/registry/orb/masutaka/tfupdate?version=0.0.2 なぜ circleci/orb-tools を使ったのか 変更を加えるたびに Orb Registry に publish していくのはなかなか面倒です。...

Ruby apps will now have the BUNDLED WITH declaration in their Gemfile.lock removed after detecting Bundler version｜Heroku Dev Center このアナウンスがあったので、調べてツイートした。ブログにも貼っておく。 loading... アナウンスの内容要約 Gemfile.lock の ‘BUNDLED WITH’ には問題があるから、Heroku では bundler version の決定（v1 or v2）に使った後、‘BUNDLED WITH’ は削除してからデプロイするよとのこと。 Heroku というより heroku-buildpack-ruby の話ね。 heroku-buildpack-ruby の処理 LanguagePack::Ruby#install_bundler_in_app から呼ばれるここで bundler v1 か v2 かを判別。 https://github.com/heroku/heroku-buildpack-ruby/blob/v207/lib/language_pack/helpers/bundler_wrapper.rb#L183-L192 下の LanguagePack::Helpers::BundlerWrapper#detect_bundler_version_and_dir_name! で、v1 なら 1.17.3、v2 なら v2.0.2 だと決定していた。 https://github.com/heroku/heroku-buildpack-ruby/blob/v207/lib/language_pack/helpers/bundler_wrapper.rb#L194-L204 その後の LanguagePack::Ruby#build_bundler で ‘BUNDLED WITH’ ブロックをゴリッと削除。 https://github.com/heroku/heroku-buildpack-ruby/blob/v207/lib/language_pack/ruby.rb#L788-L790 当該 PR Remove bundler version in Gemfile....

今年の8月から10月の3ヶ月間、総務省の家計調査に協力していました。 Wikipedia によると、 日本国内の家計の支出を通じて個人消費を捉えることができる統計。2002年からは貯蓄・負債についても調査されるようになっており、調査結果は家計収支編と貯蓄・負債編に分けて発表されている。 とのこと。2018年の餃子消費量1位は浜松市とかのアレも、家計調査の結果らしいです。https://www.e-stat.go.jp/ から誰でも利用できるようです。 はじまり 6月終わり頃のある日、突然のピンポンがはじまりでした。話を聞くと総務省から委託された調査員の方で、真面目そうなメガネを掛けたおばさまでした。年齢は60前後と推察しました。対象世帯は無作為に選ばれるらしいです。 私は10年以上家計簿をつけているし（現在はマネーフォワードを利用）、国勢調査みたいなものでしょと軽く考えていたのが想定外のはじまり。 その日はなぜか詳しい説明はなく、後日説明に再訪されることになりました。 ※ 家計調査は訪問を介したコミュニケーションが多いです。オンラインを中心としたコミュニケーションが当たり前になっていると結構重いです。 想像を絶する苦行 後日の再訪で説明をよく聞くと「3ヶ月間毎日、レシートの中身をひとつひとつ全部、紙に記入する」という、想像を絶する苦行でした。そして毎月1日と16日に家計簿を取りに来るという…。予定を合わせるのも大変だし、家計簿を付ける以外のことが出来なくなりそうでした。 ↓ これが1日分です。電子マネーや口座振替による支出は別のページに書きます。昭和か。 ※ 家計簿の記入のしかた（単身世帯用） P8 より引用 さすがに大変すぎるので断ろうとしたら、Web サービスもあるとのこと。え、Web がデフォルトじゃないの？ 調査員の方が経験がなく講習を受けただけ（？）らしく、後日説明に来ることになりました。コミュニケーションが重い…。 loading... 再々訪は2週間後だったでしょうか。どんな説明があるのか少し構えていたら、URLとID、パスワードを書かれた紙を渡されてその日は終わりました。うーむ。 割と断る気満々だったのですが、タイミングを逃したため、とりあえず始めてみるかという気持ちになりました。 家計調査 オンライン回答システム https://www.e-kakei.go.jp/ です。SignUp は出来ません。Angular 製の SPA っぽくて、HTTP/1.1 でした。 最初はトップページの表示が激重でしたが、途中から問題ないレベルまで改善されました。 ↓ 実際に入力したある日の家計簿です。 UI はあまり直感的でないです。例えば上の画面。しばらく経ってから、中央上部の日付をクリックするとカレンダーがポップアップし、他の日に移動できることに気づきました。日付の前後に “<” や “>” のナビゲータがあれば気づきやすいかと思います。 お問い合わせフォームはあったので、いくつか意見は送りました。例えばサイドメニューの「収支検索」でなにか記入して Enter すると、検索ではなくフォームのクリアが実行されるのは直感的でないとか。 あと、セッションタイムアウトが 1 時間くらいだったのは地味に不便でした。 家計調査スタート 実は私はこういうルーティンは得意です。ほぼ毎日マメにレシートやクレジットカード、電子マネー、現金の支出入を記録していました。文句ばかり書いていたのは、理不尽に自分の時間が奪われるから。 カメラによるレシート自動読み取り機能はなかなか良くできていて、文字認識はなんとか使えるレベル。iPhone からの記録はそれなりにスムーズでした。Mac はカメラの位置的に自動読み取りが使えなかったので、iPhone で入力して Mac で分類などを一括編集する必要があり、心折れる人は多い気がしました。 8/16, 9/1,… とそれなりに順調に提出をしていきました。覚えがないのに、10月上期分が提出されていたことは謎でしたが…。 調査員の方へのお知らせは特に必要なく、オンライン上で提出するだけです。 ただ、割と早く提出する必要があるようで、9/1 は午前中に SMS で提出依頼がありました。つらい。入力を溜めると大変そうです。 月末のお便り 家計調査通信という紙のお便りが、毎月末に郵便受けに入っていました。家計調査の方が届けて下さっていたようですが、担当世帯の数はどのくらいか想像すると複雑な気持ちになりました。 毎月お礼の品が届く 家計調査はボランティアですが、月末近くになると宅配便でお礼の品が届きます。価格帯は3000〜4000円くらいでしょうか。なかなか良い品です。ゼリーとジュースは会社で配りました。...

一章一章は短いものの、全部で 34 章もあったので、読み終えるのに一ヶ月ほどもかけてしまった（付録は飛ばした）。 コードが出てきた記憶はなく、依存関係を表す図が多かった印象。 決して初心者向けの本ではなく、『オブジェクト指向設計実践ガイド』[2016-09-22-1] [2017-11-01-1] 程度を理解できる程度のスキルは必要だと思う。逆に言うと、『オブジェクト指向設計実践ガイド』の次に読む本としては良い。 そういう自分も、半分くらいはあまりピンと来ずに読んでいた記憶。 一方で一番自分にが価値があったのは「SOLID原則」のまとめのあたりかな。以下 5 つの原則の頭文字を取ったもの。 ・単一責任の原則（SRP : Single Responsibility Principle） ・オープン・クローズドの原則（OCP : Open-Closed Principle） ・リスコフの置換原則（LSP : Liskov Substitution Principle） ・インターフェイス分離の原則（ISP : Interface Segregation Principle） ・依存関係逆転の原則（DIP : Dependency Inversion Principle） 業務に取り入れられる設計はあったので、良きタイミングで取り入れていきたい。 時間をおいてまた読み返そう。

今まで terraform provider のビルドには、terraform 自体をライブラリとして要求されました。今後は terraform-plugin-sdk を使います。 この PR で移行しました。 Migrate over to new terraform SDK by masutaka · Pull Request #16 · kristofferahl/terraform-provider-healthchecksio ※ https://healthchecks.io はバッチが時間通りに動いたかの監視で重宝しています。 仕事で使っている terraform-provider-heroku の v2.2.1 で知りました。 9/26 にアナウンスがあったのかな？ 知らなかった。 loading... https://www.terraform.io/docs/extend/plugin-sdk.html に従うだけで割と簡単です。tf-sdk-migrator という移行ツールが用意されています。 $ go get github.com/hashicorp/tf-sdk-migrator $ go mod vendor $ tf-sdk-migrator check $ tf-sdk-migrator migrate $ tf-sdk-migrator check (snip) exit status 1 build github.com/kristofferahl/terraform-provider-healthchecksio: cannot load github.com/hashicorp/terraform/helper/schema: open /Users/masutaka/src/github.com/kristofferahl/terraform-provider-healthchecksio/vendor/github.com/hashicorp/terraform/helper/schema: no such file or directory...

※ 会社の esa.io に投稿した記事の転載です。 本番環境で DB の値を書き換えるために、rails runner や rails console を使うことがある。bash もあるかもしれない。 $ heroku run rails r scripts/important.rb -a <App Name> # or $ heroku run rails c -a <App Name> heroku run のログは現在の端末だけにしか出力されない。アプリのログには出力されないため、LogDNA や Papertrail などにも記録されない。 現在の端末を閉じてしまうと、ログが消失するため十分注意すること。 回避方法 ↓ 以下のような非対話型コマンドであれば、run:detached サブコマンドを使うことで、LogDNA などに送ることが出来る。ただし、現在の端末には出力されない。 ・rails runner ・ls ↓ 対話型コマンドは今回の方法は使えない。他の回避方法があるかは不明。 ・rails console ・bash 非対話型コマンドのログをアプリのログに出力する ※ 以下、 を immense-shelf-19179 とします。 run:detached サブコマンドと -t オプションを使う。 $ heroku run:detached -t ls -a immense-shelf-19179 Running ls on ⬢ immense-shelf-19179....

夏休みを利用して読みました。初版は [2016-09-25-1] でじっくり読んで手も動かしたので、本当にさらっとね。 最近は Go のコードをほとんど書いてなくて、Go Modules に追いついている程度でした。ただ、それほど分からない情報もなかったので、ある意味答え合わせにはなった気がします。 例えば拙作の github-nippou で go-bindata から statik に乗り換えた のは、誤りでなかったなとか（P41）。 ちょうど設定ファイルのフォーマットをどうしようとか、置き場所を XDG Base Directory Specification に合わせようとか考えていたので、「2.8 設定ファイルの取り扱い（P45）」もタイムリーでした。 読んでて Interface 使ってコードを Testable にするだとか、HTTP Mock とか、課題をいろいろ思い出しました…。 相変わらずサラッと知識をアップデート出来るので、Go に興味ある人にはオススメの一冊です。

業務でクレジットカード機能を実装した職場の同僚氏曰く、（確か）「始めはピンと来なかったけど、あとで必要なことが全部書いてあると気づいた」とのこと。私は実装には関わってないけど、目線を合わせるために読んだ。 全部を理解しようとせず、概要だけ理解するつもりで読んだ。幸いにもコンパクトに 157 ページにまとまっていたので、気合を入れたら一日で読めた。もちろんピンと来てなくて、1/3 も怪しいかなといったところ。 オーソリゼーション（オーソリ）の実装は必須でそれが通ったら、クリアリング（売り上げ処理）が行われ、最後にセツルメントで加盟店に利用代金が支払われる。 とか、そんな程度。 第1章「決済カード業務の概要と実務」でいきなりつまづいた。 全体的に説明が分かりづらい。対象が初心者向けなのに具体例が少なく、想像しづらいためだと思う。一方で途中のコラムは具体例多めで、理解しやすかった。 第2章「カード決済ネットワークの概要と実務」は、ビザやマスターカードなどの国際ブランドの話から始まり、割と理解しやすかった。特に P104 の図は具体的でとても良かった。こうやって各所収入を得ているのね。 P85 のアクセプタンスの話は少し気になった。 アクセプタンスとは「特定のブランドを付したカードの平等な受け入れ」を表し、加盟店は、ビザブランドカードであればビザのロゴマークを付したカードのすべてを、その利用者がカード発行者と契約した決済方式ークレジット、デビット、プリペイドなどーにかかわらずまったく平等に取り扱わなければならない。いいかえれば、クレジットカードは受け入れるが、デビットカードは受け入れないということは許されない（ただし、オンラインオーソリ専用デビットカードのように、その仕組の制約から一部の加盟店でしか利用できない決済カードはある）。 実際は出来ていないケースも多いと書いてあった気がする。個人で愛用している、プリペイドカードである Kyash は Web 上の決済に使えないことは多いけど、それぞれのサービスがこのアクセプタンスに違反しているってことかな？ 第3章「金融決済用ICカード」はページ数が少なく助かった。とは言え、IC カードの概要や EMV、少額決済スキームが説明されている。読み飛ばさないほうが良いと思う。 2012 年の本なので、ここ一年で広まった QR コード決済や、各国の決済事情なども盛り込んだ改訂版の登場が待たれるところ。 アクワイアラとイシュアが理解しづらかったので、最後に簡単にまとめておく。 アクワイアラはクレジットカードの加盟店の獲得と管理をしており、イシュアがクレジットカードを発行する。歴史的経緯により、日本では同じ会社が兼任することが多いそう（だから分かりづらい）。海外では原則として銀行がアクワイアラとのこと。 ＜セゾン・アメリカン・エキスプレス・カードの例＞ アクワイアラ：ユーシーカード株式会社（クレディ・セゾンの子会社） イシュア：株式会社クレディ・セゾン 国際ブランド：AMEX

職場の同僚氏がオススメしていたので、少し前に読んだ。 私は小さなグループでリーダーシップを発揮した経験はあるが、さすがに何万人もの組織での経験はないため、なかなか興味深かった。反対陣営の筆頭を側近にして、エッジの効いた政策をより良いものに落とし込むエピソードは、なかなか出来るものではない。そもそも会社だとそこまで敵対関係になることはあり得ないし。 他に、比較優位の思考は即仕事で使えるというか、会社でしれっと紹介した。 例えばなにか承認を得ようとする場合、当事者はいかにその案が良いかを説いたり、もしくは案を出すだけで判断を丸投げしたりする。承認者からするとなんとか協力はしたいものの、材料が少なくすぐに判断できない。そもそも他にいくつも承認を求められている。結果として承認が進まないことになりがち。 例えばA案とB案を持っていき、それぞれこのような比較優位性がある、私はこのような理由でこちらを推したいなどと伝えれば、スムーズに行く確率が上がるという話。 本の中では最善と考える案、その対極の案、中間のマイルドな案の3つを出して欲しいとあった。これは組織で働く上で非常に重要な考え方で、仕事が出来る/出来ないにも関わってくる。想像力が非常に重要。最初は難しいが、経験を重ねるとだんだん身に付くと思う。 他にも、先の先まで想像しながら、先手、先手を打っていかなければならないという下りは、ソフトウェア開発における新規機能のリリースや、サーバーの深夜作業などにも当てはまる。 以前の私は、出来ることを全部やってから深夜作業に望むという考えが足りなかった。いろいろ痛い目に合ったおかげで、今は「出来ることは全部やってそれでもダメだったら、仕方がない（今のスキルの上限）。」という考えに変わった。 橋本さんは好き嫌いが分かれやすい人だと思う。彼に限らずそのパーソナリティが好きでなかったとしても、その考え方は別にするべきで、有用であれば参考にすると良いと思う。

追記(2019-02-27): ⚠️ 今後 LogDNA を使うことはないと思う。S3 にアーカイブされるログフォーマットが急に変わったり、S3 のアーカイブが遅れたりされなかったりで、問い合わせをすることが多々あり疲れたため。Papertrail に戻った。私の Tweet も参考になるかも？ Papertrail Free プランでも S3 にアーカイブ可能。しかもアーカイブパスは Athena のパーティション形式 で、アップロードは 1 時間に 1 回という高頻度（※）。 ※ 例えばアーカイブ先を s3://example-logs/ にした場合、以下の形式でアップロードされる。 s3://example-logs/dt=2019-08-01/2019-08-01-00.tsv.gz s3://example-logs/dt=2019-08-01/2019-08-01-01.tsv.gz s3://example-logs/dt=2019-08-01/… s3://example-logs/dt=2019-08-01/2019-08-01-23.tsv.gz s3://example-logs/dt=2019-08-02/2019-08-02-00.tsv.gz s3://example-logs/dt=2019-08-02/2019-08-02-01.tsv.gz s3://example-logs/dt=2019-08-02/… s3://example-logs/dt=2019-08-02/2019-08-02-23.tsv.gz Athena で Table を作るときに PARTITIONED BY ( dt string ) を付与してパーティションを有効にすれば、where dt = ‘2019-08-02’ などで絞り込みができる。当該パーティション以外はロードされないので、高速かつ料金も抑えられる。 LogDNA Free プランだと、Add-on を表示しているときしかログを溜めない。Search Retention の Unlimited Live Tail がそれ。正直使い物にならないと思う。一番安い有料プラン $5/mo にすれば、Search Retention が 7 Days になり、使い物になる。 Free プランだと S3 へのアーカイブは出来ない。有料プランにしても S3 のアーカイブは Athena のパーティション形式ではないし、頻度も 1 日 1 回。...