トーク

面白法人カヤックはYAPC::Hiroshima2024でゴールドスポンサーおよび椅子スポンサーを行なっております。
椅子スポンサーでは参加者の皆様にお楽しみいただけるコンテンツをご用意しております。始まるまでは明かすことはできませんが、なんらかの結果発表を行います。ご期待ください。

もしLT落ちてたら弊社のブログの方で後日結果発表を行います！！

自社サービスの会社でテックリードとしてプロダクトの0→1開発を2年ほど牽引しています。
2年間で試みたことのうち、「やって良かったわ〜」と思うことを4つご紹介します。

キーワード: 新人向けドキュメント、ADR、自動テスト、ライブラリバージョンアップ

私は会社のエバンジェリストという役割を担っています。
様々なカンファレンスにて話すことが仕事ではあるのですが、
登壇を行っていく中で仕事になっただけで、登壇する事は目的ではありません。

コミュニティに参加して、登壇者に憧れていたあの頃から、
少しずつ行動を起こすことでほんの少しだけ目線を変える事が出来ました。
その少しだけ変わった目線から、なぜ様々なカンファレンスにて登壇を行うのかを言語化してみます。

登壇者になると変わる直接的ないいところにもほどほどに触れながら、
特にそこから生まれるコミュニティの繋がりについてお話をします。
その中で逆説的に登壇する事が全てではないという事にも触れたいと思います。

私はコミュニティで良い方向に人生が変わった人間です。
そんな人が一人でも増える熱になれれば嬉しいです。

私はサーバーレスという技術が好きです。
サーバーレスは少しずつ浸透していき当たり前になってきましたが
私は変わらず追い続けている技術となります。

今回はなぜサーバーレスが好きなのかを言語化してみようと思います。

地方で様々な受託案件に取り組む中で感じた
地方こそサーバーレスという一つの選択について触れながら
サーバーレスのメリットに注目してお話します。

サーバーレスは技術の選択肢の一つに過ぎないと考えられている方もいらっしゃると思いますが、
その技術が含んでいる魅力を感じて頂けると幸いです。

UUV は warnings プラグマが有効なときに表示される警告のひとつ Use of uninitialized value の略語として使われます。
UUV を修正することは Perl アプリケーションの運用改善に貢献できます。
ライトニングトークの場を借りて UUV の修正のポイントを共有したいです。

「自分の書いたコード、なーんかイケてないなぁ...」

こんな悩みを持ったことありませんか？かくいう私もそうでした。
でも、変われました。コード難読化に出会えたから────

このトークでは初心者の私でも実践できた簡単なコード難読化の手法を紹介し、読みやすいプログラムを読みにくくします。
とはいえ、読みにくくするuglifyだけでは機械的で面白くありませんよね。
今回は難読化したコードをアスキーアートのように整形してbeautifyする手法もセットでお伝えします。

このテクニックさえ身に付ければライバルに差が付くこと間違いなし。

「〇〇さんのコード、最近変わったね」
プルリクエストで同僚を驚かせよう。

皆さんもこの春、コード難読化で自分を変えてみませんか。

「全員SRE会」とは私達開発チームがサービスの運用について振り返れていないよね、ということで発足した集まりです。

メトリクスは取っているけどどこに注目すればいいんだろう？、ログを取っているけどどうやって見るんだろう？、アプリケーションが遅いのはわかるんだけどうまく言語化できない、etc…
そんな実は自分たちが危うい状態なんじゃないかという危機感をもとにみんなでSRE的視点を持つことを目的としています。

とはいえ、今までいきなりSRE視点になることも、それを元に運用を変えることも難しいです。そこで私達がどう取り組み始めているのかを紹介します。

Webアプリケーションで使用するRDBMSでは、プライマリキーのデータ型として整数を利用するのが一般的です。一方、UUIDという選択肢もあります。私は、複数のプロジェクトでの具体的な経験、また、ある種の分散コンピューティングが避けられないという現代のWebアプリケーションをとりまく環境から、可能であればプライマリキーはUUIDにするとよい、と考えています。

このトークではUUIDとはなにか、どういう性質や利点があるのか、一方デメリットはなにか、を、リサーチと経験を交えて（駆け足で）お話しします。RDBMSと向き合うみなさんのデータベース設計に新たな選択肢を増やし、より安心・安全・便利・スケーラブルなソフトウェア開発の一助となると幸いです。

アイドルのコンサートやファンミーティングなど、アイドルへの応援したい気持ちをうちわを通して伝えるもの、それが応援うちわです。この文化をテックカンファレンスにも輸入しようと思いました。エンジニアにとっての登壇はアイドルにとってのコンサートと同じようなものでは？リアルタイムで応援されていることがわかると嬉しいのでは？という気持ちで、テックカンファレンスでも応援うちわを作っては持参しています。

作ったうちわの例：
https://twitter.com/sweet_chiho/status/1718048680157356543

今回はこの応援うちわの作り方を超かんたん編と上級編の2つにて紹介します。みんなで応援うちわを持ってカンファレンスを盛り上げましょう！

私は技術広報として年間10本程度のオフラインイベントを企画・運営しています。そしてオフラインイベントに欠かせないのが業務ホームパーティ、いわゆる懇親会です。懇親会でエンジニアのみなさんが楽しそうに交流をしているのを見るのが好きで、そのためにさまざまな工夫をしています。どのように懇親会を企画し、準備しているのか、これまで企画してきた懇親会も例として紹介します。
このトークをきっかけに、懇親会がより楽しいものになれば嬉しいです。

懇親会の例

• RubyKaigi 2023への気持ちを高める懇親会
• あえてお酒を提供しない、ノンアルコールでの懇親会
• and more

私は店舗向けの決済システムを開発しています。
クレジットカードをシステムで扱う事業者は、PCI DSSというセキュリティ標準に準拠することがほぼMustであり、年に一度の外部監査を受けています。

古くに考案されたクレカ決済の仕組みを支えるためのセキュリティ標準ですから、非クラウドの環境も考慮された要件が整えられており、悩ましいことも多く、
またクラウドベンダーから監査・運用業務を省力化できる便利な仕組みが提供されるため、毎年要件を確認し、業務と照らし合わせ、改善していくサイクルを回しています。

本編のトーク「VISAカードの裏側と “手が掛かる” 決済システムの育て方」とは異なり、本LTは相対する加盟店側を起点に話します。

単調になりがちな監査業務を自分たちの好みとすり合わせていくか。クレジットカードの監査に限らず、その他の監査でも使える（かもしれない）テクニックをお話したいです。

2023年のYAPC::Kyotoの前日祭LTマッチに非エンジニアとして参加し、MVPを獲得したhonchangです。
前日祭LTでは技術広報1年生として最初にどんな失敗をしたのか、その後どんな風に考えて、YAPC::Kyotoではどんなコンセプトでブースを出したのかといったお話をしました。
非エンジニアでもカンファレンスに参加することで得るものがあったので今回は非エンジニアの技術広報であるhonchangとカンファレンスの関係性をお話ししたいと思います！
トピックは3点

• 技術広報とスケジュール（納期、締切どんどんくるよね）
• カンファレンスとノベルティ（他社のノベルティ、つい研究しちゃうよね）
• そして自社イベントへ（イベント参加で学んだことを活かして…？）
  エンジニアではないけれど、カンファレンスをきっかけに自分の業務の幅が広がることがあるんだよ、ということをお伝えしたいです。

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

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

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

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

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

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

このトークの対象者

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

話すこと

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

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

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

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

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

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

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

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

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

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

ｽｯｺｺｺ!

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

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

対象者

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

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

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