現代はGitHub Copilotなどの生成AI開発支援ツールが普及していますが、簡単に使える一方で、「サンプルを生成して」等の単純な質問しかせず「ChatGPTで十分では?高いし!」という声も聞きます。
もったいないと私は思います!
チャット機能しか使わないのは確かに煩雑で「自分で書いた方が早い」と思うのも理解できます。しかし、ツールは進化を続けています。様々なUIや機能を活用し、AIとより良いコミュニケーションを取ることで、AIという相棒と共に、より効率的な開発をしませんか?
アイザック・アシモフの『鋼鉄都市』では、C(炭素=人間)とFe(鉄=ロボット)がバディになります。最初はR(obot)を嫌っていた人間の主人公も、最終的にロボットとバディとなりました。
それは小説ですが、SWEの皆さんも、人でない生成AIと良きバディになれると思います。共にC/Feの文化を築きましょう!
カンファレンス等では話を聞くことも多いテストコード。テストコードをかけると、それが命綱のような役割となり、安心してコードの変更を行えるようになります。
ですが、歴史の長いソフトウェアでは、様々な経緯からテスト環境が導入されていないこともあります。
本トークでは、Laravelなどのフレームワークを入れるのではなく、ゼロからテスト環境を導入する方法を解説します。
このトークを通じて、みなさんも関わっているプロダクトで、テストコードのゼロイチに挑戦してみませんか?
話さないこと
「複雑で辛いコード」という概念は確かに存在するものの、
その正体がどこにあるか…?を上手く説明できないという事態も、しばしば発生するのではないでしょうか。
プログラミングは往々にして「感覚」「センス」も重要なのは百も承知。
でも、可能なら地に足のついた説明を加えたいですよね。
色々な分析・説明の手法を頭の中の引き出しに入れておくと便利です。
そんな物差しの1つの例として、「LCOM」があります。凝集度を数量化するものです。
定義をしっかり記憶していなくても、
そのコンセプトは、目の前のコードで「何が起きているか」を感じるための大きな助けになります!
このトークでは、
「ざっくりLCOMってなに」を話し
「手書きで図にしてみると分かりやすいね、似た考えを普段から使えそう」を感じてもらい
「抽象化やパターンと絡めて、リファクタリングに取り入れてみるとこんな感じに」をお届けします。
最近またオレオレフレームワークをつくりました、私のフレームワークのポリシーは長生きができることです。
今回私が一晩で作り上げたフレームワーク()をベースに、どのような部分を意識することでコードが理解しやすく、長生きができる工夫をしているかをお話ししたいと思います。
機能が満載のライブラリやフレームワークに慣れている皆様は、「こんな素朴な規約やフレームワークは使いたくない!」と思うかもしれませんが、私は誰でもわかり、5年10年生き延びるフレームワークにしたいのです。
本トークはオレオレフレームワークにかぎらず、特定のライブラリと密結合せずデカップリングするようなコードを書く際にも役立つと思います。
皆さんも手のひらに収まるようなコードにして、暗黙を避け、ジョインした人がすぐにコードをかきはじめられるようにしてみませんか?
今では多くのPHPerが利用している静的解析ツールのPHPStan
このPHPStanについて踏み込み、上手く活用する方法とアンチパターンについて以下を参考にお話します。
皆さん、チームを分割してみたけど、結局また一つにまとまっちゃったことありませんか!?
チームが分かれれば効率も上がる、役割も明確になる…なんて思っていたのに、なぜかチームが再び一つに引き寄せられてしまったんです。
その原因、実は「コンウェイの法則」にあったんです!
このLTでは、どうしてチームを分割したのに再統合が起きたのか、そしてその結果として何が得られたのかを赤裸々に語ります。
私たちが直面した課題や学びをシェアして、みなさんの組織設計にも活かしてもらえたら嬉しいです!
可読性のためにコードのネストを浅くすることはとても良いプラクティスです。
ガード節はネストを簡単に解消できる手法として広く勧められていますが、途中リターンを多用することに問題はないのでしょうか?
このトークでは、ガード節を使うメリット・デメリットを詳しく分析し、さらに可読性を高めるために考案した新しいテクニックを、具体的な例を交えながらご紹介します。
ネストが浅くて読みやすいPHPコードの作成にきっと役立つ情報をお届けします。
モノリシックかつレガシーな肥大化したPHPアプリにお悩みではありませんか?10年近く長年運用されてきたアプリケーションでは、技術負債による開発・運用上の問題に苦しむことが多いのではないでしょうか。これらの問題は短期で簡単に解決できないケースがほとんどです。
そこで、本発表では、「改善」の手立ての一つとして、主にAWS Lambdaを活用したアーキテクチャの変更や機能分割を行うことで得られる開発運用効率化について実体験をもとにご紹介させていただきます。
自分の会社の製品には多くのサードパーティサービスが組み込まれています。
それらのサードパーティサービスは頻繁にバージョンアップするので、よくパラメータを更新する必要があります。例えば base URL や secret など。
HashiCorp Vault を使用して、ララベル向けの Config 管理インターフェースを実装することで、ゼロダウンタイムで Config の変更が可能なだけでなく、エンジニア以外の同僚も一緒に Config の管理できます。
連想配列に全てを詰め込んで旅をさせるのは良くないとは分かりつつ、
今まで巨大な連想配列をゴリゴリ実装していたチームが、配列からの脱却への一歩に挑戦しました。
完全な配列脱却は難しかったものの、バランスをとったリアルな挑戦ができたのでお話しします。
話すこと
郵便番号とは、当たり前に都道府県・市区町村が特定できるものだと、そう思っている人はいませんか?
まさか「複数の都道府県にまたがる郵便番号」なんてあるわけない、そう思っている人はいませんか?
そんな罠にはまった私が、郵便番号に関する実装をする際に気を付けるべき知見を、クイズ形式で紹介します!
ご存知の通り、レビューとは「講評」「批評」という意味です。
そのためコーディングにおけるレビューも、どうしてもレビュワーから実装者への一方通行コミュニケーションになりがちな側面を持っています。
しかしレビューとは、実装者とレビュワーが解釈をすり合わせる場であり、
双方向のコミュニケーションをしてこそ、漏れなく効率的なすり合わせができると私は思っています。
今回は私がPRレビューを双方向コミュニケーションの場にするためにしていることを、3つお話しします。
テストを書くことにもだいぶ慣れてきましたが、いまだに嫌で仕方ないものがあります。それがデータプロバイダです。
データプロバイダを書くのは面倒くさい。本当に本当に面倒くさい。
というのもリリース恐怖症の私は、テスト対象のありとあらゆる条件やパスを通したくなります。
「いや〜書かなくても大丈夫だろうけど、怖いし一応書いとくか…」を繰り返すうちに、どんどんテストパターンが増え、データプロバイダが膨大になります。
ここでは、私をそんな無限コピペ地獄から救ってくれた「差分だけデータプロバイダ」をご紹介します。
同地獄に陥っている方の一助となれば幸いです。
対象者
抽象構文木:ASTの名前は、PHPStanやRectorの普及もあり、少し身近な存在になってきました。
しかし「コンパイラでもない人間の我々が、なぜ喜ぶのか?」と思う人もいるはず。
名前や、チラッとだけ概念は知っている。けど、何をもたらしているのか──
そこで、ASTの概念の応用例に触れてみたら、その世界に入門しやすいのではないか!!というトークです。
「こういう事もできる(応用)」「そのために(基礎概念)」を話します。
例えばajthinking/archetypeはプログラマブルな「コード書いてくれる君」です。
ソースコード生成が「スタブの文字列置換やTwigのレンダリング」に頼らず出来るようになる!
じゃあ、その内側のどこにASTがいるんだ!
応用例から「逆に入っていく」アプローチで、ASTと少し仲良くなることを目指します。
Promiseについて、「分からん!」から「そんなものもあるんだ」を経て、「そういう風になっていて、そう動くのか」に至るためのトークです
PHPによる実装を試みます
PHPでWebアプリケーションを作る際、ほぼ全てのケースでデータ永続化の為にデータベースを利用するでしょう。
長年運用していくにつれ、テーブル数やカラム数の増加によって、認知コストやコミュニケーションコストが増加する一方です。
これらの負荷を下げる為に「DBスキーマを可視化する」ということは非常に有用であり、tblsは継続的な運用に耐えうるだけの機能を持ち合わせています。
本トークではtblsを用いたDBスキーマ可視化の実例を上げつつ、具体的なツール導入とCI設定の方法を紹介していきます。
Language Server Protocol (LSP)は、2016年にMicrosoftが発表したJSON-RPCベースのプロトコルです。
LSPはモダンなテキストエディタなら必ずある機能(e.g. 定義ジャンプ)を提供していますが、一番の魅力は特定のテキストエディタに依存しない形での実装になっていることです。
これにより各テキストエディタでの実装の必要がなくなり、エディタ選択の自由度が飛躍的に高まりました。
PHPの言語サーバ実装はintelephenceとPhpactorがメジャーです。
本登壇ではPhpactorの実装に触れつつ活用テクニックを紹介していきます。
メンタルは崩れると業務のパフォーマンスに大きな影響を及ぼします。
比較的メンタルが弱い私が継続して業務に携わるため実践してきたセルフケアやレジリエンスと言われる回復力の鍛え方をお話します。
基本的にどなたでもではありますが。
年月を経たレガシーなアプリケーションの検索処理は、肥大化したロジックによりパフォーマンスが劣化しがちです。本セッションでは、実際に直面した検索遅延を、OpenSearchを活用して改善した実例をもとに、選定理由から実装の課題、実際の効果までをお話します。
PHPカンファレンス沖縄2024にて @ex_takezawa さんのアクターモデルの話を聞いて衝撃を受けました
https://speakerdeck.com/ytake/understand-and-experience-the-actor-model-in-php
今回はPHPでアクターモデルを実現できる @ex_takezawa 作のPhluxorに入門し使用感と分散システムの優位性を探ります
https://phluxor.github.io
利用者の目線からPhluxorを使用する上での必要な前提知識や実際のハマりポイント、感じたメリットなど含めて分散システム入門します
より皆様に近い立場からの分散システムの実際の体験を共有し、少しでも分散システムが身近になることを目指します