Links

今日はYAPC::Asia TOKYO 2015 前夜祭の日です

Posted on August 20, 2015

ビッグサイトの近くまで来ましたので、始まり次第適当に自分用のメモを残しておこうと思います。gihyo.jpさんのレポートも更新されていますので、ぜひご覧くださいませ。

SHIBATA Hiroshiさん 「The story of language development」

  • 最近36協定のチェックとかやってる
  • rubyコミッターで3番目に強い
  • Asakusa.rb
  • 「Rubyのカンファレンスなのでは！」
  • RubyはPerlっぽいところもある
  • 1.8と1.9の超えられない壁
    • 1.8 はmatzさん、1.9 はsasadaさん
    • MRI (海外でよく使われてることば。Matzじゃないのに)
  • Ruby == CRuby の人と、仕様だと思ってる人が居る
    • CRuby, mruby (ISO/IEC)
    • Rubinius の人はCRubyはRubyの一部だと言っている
  • 開発とは？
    • 人、開発、問題、リリース
  • Ruby Commiter
    • キーパーソンは6人
    • Platformごとにメンテしている人もいる (有志が好みの環境で)
    • WindowsのほうがOS Xよりサポート厚い
    • “Ruby Core Team” 海外での呼び名
    • commiterはどこにでもcommitできる - ただし最後まで責任をとる
    • With great power comes great responsibility (スパイダーマン)
  • パッチは手でバックポートされてる
  • セキュリティはジャッジなどが難しい
    • security@ruby-lang.org
  • 基本的には会社での開発と同じ
    • ユースケースは「プログラムが楽しい」
    • リリースマネージャーもいる
    • 怖がらずにRubyに接して欲しい
  • Q. developer meetingとはどういう形式？
    • A. 対面。海外の人が日本語辛いので、透明性確保。毎月matzが意思決定してる
  • Q. コミッター陣で困ってる話は？
    • A. 個人的には、リリースが大変でブラック化してる。他のコミッターに仕事させたい
  • Q. どんな時間にコードを書いてる？どんな機能を実装した？
    • A. 会社のシステムでRubyがバグってたらRubyを直す。という口実で昼間書く。ビルド、gemsなどまわり。gemsのupstreamとの調停
  • Q. お金はどうなってる？ commiterだとRubyを書く機会は減るのでは？
    • A. NaCl, Herokuなどがサポートしている。スポンサーは増えて欲しい。Rubyコミッターの大半はCプログラマ。bundleされているRubyプログラムを書いている

Akira Sakamotoさん 「Perlワンライナー入門」

  • 手軽に掛ける。学習曲線がなだらかですぐ覚えられる
  • ワンライナーを使う人が増えてほしい
  • Perlの得意分野を使い倒している。「テキストデータ」「書き捨て」「10年は無敵」「ライバルがいないから陳腐化しない」
  • 正規表現が協力。特殊変数、構文が揃っていて簡潔。CPANモジュールにアクセス可能
  • テキストデータを相手にする仕事は多い
    • html, csv, ltsv, etc
  • ハンズオン形式
    • grepの代わりに使う -nlE "/zombie/ and print"
    • -n 一行ずつ -l 改行まで -e eval
    • -MURI::Encode=uri_decode
  • 例: sitemap.xmlからリンク切れを探す
  • ログの流れが速すぎる → rand で絞るとか
  • google botの割合を探す HTTP::BrowserDetect
  • フリップフロップで正規表現の間を取るとか
  • Q. デバグがだるいのは神通力が必要？
    • A. デバグが大変になった時点で神通力ない場合はスクリプトにする
  • Q. 他の言語は？
    • A. Rubyとかawkでもいける。Pythonはインデントがきつい
  • Q. おすすめのCPANモジュール
    • A. URLエンコード。SHA1系とか。Time::HiRes

tagomorisさん 「How to Create/Improve OSS Product and Its Community」

  • ユーザーのユースケースと貢献
  • OSSの例
    • 社内のものをオープンに
    • 社内で使いたい、貢献を期待
    • 内部でも外部でも
    • 外部へ広げたい
    • 外部でだけ使う
  • OSSへの影響
    • コアメンバーの違い
    • 社内の人か社外の人か
    • 保守・貢献への影響
  • オープンなチーム
    • パッチの受け入れ手順が明らか
    • 会社による支援(安心感)
  • 言語が与える影響
    • Perlで書くとScalaを書く人は見向きもしない
    • データ処理系はJVMじゃないと
  • バージョン付け
    • 0 は危ない
    • miyagawaさんの0.99は安定？ほかの言語の人には理解できない
  • 英語を使う
    • メモなど。ロシア語だと意味が分からないのと同じで日本語はNG
    • 日本語のpull-reqはrejectするくらいの勢い
  • 質がよすぎるソフトを作るとコミュニティは盛り上がらない
  • contributionについてオープンにあれ
    • issueはソフトウェアにかかわる人を増やす
  • stable、かつ、メンテしていることを常に示すこと
    • Twitter、MLへの返答
  • 日本人だけじゃなく、英語で世界のcontributorを増やす
  • ソフトウェアの特性
    • モジュール、プラガブル → コミュニティができる
  • 良いデベロッパ、会社が作るものは広まりやすい
    • 着眼点がいいとか、理由はきちんとある
  • 最初からみんなが使ってくれるOSSは使えない
    • “Do it, and keep doing it”
  • Q. 出来が悪い状態で出した方がいい？
    • A. そうではない。できる範囲をしっかりやる。レビューのステップとか
  • Q. コンテキストを理解しているとパッチを送りやすい
    • A. きついpull-reqが来た。書き直せと言うことはできる。時間は無限ではないので自分で書くこともある
  • Q. 一番悲しかったこと。嬉しかったこと。印象に残ったこと
    • A. Dockerのログをfluentdにするドライバを書いた。APIがイケてないという話が出て動かなくなった。依存がでかいと言われて書き直した。別のpull-reqはさくっとマージされた。とか。pull-reqのマージは相手の都合があるはず
  • Q. よいOSSの開発とよいソフトの設計の関連はあるの？ 単機能で分割されてると1.0で完成すると活発に見えないのは、ゴテゴテさせるべき？
    • A. fluentdは大きくなってきている。大きくなると別のコンパクトなツールが出るという流れもある。新しいツールが出たときはコアコミッターとなるチャンス。デベロッパコミュニティにはプラスなので、肯定的に捉えていい