YAPC::Fukuoka 2017 HAKATA に行ってきた!!

少し遅くなりましたが…
帰ってブログを書くまでが YAPC !!

前回の YAPC::Kansai 2017 OSAKA ではスタッフでしたが,
今回は参加者として楽しませて頂きました!

Kansai の時は前夜祭・懇親会は参加できなかったので, 今回は参加すべく前日入り.

前夜祭は途中から参加させて頂いたのですが, 着いた瞬間,
(お酒入っててお祭りっぽい分？) 当日をはるかに上回る熱気に驚きました 笑

前日の LT も面白かったですが,
もちろん当日のトークも, 新しい Perl の話, セキュリティの話, テストの話 etc. と
興味深いものばかりでした.

福岡までの旅費を支援して下さった, 学生交通費支援スポンサーの
Farmnote様, こだまリサーチ様, 面白法人カヤック様, サポーターズColab様,
そして, YAPC::Fukuoka 運営の皆様, 本当にありがとうございました!

以下, 話を聞きながらとったなんとなくメモ (+ 見つかったスライド URL) です.

[A] 2017年夏のPerl (charsbar さん)

Perl5 5.26.0 で壊れる可能性

  • encodeing プラグマの挙動 (Filter => 1 を使う)

  • 正規表現中の { の扱い (先頭の場合のみ例外)

    • /\${[^}]*}/

  • @INC から “.” が削除

    • CPAN クライアント と Test::Harness をアップデートすること
    • PERL_USE_UNSAFE_INC = 1 で一時対処可能
    • do と require は ‘./〜’ で指定
    • use lib ‘.’ はカレントディレクトリを最優先させるので良くない → FindBin で対処

Perl5 5.26 の新しい機能

  • レキシカルサブルーチン → モンキーパッチに便利？
  • ヒアドキュメントがインデント可能 (<<~)
  • Unicode 9.0 のサポート (絵文字とか増えた)
  • サブルーチンシグネチャが速くなった
  • @{^CAPTURE} 特殊変数 (キャプチャした結果のリスト)
  • %{^CAPTURE} 特殊変数 (名前付きキャプチャ)

Perl5 5.28 で廃止予定

  • 異種ハンドルの共有は禁止
  • ヒアドキュメントの終端は省略不可
  • 継承元の AUTOLOAD 禁止

Perl6

  • perl, compiler, VM 3 種類のバーション
  • perl6 -V の充実
    • CPAN Testers を Perl6 でもしたい
  • パフォーマンスや安定性の向上
    • 低レベルな (VM 等) が改善
  • テストがないものは実装があっても仕様ではない
    • ドキュメントではなくテスト (ROAST) を確認
  • I/O のテストとドキュメントが用意された → I/O まわりの仕様が決定
  • Unicode サポート
    • Perl6 は特にこだわっている (同じくらい力入れているのは swift くらい)
      • 「」(半角)
      • ×
      • 2乗 (一文字)
      • 1/5 (一文字)
      • ≦ (一文字)
      • 肌色修飾子等の見掛け上の文字数
  • Perl5 ユーザがやりがちなミスは, 実行に教えてくれる (length, \N, etc.)
  • 2017.5 からは Perl5 とは無関係なミスも教えてくれる
  • perl6-js が (Node.js 7.x で) かんたんにコンパイルできる
  • エコシステム？ (840 くらい)
    • Ecosystem Toaster (最近のコミットでどの程度エコシステムが壊れたか確認)
  • Perl6 のモジュール App::Mi6 (panda は開発終了)
  • 最新 zef
  • Rakudo 2017.02 からは 6.c(?) 非互換の nonblocking await が入っている

perl6 を学ぶには

6.c 対応の書籍

  • Perl 6 at a Glance
  • Think Perl 6 (pyton から perl6)
  • Migrating to Perl 6 (perl5 から perl6 7 月半ば)
  • Learning Perl6
  • Perl 6 Fundamentals
  • Searching and Parsing with Perl 6 Regexes
  • Web Application Development in Perl 6 (webapp)
  • Using Perl 6 (初心者向け)
  • Perl 6 Deep Dive (中・上級者▽むけ)

perl6 その他の情報ソース

  • Weekly changes in and around Perl6
  • twitter @perl6org
  • Youtube の Perl6 ビデオ
  • 次時バージョン (github の v6d.pod)

2017 後半の Perl イベント

質疑

  • ‘.’ が消えた理由
    • Debian で tmp にあるパッケージ… (書けなかった)

[A] ウェブセキュリティの最近の話題早分かり (GUEST: 徳丸 浩 さん)

  • 侵入事件の話

メルカリ CDN キャッシュからの漏洩

  • 数年に 1 度ある (別人問題)

  • A さんが見るものを B さんが見てしまったというやつ

  • CDN の仕様をチェック

    • Cache-Control: private

  • (デモ) 徳丸さんが佐藤さんに

    • よくわかる PHP のサンプル (実は脆弱性があるが今回は触れない)
    • キャッシュがよく効くように proxy_ignore_headers を書き換えた
      (nginx で作る簡単キャッシュサーバ構築)
    • 佐藤さんの情報がキャッシュされていて, 徳丸さんが見えてしまう
    • ログアウトされない
    • PHP 側ではセッションを使うとキャッシュ無効になる
      → キャッシュサーバ側で問題があるかは別

WordPress の脆弱性 (6万以上のページが改竄された)

  • アップデートで脆弱性があることが伏せられていた

  • 影響が大きいため, 1 週間遅れで情報公開

  • (デモ) worldpress を改竄

    • ただの HTML から ‘id=1x’ を送る

GMO ペイメントゲートウェイへの不正アクセス

  • 3/7 公開, 3/10 でアップデート

    • 対応としては十分早い
    • でもやられた

  • Struts 2 (S2-045) (中国で盛ん?)

  • 情報キャッチを早く (セキュリティクラスタは早い段階で騒いでいた)

    • アップデート
    • 止める (OCN は一晩止めた)

  • SELinux

  • (demo) ウェブシェルを動かす

    • Content-Type に問題がある
    • shell.js を動かす

Movable Type のプラグイン

  • ケータイキット最新版 における OS コマンドインジェクションの道の脆弱性を利用し, 本件システムへ遠隔操作プログラムを設置

  • (demo) ケータイブログで web-shell を設置

    • ガラケーは機種で解像度が違うので, 画像を加工する機能がある
    • 画像変換のツール？に web アクセス
    • すでにweb shell 設置完了？

    • adminer (PHP の DB 管理ツール) を使う (実際に使れたもの)

      • PHP ファイル 1 つでお手軽

    • convert コマンド (imagemagic) のコマンドパラメータの問題

      • バリデーションしていなかった
      • perl では安全に使える

パイプドビッツの個人情報流出

イプサ (資生堂子会社) のクレカ情報漏洩

  • 決済代行会社を利用していたが, デバッグモードでデバッグログに情報が残っていた

    • 本番モードは情報が出なさすぎる
    • デバッグモードじゃないと解析ができないのでどうしても使いたい (本来はクレカ情報はでないようにすべき)

  • サーバサイドインクルード (Apache 等の機能) の使い方に問題があった

    • コマンド実行できるのでレンサバでは禁止されていることが多い

  • (demo) SSI を利用して侵入

    • XSS は許容する, とかしてしまう
    • js の代わりに SSI を送信
      • サーバ側で web shell を DL

まとめ

  • 原因
    • 設定不備によるもの
    • ソフトウェアの脆弱性
  • どちらにも注意が必要

[B] コンテナを「守る」仕組みから、中身を理解しよう！ (近藤うちお さん)

Rubyist - コンテナとかセキュリティとかの話 - Linux のコンテナは基本的に, 特殊なプロセスとして実装

プロセス

  • fork (複製) → execve(変身) で新しいプログラムを実行

  • プロセスの属性 (/proc 以下で確認できる)

  • fork() と exec() の間で属性を変更してコンテナ的属性を持つように

  • コンテナ : システムコールを用いて OS リソースの隔離, 機能制限, 権限分離をしたもの

ソフトウェア

システムコール

  • chroot(1)

  • unchroot を防ぐ

    • capability (権限を落とす)
    • seccomp
    • pivot_root

Linux namespace

  • OS のリソースを分離できる

  • 一部だけの移動も可能 ($ ip nets exec)

  • (demo) PID を分離

    • Linux::Clone を使用
    • 12 行

cgroup (Control Group)

  • プロセスをグルーピング
  • グループ毎にリソースの状態を確認・制御する機能
  • libcgroup croutpfs からアクセスできる

  • 制御できる対象毎のサブシステムがある

  • fork bomb 攻撃

    • 母艦 OS 全体のプロセス数には上限がある
    • たくさんプロセスを立てて, 全体を止めることが可能
    • rlimit でプロセスツリー毎の制限もできるが…
  • pids subsystem
    • 最大プロセス数の制限
    • 簡単に fork bomb を防げる

kernel capability

  • Linux Kernel Capability

    • root の権限の一部をプロセスに付与・制限
    • 時間セット・シグナル・再起動だけできるとか
    • ケーパビリティセット
    • (e.g.) 一般ユーザで80番をリスンしたい
      • setcap(8) で file capabilityes を与える
      • CAP_NET_BIN_SERVICE (1024 番以下をリスンする権限)
    • (e.g.) 制限付きコンテナ内 root
      • chroot とかできないように

  • Docker でもケーパビリティの設定がある

privileged を安易に使わない

  • privileged で全(?)ケーパビリティを与えることができる
  • seccomp 等で権限は絞りこまれているので簡単には問題は置きない
  • とはいえ, 問題がおきないわけではない

seccomp

MAC

  • Mandatory Access Control (強制アクセス制御)
    (⇔ 任意アクセス権限 - ファイル owner ごとにアクセス権限を絞る一般的方式)
  • SELinux とか

  • DAC 後に MAC のポリシーが適用され, リソースへのアクセスが強制コントロールされる

  • AppArmor (MAC のミドルウェア)

  • docker では docker-default というプロファイルが当てられる

まとめ

  • コンテナは特殊なプロセス
  • docker はいい感じにしてくれる
  • 参考: スイスチーズモデル
  • しっかりと中身を理解してハマりどころを回避しよう

質疑

  • 専用のユーザを使わない利点

[A] はてなブログ最近の開発テクニックと最新の開発風景のご紹介 (hitode909 さん)

point

  • ViewModel
    • (e.g.) サイドバーのクラス
  • React
    • 難しいことは react で
    • 管理画面はクロール不要, 動的なとこが多い
    • propType でデータ構造チェック
    • 文字列ではなくタグ単位で扱える
  • 静的解析
    • デバイス別にちょっと違うのでコピーとかしがち → 静的解析
    • XRT
      • ネスト数チェック → 大きいとこは整理する
      • ブロックの切り出し
    • 不要なフラグ・重複がわかる
  • 表現力の弱いところでは頑張らない
    • perl, js に寄せる
  • 連続的移行
  • 一般的概念

  • 失敗したら戻せる

  • デザイナー

  • 毎日コードレビュー

  • リリース判断 bot (更新, 時間・曜日を考慮)

[A] Web Application Good Error Messages (and Bad Error Messages) (moznion さん)

エラーメッセージ

  • 基本的に人間が読む
  • 異常系の処理

エラーメッセージの用途

  • 状況
  • 解決のてがかり
  • サービスの健康度の指標

エラーメッセージ周りの問題

  • 書き方がいまいち…
  • 後手に周りがち
  • 異常系を書くコスト (軽視されがち)

エラーメッセージの特性

次元

  • 1 次元 (エラーコード, 識別子)
    • 他のエラーとの区別
  • 2 次元
    • 状況 (何が起こっているかの提示)
  • 3 次元
    • リカバリ・再現情報 (対処・解決の手法の提示)

方向性

  • なぜ出すのか → 必要がなければノイズ
  • 何を出すのか (次元にも関連)
  • いつ出すのか (レベル, 量)
    • 失敗すると膨大な量に
  • どこに (誰に) 出すのか (ログ収集, UI)
    • エンドユーザ
    • 開発者
    • ロガー

ライフサイクル

  • 短寿命
    • その場での対処 (e.g. 電波が悪い)
    • 即応
  • 長寿命
    • 根本的な解決に利用
    • ログ・メトリクス的 (エラーの流速を監視してアラート)
    • あとで検索できる

良いエラーメッセージ

  • 何が起きているかわかる (必須)
  • 簡潔であること (好ましい)
  • 対処手段が提案されていること (最高)
    • その場の問題を妥当する
    • 利用者のストレス軽減 → ユーザ体験
  • 解決手段が提案されていること (最高)
    • 根本的修正の助けになるメッセージ
    • 開発者向け
    • 長命ライフサイクル

悪いエラーメッセージ

  • まったくわからない
    • Something wrong
  • どうすれば
    • Inbalid parameter
    • Query is too big
  • 情報量が多すぎる
    • stack trace が膨大
    • クリスマスツリー現象 (エラーで画面がピカピカしてどこから見るかわからない)

真に悪いエラーメッセージ

  • そもそもない
  • 間違えたメッセージ

client 側のエラーメッセージ

  • HTTP Status Code
  • API Response
  • 管理画面上の表示
  • Facebook Graph API
    • API のオープンプラットフォーム
    • fbtrace_id によるエラー情報の提示・トラッキング

server side 側のエラーメッセージ

  • Exit Status

  • git のエラーメッセージは 3 次元的 (解決方法が提案される)

    • 昔 push -f が… (真に悪いエラーメッセージ)

エラーメッセージを書く

  • 次元の高い情報を示す
    • 見た人が泣かないように
  • 目的を明確に
    • 誰が見るのか
    • 出ししぶらない
  • 常に書くのは難しい
    • コストと相談 (ペイするとこは手厚く)

エラーメッセージ翻訳

  • 受け取り手にふさわしい内容に変換
    • サーバ内部エラーをユーザに示す
    • 他のサービスからのエラーをどう返すか
  • client へのエラーメッセージにスタックトレースをつっこむ
    • めちゃくちゃ便利
    • release で無効化するのを忘れないように

[A] cpm (GUEST: 鍛治 匠一 さん)

cpm の特徴

  • 速い
  • ワンライナーでインストール (curl -SL … | perl - install -g)

  • Prebuilt

    • 一度ビルドしたものは取っておく

  • モジュールインストールの機会は増えつつある

    • プロジェクト毎のモジュール管理, Carton の登場
    • CI の浸透
    • インフラのクラウド化

[B] 未来志向のCPANモジュール開発 - アイデアを生み出し実装する方法 (木本　裕紀 さん)

Object::Simple

  • 大きなものから小さなものを切りだす
  • 真似してみる (mojolicious の非同期 IO の仕組みとかわかる)

DBIx::Custom

  • SQL 感覚で使えてコンパクト
  • 大きなものと小さなものの間

Mojolicious::Plugin::AutoRoute

  • 静的なページの get をいちいち書くのは手間
  • auto ディレクトリの中にファイルを配置すれば, 自動的にルーティング
    • Render::Maybe
  • 多言語 (PHP) の機能を Perl に取り込んでみる

GitPrep

  • GitHub 的なやつ
  • Perl 製
  • Mojolicous と cpanm を活用して簡単に
  • git には perl が付いている
  • Perl の互換性を活かせる
  • Perl の強みを活かす

SPVM (static perl virtual machine)

  • 静的型
  • VM で実行

  • Perl から簡単に呼びだせる

  • 数値計算と配列演算の高速化

    • PDL 使う？ XS 使う？ うーん…
      • XS の問題
  • サーバ管理とか Web 開発は得意
  • 数値計算と配列演算は言語使用上向いていない
    • Perl の強みを活かして弱みを弱める

[B] Web API の未来 (Takatsugu Shigeta さん)

Web API の歴史

  • (2010 年〜) REST に対して JSON で返ってくるのが今流
  • (2005 年〜) REST-XML
  • (2000 年〜) XML-RPC (RPC を HTTP で)
  • (それ以前) RPC (外のリソースを使う)

サーバ

  • インターナルからインターネット
  • 共通のフォーマット (json)

クライアント

  • 専用ソフトからブラウザ
  • C から js

REST

  • サーバサイドはシンプル
  • クライアントは複雑 (高速化のため)
    • 非同期 IO
    • ローカルキャッシュ

GraphQL

Operations (3 つの操作)

  • query (データ問い合わせ)
  • mutation (データ操作)
  • subscription (データ更新通知)

事例

  • GitHub

  • Relay (クラサバのフレームワーク, react 使ってうまくやる)

    • 敷居は高くない

      [ client ] ⇔ [ GraphQL Proxy ] ⇔ [ AP server ] [ DB ] [外部サービス]

  • Falcor (中間のレイヤ)

    • クラサバ両方に入れて json でやりとり

Web API の未来

GraphQL のライブラリ

  • JS Ruby PHP は HP 見ればあるが Perl はない
  • GraphQL::Tiny (仮称) を作った

[A] 福岡の IT 企業, 開発現場の未来 (GUEST: 縣俊貴さん, 大谷祐司さん, 小田知央さん, 高山温さん, 田中章道さん)

ヌーラボ

スカイディスク

GMO ペパボ

ピクシブ

  • 創作文化を盛り上げるサービス (pixiv)
  • エンジニア: 150 * 0.7 人
  • 5 人前後でのチーム開発
  • チームでの裁量が大きい
  • みんなでマストドン立ち上げて遊んだり

オンサイト

  • Web の運営 (コンサルではなく, オペレーションまでやる)
    • SNS の運用, EC サイトの運営 (クライアントは発送するだけ)
  • 社員: 15 人 + バイト 30-40 人 + パート (エンジニア？)

(テーマ2) なぜ今, 福岡なのか？

  • サービスの拠点が増えてきて盛り上がってきている
    • 5 年前くらいから (LINE とか大きい会社来てから)

  • web サービスの運営は東京じゃなくてもよい

  • エンジニアが快適に生活できる

    • 大都市よりリラックスできて, コミュニティはしっかりある
    • 自転車通勤とかしやすい

(テーマ3) 将来に向けて, 目指すこと

[B] 新時代のテストフレームワークTest2 (akiym さん)

Perl でテストを書く

  • Test::More
    • 内部で Test::Builder を使用
  • Test::Deep
    • データ構造を複雑に比較したい
  • Test::Fatal (Tet::Exception)
    • 例外が発生した, していない
  • Test::Mock::Guard
    • 特定スコープで処理を変える
  • Test::Warnings
    • 特定のスコープでの warning を捕捉
    • 意図しない warning が出てないか

  • Test::Class

  • 便利にテストしたい

  • モンキーパッチばっかりになる

Test2

  • 5.26.0 以降は 1.30+ が標準で入っている
  • テストのテストがしやすい
  • 拡張しやすい
  • テスト失敗時のレポートがしやすい

  • Test::Builder 自体が Test2::API で書かれている

  • 基本的に互換性あり

    • Test::More はそのままいける

移行の注意

  • use utf ハックはやめる
    • use Test::Plugin::UTF8 を t/test.pm に
  • Test::Class のruntest の自動化はやめる
    • Hook::AfterRuntime を使用する
    • デストラクタを利用した黒魔術
  • Test::Pretty は動かない
  • Test::Warnings は動かない

Test2 でテストを書く (Test2::Suite)

  • use Test2::V0 (string, warnings, 必要なモジュールインポート)
  • is と like で簡単に書ける

  • fail の出力が見やすい

  • mock も書きやすい

  • add, override

  • before, after, around
  • excption, warning

Test2 の注意

  • 乱数のシード
    • T2_RAND_SEED で指定
  • isa_ok と ref_ok

テストをまとめる

  • 1 つ上の呼出し元
    • Test2::API context
  • Test2::Plugin::？？
    • コードを出力？
  • Test2::DeepLike
    • Test::Deep のように使える

スキップしていいテスト、スキップしてはいけないテスト 〜速さと信頼を兼ねたテストコードを構築する術〜 (macopy さん)

  • テストがどんどん肥大化してきてつらい
    • リリース当初 C0 90%
    • 現在不明
  • フルスペックのソシャゲサーバって複雑
  • ついつい便利関数で統合テストしてしまいがち (DB にアクセスとかするとなお遅い)

  • .pm 24 万行 / .t 26 万行

  • もはや「テストを書こう」の時代ではない

    • テストは書いて当然
    • いかに上手くやるか

なぜテスト

  • 更新しやすいのはサーバ側

    • クライアント側は申請が必要 → 遅くなる
    • 重要な部分はサーバ側 (緊急修正はサーバ側)
    • 「独自 API のブラウザ」

  • リリース前にフルテストはかけたい

    • テストには助けられる
      • 新機能 → デグレーション
      • マスタデータのテスト
    • 止まると損失 大
      • ユーザ離れ

  • テストに 30 分もかかる → 失敗できない (デプロイのタイミング制約)

  • (高速化する話)
    https://speakerdeck.com/mackee/need-for-speed-of-testing-in-perl5-web-application

  • Table Driven Test

  • DSL にする

LT 長野雅広 さん

LT Masayuki Matsuki さん

LT 高山温

  • BugBounty.jp を使って脆弱性報奨金制度

LT codehex

  • YAPC::Okinawa 3/2, 3/3 @OIST

LT nasa9084

Sponsor Session

DeNA のエンジニアの話

  • やたらと「そのサービス (機能) 誰が何をしたいのか」にうるさい
    • 誰が使いたいのか
    • ビジネスモデルはどうなのか
  • 障害対応の執念が異常
  • github のコメントスレッドがやたら長い
  • 面接の評価コメントがやたらと詳しい
  • 新しいツールをいつの間にか入れている
  • 結構どっかに出かけていく (楽しそう)

  • イクメンが多い

  • サービスのことを一番に考える

  • 新しいもの面白いものに敏感
  • 丁寧なフィードバック
  • 仕事だけでなく家族も大事に

Keynote: (山本 竜三 さん)

  • ぬーらぼ

    • Backlog
    • Cacoo
    • TypeTalk??

  • NY オフィス

  • NY 生活
    • 物価が高い
    • 雰囲気・治安は良い
    • 英会話大変