【概要】
ドキュメントを作ってチームに情報共有したぞ!これで属人化解消!と思ったら未だに自分宛に問い合わせが来る???こんなはずじゃなかったのに...皆さん、このような経験はありませんか?
せっかくドキュメントを用意しても、チームに読んでもらえない・理解してもらえないのでは作った意味がありません。
本トークでは、日常的な個人メモの取り方やそれをドキュメントに成長させる方法、さらにドキュメントを通じて業務の属人化を解消する方法をお伝えします!
【対象者】
・業務の属人化を解消したい人
・個人メモ・ドキュメントの作成が苦手な人
【目的】
・個人メモ・ドキュメント作成のポイントが分かる
・ドキュメントを通じた属人化解消
【話すこと】
・まずは個人メモから!記録のコツ
・個人メモとドキュメントはどこが違うの?
・ドキュメントを成長させるために必要なこと
・属人化解消のメリット
連想配列に全てを詰め込んで旅をさせるのは良くないとは分かりつつ、
今まで巨大な連想配列をゴリゴリ実装していたチームが、配列からの脱却への一歩に挑戦しました。
完全な配列脱却は難しかったものの、バランスをとったリアルな挑戦ができたのでお話しします。
話すこと
本セッションでは、ADHDを持ちながら10年以上働いてきた視点から、どのように職場で適応するかについてお話しします。
テーマ
ソフトウェアテストの現場では、限られた時間とリソースの中で最大限の品質を確保することが求められます。
特に、複数のパラメータが絡み合う複雑なシステムでは、全ての組み合わせを網羅するテストは現実的ではありません。
そこで登場するのが、PICT(Pairwise Independent Combinatorial Testing tool)です。
PICTは、組み合わせテストを効率的に行うための強力なツールです。
このセッションでは、PICTの基本機能から高度なテクニックまでを網羅し、実際のプロジェクトでの適用例を交えながら、その魅力と実用性を徹底解説します。
PICTを導入することで、テストケースの数を劇的に削減しながらも、品質を確保する方法を学びましょう。
2015年にランダムデータの作り方というタイトルでテストデータをどのようにして準備するか?というセッションをPHPカンファレンスなどでやりました。
それから9年が経過し、DBを利用する自動テストでのテストデータは破壊的でなく作られていると思っていました。
が、しかし、今だに現場ではシードデータからテストデータを投入していたり、愚直にテスト前工程でテスト自体では関心のない項目に対してもデータを記述していたりする場面が多いと聞きました(オフライン勉強会/カンファレンスが多くなった今年のリサーチ結果)。
これはやはり再び私がこのセッションをやるべきであろうと、破壊的でないテストデータの作り方を啓蒙したいという思いを強めました。
セッションではテストデータジェネレータ Fabricate の最新開発状況も含めご紹介します。
Language Server Protocol (LSP)は、2016年にMicrosoftが発表したJSON-RPCベースのプロトコルです。
LSPはモダンなテキストエディタなら必ずある機能(e.g. 定義ジャンプ)を提供していますが、一番の魅力は特定のテキストエディタに依存しない形での実装になっていることです。
これにより各テキストエディタでの実装の必要がなくなり、エディタ選択の自由度が飛躍的に高まりました。
PHPの言語サーバ実装はintelephenceとPhpactorがメジャーです。
本登壇ではPhpactorの実装に触れつつ活用テクニックを紹介していきます。
ジェネリクス活用していますか?PHPでは言語仕様としてジェネリクスは実装されていません(2024年9月現在)が、近年では主に静的解析やIDEによる補完のためにphpdocに記述して利用されています。
そんな中でもずっと食わず嫌いでジェネリクスを使わずにいた私が、フロントエンド実装のためにTypeScriptを体験して「ジェネリクスを完全に理解」してから、PHPでも便利に活用できるようになりました。
このトークでは一年前の私と同様に食わず嫌いしているPHPerの皆さんのために、
など、いまさら聞けないジェネリクスのあれこれをこっそりお話しします。
食わず嫌い勢のPHPerのみなさんに、週明けから「ジェネリクスなんて前から知ってるけどなにか?」という顔で活用してもらえることを目指しています!
なかなか修正が捗らないレガシーなコードがどのサービスには多かれ少なかれ存在すると思います。
そうしたサービスに対して真正面からテストの導入をするにできるかというと実際の現場においては難しい面があると私は感じています。
TDDやテストファーストは、これからのサービスを長く使い続けられる環境を整えるためには素晴らしい設計思想です。
そうした思想を取り入れるにあたり、現状のコードを改善するにあたり、少なくとも1歩でも前に進めるためにできることについて話をいたします。
・日本語のコメントは優秀(しかし時に牙をむいてくる)
・図を描く(UMLであれ、ユーザーストーリーであれ)
・コードに意味のまとまりを持たせる
・ユビキタス言語で語ろう
本セッションでは、CSVファイルのダウンロード速度が遅すぎて切り戻しになった知見をもとに、Laravelアプリケーションのパフォーマンス改善のデモンストレーションを行います。
「頑張って作ったのに遅すぎて使ってもらえない」では悲しすぎるので、ご参考にしていただけますと幸いです。
以下のテーマに沿ってデモをしていく予定です。
・ しくじり談
・ DBからのデータ取得時に気をつけること
・ 取得したデータを加工するときに気をつけること
・ 加工したデータを出力するときに気をつけること
キーワード
・ Eloquentとクエリビルダ
・ N+1問題
・ メモリ
・ ジェネレータ
想定視聴者
パフォーマンスを意識したコードを書ける・レビューができるようになりたい方
PHPUnitはPHPテストフレームワークのデファクトスタンダードとして長年使われており、普段PHPを書いてる方であれば目にしたことがあるツールの1つです。
プロジェクト規模が大きくなればなるほどテスト数が増加し、PHPUnitの実行時間が増え、CI待ちがボトルネックになるといったことが多々あります。
今回はPHPUnitをあの手この手で低速化する方法をお伝えすることによって、逆説的にPHPUnitの実行速度劣化を防ぐ考え方が身につきます。
Form・Html ファサードは laravelcollective/html パッケージに含まれています。
このパッケージは放棄されており、spatie/laravel-html への移行が推奨されています。
私の関わるサービスでの使用箇所は約1,700箇所…!
移行ツール「Shift」で移行しましたが一筋縄ではいかず…
今回は laravelcollective/html の Shift による移行で、苦労して得た知見をご紹介します。
■ 内容
■ 対象
近頃ではCI上でPHPUnit等を用いたテストが自動的に実行される環境も多くなっているかと思います。
同時に、PHPやLaravelなどフレームワークの開発も盛んに行われており、従来のLTS版で3〜5年使うというサイクルから最新バージョンへの迅速な追従が求められるようになってきました。
CI環境でPHPの最新バージョンリリースを自動検知し、自プロジェクト用のDockerイメージのビルドからテスト実行までを自動化していきます。
バージョンアップに向けた準備を自動で進める事でバージョンアップのハードルを下げましょう。
仕事は油断すると、いつまでもそこに残り続け、意義が忘れ去られ、誰がボールを持っているのか、何をもって完了とするのかが時々わからなくなります。
あなたのチームのタスクボードに、何日も動いてないチケットはありませんか?
そのチケットはヌルッと翌週に持ち越され、それに誰も疑問を抱かない状態が続いていませんか?
スプリントの期間内に終わらないと、もっと早く気づけた可能性はありませんか?
仕事は終わらせる意思を持たないと終わりません。
本トークでは、私がソフトウェア開発に携わる中で得た、仕事を終わらせるために必要な考え方や、対策についてお話します。
話すこと
話さないこと
テストコードを書くのって、最初はハードルが高いですよね?
私も最初はまったく書けずに悩みました。しかし、今では少しずつ書けるようになり、テストのタスクを自ら進んで取りに行くまでになりました。
この発表では、PHPUnitを初めて触れた時の挫折から、業務を通じて学んだこと、そしてどのように成長していったかをジュニアエンジニアの視点でお話しします。また、テストを書くことが私の開発プロセスにどのような変化をもたらしたのかについても共有します。
話すこと:
対象者:
静的解析ツールは「ここが良くないから、こういうふうに直すといいよ」と教えてくれる便利ツールです。
開発環境やCIで導入している方も多いのではないでしょうか?
私が開発するプロダクトにも導入されていましたが、PHPのバージョンアップに取り組んで初めて「静的解析を導入するとってこんなに嬉しいのか!」と感動しました。
このトークでは、初心者〜中級者向けに、安心安全なバージョンアップという観点に絞って、静的解析のスゴいところや使いどころを紹介します!
これからバージョンアップをする人はもちろん、コードの品質を高めたい方にとっても役立つ内容です!
私たち開発者にとってログは非常に重要です。
開発時のデバッグやローンチ後の障害解析など、ログを出力していることで救われたシーンは多かれ少なかれあるのではないでしょうか?
そんな私たちを助けてくれるログですが、Laravelでは様々な設定やカスタマイズが可能です。
しかしどのような設定ができるのか理解するところまで手が回らず、デフォルトのまま運用してそのままという悲しいシーンを見ることも多々あります。
このトークでは実際にログ出力する際にLaravelのLogManagerがどのような処理を行なってログを出力するのか、各設定の詳細、Laravel10より追加されているLaravelPailを用いたログの限定出力のやり方等をお話ししますので、今後のログ運用の助けになれば幸いです!
Laravel eloquentを使ったRDS上での検索クエリは、テーブル間のJOINやクエリの複雑さが検索パフォーマンスに悪影響を与えていました。特に、利用頻度の高いクエリがレイテンシー低下の主因となり、その改善を目指してOpenSearchを導入しました。
結果、検索速度が飛躍的に向上し、レイテンシーも大幅に改善されました。また、OpenSearchのPHP DSLライブラリを導入することで、クエリの構築をシンプルにし、保守性を高める工夫も行いました。
Laravel eloquentとの共存を図りながら、検索機能のパフォーマンス最適化を実現しました。これらの経験を基に、検索機能改善の実例を紹介します。
このトークは、パフォーマンスに課題を抱える開発者や、検索機能の改善に興味のある方に向けた内容です。
画面開発で、こんなお悩みを抱えていませんか?
これらの課題が原因で開発効率が低下しモチベーションも低下してしまいました。その解決策の一手として、デザインシステムの導入を進めました。
今回は、すでに存在していたデザインリニューアルのデザイン案をベースに、プロダクトにデザインシステムをうまく反映できていなかった状況から、仕組みを整備して導入を進めるまでの一連の取り組みをお話します。
最近では、DevOpsの中にSecurityを意識した活動を含める、DevSecOpsの様な考え方が広まっており、この様な流れの中でSAST(Static Application Security Testing)やDAST(Dynamic Application Security Testing)の様な検査をCI/CDに組み込む事例を見かける様になってきました。
このセッションでは、SASTツールの一つである、SonarQubeの基本的な機能や特徴、実際にCIに組み込んでの活用方法、実行環境の構築例などについてお話しします。
話すこと
SQLにおいて、最も重要なのは「正確さ」、次に優先すべきは「速度」です。
これらの要件を満たすため、どれだけ努力しても、時には可読性が犠牲になることがあります。
本セッションでは、正確さと速度を最優先した結果、可読性が低くなってしまったものの、非常に高い精度と高速性を持つSQLを実例を交えて紹介します。
一見して何をしているのか分かりにくいかもしれませんが、その背後には緻密な工夫が詰まったSQLの世界をご覧ください。