読者です 読者をやめる 読者になる 読者になる

2016年の振り返りと2017年の抱負

明けました。

2016年の振り返り

2016年の後半から、Fusicではテックリードという職位ができました(というか、作りました)。

そして、そのテックリードとして活動できた半期でした。

(プライベートでもいろいろあったのですが割愛。)

(ちなみにテックリードに立候補するために、半期の成果をまとめてPullRequestするのですが、そのおかげで半期ごとの成果をあとで拾いやすくて良いです。)

OSS活動

CakePHP3 PluginからCLIツールまでいろいろ作りました。

(新しく作ったものだけで、メンテナンスしているモノは含んでいません)

2016年の前半は koma 、後半は faultline の開発に夢中だったと思います。

どちらもFusicの業態に沿ったニッチなニーズで、世の中になかったことから作ろうと思ったものだったので、作っているときはとてもワクワクしました。

特にfaultlineのインパクトは今現在個人的にかなり大きく、開発サイクルにおいてとても良い効果を出しています。見える化は大事ですね。

発表/受賞 etc

2016年は今までに増してアウトプットしていた気がします。

これ以上増やすためには、インプットを意識して増やす必要がありそうです。

「そもそも増やす必要があるのか?」という疑問もありますが、世の中にはより高い質でより多くアウトプットしている人がたくさんいるので、まあ良いのではないかと思っています。

2017年の抱負

中学生時代のプログラムのソースコードがでてきました。

中学生時代のプログラムのソースコードが出てきた #n88basic

やっぱりプログラムが好きなんだと実感します。

2017年の目標は「チャレンジ」。

既にアラフォーですが、改めて、現状のままを良しとせず、エンジニアとしてより成長をしたいと強く感じています。

そのためには何かしらリスクを取っていく必要がありそうなので「チャレンジ」としました。(まあ、できればチートでジャンプアップしたいところですが)

Fusicでもミッションシートという制度がはじまったのですが、それに釣られてか、こうやって数年ぶりに目標を立てたので、しっかりと意識して結果をだしていきたいと思います。(具体的な数値目標についてはもう少し考えます)

楽しんでチャレンジしようと思います。


以下は、目標とは別で、2017年の早めにやりたいと思っていることです。

開発環境の見直し

新年といえばコレです。

そろそろコンテナを使っていこうと思います(さすがに作りはしない)。

昨年は「時代がDocker飛び越えてサーバーレスとかにならないかなー」とか思ったのですが、まだ無理そうなので遅れないうちに触っておきます。

あと、衰えたEmacs Listp脳をちょっとだけ活性化したい。もう少しEmacsでいたいです。

サーバーレスアーキテクチャ

とはいえ、今最も興味があるサーバーレスアーキテクチャについては、今後の開発における1つの武器(選択肢)としてキャッチアップしていこうと思っています。

  • JWT
  • Amazon Cognito Your User Pools
  • AWS Step Functions
  • GCP
  • SendGrid

特に、fautlineみたいな「Low PriceでManagelessなアプリケーション」のアイデアは社内でも導入もしやすいので、もっと出して業務効率や品質を上げていきたいです。

あと、個人的にAWSにベンダーロックインされていることについてはあまり気にしていないのですが、いろいろなタイミングでGCPの良さを聞くので、GCPは触っていきたいです。

これに関連して、Goもチョットダケデキルくらいにはなりたいなあ。

継続して勉強をする習慣をつける

これが、一番、難しそうです。。。

仕事とお酒に時間を取られている気がするので、うまく時間とやる気を捻出していきたいところですがなかなか難しそうだなあ。。。

というわけで

今年もどうぞよろしくお願いします。

何か良いアドバイスあれば、ブコメやメンション等で、是非よろしくお願いします。

サーバーレスアーキテクチャなエラートラッキングツール faultline

AWS Serverless JavaScript

本エントリーは Serverless Advent Calendar 2016 - QiitaFusic Advent Calendar 2016 - Qiita の7日目の記事です。

今日は AWS re:Invent 2016 Serverless Follow Up がありますね。うらやましい。

サーバーレスアーキテクチャなエラートラッキングツール faultline を作っています。

logo

これは何

AWSのマネージドサービスのみで構築しているサーバーレスアーキテクチャなエラートラッキングツールです。

近いツールとしては、RollbarAirbrakeBugsnagerrbit などがあります。

エラートラッキングのためのAPIバックエンドを提供する faultline と、そのAPIを利用するWeb UIのサンプル実装の faultline-webui があります。

github.com

github.com

Web UI

機能

エラー管理をする上で、最低限の機能を実装しています。

  • エラートラッキング
    • 総数
    • 時間単位総数
    • エラー概要
    • 解決済かどうかのステータス
  • 通知
    • Slackのチャンネルへ通知
    • GitHub Issueへ登録
  • 通知間隔の設定
    • 最初は通知
    • 時間単位総数上限を超えた場合に再通知
    • n回ごとに再通知

なぜ作ったのか

アプリケーションエラーの管理が大変問題

作ったアプリケーションでエラーやExceptionなどがあった場合、 https://github.com/fusic/encounthttps://github.com/k1LoW/Exception を使ってメール通知をしています。

そして、「全てのエラーのメール通知が飛んできてツラい」とか、「どのエラーの解決が終わっているのかの管理ができなくてツラい」とか、よくある問題に遭遇しています(今)。

というわけでなんとかしたいと思っていました。

有償サービスのエラートラッキングツール

多くの有償サービスがあるのですぐにでも使いたいと思っているのですが、いざ会社で導入するとなったとき以下の点でちょっと躊躇しています。

  • どれくらいの費用対効果があるか検証できていない
  • 会社の業務の特性上、1年間だけをみても無数のプロジェクトが立ち上がり、さらにそこから運用フェーズになってアプリケーションとしては残るので、プロジェクト単位の課金だとツラい

正直、健全な方向としては有償サービスを使うべきだとは思っています。(採用するとしたらプロジェクト課金やユーザ課金でない Rollbar かも)

オープンソースのエラートラッキングツール

オープンソースで公開されているerrbitやSentry(OSS)も考えましたが、「サーバーの管理」という別の大きなコストがかかるので、勇気をもって選択できそうになかったです。

サーバーレスアーキテクチャのエラートラッキングツール

欲しい機能としては、

  • 同じエラーをある程度まとめて通知する機能(Slack通知だけでもいい)
  • エラーごとの概要を後から確認できる機能(簡単な時系列のグラフ表示とか)

だけがあればいいかなと思っていて、これにさらに「(ほぼ)管理レス」という無茶要件があったのですが、「もしかしてサーバーレスアーキテクチャで作れるのでは?」と思って試行錯誤してたらできました。

最近v1になったServerless Frameworkを採用することで、AWS Lambdaを中心にS3やDynamoDBも含めて管理できて、少ないコマンドでデプロイできる形に収めることができました。

まずは、サーバーレスなfaultlineの導入をすすめて、もしこれ以上の機能が必要になったら(それは、おそらく効果がでたのだから)、faultlineの拡張をするか、有償サービスを提案しようと思っています。

使い方

faultlineの使い方です。

faultline のデプロイ

まずエラートラッキングをするAPIバックエンドを構築するために falutline をデプロイします。

$ git clone https://github.com/k1LoW/faultline.git
$ cd faultline
$ npm install
$ (Edit ./config.yml)
$ AWS_PROFILE=XXxxXXX npm run deploy

config.yml は config.default.yml をコピーして修正してください。基本的に、S3のバケット名とAPI Keyを設定すればOKです。

npm run deploy まで実行できたらAPIバックエンドのデプロイは完了です。

デプロイ完了時に、StackOutputs に ServiceEndpoint が出力されるのでコピーしておきます。

テストエラー登録

サンプルエラーをcURLで登録してみます。

エラーの登録先URLは POST /projects/{project}/errors になります。ペイロードのサンプルとして sample-errors.json があるのでそれを利用します。

$ curl -X POST -H "x-api-key: [ここにconfig.ymlのclientApiKeyかapiKeyが入ります]" -H "Content-Type: application/json" -d @sample-errors.json [ここにServiceEndpointが入ります]/projects/sample-project/errors

faultline-webui の立ち上げ

次に、Web UIを立ち上げます。Macならローカルで open コマンドで確認可能です。

$ git clone https://github.com/k1LoW/faultline-webui.git
$ cd faultline-webui
$ (Edit ./config.js)
$ open index.html

config.jsはconfig.example.jsをコピーして修正してください。endpoint に faultline の ServiceEndpoint を、apiKey に faultlineのAPI Keyを記載するだけです。

これでWeb UI上でsample-project というプロジェクトにいくつかエラーが登録されていると思います。

通知

faultlineはエラーを保持するだけではなく、通知機能もあります。

Slack 通知

POSTするデータの notifications に Slackの設定を入れて、エラー登録をすればSlack通知ができます。

slack

GitHub Issue 登録

GitHubのIssue登録もUser Token認証限定ですが可能です。

github

費用

ミニマムで$0.1/monthくらいで運用できると思います。AWSの無料枠が残っていたら無料になるくらいのリソース消費量です。

ただ、トラッキングするエラーの流量によってはDynamoDBのキャパシティユニットを増やさないといけないし、保存されているデータも線形で増えていくのでその限りではありません。

Unlimited ProjectsだしUnlimited Users(そもそもUserという概念はない)なので、気にするべきはエラーの流量だけです。

費用がかかってきたら、有償サービスへの移行を検討すると良いと思います。


以下、いろいろと。

faultlineのコンセプト

faultlineを作るにあたって、作っていきたいものを分かりやすくするために、いくつかコンセプトをかかげています。

Simple deploy

構築までに面倒な作業ができるだけないようにしようとしています。

今のところデプロイまでのコマンドは、AWSのクレデンシャルが設定されていれば、config.ymlの作成を含めて5コマンドです。

できれば、これ以上は増やしたくないと思っています。

Manageless

エラー管理を楽にしようとして、結果サーバー管理をするのは本末転倒なので、ここは是非「サーバー管理レス」でいけるようにしたいです。

そのために、サーバーレスアーキテクチャの範囲(AWSマネージドサービスでできる範囲)から超えることなく実装していこうと思っています。

(もし、サーバー管理が必要な機能がでてきたら、その機能は多分あきらめます。)

POST errors with config

"Manageless" にもつながるのですが、1回デプロイすれば、運用時に追加で何か設定する必要がないようにしたいと考えていて、その1つの方法として、"POST errors with config" というアイデアで構築しています。

例えば「Slackのどのチャンネルに通知したいのか」や「どれくらいの頻度で通知したいのか」などの設定は、普通なら管理画面などで設定しそうなものですが、こういう設定をクライアント側からエラー登録と同時に毎回投げてもらう形にしています。

そうすることで、 faultline はエラートラッキング情報は保持しますが、それ以外にはデータを保持する必要がなくなります。

他に faultline が行うのは、エラー情報取得イベント発火時に設定に沿った通知処理などを実行するだけです。

Between "Only mail notify" and "Error tracking services"

あくまで、「エラーメール通知のみの開発の世界」と「有償のエラートラッキングサービスに任せているの開発の世界」の間を狙っています。

本当の「管理レス」は金の弾丸を使った有償サービスなので。

というわけで

最近のプライベートな開発はもっぱら faultline です(そういった意味でもPHPカンファレンス2016で、今までの興味とツールを話し切れたのは良かった)。

実は ServerlessConf Tokyo 2016 のときには、既にコンセプト実装としてある程度動くものができていていたのですが、見せるきっかけも特になく、結局ここまで時間を見つけてはチマチマと作っていました。

実装は、Serverless Frameworkのバージョンアップや、周辺技術の知見の増大や、ふとした思いつきと共に5回くらい作りなおしています。

(最近聞いている boot.fm で k0kubun さんが話していたツールの実装の流れに近い)

今の自分のServerless Framework力、JavaScript力はこれくらいっぽいです。

是非「エラーメール通知のみの開発の世界」から抜けだしましょう。

k1low/xlsx と同じようにPDFを扱えるPHPライブラリ k1low/pdf を作った

PHP

前に作って放置していたのを、ちゃんと整備してCakePHPへの依存性を外してPackagistに登録しておきました。

github.com

k1low/xlsxと同じように、テンプレートになるPDFに文字を書き込んで出力するだけのシンプルなライブラリです。

<?php
use Pdf\Pdf;

$pdf = new Pdf();
$pdf->appendTTFfont('/path/to/ipag.ttf');
    ->read('/path/to/template.pdf')
    ->setValue('あいうえお', ['x' => 10, 'y' => 20])
    ->setValue('6ページ目', ['x' => 10, 'y' => 20, 'page' => 5])
    ->setValue('あいうえお', [
        'x' => 120,
        'y' => 45,
        'width' => 100,
        'height' => 230,
        'fontSize' => 24
    ])
    ->write('/path/to/output.pdf');

TTFフォント以外はcomposerでインストールできるので、導入は楽です。「申込書の出力」などの決まりきったフォーマットの帳票出力には使いやすいかと思います。

こちらからは以上です

PHPカンファレンス2016に参加/発表してきました #phpcon2016

PHP SSH

前回エントリに続き、PHPカンファレンスです。

「.ssh/configを管理する .ssh/configで管理する」というタイトルで発表してきました。

発表後の感想

.ssh/configというかなりニッチな話題でしたが、スライドのブクマ数を見る限りは、発表を見ていない人にも少しは興味を持ってもらえたんではないかなーと思いました。(解決方法になるかは別)

komad(仮)も今後も少しずつ考えていきたいなと思います。

PHPカンファレンス(無印)は規模が違った

7年ぶりに同じ開催場所に来たはずなのに、なんというか規模の大きさを感じました。本当にお祭りという感じ。

満席の発表が出たりするのも凄いなーと思うし、数少ないながらも見れた発表は面白かったし、スポンサーブースの充実度も良かったし、ネットワークは安定しているし、CakePHPは投票1番だし、懇親会では、いろいろお世話になっている人とリアルで会えるし、「これがPHPカンファレンスかー」という感じでした。

スタッフのみなさんありがとうございました!参加者、発表者のみなさんお疲れ様でした!

次回も参加できるように頑張っていきたい。

PHPカンファレンスで.ssh/configについて話します #phpcon #phpcon2016

SSH

7年振りの参加です。

phpcon.php.gr.jp

PHPは自分の主力言語なわけですが、PHPカンファレンスについては「(出力言語だし)スピーカーになれたら参加する」というオレオレルールを課しています。

そんな他人にはよくわからないルールを課していたら「PHPで話すことがない」ためにずっと参加できずじまいでした。

PHPが主力なのにPHPで話すことがないってどういうことなんですかね・・・)

↑のような楽しみをずっとできずにいました。

募集要項がちょっと違った

そんなわけで毎年PHPカンファレンスで話せるネタを探しては諦めていたのですが、今年PHPカンファレンスの募集要項を確認したら以下のような記述が。

トークのテーマは必ずしもPHPの話である必要はありません。JavaScriptの話、HTMLの話、開発環境の話、チームビルディングの話などなど、PHPエンジニアが聞いて面白ければ何でもOKです。

「これはPHPカンファレンス福岡と同じだ!」ということで、さっそくずっとどこかで喋りたかったことを応募しました。

.ssh/configを管理する。.ssh/configで管理する

様々なプロジェクトに関わっていると、自然と様々なサーバへのSSH(公開鍵認証)が必要になり、.ssh/configの管理も必要になります。これを管理する1つの方法、また、逆に .ssh/configを利用してサーバ情報などを管理しようとしている取り組みについて紹介します。

今年のPHPカンファレンスのテーマは"NEXT"ということです。

Docker界隈などで「SSHをしたら負け」と言われはじめている昨今の状況からすると、.ssh/configの話はあまり似つかわしくないかもしれません(言い訳をすると応募当初、今年のテーマを知りませんでした)。

ただ様々な事情からSSHを多用するエンジニアの方は(自分を含め)いますし、これからも .ssh/config と向き合っていく必要性はあると思います。

ただ、「普通に .ssh/configをホームディレクトリに置いてSSHだけをしている」方に、ちょっとだけ"NEXT"に行ってもらえるような話ができればと思います。

ちなみに本当の"NEXT"は多分もっと先か、別な方向なので、サイセンタンな方には物足りないかもしれません。

キーワード

  • .ssh/config
  • サーバ管理

PHPTokyoTyrantの組み合わせについてLTした以来のPHPカンファレンスでの発表!楽しみです! (はい!「TyokyoTyrant懐かしいなー」とか思ったアナタ!是非声かけてください!)

ところで

PHPカンファレンス(本家)が言語の制約を取っ払ったのは今年からですかね?

自分みたいなニッチなことにしかコミットしない(それ以外は普通な)エンジニアにはとてもありがたいです。

少なくとも応募できるのが嬉しい。

buildersconにも応募したかった人生だった。。。

Backlog Favicon ChangerをNew UIに対応させました

Backlog Chrome

nulab-inc.com

というわけで、いつもお世話になっているBacklogにNew UIがやってきました。

ただ、残念ながら今回のアップデートでもファビコンは各プロジェクトのアイコンを反映するものではなかったので、「これはまたBacklog Favicon Changerの出番かな」と思ったらHTMLが変わった結果、見事に動かなくなりました。

というわけでNew UIに対応しました(v0.2.0)(Chromeウェブストアへの反映待ちです)。

chrome.google.com

というわけでニッチですがご利用下さい。

JAWS Festa 東海道2016でawspecとかAWSの構成テストとかについて話します

AWS

登壇者応募をして採択されたので今週末名古屋に遠征します。

楽しみです。

jft2016.jaws-ug.jp

AWSをテスト(?)

タイトルは「Inside of awspec -AWSをテストする方法。そしてその中のはなし-」ということなのですが、 25分という時間なので、内容的には、JAWS-UG福岡:3度目の濃い目にAWSの話をしてみよう - JAWS-UG九州 | Doorkeeper で喋った若干濃い内容を時間に合わせてぎゅぎゅっと濃縮して短くしたうえで、「AWSのリソース構成のテスト(?)」について思うことをしゃべろうと思います。

awspecのメンテナンスをしていると、いろいろなPull Requestを国内外からいただきます。本当にありがたいです。

そのPRから垣間見える「テストツール作ってくせにお前わかっていないな!ここをテストしたいんだよ!」という思いとかは、実際にPRをマージしている自分が紹介すると面白いかなーと思っています。

会社の元名古屋在住の同僚に20,000円オーバーの寿司屋の紹介をされて戸惑っているので、もう少しリーズナブルなところで美味しくご飯を食べたいです。

ぼっちだと思うので是非声かけて下さい!