「コンピュータは0と1しか処理できない」とよく言われています。
ビット演算があったり、浮動小数点演算があったり、文字コードが16進数だったりと、PHPerのみなさんもなんとなく実感としてはあると思いますが、なぜ「0と1しか処理できない」のでしょうか。
このトークではアナログの世界・電気回路でデジタルの世界・コンピュータ処理がどの様に表現されるのか、私たちがC言語やPHPで書いたプログラムの実行結果がディスプレイやスピーカーで認識できるところまでがどの様にできているかをお話します。
ふだんの活動ではあまり気にすることのないコンピュータの基本的な仕組みの話になりますが、このトークを聞いたみなさんが今までより少し解像度の上がった目でコンピュータを楽しめることを願っています。
PHP8が2020年11月26日に登場してから、日々進化し続けているPHP。
つい最近はPHP8.3の登場もあり、以前の言語とは比べない程に型システムの改善や、パフォーマンス向上されてきました。
一部機能を取り上げれると以下の改善があります。
筆者も普段はPHP8で業務のコードを書いて、その恩恵を受けています。
このプロポーザルでは、PHP8の沢山ある機能の中でも実際の業務を通じて、学んだ事のアウトプットとしてPHP8で堅牢にコード書くTipsについて紹介します。
『リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック』(Boswell & Foucher)
エンジニアのみなさんなら、一度は読んだことがあるのではないでしょうか。
私はブライダル専門メディアを自社開発・運営している会社で保守開発を担当しており、
現在はサイトの一部機能を削除する案件にジョインし、開発を行っています。
Laravelで構築された弊社のサービスは、約20年続く結婚式場のクチコミサイトです。
改修に改修を重ね長年運用されてきたサイトの機能を削除することは、簡単ではありません。
例えば、以下のような問題に苦戦しました。
・表記揺れをしている、または意味を汲み取れない関数名・変数名である
・あちこちでクラスが継承され、メソッドやViewファイルの依存関係が複雑である
・おそらくもう二度と使われないプログラムをきれいさっぱり削除できているか、不安になる
この経験から、普段からシンプルで美しいコードで運用・保守していくことの大切さを痛感しました。
本トークでは、歴史ある大規模サービスの機能を削除する上で直面した問題と、そこから得た学びを共有します。
“機能削除”という観点から、『リーダブルコード』をどのように意識して実践していくべきか、一緒に考えませんか?
ソフトウェア開発において、品質と生産性の向上は常に追求される目標です。
しかし、これらの目標を達成するための手段として、コードレビューの重要性がしばしば見落とされます。
本セッションでは、
・効果的なPRテンプレートの作成方法
・レビューイが良いコードレビューを受けるためのポイント・テクニック
・レビュアーがコードレビューをする上で気をつけるべきポイント・テクニック
などの我々が実際に取り組んできた効果的なコードレビューの実施方法とその重要性について解説します。
「コードレビューをどのように行えばよいかわからない」「他のチームはどのようにコードレビューを行っているのか知りたい」という方々にとって、
本セッションは有益な情報を提供します。
WEBアプリケーションを開発するうえでセキュリティは切っても切り離せない重要な事柄です。
WEBセキュリティの情報や教科書はたくさんありますが、全てを勉強するのは大変です。
実際に現場であった事故やコードの例を紹介し、最近のフレームワークを活用したWEB開発で起こりがちなセキュリティ事例をお話しします。
◆対象者
・ある程度PHPでWEBアプリケーション開発をしているジュニアorミドルエンジニア
・チームが書くコードをセキュアにしたいリードエンジニア
◆書くこと
・コードレビューしてたらこんな危ない書き方があった!
・こんな脆弱性があった!
・こんな攻撃を受けた!
オブジェクト指向プログラミングにおいて重要な概念となる「SOLID原則」 。
本セッションでは、自分が違反して書いてしまったコードを例に、SOLID原則を紹介していきます。
どのSOLID原則に違反しているか
自分がミスってしまった実装例を、時間の許す限り赤裸々に公開します!!
「良いプロダクトを作るためにもっとエンジニアとビジネスサイドで協力していきたい!」
その想いを胸に半年前からスクラムを使ってプロダクトを作っています。
それまではエンジニアとビジネスサイドが同じチームで深く関わって仕事をすることがあまりありませんでした。
スクラムを入れる上でコミュニケーションの取り方をガラっと変えたかったのですが、ちょっとハードルが高いかもな、、と感じました。
そのため最初は敢えて「不完全」な形式でスクラムを始めました。
スクラムの良さをチームで実感するにつれて、徐々に「完全」なスクラムになっていきました。
そして今は「チーム全員で良いプロダクトを作っている」という感覚があります。
本トークでは、どのようにスクラムの体制を改善していったのか実体験をベースにして紹介します。
このトークの対象
みなさん、サーバレスで動かすPHPはお好きですか? 私は大好きです。
よくサーバレスなマネージドコンテナサービスでWEBアプリを実行しますが、定期実行するジョブもマネージドなサーバレス環境で実行したくありませんか?
そんなあなたのために、3大クラウドそれぞれで定期ジョブ実行するためのポイントやそれぞれのサービスの比較を行い、実際にPHPを動かす際のポイントなどをお話します!
・Dockerなどコンテナについてなんとなく聞いたことがあり、ちょっと動かしてみたい人
・サーバレスでコンテナを使った定期ジョブをしたい方
・サーバレスという言葉に惹かれる人
・各社のサーバレス コンテナサービスの比較(特徴や料金体系など)
・実際にトライしてみての気づき
人類が増えすぎたPHPを品質保障(Quality Assurance)するようになって既に20年が過ぎていた…
開発環境の周りの巨大なContinuous IntegrationはPHPerの第二の故郷となり、人々はそこでプロダクトを生み、育て、そして死んでいった。
西暦2023、静的解析が開発環境に取り入れられるようになり、いくつかの現場ではめざましい成果を挙げたが、別の現場では疎まれ、また別の現場では開発プロセスに投入できないまま散っていった。
このトークでは、私の考える静的解析導入時のバッドプラクティスをお伝えします。
@var
を憎めphp-src。それはPHP言語のソースコードのことです。
そのため全て読むのは大変です。
php-srcを読む際、適当なtest.phpを作り、ast\parse_codeを利用しながら気になる挙動の構造を確認したり、気になるfunctionにブレークポイントを仕込んでdebugしていくこととなるでしょう。
しかし、debug環境を整えようとすると、一筋縄ではいかないことが多々あります。少なくとも経験の浅い僕にとっては簡単ではありませんでした。
MacやWindowsなど、デバッグを試す環境の違いにより色々な知見を得ながら環境整備しなければなりません。
それだけの労力を割きながら、いざphp-srcのmake testをしてFailだらけになると気が滅入ってしまうものです。
そこで、Dockerを利用してphp-srcのためのsandbox環境を整えました(発表当日にはgithub上でpublicリポジトリとして公開します)。
本セッションでは、そんなsandbox環境とVSCodeを連携方法や、それらを用いたfunctionへのアプローチ(debug)方法をお伝えいたします。
もうphp-srcの環境構築に迷うことはありません。
素敵なphp-srcリーディングライフを送りましょう!
対象者: php-srcを読んでみたい方/読もうとしたけど環境構築で挫折した方
皆さん、コア吐いてますか?
コアダンプファイルは実行中のプログラムのある時点でのメモリ内容を、丸っとファイルへ吐き出したものです。Linux や Unix 系 OS では、プログラムがクラッシュした際など、設定によってその原因究明のためのコアダンプファイルを吐き出させることができます。
我々 PHPer にはコアダンプファイルは馴染みの薄いものです。PHP スクリプトの実行でコアが吐かれるのは、ふつう処理系や C 言語拡張部分の不具合を踏んだ場合です。PHP は仕事で使われることの多いビジネスマンの言語で、仕事でそのような不具合を踏みやすい環境を常用することは珍しいでしょう。
しかしこのコアダンプ、プログラムのクラッシュ時以外でも取れば取れるもので、気合で読めばけっこう楽しいものでもあります。みなさんもこのトークを聞いて、毎日じゃんじゃんコアを吐いていきましょう!
PHP スクリプトは Web で多く使われ、Web システムの多くは I/O バウンドなため、CPU が遊びがちです。マシンの有効活用には PHP ワーカを増やして並列度を上げたくなります。
しかしたとえ CPU が余っていても、各ワーカプロセスがメモリを食いすぎると並列度を上げづらくなります。実質的に可処分メモリ容量を各ワーカの消費メモリで割った数が並列度の上限となってしまうこともしばしばです。
昨今は Roadrunner、Swoole、FrankenPHP といったリクエストごとに状態をリセットしない AltFPM が成熟してきており、また昔ながらのキューワーカのようなものや Web 以外での PHP 利用も含めて、long running な PHP 実行環境を利用するシーンは増えてきています。これは、メモリがどこでどう使われているかを把握しその改善を行う技術の求められる局面が日に日に増えてきていることをも意味します。
このトークではメモリ使用量の計測のとり方からビットフラグ化、interning、SHM 追い出しといったみみっちいテクニックに PHP のアロケータ実装にまつわる事情の把握まで、12 のメモリ改善技を雑然とご紹介します。
皆さんが所属してるエンジニア組織の課題はなんでしょうか?
どの組織も何かしらの課題があるのではないかと思います。
当社ではPHPで開発された複数メディアを運営し、エンジニアの人数も増加しながら継続的にリリースすることで順調に事業を成長させてきました。
一方で、事業が成長するにつれて「スキル獲得に漠然とした不安がある」や「他エンジニアと交流・切磋琢磨が生まれにくい」と言った声も聞こえるようになりました。
こういった課題に対して、エンジニアリングマネージャーとテックリードを中心に「技術推進委員会」という名の横断組織を作り、メンバーで熱い議論を交わしながら課題解決の施策を考え、実施してきました。(チーフエンジニア制度設計、ハッカソン運営、AWS勉強会開催etc)
このセッションでは、横断組織の立ち上げからこれまでに実施してきた多くの施策や、施策を実施したことでの組織の変化について話します。
みなさん、PHPの事を深く知りたいとき、どうしていますか?
PHPのマニュアルを読む、php-srcを読みにいく、...などがパッと上がるかなと思いますが、
以下を読んでいく事でPHPの仕様を深く知っていくことができます。
https://apiref.phpstan.org
リファレンスを読み、実装されているAST周りから読み解くことでPHPの言語仕様などが”逆引き”のような感覚で面白かったので、例題を出しつつご紹介したいと思います!
息子が大学生になって、子育てが一段落しました。
新卒でエンジニアとして就職してから、結婚して子供が生まれ、今までのキャリアの中で本当にいろいろなことを考えてきました。
自分にとってだけでなく、家族にとって一番よいありかたはどういう形なのか模索し続けた結果、今ここに立っています。
その間、転職をしたり、会社が買収されたり、スタートアップに飛び込んだり、自分で会社を始めたり、いろいろありました。
本トークでは、キャリアの一例として自分がどのように考え、判断を行ってきたか紹介すると同時に、
今まで多くのWebエンジニアを(社外CTOや技術顧問等のアドバイザーとして)見てきた経験もふまえて
Webエンジニアのキャリア戦略についていくつかの考え方を提示します。
皆さんがキャリアについて考える上で、何か参考になることがあればうれしいです。
エンジニアは継続して勉強する必要があると言われています[要出典]。
じゃあなにをどうやって学ぶのかはあまり教えてくれません。コードを書いて公開すればいいよとか、本を読むといいよとアドバイスはしてくれるものの、具体的な行動に移すのが難しいなあと感じます。
そんなふうに思っていた自分は今では、本をたくさん読み、ポッドキャストをたくさん聞き、いろいろな勉強会に参加していました。私が実践している楽しく勉強ができる方法を紹介します。
PHPの世界では、CSRF対策としてセッションを利用したトークンを用いた方式が採られることが多いのではないでしょうか。
例えばLaravelの場合、「@csrf」とBladeのテンプレートファイルに記述して、Middlewareを用いれば簡単にトークンベースのCSRF対策が可能です。
しかし待ってください、例えばNext.jsにCSRF対策の機能はあるでしょうか。SvelteKitには?
実は、最近出てきたWebアプリケーションフレームワークでは、CSRF対策を標榜するような機能は入っていません。
本トークでは、SameSite Cookieを用いたCSRF対策について解説すると同時に、CSRF対策について改めて考察します。
当たり前だと思っていた、今までのCSRF対策を見直すきっかけになってくれたらうれしいです。
みなさんのアプリケーションには履歴データはありますか?
履歴データは大量に増えたり、必要なデータへのアクセスにすぐにアクセスしたかったり、履歴なのに改変できたりといろいろな要望を言われることがあると思います。
履歴データの取り扱いをする上で考慮しないといけないことを話します。
レポジトリパターンを使っていますか?
EloquentでModelをinjectして使っているつもりになっていませんか?
DoctrineORMのEntityRepositoryはいい線行ってますが、モデリングを極めると不足を感じます。
"本当のレポジトリパターン"についてお話しします。
プログラムを書くときに計算量を意識していますか?計算量の基本を理解することで、サービスが成長したときに問題を起こしにくいプログラムを作成することができます。簡単なプログラムを例にして、まず計算量という概念に慣れてみましょう。
本トークで話す内容