あなたのプロジェクトはどうやってコードを整形していますか?
PHP_CodeSniffer? それともPHP-CS-Fixer?
私は… 両方!
_人人人人_
> 両方 <
 ̄Y^Y^Y^Y^ ̄
そうなんです、EasyCodingStandardを使えば両方のいいとこどり、しかも爆速でコードを整形できちゃうんです。
このトークではこのツールの特徴とプロジェクトへの導入方法、設定方法などを爆速で紹介します。
BtoBなWebアプリケーションを開発してSaaSとして提供していると、お客様から「弊社の業務フローの都合でここを変更して欲しいのですが」という相談?要望?恫喝?を受けることがあります。
もちろんお金を払ってくれる大事なお客様なのですべての要望にお応えしたいのですが、無秩序にすべてを受け入れてカスタマイズすればコードもプロダクトもどんどん複雑になって、カオスと化してしまいます。
を考えながら個社カスタマイズを実装していく考え方をお話しします。
IaC(Infrastructure as Code)は、クラウドインフラストラクチャの自動化と効率化に欠かせない技術となっています。クラウドベンダーの一つであるMicrosoft Azureには、TerraformやARMテンプレート、BicepなどのIaCツールが用意されています。それぞれのIaCツールには特徴や利点があり、どちらが優れているかは状況によって異なります。
また、GitHub CodespacesはWebブラウザ上で開発環境を構築できるクラウドのエディターです。GitHub Codespacesを使うことによりローカル環境を汚さず手軽に環境を整えることができます。
本セッションでは、初級者向けにGitHub Codespacesを利用して、Terraform、ARMテンプレート、BicepのIaCを比較してみます。
AzureでPHPの環境を整えることを例にあげ、それぞれのIaCツールの利点や欠点を比較していきます。また、GitHub Codespacesでの開発環境構築の手順や利点についても解説します。
本セッションを通じて、AzureにおけるIaCの比較とGitHub Codespacesの活用方法について学び、より効率的なクラウドインフラストラクチャの構築に役立てていただけると幸いです。
ChatGPTやOpenAI APIを使って何か作ってみませんか?openai-php/clientを使えば、PHPアプリケーションから簡単にOpenAI APIを呼び出すことができます。このトークでは、OpenAIで使えるAPIの機能紹介、openai-php/clientのセットアップ方法、OpenAI APIを使ったサンプルLaravelアプリケーションの実装を共有します。
ComposerでPHPライブラリを作成する方法を解説します。
ライブラリの作成、Packagistへの公開までを5分以内で紹介します。
公開に必要なことに中心に紹介するため、すぐに実践することができます。
Composerは使うけど、案外なんとなく使っていたりしないでしょうか。
ライブラリ作成を通してComposerの理解を深めましょう!
みなさんは「SadServers」というwebサイトをご存知ですか?
webサイトにアクセスすると「Like LeetCode for Linux」と説明されています。
「LeetCode」であればご存知の方もいらっしゃるかもしれませんね。
このwebサイトでは「悲しい状態のサーバー」となっている設問が準備されており、「LeetCode」の要領で悲しくない状態にしてあげることが設問のゴールとなっています。
最近は「webアプリケーション開発を行っているとサーバーを触る機会がない」、「サーバーのことをどうやって勉強したらよいかわからない」といった話をたびたび耳にします。
なので、「SadServers」を通してこのセッションがサーバーに関する勉強を始めるきっかけになればよいと思っています。
PHPerKaigiではPHPerチャレンジというイベントがあり、そこで複数バージョンのPHPを実行しなければトークンを得られない問題がありました。例えば下記です。
https://fortee.jp/phperkaigi-2023/proposal/07411094-2fc1-4abd-904f-9470454531e6
この問題、回答方針の一つとして複数バージョンのDockerを用意するという方法がありますが、Dockerを使いたくないときもありますよね?
発表者は asdf を利用してPHPの複数バージョンインストールを行い、検証しました。そして無事に問題を解き、トークンをゲットできました。
このLTでは次の3つについてお話しします。
PHPだけでなく、複数のプログラミング言語・ツールのバージョン管理ができる asdf の利便性を感じていただき、複数バージョンのツールが使いたい…けどめんどくさいと…いう悩みを解消しましょう!
皆さんはどこの言語圏にお住まいでしょうか?
(もちろん PHP 言語圏だとは思いますが)PHPer の皆さんの中には,私と同じ日本語圏にお住まいの方も少なくないのでは無いでしょうか?
日本語と言えば?そう.マルチバイトですよね.私達は日頃からマルチバイト文字と呼ばれる文字を扱っています.
一方で,Laravel を始めとする世界で使われている OSS を作っているのはどこの国の人なのでしょう?
OSS のコミュニティを覗いてみると,ドキュメントや Issue はどれも英語で書かれています.もちろんこれは,英語は世界で広く使われている言語だから,というのもありますが,(これは私の体感ですが)開発者の多くは主に英語をネイティブに使っている方のような気がしています.
私が過去に使っていたライブラリやフレームワークも,英語圏の方,つまりシングルバイト文字を日常的に使っている方々が開発しているものが多くありました.そのようなライブラリやフレームワークは,しばしばマルチバイト文字が入力されることを想定していないことがあるようです.
そして,私のようなマルチバイト圏に住むエンジニアからしたら当たり前のことや感覚が,シングルバイト圏に住むエンジニアには伝わりにくいなと感じることがありました.
本セッションでは,実際にライブラリやフレームワークに「マルチバイト文字」に関するプルリクエストを作ったりディスカッションしたりした経験を元に,自分や他の開発者が直面しているライブラリやフレームワークの課題をいかに上手くコミュニティに伝え,世界で広く使われる OSS に少しでも貢献できるエンジニアになれるか,ということについてお話します.
令和のPHPerの皆さんはテストを書いていますね?
テストを書くとき、カバレッジという数値を闇雲に上げようとしていませんか?
実は、カバレッジの数字を上げたところでコードの可読性も変更容易性も上がらないし、バグも減らすことができません。
意味あるカバレッジの上げ方についてお伝えします。
PHPStan使ってますか? ここ数年のPHP界隈で品質保証のために最も使われるようになったツールのひとつと言えます。
私はいままでカンファレンスなどでPHP静的解析の布教を試みてきましたが、同時に機能追加提案から些細な修正まで約20個のPRを提出しています。
このトークにおいては5分の制限時間内でPHPStanへの貢献方法を難易度別に紹介します。
Guzzleに代表されるHTTPクライアントは、PHPからHTTPリクエストを送受信するために便利なライブラリですが、そのまま取り扱うとライブラリとの依存度が高まってしまいメンテナンスコストが上がります。そこで一般的にはラッパーを用意します。
LaravelなどのフレームワークではHTTPクライアントのラッパーが用意されていますが、そんなものは使わず、ラッパー自作しましょう。
自作することで、HTTPクライアントの依存をしっかり見抜く力が付きます。
このトークでは、Guzzleラッパーを自作しながら、HTTPクライアント・リクエスト・レスポンスのそれぞれの持つ情報が何の役割を持っているかを確認し、何に依存すべきかを考え、学んでいきます。
いちばん大切なことは「落とし所を決めて前に進める力」でした。
今回は、新卒1年目がPHP5.6から7.4へのPHPアップデートを主担当した中で学んだ「アップデートの難しさ」について語ります。
言語のアップデートはプロダクトに対する変更の影響範囲が極めて大きいです。そのため、プロダクトの技術的側面に詳しくないと壊れるポイントがわかりませんし、事業的側面に詳しくないと壊してはいけないポイントがわかりません。
また、とれる施策がたくさんあり明確に意識しなければやることがどんどん増えてしまいます。これに対応するためにビジネスサイドならびに現場エンジニアとの会話を重ね、「なぜアップデートを行うのか」を明確にしていきました。
今回は、PHPアップデートを行う中で見つけた「こうしておけばよかった」近道を話します。
SaaS全盛の昨今、マネージドなデータベースにロードバランサー、セッション用のKVSなどを含めるとPHPアプリケーションの運用費用は軽く月額数万円になってしまいます。ステージング環境や、CI後の確認環境を含めると運用費は掛け算で増えていきます。
本トークでは、なるべく安い値段でPHPアプリケーションを本番運用する可能性を探求します。
型、付けてますか?
型なしは心のゆるみ。プログラマたるもの、型付けは帰宅したら脱いだ靴を揃えるくらい自然に行なう所作です。
入力に型がなければ、すべての処理を安全に実行することはできません。
このトークにおいては標準関数のfilter_var()とPHPStanによる静的検査によって型なしの値に型健全性と実行時安全性を両立させる考え方を解説します。
https://www.google.com/search?q="コピペプログラマー"
既存のコードをクリップボードにコピーして、然るべき場所に貼り付けることで、プログラミングを遂行することが出来ます。
それなのに、世の中ではそれを良しとしない風潮もあるぞ!とは、みなさんも感じているところではあると思います。
他方で、 composer require darekano/nankano-package
をしても、それを見て「なんなのコイツ」と感じる人は少ない気がするんですよね。
どちらも「目的(要求を満足させるための振る舞い)を実装するために、コードを再利用する」という点では差がないはずです。
同じコードを世の中に増殖させる・・・!
それなのに、なぜ前者は駄目で後者は許容されるのでしょうか・・?不思議です。
駄目と言われるからには、開発者にとって必要な何か(特定の品質特性)を損ねるし、問題があるのでしょう。
良しとされるからには、そうしたダメージを回避しているか、あるいは品質を向上させる働きがあるはずです。
このセッションでは、「みんなが言っている当たり前」を理屈で考えてみようと試みます。
★ コードの再利用とは
★ コードに対する進化、フィードバックとは
★ 目先の「書く」ではなく、もっと先の「読む」「書き換える」のための品質を獲得しよう
PHPカンファレンス2023ではトーク募集にforteeというカンファレンス運用支援ツールが採用されています。
そのfortee、2023年3月下旬からトーク応募時にChatGPTによる「AI診断」の機能が付きました。
この機能は、入力されたタイトルと概要からAIがより良いプロポーザルになる様に思ったことを言う機能です。
さてこの機能、本当に役立ったのでしょうか。
ログが取れている範囲で「一度でも機能を使った方のトーク採択率」を計算してその有用性を検証するとともに、forteeへのChatGPT機能実装についてお話しします。
お話しする内容:
・AI診断機能のトーク採択率への影響
・ChatGPT機能の実装方法
・今回forteeで使用したプロンプト
・プロンプトの改善でどの様な変化がでるか
目に見える効果が無かった場合、このタイトルは釣りタイトルとなり、トークは事実上「PHPを使ったシステムへのChatGPT機能の実装方法とシステムに組み込むプロンプトの検証」となります。
競技プログラミングは、アルゴリズムやデータ構造の理解を深め、プログラミングスキルを向上させるための素晴らしい方法です。
「AtCoder」や「LeetCod」などの多くの競技プログラミングサイトがありますが、競技プログラミングで問題を解く時の言語としてPythonやGo、Rustが人気でよく使われていますが、PHPでも十分競技プログラミングに挑戦する事は可能です!
このセッションでは、競技プログラミングにおいてPHPを活用するためのテクニックについて解説します。
いくつか例題を出しながら、PHPにおけるデータ構造やアルゴリズムの実装方法について他の言語と比較しながら説明します。
テストがあるとコードレビューが捗ると思いませんか?
・テストがコードの仕様書になる
・テストを通じてどのような入力値が想定されているのか、どのような振る舞いが期待されているのかがわかりやすくなる
・プログラムの構造が見やすくなりレビューの正確性と速度が上がる
また、レビューを受ける側にとってもテストによりコードの動作が保証される安心感があるので、レビュー中の修正もしやすくなります。
このように、テストの恩恵は保守フェーズを待たずにコードレビュー中から受けることができます。
トークではレビューを受ける側・行う側の双方の視点から、テストによりコードレビューが捗る理由とテストコードの書き方を並行して紹介します。
・テストの目的は何?〜テストメソッド名でコードの可読性を上げる
・データの入出力をわかりやすく表現する〜データの流れはレビュアーの想像力に頼らずテストに落としこむ
・テストパターンと仕様について
世の中に入門書や入門者向けの記事は溢れています。
上級者向けの書籍や記事も増えています。
入門書を終えた後、次のステップに進むために何を学ぼうか悩んでいるビギナーの方は多いのでは無いでしょうか?
PHPを使って業務で開発を行っていくうえで、次のステップとして学ぶと良いことをお話ししていきます。
◆対象者
・入門書をやり終えた程度のPHP初心者
・簡単なWEBアプリケーションが作れるようになったPHP初中級者
◆話すこと
・バグを生み出しづらい書き方
・コーディング規約
・チーム開発において読みやすい書き方
・コメントの入れ方
・セキュリティを意識した書き方
・エラーの見方
内製開発チームを立ち上げて半年程度のスタートアップに昨年ジョインし、7月からCTOをやっております。
14名の開発チームに成長、サービスの展開を加速させていく中で、組織作りや開発基盤の整備を含め、取り組んできたことをPHPer目線でお話しします。
CTOに限らず似たような立ち位置の企業にジョインしたエンジニアの参考になればと考えています。
◆対象者
・スタートアップエンジニア
・新規の開発チーム立ち上げをしている人
◆話すこと
・エンジニア組織作り
・採用、技術広報
・経営層、他部署の知識向上
・開発環境、ルール作り