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

現地で学んだ自動化、セキュリティ、API設計のアイデアと実践~ドイツのPHPカンファレンスレポート 2日目

f:id:g-editor:20161216121939p:plain

こんにちは!ぐるなびエンジニアの宮原です。

2016年10月末に、ドイツ・ミュンヘンで開催されたInternational PHP Conferenceに行ってきました。 1日目の様子はこちら

International PHP Conferenceでは、お土産にPHPバッグをもらいました。ペンや小物を入れるところがたくさんついていたり、ノートPCを保護する機構が入っていたりと、エンジニアには便利そうです。

f:id:miyahara-r:20161122170857j:plain:w300

それでは、2日目のセッションの紹介を始めます!今回は、自動化セキュリティAPI設計のお話が出てきます!

セッション紹介(2日目)

Automating All The Things

@movetodevnullさんによる「なんでも自動化しようぜ!」という発表です。

以下4つの場面で使えるツールと、自動化する具体的な方法が紹介されました。

  • System Configuration
    • Ansible を用いてシステム構成(ミドルウェア)を管理
  • Software Deployment
    • Ansible を用いて以下を実現
      • アプリケーションをサーバにコピーする
      • デプロイしたアプリケーションをアクティブにする
      • 素早いロールバックを可能にする
  • Software Preparation
    • Antを用いて以下を実現
      • ユニットテスト(PHPUnit)を実行する
      • CSS や JavaScript などを最適化する
      • キャッシュを構築する
      • etc...
  • 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日目の夜には、カンファレンス会場が懇親会会場になり、カジノスペースが現れたり、ビールが振る舞われたりしました。

f:id:miyahara-r:20161122150631j:plain

そんな中、私たちは台湾から来たというエンジニアと情報交換していました。 InternationalなConferenceなので、訪問国以外の国の人とも情報交換できるのが魅力ですね。 中国語と日本語と英語が飛び交う、ちょっと不思議なテーブルになりました:D

Post from RICOH THETA. - Spherical Image - RICOH THETA

台湾でもPHPは結構使われているそうです。 個人的興味で聞いてみたGo言語はまだそうでもないとのことでした。

次回は、最終日(3日目)のセッションと、Networkingの様子をお伝えします。お楽しみに!


お知らせ
ぐるなびでは一緒に働く仲間を募集しています。



‘宮原良介’

2010年に大学院を卒業し、新卒で某大手精密機器メーカに就職。2015年の秋、食への熱い思いを持って、ぐるなびへ転職。ぐるなびでは単に開発を行うだけではなく、様々な業務改善を推進するとともに、アジャイル(スクラム)の普及にも尽力している。
パンダ好きのフルスタック気味エンジニア。