トーク

ランサーズは10年以上利用されているクラウドソーシングサービスになります。
PHP7.3 + CakePHP2.10 までバージョンアップが完了し、引き続き、CakePHP2→CakePHP4へのジャンプアップを実践中です。
本LTではその内容についてお話いたします。

Discord Channel: #track1-slt5-lancers

AWS Fargateを利用した大規模サービス開発におけるインフラ設計のポイントや工夫していること、デプロイフローなどについてお話しします。

[想定する聴衆]現在Fargateを利用されている方、オンプレミスやEC2からコンテナサービスへの移行を考えている方

Discord Channel: track1-slt2-dip

株式会社M&AクラウドではPHP、LaravelとAWSを使ってM&Aのマッチングプラットフォーム「M&Aクラウド」を開発しています。サービスリリースから徐々にアプリケーションとして成長していく過程でどの様な技術を組み合わせて課題を解決してきたかを、短い時間ですがご紹介させていただきます。

Discord Channel: #track1-slt4-macloud

ローンチ当初は少人数で依存や実装に関するルールを整備せず、都度コミュニケーションを取りながらスピード重視の開発をしてきました。結果サービスは急成長し、開発人数も増えてきたため、アーキテクチャの導入を進めることとなりました。
アーキテクチャ導入前にはどういった問題があり、導入後はどのように変わってきたのかをお話します！
技術レベルは初心者〜となっております。同じような状況に置かれている皆様のご参考となれば幸いです。

Discord Channel: #track1-slt3-カカクコム

5Gは色々なトピックで話題になっています。皆様も5Gに繋がっていますでしょうか。
5Gは無線、コアネットワーク共に4Gから大きな技術的進歩を遂げています。
モバイルネットワークの技術はWi-Fiにもその技術が応用されるようになりました。
本セッションでは、5Gの無線、コアネットワークの進歩とそれによって私達がどう幸せになるのかをお話します。
トラーナのビジョンである幸せな親子時間を増やすことに絡めてお伝えできればと思います。

Discord Channel: #track1-slt1-トラーナ

このセッションでは求人数1位になったPHPの状況と、いよいよ本番試験開始となった徳丸実務試験とPHP8上級試験の模擬問題解説を行います。WordPressの原理原則を問うKUSANAGI for WordPress認定試験の紹介も行います。

Discord Channel: #track1-6-b-php技術者認定機構

こちらでは初心者向けのPHPプログラマを対象にPHPのコーディング規約(PSR)と自動整形についてお話したいと思います。

自動整形ツール
php-cs-fixerとphp_codesnifferの挙動を一緒に見ていきたいと思います。

■アジェンダ
・そもそもコーディング規約はなぜ必要なのか
・PHPにおけるコーディング規約
・自動整形
・php-cs-fixerとphp_codesnifferの違いについて

少しでも皆さんの手助けになればと思います。

※サンプルはLaravelを使用したものになります

Discord Channel: #track1-sp-gmo

OpenAPIにはリクエストやレスポンスだけでなく、求める型や正規表現も記述して利用することができます。コードの自動生成についても盛んに行われていることもあり、最近のプロジェクトでは採用されることが多いのではないでしょうか？
とはいえ、OpenAPIを自分たちで書かなければいけない場合はめんどくさいと思います。
そこで、このセッションではLaravelからOpenAPI仕様書を自動生成する方法を紹介します。
また、生成したOpenAPI仕様書を閲覧用として利用するだけではなく、LaravelのE2Eテストやバリデーションに生かす方法についても話します。

このセッションで話す内容

• LaravelでOpenAPIを半自動生成する
• LaravelのE2EテストのアサーションをOpenAPIに沿った形で行う
• LaravelのFormRequestにOpenAPIを使う
• (予定)今回の内容を業務で利用してみた感想

想定するレベル感・技術的な要素

• OpenAPIやSwaggerを知っている
• Laravelを使ったことがある

Discord Channel: #track1-7-a-yumemi

シングルページアプリケーション(SPA)において、セッションIDやトークンの格納場所はCookieあるいはlocalStorageのいずれが良いのかなど、セキュリティ上の課題がネット上で議論されていますが、残念ながら間違った前提に基づくものが多いようです。このトークでは、SPAのセキュリティを構成する基礎技術を説明した後、著名なフレームワークな状況とエンジニアの技術理解の現状を踏まえ、SPAセキュリティの現実的な方法について説明します。

Discord Channel: #track1-8-spa-security

2019年にGaroon（ガルーン）のレガシーさに立ち向かい改善が行えるようになってきたとお話ししてから2年が経ちました。
https://speakerdeck.com/oogfranz/gai-shan-shi-bai-sitexue-bu-regasipurodakutonili-tixiang-kautimuzuo-ri
このセッションではこの2年間で実施してきた改善内容と、持続的に活動をしていくためにどのようにチームのプロセスを変えていったかについてお話しします。

この2年間、開発チームはバックエンドのController層を改良したり、フロントエンドをES5からTypeScriptに移行するなど、メンバー全員で色々な改善を実施してきました。
もちろん改善活動だけでなく、新機能開発やそれ以前から行っていたPHPのアップグレードなどGaroonを継続して提供していくための活動もしています。
なので、Garoonに必要なタスクをしながらも、改善もできるようになりました。万歳！

...とはなかなかなりません。
開発されてから19年目を迎えたこの巨大な製品には、まだまだ多くの負債が着手されないままに残されています。
また、新機能を開発しながらも多くの負債に立ち向かう中で、どの負債から優先的に対応するのかや人的リソースをどう割り振るかなど、チームとして改善を試みることの難しさに直面しました。
プロダクトのレガシーさに立ち向かえる環境作りはできましたが、それだけではレガシーさに立ち向かうのは難しいのだという当然のことに改めて気付かされました。
そんな中で、より効率的かつ持続的にプロダクトを改善していくために必要だと気づいて取り組んだ課題が、チームのプロセスを見直すことです。
これをきっかけに、問題意識の言語化や各種活動の振り返りが進み、いまチームは「Garoonを開発者にとって魅力的なプロダクトにする」ことを新しい目的として、以前よりさらにワクワクしながら活動し始めています。

そんなサイボウズGaroon開発チームの経験を是非お聞きください。

Discord Channel: #track1-6-a-cybozu

ユーザからのお問い合わせに対して適切な回答を行うことは、様々なサービスを提供する上でとても重要です。弊社ではその中でも技術的なお問い合わせについて、Slack上で問い合わせ担当エンジニアへ調査を依頼する業務フローが存在します。現在、問い合わせ担当エンジニアは当番性であり、担当領域以外の問い合わせについても対応しています。この業務フローに関して、新しいお問い合せのうち、一部は過去に対応したお問い合わせと類似したものや一致するものが存在し、回答の参考になることがあります。
本セッションでは、新しいお問い合わせについて、過去のお問い合わせから類似するものをAmazon Elasticsearch Serviceを使用して自動で抽出し、同時にKibela Web APIを使用して関連するドキュメントを検索した上で、Slackのスレッドに投稿するシステムについて導入した話を紹介します。

Discord Channel: #track1-a-base

今年リリースされるPHPの最新バージョン8.1における機能強化・変更点を中心にPHPの開発に関する最新の情報，PHPコミュニティに関する話題について紹介します．PHPの最新動向に興味がある方向けに，初心者の方にもわかりやすい解説にしたいと思います．

Discord Channel: #track1-k-php2021

Hameeでは"ネクストエンジン"というプロダクトをPHPを使って開発・運用をしています。

ネクストエンジンは13年の開発・運用を重ねて成長してきた一方でたくさんの課題も抱えており、その課題を解決するため日々改善活動を行っています。今回は監視の観点から弊社アプリケーションエンジニアとSREエンジニアの二名が現場から生の声をお届けします。

• どんな問題があり監視を行っているのか
• どのような監視を行って改善しているのか
• アプリケーションエンジニアとSREエンジニアでどう連携を行っているか

対象

• まだ監視していない人
• 監視しているけど、うまく運用できていない人
• 13年物のプロダクト開発・運用に興味がある人

Twitter:
日野陽平 (https://twitter.com/money166)
大嶋淳司 (https://twitter.com/atsusics)

Discord Channel: #track1-1-b-hamee

エヴァンゲリオンとPHPに意外なつながりがあった！
そんな話をします。

https://speakerdeck.com/sapi_kawahara/php-with-high-synchronization-rate-with-evangelion
これのリニューアル版です。

phpstan/phpstan-strict-rules というパッケージがあります。
これは、PHPStanに「より厳しい」規約を追加しちゃうよ！！！というものです。

コーディング規約の理想は「良いコード(とチーム開発)」の実現であり、その中には「断言的であること」「記述がコンパクトであること」などなどが含まれていると思います。
これは「不吉な臭い」を避けるtips集としての効果もあります。

開発者が不吉な臭いを発するのを避けたい・・・そうした方向性の進化は、PHP自体も歩んでいるところです！

「良いコード」を標榜するチームのためのphpstan-strict-rulesと、「PHP7の後半や8で出来るようになったこと」を一緒に眺めてみましょう。
今っぽいPHPでの「当たり前」を見出したり、「PHPって便利になったね！」という喜びを分かち合いましょう。

PHP歴だけは長いぼくが Laravel よくわからないので避けようとしたものの
結局 Laravel を使うことにしました
その結果 Laravel の乗り方がようやくわかりました

アーキテクチャ(設計) というほど高尚なものではありませんが
フレームワークの利便性とアプリケーションコードの適切な分離を思いついたので話したいと思います

平たくいえば
「ぼくのかんがえたさいこうのLaravelのつかいかた」
です

多くの Web アプリケーションでは一度開発したらそのまま運用を続けていくことはなく、変更や追加開発を続けていくことになります。
変更は避けられないものでありますが、無秩序に変更を続けていくと複雑度が増し、変更するのがより困難になっています。
変更したら思いも寄らない箇所に影響があって冷や汗をかいた経験がある方も多いでしょう。

本セッションではこの変更容易性に着目して、設計や実装において変更容易性を高めるための手法を考えていきます。

PHPコーダーの皆さん!型、付けてますか?

PHPStanやPhan、psalmを利用することで、PHPでも実際に実行する前に型エラーを検出することができる事は既にご存知でしょう!(知らなくてもこのセッションを聞けばOKです)

静的解析のライブラリを活用することで、

• int|nullを返却する関数のnullハンドリングを忘れていたり
• '1' === 1といった数字文字列の取りあつかいの間違えを見つけたり
• 存在しない可能性のある配列の中身へのアクセスを事前に検知したり
  することができます

特に、PHP8からは、存在しない配列の中身へのアクセスがWarningからErrorへ変更されており、環境によってはPHP7からのアップデートでアプリケーションが動かなくなる原因の一つである一方、Union型のサポートなど、言語としての型サポートも整っていく傾向があり、アップデート作業の一環としても強力なツールとなります。

既存のPHPプロジェクトに静的解析ツールを導入する際に問題になるのが、

• エラーが多く出すぎる
• アプリケーション内で、文字列でクラス名を扱かっているのでクラスが静的解析で追えない
• 値域を厳密に制限する関数や返却する型が動的に変わる関数では、PHPdocのtypehintを利用した静的解析では、動的な型付けに対応できない
  場面が多くあります。

このセッションでは、PHPStanを用いた型解析について説明した後に、

• ~コミット差分によるエラー検出をし、変更箇所に起因するエラー箇所をciで警告するようにした方法(github actions/gitlab-cilですぐに使えます!)~
• PHPStanのオリジナル拡張を作って、PHPStanデフォルトの機能で手が届かなかった点を改善する方法(実際にセッション中に拡張を作ります!)
  について話します

Discord Channel: #track2-5-a-php-static-analysis-2021

初めて作られた時にはピカピカと輝いていたソフトウェアも、時が経つにつれて「劣化」していきます。
うまく使われれば機能は増えていきます。コード量も育っていきます。そこが問題です。
増殖していくコードたちを、誰が・いつ”良く”するのか。

実行するには、組織内にマインドとスキルの両方が必要です。
それらを育むには、どこから取り組んでいけば良いでしょうか？
本セッションは、「なぜソフトウェアが『劣化』するのか」「それを解消するためにどんな事を狙っていくか」と、そこから演繹して「自分自身の取り組んでみたこと」を紹介します。

まだまだ取り組みの最中なので、必ずしも「成果」をベースに語れるものではありませんが、何かしらのヒントになれば幸いです。
また、オーディエンスの皆さんからのフィードバックをもらったり、そこから更に踏み込んだ議論が生まれていくことを期待しています。

紹介するお話

例えば、以下のような取り組みが「自分なりに考えたこと」でした。

• 「技術力」を定義する
• プロダクトと技術力の関係
• 自分自身が「技術的な成長」を感じた瞬間を構造化して捉える
• その「良いフィードバックの獲得の仕方」を組織的に再現できないか？

こうした話を「議論のネタ」として提供したいと考えています。

この課題を選んだ背景

プロダクト開発や(Web)サービスの提供を行う会社において、
Webエンジニアに求められる主要な成果は「プロダクトを良くする」ことだと思います。
プロダクトをよく出来るエンジニアとは、どういう存在でしょうか？
実は、「プロダクトをよく出来るエンジニア」になるには「プロダクトを開発する以上の技量」が要求されるのではないでしょうか。

ここには大きな矛盾があると考えています。
「プロダクトを良くし続けるには、プロダクトに必要なレベルの技量では足りない」という矛盾です。
これについて、自分自身が、所属先の企業でのロールが変化したのをきっかけに取り組むようになりました。
組織の姿が「プロダクトを作れる」を超えた「プロダクトの未来を作れる」ようになるにはどうすればよいか・・？と現在進行系で考えています。

近年、PHP コミュニティでも DDD が大きく脚光を浴びるようになりました。その考え方に触れることで設計手法や実装パターンに興味を持つようになった人も多いでしょう。

DDD に限らず、多くの書籍では様々なパターンが紹介されています。
こうしたパターンは有用なのですが、特に設計パターンにおいては性質上、抽象的な内容となり、それ自体は理解できても自分が日頃おこなっているアプリケーション開発ではどのように適用すれば良いかがイメージできないことがあります。

本セッションでは、あるドメインを題材にして、モデリングから設計、そして最終的に PHP で実装するという一連の流れをご紹介することで、ドメインを中心に開発するイメージを持っていただければと考えています。

実際は、ドメインをモデリングして PHP コードに落とし込むという行為は誰もが日常的に行っているものです。
その手法や視点が異なるだけとも言えるので、こうしたやり方もあるのだなという気軽な気持ちでご参加ください。

Discord Channel: #track1-3-domain-modeling