私は2010年からWebエンジニアとして働き始め、最初に触れたプログラミング言語がPerlでした。
それから14年が経ち、キャリアをしみじみと振り返ることも増えてきた中で、あの頃に学んだことが今の仕事の姿勢にも強く影響を与えていることにふと気が付きました。

・「ラクダ本(プログラミングPerl)」を読み、「怠惰・短気・傲慢」というプログラマ三大美徳を知ったあの日。
・dankogaiさんの「アルファギークに逢ってきた」を読み、ギークという生き方に憧れたあの日。

Perlに出会えたからこそ、あの頃にエンジニアになったからこそ、学んだことが大きな糧になっています。
今だからこその気づきをお届けし、参加者のみなさんにとって何か気づきになる話ができれば嬉しいです。

WebcamとChat GPTとText to Speechを使ってAIに自分の見た目を褒めてもらうとめっちゃウケる。

というのをデモします。

OSSへのコントリビュートはハードルが高いと思っていませんか？
誰でもできる！という話はいろんなところで聞きますが、本当にそうなの？と疑ってしまいますよね。
私も例に漏れずその一人だったのですが、先日無事に一歩を踏み出しました👏

このトークでは、”初めてOSSコントリビュートしてみた初心者”の視点から
「実際にやってみて思ったこと」を電光石火の如くお話しします。

みなさんのお好みの技術をこれからも守り、さらにその技術の可能性を広げていくために
「OSSコントリビュート」という選択肢も増やすことができたら嬉しいです！

このトークの対象者

• OSSを利用している人
• コントリビュートに興味があるけれど、一歩を踏み出せていない人

話すこと

• 技術イベントに参加し続けることで感じた、OSSコントリビュートに対するイメージの変化
• 実際の流れとやってみた感想

目的を達成するための手段としてのプログラミング言語には様々な選択肢があります。
プログラミング言語の選択は、技術選定の一環として重要な事柄です。

それはそれとして、趣味でコードを書くときや自分のためのちょっとしたハックなど、どの言語を用いても良い状況も度々あります。
そのようなシーンで「これが最も手に馴染む武器だ」といえる言語が1つあれば何かと便利です。

手に馴染む武器としてのプログラミング言語が、どのようなシーンで活きるか。
実例を交えつつ紹介します。

IT エンジニア経験のないメンバーに向けた，IT エンジニア界隈の空気感を理解してもらうための取り組みの一部をお話しします．
今回は取り組みの中から「テックブログを読む会」を取り上げて紹介します．
　
ここ数年で「技術広報」という仕事をよく耳にするようになりました．
私自身は技術広報ではありませんが，所属チームにその役割が内包されています．
このチームには技術に関する仕事をしてこなかったメンバーもいます．
いわゆる技術広報的な役割を果たすならば，界隈の空気感を知る必要があるだろうと考えています．
（IT エンジニア界隈の空気感そのものの良し悪しについては一旦置いておいて......）
　
これを達成するための手段の一つとして，みんなでテックブログを読んでいます．
毎週 30 分の取り組みですが，そろそろ始めて 2 年が経ちます．この効果をまとめます．

あの待望の続編がYAPCに帰ってくる！！！

概要

RDBの寿命はアプリケーションより長い。
そんな背景から、様々な設計が生まれ、時には多くの人を困らせる場合もあります。
そんな現場で見つかった驚きの事実を皆様にお送りします。

※フィクションです

ご紹介するアンチパターン(仮）

• 波動拳SQL
• スマートカラム
• ゴッドテーブル
• UIの重力

などなど、多くの現場を見てきた私が見たアンチパターンとそれの処方箋についてご紹介します。

この日、そーだいなるストーリーに……全広島が……泣いた……。

The Perl Foundation（TPF）はPerlの開発を支援する米国の団体です。当トークでは、TPFの活動を紹介します。

TPFはカリフォルニアに籍をもつ非営利団体でPerlの開発を支援しています。具体的な活動は以下のとおりです。
・開発者への補助金援助（昨年度実績1200万円）
・北米のカンファレンス
・White Camel賞
・募金、広報、商標管理

このトークでは現在の状況、さらに日本のコミュニティと今後どうやって協力していくかなどの展望を話します。

長生きなプロジェクトを運用していると、途中からコードフォーマッターを導入したり、コード変換器を用いて別の言語に変換したりして元のソースコードのファイルが別のソースコードのファイルに転生しちゃうことってしばしばありますよね。
こういった場合、変換後のファイルのgitのコミットログが fmt! とか Transpiled! みたいな感じで塗り潰されてしまい、元のファイルが持っていた歴史が消滅してしまうことがあります。そうなるとlogを辿ることで変更意図を探ってみたり、blameを眺めてニッコリしたりという有益な作業ができなくなってしまい困ること必至です。
そんな状況を解決するために「古いファイルの行レベルの変更履歴」をそっくり新しいファイルに引き継いでコミットを積み直すツールgit-theseusをこの度作成しました。本LTではこのツールのデモと、どう機能を実現しているかを説明します。

人間は他者と情報交換する際に、脳で思考し文章を構築した後、喉などの肉体的な組織を用いて発声しています。発声した音声は相手の脳へに耳や骨を通じて送り込まれます。

近年ではSlackやMS Teamsをはじめとするテキストのみでの情報交換の機会が増加傾向にありますが、依然として発声することによる情報交換の割合は多いです。実際、リモートワークでもZoomやGoogle Meetsを利用している方も多いのではないでしょうか。

しかしながら、人間に発声器官は一つしか搭載されていません。なので、ここで障害が発生すると重要な情報交換手段を失うことになります。

そこで、本セッションでは、人間の発声器官に依存しない、仮想的な発声器官を構築します。さらに、そのシステムを用いて、対面での会話やオンラインミーティングを行う方法を紹介します。

PerlのコードをPerlとCloudflare WorkersとDeno DeployとWebブラウザ上で動かします。

YAPC::Hiroshimaで、YAPCに初参加するPHPerです！！
めちゃくちゃ大盛り上がりなYAPCに便乗して、私の畑としているPHP界隈のことを話します。
みなさん、知っていますか？PHP系カンファレンスは、2024年1月から2024年6月まで毎月あるってことを..........！！
（なんとこれだけではなく、下半期も予定されています！！）

2024年、怒涛で開催されるPHP系のカンファレンス情報をドカッと紹介します！！！
Perl界隈の皆様にPHPの魅力と情熱を伝えることを目指し、様々な「お好み」を語りつくします！融合しましょう！！

ｽｯｺｺｺ!

不具合や障害発生時にSlackなどでエラー通知を受け取ることはありますよね
そのとき、即座に何をすべきか具体的な対応方法をイメージ出来ますか？
エラー発生時の対応は、迅速かつ効率的でなければ、小さな問題が大きな障害に発展することも……！！

そこで、私がエラー通知を受け取ったときの初動〜対応完了までに「何を考えて」「どのように対応しているのか」をストーリー仕立てでお伝えします！
このLTを聞けば、「エラー通知来ないでほしい」と願っている皆さんも、通知が来ても慌てることなく、冷静に対応できるようになっているはずです！

対象者

• 「エラー通知が来たら何をしますか？」に即回答出来ない人
• エラー通知は先輩がなんとかしてくれると思っている人
• 新卒エンジニア、新卒エンジニアがチームに加わった先輩エンジニア

みなさんは日頃 git コマンドのうちいくつのサブコマンドを利用していますか？ブランチの切り替えのためにまだ checkout を利用していますか？ そもそも今使っている git のバージョンはいくつですか？

このLTでは筆者が最新版の git で使えるおすすめのサブコマンドや設定項目を独断で次々と紹介します。ここで学んだものは今日から早速使っていきましょう！

GitHubでレポジトリを表示したときに一番最初に確認するのは、レポジトリ内のプログラミング言語比率のグラフだという方は多いのではないでしょうか？あのグラフは、GitHub謹製のライブラリ「Linguist」 (github-linguist/linguist) によって、ファイルの内容をヒューリスティックに分析した結果が表示されています。
そんなLinguistには、けっこう最近までPerlとRaku (Perl 6) の実装をうまく区別できないという問題がありました。このLTでは、この問題をある程度修正したpull requestを起点に、Linguistの仕組みや、PerlとRakuの似ているところ・似ていないところについて紹介することで、トークを聞いたみなさんが † Linguist 《言語学者》 † のようにPerlとRakuのコードを見分けられるようになることを目指します。

OSDNはマニュアル日本語化プロジェクトにとっても便利なサービスでしたが、現在崩壊状態にあります。人々がこれにどう立ち向かったかについて簡単にお話しします。

APIのテストをどのように行なっていますか？

curlでの実行をはじめ、Postman、HTTPie、Scenarigoといったツールを使って実行していることもあるでしょう。
チームでの保守のしやすさ、CIへの組み込みやすさといったさまざまな観点でこれらのツールを整理した上で、私が業務でも利用している"推し"のAPIテストツールをどのように利用しているかを紹介します。

現在、Perlの開発をしているPaul Evans氏は、こんなことを言っています。

“Perlをもっとよくしていくには、公開されている機能をギリギリまで使い倒して、できる人たちに「そんな無茶なやり方よりもっといい方法がある」と言わせるといい”
-- Blog: Charsbar::Note 「London Perl Workshop 2016に行ってきた 」より引用

実際、氏の取り組みが、try/catch, class構文といったperlの進化に繋がっています。

graphql-jsを忠実にPerlに移植するプロジェクトを進めると、型表現や非同期処理など普段使いのPerlでは難しい問題に直面しました。
が、その問題を解決することは、プログラミングをする根源的な楽しみでした。

本トークでは、移植時に必要になったType-Aliasや実際の移植結果を紹介します。

私はEmbedded SREとして日々業務に取り組んでいます。

Embedded SREの魅力は、開発チームに参画し、信頼性の向上に努め、Opsに関する知見を持ち込むこと、と同時に、開発チームが必要とする開発基盤のニーズを見出し、全体最適化を図るようプラットフォーム組織に働きかけることです。

Dev組織とOps組織の狭間に立ち、仲介者となることで両者の強みを最大限に引き出す、このどっちつかずな立ち位置が、以外にも私にとってはとても動きやすく、気に入っています。

本セッションでは、そんなEmbedded SREの魅力と開発組織への影響についてお話したいと思います。

キーワード

• Embedded SREとは？
• どっちつかずの立ち位置で開発チームとプラットフォームチームの帽子を被り分ける
• サイロ化破壊装置としてのEmbedded SRE

技術的負債とその改善について、失敗を共有するスタイルでアジャイル開発の考え方について話します。
これまでの開発の中でたびたびわからん殺しされ、後から振り返ると技術的負債を作り込んできました...

アジャイル開発については、慣れ親しんでいるXP（エクストリームプログラミング）のプラクティスをベースにします。
XPのプラクティスを知ると「こういう考え方は全然していなかったな」と思い至り、心に深く沁み入ります。
プラクティスの実践で同様の失敗を回避できている感覚があり、ここで紹介する考え方は発表者が"好む"考え方です

・「リリースした後直します」は絶対タイミング来ないよ！！
・要件を満たす最小限の実装
・既存の実装は最小限なので、要件の追加に合わせて大きく作り変えることも1つのリスペクト
・機能追加しやすくなるようにまずリファクタリングする
・機能追加にちょっとずつ混ぜ込む負債返済

サーバー監視 SaaS である Mackerel の OpenTelemetry 対応の一環として、ラベルつきのメトリックを自在に引くための PromQL エンジンを開発しました。PromQL は Prometheus というオープンソースの監視ソフトウェアで使われているクエリ言語です。

新卒エンジニアが初めて携わったこの大型開発の裏側とそこから得た学びを共有します。リリース10年目を目前にする SaaS に、 OSS に依存する大きな機能追加を行うエンジニアリングをみなさまにも追体験していただきます。

こんなことを話します：

• なぜ PromQL を選択したか
• 既存のシステムを壊さずに生かすアーキテクチャ設計
• どこまでを OSS に任せ、どこからを自分達で作るのか
• 素早く動くものを作るためのマインド
• OSS の挙動を広く・あるいは深く理解するための道具