概要
弊社がYAPCのスポンサーとして協賛しており、参加させてもらえることになりました。
大学時代を広島で過ごしたので、数年ぶりに帰れるのもとても楽しみでした。
今回は、試聴したセッションについてコメント・感想を書いていきます！
YAPCとは
YAPCはYet Another Perl Conferenceの略で、Perlを軸としたITに関わる全ての人のためのカンファレンスです。 Perlだけにとどまらない技術者たちが、好きな技術の話をし交流するカンファレンスで、技術者であれば誰でも楽しめるお祭りです！
視聴したセッション
ここから、視聴したセッションのうち発表資料が見つかったものを書いていきます。
Introduce Hono v4!!!!（前夜祭）
どんなJavaScriptランタイムでも動くWebフレームワークのHono（炎）の紹介です。
組み込みJSXやCSS in JS、Suspenceなどの機能が組み込みで使えるなど、全部入りですね。
つまり、JSXを使いたいからReactを入れて...のようなことが不要です。honoに入ってます。すごい。
前夜祭当日に最新版であるv4.0.0がリリースされました。
Cache-Control: max-age=86400（前夜祭）
キャッシュを適切に利用するには...という考え方を学べるセッションです。
処理を早くしたいからとりあえずキャッシュしていると、キャッシュが残っており最新の内容が返ってこない等問題が起こります。
では、どのような時にどのようにキャッシュを使うと良いのでしょうか。
-
目標とする速度を決める
まずは、このページは何秒以内に表示されるべき、このクエリのレスポンスは何msで帰ってきて欲しい、などを決めます。 -
キャッシュすることでどれだけ早くなるのか？
10秒の処理が1秒になると9秒短縮になりますが、1秒の処理が0.1秒だと0.9秒の短縮です。
また、該当処理がどれだけ頻繁に使われるか等を考慮し、この辺りで実装コストとのバランスを考えて優先度を決めます。 -
キャッシュの生存期間と消去・更新タイミングを設計する（ドキュメントも残す）
キャッシュを使用する際は消去・更新手段やタイミング等設計をしっかり行い、ドキュメントとして残しておきましょう。
そうすることで、他の開発者が該当箇所の動作確認をするときに「今参照したのはキャッシュなのか？」「更新したはずなのになぜ反映されない？」のような疑問をすぐに解決できるようにできます。
入門EOL対応 ~SREが鉄板の流れ全部見せます編~
EOLとは、End Of Lifeの略で、製品のサポート終了という意味です。
最近ではAmazon RDSのmysql5.7が2024/02/29に標準サポートが終了しますね。
このようなEOLにどのように立ち向かうか、という話です。
- まずEOL対応の優先順位を決める
- 手順書を書く（※対象読者の理解度を考慮する）
→実行!!
とはいえ、EOL対応やりたい！という方は少ないと思います。
ではどのようにモチベーションを保つのか。セッションの中ではいくつか紹介されましたが
その中でも最も大切なのは、必要だからやるのではなく、学ぶ機会と考えることだと思いました。
EOL対応をする際には、既存のプログラムへの影響範囲を考えたりする中でドキュメントを読むことが増えると思います。
そこで理解度を深めていけると良いですね。
What You Like May Not Be for Someone オープンソースとアクセシビリティ
どのような人でも使いやすいWebアプリケーションを作るにはどうすれば良いか、という話です。
↓こちらでは達成すべきテスト項目がまとめられています。
https://waic.jp/guideline/as/tests/
例えば、「ユーザーがコンテンツ内に閉じ込められないようにする」という項目では以下のようなテストを実施します。
キーボード操作：Tabキーでフォーカスをリンク「HTMLのリンク 1」へ移動させた後、Tabキーを押下するとFlashムービー内のボタン「富士通トップページへ」にフォーカスが移動し、さらにTabキーを押下するとフォーカスがFlashムービーから外へ出てリンク「HTMLのリンク 2」に移動するか
VISAカードの裏側と “手が掛かる” 決済システムの育て方
ベストスピーカー賞受賞セッションです。おめでとうございます。
クレジットカードで決済をしたとき、裏側で何が起こっているのかという話です。
アクワイアラー（加盟店契約会社）とイシュアー（カード発行会社）など、今まで知らなかったことが知れて非常に興味深かったです。
取引の都度発生するオーソリゼーション（仮売上）と、クリアリング（実売上）が一致しない場合は、返金したり追加引き落としが必要になります。
それらの突合ロジックが面白かったですね。
突合に使える項目が複数あり、各項目の正確性も異なります。それらを優先順に基づき段階的にマッチングしています。
ただし、1%はこれだけではうまくいかないパターンがあるようで...苦労を感じました...
My Favorite Protocol: Idempotency-Key Header
HTTPリクエストにおけるリトライと冪（べき）等についての話です。
HTTPリクエストにおいて、送金リクエストが例に挙げられました。
ネットワークエラーが発生した場合、失敗には２パターンあります。
-
クライアント→サーバへのリクエスト失敗
この場合は、サーバでの処理が完了していないのでリトライされても問題ありません。 -
サーバからクライアントへのレスポンス失敗
この場合は、プログラム上でエラーが起こらなければサーバで送金処理が完了しています。しかし、クライアントへの成功レスポンスに失敗したため、ユーザーは送金が成功したことを知りません。
2の場合にリトライされると、送金処理が再度実行されてしまい二重送金となる恐れがあります。
それを防ぐのが、Idempotency-Key Headerです。
リクエストの際にサーバ側のControllerやmiddlware層でIdempotency-Key Headerを生成、RDBMS（リクエストの度に揮発しないように）に永続化します。
こうすることで、既知のIdempotency-Key Headerが来た場合は送金処理を再実行しないような実装にすることが可能です。
Amazon ECSで好きなだけ検証環境を起動できるOSSの設計・実装・運用
ブランチ別開発・検証環境(Webサービスのサーバーを任意のブランチの状態で起動し、独立したURLで外部からアクセスできるようにしたもの)を好きなだけ起動できるOSSについての話です。
上記のような環境は主に、
- チーム外の人に開発中の状態を確認してもらいたい
- デザイナーが画像やアセットを実機確認したい
などエンジニア以外に向けてどのように環境を提供するか、という課題への解決策になります。
あらかじめいくつかの環境を立ち上げておき、メンバー内で使い回すこともできますが
管理コストや、インフラコスト、他のメンバーが使用中の場合待ち時間がかかるとうの問題が発生します。
そこで、以下のOSSが紹介されています。
検証環境の起動や、使用後の環境の掃除などが簡単に行えます。
変更容易性と理解容易性を支える自動テスト
こちらはt-wadaさんのセッションです。
自動テストを
- 信頼性の高い
- 実行結果に
- 短い時間で到達する
- 状態を保つ
方法に関する話です。
「信頼性が高い」とは、テストに合格した場合は即リリース可能、不合格なら重大な不具合があるとチームが確信できるということです。
また、ユニットテストの「ユニット」とは何か？という質問がありましたが、人によって解釈がかなり割れるということがわかりました。
そこで、メンバー内の認識を一致させるために
- Small・・・プロセスの中に収まる（高速）
- Midium・・・１マシンの中に収まる
- Large・・・1マシンの中に収まらない（低速）
という分け方が紹介されました。
CIで実行するテストの中でSmallの比率を高めることでテストを高速化できます。
また、Smallが失敗した場合はMidium以降を実施する必要がないため、無駄なリソースを使うことも防ぐことができます。
好きな技術《コト》で、生きていく技術
長いエンジニア人生で、ソフトウェアづくりを楽しいものにする技術選択についての話です。
レガシーなサービスにおいて、使われている技術に対して不満が溜まったとき、「自分が選定当時の環境に立ったとき、違う判断を下せるのか」という考え方が刺さりました。
技術選定者を尊重し、味方になれるようなエンジニアでありたいですね。
古い技術について—SMTP現代事情つまみ食い—
最近SPFについて調べることがあったので、タイムリーだと思い聴きました。
SPF・・・誰がどこから送るのか
DKIM・・・改竄がないかチェック
のような意味合いです。
まとめ
このようなカンファレンスに参加したのは初めてで、色々と刺激をもらえました。
会社として参加させてもらえたのは非常にありがたかったです。
登壇したら友達が増えると聞いたのでゆくゆくは登壇を目指したいですね...