FQDN(ドメイン名)が正しい値か否かをチェックする処理を書いたことがありますか?
filter_varで一発でしょ、と思ってたんですが調べてみるとどうやらそうでもなさそうだということがわかりました。
このトークではFQDNの奥深くてややこしい仕様についてお話します。
PHPコミュニティには長い間お世話になっており、そのコミュニティへ少しでも恩返しができたらと思い、会社にスポンサー協賛の話を持ちかけました。
特別な肩書きのない一エンジニアが、会社にスポンサーの話を持ちかけ、実際に申込みするまでのアレコレをご紹介します。
会社によって手続きに異なる部分があるとは思いますが、「スポンサー手続きって何をどうやるの?」「面倒くさいだろうな」と漠然と思ってる方の参考になれば幸いです。
こんにちは。やまゆです。
Reflection を使ったことはありますか?「重い」「メタプログラミングって何?」「フレームワークやライブラリが使ってるらしいけどアプリケーションでは使わないのでは」という話が聞こえてきます。
私は、(まだ未リリースですが) json を話す普通の PHP アプリケーションに Reflection を使った便利クラスを実装して提供しています。
その中でも、「外部から取得してきたオブジェクトをマッピングしてインスタンスにする」便利なクラスを紹介したいと思います。
皆さんも Reflection の話に触れてみて、「もしかしたらこういう便利クラス作れるかも?」とひらめいていただければ幸いです。
phpは毎年新機能が数多く追加されています。
新しい構文や式が追加されることによってphp開発者の開発体験が上がっている一方、
誰かがその開発体験を支える対応をしているはずです。
具体的にどういう対応が必要なのか、LSP、Emacs、package managerの対応等を例に話していこうと思います。
LaravelのデフォルトビルドツールがViteになることはみなさんご存知でしょうか?
webpackよりも速くなると言われていますが、実際にどのくらい良くなるのか気になりませんか?
この発表ではLaravel Mix とViteの性能比較した結果を分かりやすくご紹介させていただきます!
はたしてViteは私たちの開発体験をどのくらい快適にしてくれるのでしょうか!?
▼こんな方におすすめ
・Laravelで開発経験のある方
・Viteがどんなツールのなのか知りたい方、気になる方
背景色と文字色の見やすさについて、なんとなく経験や見た目だけで判断していませんか?
デザイナーではないエンジニアだからデザインについて敬遠していませんか?
この LT では、W3C の Web Content Accessibility Guidelines Working Group のガイドラインを参考に、計算した数値を基に背景色に対して見やすさの指標を算出し判断する方法をご紹介します。
計算方法さえわかってしまえば、なぜ「赤 RGB(255,0,0)」は「白 RGB(255,255,255)」や「黒 RGB(0,0,0)」どちらとも相性が悪いのか?数値を基に分かるようになります。
最後に、この LT を通じて WCAG ガイドラインを参考に、エンジニアもより良いデザインを体系的に学ぶきっかけになれば幸いです。
今までVSCodeしか使ったことがなく新しいエディタに躊躇していましたが、新卒2年目の4月からPhpStormを使い始めました。
PhpStormくんと仲良くなるまでにやったこと、仲良くなって初めて知ったPhpStormくんのスゴいところをLTでお話します。
~オフショア先のコード品質向上は難しい~
オフショアの場合、遠隔地であることだけでなく言語や文化、環境が違うため、お互いに意図を理解できているかや共通の認識を持てているかどうかが怪しくなってしまいます。
特に、コード品質向上のために行ったコードレビューのフィードバックについては、
・正しく内容を理解してもらえているか
・フィードバック内容を次回のコーディングに活かしてもらえるか
など、オフショア先との意思疎通が障壁となって、改善が行えない場合が多くあります。
そこで、私のチームではコードレビュー時に「再利用可能な」情報を提供することで、サービス全体のコード品質向上に取り組んでいます。
このセッションでは、
・どのようにしてオフショア先のコード品質向上に取り組めばいいのか
・オフショア先のモチベーションを保ちながらどのように改善を行っていくのか
などを、PHPのコードを紹介しながらお話しします。
PHPerなら必ずと言っていいほどお世話になったことがある Composer ですが、自作したプログラムを Packagist に登録することは馴染みが薄い方も多いのではないでしょうか。
自作したプログラムを世界中のPHPerに配布する際、Packagist に登録するだけで Composer からインストールしてもらえるようになります。
ですが、せっかくインストールしてくれたユーザには、そのプログラムの内容をできるかぎり明確に伝えたいですよね。
本LTでは、自作したプログラムを Packagist に登録して世界中の PHPer に配布する際に気を付けたいことと、PackagistのWebの閲覧画面を確認する際に知っておくと良いポイントについてお話できればと思います。
■話すこと
・composer.json の書式に関する基礎知識
・Packagist への登録方法と閲覧画面で確認したいポイント
・親切な composer.json の書き方
■この発表をご覧いただくことで得られること
・composer.json の基礎知識
・Packagist への登録が想像より簡単だという実感
派手なSQLインジェクションは一般的なWebフレームワークを使用すれば基本的に発生しません。
しかし、LIKE検索を行う場合はDoS攻撃が成立してしまうことがあります。
LIKE "%a%b%c%d%e%e%f%g%@%.%"
上記のようなクエリはSQLエンジンに大きな負荷をかけます。
LIKE句のメタ文字はエスケープする必要がありますが、
$query->where('hoge', 'LIKE', '%' . $value . '%');
と直に書いてしまうケースは多いと思います。
LaravelでのこのLIKE句のインジェクション対策はおそらく3通りほどあると思うので、
それぞれのソリューションをご紹介していこうと思います。