デジタルIDウォレットを利用できる環境が整備されつつあり、「高度な保証レベルと優れたユーザー体験を備えた身元確認」が実現する未来がすぐそこまで迫ってきています。
「日本でのApple Walletの身分証明書機能の展開」のニュースのように、マイナンバーカードのスマートフォン搭載は、これまで以上に一般的になっていくでしょう。また、一般的なサービスがウォレットを利用する方法も、AppleのVerify with Wallet APIを始めとして、AndroidやWebでも準備が進んでいます。
本発表では、現状を振り返りつつ、開発者として今後この状況を楽しみ尽くすための知識として、ユーザー体験の概略や、HPKE(RFC 9180)、mDL/mdoc(ISO/IEC 18013-5)について解説します。また、プロダクトへの応用やもっと先の期待したい未来の話にも触れていきます。
バックアップはITシステム運用の基礎中の基礎です。本セッションでは、バックアップの重要性と基本的な概念から、効果的なバックアップ戦略の立案と実施までを解説します。初めてバックアップに取り組む方や、現在のバックアップ方法に不安を感じている方に最適です。本セッションでは実際の事例を交えながら、バックアップの失敗談とその回避策についても触れ、参加者が直面しがちな課題に対する具体的なアドバイスを提供します。セッション後には、信頼性の高いバックアップ戦略を立案し、実行するための自信を持てるようになることを目指します。
内容
さくらインターネットの「さくらのクラウド」は2023年度にデジタル庁が募集したガバメントクラウドに、2025年度末までに全ての技術要件を満たすことを前提に認定されました。
2024年6月現在、デジタル庁の技術要件を満たすため、パブリッククラウドとしての機能強化とサービスの開発に取り組んでいます。
数多くの技術要件を満たすには、開発力の大幅な強化のためのエンジニアリング組織の拡大、また一人ひとりのメンバーの変化と成長が必要となっています。
そのために、私たちは学び、一丸となるための取り組みを行い、組織体制の改善を進めてきました。
本発表の主な内容
大きなチャレンジをする開発組織についての一つの事例として、また議論のきっかけになれば幸いです。
AWS Lambda FunctionURLを活用し、従来の開発モデルで作られたWebアプリケーションを最小限の変更でサーバーレス化する手法を紹介します。
カヤックが運用するeスポーツ大会支援サービスTonamelでは、Goで実装されたマイクロサービスをECSからLambdaへ移行し、急激な負荷増加への対応とコスト削減を実現しました。
今回のYAPC::Hakodateスポンサー連動企画Perlbatrossでは、Perlで実装したWebアプリケーションをLambda上にデプロイし、CloudFrontと組み合わせて低コスト運用を実現しています。
本トークでは、Lambdaに移行するメリットとデメリット、GoやPerlアプリケーションのLambda化、デプロイ手法、複数開発環境やサービスメッシュの実現方法、VPCアクセスとインターネットアクセスの両立など、実践的な内容を扱います。
カンファレンスって楽しいですよね。同好の士が集まる場があるということは、それだけで私たちをワクワクさせてくれます。
では、自分でやってみたいなと思ったこと、ありませんか?カンファレンスと言わずとも、何人かで集まって、お互いに知見を交換し合ったり、お悩みを相談し合ったり…そういった場に、何かしらの形で関われたら…と思ったことは?
このトークでは、私が勉強会やカンファレンスに飛び込んだり、立ち上げたり、広げたり、誰かに託したり、諦めたり、そして人生が変わったり(!)してきた経験から、そんな皆さんの後押しになるかもしれないエッセンスを、「今日の懇親会で早速使える小技」なんかも挟みつつお伝えします。
YAPCは、みんなで作るお祭り。今日のこの場は、運営の皆さんの「やっていき」と、私を含む全員の「のっていき」の連鎖によって作り上げられた場です。
あなたも、ほんのちょっとだけ勇気を出してみませんか?
eBPFについて紹介するトークです。
ただ紹介するのではつまらないので、eBPFのLoaderをPerlで自作し、KernelにAttachします。
この発表を通じて現代のLinuxにおけるeBPFの使われ方と、eBPFバイナリの面白さを伝えます。
eBPFのバイナリの構造を理解したい方
PerlでeBPFを実行してみたい方
今回は秋口の開催ということで次期バージョンの話はあまりできなさそうですが、現行の Perl 5.40 の機能を中心に最近の Perl 界隈のニュースなどを紹介します。
大規模言語モデル(LLM)は、今や多くの企業や開発者にとって身近なツールとなりました。しかし、その実装には様々な課題や考慮すべき点があります。
本セッションでは、ここ1年半ずっとLLM時代のプロダクトの設計・開発・営業・導入に取り組んできた中で得られたLLMの実装パターンとその実際について、ソフトウェア開発者が活用するという視点から解説します。
コンテンツ:
国内では、思ったほどLLMらしいプロダクトやその活用が増えていない危機感があります。
本セッションを通じて、明日からなにか取り組んでみる、プロダクトに反映させてみる、というきっかけを作れたらと思います。
「推測するな、計測せよ」パフォーマンスの話題でよく耳にするフレーズですが、その実践は意外なほど難しいものです。
ひとくちに「計測」といっても、何を計測するかを判断し、得られた計測値を解釈するとき、開発者の技量は大いに試されます。
数ある「計測」ツールの中でもひときわ強力なのが、perfやpprofに代表される「プロファイラ」。
プログラムの関数単位で呼び出し回数や実行時間を集計し、flamegraphなどのビジュアライズを出力できます。
しかし、使いこなすためには少々の知識が必要です。
Rubyプロファイラ開発者として、一人のプロファイラおたくとしてこれらの疑問に答え、良き「計測」をする方法、そして理想のプロファイラについてお話しします。合言葉は「全部知る」!
現代のソースコードのエラー分析やフォーマットなどの機能はその多くがエディターの拡張機能ではなく、LSP(Language Server Protocol)を介して言語サーバーと通信することで実現しています。
これにより1つの言語サーバーから、様々なエディターでその言語のコード記述の支援機能を提供しています。
言語サーバーは開発しやすさや利用者の開発環境の状況からTypeScriptで書かれることが多いですが、LSPに沿ってさえいればPerlでも実装することができます。
本セッションではPerlを使ってVSCodeで動くPerlの言語サーバーを実装する方法をお話しします。
対象
話さないこと
Mutation Testingとは、プロダクションコードに対するテストコードがどれだけ十分に書かれているか?という観点から、テストコードの品質自体を評価するテスト手法です。
これまでのプロダクションコードの品質のみを担保するのではなく、一歩進んでテストコードの品質をも担保しようという比較的新しい観点です。
これを導入することで何がよいかというと、見かけ上のコードカバレッジが高く、全般的にテストコードが網羅できていたとしても、テストコードが正しく書けているとは限らないのですが、その部分を簡単に検出できるということです。
今回は「Mutation Testingとは?」という詳しいお話から始め、実際にMutation TestingをJavaScript,PHPに導入するまでの道のりや、その際に直面した問題点、その問題点をどうクリアしたか?なども含めてお話しできればと思います。
本セッションでは、分散システムのような複雑な仕様や動作を持つプログラムに対して、様相論理を用いてその仕様を記述し検査する技術について解説します。
我々はシステムの仕様を保証する際、テスト設計や自動化ツールのような、仕様を「テストする」ための方法論を考えがちです。しかし、その前に仕様が「記述できる」ことが前提であり、これは決して自明ではありません。例えば、分散システムに対して「一部のサーバが落ちてもいつか回復する」といった性質なんて一体どうしたら表現できるのでしょうか?
複雑なシステムの仕様を考える上で、自然言語による曖昧性を排した「共通言語」を定義したいという動機は、古くから現在に至るまで、研究と実用が交わる大きなテーマの一つであり続けています。本セッションではこのような「共通言語」としての様相論理について、自分では手を出しづらいあなたのために、しかしできるだけ誤魔化さず解説します。
プログラミング言語AWK第2版の発売やシェルスクリプトのテクニックなどが以前に比べて多くみられるようになっています。一時的なスクリプトを作るには少々手間なコンパイル言語が普及してきたことや、さまざまなバックグラウンドを持った人でも読めるようなリンガフランカとしてこれらの軽量なスクリプト実行環境が用いられてきたと考えています。
しかし元々そのポジションにいたのはperlコマンドではないでしょうか? CGI時代の影響からかPerlはWebアプリケーションを書くための歴史的な言語であるという認識が広くみられますが、本来得意なのはテキスト処理です。またコマンド同士を繋げるグルー言語としても非常に有効に機能します。
このトークではawk,sedとの互換性、もしシェルスクリプトをPerlに置き換える場合などを例に、Perlを採用するメリット・デメリットを述べていきます。
スタートアップのQAエンジニアとして、品質マネジメントを行っています。
このトークでは、アンチパターンとベストプラクティスを交えて、
品質マネジメントにおけるリスクマネジメントの勘所である"プロジェクトリスク"と"プロダクトリスク"の見分け方ををお伝えします。
〈話すこと〉
・JSTQBに基づくリスクマネジメントの概要
・リスクが顕在化する要因と開発プロセスへの影響(実例)
・プロジェクトリスクとプロダクトリスクの違い
・リスク識別のベストプラクティス(自社の取り組み)
・今、必要とされる品質と品質マネジメントの必要性
皆さんが未来のリスクマネジメントに役立てられることを願い、一般論と経験を交えて説明します。
プログラム上で非決定的な要素、例えばPromiseなどを扱うことは多いでしょう。非決定的な要素は扱うのは難しい印象がありますが、一方で現在から続いている未来の可能性とも理解できます。この可能性を継続渡しという手法でプログラム上で表現できます。
このセッションでは継続渡しという関数型プログラミングの考えを始めから解説し、try ~ catchやパターンマッチングの面白さを伝えます。また、デザインパターンとの比較を交えつつ、その特徴を探っていきます。
特に初心者の方に、プログラミングで表現できることの広さと、日々の業務では遭遇しないコードを味わっていただけるお話をします。
突然ですが、サービスの中で最も寿命が長い要素は一体何でしょうか?おそらくそれは「永続化されたデータ」のはずです。コードは少しづつ改善していくことが可能ですが、データ、特にユーザーのアクション起因で保存されるものは全く変わらないこともあるでしょう。
しかし、例えばサービスをリニューアルするとなった場合に、永続化されたデータをそのまま利用することは可能でしょうか?リニューアルにあたって、データ構造を変えたくなることもあるでしょう。
とはいえ、どのように進めるとよいでしょうか?
このトークでは、複数のサービスリニューアルと、それに伴うデータの引越し経験を元に以下の点についてお話しします
また、 これまでの経験を元に、少しでも長くサービスを運用していくためのポイントも考察していきます。
本トークでは、私たちが Architecture Decision Record (ADR) を導入してからの 3 年間の経験と学びを振り返ります。今では社内の複数の開発チームに導入されている手法です。
ADR を導入する前の期待と、実際の成果、また運用中にどのような課題が生じ、どのように対処してきたかを共有します。
ADR を運用してきた実際の経験を共有することで、ADR の運用に対する理解を深め、他の開発チームが同様の手法を導入する助けになることを目指しています。
"AI"の発展でますます「何にでも答えてくれる」存在として使われつつある電子計算機ですが、「計算機」が根源的に扱うのは今も昔も数値。 情報処理 ≡ 数値処理 なのは今も昔も変わらないのですが、それゆえに今も昔も変わらないのが「一個ずれる」(off-by-one)エラー。本talkでは筆者が実際に体験した二つ(以上?)の実例を通して、視聴者のみなさまにもその悲哀を共有していただきます。ちなみにどちらも見事 Perl 本体のバグも踏み抜きました。
あなたは最近「顧客提供価値が大事」とかいう言葉のもとに、新しい技術や攻めた設計をあきらめていませんか?
私たちエンジニアにとって、顧客の要望に応えることはもちろん重要です。
しかし、それが理由で自分たちの技術的な理想を諦めるべきなのでしょうか?
私はそうは思いません。
このセッションでは、誰になんと言われても「いい開発環境」を作りたくて頑張っている私の取り組みと、その成果についてお話しします。
このセッションを通じて、最新の技術トレンドを追いかけることと、堅牢な設計を維持することのバランスをどう取ってきたか、そしてそれがチームやプロジェクトにどのように役立ったかを共有します。
このセッションで触れる内容
・devcontainersを活用した開発環境構築
・PlanetScaleなどのサーバーレスDB
・なにより「エンジニアにとって楽しいことってなに?」ということ
私は2003年からperldocjpプロジェクトでのPerlドキュメントの翻訳に参加し、現在まで更新し続けています。
言語のドキュメントは、分量があるだけでなく、定期的に更新されるため、翻訳をそれに追随させ続けるための工夫が必要になります。
このセッションでは、このようなドキュメントを翻訳し、それを更新し続けるために行った技術選択や工夫、作業を助けるために作成した小物ツールについて概説します。
※ 実例はPerlのものですが、考え方は他の環境でも応用できる内容を想定しています。