Serverless Frameworkというかサーバレスアーキテクチャの話をGeeks Who Drinkで発表してきました #GWD_Nulab

Serverless

@agata さんに良い機会をもらってビール片手に発表してきました！ 🍻

nulab.connpass.com

requestIdleCallback() の話

@anatoo さんの発表。ブラウザ上で様々なリッチアプリケーションが動くようになってどんどん要求が増えていっているのだと思います。

requestIdleCallback() はブラウザのアイドル時間に様々な関数を実行できるというものらしく、Web Workerとの対比でわかりやすく説明してもらえました。

その時には用途を思いつきませんでしたが、Webブラウザ上で実装しているIDEなどには良さ気な機能だと思います。

Cacooの没実装の話

@hiramako さんの発表。没実装になった理由や採用された実装の対比など、とてもわかりやすかったです。その分「かなり苦労して開発してそう」という感想。

それだけにCacoo HTML5は楽しみです。

Kibelaを支える技術

@ihara2525 さんの発表。Blog + Wiki + αなKibelaの紹介。Fusicももっと大きくなったら社内共有サービスをこんな風に拡張すればいいんだろうか。

「技術的挑戦は精神衛生上必要」っていうのは最近特に思います。

Shifterの話

@tekapo さんの発表。Shiferの話でした。すごくスッキリわかりやすかったです。

対応できるWordPress（WordPressはいろいろ拡張できるので）の範囲がどんどん広がることを期待しています。

Serverless FrameworkでAWSフルマネージドなツールをいくつか作って得たアーキテクチャ設計の知見を共有してきました

早口なうえに（おそらく）時間オーバーをしてしまったという詰め込みっぷりでした。

本当はもう少し最後らへんの設計のアイデアの話をじっくり話したかったのですがやはり無理でした。。。

hubedit以外はすべてGitHubでソースコードを公開しているので、アーキテクチャの図と見比べて「あー、こんな感じね」とみてもらえれば。

そして

じゃんけん大会で勝った！！！@anatoo さんありがとうございます！

まだ途中ですがじっくり読みたいと思います！

主催のNulabの皆さん、また発表者、参加者の皆さんありがとうございました！🍻

GitHubのプライベートリポジトリをストレージとして活用したシンプルなメモサービスhubeditを作っている

Serverless GitHub

スマートフォンのブラウザからでもメモが書けるサービス

自分はいつも簡単なメモ書きにはEmacsか、ブラウザを開いていたら wri.pe を使っていました。

wri.pe を使い始めたのは2013年からで、かれこれ4年使っていることになります。

wri.pe で気に入っているところは

  • シンプル
  • スマートフォンのブラウザからもストレスなく使える
  • バックアップが自分がハンドリングできる場所に取れる（wri.peはDropbox）

というところです。

いつでもどこでもブラウザがあれば雑にメモが取れるのが最高です。

ただ、ちょっと困っていることがあって wri.peは最近

  • ノートの検索機能が動かない （微妙に動いている！？）
  • ノートの削除機能が動かない

という状況が続いています。

これが地味に効いてきているので、「自分で作ってみようかな」という気持ちになって作りはじめています。

hubedit

hubedit.com

f:id:k1LoW:20170713071007p:plain

hubeditは wri.pe と同じように

を主眼に置いています。（まあ、つまり「自分が便利に使えるように」ということですね。）

特に「バックアップ」が特徴で、バックアップというよりもむしろバックエンドにGitHubのプライベートリポジトリを使います。

OAuth連携したGitHubアカウントで my-hubedit というプライベートリポジトリを作ってそこをメモの保存場所とする、つまり、メモの操作を全部 git commit ベースで実施するというアーキテクチャです。

GitHubリポジトリということは、当然 git pull して手元のEmacsでメモを作成編集することも可能です。

つまりいつものソースコードのように、ローカルでの編集と git push による同期が可能。便利。

また、せっかくバックエンドがリポジトリなのでディレクトリにも対応しました。

アーキテクチャ

f:id:k1LoW:20170712231630p:plain

いわゆるサーバレスアーキテクチャで構築しています。

HTMLや、そのHTML上のJavScriptが叩くAPIから全てを、API Gateway / AWS Lambdaで実装しています。メモファイルの操作は全部GitHub API v3で操作しています。

とりあえず早く使えるようにしたかったので、今のところ画像は皆無で、CSSやFont、JavaScriptなども直書きか cdnjs ベースにしています（そのうち気が向いたらS3の静的Webサイトホスティングなども活用しようかと思います）。

取得したGitHubのOAuthトークンだけはS3バケットに置いていますが、これもS3バケットのライフサイクルポリシーで1日で消えるようにしています。

ストレージは各々のGitHubリポジトリなので、hubeditの利用をやめたいときはGitHubでOAuth連携をはずすだけで完了です。

まだ微妙な点

  • GitHub API + S3をバックエンドとしているのでレスポンスがもっさりしている
    • DynamoDBをつかったら少しは早い？まあ、あきらめている
  • メモの編集が2コミットに分かれている（削除と追加）
    • ちゃんとコミットを作りたい
  • Vue.jsを初めて使ったので、コードが微妙っぽい。JSファイルの読み込み方法も開発モードのまま
  • UIが雑。ローディングアクションすらない。
  • ロゴがない（またか）

というわけで

個人利用としてはまあ満足です。

とりあえずwri.peのメモを変換して git push したので、このまま本格利用してみようと思っています。

PUBLIC BETAとして公開していますので、興味ある方は自己責任でご利用下さい。

（これってもっとがんばって組んだら、GitHubリポジトリをバックエンドにしたチーム情報共有サービスなんて作れたりするんだろうか。）

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と一緒じゃなくても使えますよ？