私はかれこれ10年以上、出社時は、ほぼ毎朝カフェでノートパソコンを開いて、「仕事以外のなにか」をやっています。
例えば、興味のある技術を試したり、OSS の開発をしたり、登壇資料を作ったり。
世の中では「朝型の生活はいい」といった話も見かけますが、「エンジニアの朝型の生活」の一例として、実行してみて良かったこと・悪かったことなど、これまでの私の経験を踏まえてお話してみようと思います。
無料のWordPressプラグインである「FMPress Forms」を使用して、Claris FileMaker Serverと連動したWebフォームを作成する方法とその開発レシピについて解説します。FMPress Formsを利用することで、WordPress用のフォームプラグインであるContact Form 7で作成したWebフォームから送信されたデータをFileMakerデータベースに登録できます。ローコード開発ツールとして注目されているClaris FileMakerの製品構成やライセンスについて紹介しつつ、公開サイトとして運用しているWordPressと、社内システムで使われているFileMaker Server間の連携例を詳しく解説します。
PHP は Web を主戦場として発展してきた言語で、Web 以外はあまりおすすめしないというような紹介がよくされます。
果たして本当にそうでしょうか?
自作のもの、他作のもの含めて世の中には熱いパッションを感じる色々なゲテモノがあり、どれもみな愛すべき非常に面白いものたちなので、この機会にじゃんじゃん大紹介します。
2023 年 11 月、PHP で ISUCON13 にチャレンジしました。したはずです。このトークを応募した時点ではまだ ISUCON13 は開催されていないのですが、チーム登録は済んでいます。
当日実際に出せたスコア、行った取り組みの内容を簡単に振り返りつつ、よりスコアを伸ばすために行った感想戦の結果もご紹介します。
なお、当日に PHP 参考実装が提供されないなどの不幸があった場合も、自前で PHP 実装を用意するなどの形で楽しくトークを成立させられるようなんとかします。
想定する聴講者は以下です。
現代のWebではメールアドレスをIDとしてアカウント登録するサービスが多くあります。
メールアドレスをIDにすることの是非については現代では異論もありますが、なんだかんだといってまだ主流の方法といってよく、Webサービスの生命線と言ってもよいでしょう。
「そんなのフレームワーク使えばすぐ作れるでしょ」
……そう思って、素朴に作った私たちを待ち受ける運命をいっしょに追体験していきましょう。
話者は好んでOSSのBrefを利用したサーバーレスのシステムを構築しています
その中の欲求の一つにAWS Lambda内でSQLを利用したいという欲求があります
Amazon VPC内でAWS Lambdaを利用し、Amazon RDSに接続する方法がよく提案されます
しかしこの構成では利用した分だけ料金を支払う、いわゆるゼロスケールな構成に出来ません
この課題を解決するために、DBaaSであるSupabaseを利用したアプローチを考えました
非常に優れた仕組みと感じており、検証を進めましたがその中で少なからず感じた課題感がありました
今回はその課題感と、解法の提案を行いたいと思います
地方こそサーバーレス、PHPでサーバーレスアプリケーションを構築する一歩を踏み出しましょう
Psalm や PHPStan、あるいは PhpStorm などでの静的型解析の隆盛により、時には動的型の言語であることを忘れそうになってしまうのが現在の PHP という言語です。
しかし一方で PHP は古くからある言語ですから、その現代的なエコシステムの力を借りられない、ソースコード中にほとんど信用できる型情報のないレガシーコードを扱う現場も数多くあります。あるはずです。そうですよね?
このトークでは静的解析や動的解析によって PHP コードへ自動で型アノテーションを付与する方法を 2、3 個ほど紹介し、各手法の良いところ・悪いところを比較検討してみます。
想定する聴講者は以下です。
先日「PHPを動かす技術バトル~PHPer Tea Night~」という非常に興味深いイベントがあったので参加しました
その中でPHPの実行環境は「mod_php」を利用しているのか「PHP-FPM」を利用しているのかの議論がありました
インターネットでみた記事以上の情報のやり取りも行われ、様々な議論が起こり知見が深まった中で、
その違いの解像度を上げたいと考えました
もう一つの選択肢としてOSSであるBrefの話も添えてPHPの実行環境についての比較をします
なんとなくPHPの実行環境を決めるのではなくて、あなたの推しのPHP実行環境を見つけましょう
PHPをローカル開発するにはXAMPPとかMAMPを入れたらいいんでしょ? と言われて早数十年。
いやいやXAMPPで困ってないよと思いながらも、いつの間にか世の中ではみんなコンテナとかDockerとか言うようになりました。
本トークでは難しいことは置いといて、なぜみんなコンテナを使うようになったのか、Dockerの良いところ悪いところについて簡潔にお話しします。
話者はPHPカンファレンス2022にて「RFC911*から振り返るHTTPの仕様」という話をさせて頂きました。
その中で特に新しい仕様である「RFC 9114 - HTTP/3」を読んでインターネットの未来を感じました。
今回はHTTP/3に焦点を絞ってRFC 9114からの仕様を理解した後に検証を行い、これまでのHTTPとの違いを体験します。
PHPerとは切っても切り離せないHTTPの次世代プロトコルを体験することでその価値に触れ、
HTTP/3採用のモチベーションになれば幸いです。
PHPerの皆さまは今日もPHPを何処かの環境で動かしている事だと思います。
様々なクラウドベンダーの上にはPHPを動かす選択肢がいくつもあるのですが、
実際にどの環境で動かすのが良いのか迷ってしまいます。
今回はクラウドベンダーをAWSに絞り、
現在稼働させることのできるPHP実行環境の比較を行います。
より良いPHP環境を選択して、コスト効率よくPHPを運用しましょう。
2018年から約5年、計15人の1on1をする中でよく話すことをまとめた教育における考え方や理論をまとめた私の秘蔵のボードを大公開します!
しかも、どんなときに使うかの実践例付きで紹介します!
「わたしたちのコード(=ドメインロジック)」は安定していますか??
フレームワークを利用している場合にコードの境界がハッキリしていないと、強くフレームワークに依存することにもなりかねません。
フレームワークには便利な機能がたくさんあります。
たとえばLaravelには、Eloquent、Facede、サービスコンテナ、認証、ミドルウェア、Blade、artisanコマンドなどがあり、それらの機能を活用することで、スピード感のある開発ができるでしょう。
しかし依存のしすぎはビジネスの変化への対応による作り直しや機能のバージョンアップの際に思わぬ量のコード修正になってしまうことがあります。
わたしのチームでは主にInterfaceを利用して「わたしたちのコード(=ドメインロジック)」をフレームワークから独立させ、安定させることを心がけており、その方法をご紹介できればと思っています。
コードの問題点は見た目には分かりにくいことがあります。
知らず知らずのうちに悪いコードが増え、気付いた時には『レガシーコード』と呼ばれるような状態になっているかもしれません。
そこで、問題点に気付くための1つの方法として、コードを計測する方法があると考えています。コードの計測によって得られる情報は多岐にわたり、コードのサイズ、重複コードの有無、コーディング規約の遵守状況、循環的複雑度、エラーの有無などが含まれます。これらの情報を分析することで、コードの状態を知ることができます。
ただし、計測した数値は必ずしもそれ単体で問題点を示す訳ではありません。そのため、他の数値と組み合わせたり、実際にコードと対比して判断・行動することが重要です。
本トークでは、特にコードをツールで計測することによって得られる結果に着目し、コードの改善にどのようにアプローチするかをお話しします。
みなさんPHPをビルドしていますか?
つまりはaptやhomebrewやコンテナでPHPをビルドせず、バイナリインストールばかりしていませんか?
昨今、PHPのソースコードについて様々な話題がふえてきているものの、「あれ?ビルドする人がすくなくない???」と思っており、PHPをソースからコンパイルして使う方法が失伝している気がします
なので、今回PHPをビルドし、それをつかうという「ちょっと前だったら当たり前だった行為」についてトークしてみたいと思います
ちょっとトリッキーな技も説明できるかも?
このトークは初心者、中級者向けです。
リーダブルコードでは、このような定理が紹介されています。
「コードは他の人が最短時間で理解できるように書かなければいけない。」(Dustin Boswell リーダブルコード P.3 より引用)
皆さん、めちゃめちゃに長いSQLや、サブクエリのネストが深すぎて眩暈がするような難解なSQLを読んだことがありますね? 書いたことがありますね? 僕は、あります。
そこで、本トークではどうしたらリーダブルなSQLが書けるかというアイデアを紹介します。
ジェネレータは、特に大量のデータを効率的に処理する際に有効な手法です。
例えば、LaravelのCollectionは便利な機能ですが、多用するあまり気づかずに大量のデータを扱ってしまい、意図せずパフォーマンスに影響を与えることがあります。
本セッションでは、PHPとLaravelにおいてジェネレータを活用し大量データ処理のパフォーマンスを改善する方法について説明します。
普段PHPで開発しており、運用上のデータ量増加問題についてまだ考えてない方、あるいは現在悩んでいる方
ある程度事業が成長している会社であれば、技術的負債と向き合う必要があります。
私も沢山の会社で今まで向き合ってきました。
そこで小さくリファクタリングしようとして失敗したり、フルリニューアルに挑戦して失敗したり、多くの失敗の末、今では成功するアプローチとバランス感覚が身についてきました。
本日は実際に私が経験した失敗談と成功談を交えながら、技術的負債と付き合っていく正しい歩き方についてご紹介します。
※登壇資料はこちらです。
https://speakerdeck.com/soudai/learn-from-predecessors
このトークではシステム開発用スマートウォッチ的なものの話をしたいと思います。
健康を求め、私たちはジムに通うなどします。そして、体重、心拍数や消費カロリー等を測って成果あるいは体調を確かめます。そう、私たちは自身ことを思いの外わかっていないのです。だから私たちは測ります、私たち自身を。そして、メニュー、頻度、強度を変えるなど、習慣を見直すことでなりたい自分を目指します。
システム開発も似ています。「事業を成長させたい!ガシガシ開発を進めたい!」私たちは願い、勉強したり、開発プラクティスや技術を導入するなど工夫します。でも実際のところうまくやれているのか、私たちにはわかりにくいものです。だから私たちは測ります、私たちの活動やシステムを。
このトークでは、Four Keys等を用いてどのように可視化を進めたか、何が分かり、習慣をどう見直し、開発における体験がどう変化したかを共有します。
「推測するな、計測せよ」という言葉は、改善策を探す時だけでなく、新機能をリリースする時も同様で、「計測」することは重要です。
開発環境の少量のデータを扱う場合は問題なく動作するクエリも、本番環境の大量のデータではパフォーマンス低下し、スロークエリになる可能性があります。
このトークでは、本番環境での実行計画の実行時間が約600msかかるクエリを、約0.2msに改善した事例を題材に、計測と具体的な手法について紹介します。
話すこと
注意:このトークではPostgreSQLを使用しています。