時刻 | トラックA | トラックB |
---|---|---|
18:50 ~ 19:00 | Opening 10min. | |
19:00 ~ 19:25 |
ゲスト対談(前半)
25min.
石田絢一 uzulla / Junichi Ishida, 和田裕介 yusukebe / Yusuke Wada
|
|
19:25 ~ 19:30 | 乾杯(株式会社ディー・エヌ・エー様) 5min. | |
19:30 ~ 19:55 |
ゲスト対談(後半)
25min.
石田絢一 uzulla / Junichi Ishida, 和田裕介 yusukebe / Yusuke Wada
|
|
19:55 ~ 20:00 | 乾杯(LINE株式会社様) 5min. | |
20:00 ~ 20:20 |
TypeScript へ型安全性を高めながらリプレースする
20min.
@kimuson
|
PHP で NFC リーダーを実装する
20min.
めもりー
|
20:20 ~ 20:30 | 休憩 10min. | |
20:30 ~ 20:50 |
my$talk=qr{((?:ir)?reg(?:ular )?exp(?:ressions?)?)}i;
20min.
Dan Kogai
|
ReDoS 検出の最先端 recheck の紹介
20min.
藤浪大弥 (@MakeNowJust)
|
20:50 ~ 20:55 | 初日クロージング 5min. | |
20:55 ~ 22:00 | 懇親会 65min. |
時刻 | トラックA | トラックB |
---|---|---|
13:30 ~ 13:40 | オープニング 10min. | |
13:40 ~ 14:20 |
5年にわたる"Perl の" REST API を "Perl で" GraphQL API 化し作り直す
40min.
@mangano-ito
|
じわじわとPerlからGoに移行しようとしている俺達のマイクロサービシーズの紹介
40min.
@macopy
|
14:20 ~ 14:30 | 休憩 10min. | |
14:30 ~ 14:50 |
スクラムでつくる頼もしく生き生きとしたチーム
20min.
五十嵐雄
|
Hono[炎] Ultrafast web framework for Cloudflare Workers.
20min.
Yusuke Wada
|
14:50 ~ 15:00 | 休憩 10min. | |
15:00 ~ 15:20 |
あなたの知らない(かもしれない)コアモジュール
20min.
白方健太郎
|
フロー効率の向上から始める開発生産性の高め方 ~ モブワークを沿えて ~
20min.
面川泰明
|
15:20 ~ 15:35 | 休憩(15分) 15min. | |
15:35 ~ 15:55 |
perlimportsから探るPPIの世界
20min.
八雲アナグラ
|
エンジニアの個人ブランディングと技術組織
20min.
Takafumi ONAKA
|
15:55 ~ 16:05 | 休憩 10min. | |
16:05 ~ 16:45 |
Acme、其はPerlのユグドラシル
40min.
@makamaka
|
7年間運用したソーシャルゲームをAmazon EC2構成からAmazon ECS構成へと乗り換えた話
40min.
@commojun
|
16:45 ~ 17:00 | 休憩(15分) 15min. | |
17:00 ~ 17:40 |
Keynote
40min.
松木 雅幸 songmu / Matsuki Masayuki
|
|
17:40 ~ 17:50 | 休憩 10min. | |
17:50 ~ 18:30 | Lightning Talks 40min. | |
18:30 ~ 18:45 | Closing 15min. |
1. スポンサーLT(ピザハット様) 2. さっぴー川原 「MyDNSとUnboundが同居していることにハマった」 3. Kang-min Liu「aaa.pl」 4. nikkie 「Perlの力も使って聴かせるAIの声」 5. ariaki 「CTOになりたいと思っていたけど今はそのときではないと気づいた件」 6. utgwkk 「prototypeとjust epic. と私」 7. タケタニヒロト「Perl詩を味わう」 8. kfly8 「Tシャツに書かれたコードを読む」
Suica や PASMO をデバイスにタッチして値を取得する、そんな夢を PHP で叶えました。 PHP7.4 から PHP FFI と呼ばれるものが導入されました。Suica や PASMO は FeliCa と呼ばれる NFC の規格の 1 つです。実装方法は多岐に渡りますが、概ね libnfc と呼ばれるライブラリや libusb を使う方法などがあります。しかし、今までの PHP ではこのライブラリを呼び出すことさえ叶いませんでした。そこで、本セッションでは PHP7.4 から導入された PHP FFI を用いてどのように PHP で NFC リーダーを実装するのか、そして実際のデモを交えてトークできればと思います。 Perl にも FFI があるようですので、このトークをみてご興味を持った方はぜひお試しいただければと思います。
正規表現。Perlが最も愛されそして(不当にも)憎まれる理由の一つ。しかし今や正規表現をサブ言語として持つ言語はPerlに限りません。本talkではこの最も人気のある言語内言語に関して、時間が許す限り型って、もとい語っていきます。 * regexp? what is it? * $supported_by ~~ @most_major_languages; * but how (much)?\? * Unicode support? * assertions? * modifiers? * use CPAN; * Regexp::Assemble; * Regexp::Common; * Irregular expressions * qr{(func?(?:tion)(\(((?:(?>[^()]+)|(?2))*)\)))} * (ir)?regular questions (?:from|by) the audience * ReDOS - Regexp considered harmful!?
※タイトルはtreeです CPANにリリースされる全てのAcmeモジュール(名前空間にAcmeを含むモジュール)を紹介するPerlの同人活動は、2021年度版『Acme大全』の発酵を以て、14年間の活動に笑止符を打ちました(終止符とは言ってない)。 拙作の奇怪ですので、これまでどのように活動に取り組んできたのか、 今まで出会った中で特に印象腐海モジュールは何だったのか、 Acme界隈の出来事や動向、そして「これから」について大いに騙りたいと思います。 アジェンダ - Acmeの扉 - 必要はAcmeの母 - 少々Acmeウゼェナ - 星のAcme
はてなマンガチームで開発している GigaViewer においては,REST API をサーバーサイドエンジニアがネイティブアプリの1画面ごとに毎回作り,画面の要素変更のたびにひたすらパラメーターを追加して提供していました. これを GraphQL API として作り直したことで,既存実装の再利用性も高まり,追加・変更時の開発効率も高くなり,決められたスキーマから自由に必要な要素を組み合わせることができるようになりクライアントサイドからも扱いやすくなりました. この発表では,5年にわたる Perl による既存のコードベースがあるうえで,いかにして,ライブラリと結合し 不足する機能を追加してパフォーマンス向上・GraphQL ベストプラクティスを導入できるようしたかや,どのようにチーム間で連携しながらスキーマファーストで開発を行い既存・新規アプリに導入していける柔軟な GraphQL API を実現したかについて話します. ## アジェンダ - REST API 時代における苦労の紹介 - 1画面1API から生まれる不必要な情報 - よく似たリソースの増加 - 再利用のしづらさ - 既存の設計をふまえた導入 - GraphQL ライブラリの導入 - キャッシュとパフォーマンス改善のための仕組み - GraphQL デファクトスタンダードに揃える - GraphQL ベストプラクティスを実現する拡張 - エラーハンドリングとスキーマファースト開発のための仕組み - ネイティブアプリ開発チーム・ウェブ開発チームを横断した連携と意思決定 - GraphQL 導入のための実験 - スキーマの決定と整合性を取るための会 - どう良くなったか - プロトタイプづくりが簡単に - ウェブでも使えるようになった - 機能の追加変更が簡単に ## ゴール - Perl による GraphQL 開発のための知見と手段について知る - プロダクトの特性に応じライブラリを拡張することで開発効率を上げる - チームを横断した枠組みで共同開発プロジェクトを意思決定して進める ## 対象者 - Perl による GraphQL 開発に興味のある開発者 - 既存のコードを活かしてより柔軟な API を提供したい開発者 - 既に GraphQL 開発を行っていて他社事例が気になる開発者 - チームを横断したプロジェクトを行う開発者
みなさんはサービスを運営していて、技術的な要因、もしくは採用的な要因でPerlでこれから将来やっていくことに行き詰まってしまうことはありませんか。 ありますよね、そうあるんですよ! というわけで面白法人カヤックが運営するトーナメントTonamelは様々な理由により、じわっじわっとPerlを主軸としたモノリスアプリケーションから、Goを主体としたマイクロサービス群へ機能を移設している真っ最中でございます。 このトークでは、2020年から始めた移行の歩みを道半ばですが紹介します。 * 移行に際してどのように現状と技術的もしくは開発リソース的に折り合いをつけていくか * どうやって2つの言語を共存させるか * 認証をどうするか * まだPerlから剥がせてないので、PerlアプリケーションがAPI Gatewayの役割を持っている話 などなど、そのへんのよもやまを話します。
Perl や JavaScript 等の動的型付け言語では柔軟性が高い利点もありますが、複雑化してきて思うように開発速度が出なかったり、メンテナンスが大変だったりと言ったつらさを感じてはいませんか? 本セッションでは動的型付け言語に静的型をつける「漸進的型付け」に触れながら、JavaScript を緩い型付けの TypeScritpt へ、そしてより堅い TypeScript へと移行する方法について、実際のリプレース事例を交えて紹介します。 トピック - 動的型付け言語つらい - Perl と JavaScript の実例 - 漸進的型付けってなに - がんばらない TypeScript: 緩いオプションなら簡単に移行できる - メリハリのある TypeScript: 堅いオプションで部分的に無効にしながら移行する - リプレース手順 - リプレースの結果 想定ターゲット - 運用歴の長くフロントエンドの環境がレガシーなプロダクトで開発をしている人 - JavaScript を使ってる or TypeScript に置き換え済みだが緩いオプションで思うように恩恵を受けられていない - 動的型付け言語ユーザー
はてなブックマークのWebチームでは、開発プロセスにスクラムを採用しています。なかなかスクラムを乗りこなせない時期が続いていましたが、2021年10月に大きな転期があり、チームが劇的な進化を遂げました。今では、2週間スプリントのゴールを適切に設定し、その達成の道のりを楽しむことができています。スプリントのゴールを達成するために、タスクの分解や日々のコミュニケーションも活発になり、安定したパフォーマンスを発揮できるようになっています。その安定したパフォーマンスを背景に、少し遠い未来の予定についても、根拠を持って答えられるようになりました。この発表では、スクラムチームを大きく進化させた方法や、実体験を通じて学んだスクラムのパワーをお伝えします。この発表を聞いたあなたは、きっと自分のチームでもスクラムを実践してみたくなることでしょう!
弊社KAYACで運用しているソーシャルゲームタイトル「ぼくらの甲子園!ポケット」は、2014年のリリースから、7周年を迎えました。開発チームでは、Amazon Linux OSのサポート終了に対応することをきっかけに、Amazon EC2構成からAmazon ECS構成への乗り換えをするという決断をしました。 - 従来のEC2によるシステム構成からコンテナベースのシステム構成へと乗り換えることで大きく変わった点 - リリース時からアップデートされず維持されていた、Perlのバージョンを5.16から5.30へとアップデートした際の苦労 - 長い歴史で肥大化してしまったリポジトリ特有の問題とその対処、どうしてもSPOFとなってしまっていたバッチサーバを冗長化する作戦 - システム構成の刷新といったような、専門的で、非エンジニアにはその恩恵が実感されづらい仕事を理解してもらい協力を得ることの重要性 …など、一連のシステム刷新作業を通して様々な学びが得られたので、それらについてお話させていただきたいと思います。
Perl をはじめ多くのプログラミング言語の正規表現のマッチングではバックトラッキングが使われていますが,正規表現パターンによってはバックトラッキングが爆発し,マッチングに多大な時間を消費することがあります.これを利用した DoS 攻撃の一種が ReDoS と呼ばれます. 発表者は recheck という ReDoS 検出プログラム (https://github.com/MakeNowJust-Labo/recheck) を開発・公開しています.これは最先端の ReDoS 検出アルゴリズムを実装していて,高速かつ正確な検出が可能となっています. 発表では,ReDoS という脆弱性がどのようなものか,どのようにして ReDoS を検出するのか,ReDoS を防ぐためにはどうすればよいのか,といった点について解説します.
僕らはインターネット上で開発の知見を得ることによってサービスを開発・運営できているので、インターネットに還元したい。そんな気持ちから、会社でもアウトプット (登壇や技術ブログ、執筆、OSS 活動等) が推奨されています。 社としての技術ブログも存在しますが、スタッフ個人のブログを通じて発信するのも同じように推奨していきたい。エンジニアの個人ブランディングも大事だと考えているし、自分の場所の方が書きやすいというのも感じているからです。 その上で、社内外の色んなサービスに散らばった技術 Tips を上手くまとめて再放流することで、手軽に情報を摂取し、技術的好奇心を満たし、成長し続けられる環境を用意したい。 そんな、個人の集合体としての技術コミュニティを運営する方法と、そのために開発したアプリケーションについて紹介します。