こんにちは！ぐるなびエンジニアの宮原です。
2016年10月末に、ドイツ・ミュンヘンで開催されたInternational PHP Conferenceに行ってきました。 1日目の様子はこちら。
International PHP Conferenceでは、お土産にPHPバッグをもらいました。ペンや小物を入れるところがたくさんついていたり、ノートPCを保護する機構が入っていたりと、エンジニアには便利そうです。
それでは、2日目のセッションの紹介を始めます！今回は、自動化、セキュリティ、API設計のお話が出てきます！
セッション紹介（2日目）
Automating All The Things
@movetodevnullさんによる「なんでも自動化しようぜ！」という発表です。
以下4つの場面で使えるツールと、自動化する具体的な方法が紹介されました。
- System Configuration
- Ansible を用いてシステム構成（ミドルウェア）を管理
- Software Deployment
- Ansible を用いて以下を実現
- アプリケーションをサーバにコピーする
- デプロイしたアプリケーションをアクティブにする
- 素早いロールバックを可能にする
- Ansible を用いて以下を実現
- Software Preparation
- Antを用いて以下を実現
- ユニットテスト(PHPUnit)を実行する
- CSS や JavaScript などを最適化する
- キャッシュを構築する
- etc…
- Antを用いて以下を実現
- Putting it all together
- Jenkinsを用いて、上記の自動化した項目を、ワンクリックで実現できるようにまとめる
それぞれ実際の設定例や画面例なども一緒に示されています。同じようなツールを使って自動化しようと考えている方は、参考にしてみると良いかもしれません。
エンジニアたるもの、自動化できる作業は何でも自動化していきたいですね！
Application Security: Lessons Learned?!
Webアプリケーションのセキュリティ問題を実例から学ぼう、というセッションでした。発表者は@chwenzさん。
セキュリティ問題の経緯説明だけでなく、実際のソースコードやクエリも紹介されました。具体例が挙がっていてわかりやすいと思った反面、問題発生時のことをイメージできてしまい背筋が凍ったのを覚えています。
セキュリティに問題があったとき、一番被害を受けるのはユーザの方々。サービスが止まるだけでなく、個人情報流出などの問題も起こりえます。本当に気をつけなければなりませんね。
今回の発表スライドではないですが、近い内容のものがありましたのでリンクを貼っておきます。
Web Application Security: Lessons Learned - ConFoo 2015 - Joind.in
The JSON API Spec
REST APIを構築するとき「JSONのデータ構造をどのようにしたら使いやすいか」「エラー時の処理はどうしたら良いか」といった悩みを抱えたことはあるでしょうか。
本セッションでは、@marcoowさんがJSON APIという仕様を紹介してくれました。
JSON API仕様のごく一部を紹介してみます。
- トップレベルメンバーに「data」「errors」「meta」のいずれかを含む必要がある
- 「data」と「errors」は同時に存在してはならない
- リソースオブジェクトはトップレベル以下に定義
サンプルは以下のようになります。
{ "data": { "type": "articles", "id": "1", "attributes": { // ... this article's attributes }, "relationships": { // ... this article's relationships } } }
構造の定義に加えて、データ取得時にパラメータを指定。必要な要素だけを取得し、フィルタリングもサポートしています。
セッションの中ではGraphQLも紹介されていました。こちらはAPIを使いやすくするためのクエリ言語のようです。
ただ、@marcoowさんによると「GraphQLを使う頻度が高くなったり、サブフィルタやHTTP POSTを利用したりすると処理が遅くなる可能性がある」とのこと。一方でJSON API＋HTTPプロトコルを使えば、デメリットなしで同じようなことが実現できるそうです。
さらに、JSON APIのポリシーは「never remove, only add strategy」。仕様がバージョンアップされても互換性の心配がありません。APIのデータ構造の定義に悩んでいる方は、JSON APIも検討してみてはいかがでしょうか。
今回のスライドではないですが、別の機会の近いものを見つけたので、紹介しておきます。
REST, the new SQL?
@spriebschさんが、APIのデザインについて語っていました。
セッションはSQLとRESTの比較からスタートし、発表者はWebサイトの進化スピードは速くなる一方、RDBはそこまで進化していないことを指摘。そこでSQLを使うよりもREST APIやマイクロサービスを構築することで、そのギャップを埋めることができると主張していました。
また、REST APIのデザインは、いろいろな要素に左右されるかもしれませんが、決め手はユースケースであると述べています。
セッションではRESTをレベル分けするためのRichardson Maturity Modelも紹介されました。レベルが高ければ高い（RESTfulの度合いが高い）ほど良いAPIになります。既存のAPI 改修や、これから新しくAPIを設計するときに参考にすると良いかもしれません。
あわせてREST APIを構築する際に「CQRSを考慮することでより良い設計ができる」ということも言及されていました。
スライドはこちらからどうぞ。
懇親会
2日目の夜には、カンファレンス会場が懇親会会場になり、カジノスペースが現れたり、ビールが振る舞われたりしました。
そんな中、私たちは台湾から来たというエンジニアと情報交換していました。 InternationalなConferenceなので、訪問国以外の国の人とも情報交換できるのが魅力ですね。 中国語と日本語と英語が飛び交う、ちょっと不思議なテーブルになりました:D
Post from RICOH THETA. - Spherical Image - RICOH THETA
台湾でもPHPは結構使われているそうです。 個人的興味で聞いてみたGo言語はまだそうでもないとのことでした。
次回は、最終日（3日目）のセッションと、Networkingの様子をお伝えします。お楽しみに！
お知らせ
ぐるなびでは一緒に働く仲間を募集しています。
