YAPC::Fukuoka 2017 HAKATAに前後含めてフルで参加してきました #yapcjapan

Perlは全く書けませんが、YAPC::Fukuoka 2017 HAKATAに参加してきました！

最初から最後までフル参加者！ @akase244 さんとも話しましたが最高でした！（いろんな意味で）

全然野菜

まずは、会社を早めに抜けだして濃い目のイベントYAPC::Fukuoka 前々夜祭(非公式)へ

pepabo.connpass.com

なんか「テレビで見た人だー」みたいな有名エンジニアの人がいっぱいいるし、話している内容も興味深かったです。

やっぱりWebサービスの運用は大変だし、だからいろんな技術で戦っているんだな、と。

一方、受託開発で戦っている自分は、やっぱり octopass の方に興味があって、@linyows さんに「@linyows さんの知らない（であろう）受託開発の世界（という名のユースケース）」を延々と話していました。

前々夜祭で既にビールが入りました。

前夜祭

椅子もありつつ立食でビール飲みながらLTを聞きながら「テレビで見た人だー」みたいな有名エンジニアを見ていました。

atnd.org

うまいぐあいに福岡勢じゃない人と話すことができて最高でした。

「言語オタクで新しい言語を〜」って言いながらPerl6が入っていないのは絶対ツッコミ待ちだったと思います。

自分もギョームと全く関係のないギジュツテキな話をLTでしたら

と言われる始末。プロトコルとかプログラミングの話をしたんだけどなー。

ちなみにスライドの最後はこんな感じでした。

f:id:k1LoW:20170706165419p:plain

！！7月22日、7月28日、福岡 Kieth Flackにてイベントあるので是非遊びに来て下さい！！最高な音をお届けします！！

YAPC::Fukuoka 2017 HAKATA

いよいよ本編。

諸事情により残念ながら実行委員長の開会宣言は聞けずじまいでした。

ただ、関係各所から伝え聞くところによると、「ウケてない」「スベってもいない」「そもそも笑いをとっていない」「普通」「ちょっと声が小さかった」とのことでした。 個人的には倍速LT芸人の力を発揮して欲しかったです。無理か。

セッション

Perlなセッションが多かったので心配だったのですが、そこは言語関係なく「フムフム」「おー」と聞ける楽しいセッションが多かったです。

実は、特に聞くセッションを決めることなくフラフラと移動したり移動しなかったりしてセッションを選択していたのですが、どのセレクトも良かったと思いました。

個人的な印象ですがYAPCのセッションって独特の雰囲気がありました。PHPカンファレンスやRubyKaigiとはまた違った感じでした。言語化できません。

あとSpecial Sessionも良かったです。内容については自分は福岡勢なので「そうだね」という感じなのですが、 @wats さんの絡みでなんか「福岡良い」という感じがしました。これも言語化できません。

ただ、すみません。やっぱり最も印象に残ったのは最後のKeynoteでした。ベストトークの投票最後まで待って良かった。

なんというか是非Togetterとかで他の人の感想もみていただきたいのですが、いろいろとひしひしと伝わってきました。

togetter.com

@dragon3 さんみたいな人がエンジニアとして存在しているからヌーラボさんは強いんだと思いました。

懇親会

他県のPerl Mongerの人たちとCPANの世界の話をずっとしていました。

自分はPackagistとかgemとかnpmとかはリリースしたことはあるのですが、CPANはありません。

他のそれと比べてCPANは敷居が高いイメージがあったのですが、CPAN Authorの皆さんと話してみて、

やっぱり敷居が高いと感じました。CPAN Testersヤバい。プレッシャー凄い。CPANリリースみんなウォッチしているってなんなの。

でも、やってみたい気持ちも生まれました。とりあえず「PHP使えるならPerl使えるよ」という言葉を信じてみようと思います。

2次会は次の日が早い @dragon3 さんを強引に引き止めて少し呑んだりしていました。最高だった。

その後

おもしろイベントがあったみたいなのですが、緊急対応で参加できず。。。

medium.com

感想

最初から最後までフル参加者で、カンファレンス前後含めて全部参加すると最高でした。

YAPCレベル高いなーという印象です。

運営、発表者、スポンサーの皆様ありがとうございました！

octoreleaseのJavaScript版 "octopublish"と、PHP版 "octopackage" を作った

JavaScript PHP

自分はawspecやkomaなど、gemのリリースにずっとoctoreleaseを使っていて、いつも便利さを感じています（mizzyさんありがとうございます）。

k1low.hatenablog.com

特に便利な機能は、関連PRへのコメントとリリースノートのPullRequestへのリンクです。

これは、PullRequestしてくれた人へのお知らせだけでなく自分用のメモとしてもとても重宝しています。

ところが、最近個人的に課題がありました。

octoreleaseは他の言語では使えない

OSS活動をしていて、Rubyでは簡単にできるのにJavaScriptやPHPでできないことにストレスを感じていました。

それがoctreleaseを利用したリリースでした。

というわけで、やっと、それぞれ作りました。

github.com

github.com

使い方はoctoreleaseとほぼ同じです。hubコマンドの利用（~/.config/hub）が前提なのも同じです。

詳しくはREADMEをご覧ください。

言語ごとにリリース方法が違う

今回、otoreleaseの別言語実装を作ってはじめて意識したのが、

各言語でリリース方法（リポジトリへの登録方法）が違うということです。

「使い方はoctoreleaseと"ほぼ"同じです」というのは「同じではない」ということです。

例えば、Rubyでは rake release によって、*.gemspec (正確には *::VERSION )にかかれているバージョン番号でGitHubへtagが振られ、そしてrubygems.orgへリリースされます。一番便利です。

（※今回は簡単にするためにGitHubだけを例に取り上げます）

JavaScriptはGitHubへのtagの登録は自身で行う必要があります。npm publish は package.json のバージョン番号でリリースされます。

PHPもGitHubへのtagの登録は自身で行う必要があります。そして（連携していれば）GitHubのtagと同じバージョン番号でPackagist.orgへリリースされます。

つまり、PHPスクリプトやcomposer.json内にそのライブラリのバージョン番号を示すものがありません。

今回、octopublishとoctopackageでは、そこらへんを個人的な感覚で吸収しました（＝適当）。

Composerプラグインを作ってみた

今回PHP版octoreleaseであるoctopackageを作るにあたって、Hirakさんのスライドと発表映像が本当に役に立ちました。

PHP Conference2016 Track1 (2) Composerプラグインの作り方 - YouTube

この発表は、まさにチュートリアルでした。発表を見ながら順番に実装していくだけでできました。

これはHirakuさんの発表も当然ですが、発表を映像として残してくれたPHPカンファレンスの方々のおかげです。

スライドの行間を体験できました。本当にありがとうございます。

というわけで

誰得というか俺得なわけですが（そして最低限の実装ですが）、octoreleaseと同じ便利さをJavaScirptとPHPで実現できて最高です。

PHPカンファレンス福岡2017でfaultlineについて発表してきました #phpconfuk

PHP

前回とほぼ同じタイトルですが、無事発表してきました。

github.com

実はスタッフとしてもお手伝いさせてもらったのですが、こちらは前日までにピークになる印刷業を担当しているので、カンファレンス自体は比較的楽をさせてもらいました。すみません 🙇 ありがとうございます 🙇

(登壇者視点で) Ask the Speakerが良かった

会場は一番小さいDホールだったので、ほぼ満席の中発表させていただきました。ありがとうございました。

25分で発表を終えたのでその場で質問を受けることができたのですが、その後、Ask the Speakerの席でも多くの方にかなり良い反応をもらえてとても嬉しかったです。

会場での質問のときに「Ask the Speakerの場でfaultline-webuiのデモを見せる予定です」と言ったのが良かったのかもしれません。

かなり込み入った質問をもらったり、POST with configに共感してもらったり、近くで会話できたのが良かったです。

頂いた質問はこんな感じでした。

最低限のAWSリソースの設定でfalutlineを構築したら、どれくらいのエラー通知に耐えられるの？

最低限の設定の場合、DynamoDBのCapacityが支配的になるので1秒間に1回のエラー通知を処理出来ます。

falutlineをインストールするときにAWS KMSのキーなどを事前に作る必要があるの？

いいえ、faultlineのデプロイをするために利用するIAM Userの作成以外で、AWSマネジメントコンソールで何かをポチポチする必要はありません。

faultline / faultline-webui にACLはあるの？

ないです。

ユーザの概念もありません。エラーをPOSTすることができる clientApiKey と全エラーを参照/操作できる apiKey しかありません。

ちなみに、パラメータ名は失敗したと思っています。

fautline-webuiで検索機能をつくれる？

実現可能だとは思います。

ただ、faultlineのストレージには最低限の情報のみだけを格納しているので、それに検索機能を実現しようとするとそれなりにIOコストやCPUコストが必要になって、結果、費用が高くなりそうではあります。

例えば、faultlineのエラーの詳細ログはJSON形式でS3に保存されているので、Amazon Athenaを活用した検索は可能だと思います。が、マニーが飛びそうですね。

PHPカンファレンス福岡2017 After Hack

fusic.doorkeeper.jp

昨年度に引き続き、非公式ながらまたしても開催しました。

ここでもfaultlineのハンズオンをやらせてもらったり、その場でPull Requestをもらったりして最高でした。

実際は上記以外のほうが濃かったです。来てくださった人が界隈で著名な人ばかりで発表も面白かった！

特に @slywalker さんのCakePHPの上に積み上げられたコードは別次元でした。ほんと精進します。。。。

ただ、

今年も！！

無限ビールを達成してしまいました！！

来年もし開催できたら「無限ビール達成できませんでした。。残念」と言いたい。

かかってこい！！

（※注意: 無限ビールを用意しているのは私ではなくFusicです。会社のみんなに感謝）

というわけで

皆さんお疲れ様でした！

PHPカンファレンス福岡2017でfaultlineについて発表します #phpconfuk

AWS Serverless PHP Ruby JavaScript

昨年から faultline というエラートラッキングツールを開発しています。

github.com

PHPの現場 #4 でも紹介されていたRollbarと同じジャンルのツールです。

php-genba.shin1x1.com

faultlineというOSS

fautlineはAWSのマネージドサービスのみで構成されています。

いわゆるサーバレスアーキテクチャなため、サーバ自体の管理は（AWS任せで）不要になり、運用コストも（完全なゼロにはならないですが）限りなく小さくすることができています。

つまり、運用面において、OSSでありながら有料のSaaSに近い感覚で運用ができます。

また、簡単に導入できるようにfautline自体のインストールもシンプルにしています。

さらに各アプリケーションへの導入も、PHPだけでなくJavaScriptやRubyのライブラリも提供することで簡単にしています。

なぜここまで整備をしているかというと、複数のプロダクション環境で実際に運用しているからです。

というわけで

「実際どうなの？運用できているの？」という気になる点について、今週末6月10日に開催されるPHPカンファレンス福岡2017で、“faultline / faultline-php によるサーバ管理不要なエラートラッキングとその効果"というタイトルで発表します。

“OSS"の"サーバレスアーキテクチャなツールの活用” というのはまだまだめずらしいと思いますので、興味ある方は是非。

awspecのための簡易AWSリソース取得ライブラリ awsrm をはじめた

AWS Ruby

AWS Summit Tokyo 2017が開催されている中、皆さんいかがお過ごしでしょうか？

弊社も IoT開発のためのテストサービスであるmockmockを出展しています。

mock-mock.com

皆さん、是非ブースに遊びに来てください。

ちなみに、私は金曜日のAWS Dev Dayに一般参加者として参加予定です。

さて、本エントリは、以下のエントリに対しての実装です。

k1low.hatenablog.com

いよいよAWSリソースの一意特定が難しくなってきた

awspecで上げられたIssueで、現行awspecだとテストが書きにくいものとして

  • Auto Scaling GroupをTerraformで作っているので名前をつけていない。タグでリソースを特定したい
  • Route Tableをテストする際にVPCでフィルタリングしたい
  • SubnetをCIDRでテストを書きたい（名前やIDで特定していない）（必然的にVPCでフィルタリング）

などがありました。

ただ、様々なリソースの様々な特定方法をawspecの各リソースタイプに実装するのは、実装が複雑になりそうなのであまり乗り気ではありませんでした。

とはいえ、「awspecを使う人にSDKを駆使してもらうのを強いるのもなー」と思っていまして、思考が紆余曲折した結果ライブラリとして切り出しました。

awsrm

github.com

awsrmはシンプルで統一したAWSリソース情報の取得方法の提供を目指すライブラリです。

（Relational Mappingとは言えない実装ですが、情報取得の仕方を少し世の中ののORMに似せているので、名前の末尾に rm を付けてみました。）

SDKを直接使うよりも簡単に（でも、できることは少ない）

「統一したAWSリソース情報の取得方法」というのが結構重要で、実はAWSリソースの取得方法はSDKレベルだとそれぞれ似ているけどちょっと違います。

そこらへんを強引に統一することで、awspecを利用するときにあまり考えることなく必要最低限のAWSリソース情報を取得できるようにしています。

例えば、SubnetをVPCでフィルタリングしつつCIDRブロックでテストを書きたいときは one メソッドが使えます。

require 'awspec'
require 'awsrm'

describe route_table(Awsrm::Subnet.one(cidr: '10.0.0.1/24', vpc: 'my-vpc').id) do
  it { should exist }
  it { should belong_to_vpc('my-vpc') }
end

あるVPC内のRoute Tableのテストを一気にしたいときは all メソッドを利用します。

require 'awspec'
require 'awsrm'

Awsrm::RouteTable.all(vpc: 'my-vpc').each do | route |
  describe route_table(route.id) do
    it { should exist }
    it { should belong_to_vpc('my-vpc') }
  end
end

find(:first) とちょっと違う動きの one

awsrmのユースケースは、awspecにおけるリソースの特定ですので、SQLでいう LIMIT = 1 ではリソースの一意な特定ができているとは言えません。

なので、awsrmで提供している one メソッドは、取得結果が0件だったり2件以上だった場合はエラーになります。

というわけで

「awspecでこんな感じでリソースをまとめてテストしたいんだけどなー」と思いましたら awsrm へPull Requestをよろしくお願いいたします！

最後になりますがawspecと一緒じゃなくても使えますよ？

楽しみにしているテック系Podcastまとめ

未再生エピソードがもうありません。

半年以内に配信があった中で、配信を楽しみにしているPodcastをいくつかリストアップしてみます。

目的は「もっとエピソード配信が増える」「もっとテック系Podcastが増える」です。

Rebuild.fm

http://rebuild.fm/

最近のテック系Podcastブームの先駆け。

テック系を通り越して既に別次元のエンターテイメントになっている。

なんでこんなに面白いのかわかりません。でも面白いんです。

mozaic.fm

http://mozaic.fm/

Web技術。毎回濃くて勉強になります。

そのWeb技術をよく知らなかったらmozaic.fmその技術のエピソードを聞いてテンションを上げる方法をとったりします。

最近配信が止まっていますが、まだ凄いWeb技術がでてきたら配信されそうです。

engineer meeting podcast

http://engineer-meeting.tumblr.com/

エンジニアの人たちの話。ゆるい。リアルなエンジニアの人たちの話っぽい話の流れが好きです。

もう3年続いているらしいです。老舗なほうですかね。

「こんばんわ。エンジニアミーティングPodcastでーす。」の入りがクセになっています。

「プロジェクト開発カードゲームを作ろう」のコーナーは是非聞いてみて欲しいです。プレイしたくなります。

のぼりーさんのクラウドインフラPodcast

https://cloudinfra.audio/

クラウド系Podcast。自分の仕事の守備範囲と近い話なのでいつも興味深く聞いています。

Rebuild.fmと並んで、奥さんとドライブ中に聞くことがあるPodcastです。

Frontend Lunch

https://soundcloud.com/hatena-frontend

はてなのフロントエンドのエンジニアの人たちの技術ばかりのPostcast。レベルの高いエンジニアの人たちの話題ってこんな感じなのかなーと思っています。

最近、JSer.infoの話題からはじまるのですが、フロントエンドについていけていない自分としては「あーそういうところに興味を持つのか」と勉強になります。

PHPの現場

http://php-genba.shin1x1.com/

まさにPHPの現場。最も「あーあるある！」ってなるPodcast。あと耳が痛い。「もっと頑張らないと」と思ってしまいます。

boot.fm

https://bootfm.github.io/

話題の範囲や割合がすごく好みなPodcast。

最近更新がないのがちょっと寂しいです。

genba.fm

https://genba.fm/

最近はじまったJavaScriptの現場のPodcast。

らしいですが、フロントエンドに弱い自分にはレベルが高いのかまだ現場感が感じられない感じです。

mosaic.fmとは別の感じで濃くて「次のエピソードはなんだろう？」と楽しみです。

Vue.jsにも興味を持ちました。

以上です。

技術の話が多くて、アニメなど趣味の話題が少ない（もしくは知らない人のために都度噛み砕いている）Podcastが多い気がします。

技術の話は（当然）勉強になりますし、それ以外でも、聞いている間だけでも話題についていけているフリができるようなエピソードが好きみたいです。

オススメがありましたら教えて下さい。

最近のCertman活動またはCHANGELOG

AWS Ruby

日本だけでなく海外の方にも（どこで見つけたんだ？）使って頂いていて、ACMやDNSにおける知識を教えてもらいつつ修正を繰り返してとりあえず一段落した感じです。

前回 からのアップデートをCHANGELOG代わりに記録しておきます。

--remain-resources オプションを追加した

github.com

証明書の自動更新の条件に当てはまらないときのための対応です。

ACMを取得するために利用したRoute53/SES/S3の設定を残しておくというものです。

実はこの条件についてリクエストをもらうまで知りませんでした。ありがたいです。

これをきっかけにできるだけ将来にわたってリソースを残しても問題がなくなるように、 v0.7.0までにわたっていろいろ改修を加えました。

各リージョンでACMを発行しても問題がないようにした

当初はRoute53でも使える証明書が発行できる us-east-1 固定でした。

リクエストをもらって各リージョンでも使えるようにしました。

github.com

その際に不可解な現象に悩まされ（あるリージョンではうまくいくけどあるリージョンではうまくいかない）、 muranushi さんにかなり付き合ってもらいながら改善できました。

ちなみに不可解な現象というのはS3のバケット名のバリデーションがリージョンごとに違ったというものでした。

ワイルドカード指定のドメインや www. なドメインに対応した

やっぱり要望がありました。Pull Requestまでいただきました。

まあ、そうですよねー。

認証用メール用のドメイン（MXレコードの配置）についていろいろなパターンに対応した

認証メールを受け取る方法がいろいろあるので（これもあまり知らなかったです）、いろいろとアドバイスをもらいながら修正をしました。

S3/SESのリージョンをCertman側で指定するようにした

SESは全てのリージョンにはないので、SESがないリージョンでACMの証明書を作成する場合SESは別のリージョンになります。

最初は「別のリージョンにする必要があれば」us-east-1にするような実装だったのですが、これを「ドメイン名をハッシュ関数に渡して、Certman側でSES/S3のリージョンを指定する」ようにしました。

これはCertmenを作成する際に、Certman側でSES/S3のリージョンを知る方法が必要だったのと、リージョンが分散されているほうが有効だと判断したためです。

SESのReceipt Ruleを作成する際に、既存のActive Receipt Rule Setに追加するようにした

SESのActive Receipt Rule Setは各リージョンで1つしか設定できません。当初は新しいReceipt Rule Setを作成してそれに切り替えてACMの認証メールを受け取っていました（終わったら既存のReceipt Rule Setに戻す）。

しかし、これだと認証メールを受け取っている間、既存のReceipt Rule SetにあったRecipt Ruleが動かないという問題あります。

さらに、 --remain-resources を指定してリソースを残してしまうと既存のReceipt Rule Setが適用されないままになります。

なので、v0.7.0からCertman用Receipt Ruleは既存のActive Receipt Rule Setに追加するように修正しました。

認証メールの再送に対応した

github.com

CertmanではACMの認証に必要なリソースを一気に作るので、ときどき認証メールを受け取れないタイミングがあります。 なので、ACMの認証メールを一定間隔で再送するようにしました。

今後対応したいこと

  • 最初のpromtをスキップできようにする（-y オプション)
  • 既存のACM証明書の認証メール取得用AWSリソースを後から作成できるようにする ( コマンド名決まっていない )
  • 証明書のインポートに対応する ( import コマンド )
  • 証明書のステータスを取得する ( status コマンド )

Certmen (ACMの証明書全てを管理する何か) が必要かどうかはいろんな人からフィードバック貰いたいところですね。

ACMの証明書取得方法を忘れたい人は是非利用してみてください。