トーク

2018年から約5年、計15人の1on1をする中でよく話すことをまとめた教育における考え方や理論をまとめた私の秘蔵のボードを大公開します！
しかも、どんなときに使うかの実践例付きで紹介します！

サーバーレスPHP、凄いんです。

BrefというOSSのお陰で、驚くほど簡単に環境が作れて、デプロイまで出来てしまう。

今回は更にDBaaSであるSupabaseも添えた、コストメリットが高いサーバーレスPHPのサクッと作り、サーバーレスPHPの魅力を語ります。

実行環境の１つとして、是非サーバーレスPHPを選択肢に加えてください。

• 想定する聴講者
  • サーバーレスがなにか知らない方
  • Supabaseがなにか知らない方
  • PHPでサーバーレスは無理だと思っている方
  • とにかく安くPHPを動かしたい方

LaravelとChatGPTのAPIを駆使してキャリア診断アプリを作る話をします。

具体的にはチャット形式でいくつか性格や行動、趣味などを診断するような問いに答えていくと、
あなたに適したキャリアや職業が表示されます。数値化されたデータはグラフなどでも表示予定です。

話者は2022年、HTTP3について調べた結果「スゲー！」ってなりました。

この体験を皆さまにスピーディーに体験していただくために、
HTTP3のいいところを仕組みにちょっと触れながらライトニングに話します。

細かいことは良いんです、HTTP3スゲー！ってなって欲しいんです。

その結果、HTTP3やってみるか〜！というモチベーションに繋がる事を望んでいます。

• 想定する聴講者
  • HTTPの仕様を知らない方
  • HTTPの仕様は知ってるけどHTTP3は知らない方
  • HTTP3スゲー！となりたい方

アプリケーションのパフォーマンス改善を行う場合、適当に手を動かしてもうまくいかないことが多いと思います。

少しでもよいカイゼンを行うためには「事実」を把握するために「計測」するというアクションが大事です。

ツールを使ってコードのメトリクスの取得するのも1例です。
コードのサイズ、重複コードの有無、コーディング規約の遵守状況、循環的複雑度、エラーの有無などコードに対する「事実」を把握することができます。

把握できた色々な「事実」を元に、どこがアプリケーションの改善点なのか…？何がアプリケーションにとって最適なのか…？？プロダクトにもっとも寄与するためには…？？？を考え「判断」し、「行動」に繋げていきたい。

このトークではどのように考えてカイゼンのための行動をとっているのか？をお伝えしたいと思っています。

「わたしたちのコード（＝ドメインロジック）」は安定していますか？？

フレームワークを利用している場合にコードの境界がハッキリしていないと、強くフレームワークに依存することにもなりかねません。

フレームワークには便利な機能がたくさんあります。
たとえばLaravelには、Eloquent、Facede、サービスコンテナ、認証、ミドルウェア、Blade、artisanコマンドなどがあり、それらの機能を活用することで、スピード感のある開発ができるでしょう。

しかし依存のしすぎはビジネスの変化への対応による作り直しや機能のバージョンアップの際に思わぬ量のコード修正になってしまうことがあります。

わたしのチームでは主にInterfaceを利用して「わたしたちのコード（＝ドメインロジック）」をフレームワークから独立させ、安定させることを心がけており、その方法をご紹介できればと思っています。

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

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

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

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

コードの問題点は見た目には分かりにくいことがあります。

知らず知らずのうちに悪いコードが増え、気付いた時には『レガシーコード』と呼ばれるような状態になっているかもしれません。

そこで、問題点に気付くための1つの方法として、コードを計測する方法があると考えています。コードの計測によって得られる情報は多岐にわたり、コードのサイズ、重複コードの有無、コーディング規約の遵守状況、循環的複雑度、エラーの有無などが含まれます。これらの情報を分析することで、コードの状態を知ることができます。

ただし、計測した数値は必ずしもそれ単体で問題点を示す訳ではありません。そのため、他の数値と組み合わせたり、実際にコードと対比して判断・行動することが重要です。

本トークでは、特にコードをツールで計測することによって得られる結果に着目し、コードの改善にどのようにアプローチするかをお話しします。

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

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

どうですか？社内イベント、開催してますか？

エンジニアとして生まれたからには様々な社内イベント開催のチャンスがあるかと思います。
LT会や勉強会、輪読会や懇親会……

でもどうやって開催したらいいんでしょう？何を、いつまでに、どのように進めたら？当日はどうする？

本セッションでは、私が社内イベントの運営や司会進行を数年務めてきた中で、
得たノウハウや個人的に大事にしている価値観についてお伝えできればと思います。
皆で楽しく円滑な社内イベントを作り上げていきましょう！

ぜひ聞いてほしい方

社内イベントを開催してみたいけどどうしたらいいかな……と悩んでいる方
社内イベントを開催しているけどなかなか上手に進められない方
※トーク内容の大半は社内/社外を問わないものとなりますが、
社外イベント特有の観点について扱わないため今回は「社内イベント」に限定します

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

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

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

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

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

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

リーダブルコードでは、このような定理が紹介されています。
「コードは他の人が最短時間で理解できるように書かなければいけない。」(Dustin Boswell リーダブルコード P.3 より引用)

皆さん、めちゃめちゃに長いSQLや、サブクエリのネストが深すぎて眩暈がするような難解なSQLを読んだことがありますね？ 書いたことがありますね？ 僕は、あります。

そこで、本トークではどうしたらリーダブルなSQLが書けるかというアイデアを紹介します。

概要

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

トーク内容

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

想定聴講者

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

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

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

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

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

このトークではシステム開発用スマートウォッチ的なものの話をしたいと思います。

健康を求め、私たちはジムに通うなどします。そして、体重、心拍数や消費カロリー等を測って成果あるいは体調を確かめます。そう、私たちは自身ことを思いの外わかっていないのです。だから私たちは測ります、私たち自身を。そして、メニュー、頻度、強度を変えるなど、習慣を見直すことでなりたい自分を目指します。

システム開発も似ています。「事業を成長させたい！ガシガシ開発を進めたい！」私たちは願い、勉強したり、開発プラクティスや技術を導入するなど工夫します。でも実際のところうまくやれているのか、私たちにはわかりにくいものです。だから私たちは測ります、私たちの活動やシステムを。

このトークでは、Four Keys等を用いてどのように可視化を進めたか、何が分かり、習慣をどう見直し、開発における体験がどう変化したかを共有します。

「推測するな、計測せよ」という言葉は、改善策を探す時だけでなく、新機能をリリースする時も同様で、「計測」することは重要です。
開発環境の少量のデータを扱う場合は問題なく動作するクエリも、本番環境の大量のデータではパフォーマンス低下し、スロークエリになる可能性があります。
このトークでは、本番環境での実行計画の実行時間が約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の限界、使うべきでないところ

についてお話します。