PHPカンファレンス2015 スペシャルレポート

PHPカンファレンス2015 当日レポート[更新終了]

この記事を読むのに必要な時間:およそ 27.5 分

秋山顕治さん「Electronからクロスプラットフォーム・アプリケーションの歴史を考える」

Electronといえば,Node.jsとChromiumをベースにしたクロスプラットフォームアプリケーション開発プラットフォームとして有名です(旧 Atom-shell)⁠AtomやSlack, kobitoなどのプロダクトのクライアントアプリケーションはElectronが使われています。

秋山顕治さんの発表では,Electronの登場背景からこれまでのデスクトップアプリケーション開発事情とクロスプラットフォームアプリケーション開発の歴史を振り返りました。

画像

ElectronのWebエンジニアにとっての利点とは

Electornの利点は,やはりWebの技術でデスクトップアプリケーションが開発できることが大きいと言います。簡単なアプリケーションならすぐに作れるので,実際に秋山さんが作ったタイマーアプリのデモを示しました。

なぜ今までデスクトップアプリケーションを作ったことがなかったのか?と思い返す

今まではデスクトップアプリケーション開発といえば,Windowsなら.NET系の開発,MacならCocoa系の開発をする必要があり,割と低レイヤーな言語で開発し,それぞれのプラットフォームに対応する必要がありました。このことに付随して次の項目が敷居を上げていたと指摘しました。

  • 新たな言語を学習するコストが高い。
  • 開発環境を用意するコストが高い。
  • デベロッパー登録をしないとインストールできない。
  • あるプラットフォームむけに構築されたソフトウェアは他のプラットフォーム上で動かない。

これが実際に秋山さんのモチベーションにどう関わってきたのかを振り返ります。ちなみに,本発表でのクロスプラットフォームの定義は同じ言語で複数デバイス対応することを指します。

* 古代からの流れを一気に

これまで次のような時代の変遷がありました。

  • OS登場以前(1950年頃): いろいろな実装が乱立していた。
  • OSの確率: ある程度戦争に終止符が打たれ,OSという概念が生まれてくる。
  • ハードウェアおよびOSの乱立: HWやOSが乱立。
  • 2000年代: OSがいっぱいあってもしかたないと,収束してきた。

そして,プラットフォームがある程度の数に収束して,Windows,Mac,Linuxあたりに対応するアプリケーションを作れば良い,という流れができてきました。ただ,収束してきたと言えども,2つや3つのOS向けに開発者を行うのはツライという印象です。

開発者の願いは,"一度書いたら,すべてのプラットフォームで動いて欲しい"

この流れから生まれてきたのがJavaです。またはQtや.NETも生まれてきました。これらは,一度プログラムを書けば複数のOS上で動作するような設計がされてきました。ただ,個人開発を行うには辛く,業務として企業が取り組んでいる印象が強かったと秋山さんは話します。

Web技術の採用の流れ

その後,個人開発でも簡単に作ることができるWeb技術を使ってクロスプラットフォーム開発を行う流れが出始めました。Flash(adobe AIR)やMicrosoft Silverlightはそういった流れから生まれたのでしょう。ただ,Flashに関してはAppleがiPhoneにFlashを採用しなかったことから下火になり,SilverLightもIE上で動作という制約があり,まだまだオープンな形で使えるものがありませんでした。

この頃からのブラウザアプリの流れ

その後2010年に,次の特徴を伴うGoogle Chromeアプリが登場します。

  • Webアプリケーションがオフラインで利用できる
  • ブラウザを開かなくても利用できる
  • 様々なブラウザの機能を利用できる

これらの特徴には魅力的に感じつつも,まだまだChromeという環境に依存することや,専用のランチャーをインストールする必要性,CHrome自体のシェアを考えるとまだ手を出せない印象でした。一方で,既にクロスプラットフォームを前提に構築されているWebブラウザであるChromeにどっかりのっかった点は良い面であったと秋山さんは言います。この時点までいろいろなものが出てきたけれど,⁠俺を動かす情熱には足りない…」とのことでした(笑)

* ここまでの秋山さんの要望

秋山さんの要望をまとめると,次のとおりです。

  • なるべく多くの環境で動作
  • ライトな言語で開発したい
  • 持っている技術の流用か,後に仕事に流用できなそうな技術を採用したい
  • ランタイムのインストールとかしたくない(させたくない)

そこで登場したのがElectron

そして登場したElectronは,次の特徴を持っていました。

  • HTML+CSSでUI構築
  • Javascriptで動作を記述
  • クロスプラットフォームのWebブラウザをランタイムとして同梱

AirやSilverlightはあらかじめランタイムをインストールする必要があったけれども,Electronはランタイム同梱なので,使う側がランタイムインストールなど手間が無く使えます。結果,すべて要望に合致したのがElectronでした。

* Electronはなぜ最初から登場しなかったのか?

Electronはなぜ最初から登場しなかったのか?と述べる秋山さん。Electron登場の条件は以下があったと指摘しました。

  • オープンソースのクロスプラットフォームWebブラウザの登場(chromium)
  • JSのサーバーサイド(実質的にはブラウザ外)実装の登場(Node v8)

Webの技術が拡張されていった結果,Electronが登場したと述べました。

* 秋山さんの要望以上の利点

Electronのメリットとして,次の事柄を挙げました。

  • Node.jsの機能利用(19万以上のnpm)⁠
  • 実質Web開発なのに対象環境をElectronおよびNode.jsのみに絞ることができる。
  • ブラウザの種類についてもバージョンについても気を使う必要がない(ランタイム同梱だから,開発者はほかのを意識する必要が全くない)⁠
  • JSで開発できること。多くのWeb開発者はJSを触っている。
  • Polymerなどはブラウザ互換が肝になっていたけれど,ElectronはChromimに対応していればいいのでクロスブラウザは考えなくても良い。

また,PHPのエキスパートはJavaScriptのエキスパートでもあるよね?と指摘し,ここでやっとPHPconということを思い出したかのような発言が出ていました(笑)

* Electronの欠点

デメリットととして,ランタイム同梱なのがメリットである反面,そのせいでバイナリサイズが大きい(数百MB)というところを挙げました。とはいえ最近のパソコンはそれくらいのサイズならば問題なく使えるものが多く,そこまでデメリットでも無いかもしれないとも述べていました。

具体的にどういったシーンで使えるのか?

そして,Electronは次のようなシーンで使えると紹介しました。

  • "最強のTwitterクライアントを作る"といった流れがあるので,オレオレツールとかいいかも
  • 社内向けのクローズドなアプリケーション
  • クロスプラットフォームなアプリケーション作り(Macしか持ってないけどWindows向けアプリケーション作るなど)

画像

まとめ

本発表は,クロスプラットフォームアプリケーションを取り巻く歴史を振り返り,なぜElectronが登場して,今注目されているのかを考えるものでした。Electron使い,皆さんもデスクトップアプリケーション作ってみてはいかがでしょうか。

久保達彦さん「フリマアプリ「メルカリ」の急成長を支えるエンジニアリング」

久保達彦さんは,フリマアプリ「メルカリ」の成長とともにどのようにエンジニアリングしてきたかについて発表しました。

画像

メルカリのインフラについて

メルカリのインフラは,さくらとAWSのハイブリッド構成になっています。専用サーバはコストパフォーマンスが高く性能自体も高いため,サーバの台数を100台程度で抑えることが可能になっていること。クラウドは突発的な負荷の対応や,試験用,使い捨て用にサーバを確保しやすいなど,柔軟性が高いものになっていると紹介しました。

PHPで高速なAPIサーバを実現

各所で細かくチューニングしていて,機能を絞ったものでも対応できるため,軽量なフレームワークであるdietcakeを使っているそうです。

他にも,高速なサーバを実現するために次に挙げたことを行っているとのこと。

  • キャッシュを使ってなるべくサーバに仕事をさせない。
  • New Relic によるモニタリングをし,速度を監視し問題があれば修正。
  • php-Parallel-Prefork というライブラリで非同期処理を行う。
  • 2015年7月にPHP5.6にアップグレードし,レスポンスが改善。

nginx によるハイパフォーマンスネットワーキング

メルカリのアプリから,HTTPSもしくはSPDYでnginxに接続し,そこからHTTPでApacheとmod_phpで構成されるAPIサーバに接続しにいきます。nginxを多用することで,スケーラビリティが高く,数万もの同時接続を軽快に捌くことができること。また,高速なHTTPS通信を提供していると説明しました。また,今はSPDY/3.1を使用していますが,iOS9の普及率を見てHTTP2に変更する予定だと述べていました。

検索結果のキャッシュ

検索処理はキャッシュを使わないとかなりサーバに負荷をかけてしまうため,なるべくキャッシュできるように努力しているそうです。続きは公開している資料を参照してくださいとのことでした。

SlackでChatOps

デプロイや勤怠管理,アラート通知,CIの手動実行など,様々なことをSlackでできるようにしていると言います。

いろいろなサーバからSlackに通知する際,

  • 各サーバ上のクライアントがIncomming WebhooksのURLを知っておく必要がある
  • 各クライアントで利用している言語がバラバラ ・通知処理を書くのが面倒

といった問題があり,プロキシを立ててそれと通信するクライアントを各サーバに配置することを念頭に,slackboardというライブラリを作ったと紹介しました。slackboardは久保さんが作成したライブラリで,slackboard,slackboard-cli,slackboard-logで構成されます。

slackboard-cliを使うとechoの後に記述した内容をSlackへ通知することができます。

$ echo mercari | slackboard-cli -c tech-test -s slackboard-server:29800

slackboard-logを使うとコマンドが失敗したときにそのログをSlackへ通知することができます。

$ slackboard-log | -c tech-test -s slackboard-server:29800 -- ls hoge~

ゼロダウンタイムデプロイ

以前のデプロイではrsyncを複数回使っていたそうですが,たくさんの500エラーがでてしまっていたそうです。これを解決するために,ngx_dynamic_upstreamというライブラリを使うようにしたとのこと。

プッシュ通知基盤

基本的に外部のサーバと通信するのでとても重かったそうです。そこで,Gaurunを作ってそれを使ってサーバ構成を見直し,nginxにまとめる形に直して対処したとのこと。

ログ分析基盤

ログ容量は1日200GBあると言います。各サーバからfluentdに転送する前にDataTrackというライブラリを使っていたこと。また,Norikraからfluentdを経由して,データの種類によってMackerelとSlackに振り分けているそうです。しかし,ログが分析に適していなくて職人芸が必要だったので,ログを設計し直すことにしたそうです。

Pureeを使うことでアプリからfluentdにログを取得でき,OpenRestyを使うことで高速なWebアプリケーションを作ることができたと紹介しました。PascalはOpenRestyのおかげで,ログのフォーマットを分析に適した形にすることができました。アプリ内アクションやA/Bテスト分析など,適用できる範囲を広げていくそうです。

まとめ

いろいろ工夫して高速なAPIサーバを実現していることが紹介されましたが,来年は7対応をするかもしれないと述べていました。なお,メルカリではエンジニアを募集中とのことです。

席は満席になり常にシャッター音が鳴り響いていて,注目の高さが伺える発表でした。

画像

富所亮さん「Behat Driven Development」⁠

富所亮さんは,現場に自動テストを導入したことについて発表しました。

画像

最初に,富所さん自身の経験から自動テストにまつわる悲しい過去を語りました。

  • 何度も同じ箇所でデグレ。
  • でも,自動テストを追加する工数が取れないと言われる。
  • でも,自動テストのやり方がわからないと言われる。
  • RspecとかCapybaraはRubyのツールだから分からないと言われる。
  • バグが起きた時の再発防止策で「がんばる」とか言われる。

このように自動テストがない状況だったため,作業が積み重なり自動テストを導入したいと考えていたそうです。

そこで,2年前に出会ったのがBehatだと言います。必要なものがすべてBehatにあったそうです。Behat自体はBDDのツールですが,BDDとしては使わずに,単純に自動テストツールとして使っていると紹介しました。TDDやBDDの導入は生半可では回らないので,ひとまず自動テストを導入してみたかったと述べていました。

自動テストには,次のような利点があります。

  • デグレがよく起こる箇所の事前検査
  • ビジネス的に重要な箇所の事前検査
  • テスト手順が煩雑な箇所の検査
  • 放置状態の機能の死活監視

富所さん自身が,個人的に感じる利点としては次の事柄を挙げました。

  • リリースに自信がでる(よく聞く)
  • リファクタリングに勇気がでる(よく聞く)
  • 面接の時言える。
  • 自動テストは,意識高そう。

ただし,現場に自動テストを導入しようとすると,⁠テスティングツールの学習コスト」⁠テストに対するコストが高いと非エンジニアに対して理解を得にくい」⁠テストを書いたことがないエンジニアの精神的な障壁」などの話がよく取りざたされるそうです。このようなことを言う人たちへのケアができていないと,そもそも自動テストというものが受け入れられないと語りました。

次に,自動テストの失敗談について紹介しました。

* ケース1) テスト作れない

テストが作れないという問題。原因としては ⁠テスト自体をやったことがない」⁠テストについて教育や学習の時間が取れない」など。そもそもテストを作れない理由は,⁠教育工数が取れない組織自体に問題」⁠自動テストへの心理的ハードルの高さ」⁠効率のいい運用ができなくて,時間がなくなっていく負のスパイラル」が挙げられる。

* ケース2) 自動テストの遺跡

CIがないとテスト自体が,遺跡になる。プロジェクト開始当初は全員テストを書いても,プロジェクトが佳境になったり緊急対応時にきちんとテストを書かない人が出てくる。

また,特定個人の環境でしか動かないテストも存在し,遺跡になってしまう。これはCIが不在ということが問題。誰の環境にも依存しないところできちんとテストができる環境がないと特定の個人に依存してしまうから,自動テストが回らない。

* ケース3) テストの放置

Jenkinsにテスト実行ログやグラフは出ているが,ただテストを実行しているだけになっている場合。成功・失敗といった結果がメーリングリストに飛んで来くるが,誰も反応しなくなる。最悪,テストが失敗状態でリリースが重ねられると,自動テストされる意味がなくなってしまう。

リリースツールは,テスト失敗時にリリースできない状態を作ってあげないと,自動テストがリリースに影響を与えられない。また,通知がメーリングリストだと他人事になってしまう。例えば,sys-xxx@のような人を特定できないメールアドレスだとそうなる。つまり,自動テスト導入後の運用も含めてトータルに考えないと,あっという間に廃れてしまう。

以上は富所さんの体験談だそうですが,自動テストを押しつけても現場に浸透しなかったと言います。現場における平均レベルのエンジニアが自然と実行できるレベルにまで噛み砕かれている状態でないとうまく浸透しないと話していました。

BDDテストフレームワーク「Behat」

次に,Behatを紹介しました。BehatはBDDテストフレームワークで,Cucumberにインスパイアされています。テストシナリオはGherkin形式で,PHP製とのこと。

Behatは次のような形で使うことができると説明しました。

  • デフォルト状態では何もない。
  • テスト(feature), アサーション(step)は自分で作る。
  • 一般的にはextensionを導入して使う。

そして,テストコードをもとにBehatの使い方を解説しました。Gherkin形式で書かれたfeature(テストシナリオ)にはPHPコードが一切出てきません。step(テストコード)にfeatureで書いたものが割り当てられていきます。

自動テストの成功を阻む要因として次のような事柄が挙げられます。

  • 1. テストツールの教育不足
  • 2. 個人依存のテスト実行環境
  • 3. 導入後の通知や運用ルールの不備

しかし,Behatはバランスが良いため,Behatと現場の相性がよいそうです。上記要因に対して次の効果をもたらすと話しました。

  • 1. テストツールの教育
    • PHP製という強み。
    • Qiitaや,後述の参考資料の内容を1時間程度やれば,十分把握できる。
    • E2Eテスト前提であれば,Mink拡張を利用するだけなので, PHPのコードは一行も書かない。
  • 2. 個人非依存のテスト実行環境
    • Composerでinstall可能。
    • 近代的なCIツールなら簡単に構築可能(前述)⁠
  • 3. 導入後の通知や運用ルール整備
    • 最近のCIツールは通知拡張を備えている(slackとか)⁠
    • テスト失敗時にdeploy出来ないフローにする。
    • PR開発によるコードレビューは相性が良い

近代で自動テストを回すために必要な構成要素はVCS(Bitbucket, GitHub)⁠CI(wercker, Jenkins, Travis CI)⁠Notification(slack, HipChat, idobata)です。これらを正しく扱うことで,テストが実行されてかつテストがOKだった場合のみデプロイが走り通知がされることができ,自動テストが運用できるとのことです。

富所さん自身の自動テストへの取り組み体験をもとにした発表で,とても参考になったのではないでしょうか。

画像

著者プロフィール

大橋勇希(おおはしゆうき)

東京都渋谷区在住。Webアプリケーションエンジニアで,主な使用言語はPHP。最近は,TDD(テスト駆動開発)やDDD(ドメイン駆動設計)に取り組みエッセンスを吸収している。

Twitter:@secret_hamuhamu URLhttp://hamuhamu.hatenablog.jp/


柏原幸治(かしわばらこうじ)

東京都豊島区在住。仕事はブラウザーゲームのバックエンドをPHPで開発している。他の言語もいろいろいじるが,一番長く使ってるPHPが一番使いやすい。

Twitter:@noah0x00
Facebook:https://www.facebook.com/koji.kashiwabara


菅原のびすけ(すがわらのびすけ)

株式会社LIG エンジニア。1989年生まれ。岩手県立大学在籍時にITベンチャー企業の役員を務める。同大学院を卒業後,株式会社LIGにWebエンジニアとして入社し,Web制作に携わる。最近は特にIoT領域,インタラクティブな企画実装などに従事している。

マッシュアップアワードを始めとしたハッカソン等で入賞歴あり。家賃0円クリエイターズシェアハウス第1期生。ジーズアカデミー第1期メンター。LIGinc,HTML5Experts.jp,さくらのナレッジ,gihyo.jpなどでも執筆・寄稿をしている。Milkcocoaエバンジェリスト,特技はわんこそば,趣味は雪合戦。

Twitter:@n0bisuke

LIGincプロフィール:http://liginc.co.jp/member/member_detail?user=nobisuke


中村慎吾(なかむらしんご)

仕事でPHPを使うようになって10数年。楽しい事には何でもやってみるスタイル。趣味が講じて(拗らせて?)会社も作りました。Web開発となるとPHPは手放せません。

Twitter:@n416
URLhttp://kisaragi-system.co.jp


仁多見遼(にたみりょう)

岩手県立大学大学院 ソフトウェア情報学研究科 2年。主にAndroidアプリ開発をしているが,2016年4月から東京でWebエンジニアとして働くことになり,PHPやJavaScriptを書き始めた。いろんなイベントに参加したり,自身でハッカソンを主催するなどイベントが大好きな人。

Twitter:@bird_nitryn
URLhttp://rnita.me

バックナンバー

PHPカンファレンス2015 スペシャルレポート