サービスは生き物のようなもので、放置すれば腐ってしまいます。
適切なメンテナンスとアップグレードが必要です。
本セッションでは、古くなったPHPフレームワーク(Laravel)を再生するための具体的な戦略を解説します。
ユニットテストの導入、Laravelアプリケーションのコンテナ化によるインフラ刷新、Laravelアプリケーション/MySQLのバージョンアップなど、数々の挑戦とそれを克服した方法を紹介します。
これにより、デプロイ頻度の向上、テストコードによる仕様の明文化、システムの安定性を向上させることができました。
実際の成功事例を通じて、参加者はPHPプロジェクトの持続的な進化を支える具体的な戦略を学ぶことができます。
年月を経たレガシーなアプリケーションの検索処理は、肥大化したロジックによりパフォーマンスが劣化しがちです。本セッションでは、実際に直面した検索遅延を、OpenSearchを活用して改善した実例をもとに、選定理由から実装の課題、実際の効果までをお話します。
PHPは、エンジニア・案件ともに豊富となり、もはや習熟していれば使いどころに困らない昨今となりました。
一方で、copilotの台頭や経営層のIT解像度の深化等により、
エンジニアへ投資する目線もまたシビアになったと言えます。
そんな中で、より魅力的なプロダクト開発や優れたチームの構築へ、私たちを連れて行ってくれるものは何でしょうか?
競合に劣らぬ価値を発揮し、プロジェクトを牽引するには、何が必要とされるでしょうか。
本LTでは、業界、業種、業態(営業→開発、医療→エンタメ等)を問わず経験した話者の観点から、
「必要だったビジネススキル」「掛け算の重要性」を主題としてご紹介します。
技術に伸び悩んだ時どうすべきか。ビジネススキルとは何か。
具体・抽象を交え時間いっぱい詰め込みます。
本LTで新たな気づき・学びをご提供し、ご清聴賜りました皆様のエンジニアライフの一助となれれば幸いです。
書き初めとは、新しい年に初めて字や絵を書くことを指します。令和6年の師走、今年最初のSymfonyを書いてみませんか?
このセッションでは、オートワイヤリングに特化し、Symfonyでのオートワイヤリングを実際に体験していただきます。Symfonyが初めての方や、他のフレームワークを利用している方にも、安心してSymfonyに触れる機会となることを目指しています。ぜひお気軽にご参加ください。
バックエンド開発を担当しながらスクラムマスターを務めることになり、気づけば約1年が経過しました。この1年間、開発チームの速度を向上させるために、さまざまなアプローチを試み、試行錯誤を重ねてきました。
チーム内のコミュニケーションの改善、プロセスの見直し、ツールの導入など、いくつかの施策を実施してきましたが、特に効果が現れた方法に焦点を当ててお話しします。
本セッションでは、実際に取り組んできた施策の背景、その成果、そして今後の展望についても触れながら、皆さんと共有したいと考えています。
令和の今日。性別関係なく、メイクを楽しめる世界になりました。
その中でも、爪を塗る(ネイルする)ことは開発生産性を上げる効果があると、私は考えています。
この5分で、ネイルによって得られるメリットをご説明します。
LaravelプロジェクトにおけるL5-Swaggerの活用方法と、それによるAPI開発プロセスの効率化について深堀りします。
L5-SwaggerはLaravelでSwagger(OpenAPI)ドキュメントを自動生成するツールであり、APIの設計、開発、テスト、そしてドキュメンテーションのプロセスを大幅に改善します。
ぺちこん参加回数2桁になっている私が、「ぺちこんは楽しいから、もっといろんな方に知って欲しい!参加して欲しい!」そんな思いで声をかけ、毎年初参加者を誘うことに成功しています。
ぺちこん自体を知らない方、名前は知っているけれど踏み出せない方、いろいろいらっしゃる中で、私が日頃から行っている声かけやお誘いポイントをお伝えします。
システム運用時にslack通知設定をしているシステムは多々あると思います。
私が関わっているシステムでも、日々様々な通知をslackに出しています。
しかし、slack通知が多すぎて本当に必要なものが埋もれてしまったり、@channelだらけでミュートしたくてもできないチャンネルになったりしていませんか?実は通知が届いていたのに誰も対応できなかった、なんて経験はありませんか?
そんな運用の苦労を少しでも減らす方法を、実際に運用してみて直面したケースを例にお話ししたいと思います。
■話す事
・slack通知NGパターン
・slack通知を誰が見るか
・slack以外の手段
■話さない事
・slack通知の設定方法
DRY(Don't Repeat Yourself)原則はコードの重複を減らし、保守性を高める効果的な手法ですが、適用の仕方によっては仕様変更に対応できなくなることがあります。
私が直面したのは、二つの似た処理を一つのメソッドに統合し、フラグで細かい違いを切り替えるコードでした。しかし、片方の処理を変更すると、もう片方にも影響が出てメソッドが複雑化する…これ本当にDRYなん?と思いました。
このトークでは、当時はDRYだったものが、時間とともに保守性を損ない、結果的にDRYではなくなったケースについて紹介します。
何を共通化し、何を分離すべきかを考え直し、どのようにリファクタリングを行ったかについて具体的な事例を交えてお話します!
「当時はこうでよかったが、今ここに大変更を加えたい」と感じている方や、似たような体験をした方にとって、私の対処方法が参考になれば嬉しいです!
PHPは言語仕様として様々な条件分岐を持っています。if, else, elseif, switch, 三項演算子, match, &&, ||...職業PHPエンジニアの皆さんは日々これらを使いこなして仕事をしていることと思います。では、ユーザー要求や要件の中に、あるいは要求以前のビジネスの中に、仕様書やフローチャートに表される前の条件分岐の形を見出す力はどうでしょうか?自信ありますか?
このトークでは、PHPの様々な条件分岐を概観した上で、日常で人間が行っている様々なビジネス上の判断をPHPの条件分岐に落とし込む考え方についてお話しします。
様々な条件分岐が「見える」生活をしてみませんか?
This session bridges the gap between PHP and JavaScript by comparing modern features like arrow functions, classes, and destructuring in both languages. Attendees will see how PHP has evolved to include features familiar to JavaScript developers, simplifying cross-language development.
This talk focuses on leveraging modern PHP features like arrow functions, typed properties, and named arguments to write robust, clean, and maintainable code. It offers best practices for structuring and organizing code and includes examples of bad code, showing how to resolve these issues with specific PHP features.
みなさんのプロジェクトは、どのようなソフトウェアアーキテクチャを採用していますか?
明確なアーキテクチャが決まっておらず、各メンバーが異なる設計をしているプロジェクトも少なくないかもしれません。
私たちのプロジェクトもその傾向にありました。
本セッションでは、プロジェクトのリニューアルを機にオニオンアーキテクチャを導入した経験について、以下の内容を中心にお話しします。
• オニオンアーキテクチャを採用した理由
• Laravelにオニオンアーキテクチャを導入する際の具体的な手法
• Laravelでの実装時に直面するであろう課題とその解決策
• アーキテクチャを維持するための取り組み
• 導入によるメリットとデメリット
「オニオンアーキテクチャって難しそう」「導入してみたけどうまくいかなかった」
という悩みを持っている方々にとって、参考になる情報をお伝えします!
驚くほど人間的な回答で世間を賑わせたChatGPT。
しかし2024年時点では工夫をせずに依頼をすると「突然英語で回答する」「架空の資料を元に回答する」など、ビックリさせられます。
本トークでは、ChatGPTに思い通りの回答をさせるためのマインドやTipsを紹介し、少しでも思い通りな回答をさせる方法についてご紹介します。
PHPUnitを支える仕組みに、イベントシステム(Observerパターン)があります
何故?
もちろん、無闇にイベントが設計されている訳ではありません
「フレームワーク(FW)の作者や利用者が感知したい・拡張したいはず」のポイントを察知して
要所要所にイベントが仕込まれている!と考えられるでしょう
イベントを知る=FWの思想に触れる手掛かりになります
普段とは少し違う視点で、PHPUnitを眺めてみましょう!
コミュニケーションは様々な場面でギャップが生じてしまいます
発された言葉「以外」の解釈コストが高くなると、受け手のイラッ・モヤッに繋がります
(何が伝わっていないの?」など)
「明瞭な部分の比率を高める」のは有効です
例えば、発言時や受信時には「事実・解釈,意見・評価,要求」の区分が助けになります
こうした工夫が、自他を尊重した態度の表現に繋がります
発表者自身が「気にしている事」「気にしすぎないために考えている事」を共有します
良いコードは拡張しやすくて、そのためには適度な抽象化が必要でね──
プログラマーとしての向上を目指すと、いつでも「抽象化筋」が立ちはだかります。
が、「抽象化をできるようになるには?」と聞くと、抽象的な答えが返ってきがちで。
こいつは何だ?
私自身が「抽象に依存する、なるほど」「インターフェースって便利」と思えたきっかけの1つが、
「たぶん何かがここら辺にあって、そこに良い感じに話しかけると、きっと処理してくれるだろう」
で進む開発するスタイルに触れた事でした。
裏を返せば「話しかける相手は分からないけど、欲する事は明確である」が求められます。
抽象化思考の1つのヒントが、正にこの「過不足なく欲求を明確にし、表現する」にあるのです。
このトークでは、こうした感覚的な部分の言語化と共有を試みます。
更に、この思考とコードの記述を繋ぐ手法として「テスト駆動開発」の実践方法を紹介します。
ORMを使っている人は、それが「DBから取ってきたデータを、PHPのオブジェクトに変換して渡してくれるものだ」と知っています。
「SELECT文で取得した値からPHPの世界のインスタンスを作る所を、その目で見た事がありますか?」と問われると、如何でしょうか。
PHP製フルスタックフレームワークは、それぞれ特徴的なORMを有していることが多いです。
Active Recordか?Data Mapperか?という大局的な話から、もっと些細な「そのフレームワークっぽい癖や工夫」にも違いがあるでしょう。
このトークでは、少し踏み込んで「ORMのデータの取り方と組み立て方」を比較していきます。
「PHPStanを入れましょう」「静的検査、型の世界をやっていき」といった時に、
必ずしも「レベルをどうするか」「baselineがどのくらいあるか」だけに限らずとも良い訳です。
自分たちのチームやプロジェクトにとって弱みになっている部分、基準としていきたい部分について
ピンポイントでルールを入れていく道があります。
そのために、「使えるルール」が増えると良いですよね。そのまま「静的検査の語彙」になります。
さぁ!!phpstan-strict-rules が来てくれました!!!
必ずしも「全部を有効にする」っていう使い方ではないでしょう、そういうものは本体に居るはず!!
5分で全部のルールを紹介します。
紹介には、「どんなコードを指摘してくれるルールなのか?」が含まれます。