PhpStormでGitやGitHub使っていますか？

• commitしてますか？
• ブランチの操作してますか？
  • rebase, merge, switch, pullやfetchやpushも？renameも？
  • cherry-pick, revert, コミットメッセージの編集も？
  • コンフリクトの解消も？
• コードレビューも？
  • コメントを見たり解決済みにしたりリアクションをつけたり？
• ファイルや行単位での変更履歴の追跡も？
  • 該当の変更が含まれるPull Requestを開いたりも？
• 「変更リスト」の管理も？
• stashも？
• bisectも？

みたいな話をします

「ライブラリが古いせいでやりたいことが出来ない」「利用バージョンのドキュメントが既にこの世に無い・・・」そんな経験はありませんか？

古いライブラリはセキュリティリスクをもたらし、技術的負債にも繋がります。
本トークでは週次でのライブラリバージョンアップを1年以上続けている実体験をもとに、継続的バージョンアップのメリットや安全に実施するために出来る工夫、はじめ方についてお話します。

想定観客

• バージョンが古いせいで苦しんでいるかた
• ビッグバンバージョンアップでつらい思いをしたかた
• セキュリティやパフォーマンスに敏感なかた

お話しすること

• なぜライブラリをバージョンアップするべきか
• バージョンアップ時に見るべきポイント
• 安全に上げるために整えている仕組み
• 継続的バージョンアップのはじめ方と文化作り

レイヤードアーキテクチャをはじめ、オニオンアーキテクチャ、ヘキサゴナルアーキテクチャ、いわゆるクリーンアーキテクチャ、他には独立したコアレイヤーパターンやADOPなど様々なレイヤ化アーキテクチャが存在していることからわかるように、レイヤを元にアプリケーションを構造化することはとても良いアイデアです。

しかし一方でレイヤを増やしたもののあまりメリットを享受できない場面も存在します。

このセッションでは、なんのためにレイヤ化をするのか、どういった観点でレイヤが作られるのか、レイヤ化することによってアプリケーションの複雑性がどのように管理しやすくなるのかといったことを考えてみたいと思います

Laravelの魅力でもあるEloquent Model。
良くも悪くも雰囲気で書けてしまう反面、特定条件下では正しく動かなかったり、パフォーマンスの悪いコードを書いてしまう恐れがあります。

本トークではEloquent Modelを使うときにハマりがちなトラップを取り上げて、それらが「良くない理由」と「どうすれば良くなるか」をご紹介します。

想定観客

• 雰囲気でLaravelを書いている方
• 不具合が起きにくいコードを書きたい方
• パフォーマンスの良いコードを書きたい方

お話しすること

• そのコード、nullが返ってきたとき死にます
• そのコード、クエリ1,000回発行されるけど大丈夫？
• そのコード、メモリ1GB使うけど大丈夫？
• 良くある間違いを仕組みで防ぐ (Laravel IDE Helper x PHPStan)

Renovate や Dependabot などが広く使われるようになったことでライブラリバージョンアップの対応頻度が高まっている現場は多いのではないかと思います。
ライブラリは導入することによって開発コストを大きく削減できる一方、使い方によってはバージョンアップの対応コストが必要以上に高くなりますので、バージョンアップ対応にそこそこの工数が取られている人も多いのではないのでしょうか。

このセッションではバージョンアップが楽になる使い方をいくつか提示し、それぞれのメリットデメリットを整理することでライブラリとの使い方・付き合い方について考えていきたいと思います。

PHP 8.4で追加された pg_result_memory_size() は、SQL実行結果の中でも memory_get_usage() に計上されない隠れたメモリ使用量を可視化します。特に大量データ処理時のメモリ不足リスクを軽減する重要なツールです。

この関数の実際の動作を見ながら、PHPでデータベースを扱う際の注意点と解決策を検討します。

1. メモリの種類: PHPが管理するメモリとそうでないメモリ。これらはサーバの動作にどのような影響を与えるのか。
2. 実例: PHP 8.4で実際に大量データを扱い、リソースのメモリ消費量を観測。
3. 開発者へのインパクト: ライブラリやインフラストラクチャ層での考慮ポイント。リソース管理の重要性。

対象者:

• PHP開発者で、メモリ管理やデータベース接続の効率化に関心がある方
• PHP内部の実装について興味がある方

みなさんはラフティングというアウトドアスポーツをご存知でしょうか？
このトークではゴムボートで複数人が急流に挑戦するという川のアクティビティのガイド（インストラクター）という一見畑違いの業界・業種からWeb業界に転職してきた私が、
「アウトドアツアー」と「ソフトウェア開発」という一見正反対にも見える２つ産業を経験したうえで気付いた２つの業界の共通点についてお話しさせて頂きます

世の中のプロダクトは、二つに大別出来ます。 「ライブラリ・フレームワーク」と「アプリケーション・サービス」 です。

この二つには何の違いがあるのでしょうか？それは、 「インターフェースであるか、ドメインであるか」 です。

一方は多くの開発者に向けて汎用的に作られたもの、もう一方は特定のエンドユーザーに向けて専門的に作られたもの。

この二つの目線を見分けることで、様々な諸問題と正しく向き合うことが出来ます。

このトークでは、インターフェースの目線とドメインの目線、二つの目線で技術に対することで得られるメリットをご紹介します。 「技術的負債」 とは何なのか。 「技術選定」 はどうすればいいのか。 正しい目線で物事を見極めたい あなたに、是非ご覧いただきたいと考えています。

質問①：最後に誰かにほめられたのはいつですか？
質問②：最後に誰かをほめたのはいつですか？

このトークでは人間関係を円満に保つのに重要な「アクノレッジメント」と、「今日から使える」その応用テクニックについてお話します

Interfaceの設計、していますか？

適切なInterface設計はコードの再利用性を高め、保守性を高める一方
不適切な設計をしてしまうと不要な複雑性を周辺に生み出し保守性に大きな悪影響を及ぼしてしまいます

このトークでは

• Interfaceを設計するとはそもそもどういうことか？
• 良いインターフェースの条件
• インターフェース設計の先にあるもの

といった切り口に対して

• サンプルコード
• 有名な設計原則
• 書籍の引用

などを用いながら「良いInterface設計」とその効果について解説します

プログラミングの現場で、顧客の要求する仕様をクラス設計していくと、共通する機能が出てくることがあります。
そこで聞かれる
「共通する機能ってスーパークラスに実装するのと、インターフェースにするの、どっちがいいんですか？」
という疑問。
それにお答えします。
より現場にありそうな問題を取り上げて、ドメイン駆動設計の入り口まで紹介します。。

＜対象者＞
・プログラミングを始めて2，3年以上
・オブジェクト指向でプログラミングをしている
・オブジェクト指向のプログラミングを理解はできるし、自分で書いているが、うまく書けているか自信がない

成長、できていますか？
皆さんは今年どんな成長をし、来年はどんな成長を計画しているのでしょうか？

このトークでは30代半ばでの初めてHello Worldから異業種からの転職を経て、「エンジニアとしての経験年数に対してパフォーマンスが高い」と評価を受けることが多くなった現在まで、「一貫して意識してきたたった１つのこと」についてお話します。

自身のスキルに悩んでいる方、成果を出せるように成長したい方のヒントになれば幸いです

サービスを切り出す際に、既存の再利用可能な実装を活用しつつ、ヘキサゴナルアーキテクチャを導入した背景とその効果を紹介します。このトークでは、特定のレイヤーにプロセス外依存や既存コードへの参照を局所化し、依存箇所を明確に管理することで、どのように開発効率やシステムの保守性を向上させたかを具体的な事例を通して説明します。

このトークでは、フロントエンドとバックエンドの整合性を保つために、スキーマ駆動開発（SDD）をPHPプロジェクトにどのように適用しているかを詳しくお話しします。スキーマを契約として定義し、その契約を守ることで、開発の信頼性と効率を向上させる方法を解説します。具体的には、スキーマ設計のプロセスから実装フェーズでの管理方法、さらにトラブルを未然に防ぐための戦略までを包括的に紹介します。

新しく加入したメンバーの皆さん、チームに馴染めていますか？
新しいメンバーを迎えた皆さん、メンバーに馴染めてもらえていますか？

一説によるとWebエンジニアの平均在籍年数はおよそ3〜4年だそうです
ということは、最初の半年〜1年である程度新しいメンバーを戦力化できないと、エージェントに支払う費用などを考えると企業としてはよくてトントン、悪いとマイナスになってしまいます

このトークでは「馴染む速さ」に定評のあるいち個人が最近の転職で経験した

• 「オンボーディングされる側」として意識していたことでうまくいったこと
• 自分が組織に馴染む速さを支えてくれた会社の文化
• 上記を２つを支えていると感じた社内の仕組み

についてお話させていただきます。

採用する側、される側双方にとってのROIの最大化のヒントになれば幸いです

TLS/SSLについて暗号化と証明書のチェックをする程度という理解でも困ることは少ないですが、もう一歩踏み込んでどのようなプロトコルになっているか、公開鍵の署名や共通鍵の暗号はどう選ばれ使われているのか、これらのレイヤーを詳しく見ていくと非常に興味深い世界が広がっています。
このセッションでは、そんなTLS/SSLの内部構造に迫り、技術の楽しさを共に味わいたいと思います。

数ヶ月前の私も、TLSについては漠然とした理解しか持っていませんでした。しかし、PHPでTLS1.2を実装する中でその複雑さが実に面白く、やがて「完全に理解した！」と言える境地にたどり着きました。

本セッションでは次の内容を発表する予定です

• TLSの基礎
• PHPでの実装ポイント
• 車輪の再発明の面白さ

15年間誰も手をつけられなかったレガシーシステムを、どのようにしてバグゼロでリプレースに成功させたのか、その実践的な戦略をお伝えします。
私の考えたオリジナルの手法をはじめ、シャドーテスト、カナリアリリース、ダークローンチ、ランダムテスト、フォールトマスキングなど、多彩な手法を駆使し、リスクを最小限に抑えながら安定したシステム移行を実現しました。
特に、これらのテクニックを組み合わせることで、予期せぬトラブルを未然に防ぎ、計画通りのリプレースを成し遂げたプロセスを詳しく解説します。
他のプロジェクトでも応用可能な、実践的な知見を共有しますので、システム刷新を検討している方にとって必見の内容です。ぜひご参加ください。

皆さん、チームを分割してみたけど、結局また一つにまとまっちゃったことありませんか！？

チームが分かれれば効率も上がる、役割も明確になる…なんて思っていたのに、なぜかチームが再び一つに引き寄せられてしまったんです。

その原因、実は「コンウェイの法則」にあったんです！

このLTでは、どうしてチームを分割したのに再統合が起きたのか、そしてその結果として何が得られたのかを赤裸々に語ります。

私たちが直面した課題や学びをシェアして、みなさんの組織設計にも活かしてもらえたら嬉しいです！

弊社M&Aクラウドでは会社や事業を売却したいユーザーと、その会社や事業を買いたいというユーザーがマッチングするプラットフォームを提供しています。
そのシステムでは、マッチングした場合のみに特定の情報が閲覧開示されます。
しかし既存の実装ではほとんどUIに近い層で情報をコントロールしていたためヒヤリとする実装となっていました。
このトークでは情報の開示レベルを制御する設計方法を紹介します。
PHPStanも活用し、コーディングの時点で開発者が迷うことなくオブジェクトを利用できる設計を紹介します。

皆さん、丸投げされてますかーーー！！！？？？

どんな現場にも「タスクとしてパスできる状態に仕立て上げる暇がないから放置されちゃってる仕事」というものがあります。
きっと上司やお客さんは「丸投げできる人がいれば・・・」と日々嘆いていることでしょう。
そう、なんと「丸投げされる技術」があれば一生食うに困らないのです！（過言）

私はよくお客さんから「こんな雑な投げ方なのにいい感じに対応してもらってマジで助かります！あざす！」みたいなことを言われます。

一体私はどのようにしてお客さんに安心して丸投げをしてもらい、どんな手順や仕草で仕事を進めているのでしょうか。

このLTでは、仕事を丸投げしてもらったときの私の頭の中身や実際にやっていることなどをまるっと皆さんにシェアします。

皆さんも丸投げされる技術を習得して青天井の信頼をGETしちゃいましょう！