Pixel Pedals of Tomakomai

北海道苫小牧市出身の初老の日常

トップ > 技術 > 今日は YAPC::Nagoya::Tiny 2019 の日です

今日は YAPC::Nagoya::Tiny 2019 の日です

技術

来ましたので、自分用のメモを残しておきます。

開会の挨拶

  • 名古屋から来た人、東海から来た人
  • ランチはルーセントタワーB1が穴場
  • Tiny とは？
    • 新たなコミュニティの形成。
    • 小規模で開催しやすい
    • メインはトーク
  • ハッシュタグ: #yapcjapan
  • フロア貸切ではないので注意

Perlでもできる！ PerlウェブサービスにDocker, ECS, CDKを導入してよかったこと、大変だったこと / Windymeltさん

  • Perlアプリケーションの環境構築は大変
    • plenv, MySQL Redice, Imagemagic, bzip2 などなど
    • デザイナーさんやプランナーさん
  • Docker-compose の導入
  • 開発環境 = ミドルウェア、ソフトウェア実行環境、ソースコード
  • ミドルウェアは Docker-compose で切り出す
  • 実行環境は Docker image として切り出し
  • ソースコードを同梱すると、頻繁な作り直しが発生
    • ホストに置く
  • ミドルウェア、実行環境はホストやブランチをまたがってもだいたい一緒
  • 開発環境の管理が容易
  • Dockerfile で CI にも持ち込めるが
    • キャッシュがなくて20-30分待たされる問題
  • AWS ECR: Elastic Container Registory
  • DockerイメージをAWSにおけて便利
    • 素朴に1つのイメージを共有するとブランチ間で競合
    • どうタグつけるか
  • 実行環境は Dockerfile と cpnafile.snapshot に依存
    • cat でつけて md5 の先頭7文字をとって tag にする
    • docker-compose のラッパを作って、 tag に該当するものがECRにあるかを見て、なければpush
  • 30秒くらいで簡単に環境構築できるようになった
    • 問題が次々発覚したのは大変だった
  • 動作検証用の環境
    • マージ前に見れる環境が欲しい（ステージングではなく）
    • 環境を作るのはSREの力が必要で大変
  • AWS ECS
    • king of docker-compose
    • だいたい死なない
  • ソースコードなしの Docker イメージでは動かせない
    • AWS Code build を利用
    • Makeみたいなやつ
    • 特定のブランチ名についてhookを動かしてビルド
  • ECSで検証時にブランチごとにサブドメインを切りたい
    • 共用ALBを立てて、ブランチの数だけリスナルールを生成
  • 本番っぽいDBが欲しい
    • RDSを立てて本番DBのスナップショットを入れた
  • SREの助けを借りずに環境構築ができるようになった
  • タスク定義、サービス定義、ALBリスナールール → 目でrsyncが必要
    • CDKの導入
    • TypeScript でAWS リソースを記述
  • スタックの作製
    • 基盤部分とブランチ部分を分ける
    • スタック同士の依存関係を表現 → 壊れない
    • ブランチごとに別スタック → CDKのコンテキスト機能
      • ブランチ名がわかればイメージ名が分かる。
  • 自動化されたが、CDKに慣れる必要があった
    • まだない機能があったり
    • issue を作ると作ってもらえるかも
    1. CDK使うと暗黙的にリソースが？
      1. アウトバウンドが開放されたり、勝手に権限を与えてしまったりが、デプロイ時に聞かれる
    1. IAM の設定が煩雑になりがち。工夫は？
      1. クラスタやコンテナを作るときはTyeScriptのスタイル。型レベルで作るべきものはわかる。一つのファイルに固められるので煩雑さはマシ

Rust に入門したくて！libperl を bindgen して Perl の ASTを舐め始めた話 / hkobaさん

  • FFIでRustを学ぶ
  • 今日話さないこと: Rust
  • おっさんPerlプログラマーの悩み
    • 作ったライブラリが言語ごと流行から外れて負債呼ばわり
    • 既存の資産の総書き直し？
  • Perlの限界
    • 静的な型検査
    • fields で静的に見てもらうこともできる
    • 定義時点や関数渡しの部分のチェックが甘い
    • 内部APIでPerlのASTを読むことは可能
    • だが、Perlは弱いママ
  • 近代的な言語でやればいい
    • Rust: GCを押し付けないため、GCの競合がない
  • 実践Rust入門という日本語の本が出た
    • 仕様が安定したのでは
  • チュートリアル: The bookのGetting Started と Programming a Guessing Game
    • perl_parse() を呼ぶのが目標
    • 書籍の FFI の章
  • perl_parse() スクリプトのコンパイルを済ませる
    • perl_construct, perl_parse, perl_run の順で呼ぶ
    • perl -c と同じ効果
  • PerlInterpreter には Opaque と からの列挙型を利用
  • std::ffi::CString C文字列
  • 呼べた → segv
    • gdb を使って普通にデバグできそう
    • 普通のC言語と同じ！
    • lifetime のミスでdangling pointer
    • unsafe ばかりだが動く
  • bindgen とは
  • EXTERN.h と perl.h から生成
    • 1.5MB
  • エラーが出るが、 redefined
    • 定数定義が本当に二回されていたので、手で削るとビルドは通る
    • unsafe の嵐だが動く
  • perl crate がすでにあったが、 Perl から Rust を呼ぶもの
    • 被らないので、 libperl-sys libperl-rs にした
  • ビルド: Config.pm から libperl のビルドオプションを取得して rust 用にする
  • まとめ
    • FFIからRust入門するのはあり（よく知っているライブラリがあれば）
    • bindgen は期待できそう
    • gdb使えるのはよい
    1. RustでPerlを書いて下さい
      1. もしかしたらそういう未来はあるかも。そのための足がかりの仕事

(my$name="Perl 6")~~s/Perl\s*6/Raku/; / Dan Kogaiさん

  • 司会「なんて読むんでしょうかね」
    • 読めないけど実行できるタイトルで
    • Raku が必要 (Perl5ではだめ)
  • YAPCではなくYARC（やらしー）になるのでは
  • @TimToady 「Perl 6 と呼ぶのをやめよう」
    • 別の言語なのに同じ名前なのでお互いに足を引っ張っている
    • 今後は Raku となる
  • URLもraku.orgになっている
  • Perl5 は perl と読んでいい
  • Raku の道は楽なのか？
  • やぷしぃとやらしぃは分かれる？
    • お互いにPerl仲間というのは続いているようだ
    • やらしぃはこの規模なら成立するかも
  • ラクダは楽だがRakuは落下？
    • 昔より、URLを変えるのは大変である
    • 例: itojun さん。本名は変えられたがネットの名前は変えられない
    • 例: JavaScript。Javaとの確執でEcmaScriptと呼ぶべきだが
  • Perl6は -Ofun 、 Python3は -Ofuture
    • BFDLはリタイヤしたが、Python2はリタイヤしていない
    • Perl4からPerl5 -Omodern はうまく移行した
    • jcode.pl Jcode.pm Encode.pm もうまく移行した
  • Perl4 と Perl5 よりも、当時の Perl5 と今の Perl5 のほうが中身が違う
    • 名前が一致するのに相応しいほどの後方互換性があったからうまくいった
  • Swift -Ocurrent
    • メジャー番号が変わると互換性がない
    • 稀有な成功例。Appleがリソースを突っ込んだから
    • 互換性を気にしなくていい程度の使われ具合だった
  • 人間個人の名前も変えにくくなった
    • 名前は自分だけのものではなく社会的なものに。ポインタ化。
    • s/Autrijus/Audrey/ Pugs を実装した頃に名前を変えていた
  • Perl 6 は Perl における一番の失敗ではないか
    • Perl 5 もいつまで経っても未来が来ない、と思われてしまう
  • Raku はできて19年。新しい・・・？
    • Perlへのコミュニティに、貢献してきたはず
    • 古いものと見なされるのは残念
  • Rakuになるのはラクじゃない
    1. CPAN の P は変わるの？
      1. 今は github から引っ張ってくる時代。別の機会に考察したい。
      1. (PAUSEでアップデートすることになっているが、どうなるのか)

Makefile生活 / azumakuniyukiさん

  • Makefile とは
    • make コマンド実行時に読まれる
    • BSDでは gmake を使って
    • GNUmakefile makefile Makefile の順で探しに来る
    • 処理をターゲットでグループ化
    • 行志向のシェルスクリプト、古来からある
  • make make all make install make clean make test make world とかよく使う
  • コマンド履歴の20% make
  • 実行すると画面いっぱいに大量の何かが流れていく
  • perl-5.30.0 の GNUmakefile は 14,153 行
    • automake の結果
  • 深入りすると危ない。沼。極めないほうがいい。浅瀬について話す
  • CPANM = http://cpanmin.us マクロ
  • cpanm: ターゲット名
  • コマンドは TAB から始める
  • install: cpanm 疑似ターゲット: 依存名
  • Makefile をタスクランナーとして使う
    • リポジトリ、設定ファイル置き場、Ansible Playbook置き場、に置く
    • 複雑なことには向いてない。単一のコマンド、実行順が決まっている
  • make fix-commit-message make push make cancel-the-latest-commit make remove-added-file などを用意して使っている
    • zsh の補完が効くので、覚えなくて良い
  • make restart
    • postfix の restart 。文法がおかしいとエラーで止まるようにする
  • make test-conn-with-starttls
    • smtpのテストをするための
  • エリアスとして使っている
  • make deploy-public-key SSHREMOTEHOST=... ... に鍵を設置
  • make check-wordy
    • Perl Hackers Hub で決まっている禁則文字の処理
  • make すると git status するようになっている
  • test check clean などは共通のターゲット名とする
    • 共通の名前にしておくと戸惑うことがない
  • ホームディレクトリで make clean すると古いスクリーンショットが消える
  • Omake (おまけ)
  • -n ドライラン、 -f ファイル名、 マクロの上書き、 @ コマンド非表示、 - エラー無視

10年でどう変わった? はてなブックマークでのPerlの使い方 / 伊奈 林太郎さん ( @oarat さん)

  • はてなブックマーク
    • 2005 年リリース
    • 2008 年リライト
    • 2013 年デザインリニューアル
    • 2015 年フルリライト
    • 2019 年完了
    • Scala で書き直したが、Perlも使っている
  • 旧システム構成では、他のサービスも一緒に１つのコードベースに
    • .pm 400,000行, .t 270,000, html 70,000, gitmodules 30+
    • パフォーマンス上の問題（影響範囲が大きすぎて直せない）
    • サーバコストの増大
    • 書き直しコストは（うまくいって３年→書き直せるね）
  • 新システム構成ではマイクロサービス化
  • 250ms で返せた割合 4割から9割に改善
    • サーバ台数は半減
    • リリースサイクルは週から日へ
    • 仕様の整理
  • 困ってたところをどう解決したか100連発（無理なので一部）
  • 巨大なモノリス。単一言語
  • マイクロサービス化
    • HTTPでJSONをやり取り
    • 境界づけられたコンテキストで分ける、再利用性、言語の違い、リリースサイクル
  • 言語選択 Scala, Perl, Go, Python
  • バックエンドは Perl
    • ドメインモデルの表現
    • 更新頻度が低い部分
  • Perl
    • ビュー、デザイナも触る
  • Go
    • 非同期処理。小さく作る
  • Python
  • ジョブキュー
    • TheShwartz + WorkerManager だった
    • 重いジョブにリソースを専有される → キューが詰まる
    • Scala で使えない
    • 環境が壊れがち、動作確認が大変
  • Fireworq (Go) を開発
    • キューに専念する。複数キューを定義（思いジョブの隔離）
    • 同時接続のワーカ数を動的に変更可
    • ワーカはHTTPバックエンドとした
    • 2014年に作ったもの - ブックマークの作り直しのために先んじて作った
  • トランザクション
  • DDD
    • ファットモデル、ファットコントローラ(？)
    • アプリケーション層の役割がちぐはぐだった
    • アプリケーション層について議論、指針をドキュメント化
    • Perlはビューモデルの層なので大雑把
  • ファットモデル
    • 5,000行弱のエンティティ。副作用があらゆるところで起こる
    • 不変というルールにした
    • Perlでは Class::Accessor::Lite 。 Class::Mix で動的継承
  • Class::Mix
    • DOに動的にフィールドを追加する
    • clone_with で多重継承させる
  • 文化を継承する
  • 厚いフレームワークからの脱却
    • Ridge, DBIx::MoCo (RoRリスペクトの重いもの)
    • ブックマークチームしか使っていない
    • フレームワークから逸脱した利用が増加
  • Ridgeの辛いところ
    • 暗黙のディスパッチルール
    • URIとメソッドの対応が不明
    • ルールも複雑
    • before_filter after_filter 変なところにロジックが書かれて追えない
    • ほとんどが Ridge を継承
    • Plack + Router::Simple で書き換え
  • DBIx::MoCo
    • 変更操作を最後に書き出すものだが、 ->save で即時書き出し
    • キャッシュがあるのに、キャッシュを回避しがち
    • トリガで色々やり過ぎ
    • N+1 クエリ
    • 生クエリを書きがち
    • DBIx::Handler + Scope::Container
    • has-a 関係は複数件一度に引くメソッドだけを作る
  • Perlのバージョン
    • 5.8 だった。 CentOS 5 、 mod_perl 、 yum (CPANモジュール)
    • Plack化、cpanfile化、Docker化は失敗していた
    • 5.2x に書き換えた・・・すべてが輝いて見える
  • モジュールの動的ロードはしない
  • デッドコードは今すぐ消す
  • Elasticsearch のバージョンを上げられない（フィールド名が変わる）
    • 壊れてもわかりにくい。Scalaだと型付きなので安心
  • Twitterの文字数制限
    • Perlで再現するのは難しい
    • Scala なので Javaの公式パッケージならO.K.
  • プロジェクトの進め方
    • PoC、社内リリース、本番リリース、プロジェクト収束
  • PoC レビュー
    • CTO、チーフエンジニア、インフラ部長、旧システム識者
    • 捨てる仮実装 (捨てなかったけど)
  • 社内リリース
    • 社内URLをブックマークして利用
  • 本番リリース
    • 面の単位で新システムに切り替え（参照系から）
    • 面ごとに必要なデータをオンライン同期（5～10回）
  • プロジェクトの収束
    • 残っていた API、非同期処理、更新系
    • 使っているリソースに依存しているサービスを全回収
    • 2～3ヶ月かけてすべてのコードを読んで洗い出し
    • やることの総量は決まっていたので、ウォーターフォール的に進んだ
  • レガシーコードの考古学は気合い
    1. Class::Mixでtrait。 *::Role はどうして使わない？
      1. Class::Accessor::Lite しか使ってないので。 is_a とくっつけないと呼べない、の最小階
    1. canonical URLには対応している？ Twitterは？ 一番うざい点なんだけど
      1. Twitterが悪い。ガツンと言いたい。検討します
    1. DDDの学習コストは高いが、最初はどうした
      1. プロダクトコードに苦しめられたおっさんには教えやすい。新卒には厳しい。

他言語ユーザから見たPerlのおもしろさ / うたがわききさん

  • Python3 を書いてた
    • Python2 を無視することで乗り越えてきた
  • プログラミング言語、それを構成するものには色々ある
  • 単一の言語ではなく、比べることで見えてくるもの
  • my $x Pythonにはなく、Perlでは静的解析されてるのすごい
  • コンテキストは Perl 特有のもの
    • $x = @arr ($x) = @arr wantarray
  • %hash と @arr が互換なのが不思議
  • 関数の引数 shift $_[0] @_ args とかあってむずい
    • 「 Smart::Args 使うしか」
  • ( (1, 2), (3, 4) ) と書けない
    • [ [1, 2], [3, 4] ] ならいい
    • これは Python でも
  • package がクラス名
  • CPAN と名前空間
    • 名前空間の文化は良い
    • Acme はよい（ジョークであることがわかりやすい）
  • Try::Tiny
    • try catch って関数があるだけ。モダンな言語機能も手作り
  • Scope::Guard
    • Go でいう defer
    • $guard っていう変数は何・・・？ → デストラクタ
    • GC のついでによしなにモダン機能ができる
  • VSCode と Perl
  • package 宣言を自動にしてほしい
    • Perl insert package を書いた
    • package 名と use の補完

40分で学ぶPerl入門 / 木本裕紀さん

  • 右キーが効かないトラブル
  • 正規表現の使い所
  • find * | grep -P '(\.pm|\.pl)'
  • perl -pi -e 's/shimeji/enoki/'
    • すきやきでしめじと間違えてえのきを買ってきたとき
    • git reset --hard があれば戻れるので
    • 「 .bak を用意して、 .bak を戻す。 git 使っている方が現代人ぽい？怖くない？」
    • remote には全部残っている
    • いろいろあります
  • HTMLの aタグ の href を置換するライブコーディング
    • danさん、間違っていたら教えて下さい
    • やっつけ仕事には正規表現はいい
    • 「すべてが UTF-8 で完結していれば、 Encode は使わなくていいはず」
  • オブジェクト指向
    • スクリプトをベタ書きするときは使わない
    • 機能を分割して提供したい場合 (CPANモジュールとして使ってもらいたい)
    • OOPのほうがユーザには使ってもらいやすい
    • オプションの指定をコンストラクタでできる
  • Perlのオブジェクト指向
    • 他の言語と違って構文がない
    • データと名前空間を結びつけたもの
    • リファレンスと bless だけあればいい
  • ライブコーディング
    • bless を使う例
    • 今度は一回で出ました
    • new
    • でたー！！（発表終了）

Perlにおける動的なモジュールロードのメリットとデメリットについて / ybrliiu さん

  • TMTOWTDI が好き
    • OOPの実現方法がいろいろある
    • Perl のコアにOOPが入ったりするのは楽しみ
  • 動的なモジュールロードが辛い理由を明文化したい
  • アイテム効果クラス
    • 静的はめんどくさいから動的にロードさせるようにした
    • grep してもアイテム効果クラスの場所が見つからない
  • 動的なモジュールロードは柔軟性がありすぎる。保守性が下がる
    • 動的なモジュールロードが必要なときは保守性が下がらないよう
  • 静的なモジュールロード
  • 動的なモジュール
    • Module::Loadなどを使う
    • import は自動的に呼ばれない
    • CHECK INIT はスキップされる
  • 動的なモジュールロードのメリット
    • クラス名をまとめてコードを短くしたり
    • Module::Find
    • Catalyst 風 → use しなくても使える、パッケージ名が短くなる
    • プラガブルなモジュールを作れる
    • 動的ディスパッチ
    • 起動にかかる時間の短縮 (利用時までロードを遅らせる)
    • 相互依存の解決
  • デメリット
    • モジュール名を組み立てると greppability が低下
      • 静的ツール解析にも厳しい
    • ロードタイミングがわからないため、混沌とした依存関係が生まれる
    • 依存関係がわかりにくい、循環依存が見つけにくい
    • 依存しているモジュールが壊れていてもわからない
      • all_uase_ok とかで全モジュールをロードはできる
  • なるべく静的にモジュールをロードしたい
  • パッケージ名が長すぎる問題
  • use 忘れを防ぐ方法の代替案は不明
    • IDEが先頭に入れてほしい
  • まとめてロードするのは動的にロードするしかない
    • 設計が間違えている可能性がある
    • 動的ロードするなら all_uses_ok は必要
  • プラグイン機構
    • 外部で use したプラガブルなオブジェクトを投げ込むとか
  • 動的ディスパッチ
    • 事前ロードして対応表を作る
  • 起動時間の改善は動的ロードするしかない
    • 保守性と犠牲になるのでよく考える
  • 依存関係を動的に解決
    • if プラグマで選択的にロードできる
    • 循環参照は治す
    1. 動的ロードのまま直せなかったことは？
      1. 現在やり始めたのでまだ不明。いずれ話せるかも

似ているけどちょっと違うものたちをモデリングする技術 / hitode909 さん

  • 似ているけどちょっと違うものとは
  • 漫画サイトが9サイト目
    • 見せ方(週毎の更新か、など)
    • ビューアー(オフライン機能、定期購読機能)
    • ほか、管理画面、漫画の取り込み機能(エピソードだけ？価格も？)など
    • 同じ要件もあるが違う要件もある
  • コードベースは共通
    • Hostヘッダで
    • Perlで開発
    • 全サイトにデプロイされる。どこかが壊れれば壊れる
  • DBも共通
    • media_id
  • redisも共通
    • キーは１つのクラスに押し込み
  • 却下したこと
    • ビューワ、マイクロサービスごと
    • 別のDB / マイグレーションのタイミングがむずい
    • Hostヘッダでmedia id をわける
  • コードベースが線形に増えないようにする
    • 10サイト増えてコードが10倍になってはいけない
  • 列挙は避けてルールベースで共通化
    • 例: メディア名をもとに、URLを機械的に決める（列挙しない）
  • 値置き場は定義ファイルに追い出す
    • YAMLファイルに追い出している
  • ネームスペースの工夫
    • 特定のメディアの場合はメディア名をクラス名に入れる
    • 共通のものはメディア名を入れない
  • 機能に着目したネームスペース
    • Media が Feature を持つ
    • Core: 共通概念、 Feature: メディアごと
    • Giga::Feature に様々な機能を置く
  • 5サイト目まで作ったところで
    • どのメディアがどのフィーチャーを持つかを知るクラスを作成
    • 宣言的に定義
    • has_feature 特定のページに物を出すか出さないか
    • before_filter で処理を共通化
    • HasFeature フィーチャーがきちんと実装されているかをチェック
    • wip_feature_toggle 1リクエストでだけフィーチャーを有効化（デバグ用途）
  • Scrapboxにドキュメントをどんどん書く
    • 設計パターンをどんどん書く
    • 書籍を参考に
  • コンテキストマップをみんなで書く
    • 認識がずれたときに利用
  • 困ったこと
    • 共通化によるSQLの非効率
    • ボトルネックはどこになるのかはっきりしない
    • チームの舵取りが難しくなってきた
  • アプリケーションの要件に合わせた構造を作る。日々認識を合わせる。素朴だけでなくときには複雑なこともする
  • Google Jamboard は大きすぎるので注意
    1. メディアを取り違えたことは？
      1. ない
    1. はてブとは方針違う？
      1. コードの特性などが違うので。コードは難しいので共有している
    1. 依存が複雑になる。どう対処する？
      1. フィーチャーをパックにしてまとめて扱うと単純化されるのでは
    1. フィーチャーは Role ではないか？
      1. フィーチャーはオブジェクトではない。素朴なパッケージなので互いに鑑賞しにくくしたかった。一つのクラスにしたくはなかった
      1. Role は衝突回避なので使えるのでは
      1. 必要になったら議論していきます

らくらくPerl6入門 / 八雲アナグラさん

  • Rakuとは？
    • 僕が3歳のときに生まれた新しい（？）言語

    • rakulang

    • Perl5との互換性はない
    • 仕様と実装の区別
  • 名前の案
    • 6lang, Camelia
    • ダミアン先生が raku を提案
    • 箱根の焼き肉温泉rakuでハッカソンをすると盛り上がりそう
  • 歴史
    • Pugs
    • Parrot 初めてVM (開発停止)
    • Rakudo
  • Rakudo
    • Rakudo, NQP(Not Quite Perl。サブセット), VM
    • VM は MoarVM, JVM
  • Raku は 仕様の名前。 Rakudo が実装
  • NQP
    • Rakudo 開発者向け。プログラミングをしてはいけない
  • MoarVM
  • raku のダウンロード
    • rakudo-star
    • 6pad ブラウザで動く
    • ソースまるごと欲しい場合は perl6/z
  • Comma IDE 120ユーロ/年だが、無料も可能
  • Rakuの本
    • 海外では出ているが、昔の本では動かないかも
  • perl6 コマンドでインタプリタが起動
  • perl6 は分かれる
  • 拡張子 .pl を使うなら use v6 すること
    • 拡張子 .raku .rakumod .rakudoc .rakutest
    • Perl6 Modules からモジュールの検索が可能
  • raku のドキュメントは？
    • 公式ドキュメントを利用
    • 書籍はフローチャートを利用
    • ブログは妄想が書いてあることもあるから注意
    • Roast (テストシート)
    • IRCで問い合わせるのも良い (Alexander さんにツイッターで聞くのも)
    • Haskell To Raku とかもある
  • Rakuの遅さ
    • 速くはなってきている
    • Ruby Perl5 Python より早いケースも有る
    • 起動は遅い
  • シジルを使う
    • $ @ %
    • 変数のコンテナの種類を示す指示詞
      • コンテナを経由するので
    • @array_test[0] %hoge{"foo"} シジルは変わらない
  • . を使える
    • Mu (無) を継承している
  • デフォルト値
    • Nil を代入した途端にデフォルト値に戻る
  • %% 割り切れるか
  • ジャンクション 4 & 6
    • リストの中身をjunction にすると一度に処理可能
    • ? bool をとる、 ! 反対にする
  • 日本語に対応している 「」 が利用可能
  • sub でサブルーチンを定義
    • サブルーチンシグネチャがデフォルト sub add ($left, $right)
    • デフォルト値 sub add ($left $right = 1)
    • 名前付き引数 sub bmi(:$height, :$weight)
    • 書き換え可能な変数 sub setZero($n is raw) (ただしリテラルはだめ)
  • 引数の型指定 Int コンパイルタイム
  • @_ は厳しい
    • @_.shift と書かないと
  • class でクラス定義
    • === eqv
  • Twigil : public な API は . 、プライベート !
  • NativeCall
    • 共有ライブラリを実行時に呼び出す
    • C の rand 、 falk を呼び出す例
    • ライブラリなら呼び出せるので Go も呼べる
  • RakuのWAF
    • Crust, Bailador, Hematite, Cro
    • Cro がおすすめ。EDUMENTが商用サポート
    • CroでLDAPの実装
  • cro コマンド
    • cro stub http hello hello http で hello というモジュールを hello ディレクトリへ
    • Cro::HTTP::Router ルーチン具
    • Dockerfile の自動生成
  • Red
    1. Raku のセールスポイントは
    2. grammer や regex
    1. is_raw のエラーは静的？
      1. 試します。・・・実行時です。perl6 -c だと syntax ok
    1. Raku は末尾に 1; は？
      1. いりません

LT

LTに出ていたので、メモはなしです。

クロージング

  • YAPCは現地の人の協力が多大に必要
    • 開催地が限られる
    • 小さく開催
  • 参加者 48 , トーク 10 スポンサー 5,
  • 次回は京都 2020-03-27, 28
  • お疲れさまでした！