トーク

コミュニケーションにおける「パス」について、「コミュニケーションパス」がまず頭に浮かぶと思います。

いわゆる、コミュニケーションがどれだけ発生するか？というコミュニケーションパスとともに、チーム間を跨ぐ場合に誰を経由してコミュニケーションするか？という経路としてのパスもあります。

個人的に、直接のコミュニケーションにおけるやりとりも「パス」(pass)することだと考えていて、相手にいいパスを出せるか？というのもチームコミュニケーションにとって大切な要素ではないでしょうか。

本トークでは、コミュニケーションにおける対話（パス交換）に着目して、私が大切にしていることを共有したいと考えています。

ちょうど2年前に執行役員から急にSREチーム立ち上げやってみない？と誘われ試行錯誤しながらSREチームをやってきました。

開発組織15人規模の中から新しくSREチームの立ち上げにおいて困難だったこと、工夫したこと、組織としてできるようになってきたことなどを振り返りながら紹介します。

みなさんPHPをビルドしていますか？

つまりはaptやhomebrewやコンテナでPHPをビルドせず、バイナリインストールばかりしていませんか？

昨今、PHPのソースコードについて様々な話題がふえてきているものの、「あれ？ビルドする人がすくなくない？？？」と思っており、PHPをソースからコンパイルして使う方法が失伝している気がします

なので、今回PHPをビルドし、それをつかうという「ちょっと前だったら当たり前だった行為」についてトークしてみたいと思います

ちょっとトリッキーな技も説明できるかも？

このトークは初心者、中級者向けです。

概要

ジェネレータは、特に大量のデータを効率的に処理する際に有効な手法です。
例えば、LaravelのCollectionは便利な機能ですが、多用するあまり気づかずに大量のデータを扱ってしまい、意図せずパフォーマンスに影響を与えることがあります。
本セッションでは、PHPとLaravelにおいてジェネレータを活用し大量データ処理のパフォーマンスを改善する方法について説明します。

トーク内容

1. PHPのジェネレータの概要と基本的な使い方について
2. Laravelにおけるジェネレータを使ったLazyCollectionの使い方について

想定聴講者

普段PHPで開発しており、運用上のデータ量増加問題についてまだ考えてない方、あるいは現在悩んでいる方

ある程度事業が成長している会社であれば、技術的負債と向き合う必要があります。
私も沢山の会社で今まで向き合ってきました。

そこで小さくリファクタリングしようとして失敗したり、フルリニューアルに挑戦して失敗したり、多くの失敗の末、今では成功するアプローチとバランス感覚が身についてきました。

本日は実際に私が経験した失敗談と成功談を交えながら、技術的負債と付き合っていく正しい歩き方についてご紹介します。

※登壇資料はこちらです。
https://speakerdeck.com/soudai/learn-from-predecessors

「推測するな、計測せよ」という言葉は、改善策を探す時だけでなく、新機能をリリースする時も同様で、「計測」することは重要です。
開発環境の少量のデータを扱う場合は問題なく動作するクエリも、本番環境の大量のデータではパフォーマンス低下し、スロークエリになる可能性があります。
このトークでは、本番環境での実行計画の実行時間が約600msかかるクエリを、約0.2msに改善した事例を題材に、計測と具体的な手法について紹介します。

話すこと

• 理論：EXPLAINコマンドを使った実行計画の読み方
• 実践：本番レコード調査、具体的な対応として実行計画の解読、クエリ再設計、INDEXの再検討

注意：このトークではPostgreSQLを使用しています。

フレームワークのドキュメントに従って、あるいはプロジェクトの既存のコードに従ってファイル上部に書いた「namespace」「use」といったキーワード。

この意味、正しく理解していますか？
「ディレクトリ名と対応させて書くやつ」「他の言語でいう import みたいなやつでしょ？」みたいな認識をしていませんか？

実は PHP の機能としては namespace（名前空間）とディレクトリ名、ファイル名には一切の関係はありません！

「じゃあ、なんで require とかを書かずに他のファイルに定義したクラスを使えているの？」と思ったあなたに、その仕組みと、それらを支えている存在をお教えします。

※本トークは「第 146 回 PHP 勉強会@東京」にて発表した LT の増補改訂版です。

コロナ禍をきっかけとして、テレワークを導入した企業は珍しくないでしょう。
テレワークは働きかたに様々な利点をもたらしてくれた一方で、新たな問題をもたらした側面もあります。

私たちのエンジニア組織は従業員どうしの関係性や勉強会等の活発さといった文化を強みのひとつとしていました。
そして、テレワーク導入直後にはその強みがほとんど見えなくなっていたのです。
もともと組織文化醸成の役割を担っていた「開発組織活性チーム」は、この問題に対して活動内容をテレワークに適応させるための試行錯誤に舵を切ります。

本トークではそこからおよそ 2 年にわたる「開発組織活性チーム」の取り組み内容と、それによって実現できたこと、できなかったことおよびそれらの考察をお話します。

アジャイル開発、していますか？チームは成果を出せていますか？
弊社ではクライアントワーク型の案件でスクラムを採用していますが、全てのプラクティスを厳密に採用しているわけではありません。

このトークでは成果を定義し、結果を計測し、改善をするためにやったことと、それによって起きた変化を紹介します。

※プロポーザル時点では改善活動を始めたばかりですが、カンファレンス時点では３ヶ月程度で実際にどの程度の変化が起きたのかを紹介できる予定です。

Google Apps Script（以下、GAS）とはGoogleが提供するローコードプラットフォームです。
単なるJavaScript実行環境にとどまらずGoogleの提供する各種サービス（スプレッドシートやフォーム等）との連携を容易に行えたり、動的なWebページを表示できたりと、まさに「ローコードプラットフォーム」と呼ぶにふさわしい機能を備えています。

何が正解かわからないビジネスの世界において、誤った方向性でプロダクトを作り込んでしまうことを避けたいもの。
そのためにコストをかけずにプロトタイプを作って仮説検証のサイクルを回す必要がありますが、GASの備える特性はその際の強力な助けとなります。

本トークでは、その際に知っておくと役に立つ

• GASでできること
• GASを使うときのコツ、Tips
• GASの限界、使うべきでないところ

についてお話します。

「テストを書くことは重要だと分かっているが、具体的にどこから始めれば良いか？」という疑問に答えるために、実際のコード修正や機能追加のような日々の開発タスクに隠れている、テストを書くきっかけを探ります。

具体的なバグ発生事例を活用し、それを防ぐためのテスト作成方法を紹介します。さまざまな状況をテストの観点から見直し、テストを書くきっかけ作りを目指します。

対象者

• テストを書き始めたいが、具体的なきっかけがないエンジニア
• 従来の開発タスクにテストの視点を取り入れたい人

異業種からの転職、一時期流行りましたね。
私もブームからは少し遅れたものの、異業種からITに転職してきました。

「ある動画」を見たことをきっかけに参加しはじめたPHPのコミュニティからは沢山のものを得られています。
このトークでは１人の異業種エンジニアがコミュニティ活動を通してどんなものを得てきたかを実体験を元にお話したいと思います。

1つの変数がいくつもの関数を経由し、それぞれでpreg_replaceが乱用されるようなレガシーコードに立ち向かっています。

機能追加するにあたり、既存機能がどのように動作するか理解することは非常に重要です。

このトークでは、そんな混沌としたレガシーコードの動作を理解するために実際に行なった方法について解説します。

話すこと

• テストデータの集め方
• 既存機能の動作を理解するための方法

子育てをしながら新しい技術を学ぶことをとても大変なことです。
学ぶことに正解はないけど、模索しながら少しづつ自分の中でカタチができてきたのでそのことについてお話しします。

子育て中じゃなくても、みなさんの学び方に対するヒントになる何かをお伝えできればと思います。

Emacsは40年以上の歴史がある老舗のテキストエディタであるにも関わらず、非常に開発が活発で日々進化しています。
Emacs最大の魅力はカスタマイズ性であり、他のエディタの追随を許さないくらい優れています。

私はEmacsの設定を1万行程度しておりPHPに関してもヘビーカスタマイズしています。
今回のLTではオススメプラグインを紹介しつつ、Emacsでの開発体験が如何に素晴しいものか伝えます。

MySQL や PostgreSQL は非常に安定した信頼できるプロダクトです。これまでの数々の実績を見てもそれは確実でしょう。

しかし、 IT 業界の規模が急速に拡大し、クラウドサービスが席巻している今、「1インスタンス1DB」を前提として設計されたそれらプロダクトには性能限界が来ています。つまり スケーラビリティの問題 です。
その問題を解決しようとしているのが Google Spanner や PingCAP TiDB などの NewSQL と呼ばれる新時代のリレーショナルデータベースです。
今回はその中でも TiDB に焦点を当てて、 MySQL や Spanner と比べたメリット/デメリットを実際に使って検証します。

対象者

• MySQL でスケーリング大変だ、と思っている方
• NewSQL(TiDB) の実力がまだわからない方

「なんで PHP をメインで書いているのに、 JavaScript(TypeScript) も一緒に書かないといけないんですか！ React ってなんですか！今は Svelte が良いって聞いたけどじゃあどれ使えばいいんですか！」

という問題を解決するかもしれないのが Laravel Livewire です。これを使えば、 PHP でフロントエンドのロジックを記述することが可能です。

今回は、 LaraconUS 2023 で発表された Livewire v3 と関連パッケージを使って、(ほとんど) PHP だけでフロントエンドロジックも実装してしまう技術を紹介します。

対象者

• JavaScript(TypeScript) しんどい方
• 「全部 PHP がいい！」という方

概要

データベースから結果セットを取得するデザインパターンとして、
Active Record パターンと Repository パターン（によって抽象化された Data Mappter パターン）がよく知られています。
これらのパターンは一体どういうもので、どのようなトレードオフによって選定されうるのかを解説します。

対象者

• ソフトウェアの設計に興味があるひと
• Active Record, Repository パターンを聞いたことがない、または聞いたことがあるだけなひと

もうちょっと詳しく

実質的には、PofEAA に記述されているパターンを PHP で再翻訳することになります。
PofEAA はあるパターンの説明に、別のパターンを使用することが多々あるため、その「らへん」についても紹介します。

エンジニアとしての道を歩む中で、ときおり「私はつよつよエンジニアと言えるのだろうか？」という疑念が私たちを襲います。
初心者の段階を脱し、中堅エンジニアとしても充分な経験を積むと、周囲からの期待も高まり、自身がそれに応えられるのかという不安が生まれることもあります。
自分に自信をもてないまま周囲から「あの人は強い」と言われるのは、少し毛恥ずかしいことですよね。
心の中では「PHPなんて生ぬるい言語を使っていてもつよつよエンジニアと言えるのか？」と不安がよぎることもあるでしょう。

このセッションでは、エンジニアとしてのキャリアのなかで、どのような経験や学びが自身の成長に繋がり、どうすれば自身の強さを発見できるのかを考察します
エンジニアとしての道を歩む皆さんが、自身の強みを最大限に引き出し、自己評価に自信を持ち、いつか「つよつよエンジニア」と自称できるようになる手助けをします。

概要

私たちが働く IT の業界は変化が激しく、既存のスキルが数年ですぐに陳腐化してしまいます。
変化のなかで生産性の高いエンジニアであり続けるためには新たな事柄を戦略的に学んでいくことが重要です。
本セッションでは戦略的な学習習慣を身につけること「学び方の学び方」についてブレイクダウンして考察していきます。

トーク内容

• 学ぶ人と教わる人
  • 未開の地を開拓するには自ら学ぶしかない
  • 自ら学ぶ人は常に教わるだけの人の先を行く
• 何を学ぶべきか？
  • あなたの欲は模倣である
  • 真に欲しているもののために学ぼう
• どのように学ぶか
  • 学習最適化組織を作る
  • ギバーとテイカーの組織的学習論

想定視聴者

• エンジニアとして成長し続けるヒントを見つけたい人
• メンバーが自ら学ぶ組織を作りたい人