例年以上に大盛り上がりのYAPC::Asia Tokyo 2015において惜しくも採択されなかったトークであっても、このような場を作ってでもなお皆さまにお届けすべき価値あるものばかりだと考えておりますので、YAPC::Asia Tokyo 2015の興奮の冷めやらないうちに、第3回目を開催したいと考えました。
...とのことで開催された、第3回ペパボテックカンファレンス 〜 YAPC::Asia PEPABO 2015に参加してきた！
お話を聞きながら、それとなくメモを取ったりしていたのだけど、ガッとまとめる感じにはどうもならなそう・とはいえそのまま esa に溜め込んでおくのももったいないし、ということで、そのメモをそのまま雑に貼り付けておく。ハッシュタグは #pbtech 。
10年動き続けているブログサービスのエンドツーエンドを書いた記録
https://yapcasia.org/2015/talk/show/c9546112-1347-11e5-ad02-d9f87d574c3ayapcasia.org
概要
今年で10年目を迎えた JUGEM(ジュゲム) というブログサービスがあります。
ひょんなことから、このブログサービスのエンドツーエンドテストを自動化しなければいけなくなった私が、どのように考え、実際にエンドツーエンドテストを書いていったか、そして、ぶつかった壁や苦労について紹介していきます。
資料
内容
- プラベートクラウド、nyah
- そこへ jugem を移設
- 自動テストで完全には担保できてない...ならエンドツーエンドテストだ、と
- 新規構築時のチェックリストがテストの元になるもの
- 採用したライブラリ
- Turnip（自然言語でシナリオを書く）
- Capybara
- Poltergeist
- 自然言語でテストを書けることに価値を感じている
- ユーザー視点の言葉で共通の語彙 を持つことが出来る、 前提を共有 できる
- 複数の処理をまとめて、それに日本語をつける とテストが書きやすい（ログインする、とか）
- 「テストを書く過程」の価値。名前付けと識別可能にしていく活動
- ステージング環境やリリース前の本番環境に向けて実行する。 DB に直接接続しないことでテストの価値を上げる
- データの削除についても、画面樹の操作を使って削除するようにする（「登録されていません」と出るまで、みたいに）
- デバッグ用のステップを挟んでおいて、スクリーンショットや html を確認できるようにしたり、 binding.pry できるようにしたり。
- 「ヘッダーの中にあるログインリンク」というような表現ができるように sub_step を書くようにする
- 毎回実行されると困るテストは、rspec のタグの機能を使って制御してる
- 入力してから反映までにラグがある場合、やむなく retriable を使った
- やってよかった点
- アプリケーションの動作をよく理解できた
- step を上手く作れると、新しい step を作らずに feature を量産できる
- つらかった点
- これによりミドルウェアの継続的なバージョンアップも支えられるはず
- 通常の開発サイクルにも組み込みたい
QA
- テストケースの移行、どのくらい進んでいる？
- 全てのテストケースを移行できないことはわかってるので、そこは手でやる。FLASH とか。
- 逆に、350 件全てを移行する必要はある？
- JUGEM チームで必要だと設定している項目なので、やっていこうと。着手順は簡単そうなものからやってる。とはいえ、難しいところともバランスよく進めている。
- 抽象度が高めのテストフレームワークを使っていると、使える人が属人化しそうだが？
- 特に案はないが、 日本語で書けるというのはメリットだ と思ってる。 プログラミング言語だとなんでもできるけど、日本語だと無茶はできない 。テストの外側の語彙を揃えるところを気をつけている。
MogileFSをバックエンドとしたPrivate S3の作り方
https://yapcasia.org/2015/talk/show/3ea83132-1352-11e5-9978-d9f87d574c3ayapcasia.org
概要
写真共有・保存サービス 30days AlbumではオブジェクトストレージとしてMogileFSを利用しています。 そして、そのストレージにS3互換仕様でアクセスするためのWeb APIが 本日 社内向けにリリースされました。
本トークでは総容量700TBを超すMogileFSクラスタの運用苦労話と、そこにどうやってS3互換APIくっつけたのかをご紹介しようと思います。
資料
内容
前半・インフラ編
- いままではオンプレミス
- 大量の画像。各サービスがそれぞれ違った仕組みで独自に構築している
- Nyah 上に各サービスが再構築するのは非効率
- 大統一オブジェクトストレージが求められた
- MogileFS vs OpenStack Swift
- 大規模分散ストレージの運用は甘くないと考えた
- s3 互換の API があるのは魅力だったけど
- Bayt
- api は rails と uncorn
- munin, kibana, BigQuery
- 47 devices / host
- 700 process を超えると親が子からのメッセージに応答しなくなる
- プロセスの優先度を最大に変えたら応答するようにはなったが...
- そんな親から生まれた子も最優先プロセスなので、全体的に高負荷に
- MySQL 5.5 にしたことで実行計画がかわり、使われていなかった index が使われるようになったことが原因
- 不要な index なので drop 、解決
- gateway 、実URL を2つ返すことで、一つ目がダメでも2つ目でフォールバックできる
- mogilefs は同じデータを二箇所以上にストアする特性
- body だけでなく status code も s3 互換に。
- リクエストUUIDを gateway で発行してる
後半・API 編
- S3 API ができることだけを提供 する
- アプリ側にも、 s3 を使うというつもり で設計してもらえる
- いきなり s3 を参考に実装するまえに、 さくらのオブジェクトストレージドキュメントを参考にしながら やった
- s3 をリファレンス実装とする
- s3 へのリクエスト・レスポンスをテスト（request spec）に起こしてから TDD
- 機能を実装しない API でも 501 を返すようにルーティングだけ作るの大事 。
- 別の API にルーティングされてしまうのを防ぐ
- xml の生成、
oxが一番早かった - rails の恩恵は少なめ、もっと早くしたいので...
- Web API サーバとしての Elixir の可能性？
QA
Lightning Talk 01
歴史あるwebサービスに携わって２年半の間に起きた事やった事
https://yapcasia.org/2015/talk/show/fbb5d464-1000-11e5-8165-d7f07d574c3ayapcasia.org
概要
約１０年程続いているWebサービスでPHPerをやっています。 よくあるLAMP環境で構築されたWebサービスです。 このWebサービスに関わって２年半が経ちました。
ロール数は主にメンテされているのが４個。極稀にメンテしているものを含めると１０個程になります。 動いているDBサーバも合計で約１０台前後あり、それなりな規模のサービスです。
入社当時はphpで書かれた独自フレームワーク、素のSQL、一部php4、pearでライブラリをインストールして使っていて、mysql4.0、バージョン管理はsvn+git-svnでした。
今では引き続き独自フレームではありますが、composerを使うようになったり、mysqlをバージョンアップしたり、ローカル開発環境が構築されたり、Eloquent(O/R Mapper)を使うようになったりと、２年もたつとかなり状況が変わってきています。
入社した当時の状況から、今までを振り返り、歴史あるwebサービスが改善されていく様子をお伝え出来たらなと思います。
資料
内容
- カラーミーショップ。10年続くサービス
- 独自フレームワーク。PHP。一部 Rails で api
- 「何かをよくする方法はいろいろある」
- 入社当時
- GHE 導入
- issue, PR。これがないと仕事にならないくらいになった
- PR によりレビューをするように なった（PSR を意識するようになった）
- レビュー
- 毎日交代でレビュー当番
- 共通の認識が生まれるようになる
- 問題点についての会話が増えた
- 問題をどうすればいいんだろう、と考える機会も増えた
- テストの導入
- E2E テストが作られた
- ユニットテスト
- Composer 導入
- 以前はサーバチームに pear の install を依頼してた
- 社内用 compser ライブラリを作成した
- 似たようなロールが4つ、コピペ
- ローカル開発環境
- Vagrant + Puppet
- whenever
- 以前はサーバチームに依頼したり手作業で crontab を編集したり
- MySQL バージョンアップ
- Eloquent ORM の導入
- サンプルを作って共有してみんなに使ってもらえるように
- 何かで修正する際に一緒に書き換え、みたいに広めていった
- FTP -> Bayt
QA
質問してみた。
- レビューしてなかった、テストがなかった、という環境から、レビューをするようになって、それまでの開発速度が下がったりとかは？
- 別件で手を入れる必要のあるところからテストを追加していく、という方法を取った。
- E2E テストを作ろう、とか、レビューしよう、とか、GHE というツールの導入だけじゃそこまでいけないと思うが、どうやって意識が高くなった？
- 周りに Ruby エンジニアがいるなどの環境があり、そことのギャップは常に意識していた。
Q「ツールの導入だけじゃ意識はかわらないと思うが、なにか切っ掛けがあったのか?」
A「Rubyのエンジニアが増えてきて、PHPももっといいかんじにしていこうという気持ちになった」 #pbtech
— けんちゃんくんさん (@kenchan) 2015, 8月 29尋常じゃない速度でドッグフードを食べる方法
https://yapcasia.org/2015/talk/show/f279d804-0efd-11e5-bc53-43ec7d574c3ayapcasia.org
概要
本発表では開発者のためのホスティングサービス Sqaleの運用をしながら、Sqaleの上で動作する新規サービスの開発中に得られた、 尋常じゃない速度でドッグフードを食べていく方法についてお話します。
資料
内容
- Sqale
- カラメルも Sqale で動いてる
- 1ユーザーとしてたくさん使ってみる
- 今までに見えなかったユースケースが見えてくる
- 問い合わせ対応もスムーズに
- GitHub に sqale-support を作った
- public repository
- デプロイ通知などで日々の運用を楽しく
- すぐ対応できるところは自分で直す
- ドッグフーディング以外の観点も大事
QA
- PHP5.4...
今夜、インターネットの片隅で。 〜ウェブサービス開発ちょっといい話〜
https://yapcasia.org/2015/talk/show/1be822d8-0f83-11e5-b022-43ec7d574c3ayapcasia.org
概要
はじめまして！鹿です。 GMO ペパボ株式会社というところで、カート ASP サービスのデザイナーをしています。
ウェブサービスは、エンジニアとデザイナーが一緒になって、やりとりをしながら開発します。 でも、文化もスキルも違う人たちがコミュニケーションを取るのは、難しいときもあります。
そんなインターネットの片隅で、本当に起こった「ちょっといい話」をさせてください。
内容
- デザイナー
- カート画面の再構築
- その人に最適な画面を出してあげたい
- UI を説明するための動画を作った
- 目に見えるものって強い！
- この素晴らしい機能をつくるために何が必要か、という話ができるように なった
- iOS とか、デザインに一貫した世界観がある
- css フレームワークを作った
- 当然の話...
QA
- ポエム、合意をとれなかったが、今度やるときはどうやって合意をとっていきたい？
- ポエムもプロトタイプの一環 と捉える。 誰か一人で作るんじゃなくて全員で作る とか。
Lightning Talk 02
OS X アプリケーション 開発普及活動
https://yapcasia.org/2015/talk/show/28f713a4-fbeb-11e4-9fa6-8ab37d574c3ayapcasia.org
概要
今年も開催されるAppleのWWDCですが、iOSやOS Xとあわせて4000を超えるAPIが発表され、 開発者のためのイベントとして、例年以上にふさわしい内容だったのではないでしょうか。 さらには、Appleから新しくSwiftという言語が発表され、強いインパクトを受けたのはまだ記憶に新しい事だと思います。
しかし、なかなか周りではiOSのことばかりでOS Xの開発をしている人は少なく、はたまた情報も少ない状況です。 なので、開発するにしても敷居が高くなりなかなか手が出せない状況だとおもいます。 本発表をきっかけにして少しでも皆さんにその良さや楽しさを伝えて仲間を増やし、少しでも興味をもっていただければと思います！
内容
- OSX デスクトップアプリの開発について
- Electronェ...
仮想通貨自動トレード記 Part1 〜 国内Bitcoin取引所で裁定取引したら儲かるの？ 〜
資料
内容
- Bitcoin で裁定取引
- node で自動化しようとした話
- バグがいくつかあって損失が...
- slack を連携先にする場合、絵文字を有効活用することで通知内容がわかりやすくなる
Lightning Talk 03
- スピリチュアル枠？
- うずらさんがエンジニアとしてどのように生きてきたのか？
- YAPC::Asia Tokyo でベストトークを取る方法 !
- トークしなければ！ってことはない、しないですごい人の方が多い
- したら楽しい・自分の得になる人はやるべき
- プロポーザルはラブレター！
- タイトル9割
- されど内容も重要
- 興味がない人に興味をもたせ、足を向けさせる
- 前振りでコンテキストを共有
- 予習できるなにか 、大事
- 有名人でも落ちる世界
- 「このトーカーは信用できるか？」を超える必要がある
- 「あなた」というブランドも重要
- 主催者があなたのことを調べるかも、 調べられるに耐えられる「活動」はありますか？
- ある日突然、は無理
- 「ムダな時間にはならなそうだな」と思われる程度には「信用」されよう
- 発表は最低限...
- 聴講者を不安に・迷子にさせない
- 喧嘩は自分に売る 、顰蹙は買わない
- 一番覚えられているトークが勝つ
- 人生そんなもん
- 心を強く保つ
- 地道な人生、エンジニア人生もきっとこんなもん
- 面白い人はやっぱり強い！
QA
- 結局どういうトークがいいのかがわからなかったのですが...。。
- スキームがあるわけではない。あなたが一番喋りたいことを喋るということが前提。
ありがとうございました！
GMO ペパボさん、素敵な環境だと思いました、ありがとうございました！（私用により懇親会には参加せずに失礼しました :bow: ）
なんかわからんがかわいい。 #pbtech pic.twitter.com/dMdV3k2kLR
— いのうえ (@a_know) 2015, 8月 29スリスリくんかわいい。
