Web サイトの 78% を支えるといわれる PHP ですが、最近の世情はどうも機械学習全盛の時代なようで、PHP でこのナウい技術へ触れるための方法はあまり選択肢がありません。最近主流の盛り上がっている技術、と、Web の主流と言える言語、の間に大きなギャップがあるわけです。
このトークではこのギャップを埋めるべく krakjoe (Joe Watkins) さんが最近に開発したライブラリ、PHP-ORT を紹介します。
https://krakjoe.github.io/ort/
どのような環境で、どのような速度で、どのような処理が可能なのか、そして既存のソリューションとの差異について、駆け足で解説していきます。
GitHubには多くの便利な機能があると知りつつも、 「結局どれを使えばいいのか分からない」 「CI/CDやAI活用をどう始めればいいか迷っている」 と感じている方は多いのではないでしょうか。
開発のスピードと品質を高めるActions、Codespaces、Copilotなどの機能は、単体で使うだけでなく、DevOpsの実践やチーム開発の改善にもつながります。
本セッションでは、GitHubを使っている・これから活用したい開発者を対象に、私が実践しているGitHubの活用方法を15分で紹介します。(全部言えるかもしれないし言えないかもしれません)
10月にはGitHubの年次カンファレンスである「GitHub Universe」に参加予定ですので、カンファレンスの様子も交えてお話しする予定です。
Azure Virtual Desktop(以下AVD)はMicrosoftが提供しているDaaSです。
DaaSですので、デスクトップを使用することが多いのですが、
デスクトップだけでなく特定のWebページを配信することも可能です。
AVDにおけるWebページ配信の方法についてご紹介します。
コードレビューでは、人格攻撃をしてはならないとされています。
それは裏返せば、書かれたコードをレビューするときに
それを書いた人のことをどうしても考えてしまう、ということでもあります。
自分が攻撃(非難)されたように感じてしまうのも、同じこと。
自分が書いたコードは、あたかも自分の一部であるかのように感じる気持ちがあるのです。
しかし現在、生成AIがコードを書くようになってきています。
人間が書いているところを補完してくれたり、
自律的にコードを書いてPull Requestの作成までしてくれます。
では、そのコードはあなたが書いたものだと言えますか?あるいは、思えますか?
このトークでは、コードと私たちの距離について考察します。
(心理的な)オーナーシップの話だけでなく、責任の分界点についても見ていきます。
生成AIの導入で変わりつつある距離感について、一緒に考えてみませんか。
「AIが相棒なら、1人で全工程実装したプロダクトを作れる……!!」
そう思った瞬間、ゼロからの個人開発に挑戦することにしました!
技術選定は、大好きなPHP、初めて使うInertia.js、そしていつかちゃんと学びたかったAWSインフラ構築。
このトークでは、私がなぜ個人開発を選んだのか、仕様策定から設計・実装・テスト・デプロイまで、開発フローの各段階でAIをどう活用したのか、AIと一緒に試行錯誤して挑戦する個人開発ストーリーをお届けします!
また、短期間で動くサービスに仕上げるための工夫や、個人開発で成長するために必要な考え方についてもお話します!
聞きに来てくれた皆さんには、「AIという相棒がいるからこそできる、新しい技術の学び方」を持ち帰っていただきたいです!
カンファレンス参加をもっと楽しくするアプリを作りました!当日みんなで使いたいです!
このトークでは、ある仮説を提案します。
技術的負債の、「利率」にあたる部分はチームメンバーの増加によって見かけ上増える
プロダクトの開発で機能とソースコードが変更されると貸借対照表の借方に新機能によって得られる価値(正味現在価値)が入り、貸方に技術的負債が入ると捉えられます。この、貸方に入る技術的負債が通常の負債とは異なる性質を持つと言うのが、この仮説の骨子です。
トークでは、貸借対照表や正味現在価値などの用語についても解説を加えます。
この仮説を通して、各チームで
・技術的負債の解消をするかどうか
・いつ技術的負債を解消するか
・カスタマイズをすべきかどうか
・カスタマイズをする場合はリファクタリングを計画するか
などについて議論を深めるきっかけにしていただくことを目指します。
※内容の正確さには注意を払いますが、私は会計学の専門家ではありません。
2012年頃から開発が始まったシステムを現在リプレースしています。
開発開始当時は社内に知見がない中で苦労をして価値を出してきたことは素晴らしいことだと思います。しかし、10数年たった現在さまざまな問題があることも事実です。
転職を機に現在このシステムを、基幹システムのリプレースに合わせてリプレースをしています。DevOpsが国内で話題に上がる様になって10数年経過した現在ではDevSecOpsのような、セキュリティを開発フェーズから意識する考え方も普及してきています。
このセッションでは、私が10数年DevOps/CI/CDを継続して進めてきた経験を活かし、0から構築している環境の考え方や実践している内容を共有したいと思います。
PHPカンファレンス福岡10周年おめでとうございます。
この10年で、私はアラサーからアラフォーに進化しました。
本トークでは、技術や仕事との付き合い方の変化についてお話しします。
最新技術は面白いです。でも1年後には違う技術で盛り上がってるんだろうなと思うこともあります。
若い頃は最新技術に夢中でしたが、今は新しさよりも、自分が熱を持てるものを重視するようになりました。
一方で変わらないのは、誰かの役に立ちたいという気持ちです。
気づけばマネジメントされる側から、する側になりました。
チームが楽しく働ける環境を作れると、嬉しいですし、やりがいもあります。
今回は「アツいトーク」がテーマということで、気恥ずかしさもありますが、私のパッションをお伝えしたいと思います。
同じ時代を技術者として過ごしてきた方や若い世代の方に、N=1のサンプルとして共感・参考にしていただけると嬉しいです。
当時、「効率よく生きることこそ、正義」というマインドを持っていました。
「楽をして生きること」が正しいと考えていました。
しかし、時代の流れと共に「何物でもない」ことへの焦りを感じていました。
そんな私が
好きな技術に出会い
コミュニティイベントへ参加し
ブログや登壇などアウトプットをするようになり
今や好きなことを仕事にできています。
実体験を元に今に至るまでの過程をご紹介したいと思います。
好きなことを仕事にするための何かヒントになれば幸いです。
アプリケーション開発において重要な非同期処理。
昨今ではLLMを利用した機能開発の需要も高まってきており、
特にレスポンスに長時間を要する推論モデルを利用する場合などにもやはり非同期処理が必要となってくる場合があります。
本セッションでは、Laravelのジョブキューを用いた非同期処理について、
適切に運用するために重要なキューワーカーの台数・ジョブの優先度・タイムアウト・リトライといった設定、重複実行の防止方法や考え方などを初学者向けに分かりやすく紹介します。
「ふりかえり会で決めたTryは達成した。でも、なぜかチームは苦しいまま……」
「合意した要件・仕様を作り切った。それでも、プロダクトは思うように伸びない……」
「設定した個人目標をクリアした。なのに、評価が上がらない……」
こうした状況は、なぜ起きるのでしょうか?
実は、その背景には、「そもそも何を問題と捉えるか」という出発点のズレがあります。
どれほど見事な解決策でも、問題設定自体がズレていれば得られる価値は低くなります。
問題設定の質が、成果の上限を左右してしまうのです。
本セッションでは、"時間的変化"と"視座操作"という2つのアプローチを使って、問題設定の質を高める手法を紹介します。
皆さん、バイナリやバイトコードはお好きですか?
さて、Java、Python、Lua、Ruby他、モダンな言語は言語VMという機構を備えています。さらに、WebAssemblyのような、特定の言語に依存しないVMもあります。
そしてご多分に洩れずPHPにもVMがあります。とはいえ、PHPプログラマが直接VMのバイトコードを書くわけもなく、「OPcacheが使うなんか高速にするやつ」というふんわりした理解の方も多いのではないかと思います。
このトークではPHPのZend VMを通して、VMとはそもそも何か、なぜ必要か、VM実装の基本についてお話しします。以下のトピックの予定です。
・VMに関する基礎知識
・レジスタマシンとスタックマシン
・バイトコードの基本
・言語におけるVMの意義とメリット
・PHPのZend VMに触れてみよう
・Zend VM互換のVMを自作してみた(?)
みなさんはnikic/PHP-Parserをご存知でしょうか?
様々なライブラリの裏側で使われているPHP-Parserですが、実は皆さんにとっても身近な存在かもしれません
このトークではPHP-ParserやASTの概要について軽くお話しするとともに、
PHP-Parserを利用してASTの差分を取り、同じプログラムであることを保証することで軽微なリファクタリングを気軽に行う方法を紹介します
「レガシーな環境だし、テストもないからLinterをかけたいけどかけられない」
そんなお悩みを持っている方の一助になれば幸いです
「設計ドキュメントは必要か?」
この議論は開発現場でたびたび持ち上がります!
ドキュメントが少ないことでスピードが出るチームもあれば、丁寧な設計が結果的に開発効率を高めるチームもあります。
複数の開発チームを経験する中、『チームトポロジー』を読んで「ドキュメントの最適なあり方は、チームの特性に依存する」という気づきを得ました。
本トークでは、以下の観点から「チームごとに適したドキュメント管理の考え方」について具体的にお話しします。
・ドキュメントの必要性とは
・チーム特性に応じたドキュメント管理
・実際のチームで実践しているドキュメント管理方法
設計やチーム運営に関わるエンジニアにとって、明日からの開発をより良くするヒントを持ち帰っていただける内容を目指します。
「スタイルとは何か。野生とは何か」──元同僚がXでつぶやいたとき、探索的テストにまつわる曖昧さに、改めて目を向けるきっかけになりました。
Cem Kanerが「スタイル」と呼んだこのアプローチは、仕様の曖昧さに対して、観察・仮説・検証を繰り返す“ふるまい”です。それは、私自身の思考のクセに根ざしつつ、チームの存在によってアプローチとしての気づきが促されてきました。
本セッションでは、探索的テストを「スタイル」として捉えることで見えてきた、属人性・再現性・品質との向き合い方を語ります。QAの実践における“野生”──型にはまらない問いとふるまいが、どんな価値を生んできたのか。その軌跡を共有します。
「やべっ!テスト落ちた!!一旦Rerun!!!」
──みなさん、これ、やっていませんか?(特大ブーメラン)
通ればラッキー、通らなければ…まああとで考えるか、というアクションに陥りがちです。
このような"たまに落ちる"Flaky Testを放っておくと、じわじわとテスト全体の信頼性を失っていきます。
私自身、何度も同じ轍を踏んできましたが「そもそもそのようなテストを書かないようにする」勘所を掴んできました。
このトークでは、Flaky testになりそうな臭いのするテストの勘所、そして、そもそも生まないためのテストの書き方について話します。
話すこと
・Flaky Testになりやすいパターン(キーワード: 不定な並び順, 非決定的な現在時刻, 日付が変わると落ちる, ...)
・Flaky Testにしないための書き方
・Flaky Testをそもそも生まないために
Amazon RDS Blue/Green Deploymentは本番DBのクローンを作成し、更新後にスイッチすることで安全かつ高速にリリースを行う仕組みです。
ダウンタイムめちゃ少なく移行できる!!というのが旨みで時間のかかるDBアップデートもユーザーに負担をかけることなく終わらせることができます。
これを完遂させるまでにはいくつかの悩み・ハマりポイントがありました。
そのため実録として、どのように運用したか実際に作った手順書も大公開します。
不安の多いDB バージョンアップをハードルなく進めるための指針となる話をします。
話すこと
・Blue/Green Deploymentとは
・実録〜前もって確認すること・手順書・リアルな所要時間〜
・Blue/Green Deployment を選ぶ場面、選ばない場面
・やってみてわかったDBバージョンアップの勘所
何かを志そうと思った時
「どうせ無理」
「そんなのできる訳がない」
と言われたり
「私にはどうせ無理か…」
と諦めてしまったりすることがあるかと思います。
システムエンジニアとして働く中でそんな”どうせ無理”に抗い、今では好きなことを仕事にすることができています。
どう抗い、どう好きなことを仕事にしてきたのかをご紹介します。
誰かが少しでも自分らしく生きるためのヒントになれば幸いです。
PHPでwebシステムを開発をしていると、必ずと言っていいほど日付に関わる処理を実装します。
「契約開始日から1ヶ月後の契約だけこんな処理を。。。」
「この条件は注文された日から30日間だけ有効で。。。」
「受注日より前の注文だけ取得して。。。」
新人エンジニアの頃、何気なく渡されたタスクで、何気なく実装した日付に関する処理でエラーを連発してしまいました。
DateTime->modify('1 month')
が1ヶ月後にならない簡単そうなタスクに見えて落とし穴がいっぱいの日付について話します。