みなさん、PHPの事を深く知りたいとき、どうしていますか?
PHPのマニュアルを読む、php-srcを読みにいく、...などがパッと上がるかなと思いますが、
以下を読んでいく事でPHPの仕様を深く知っていくことができます。
https://apiref.phpstan.org
リファレンスを読み、実装されているAST周りから読み解くことでPHPの言語仕様などが”逆引き”のような感覚で面白かったので、例題を出しつつご紹介したいと思います!
息子が大学生になって、子育てが一段落しました。
新卒でエンジニアとして就職してから、結婚して子供が生まれ、今までのキャリアの中で本当にいろいろなことを考えてきました。
自分にとってだけでなく、家族にとって一番よいありかたはどういう形なのか模索し続けた結果、今ここに立っています。
その間、転職をしたり、会社が買収されたり、スタートアップに飛び込んだり、自分で会社を始めたり、いろいろありました。
本トークでは、キャリアの一例として自分がどのように考え、判断を行ってきたか紹介すると同時に、
今まで多くのWebエンジニアを(社外CTOや技術顧問等のアドバイザーとして)見てきた経験もふまえて
Webエンジニアのキャリア戦略についていくつかの考え方を提示します。
皆さんがキャリアについて考える上で、何か参考になることがあればうれしいです。
Laravelのバージョンアップを行う予定が、プログラムをすべて書き換える「リプレイス」をすることになったお話です。リプレイスをすることになった背景や進め方、よかったこと、大変だったことを、技術的、組織的な観点でお伝えします!
エンジニアは継続して勉強する必要があると言われています[要出典]。
じゃあなにをどうやって学ぶのかはあまり教えてくれません。コードを書いて公開すればいいよとか、本を読むといいよとアドバイスはしてくれるものの、具体的な行動に移すのが難しいなあと感じます。
そんなふうに思っていた自分は今では、本をたくさん読み、ポッドキャストをたくさん聞き、いろいろな勉強会に参加していました。私が実践している楽しく勉強ができる方法を紹介します。
PHPの世界では、CSRF対策としてセッションを利用したトークンを用いた方式が採られることが多いのではないでしょうか。
例えばLaravelの場合、「@csrf」とBladeのテンプレートファイルに記述して、Middlewareを用いれば簡単にトークンベースのCSRF対策が可能です。
しかし待ってください、例えばNext.jsにCSRF対策の機能はあるでしょうか。SvelteKitには?
実は、最近出てきたWebアプリケーションフレームワークでは、CSRF対策を標榜するような機能は入っていません。
本トークでは、SameSite Cookieを用いたCSRF対策について解説すると同時に、CSRF対策について改めて考察します。
当たり前だと思っていた、今までのCSRF対策を見直すきっかけになってくれたらうれしいです。
みなさんのアプリケーションには履歴データはありますか?
履歴データは大量に増えたり、必要なデータへのアクセスにすぐにアクセスしたかったり、履歴なのに改変できたりといろいろな要望を言われることがあると思います。
履歴データの取り扱いをする上で考慮しないといけないことを話します。
レポジトリパターンを使っていますか?
EloquentでModelをinjectして使っているつもりになっていませんか?
DoctrineORMのEntityRepositoryはいい線行ってますが、モデリングを極めると不足を感じます。
"本当のレポジトリパターン"についてお話しします。
私はポモドーロ・テクニックをこよなく愛する者です。会社ではポモニキと呼ばれており、日々ポモドーロ・テクニックを使っています。
しかし、このテクニックには抑えておきたい大事なポイントがいくつかあります。そうしないと集中もできず、作業も進まず、無駄に終わってしまいます。
本トークでは、ポモドーロ・テクニックの要点とやり方、さらにはおすすめのタイマー紹介など、ポモドーロ・テクニックを始めるための知見を紹介します。
Architecture Decision Record (ADR)はご存知でしょうか?
設計に関する議論や決定をまとめておく文書として、近年注目を集めています。
本トークでは、実際に会社でADRを導入して一年以上運用した結果、開発現場で継続的に使われているのかどうかなど、 実情を赤裸々にお話します。
本トークで話す内容
アプリケーションがヒットするとソフトウェアはどんどん肥大化します。そして、既存のウェブアプリケーションウェブフレームワークはPackage By Layer(PBL)の形式で作られているため、レイヤー内のファイル数が多くなりすぎてメンテナンスが困難になっていきます。
そこで、解決策の一つとしてよく取り上げられるのが Package By Feature(PBF)です。本トークでは実際にPBLのモノリスにPBFを取り入れて一年たった結果、どうなったのかをご報告します。
熟練のエンジニアたちがプロジェクト参加時に何を考えているのか、知りたくありませんか?
もしかして、設計のことを考えている?利益?事業ドメインの理解?
いやいや違うんです、兎にも角にも真っ先に確認しておかないといけないことがたくさんあるんです。
このトークでは、シニアエンジニアがプロジェクトを成功させるために何を考えているのかをぶっちゃけてみます。
2018年に「Laravel Collection の計算量を調べてみた」というタイトルで PHP勉強会で発表を行いました。
https://speakerdeck.com/hanhan1978/laravel-collectionfalseji-suan-liang-wodiao-betemita
あれから、5年。月日が流れて、Collection にはメソッドが追加され、ロジックにも変更が入りました。
というわけで、今、計算量がどうなっているのか測り直してみました。
プログラムを書くときに計算量を意識していますか?計算量の基本を理解することで、サービスが成長したときに問題を起こしにくいプログラムを作成することができます。簡単なプログラムを例にして、まず計算量という概念に慣れてみましょう。
本トークで話す内容
B+木をご存知でしょうか?RDBMSのインデックス作成に採用されているデータ構造で、ディスクの効率的な利用や、検索を行いやすいなどの特徴があります。しかし、耳学問で聞いてもイマイチ特徴がピンと来ないのです。
本トークでは、PHPでB+木のデータ構造を実装して、RDBMSでB+木が採用される理由、インデックスの構造的な仕組み、何故検索が速くなるのか?などなど、データベースの仕組みの根幹を覗いてみましょう。
本トークで話す内容
本トークでは、Laravelで作られた基本的なウェブアプリケーションを例に上げて、ウェブアプリケーションのチューニングとはどのようなことをすればよいのか?どのような原因でウェブアプリケーションが遅くなるのかを説明し、その対処法について紹介します。
本トークで話す内容
PHP は、気軽にウェブアプリケーションを作れる言語として、初心者から熟達者まで、人気のプログラミング言語です。
しかし、せっかく作ったウェブアプリケーションも、保守・運用で扱いにくいとレガシーアプリケーションとか、技術負債などと呼ばれます。また、PHP を忌避するエンジニア達も存在していて、レガシー化しやすいから PHP で新しいアプリケーションは作りたくないと評されたりもします。
しかし、保守性の高いウェブアプリケーションとなると、難しい設計論とかアーキテクチャーとかの話が出てきて、どうやっていいかよくわからなくなります。
なんとか、PHP の気軽さを保ちつつ、保守・運用がしやすいウェブアプリケーションを作ることはできないだろうか?
本トークでは、なるべく難しい設計論を避けつつ、どうやったら無難で、レガシーになりにくく、レガシーになったとしても何とかなるウェブアプリケーションが作れるかをまとめます。
本トークでお話すること
コミュニケーションにおける「パス」について、「コミュニケーションパス」がまず頭に浮かぶと思います。
いわゆる、1対1のコミュニケーションがどれだけ発生するか?というコミュニケーションパスとともに、チーム間を跨ぐ場合に誰を経由してコミュニケーションするか?という経路としてのパスもあります。
個人的に、直接のコミュニケーションにおけるやりとりも「パス」(pass)することだと考えていて、相手にいいパスを出せるか?というのもチームコミュニケーションにとって大切な要素ではないでしょうか。
本トークでは、1対1のコミュニケーションにおける対話(パス交換)に着目して、私が大切にしていることを共有したいと考えています。
突然ですが、あなたはどれぐらい集中してない状態でもPHPコードを書けますか?
たとえば、唐揚げを揚げながら、PHPコードを書けますか?
普通のPHPerのあなたはそんなことできるわけない、と思うでしょう。実はできます。
どうやればできるのか、お話しします。
「PHPUnitでテストカバレッジを取ろう」とすると、phpunit/php-code-coverage
というパッケージによって分析・レポート出力がなされます。
カバレッジのデータは、Xdebug(など)の拡張によって、PHPスクリプトの実行情報を取得されるものです。
一言で「テストカバレッジを取る」といっても、複数のレイヤーに登場人物がいて、それぞれの果たすべき役割が組み合わさって実現されていると言えます。
さて、実際に「それぞれで、どういうデータが出力され、どう変換されるのか」「どのような流れで、カバレッジの収集処理が起動・完了されるのか」が気になりませんか?
内部的な仕組みを知ることで、「単体テストでのテストカバレッジ計測」以外の活用方法も見いだせるかも知れません。
例えば、Xdebugの作者がYoutubeに展開している「Code Coverage for Websites」などは、興味深い例の1つでしょう。
このセッションでは、
について話をします。