くりにっき

フルスタックキュアエンジニアです

Pixela v0.2.0を出した

github.com

https://github.com/sue445/pixela/blob/master/CHANGELOG.md#v020

大きな変更点

Pixelaのエンドポイントをリソースっぽく扱うためのメソッドを作りました

~v0.1.1

# create graph
client.create_graph(graph_id: "test-graph", name: "graph-name", unit: "commit", type: "int", color: "shibafu")

# register value
require "date" 
client.create_pixel(graph_id: "test-graph", date: Date.today, quantity: 5) 

v0.2.0~

# create graph
client.graph("test-graph").create(name: "graph-name", unit: "commit", type: "int", color: "shibafu")

# register value
client.graph("test-graph").pixel(Date.today).create(quantity: 5)

経緯

sue445.hatenablog.com

先日作った時は最速(サービスリリース24時間以内?)で全APIを網羅したクライアントライブラリを出せたことに全く不満はなかったのですが、実際に使ってみるとPixelaのAPIを愚直にRubyのメソッドにマッピングしただけなので冗長な感は否めませんでした。

そこで、aws-sdk に対する aws-sdk-resources みたいな感じで使えるようにしました

何が嬉しいの?

上の例だけだといまいちメリットが分かりづらいですが、メソッドチェーンを分解して変数抽出することによりAPIをたくさん呼ぶ場合でもなるべく同じ引数を何回も書く手間を減らしてます

graph = client.graph("test-graph")

graph.create(name: "graph-name", unit: "commit", type: "int", color: "shibafu")
graph.pixel(Date.today).create(quantity: 5)

v0.1系までのメソッドとv0.2系以降のメソッドでどっちが使いやすいかはケースバイケースだと思うので、古い方のメソッドを消すつもりは今の所ありません。(実際APIのテストコードを書く時は前者の方が書きやすいので)

詳しい使い方はリファレンスを見てください。

https://www.rubydoc.info/gems/pixela/0.2.0/Pixela/Client

Itamae v1.9.12を出した

メンテナ業の報告です

リリースノート

https://github.com/itamae-kitchen/itamae/blob/master/CHANGELOG.md#v1912

v1.9.12の概要

PRを眺めてCIが通れば即マージできそうなPRに対して「遅くなってごめん。LGTMだけどCIがコケてるので最新のmasterを取り込んだらマージするよ(意訳)」ってコメントして、反応があったPRをマージしてリリースしました

リリースノートに書いてる変更内容

jail backend: add support of FreeBSD Jail (itamae jail)

github.com

FreeBSD Jailサポート

docker backend: Fixed edit action of file resource doesn't work with docker backend

github.com

ItamaeのCIを直す過程で見つけたバグの修正。(後述)

itamae docker でfile editできなかったのを修正

github.com

dry run実行時に (dry-run) がつくようになった

リリースノートに書いてない変更内容

WerckerからTravisCIに移行

github.com

  • CircleCIと違ってWerckerはワークフロー設定はymlだけで完結しない(メンテナが設定画面をいじる必要がある)ためPR送る側からすると不便
  • マトリクステストする場合はTravisCI使うのが圧倒的に楽
    • CircleCIでもできないことはないが記述量がTravisCIに比べて多くなる
  • DigitalOceanで立てたVMに対して itamae ssh するのがつらい
    • ssh越しだとCIが安定しない(ローカルのDockerコンテナに対してitamae実行する方がまだ安定する)
    • ssh越しのitamae実行なのでローカルに対してitamae実行するよりも確実にオーバーヘッドがある
    • VirtualBoxのtrusty(ローカル用)とDIgitalOceanのtrusty(CI用)は完全に同一じゃないので、ローカルとCIで挙動が違うのは罠
      • ローカル実行時にもDIgitalOcean使えばいい話なんだけど、アカウント登録して課金しないとVM立てられないのでハードルが高い
      • DockerイメージならローカルとCIで環境を完全に同一にできる
  • 最近の流行だとDockerでCIするのがモダン

みたいな思いを込めて英語でPRのdescriptionを書きました。

かつ、このCIを通すために既存のテストやバグも直しました。

控えめに言って今年一番頑張ったPRでした。

関連エントリ

blog.unasuke.com

マージ後にTravisCIを設定したり、PRをずっと放置してた関係で落ちてたテストを直してようやくmasterブランチのテストが全部通るようになりました。

gemspec更新

github.com

せっかくなので新メンテナの名前をgemspecに追加

今後もマージ後なるはやでリリースしていきたいと思うのでよろしくおねがいします

Pixelaのクライアントgemを作った

Pixelaとは?

blog.a-know.me

pixe.la

このビッグウェーブに乗るしかないと思ってまずはクライアントgemを作りました。ご査収ください

github.com

一応現時点で存在するAPIは全部対応してます。

Packer with mitamaeこぼれ話 #技術書典

Packer with mitamae のおまけというか付録みたいなやつ

sue445.hatenablog.com

副産物

sue445/vagrant-aws

vagrantvagrant-awsvagrant-serverspecがインストールされてるDockerイメージです

https://hub.docker.com/r/sue445/vagrant-aws/

github.com

CircleCI上でVagrantvagrant-awsを使おうとするとvagrant-awsのインストールにそこそこ時間がかかって*1つらかったので、Dockerイメージを自分で作りました。

https://github.com/sue445/dockerfile-vagrant-aws/blob/master/.circleci/config.yml を見てもらえれば分かると思いますが、Vagrantの最新版が出ると自動でDockerfileを更新してtag push&Dockerイメージの自動アップデートをするようにしています。

特定のミドルウェアのDockerイメージを自動更新したい場合に参考になるかと思います。

この辺の最新のバージョンを取得する部分だけ変えてやれば他のDockerfileリポジトリでも流用できるはず。*2

https://github.com/sue445/dockerfile-vagrant-aws/blob/1c73ea65415a649635d36d727519f8441445676e/.circleci/config.yml#L63-L66

packer-provisioner-serverspec

packerでserverspecを使うためのprovisionerです

github.com

https://github.com/unifio/packer-provisioner-serverspec をforkしてるだけなんですが、本家でバイナリを提供してなくて不便だったので自分でビルドしたバイナリをReleasesに置いています。

https://github.com/sue445/packer-provisioner-serverspec/releases

fork元とfork先でコードレベルでの差分はありません。

執筆中に気づいたのですが、Packerはgolang製のバイナリで実行環境に依存しないのがウリなのに、packer-provisioner-serverspecはserverspecを実行するために実行元にRubyがインストールされている必要があるのがイケてないんですよね。。。

provisioner内でDockerのコンテナを起動してその中でserverspecを実行すればまだマシになるとは思ってるのでそのうちなんとかしたいという思いはあります。(思いだけ)

Packer以外の事例だと https://www.npmjs.com/package/serverless-python-requirementsdockerizePip がDockerコンテナ内で pip install しているので同じようなことをやればいいはず。

書名がPacker with mitamaeなのにどうしてリポジトリ名がtechbookfest5-itamaeなのか?

github.com

最初はmitamaeじゃなくてItamaeでやろうとしてたのですが、やりたいこと的にmitamaeの方が筋が良さそうということに気づいて方向転換しています。

途中で方向転換したのがこのコミットです。

https://github.com/sue445/techbookfest5-itamae/commit/5307461804342b1e0af2fac7151da7aa95e06506

途中でリポジトリ名を変えるという手もあったのですが、リポジトリ名を変えた時にCircleCIの挙動がどうなる(再設定すれば勝手に同期してくれるのか、作り直しになるのか)か自信がなかったのでそのままにしてます。

書こうと思ってやめたこと

最初にサンプルプロジェクト( https://github.com/sue445/techbookfest5-itamae )を一通り作ってから執筆したのですが、サンプルプロジェクトにあって紙面にない要素があります

rubocop-itamae

github.com

せっかく自分が作ったものだし一応rubocopの静的チェックを入れてはいるのですが、実際に執筆しようとするとPackerでmitamaeを使うという本質から外れてしまうのでオミットしました。

執筆期間

  • サンプルプロジェクト作成:2週間
  • 執筆:4週間
  • レビュー:1ヶ月間

執筆自体は9月頭に終わっていて、技術書典までの残り1ヶ月間をレビューや当日の準備などにあてています

執筆用のリポジトリのコミット頻度はこんな感じです。

f:id:sue445:20181014170513p:plain

被チェック数

f:id:sue445:20181014170855p:plain

マイページの被チェック数を定期的に取得してスプレッドシートに送りつけてグラフ化してたのですが、技術書典の開催中も被チェック数が増えていて面白かったです。

f:id:sue445:20181014170915p:plain

*1:10分くらい

*2: 実際このリポジトリの設定も https://github.com/sue445/dockerfile-heroku-cli/blob/master/.circleci/config.yml をほぼ流用しています

syobocaliteを作った

しょぼいカレンダー のLite(軽量)版APIクライアントを作りました

github.com

モチベーション

元々は https://github.com/sue445/cure-mastodon-botshttps://github.com/xmisao/syobocal を使っていたのですが、以下のような難点がありました

  • 番組の時間をTime.parse でpaeseしてるので *1、HerokuのようにJST以外の環境で動かすと時間がずれる
  • レスポンスが HashArray なので、レスポンスを利用側で拡張したい時にオープンクラスしてモンキーパッチをあてづらい

1年くらいはアプリ側でモンキーパッチをあてて使っていたのですが *2、別のボットを作る時にcure-mastodon-botsと同じことをやるのが嫌だったのでgem化しました

使い方

Ruby本体の TimeactivesupportActiveSupport::TimeWithZone に対応してます。

require "syobocalite"
require "time"

start_at = Time.parse("2018-10-07 08:30:00")
end_at   = Time.parse("2018-10-07 09:00:00")

# or

Time.zone = "Tokyo"
start_at = Time.zone.parse("2018-10-07 08:30:00")
end_at   = Time.zone.parse("2018-10-07 09:00:00")

# Get programs that start between 8:30 and 9:00
Syobocalite.search(start_at: start_at, end_at: end_at)

http://cal.syoboi.jp/cal_chk.php は日付単位でしか取得できないですが、自分の用途だと時間で絞りたいことが多いので時間を引数に渡せるようにしています。*3

*1:https://github.com/xmisao/syobocal/blob/v0.9.1/lib/syobocal/calchk.rb#L27-L28

*2: https://github.com/sue445/cure-mastodon-bots/blob/cd4940a07e2bd38d2671838e44fe6eac9cf799f7/lib/syobocal_ext.rb

*3: https://sites.google.com/site/syobocal/spec/db-php だと時間単位で取得できるのは知ってるのだけど、そっちは番組名とサブタイトルが同時に取得できないので不便

Itamaeのコミッタになった

いきさつ

blog.unasuke.com

Itamae のCIってここ2年くらいずっと落ちたままになっていて、RubyKaigi2018で仙台にいる時にCIを直しました。

github.com

ずっと放置されつつも id:yu_suke1994id:ryotarai を突っついてくれてPRをマージしてもらい、Itamae *1のコミット権をもらいました

コミッタになってやったこと

Admin権限をもらったのでTravisCIの設定をして、約2年ぶりにmasterブランチのビルドをグリーンに戻しました

f:id:sue445:20181011002905p:plain

ちなみにPRを送りまくってたらいつの間にかコミッタになってたやつはこれで4つ目になります

コミット権をもらったリポジトリ一覧

github.com

github.com

github.com

ポエム:僕とItamae

僕が初めてItamaeと出会ったのが2014年の Infrastructure as Code 現状確認会 でした。*2

その時はItamaeはおろかプロビジョニング全くやったことがない状態でした。

その後なんやかんやでItamaeを使い始めて2015年の Itamae Meetup #1 ではLTをするくらいにはなりました。

qiita.com

その後さらにItamaeプラグインをたくさん作ったり 前職でItamaeを使ったインフラCI を構築したりして、つい先日はmitamae *3 の本を執筆して技術書典5で頒布しました。

sue445.hatenablog.com

プロビジョニングツールはChef, Ansibleと色々ありますが僕はItamaeが一番筋がいいと思っているし好きなので、今後も使い続けていくと思います。ちなみに最近のマイブームはMacの環境構築をmitamaeで行うことです

https://github.com/sue445/dotfiles/tree/master/mac

技術書典が終わって一段落したので、たまったIssueとかPRを読んでマージできるやつはどんどんマージしていきたいと思ってます。(アドベントカレンダーのことは思い出さないようにしつつ)

*1:厳密には https://github.com/itamae-kitchen 全体

*2:イベントページはZusaarなのでもう見れない。。。

*3:Itamaeのmruby実装

Packer with mitamaeのDL販売を始めました #技術書典

技術書典5 お疲れ様でした。

ウインドテイストとしては14年ぶりのサークル参加 *1 でした。

Go*2なので技術書典5にサークル参加できてよかったです。(様式美)

DL版について

BOOTHでのDL版販売を始めました。会場頒布と同様の500円です

sue445.booth.pm

技術書典5のハイライト

他に色々書きたいことはあるんですが疲れすぎてるのでそれはまた後日