• Home
• About
• Contact
• Archive

今日は YAPC::Asia Tokyo 2014 の１日目です

今日からが本番です。これから会場に入ります。

本日も一部の内容は gihyo.jpさん にも掲載していますので、併せてご覧ください。

オープニング / yusukebeさん

• みなさんが作る会です
• JPAの“和田”さんです
• “There is MORE THAN ONE WAY to enjoy it!”
• 無限コーヒーあるよ！ かき氷もレッドブルも
  • スピーカーと話して欲しい
  • 仕掛けは用意したので、みなさんで交流してください
• イベントホール以外飲食禁止
• ポータブルWifiの電源はOFFに！
• 同時翻訳あり。機械は無くさないように
• ベストトークの投票してね
• ハッシュタグは #yapcasia 。ブログもね！

Satoshi Suzukiさん「インフラエンジニア(狭義)は死んだ 」

• プログラミングスキルのないエンジニアは死ぬのか
• フルスタックエンジニアになろうという話ではない
• 開発についていけない人がなるもの？
  • コードを書かないイメージが持たれていることが多い
• 2年くらい考えて色々やってみた
  • 2008年から、2年くらい金融系の仕事をやっていた
  • C++、Java、PHP、で挫折 → 思い直した、という話
• インフラエンジニアとは？
  • システムスタック: データセンタ、電源、ネットワーク、筐体、OS、データストア、言語、アプリ(サーバ、WEB)、フロント
  • インフラエンジニアは筐体周りまで？ OSとデータストアくらいまで？ → 多様
  • WEBサービスの開発現場の人が今日のトークの対象
• インフラエンジニアの今後
  • 運用をデータホテル、ハートビーツなど、外部にお任せ。あまりデータセンターに行かない
  • AWS、GCEなど、クラウドの理由。監視など、基本的なやることは変わらない
  • ソフトウェアの力で解決できることが拡大した
  • Nagios exchenge にプラグインが公開されている → 書けないと拡張できない
  • Fluentd → これも拡張を書く必要あり。Ruby以外でも拡張できる
  • Immutable Infrastructure, Disposable Infrastructure, Infrastructure as a Code → ソフトウェアの力
  • コードを書けないインフラエンジニアはダメなのでは
• Operation Engineers Casual Talks という勉強会をやった
  • tagomorisさん「自称は自意識に影響を与える、解決すべきことはなにか、分業は不可能、問題はコードで解決」(ほげエンジニアの定義について、より)
  • fujiwaraさん「コード書かないで解決できるならその方がいい。書くほど当然バグが出る」(枕を高くして寝る話、より)
  • パネルディスカッション「問題は何かを考察するのが大事。必要ならコード読み書きする」
• ya*poさん「インタネットに関わるエンジニアでインフラかコードがわからないのはまずい」
  • できる部分から実行していく
  • ApacheやMySQLのソースコードをいきなり触るより、解決できる問題から
• 実際に手を動かせるかが大事
  • 名称にまとわりつく先入観を捨てる
  • 「ooエンジニアはxxをしない」という先入観がまずい
  • 自分には関係ないことなんだ、と思ってはいけない
• どのように習得したのか
  • 入門書レベルまでは本などで自力で
  • とにかく書く → Fluentdのout_exec_filterでPerlのコードを使った
  • 業務で、既存システムをどんどん書き換えた
  • とにかく読む → CloudForecast, GrowthForecast, HRForecast, Yabitz, Whada, Fluentd
  • 言語が違っても設計などが参考になる
  • 身近に作者が多かったのもよかった
• コードのアドバイスをもらえた
  • コメントを適切に。期待する入力と戻り値
  • 冗長でもわかる名前をつける
  • 「xxしてからooするやつ」という名前になると、分割したほうがいいという目安
• 教わるときに気をつけること
  • 諸先輩方の言うことは素直に聞く
  • 盲信するのもよくない(「過去の自分は他人」と言われた)
• fluent–plugin-flattenとrewriteのバグ修正をやらせてもらった
  • コーディングスタイルなどのアドバイスを受けた
• Serverspecの機能追加のpull-reqを送った
  • テストの落ちるpull-reqを送ってはいけないという教訓を得た
• ソースコードリーディング会
  • プロダクションコードの実装者を呼んで、解説してもらいながらコードを読む
  • 当事者意識が芽生えるのが利点
• 仲間を増やす
  • 仲間に恵まれた → インフラにも精通したソフトウェアエンジニアなど
  • 刺激を受けられる → インフラエンジニアから開発者をするようになった方々
  • まずはブログを書く、勉強会で発表する、などして名前を知ってもらうといい
• まとめ: やればできる
• 質疑応答
  • Q. インフラとアプリの領域かぶるSQLの部分について協業とかの仕方は？
  • A. お互いがお互いの領域を知るべき。遅いというだけでなく、実装を知ってアドバイスする
  • Q. 逆にアプリエンジニアの人に望むことは？
  • A. 前職ではコミュニケーションが難しいことがあった。アプリの人もインフラを知るといい

Daisuke Makiさん「Go For Perl Mongers」

• みんなで発声練習してください「YAPC大好き！」
• Go を初めて1年弱。10万行くらい書いた
  • 最初の4万行でgoの落とし穴にかなりハマった
• 質問は話の途中か廊下、Twitterなどで
• Go は LLっぽいCである
  • LLののりを引きずるとGoが嫌いになる
  • 設計、考え方など、全く違うメンタリティで
• 例外
  • Goに例外はない
  • panic()とrecover()は本当にどうにもならない時のみ
• オブジェクト(継承)なんてない
  • オーバーライドしたメソッド呼び出しに見えるけど、違う
• GoroutineはPOSIXスレッドではない
  • killもwaitpidもできない
  • Goroutineは何百万個作ってもよい
  • 非同期処理に精通していると、同期処理は書きやすい
• 例外とエラーについて
  • panic()になったら、ランタイムがどういう状態にあるのか保証できない(メモリエラーなど)
  • 早めにエラー処理(return)し、必ず呼び元で確認する
  • 複数の戻り値でerrorを返す。 return i, nil
  • if err != nil { を見たらエラー処理だと思えるようになる。流儀に沿ったほうがいい
  • panicは本当に復帰できない場合のみ
  • recoverは本当に大丈夫だとわかってるpanicに対してのみ
  • fmt.Errorf() エラーメッセージは小文字で始めないと怒られる
  • fmt 「フント」と読まないとgoの人に怒られる
• Goでの構造体設計
  • Cの構造体チック
  • オブジェクトはない。レシーバとメソッドはある。継承はない
  • 親からフィールドやメソッドをもらうことができない
  • 呼び出したいオブジェクトを埋め込んで、呼び出す
  • 無名埋め込みができる。あたかも継承したように見える
    • が、移譲。レシーバが子クラスにならない
    • child.printReceiver と child.Base.printReceiver は匿名にしても同じ意味
  • インタフェース中心にする。小さい部品を作ってmix-inすることで再利用
  • インタフェースを定義し、埋め込みでそれを満たす(MooseのRole)
  • Genericsはあきらめましょう。公式な答え「考えてもいい」
  • APIを考える→「草食動物」ではなく「草を食べる、ことができるもの」
  • go-stf-server はその苦闘の歴史なので、興味があれば
• 並列の道具揃ってる
  • goroutineはスレッド、channelはスレッド間通信
  • どのスレッドでいつ実行されるか不明
  • 回収する必要はないが、同期しないとリソースの開放に問題
  • goroutineの停止、終了を待ったりなど、一切の制御は不能
  • channelを使って同機を獲る defer の中でチャネルに送ると、終了を検知できる
  • defer はgoroutineの終了を待たないと終わらない
  • goroutineを停止させるには、チャネルとフラグを使う
  • チャンネルにバッファがあるので注意。超えるとブロックする
    • きちんと読み込まないとデッドロック
    • 書き込みのみ別のgoroutineに移すことで凌げる
• Goのフォーマッティング → gofmt、golintを使うしかない
• 戻り値の型をinterfaceにしておくと、nilを返してもnilじゃないことがある
  • interfaceがnil判定されるには、具象型もnilである必要がある
• os.Exit() と log.Fatalf() は一切 defer を呼ばないので注意
  • 普通に return したほうが
• 外部のブロックするようなコードの呼び出し
  • goroutineで包んで、自前でchannel化する
• まとめ: goを書くときは考え方を買える。「goに入りてはgoに従え」

Tokuhiro Matsunoさん「お待たせしました。Perl で BDD を簡単に実践する最高にクールなフレームワークができました」

• 英題「Perl and testing libraries」
• TDDでやってる人 → 一人
• テスト書くのは嫌いだが、書く。でも怠けたい
  • 少しのテストで最大限の効果
• 歴史: Test::More, Test::Class
  • 'dan' ne 'kogai' どちらも Test::Builder に依存してて、基本的に同じ
• TAP : Test Anything Protocol
  • okとnot okを出してproveで
  • subtestやdone_testingのような拡張もできてる
• Test::Builder2
  • 2011年から初めてる
  • Perl6と同じくらい夢が詰まってる
  • Custom output, Full rewrite, OO-ish
  • まだ開発中。時間がかかる。すべてのモジュールに対して通るように
• Test::Pretty
  • 出力をunicode文字を使った出力に変える
  • subtestの読みにくい出力を読みやすくする
  • モンキーパッチ当てまくってる
• Test::Ika
  • RSpecライク
  • Ikaとはikasamaさんのika
  • 最終的に、ikasamaさんがメンテナンスすることに
• Test::Moreの開発が停滞している
  • Test::Builder2 は開発が中止となった
• Test::Kantan は Test::Builder に依存してない
  • 出力をフックしたりしている
  • subtest にフックをかけられる – before_each、after_each。subtest以下すべてに適用
  • jasmineにインスパイアされてる
  • BDDっぽく書ける。given, when, then
  • Test::More のスタイルも使える
  • パワーアサート: B::Tree 使ってソースをhookして実現してる
  • 'kogaidan' ne 'dankogai'
  • 色がついてたほうが一般ウケする
• not ok 1..1 → テストの通ってる数はそんなに意味がない。all or nothing でよい
  • 大規模ソフトウェアとかのインテグレーションとかなら意味があるかも知れないけど
• すぐに使いたいならTest::Prety、RSPEC厨ならTest::Ika or Test::Kantan
  • Test::Kantan はコントリビュータを募集中

Taiki Kawakamiさん「Perl::Lint - Yet Another Perl Source Code Linter」

• いきなり新バージョンをリリース – テストFAIL → リリース断念
• Perl::Lintとは – source code linter → Perl::Criticでは？ – linter : ソースコードを解析して、教えてくれるもの
• 悪いコードの例 – unless + not, not + &&, 2引数、open, openの戻り値、never reached – あら探し(コードレビュー)楽しくない → 人間がやるべき？ – そもそも人間は見過ごす – 読みやすい＝レビューしやすい＝保守しやすい
• 初めてのsource code linter : 1979にC言語のもの – js-hint, find-bugs, Go, Scala などなど
• PerlではPerl::Critic – PBPスタイルにあっているか見る
• 機械化する利点 – 文句を言わない、疲れない、ミスをしない、速い、自動化ができる、コストが安い
• Perl::Criticの問題点 → 遅い – Perl::Lintは97 cnt/s (Perl::Criticは18call/s)
• Perl::Lintをなぜやっているか – TPFの助成金でやってる – みんなもTPFやってください
• Perlの静的解析のやり方 → Web::DB press読んで – トークン列の評価 or ASTの評価 → Perl::Lint は前者 – PPI と Compiler::Lexer → Perl::Lintは後者
• Compiler::Lexer – 高速な字句解析機 – Perl::Lintはこれのお陰で速い – 分析結果の大事な部分→ dataとkindとtype
• Perl::Lintのコツ – トップレベルにPoliciesとRuleのみ – ポリシーはPBPに従ったもの。ポリシーは独立 – 例: 組み込み関数のtieは使わない（ちょっとゴツイ） – 例: もっとゴツイ(スライド8枚くらい)
• Perl::Lint では C-Style forを使っている – 先読み、後読みが頻繁に必要なため – PBPで禁止されている – C-Style forを使うなというポリシーもC-Style forを使っている
• Perl::Lintの実装の特徴 – 正規表現は遅いから使わない (遅いから) – Perl::Lint は関数呼び出しが少ない (遅いからとサボってるから) – POPOやraw-blessなど、シンプルなものを使ってる
• Perl::Critic のルールは難しい – perlcriticrcはめんどくさい
• Perl::Lint はデフォルトでいい感じのポリシーを用意。使わないのをフィルタ – ignoreやfilterが提供されている – perl criticライクなものも
• Perl Lint Playground というサービスを作った – Share機能もあるのでTwitterに投稿できる – ユーザからのフィードバックは重要。それを得たいがために作った – モチベーションが上がる。ライブラリ開発は地味なので・・・
• この碁の展望 – すべてのPoliciesの実装 – 「## no lint」への対応 – Test::Perl::Critic 的なもの – Githubとの連携 – TODOにlintの結果を埋め込む(rubocopではやってる)
• Perl::Lintは作りかけ(２ヶ月押してる) – SEGVやABRTが起こる – 「$/」があるとSEGVするので、forkして凌いでいる
• Perl::LintをPerl::Lintでチェックするデモ
• 質疑応答 – Q. 独自のポリシーの拡張は？ – A. 簡単な奴は簡単に書けます – Q. なぜASTを使わない？ – A. コンパイラのパーザが不安定 – Q. Compiler::Lexerはどうなの？ – A. SEGVになるケースはかなり減っている。今後に期待 – Q. ポリシーを作るときにASTがあると嬉しそうだけど、トークン列を見ることでよくなることは？ – A. 手作業でASTを組み立てている。ほんとはASTがよい – Q. Perl::LintでPerl::Lintのテストを全部通るようにする計画は？ – A. 辛いのでないと思います – Q. 実装したくないポリシーを実装して欲しい – A. 実装したくないポリシーを実装して欲しい・・・のは冗談で、ドキュメントを充実させたい。特にポリシーの
• ダイナミックスコープ解析、がきつい感じしかしない
• 静的解析友達を募集しています

hakobeさん「Scala In Perl Company : Hatena」

• Hatena はほぼすべてのプロダクトがPerl
• なぜPerlか？
  • 少ない記述量
  • 実行手順（試行錯誤しやすい）
  • CPANライブラリ
  • WEBの開発基板
  • コミュニティ
• 10年で起こったこと
  • スマホ、技術の高まり、ユーザの変化
  • ソフトウェア進化を継続することが必要
• Perlとソフトウェアの進化
  • 単体テスト、CI、ソースコード解析、レビュー、段階的な変更、開発フロー見直し
• 突然のランタイムエラー
  • $url->schema で落ちたりとか、メソッド名の変更を追えてないブランチとか
  • エラー検知に限界がある
  • カバレッジをどこまで高めるのか
• 安全なソフトウェアの変更が必要
• mackerel → はてなのサーバ管理サービス
  • はてなIDは使わない。スケジュールの自由度がある
  • 新言語投入のチャンス
  • 静的型システム[MUST]、柔軟さ、Web開発、社内に開発者、ライブラリ
• Haskell の問題点 → 社内に人がいなかった
• Scala
  • オブジェクト指向と関数型のハイブリッド
  • JVM。Javaと互換性
• Scalaな理由
  • 多様な型がある。特に、代数的データ型を定義できる
    • Optional型 → undefチェックを矯正
  • 記述が柔軟。Perl Mongersも安心の書き心地
    • _とか型推論とか
  • Javaのライブラリがそのまま使える。DBとかネットワークとか
  • 社内に書ける人が居た
• 環境
  • Emacs + sbt とか IntelliJ + sbt とか
• 利点と欠点
  • コードの変更に強い
  • レビューが楽
  • コンパイルが長すぎる。3分かかる
  • 学習コストが高い
  • Java界隈のことがわからない
  • 型システムは最高

Lyo Katoさん「O2O/IoT/Wearable時代におけるWeb以外のネットワーク技術入門」

• EventHub系ツール、サービス
  • IFTTT, PubSub(MQTT)
  • 前者は、周りのサービスはHUBを知らない。後者は、周りのサービスがHUBを知っている
• Machine to Machine 以外でも
  • Beluga (Group Messenger) が採用していた
  • PubSubはグループチャットと相性がいい
  • 機械にとってのグループチャットと思うとわかりやすい
• /区切りのtree構造でイベントを監視する
  • +はワイルドカード(同じレベルのみ)、#は下のレベルすべて
  • 省エネ。フォーマットのパケット、手続きの簡略化
• QoS (Quality of Service)
  • 機械は動くがネットワークは止まる
  • QoS 0 : 特殊なことはしない
  • QoS 1 : 保存してからpush。配信できたら保存を消す。届くまでリトライ
  • QoS 2 : 一度しか送らないことを保証
• MQTT-SN → Sensor network。ゲートウェイを使ってまとめる
• MQTTはほかの技術との比較が混乱しやすい
  • 「HTTPに比べて省エネである」
  • Polling : 数秒に一回的な
  • Long Plooing : responseの戻りを遅らせる
  • Server Sent Event
  • APNS / GCM & HTTP GETでも実現できる
• HTTPによるM2Mネットワーク
  • IBMとかその辺。HTTPで機器間のやりとり。RESTfulアーキテクチャ
  • 省エネ的に厳しい
• CoAP : HTTPをベースにマシン用に最適化したもの
  • Constrained RESTful Environment (CoRE)
  • Observeオプション、Bonjour的なものなど
• Bonjour : Zero Configuration Network
  • DNSのPTR/SRV/TEXTレコードを使って、機器の追加などを認識する
• CoAP VS MQTT
  • CoAPはHTTPなので外部連携はらくかも
  • 標準化の途中なので要ウォッチ
• NAT超え
  • ICE
  • 外に飛ばすときにマッピングを記録
  • ルータによって振る舞いが違う
  • STUN : NATの外側でのアドレスを知れる
• MQTTって、Message Queue? Messaging?
  • AMQP : RabbitMQが有名。キューだけじゃなくバインディングが柔軟だったり
  • MQTTはMessage Queue関連のプロダクトから名前をもらっただけで違う
• XMPP : 仕様が非常に複雑。相手が居るかどうかの機能だが、スケールしない
• Redis/STOMP : Redisはプロトコルでなく実装。STOMPがMQTTに近い
• MQTTは使うべきか？ → 実装しておくと、家電とかの実装が進めば、利点が出るかも
• AnyEvent::MQTTというモジュールがある
  • サーバ実装はなさげ。昨夜リリースされたSango(MQTT as a service)で試すと良さそう
• Bluetooth Classic
  • 旧来のBluetooth。高速化の追求
• Bluetooth Low Energy (BTLE)
  • 4.0から。別物と考えたほうがいい
  • BTLEではペアリングなしで使うことがほとんど
• ピコネット:CentralとPeripheral
  • Peripheral側がサーバ
  • Peripherarlがbroadcast。Central側がscan
  • 小分けで出す(Low energyのため)
  • 接続後は定期的にやりとり
  • 周波数を毎回切り替えて混線を防ぐ
• Bluetooth の Profile は予め用意された仕様
  • 自分でプロトコルを決める場合は、Classicの場合はSPPで、LEの場合はGATT
• サービスの中から目的のCharacteristicを読み書き
• iOSは5.0、androidは4.3からBTLE
  • androidはLEはまだ時間がかかる。iOSとの連携はまだまだかな
• iBeacon
  • 近接検知。近寄ったことがわかる。強度で距離の推測。方角は不明
  • 2つ使えば移動の検知
• iBeaconで、スマホで情報を見る際の検索を省ける
• 情報伝達の歴史 : BROADCAST → PULL → PUSH → PICK
  • 近くのデータをPICKできるように。GoogleGlassでは使ってる。
• これからPersonalizationのフェーズ
  • セキュリティとプライバシー
  • 裏でビーコンを元にGET/POSTを叩く
• BTLEは応用の余地がある。MQTTもメリットデメリットを考えれば
  • 相互作用を考えると面白い

Kenichi Ishigakiさん「Get a kick out of CPAN」

• CPANから刺激を受けてモジュールを書きましょう
  • Dave Crossのポスト → perlを評価しているのは内部のコミュニティ
  • 日本語の別のポスト → YAPCの殻に閉じこもるのはね・・・
  • Perlのマーケティングはどうなのか
• CPANは重要なもの
  • DRY
  • CPANモジュールは共用語の役割
  • CPANを健全に保つのは重要
• Perl 5.20 でCGIモジュールなどが消えた
  • でも、90%くらいは通ってる。CPANTSのメトリクスも良好
• 日本のCPAN Authorの数が気になる
  • 536名。ヨーロッパの合計よりも多い
  • モジュールをアップしたのは66%しかいない
  • 「何をリリースするか」が聞かれているはず
  • 2つリリースしているのは45%。5つ以上だと22%
  • 今年リリースした人は20%。新しいものをリリースしたのは11%
  • YAPCには1,000人来ている
  • 世界でも同じような状況
• フィードバックがないために、2個目以降のモジュールが出ないのでは
  • このような状況で新しい人を勧誘しても大丈夫なのか
  • 平均3つモジュールがあれば、誰かに使われる
• ゲーミフィケーション、が役に立つのかも
  • ゲームっぽい要素を加えて、やりやすいようにする
  • 例: ラジオ体操のシール
  • 速める、人を集める、継続させる
  • ゴールのハードルを下げ、適切なマイルストンを
  • 進捗を分析する
• PBL : Points, Badges, Leaderboards
  • ポイントの取得が目的化されたり
  • 追いつけない人のモチベーションを下げたり
  • バッジの難易度設定を適切にしないといけなかったり
• 8/16 の CPAN DAY でそのような話になった
  • 一番初めにCPANにモジュールがリリースされた日
  • 107人が同時にモジュールをリリースした
  • Ingyさんが300回以上リリースした → アップデートメールが・・・
  • ちょっと考えさせられた。Gamificationの設計には注意
• (ここからはスライドなし)
• CPANを健全にするアイデア
• チケットを見つけて、パッチを送る
  • QAとして、まず正しい
  • 世の中にあるモジュールを知れる
  • 作者へのフィードバックになる
  • RTのチケットの統計があるので、この話をしてどうなるか見てみたい
• 元々ユーザの利用がある更新されていないモジュールのメンテナを引き受ける
  • フィードバックを得られる可能性が高い
• 大きくて活発なコミュニティを探す
  • 特殊な分野だとフィードバックは来にくい
  • 興味のあるコミュニティを探してみる
• Perl Hackers Hub の 26回
  • Perlの困ったことの調べ方
• YAPCに参加して何かしてみたいとか感じたら
  • ホールなどで話すとアイデアがもらえるかも
• CPANモジュールはたくさん持ってるが、さらにアイデアが欲しい
• Questhub
  • https://questhub.io/realm/perl
  • QAハッカソンなどの参加者がネタをアップしてる
• 今後のCPANの状況を見て、地方PMなどで発表すると思うので、ぜひ
• 質疑応答
  • Q. Code Repos には上げやすかった。テスト的なものがあると上げやすい気がしました
  • Q. githubなどのissueに難易度をつけて、公開するサービスを作るのも面白い
  • A. 面白い。誰が判断するのかは難しい
  • Q. どなたかが対応すべきな気はする
  • A. RTなら難易度がある。githubはあまりない
  • Q. モジュールの内容が飽和しているのでは？
  • A. 飽和している分野もあるがそうでない分野もある。他の言語から概念の持ち込みや、古いモジュールの書換なども
  • Q. github止まりのものは、CPANにあげたほうがいいのか。prepanの認知度はどうなのか。慎重になるかあげるべきなのか
  • A. インタフェースだけ変えてあげるとかはちょっと。他はご自身の判断。prepanはモジュールの書き方のpodにあるはず
  • Q. githubに上がってるモジュールで、CPANに上げて欲しいものを助言すると自信を持って上げやすくなる
  • A. Acme::CPAN::Authorsのgithub版が欲しい。metacpanにgithubのアカウントを登録して下さい

LT

maka2_donzoko@twitterさん「同人活動の報告と今後の展望」

• 今日は菊池真さんの誕生日
• コミケ前はAcmeモジュールに向き合う
• Scalaの仕事をしたい方には、好きなだけPerlが書ける仕事を紹介します
• Acme大全2014年
  • チャームポイントは表紙
  • 雑なPerl (存在しないAcmeモジュールを探す)
• 「ご覧ぐ」ださい
• タクシーの運転手「あんた、いつまでこれ続けるの」
• 紙媒体は今回が最後
• YAPC::Asiaで離婚の事例にならないように、お願いします
• シール 150枚くらい余ってる
• 新作「神捗道Deathか」
• Acme大全　全巻

charsbar@githubさん「top 10 kwalitative japanese authors 2014」

• 今年は、今年リリースしてない方は省略
• 3位 HAYAJOさん 2位 YAKEXさん 1位 BAYASHIさん
• Minilla を使っている方は注意
  • META.json のバージョンは2だと、ライセンスがリストなので注意

shoichikaji@githubさん「Relocatable Perl」

• 何度もperlをビルドするのがメンドイ
• 古いsystem perlはちょっと・・・
• 誰でも使える最新のPel : Relocatable Perl
  • use 時に -Duserelocatableinc を指定すると、どこに置いても動く
  • ダウンロードすれば快適に使える
  • shoichikaji/relocatable-perl
  • wgetして回答するだけ
• Perl製のアプリの場合、perl も一緒に配布したい
• デモ : growth forecast
  • ダウンロードして解答するだけ

papix@twitterさん「perl入学式 2014年度中間報告」

• 東京、大阪に加えて、福岡でも開催
• 福岡のスタッフさんが増えた
• 釧路OSSでの短期集中講座 → 参加者10名
• グループがgithubへ移行
• 就職してリソースが減ったので、タスク分割した
• ウェブサイトがリニューアル → やさしい感じのロゴ
• JPAとの連携
• 3周年です
• 始めたい人は来てね

hiratara@githubさん「Lens : Smart setter for immutable data」

自分のトークでした。

gugod@twitterさん「Beyond Civic Hacking」

こちら聞き取れませんでしたが、懇親会の時にgugodさんに解説して頂きました。

• 様々なデータのビジュアライズ
• ゴーン(時間切れ)

shuhei.tanuma@facebookさん「OSSのりそうとげんじつ」

• 承認欲求とは違うと思ってる
• 自分の考えたアイデアで問題を解決することが楽しい
• OSS活動にハマった20代
  • デート中にSEGVの原因を考え続けて怒られた
• 30代 後どのくらいOSSで遊べる？
  • 一日の時間 3.5h/日
  • やらない洗濯が必要
• 寝ないという手も → 病院に
• メンテナンスコストの増大
• 企業のフルタイムOSS VS 個人のOSS
• うっかり業務アプリに組み込む
• コミュニティを育てる
• メンテナンスは難しい xhprofすら・・・

catatsuy@twitterさん「新卒インフラエンジニアが・・・」

• 代表的perl企業
  • pixivはすべて小文字です
• 新広告サーバ開発プロジェクト
  • nginx - circus - go
• Perlは一部で使っている
  • ページキャッシュを Sys::PageCache で使用しないログのページを削除

kazeburo@githubさん「Web Framework Benchmarks とPerlの現状報告会」

• Techempower社が21言語、100近いWebアプリケーションのフレームワークのベンチマークを
• 項目が色々あり、全部実装しなくていい
• AWSのマシンを使う
• Perlの惨状
  • そもそも動かない
  • PHPの半分
• ISUCONやります！
• チューンして良くなった
  • Unicornがかなり速くなったけど、Perlもかなり良くなった
  • ActivePerlをやめた、Monoceros、plackupもdefaultだった
• WAFを作ったらpull-reqするとよさげ

bayashi@twitterさん「YAPC::Asia Ramen Challenge」

• 日吉はラーメン天国
• 家系が充実
• Ramen + OSS
• ルール
  • ラーメンを食べて写真をあげるかOSSに貢献する
  • 3人を指名する
  • ハッシュタグは #yapcramen
  • githubでもいい。PerlじゃなくてもO.K.
• (スタート！)[https://twitter.com/bayashi/status/505277220223324160]