あんパン

こしあん以外は認めない

yarn-outdated-formatter@2.0.0をリリースしました

yarn outdated --jsonを整形するツールの新しいバージョンをリリースしました。

yarn@1.2.1からyarn outdated --jsonの出力形式が変わり、その対応を入れたバージョンです。(id:wadackelさんにPull Requestいただきました。ありがとうございます!) このリリースでyarn@1.2.0までのサポートを落としたので、メジャーバージョンを上げました。

github.com

yarn自体のバージョンを上げるタイミングを逃しがちで、すっかり変更を見逃していました。まるで現代の紺屋の白袴のよう。。

そして丁度会社的に期末期初でバタバタしており、GitHubの通知も見逃して対応が遅くなってしまいました。申し訳ないです。ぱすたくんからのPull Requestもマージしますと言っていてすっかり対応を忘れていた! ので、近日中にマージしてリリースしようと思います。

ところで、Contributionをいただいた時、どこにその旨を書いておくのが一般的なんでしょうか。CONTRIBUTIORS.mdとかAUTHORS.mdとかを作る感じ?またはCHANGELOG.mdあたりにあると良い? npm releaseしてから、そういえば何か書いたほうが良かったなと思い立ったのでした。追記したいので、こうした方が良いなどアドバイスあれば教えてほしいです。

spec/factories以下に正しいfactoryの定義が存在するのにFactory not registered

結論: springのせい、らしい

spec/spec_helper.rb

Rspec.configure do |config|
  config.before(:all) do
    FactoryBot.reload
  end
...
end

したら直った。もっと良い直し方あるのかなこれ。

spring起因の問題にぶち当たること多くて、世の中のRails使っている人々はみんなこんな思いをして書いているのか気になる。

出典: ruby on rails - ArgumentError: Factory not registered - Stack Overflow

docker-compose run --rm app bundle exec rails cがうごかなかったやつ

これ。

masawada.hatenadiary.com

Dockerfileで

FROM ruby:2.4.2

...

ENV BUNDLE_PATH /bundle

としていたけど、ruby:2.4.2の方はこういう状態で、$BUNDLE_BINがあらぬ方向を向いている状態になってたっぽい?なぜかruby:2.4.1だとうまく行ってたんだけどナ。

正確には、bundler 1.15.4までは大丈夫で、1.16.0からは動かなくなっていた。まだdiff見ていないけどそのあたりでちゃんと各種PATHを見るようになったとか、そういう話かもしれない。

ということで、BUNDLE_PATHを設定するのをやめて、bundle用のvolumeを/usr/local/bundleにマウントするようにしたところ、正常に動かすことができた。

サポーターズさんの勉強会で、はてなブログの開発フローなどの話をします

来る12月20日、サポーターズさん@東京の勉強会にご招待いただき、『はてなブログの実例で学ぶ「はてな流」大規模Webサービス開発の勘所』と題して、はてなブログで実践している開発・運用Tipsなどの話をします。

supporterzcolab.com

完全に煽ったタイトルをつけておいて恐縮ですが、新しいプロジェクト始めるときはちゃんとキックオフしようね、とか、当たり前のことを当たり前にやりましょうね、みたいな、そういうノリの話をします。多分。大枠は決まってるけど、話す内容の詳細は詰めているところです。

プロジェクトを進めるにあたって、当たり前にやった方が良いことを見落としがちだったり、そもそもそういう意識がなくてやらずに進めてしまうことは多いと思います。ので、そういうやつの再確認をしましょうという意味合いがあります(本当か?)。あとは会社やチームによって意識ポイントが違ったりして、そういう差異が確認できて面白いという聴き方もあるかなと思います。どうかな、わからん。

既に15名の方々に参加登録をいただいています。是非みなさんも奮ってご参加ください。基本的に学生を含めた若手エンジニア向けの勉強会なんですが、あまり技術技術した話にはしないつもりでいます。なので若手ディレクタとか若手プランナみたいな人も歓迎です。

暇な人は終わったら近くの鳥貴族とかで打ち上げしましょう。

Google Homeで血圧を記録できるようにした

f:id:masawada:20171011024618p:plain

Google Homeを購入したのは日記に書いたとおり。

ぼくは高血圧ぎみで薬を飲んでいて最近は毎日血圧を測っているのだけれど、億劫で記録はしていなかった。いちいちノートにつけるのは面倒だしスマートフォンを開いてメモアプリを立ち上げるのも挫折した。

Google HomeならIFTTT連携でGoogle Spreadsheetに血圧を記録できるのではないかということに気づいたので、早速やってみた。

Google Assistantをトリガーにして出力先をGoogle Spreadsheetのadd row to spreadsheetに向ける。全体の設定としては以下の通り。

f:id:masawada:20171011022241p:plainf:id:masawada:20171011022244p:plain
IFTTTの設定

これで「ねえGoogle、血圧80の120を記録して」と発話すると、Google Homeが 80の120 の部分を抜き出してGoogle Spreadsheetに記録してくれる。上記の設定だとGoogleフォルダが自動で作られて、その中に血圧マスタというSpreadsheetが作られる。ここのB列に血圧が80 の 120といった形で記録される。

一応CreatedAtを記録するように設定しているのだけど何故かうまく記録されないので、この動画の通りにやる。

www.youtube.com

具体的には、血圧マスタのScript editorを開いて

function addDate(e) {
  var lr = SpreadsheetApp.getActiveSheet().getLastRow();
  SpreadsheetApp.getActiveSheet().getRange(lr, 1).setValue(new Date());
}

このスクリプトを保存してトリガーを追加する。トリガーの設定は以下の通り。

f:id:masawada:20171011022807p:plain
トリガーの設定

ここまでで血圧のマスタが完成する。

f:id:masawada:20171011024201p:plain
血圧マスタにGoogle Homeから入力されたデータの様子

どうも同一のファイルに別シートを追加するとIFTTTでうまく行を追加してくれなくなってしまうようだったので、このマスタとは別にデータを整形するためのスプレッドシートを作成する。

新たなシートを作成してSheet1とSheet2を作成しておいて、Sheet2の方にはA1のセルに=IMPORTRANGE("https://docs.google.com/spreadsheets/.../edit","Sheet1!A:B")を入力する。URLの部分は、血圧マスタのスプレッドシートのURLを入れる。これで血圧マスタから整形用シートのSheet2に全く同じデータを取り込むことができる。

Sheet1にはA列が時刻、B列が下の血圧、C列が上の血圧という感じで整形してデータを入れる。1行目には見出しを書いておいて、A2には=Sheet2!A1と入れる。B2には=IF( ISBLANK(Sheet2'!B1) , "", SPLIT(Sheet2!B1, " の "))と入れる。最後にA, Bそれぞれの列について下の方まで内容を複製する。セルを複数選択してcmd+dで複製することができる。A1とかB1とかの数字部分が行に応じて勝手に書き換わってくれて便利。

これでデータをうまく整形できたかと思う。

f:id:masawada:20171011024618p:plain
整形後の血圧の様子

あとはやる気の問題だけなので頑張って声を張って毎日血圧を記録していこう。


追記: Google Homeの認識がちょいちょい変わって、「80の114」というと「80 - 114」だったり「80 の 114」だったりするので、スクリプト部分を少し変えました。

function formatRow(e) {
  var sheet = SpreadsheetApp.getActive().getSheetByName('Sheet1');
  var lr = sheet.getLastRow();
  
  sheet.getRange(lr, 1).setValue(new Date());
  
  var value = sheet.getRange(lr, 2).getValue();
  var formattedValue = value.toString().replace(/\s(から|-)\s/, ' の ');
  sheet.getRange(lr, 2).setValue(formattedValue);
}

自分のサイトを作り直した

https://masawada.me

もともとGitHub Pagesで管理していたが、そろそろHTTPSで配信してもよかろうと思い立ってCloudFront+S3で配信することにした。おおよそいつもの構成。

↓このリポジトリで管理していて、masterにコミットが追加されるとCircle CIで勝手にビルドしてデプロイする。いままでHTMLとCSSをベタで書いてたけどEJSとSass使うことにした。みどころはそれくらいなはず。見た目自体は全く変えていないけど中身は丸々書き直した。

設定にあたっては、307 Temporary RedirectでS3のURLに飛ばされて困った。正確にはbucket-name.s3.amazonaws.comがデフォルトでus-east-1を向いていて、実際のS3 bucketのregionと異なる場合はリダイレクトされるという仕様にハマって困った。

CloudFrontのoriginをS3に設定するとbucket-name.s3.amazonaws.comに自動で向くのでS3 bucketのregionがus-east-1以外のときに307が発生する。そのため独自ドメインをCNAME(Route 53ならAレコードのaliasでも)でCloudFrontに向けるとS3のURLへのリダイレクトが発生して期待通りにアクセスできない。

bucket-name.s3.amazonaws.comがus-east-1に向く設定はユーザからは変更不可能(のはず?)で時が経つと勝手に適用されるとのことなのだけど、数時間たってもなぜかうまくいかなかった。

masawada.meは東京リージョンのS3 bucketを使っているので、今回はbucket-name.s3-website-ap-northeast-1.amazonaws.comというようなURLをCloudFrontのoriginとして設定したところうまく見られるようになった。

若かりしころはFetchというFTPクライアントでちまちまHTMLとかをアップロードしていたので、こういう構成の静的ウェブサイトを作るときはいつも隔世の感を感じながら作業している。