ソフトウェアエンジニアには抽象化の能力が重要と言われます。
では実際に抽象化とはどのような能力なのでしょうか?
実際の事例を交えながら、抽象化を理解し、実務に活かせるようにします。
PHP Standards Recommendations 、通称 PSR と呼ばれる、 PHP エコシステムで共通のインターフェースを宣言し、それに準じて実装することで再利用性・可搬性を向上させる施策があります。
その中でも今回は PSR-15 に焦点を当てて、この PSR が 誰のために作られ、どうやって使っていくことが求められているのか をインターフェースから解説していきます。
handle
という 1 メソッドだけが宣言されたこのインターフェース、一体どう使えば良いのでしょうか? PSR-7 に批准していない Laravel(Symfony) ユーザーはどうこれをとらえれば良いのでしょうか?
PSR-15 批准フレームワークを 自作 して得た PSR との向き合い方をご紹介します。
初心者向けのセッションです。
対象:
• PHPをこれから始めたい方
• 学習中に壁にぶつかってしまった方
• ChatGPTの活用を知りたい方
ゴール:
ゼロから始める方にもわかりやすく、PHPがはじめられるようになります。
内容:
近年、AI技術の進化により、言語習得のハードルがぐっと下がりました。
このセッションでは、ChatGPTを使ってPHPを学ぶ効果的な方法を紹介します。
• ChatGPTを活用した効率的な学習方法
• PHPの基本的な概念と書き方の解説
• 簡単な開発環境のセットアップ方法
• ChatGPTを使ったコーディングのヒントとテクニック
• 実際に動くシンプルなプログラムの作成
ChatGPTを活用して、よりスムーズに、そして楽しくPHPの世界に飛び込んでみましょう。
結婚準備クチコミ情報サイト「Wedding Park」は今年でクチコミサービス開始から20周年を迎えたウェブサイト。
このレガシープロダクトでは、幾度もPHPで動くシステムのバージョンアップやシステムリプレイスのプロジェクトが生まれてきました。
・PHPのバージョンアップ
・Laravelフレームワークへのリプレイス
・オンプレサーバからAWSへの移行
・コンテナ化 など
システム運用者として定期的にアップデートしていきたい想いと、長期にわたる大規模プロジェクトとなり頻度高く実施ができない。そんな悩みとぶつかっていました。
その歴史の中で約10年、アプリケーションエンジニアとSRE、各視点で向き合って運用・開発してきた経験を基に、
・これまでのシステム改善の変遷と知見
・運用と開発視点でのプロダクトとの向き合い方
・新たな価値を継続的に提供し続けるための長期計画
をご紹介します。
PHP やプログラミングにまつわる内容をクイズ番組のような形態で早押しで答えていただきます。
回答者(またはチーム)はカンファレンス前に募集しておき,トーナメント形式で実施します。チームを組むのもあり,一人で答えるのもありの本格クイズ形式で進めます。
例えば以下のようなクイズに早押しで答えていただきます:
「PHP でファイルパスを指定して,ひと関数だけで読み込むには file_get_contents を用いますが,ファイルパスを指定してひと関数だけで書き込むには何の関数を使えばよいでしょうか?」
のような出題に対して「答え: file_put_contents」とどなたかが(もしくはチームが)答えられると正答数が加算されるような仕組みです。
PHP を書く上で、静的解析ツールは必需品となりました。コードを実行する前に型を解決し、問題を明らかにすることで、開発イテレーションを大きく向上することが可能です。
静的解析ツールはいくつかありますが、その中でも PHPStan は非常に強力なツールとして利用されています。その PHPStan で最も細かく解析してくれる level: max
を使うと、 mixed
型や array-shapes
を含め 全ての変数に型を明示する必要があります 。
このトークでは、自作 PSR-7 実装を通して、どのようにして level: max
な PHPStan で 型安全 に実装するか、そして その費用対効果がどれほどなのか を紹介します。
レベルマックスな PHP ユーザーは一体どうなるのか?解き明かします
心を込めて模倣をすれば、Composerと心は通うのか──
「composer require hoge/fuga
と打ったら、適切にパッケージが配置され、オートロード可能な状態になった」
を100分間で目指す企画です
composer require
で新規パッケージをインストールする、一連の流れPHPerの世界でもwhatやwhyが大事だ、howはなんでもいい、と言われるようになりました。
たしかにwhyやwhatはとても大事で、howは所詮howです。
しかし、howを軽視しすぎるのはおすすめできません。
「思考に気をつけなさい。それはいつか言葉になるから。言葉に気をつけなさい。それはいつか行動になるから。(後略)」というマザーテレサの名言にもある通り、howは知らず知らずのうちにあなたの設計方針に影響を与えてしまうのです。
howがどのように設計方針に影響を与えるかの実例をいくつか紹介した後、その対策についてお話しします。
ORM(Object Relational Mapper)使っていますか?
生PDOを使っていた段階からはじめてORMを使ったとき、誰しも感動したと思います。
しかし、しばらく使っていると…アレアレ?困り事が発生してきます。
このトークではPHPの代表的なORMについて概観し、ORMにまつわる困り事の具体例を解説してから、ORMを乗り越えて、ORMに縛られるのでなくORMの使い方をコントロールするための考え方についてお話しします。
ORMとは何を解決してくれるツールで、何は解決してくれないのか。ストレスなく保守しやすいORMとの付き合い方のバランスはどこにあるのか。皆さんが考えてみるきっかけとなることを目指しています。
キーワード: DTO(Data Transfer Object), 詰め替え, クリーンアーキテクチャ, ORM as 高級なクエリビルダー
本セッションではDDDのための設計パターンの一つ CQRS/Event Sourcingの実装をアクターモデルとともに体験します。
アクターモデルを通じて他言語と同等な
本格的CQRS/Event Sourcingの実装を体験することで仕組みの理解に役立てることができます。
PHP アクターモデルツールキットPhluxorによるCQRS/Event Sourcing実装体験と、
CDCを利用したCQRS/Event Sourcingが体験できますので、
他言語でおなじみのAkka/Pekko、Proto Actorなどの理解にも繋げることができます。
実装ではREST APIまたはGraphQLを利用予定です。
実行環境はローカルのDockerとなりますのでPCの持参をお願いします。
コードは簡単な土台を提供しますので事前準備は必要ありません。
クリーンアーキテクチャの同心円で、一番外側にあるデータベース。ドメインのコードはデータベースに依存させないように書きましょうと言われがちです。しかし、果たしてデータベースは本当に常にドメインの外側に置くべきなのでしょうか?
リンケージではLaravelとDoctrineORMを組み合わせてドメインのコードとフレームワークの距離を保ちつつ開発していますが、ドメインとデータベースとの距離については議論がありました。
Doctrineという技術選定、ドメインのコードからORMへの依存を許す決断をした根拠についてお話します。
これまでPHPにおけるテストフレームワークといえばPHPUnitが主流であり(PHPSpecやCodeception等もありますが普及範囲が広いものに言及します)、ほとんどのPHPを使ったシステム開発で、テストフレームワークを導入していれば一択といっても過言ではないと思います。
ですが、近年(といっても2021年の登場ですが)流星のごとく登場した、テストフレームワーク「Pest」を、弊社では取り扱うこと決め、その導入からテストコードとして認められるマージされるまでの実録を爆速紹介いたします。
2023年5月、Twitter(現X)が提供するAPIが突如として有料化し、2009年から個人により運営されてきたTwilogがサービスの終了を発表しました。
そこに手を差し伸べる1つの企業がありました。そう、Twitter関連企業のTogetterです。
華麗な買収エピソードの裏側で、Twilogの統合プロジェクトがスタートします。
などなど、1年間に及んだ移行作業の全容についてお話しします。
Twitter(X) :
yositosi(@yositosi) https://x.com/yositosi
アオヤマ ミント(@MintoAoyama) https://x.com/MintoAoyama
このワークショップセッションでは、参加者がPHP製 アクターモデルツールキット Phluxorを利用して
アクターモデルを用いた実装を体験します。
PHPでの限定的な考え方や実装に閉じず、
他言語で広く使われているAkka/PekkoやProto Actorなどにも流用できるように
共通の概念を用います
PHPを通して他アクターシステムを理解する手助けにもなるでしょう!
①
「このコード何となく良くない気がする、リファクタしよ〜」「書き換えてみたけど、しっくりこないな‥」
そんな経験はないですか?
②
「コピペコードになってるなぁ。もっと良いやり方がありそう…」「でも既存コードに手を入れる踏ん切りが付かない!」
そんな人はいませんか?
コードの代わりに、日本語で記述された要求・手続きの文章に「変更」を加えていきます
良い設計技法やイケてるコーディング──
新しい事を学ぶ際には「なぜ生まれたのか」を知ると武器になります
そのために、「それが生まれる前の様子」を知ると助けになります
現代的な「良い」コードの探求のため、昔っぽい世界を覗いてみませんか?
「クラスもねぇ制御フローもねぇglobalやgoto頼りの世界」を覗いていきませんか???
手続き型?いいえ!もっと遡りましょう
「構造化プログラミング的な要素を排除しつつ、今日のPHP(8.4)で開発」に挑みます
PHP Internals Book https://www.phpinternalsbook.com/ というものをご存知でしょうか
これはphp-srcを知りたい人のための資料になっています
普段はこれをもとにしたPHP Internals わいわいというもくもくハンズオンを行っています。
これをPHPカンファレンスのワークショップで行うというものです。
今回はPHPカンファレンスのワークショップとのことで、mbstring拡張がどうなっているのか、mb_*関数を作ってみましょう!
Hi! I'm tekimen, PHP mbstring commiter.
Would you like know what works mbstring?
If this proposal accepted, Feel free to join to our workshop!
エンジニアとして始めると必ず知る概念、それが「デザインパターン」です(諸説あり)。
私は新卒の頃、輪読会としてデザインパターンの本を読みました。そして、その知識を持て余したものです。
”デザインパターンを勉強しよう”で知ったデザインパターンは、その適用に失敗することの方が多いように感じます。
「道具として自然に出てくること」が大事であること、そして「道具としてもう使われないものもあること」を認識するのが大切です。
普段使用するフレームワークやライブラリに出てくるデザインパターンを参考に、今でもよく使われるデザインパターンを紹介していきます。
話すこと
・デザインパターンとの向き合い方(共通言語として”デザインパターン”を知っておく)
・フレームワークやライブラリに出てくるデザインパターン
・好んで使わないデザインパターン
※GoFのデザインパターンのことを指します。
PHPUnitには多くの便利なアサーションが用意されていますが、わたしたちが普段使っているフレームワークにも独自のアサーションが実装されていることをご存知でしょうか?
普段便利に使わせてもらっているアサーションの中身がどうなっているか、みたことはありますか?
「まだ、みたことない・・・!」という方、このセッションでテストの裏側にある仕組みにDeep Diveし、テストライフをさらに快適にしていきましょう!
話すコト
・PHPUnitがどのようにアサーションの結果をOK/NGと判断しているのかを知る
・各フレームワークにあるいろいろなアサーションを知る
・自分でカスタムアサーションを作成するという選択肢を知る
PHPのバージョンが上がるにつれて型周りの機能が充実してきました。
これに伴い、実行時、型によるエラーを発生させないためにコードを書く時に注意したり、静的解析による検査を導入するという事が必要となってきました。
PHPStanはそのような実行時にエラーとなる可能性のある部分を指摘してくれる静的解析ツールであり、ご存知の方も多いと感じます。
しかし、「導入がしたいけど出来ていない」という話や「導入したけどあまり活用出来ていない」という話を時々聞きます。
そこで、本トークでは以下のような点について自身の経験を踏まえてお話します。
PHPStanを全く知らないという人から導入を検討している方、更に知識を深めたいという方まで楽しめるトークを目指します。