EOL対応はエンジニアの永遠の課題ですよね。
弊社では5つのサービスがPHPで作られており、そのうち4サービスは10年以上の歴史を持つサービスです。
そんな中始まったPHP8へのバージョンアップ対応は一筋縄ではいきませんでしたが、以下のステップで取り組んだことで大きな問題なくバージョンアップを終わらせることができました。
このセッションでは、弊社の全5サービスで行ったPHP8へのバージョンアップ対応の取り組みやそこから得られたノウハウをご紹介し、これからPHP8へのバージョンアップを検討されている方に有益な情報をお届けできればと思います。
Laravel Octane(オクタン)は、SwooleやRoadRunnerなどの高性能なアプリケーションサーバを使用し、アプリケーションを提供することで、アプリケーションのパフォーマンスを向上させます。Octaneはアプリケーションを一度起動したら、メモリ内に保持し、そして超音速でリクエストを送り返します
(引用:https://readouble.com/laravel/8.x/ja/octane.html)
Laravel Octane(Swoole版)でPharをつかってワンバイナリアプリケーションにして運用してみた話です
過去、PHPカンファレンス北海道(2019)にて
「pharによるワンバイナリアプリケーションの可能性を探ってみた」
でお話ししましたが、そのリベンジ(現実版)になります
PHPだけど、Buildして(Pharでpackして)、Deployして運用してみよう!
PHPは言語仕様上、stringやintegerといったスカラー型にRubyやPythonのような他の言語のようにメソッドが生えておらず、手続き型のAPIを用いてそれらを操作する必要があります。
しかしながら、メソッドが生えている方が便利な場面もあり「そのように書けたらなあ...」と思う事もあると思います。
これらを達成するのにエクステンションを用いて言語仕様を拡張しスカラー型にメソッドを生やす事も出来ますが、今後の言語仕様の追加や変更に追従しなければならないなどの点を考慮して、純粋なPHPのクラスでスカラー型をラップしてそこに便利に扱う為の関数を生やしたライブラリを作った話をしたいと思います。
みなさん、あなたが保守しているコードベースで一番バグが混入しやすいファイルが何か知っていますか?
このトークでは、保守容易性指数(Maintainability Index)とGitHubのコミット数を用いて、
保守性が低くて、よく変更されているファイル(= バグが混入しやすいファイル)を見つけ出す方法についてご紹介します。
N + 1問題とは、ループ処理の中で都度SQLを実行してしまうことで必要以上にSQLが発行されてしまい処理が遅くなってしまう問題です。
N + 1問題が存在していても、ユーザーに影響のない程度の処理時間なら改修する必要はありません。
しかしながら、データ量が増えたりページへのアクセスが増えることで後から問題になってしまうこともあります。
今回は、そんなN + 1問題をサクッと検出して、問題が発生する前にN + 1問題を撲滅する方法をご紹介します。
Rectorを使うと、簡単にコードの書き換えを行うことが出来ます。
「FWのバージョンを上げたから新しい記法に対応しよう」とか「新規にヘルパーメソッドを定義したから、既存コードもこちらを使うようにしたいな」なんて場面で、コマンド1発で実現できるのです・・!
自身のプロジェクトの固有の書き換えルールを定義し、活用できたらとても便利だと思いませんか?
例えば「新しいコーディング規約を定義したから、それに沿ったコードに直すぞ」なんて作業を自働化できたら嬉しいですよね。
独自ルールの作成方法、利用方法をLTで紹介します!
みなさん Composer 使ってますか?使ってますよね〜〜〜??
Composer のようなパッケージマネージャのおかげで、パッケージの依存関係を明らかにしたりパッケージの依存関係や実行環境の依存関係にあわせてパッケージを適切なバージョンにアップデートすることもできます。
一方で、定期的にパッケージのバージョンアップを行うのは手間ではあります。その一手間を減らしてくれる dependabot や WhiteSource Renovate といった自動でパッケージのアップデートを Pull Request にしてくれるツールが登場します。
本トークでは、 Composer を利用しているプロジェクトにおいて、 WhiteSource Renovate を用いたアップデートに関する Pull Request の自動作成戦略についてお話しできればと思います。
自動テストにおけるテストフィクスチャは、ほぼ全てのソフトウェアにおいて必要になるテクニックです。その中でもデータベースと密接に連携する Web アプリケーションにおいては、データベースにデータを投入し、そのデータをフィクスチャとして利用するテクニックは初期の頃から利用されてきました。
PHPにおいては、 Fabricate という Ruby における factory_bot のような"柔軟な定義構文を用いてフィクスチャを管理する"ためのパッケージや、ここ最近になって CakePHP Fixture Factories という Fabricate に近しいコンセプトのパッケージが登場してきています。
本トークでは、最近登場した CakePHP Fixture Factories の解説を中心に、新たなテストフィクスチャ管理ツールのスタンダードについてお話できればと思います。
世は大 Laravel 時代を迎えています。業務でも Laravel を採用している会社はそれなりにいるのではないでしょうか。
しかし、「依存を増やす」ということは「障害点を増やす」ことと同義です。
「Laravel は安定しているからロックインされてもいい」とみなすことも出来ますが、業務では「最悪の場合」も想定して選択していく必要があります。
DDD の文脈では(私は DDD 初心者ですが)、ビジネスロジック(ドメインロジック)を重要視します。フレームワークはビジネスロジックをサポートしますが、直接依存しない方が安全です。
このトークでは、「いつでも Laravel を捨てることもできる疎結合な設計」を紹介します。
成長するためにアウトプットというのは非常に重要ですが僕のまわりでは
・プライベートで開発ほとんどしてないからネタがない
・公開できるようなネタがない
・とにかくネタがない
ということが非常に多いです。
僕も最近はプライベートで開発できてないので、めちゃくちゃ気持ち分かります。
でも我々は日々業務で技術に触れていますし、日々学んでいますよね?
だったらそれをアウトプットすればいいのです!
もちろん業務で得た知識をそのまま一般公開することはできませんし危険です。
外部に出してはいけない情報もあるでしょうし、場合によっては情報漏えいにも繋がります。
そういう知識をアウトプットするには「抽象化する」ことがとても重要です。
本セッションでは「知識の抽象化」の仕方を実際に僕が経験したことを例に説明します。
このセッションで少しでもアウトプットへのハードルが下がると嬉しいです!
今やソースコードをgitで管理しているのは当たり前の世の中になりました。
gitのcommitを俯瞰で見ることで
・誰がどれくらいcommitしているのか
・対象期間に1番commitしてるのは誰なのか
・このリポジトリに関して1番詳しいのは誰なのか
などを知ることができます。
このセッションでgitのcommitの集計方法を学びましょう!
Notionは、タスク・Wiki・データベースなどを統合するマークダウンサポートを備えた次世代ドキュメントアプリケーションです。
「戦国炎舞 -KIZNA-」、「この素晴らしい世界に祝福を!ファンタスティックデイズ」、「呪術廻戦 ファントムパレード」などのスマホゲームを開発・運営している株式会社サムザップでは、情報共有のツールとしてNotionを活用しています。
こちらのセッションでは「Notionを活用することにした経緯」、「別のツールからNotionに移行するまでのあれこれ」、「Notionをどのように活用しているのか」などについてお話しします。
また、「Notionをどのように活用しているのか」では、NotionのAPIをPHPで活用している部分についてもご紹介します。
誰かが言った。
「データベースの寿命は、アプリケーションよりも長い。」
多くの人が感覚として持っているのではないでしょうか。
この10年間で多くの技術が生まれ、そして変化し、開発の現場も進化してきました。
そんな中、データベースの世界では何十年もRDBMSが活躍しています。
それはなぜでしょうか。
この10年間のRDBMSの変化から開発に必要なことが見えてくるはずです。
そして、そこからこの先の10年を見据えたシステム開発の勘所を紐解きます。
様々な商用データベースに対して、MySQLやPostgreSQLのようなOSSデータベースは如何に追従しているのでしょうか。
そしてクラウドならではの新しい形のデータベースも次々に生まれています。
これらを題材に今、あなたが新しいサービスを作る時、10年戦えるデータベースの作り方を見つけていきましょう。
昨今のプロダクトの改善・開発を実施していくためには、データを可視化・分析することはこの時代必須といえます。
特に、アプリケーションエンジニアにも一定のリテラシーが求められている時代だと考えられます。
しかし、そのために必要なデータはRDB、ログなどの様々な形式、場所にあり横断的な分析をすることは容易ではありません。
そこで、私たちのアプリケーションの分析環境をBigQueryに構築したエピソードをもとに、以下の知見についてトークします。
カルテット開発部の2人によるLT2本立てでお送りします!
【プライベートな社内パッケージの再利用にsatisを使っている話 by志賀】
みなさんの会社ではプライベートな社内パッケージを再利用する際どうやっていますか?弊社ではSatisというcomposerリポジトリージェネレータを使っています。その事例についてお話しします。
【受託制作会社から自社サービスの会社へ転職して思ったこと by有澤】
自分は「受託制作会社」から「自社サービスの会社」へ転職した身です。
今後、そのパターンに沿って進みたいエンジニアに向けて、感想を共有します。
NoSQLのような可用性・柔軟性を持ちながらSQL・トランザクションをサポートすると言われているNewSQL(Cloud Spanner, CockroachDBなど)の導入事例が最近目につくようになってきました。
ですが、NewSQLと既存のNoSQLとの違い、また実際どのようなメリットがあるのか、よくわからない部分も多いと思います。
今回の発表ではNewSQLの1つであり、MySQL互換のTiDB(タイデービー)をローカル環境でセットアップして、PHPのアプリケーションからつないで使ってみるところまでを、発表したいと思います。
アプリケーションエンジニアの視点から調査した以下の内容をまとめて発表予定です
PHPは主にHTTPサーバアプリケーションの実装に用いられますが、案外長い時間がかかるバッチ処理なんかも書けたりします
数十分~数日かかる処理まで、長い時間がかかる処理をPHPで並列で回す方法や気を付けるべき点などを、仕事で主にインフラを担当している自分が実際に業務であった経験ををもとにお話します
BASEはCakePHP2という古いフレームワークを使っています。バージョンアップ計画は水面下で動いていましたが、コロナ特需によるサービスの急成長とそれに伴う開発組織の急拡大を背景に、バージョンアップだけでなくサービスの中長期的な成長を支えながら組織の問題も解決するような統合的な戦略が求められ、もはやバックエンドテクノロジーのリアーキテクチャリングと呼べるプロジェクトへと定義が更新されています。
事業会社における開発組織として中長期的にサービスとテクノロジーにどう向き合えばよいのかを考え続けた結果、我々はマイクロサービスではなくモジュラモノリスを中心に据えた戦略をたてました。この発表では我々の考える中長期的なアーキテクチャ戦略の概要と、PHPにおけるモジュラモノリスの実践について、1つの他社事例として皆様にお伝えしたく思います。
PHP8.0から追加された機能、Attributes。
これを使ったメタプログラミングの例として、クラスのプロパティにAttributesを付与することで
・データベース(PDO)から取得したデータをクラスのインスタンスに変換する
・JSON文字列をクラスのインスタンスに変換する(あるいはその逆)
といった処理が自動で出来上がるプログラムの解説をします。
昨年開催されたISUCON11にて問題(参考実装)のPHPへの移植を担当させていただきました。
最終的なソースコードこそシンプルなWebアプリケーションではありますが、その裏には
・「(私の思う)良い設計」を実現するための意思決定
・「ISUCONの問題」という位置付けに由来する取捨選択
・移植中に遭遇したトラブルとその解決策
といった文脈や葛藤が存在しています。
本発表はそれらを共有することで
・PHPアプリケーションの設計、実装事例として役立ててもらう
・ISUCONの言語移植に興味を持ってもらう
・ISUCON問題移植の「実装や設計の練習をする教材」としての可能性を知ってもらう
ことを目的とします。
なお、以下のテーマは扱いません。
・(移植に利用した)Slim Frameworkの使い方
・ISUCON11の問題解説
・パフォーマンスチューニングに関する知識、技術