技術選択と聞いてみなさんはどんな印象を受けますか?
かっこよくてキラキラしている? 難しくて泥臭い?

プロダクトに採用する技術の正解とは何でしょうか? そもそも正解ってあるのでしょうか?

職業ソフトウェアエンジニアとして、人生の大半を費す仕事で触れる技術はなるべくなら楽しく好きなものにしたいです。
しかし同時にプロダクト・事業を成功させることも大切です。

職業人としての「正解」と趣味人としての「正解」は相容れないものなのでしょうか?

このトークでは仕事・趣味を通じてさまざまなプロダクトを立ち上げ・運用してきた体験を通じて「好き」を「正解」に近付けるためのエッセンスについてお話しします。

より詳細には以下のような内容をお話しする予定です:

• 業務で合理的な技術選択を果たすための観点
• 教育や採用・コミュニティ貢献について
• 趣味開発の選択にどのような軸を持つか

Perlに対する最大の誤解の一つに「型がない」というものがあります。実はPerlは単に型があるに留まらず、C言語などと異なり「型安全」ですらあるってご存知でしょうか?Perlの型の扱いは実にユニークで、Perlを主言語としない方もPerlの型を通して型(type)という概念を一段と深く学べるでしょう。

• What is type?
• Static vs Dynamic
• Textual vs Contextual
• Why typed that way?
  • Scalar (≒ Union?)
  • Array, Hash and beyond
  • bless it with the class

好きか嫌いかと問われれば好きに入るぐらい長らくSMTPに携わっていまして、1982年にRFC821となってから43年も経つ伝統産業みたいなSMTPは少しずつ現代の要求を満たす周辺技術が実装されRFC化されています。
本講では現代のSMTPを支える重要な技術について概説的にお話をします。

内容

• メールアドレスの役割・エンベロープ・ヘッダー
• 認証技術(SPF, DKIM, DMARC, ARC, BIMI)
• 暗号化(STARTTLS, MTA-STS, DANE)
• 大量配信での注意
  • レピュテーション(IPアドレス,ドメイン)
  • List-Unsubscribeヘッダー(Gmail等)
  • 商用配信サービスか自前サーバーか

対象

• 現代的なメール技術を知りたい人
• メール沼に入ろうとしている人
• インフラ担当で近所にメール沼がある人

複数のパッケージが同じリソースに依存している場合、どのようにしてコンフリクトを解決するのでしょうか？
また、依存関係が循環している場合、それはどのようにブレイクされるのでしょうか？

このトークでは、cpanmの依存関係解決の仕組み、そして現代の若者がPerlを学ぶ様子についてお話ししたいと思います。

私は以前からパッケージマネージャの依存関係解決に興味を持っていました。その美しくも複雑な仕組みが、どのようにスムーズなパッケージ管理を実現しているのか気になりますよね？ そして今回、探求の一環として「cpanm」の世界に足を踏み入れることにしました。依存関係解決の流れを具体例を用いてわかりやすく説明します。

主なトピック

• cpanmのソースコードを読み解く私の冒険と発見
• 依存関係解決の複雑で魅力的な仕組みの探求
• 現代の若者がPerlと向き合うリアルな様子

平成から令和、時代が変わりエンジニアを取り巻く環境も変わってきました。そんな中、技術やノウハウを伝える方法も変化していると思います。今と昔でどう変わってきたのか、これからはどうなっていくのか、今を生きるエンジニアに伝いたいことは何か、などについて豪華ゲストをお招きしてお話してもらう特別企画を用意しました。詳しくはこちら。https://blog.yapcjapan.org/entry/2023/10/12/200000

登壇者

• 櫛井 優介
• 伊藤 直也
• 和田 裕介
• 和田 卓人
• 馮 富久

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

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

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

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

というのをデモします。

RubyKaigi 2023 の前日に KeebKaigi 2023 があったりと、盛り上がっている自作キーボードの世界。
私は C でも Python でも Ruby でもない選択肢として Go (TinyGo) で自作キーボードを作っています。
自作キーボードと言えば、たくさんの人が各々の楽しみ方をしています。

このトークでは、自作キーボードの独自ファームウェアを作る経験から得られた 「プログラムを書いて楽しむ」 という新しい楽しみ方を紹介します。
普段使いするキーボードのプログラムは、ソフトウェアの改善をダイレクトに感じることができてとても面白いです。

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

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

概要

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

※フィクションです

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

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

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

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

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

-