Perl
イベントまとめ
備忘録
yapcjapan

YAPC::JAPAN 2019 Tokyo 会場 まとめ メモ

開催中のYAPC::Tokyoのメモ

誰かが「この資料あったよー」って編集リクエスト来たりしないかなーと思いつつ公開してます。終わった後清書して更新します。


尚コレを書いてる本人はPerl書いてないです。

公式サイト: YAPC::Tokyo 2019


opening

テーマ: 報恩謝徳

「報いる方法は人それぞれ」


得た刺激を返していこう


周知事項


  • ランチセッションが先着150名分

  • 電源は3階オープンスペース


ハッシュタグ

#yapcjapan

#yapcjapanRoom0
#yapcjapanRoom1



チームが前に進み続けるために僕たちが考えたこと (20min)

papix 氏

資料

hatena blog media


toc向けとは違うtob向けチームだけど連携はしてる


停滞感を感じた


  • 規格の全容が追いにくい


    • ディレクターが全部決めるため



  • タスクの進捗状況がわからん愛


    • 定例MTGでしか進捗が共有されない



  • 余裕がない


    • タスクの見積もりがざっくりしている

    • はてなブログのステークホルダーがおおい

    • ディレクター陣も交渉に大忙し



辛い


アジャイルって?


  • 「適応すること」に価値を置く

「全然わからない俺たちは雰囲気でスクラムをやっている」

「兼任スクラムマスターをやろう!」


インプットフェイズ


  • 前職の経験

  • アジャイル侍

  • カイゼンジャーニー


導入設計


腹をくくる

業務開発フローは「変えることは無条件に正しい」


2つの看板


  • 要件定義の様子を可視化する

  • タスクの状態を管理する看板


デイリースクラム


  • 昼会として実施


スプリント計画

最初は1週間なれてきたら2週間スプリントに


僕たちはこうなった


  • 開発者の視点も盛り込んで要件定義できる

  • デイリースクラムでアラートも出しやすい

  • ベロシティに基づいて計画できる!

「頑張ろう まだまだ若い まだまだこれからだ」


ユーザーストーリー

テンプレートを用意しておけば自然と埋まっていくするとやることが見えていく


変化


  • タスクの管理


    • 当初は分割したタスクをIssueにしていた


      • 1つの企画お情報複数に分散する



    • → 物理看板に変化

    • 相対見積もりを時間による絶対見積もりに


      • 相対見積もりは終わりがあると使いやすいが僕たちには終わりがない


        • 相対見積もりは使いづらい







  • 物理看板


    • ユーザーストーリーや開発タスクなど種類ごとに色分け



  • デイリースクラムをスタンディングに


    • 座っていると副業ができてしまう

    • 立ってたくないから早く終わるように

    • デイリーは立ってやろう!



  • バックログ整備会


    • 議論や説明に集中できるように



  • 振り返り会


    • スプリントをイベントで振り返る

    • "感情"を数値化する

    • 投票して点数が高い物事に議論する



スクラムをチームにCustomizeして導入できた

「変化し対応し続けない」

「手を動かしたもののみ世界を変えることができる」


## 私とOSS活動とPerl (20min)

前田隼輔 氏

資料: 私とOSS活動とPerl

普段はserver side kotlin


0.学生時代


  • 生命科学での研究で大量のデータ処理を行うことに


    • バイオPerlで解析していた

    • 当時は何もわからず取り敢えずOSSを使っていた




1.新卒社会人


  • アプリケーションはJAVA


    • オブジェクトを覚える



  • 運用ではPerl

  • 運用作業の発生頻度が微妙

  • SQL覚えられない


    • JAVAのメゾットチェーン的になのをPerlでも書きたい!

    • ここで初めてmoduleの概念をしる


      • これでJavaと同じようにかける!

      • PerlのO/Rマッパーを作る

      • コレを会社でも使いたい


        • 初めてGithubにソースコードを公開







  • CPAN:Authorになりたい!


    • 3年目で称号がほしかった

    • SLACK:RTM:BOTを作った

    • 初めて公開

    • ソースコードのリポジトリに変化


      • Star

      • PR

      • 異なる言語圏

      • 言葉以外の情報が大切





  • 最後に


    • 今作っているもの


      • SLACK:RMT:Bot

      • duck8823/duci


        • GO製CIサーバー

        • 特別な設定が要らないCIサーバー



      • 「世界はOSS開発者に優しい」







Perl to Go (40min)

xaicron 氏

GoでWebアプリ各流れを知れるといいよね


なぜGoを使うのか


  • 昨今オンプレはダウントレンド

  • クラウド上でコンテナ上で運用することが当たり前になってきている

  • コンテナでの運用ではスペックが低いため軽く高速であることが求められる

  • コンテナサイズは小さい方が高速に立ち上がる

  • スクリプトライクに使うことができる

  • コンパイル速度も早い

  • クロスコンパイルが容易にできるので簡単にできる

上記の理由で現代では使いやすい言語だと思う


流行に乗り遅れないためにも


Perl MongerがGoを始めたときにハマったところ


  • CPANがない


    • git repositoryのURLで指定してインストールする

    • CPANやGEMみたいな中央集権型のようなライブラリ情報がない

    • ライブラリで探すときはGiothubでググる


      • → 将来的にModule Indexerを作るらしい

      • こんごCPAN Testersみたいなももでるかも?

      • ライブラリのmirroも作成予定


        • 現状Githubが落ちると何もできない



      • 1.13でコアに入るよてい





  • $GOPATHから逃れられない


    • golangは$GOPATH以下で開発する必要がある

    • あらゆるライブラリは$GOPATHいかにないといけない

    • 1.8以降は$HOME/go以下がデフォルト

    • 1.12で気にしなくても良くなる…?


      • 実際は…?





  • ライブラリの管理が難しい


    • $GOPATH/src以下にクローンされる

    • go1というタグがあればそれを見てくるらしいが対応している物が少ない

    • gogetでバージョン設定ができない

    • 実際はWEB APP開発ではgo getはあんま使わない


      • cartonとかが大体





  • オーサリングツールがない


    • GOにはオーサリングツールの決定版がない


      • まっさらな大地でやっていく



    • go xxxコマンドを打つMakefileを書く

    • minilla



「ライブラリの扱いでハマることが多かった 今後も変わっていく」


GOの言語仕様で学ぶPerlとの相違点


  • camelCase


  • 配列とスライス


    • スライスは可変長変数 基本はこっちを使う



  • 関数名


    • PascalCaseで書くとpublicにcamelCaseで書くとprivateに

    • 複数の返り値を指定できる

    • 関数を代入したり他の関数を渡したりできる



  • Errorハンドリング


    • Try/cacheはない

    • 例外を出すときはpanic()を使う


      • Perlでいうdie()



    • recoverでキャッチする

    • しかしpanic()を使うことは推奨していない


      • カーネルやErrorで終わらないといけないときに出す



    • 慣習として返り値がErrorインタフェースかboolを返す



  • defer


    • deferすると関数を抜けるときにfunc()を実行する



  • gorutine


    • Goを象徴する機能

    • go func()で別スレットでプログラムが走る


      • 簡単に並列プログラミングできる!





  • context.Context


    • 特定のgorutineや一連の処理中にデータを入れて引き回したりキャンセル処理を波及させるのに使う





Perl on Rails

GUEST: 大仲 能史 氏

はてなとしてPerlを脱出仕様にも決め手がない


「(この間にRailsを布教できるのでは)」


Perl on Railsとは

RailsのいいところをPerlに輸入して布教させたい


Write Less Code


  • コードは少ないほどよい


    • Locの話



  • DRY CoCは実現するための手段


  • RESTful


  • The 12-Factor App.



はてなPerlの状況


  • 「薄いフレームワーク」

  • 安全で最小限な実装をプロジェクト内に持つ


レールに載せたい

4年ぐらい前の世界ならRailsは最強最速フレームワークだった


Rake

makeのRuby版

モブプロしてる中Perlプロダクトでrakeを書いてるのがバレた


API REPL

サーバーはJSONを返すAPIがある


  • APIの確認にCURLを使ってた

  • tokenを取得したりとか大変

  • HTTP Requestを発行できるREPLを作成


ACTIVE RECORDE


  • 全テーブルに対するクラスを生成

  • 弊害


    • 複合主キーがデフォルトにない

    • プライマリーKeyがないテーブルがある

    • migrateしまくって使いやすくしていった



  • ER図の自動生成をして不況させていく


Test::mysqld Test::RedisServer


  • pral界特有

  • ミドルウェア全部入りのコンテナでテストしている


migrate


  • リリースのチェックボックスで管理している

  • →migrateでrakeタスクを作った


CLI


  • プロダクト用のCLIツールを作った


seed


  • rake db:seed を作った

  • 本番からデータを取ってきて適用する


    • 運用会社が別だったのでなにかあるのか対応するために





エンジニア組織論への招待

GUEST: 広木 大地 氏

資料: 2つのDXと技術的負債-YAPC Tokyo 2019 - Speaker Deck

ビジネス書とも技術書とも言われるエンジニア組織論への招待


  • 何かを実現することは不確実性を減らすことである

  • 不確実なものから人は闘争防御回避取ろうとする

えんじにありんぐ = 不確実性をへらす


  • マイクロマネジメント型組織

  • エンパワーメ型組織

後者の方が基本強い


  • 環境性不確実性

  • 通信制不確実性

僕たちっ物事を明確にしたがる

そのコミュニケーションが否定に取られがち


コミュニケーションとは

非対称性を解消していくこと

常識の距離が近い人ほど簡単

人数の2乗のオーダーで交流が発生する

ダンパー脳のサイズと群れの大きさが比較したものだいた`150以上か群れとして認識でできないととされている


他人と向き合うのは怖い


  • 攻撃的行動

  • 回避的行動


学習を促す心理状態になれば本能を克服できる


  • 心理的安全性を高めれば本能を克服できる


    • 心理的安全だけが高いとコンフォートゾーンになってしまう



  • 脳には似ているものをまとめてしまう機能がある


    • → ゲシュタルト原則

    • 15階のれんちゅうがー あの部署のれんちゅうがー

    • → もんだいは脳の機能が悪いに作用していること


      • →リファクタリングしよう

      • バグを憎んで人に組まず





  • なぜかコード数式がないとポエム扱いされる


    • ソフトウェア工学の問題



  • 生産性、品質、コストのトリレンマを超える


    • トリレンマ ・・・同時に三つ取れないもの



よいチームの傾向

- 関わる人数が最小限におさまっている

- 多様性がある

組織構造はコミュニケーション構造と同じになりやすい

→そのため悪い組織構造は悪いシステムを生み出しやすい


  • 逆コンウェイ作戦






  • マイクロサービシーズ

選択肢をもつ側が強く持たない方が弱い

コントロールの喪失によるホールドアップ現象はありふれた経済現象である

技術的負債は何十兆円という価値になっている


なぜ多くのエンジニアは技術的負債現象と呼ばらなければ行けなかったのか


見ることができないという非対称性が問題の根本



  • システムの見えかた


    • エンジニアにはctスキャンに通したように隅々からわかる人体

    • 日エンジニアにはなにもなかみがわからない人体



  • 技術の構造がわかるコミュニケーションを取っていく


  • 何をやりたいのかをはっきりさせる


  • 問題に光を当てればそれは技術的負債と呼べないかもしれない


  • コンピテンシートラップとdx




Dive into MySQL Error (40min)

yoku0825 氏

「こんに千葉!」

資料: Dive into MySQL Error (YAPC::Tokyoバージョン) - Speaker Deck


Error種類


  • MySQLサーバー以上

  • クライアントに対するネガティブな反応

  • クライアントライブラリーの異常


サーバーからのクライアントに対するネガティブな反応


  • 認証失敗

  • Error時はErrorパケットを発行する

  • サーバーそもそもの異常


    • プラグインやサブシステムで拾えるのはある



  • サーバーからクライアントに返すやつ


    • 概ね1000番代 昔からよくあるからあるわけだし



  • エラーが出たらまず何番台かを確認


  • 2k番台なら到達していな可能性が高い


    • ごく前れにサーバー側の問題だったりする

    • 2002 sockファイルがない

    • 2003 tcp接続に失敗


      • 同じエラーでもタイムアウトでもタイムアウトさせる箇所によって変化がある



    • 2006, 2013


      • どこで落ちるかで変わる

      • クエリを投げてからつながらなくなる

      • クエリ処理中にTCP接続が切れる→2013



    • 2059


      • 8.0になってからみんなググるあれ

      • 8.0からの新規の認証ライブラリだが昔のものでは持っていないのででる



    • 1251


      • 8.0へMySQLもっと古い物を使うと出てくる

      • プロトコルに互換がないことに気づいて出してくる



    • libmysqlclient.so


      • MySQL Connetor


        • Perl Rubyが使っている






    • サーバー

    • perrorで調べれない






1213番


  • デットロックErrorとして有名だが、コレはデットロック思想になったことに対するError


2000番台Error応用

Last_IO_ErrorはOSエラーコードが出てこない


1xxx, 3xxx


  • 1251


    • SQLステート


      • サーバ






perror


  • エラーコードを渡すとエラーメッセージのフォーマットを返してくれる

  • たとえば1593 Fatal error以外は場合によって変わる


    • エラーコードでググっても効果はない


      • ググるならメッセージでググったほうがいいよ







「 C/C++は $ ないだけでだたいperl は同じ」

「MySQL Test RannerはPerl製」


エラーに触れるついでにエラーログについて


  • MySQLエラーログは実はstderrとstdoutがつながってるだけ


めとめ


  • エラーにはクライアントとサーバーがあり

  • サーバーエラーは物によっては汎用的すぎるエラーがあったり特化してるやつがある



資料

見に行けなかったけどTwitterで公開してくださった資料たち


当日


- Development and practical use of CLI in perl 6


LT


- 自走するプログラミング入門者の探し方 - Speaker Deck


前夜祭