昨今、Forteeはカンファレンスのプラットフォームとして多くの国内カンファレンスで使用されています。
また、最近では「カンファレンスに登壇やスポンサーをする」という趣旨のブログやプレスリリースが増えてきています。私も所属している企業でテックブログを執筆しています。
何回か登壇情報のテックブログを書くうちに、「Forteeから情報をコピペするのがめんどくさい」「集め終わった情報をjsonなどで保存したい」と思うようになりました。
そこでプログラムを書き、Forteeからtalk情報やog画像を取得できるようにしました。
本セッションではプログラムをどのよううに作成したかを紹介します。具体的には、プロポーザルページデータ(html)の取得、HTMLデータの加工方法についてお伝えします。
このセッションの対象者は登壇ブログを書く方や未来のFortee CLIの開発者です。
PHPはインタプリタ型言語で、実行ごとにパースとコンパイルが必要です。
OPcacheは一度コンパイルされたコードの最適化されたバージョンをキャッシュする拡張機能です。これによりPHPの実行が効率化されます。
PHP8よりOPcacheにはサブセットとしてJITコンパイラが導入され、より高速にPHPコードが実行できるようになりました。
本トークではOPcacheの概要から、チューニングの要点、監視や運用について解説します。
また、25k req/s程度を捌く大規模なPHP Webサービス環境におけるOPcacheチューニングの影響や、
特にJIT導入時のレスポンスタイムやCPU系メトリクス等についての変化を共有します。
PHPで作られたツールをいろんな環境でサクッと動かしたいと思ったことはありませんか?
Docker上で動かすことも出来なくもないけれど、色々制約もあるし、どうにかしてシングルバイナリで動かせないかな?ということでアレコレ試してみたことをトークしたいと思います。
どんなに綺麗な仕様書を書いても、コードから離れては生きられない(メンテナンスされず陳腐化して活用されない)。
そんな思いからスキーマ駆動開発でのコードとスキーマの乖離をさせないという理想を追い求めて辿り着いた開発プロセスを紹介したいと思います。
スキーマ駆動開発での悩みポイントにフォーカスし、なぜ今回のプロセスを採用しようと判断したのか?
また段階的にプロセス見直し最終的には他プロジェクトにも適用可能なcomposer化を目指したのか?についてお話します。
2023/09、PHP5.6からPHP7.0にアップデートしました。
そこから後述のスケジュールでバージョンアップを行なっていきました。
どのように進めていったのか、何に苦労したのか、何を工夫したのか、について話します。
バージョンアップスケジュール
※ECサイト、管理画面の2環境のスケジュールです
・ECサイト
7.0 2023/09
7.1 2023/11
7.2 2023/12
7.3 2024/02
7.4 2024/03
・管理画面
7.0 2023/09
7.1 2023/10
7.2 2024/01
7.3 2024/01
7.4 2024/03
AWS CDKでサポートされていないPHPでIac的なことをやるとしたら?という興味とその実装が本発表の論点です。
今回はAWS SDK for PHPから提供されるクラスをを使用して全てのインフラリソースをコード化し、その場合の構成管理やメリデメを共有する内容になります。
インフラ構成の題材としては、下記のサービスを使用したシンプルなContainer Applocationを考えています。
VPC, Subnet, ALB, ECS
扱いたいトピック
皆さんは、全く慣れない言語を「今から使ってね」と言われた経験はありませんか?私はいままさにそうです。
コンパイラの言うことを聴いているだけで動くコードが書けるRustと違い、PHPは気をつけることがいっぱい......。(個人の感想)
そんなPHPに不慣れな私が普段のRust開発と変わらずPHP開発ができるようになった自分なりに開発環境や気をつけていることをおはなしします。
もしこれから全く違う言語を触ってね、と無茶振りされている人・これからされそうな人、安全にPHP開発がしたい人向けのLTにする予定です。
SaaSでは複数顧客のデータを同じApp、データベースサーバーで扱う設計(マルチテナント)をよく用います。
リソースの運用効率がよく管理も楽ですが、他顧客のデータにアクセス出来てしまうリスクを抱えています。
これでは攻撃が怖くて夜しか眠れない…情報流出のニュースを見るたび不安で寿司しか喉を通らない…恐怖を和らげるために毎日飲みに行ってしまう…
安心して遠くのカンファレンスに行くこともできません。
この対策として、顧客別にデータベース スキーマ(MySQLでの"データベース")を分け、DBユーザも分離する方法を紹介します。
DBユーザ権限の制限により、ロジックミスがあっても、仮にSQLインジェクションが通っても、絶対に他顧客データにはアクセスできない設計です。
またCakePHPのORMでこの運用を自動化し、ロジック側で意識せず運用する方法も紹介します。
WEBサイトにユーザがJavaScripを埋め込めると、任意の操作が可能になってしまい、非常に危険な脆弱性となります。
例えば管理者権限ユーザを狙ってセキュリティを解除させたり、情報をお漏らししたり…
これはクロスサイトスクリプティング(XSS)と呼ばれ、PHPではhtmlspecialchars()で対策できるようになっています。
とはいえ「全ページ中で1箇所でもhtmlspecialchars()忘れたら死ぬ」は辛くないですか?
自分は大丈夫?他のメンバーは?新人が来たら?そもそも"気をつける"が対策なのは…
この危険かつ面倒なXSSに対し、Content Security Policy(CSP)というHTTPヘッダが強力な防御策になります。
本発表ではCSPヘッダの紹介と実装方法、また実際にPHP + nginx + Vue構成でサービスを作った際にハマったポイントをお話しします
クリーンアーキテクチャの同心円で、一番外側にあるデータベース。ドメインのコードはデータベースに依存させないように書きましょうと言われがちです。しかし、果たしてデータベースは本当に常にドメインの外側に置くべきなのでしょうか?
リンケージではLaravelとDoctrineORMを組み合わせてドメインのコードとフレームワークの距離を保ちつつ開発していますが、ドメインとデータベースとの距離については議論がありました。
Doctrineという技術選定、ドメインのコードからORMへの依存を許す決断をした根拠についてお話します。
単位時間あたりの充実度,高めたいですよね.
これだけ情報過多の世界になって,いいブログやいいスライドもたくさん出てきました.
「いいブログやいいスライド以外を掴んだら時間が無駄」
「センスのある人の発信を追いかけるだけで十分」
そうお思いの方はいらっしゃいませんか?
あるいは,
「チームメンバーにも自主的に情報収集してほしいけど,なかなか行動を起こしてもらえない」
と,嘆かれている方はいらっしゃいませんか?
これらの思い込み,悩みに,永遠の別れを告げましょう.
私が取り組むインプット活動である「ブログを読む会」を紹介します.
inspired by https://iidasaketen.thebase.in/items/8376621
参考情報 : https://note.com/tomio2480/n/nf909bb77b4b7
1年前の私は、チーム開発や複雑なシステムの開発経験がほとんどありませんでした。
しかし、試行錯誤しながら色々な「道具」を身につけていき、中途入社1年足らずで複雑な業務システムのリファクタリングのリーダーを任されるまでになりました。
私が開発で使っている「道具」は最新のパッケージばかりではなく、ごく普通のアナログなものも数多くあります。
このトークでは以下を実現するために、私が普段使っている七つ道具を紹介します。
・思考の整理にはこれ -> 〇と〇〇
・見落としをなくせ -> 〇〇〇〇〇〇〇
・複雑なパターンを攻略 -> 〇〇〇〇〇〇〇〇〇〇
・「わかっている」が落とし穴 -> PHP〇〇〇〇〇
・論より証拠を提示せよ -> PHP〇〇〇〇〇〇〇〇
・縦横無尽に検索 -> 〇〇〇〇
・退屈なことは… -> 〇〇〇〇
対象者
仕事でコードを書き始めて1~3年くらいのエンジニア
WEB開発において、コンテンツ管理機能の追加は一般的な要件です。
ブログ機能の追加を例に挙げてみましょう。
従来の開発プロセスでは、データベース設計、投稿機能、画像アップロード機能などの実装に多大な手間とコストが必要になります。
このプロセスは開発者にとって負担が大きく、プロジェクトの進行を遅らせる原因にもなります。
本トークではLaravelとヘッドレスCMSのmicroCMSを組み合わせることで、この問題を効率的に解決する方法をご紹介します。
LaravelアプリケーションとmicroCMSの連携方法、APIを活用したコンテンツの取得や表示の方法をコードスニペットを交えて解説します。
本トークの内容を実践すれば、開発の自由度を高めつつコンテンツ管理の手間を減らすことができます。
あなたはより効率的に、そして柔軟にプロジェクトを進められるでしょう。
私はこれまで幅広いキャリアを歩んできました。経歴としてはSES企業/Web系自社開発の上場企業/フリーランスエンジニア/起業/Web系受託開発企業/スタートアップ企業/プログラミングスクール講師/地方移住などです。
その中で得られた経験などを元にエンジニアとしてどのような選択肢があるのか?というお話をできればと思っています。
1.何故キャリアのゴールを決めた方が良いのか?
日々の仕事の納得感が変わる
人的資産、社会的資産、知的資産の計画を立てるとゴールが見えてくる。
2.日本と世界におけるエンジニア市場の違い
3.これまでの自分のキャリア
4.他のエンジニアのキャリアモデルケース
5.どうやったら、ユニークな人材になれるのか?
6.自分に合ったキャリアの最適解を決める方法
7.実際、エンジニア出身経営者としてキャリアを歩んでみてどうだったか?
Visual Regression Test(VRT)とは変更前と変更後のコードで対象画面のスナップショットを比較することで、発生したUIの差分を検知し、見た目のリグレッションが発生していないかを検証するフロントエンドのテスト手法の一種です。
一方で、VRTは強力なリグレッションテストツールでありながら、Flakyで壊れやすく、継続的な実行が難しい側面もあります。
本トークでは、チーム開発でVRTを行う過程で問題となることや、継続的にVRTを運用する方法について実体験をもとにご紹介いたします。
Fat Controller
と聞いて、いい印象が思い浮かばないのはなぜだろう。
Fat Controllerに何かの恨み辛みを含む記事は見たことがあるが、逆は全くない。
そもそもFat Controllerとは何か?
何がFat Controllerを悪者たらしめるのか?
世の中のすべての物事森羅万象には、長所短所あります(諸説ある)。
筆者はFat Controllerに助けられることが、ここ数年でしばしばあったからこそ、Fat Controllerに向き合いたいと思う。
Fat Controllerの真実を、あなたも知りたくはありませんか?
私はおよそ9年弱同じ会社に勤め続けた後、今年の4月1日に新しい職場に転職します。
これまでも私は前の職場で3つのチームで働いてきて、異動するたびに自分なりに素早いキャッチアップを意識して様々なことをやってきました。逆に自分のチームに新しいメンバーを受け入れる際にも工夫していたことがいくつかあります。
PHPカンファレンス福岡2024当日は、私が新しい職場に転職してほぼ3ヶ月経過しているので、実際どういった工夫を実施したのか・周りのメンバーからどういう支援を受けたのかを発表いたします。上手くいったことも、逆にそれほど上手くいかなかったこともあるかもしれません。
このトークは今後社会人になる予定の人、初めて社内で異動をする人、初めて転職することになる人にとって有意義なトークになることを目指します。
みなさんは OSS に contribute した経験はありますか?
すでに contributor の方もいれば、興味はあるけれど、一歩を踏み出す勇気がまだ出せていない方もいると思います。
かくいう私も、 OSS への contribute に興味はありつつも、その一歩が踏み出せずにいる一人でした。
そんな自分が、とあるきっかけで OSS に Pull Request を送り、 contributor になりました。
本トークでは、 OSS の contribute を躊躇していた私が OSS contributor への第一歩を踏み出せたきっかけについてお話しします。
実際に contributor になった経緯を余すことなくお話しします。
このトークを聞いたら、きっと OSS やコミュニティがもっと好きになりますよ!
(なぜ コミュニティ も? それはトークでのお楽しみ!)
みなさんは GraphQL を利用したことはありますか?
GraphQL の利点として、クライアントが必要とするデータを API に 過不足なく伝達して取得できる という、 従来の REST API では実現が難しい機能 を実現できます。
GraphQL は さまざまな言語やフレームワークでサポート されており、 PHP でも利用できます。
さらに、 Laravel では、簡易的な API サーバーであれば容易に実装が可能です。
本トークでは、 GraphQL の基礎と、 Laravel で GraphQL サーバーを実装する方法を紹介します。
また、実際に Laravel で GraphQL を利用した事例についてもお話しします。
一緒に GraphQL の基礎を学んで、 GraphQL の便利さを体感してみませんか?