決済と検索を数回のAPIコールで手軽に実装・連携させる方法を紹介します。
Stripeには、販売する商品や提供するサービス・サブスクリプションの情報をストアすることができます。
また、2022年にリリースされたSearch APIを利用して、商品データの検索が可能です。
しかし大規模なEコマースサービスやCtoCのマーケットプレイスなどでは、
商品価格を上限・下限で指定するなど、複雑な検索が求められます。
このトークでは、Stripeに登録したデータをWebhook経由で全文検索FaaSのAlgoliaに同期し、
Algoliaを利用した検索システムを顧客に提供する方法を紹介します。
◆現在予定しているトピック(変更する可能性があります)
・AlgoliaにStripeの商品・料金データをインデックスさせる方法
・Algolia Instantsearch.jsを利用した検索UIの作成方法
・検索結果とStripeの決済ページやカート機能と連携させる方法
オンラインサービスに欠かせない、課金・請求システムのTipsを紹介します。
Laravelを利用してアプリケーションを開発している場合、
Cashierを利用することで、Stripeを使ったオンライン決済機能を組み込むことができます。
また、AWSやGCPなどのクラウドサービスは、
作成したアプリケーションを複数の環境・用途にデプロイする作業を効率化します。
このトークでは、「Laravel Cashierを利用したStripeの決済組み込み方法」についてと、
「AWS App Runnerへのデプロイ方法」の2つを簡単に紹介します。
現在予定しているトピック(変更する可能性があります)
・Laravel Cashierのセットアップ
・Stripeアカウントでやっておきたい設定
・Stripeの便利機能をCashierまたはStripe APIから使う方法
・AWS App RunnerへのLaravelアプリケーションデプロイ
・AWSからStripeを利用する際のTips
アプリケーションを安定的に運用していくには、安定した実行基盤を構成する必要があります。
プラットフォームの選択肢として Microsoft Azure というクラウドをオススメしたいです。
「PHPとAzure」についての情報はそれほど多くないため、親和性はあまり良くないんじゃない?と思う人もいるかもしれません。
しかし現在の Azure は様々なサービスが提供されており、PHP 製のアプリケーションでも PHP を普段使っているエンジニアでも、様々なシーンで Azure を利用することができます。
PaaS (Platform as a Service) を中心としたアーキテクチャーを構成することで、運用の作業負荷を軽減し、エンジニアが本来の役割や作業に専念するための環境を作ることができます。
アーキテクト(アーキテクチャーを考える人)やアプリケーション開発者を対象に、Azure で実現するクラウドアーキテクチャーについて紹介するセッションを行います。
【取り上げる予定のキーワード】
パブリッククラウド、Microsoft Azure、PaaS、GitHub、コンテナー、CI/CD、サーバーレス、DevOps、NoSQL、開発環境
ソフトウェア開発、色々な場面で人とのコラボレーションを求められがちですよね?
例えば、アジャイル系のフレームワークやプラクティスを採用している・していないに関わらず、ふりかえり(retrospective)を行っているチームは増えてきていると思います。
それ以外にも、チームビルディングの場面だったり、プロダクト開発のためのブレインストーミング、もしくはポストモーテムにおいても参加者それぞれの視点が出揃うことが求められます。
理想的なのは、そこにいる全員が同一の目的を持って主体的な意思表示と議論に参加できている状態です。
そのために、場をファシリテーションする人には「発散」と「収束」を効果的に行うことが求められます。
しかしながら、単純に意見を求めるだけでは達成が困難な事も多いです。その壁を破るためには工夫や知見が必要になります。
どのようにしたら、参加者に思考を促し、高いレベルでのコラボレーションが実現されるでしょうか。
思考を促進するための接し方として、「問いかけ」や「発問」と呼ばれるものがあります。
ファシリテーターが、これらの概念や観点・技法を自らの引き出しに入れておくことで、今までとは少し違った議論が生まれるかも知れません。
本セッションでは、テクニックと態度の両面から「どのように場を回す工夫をするか」を共有します。
現代的な開発において「テスト」は欠かせません。
そして、「ソフトウェアテスト」あるいはその中の「自動化テスト」といっても、それぞれに様々な手法や戦略、ねらいと目的、それらを実現するためのツールなどがあります。
その中でも、普段の開発において、我々のような開発者・プログラマーにとって最もなじみ深いのは「ユニットテスト」ではないでしょうか。
この分野における古典的ともいえる名著の一つに、「xUnit Test Patterns(xUTP)」があります。名前だけは聞いたことがある・・という人も沢山いるかと思います。
一体どんな本なのでしょう?内容が気になるものの・・・気軽に手を出すには、分量的にも価格的にも重い一冊と言えます。
読んだ方が良いぞ!!!と思っていても、未読のままの人も多いのではないでしょうか。
重い本を読むための勢いが欲しいですよね。
まずは、「どんな事が書かれているのか」「(頑張って読むことで)どんな知識を得られそうなのか」という期待値設定のための案内があれば嬉しい・・・と思いませんか?
本セッションは、そんなガイドとなるべく、「xUTPの入り口まで近づいて見てみる」をテーマに話をします。
xUTPが、テストに強くなりたいあなたの味方になるかも知れません!!
コンピューターの処理性能が向上したこと、より大容量で安価なストレージが多く開発されたことにより、大量のデータを活用することが可能になった。
その大量のデータを活用する手段として様々なNoSQLが開発された。
なぜNoSQLが必要なのかを切り口にNoSQLについて色々とお話しします。
・NoSQLとは何なのか。なぜ必要なのか。
・NoSQLにはどのような種類のものがあるのか。
・どういう場面で活用すべきなのか。
プログラミングを始めてから、一定のペースで「プログラミング歴」が伸びています。
最初の1年、暫く経った5年、それすらも超えて10年・・・と時間は流れていきますが、それでも変わらないのは「学び続ける課題がある」という事です。
環境の変化も伴いながら、それでも学び続けるのです。
例えば「後輩や部下に対して指導するようになった」とか「マネジメントの仕事が増えて、業務でコードを書く時間や必要性が減った」など。
学習方法や身につけるべきスキル・知識などは千差万別で、一般化して語ることは難しいですが、「いちヒントとして、どのような姿勢で学びを得ていく事が出来そうか」を本セッションで共有します。
PHPerが Serverless を利用してアプリケーションを構築するときに障壁となっているのが、クラウド側のPHPのサポート状況が不明であることと、使い慣れたPHPフレームワークをどのように Serverless でも利用していくかがよくわかっていないこと、という声をよくいただきます。
PHPを AWS Lambda 上で使う方法についてはWEBで調べれば多くのブログがヒットするものの、情報が溢れており様々なやり方がある中で、何がベストなのかを探っていくのは困難な状況になっています。
このセッションではシンプルに Lambda 上で PHP を動かすところから入って、既存のPHPフレームワークをどのように Lambdaの上に乗せていくかまでをお話ししたいと思います。
<想定聴講者>
以下のモチベーションがあるデベロッパー
<トーク内容>
みなさん、フレームワークや独自実装を用いて、ファイルのアップロードを対応しているプロダクトも多いのではないでしょうか。
実は私は、画像や音楽ファイルを含めたファイルのアップロードが、おそらくプロダクト開発をする上で苦手だなと感じることが多々あります。
「$_FILES を参照するだけでいいじゃん」そう思う人もいると思います。しかし、ファイルのアップロードというのは、より気を使わなければいけないことが多々あります。拡張子だけで、特定のファイル、例えば image.jpg というファイルの中身が png で送られている場合などもあり得ます。これはまだかわいいレベルです。そしてこれよりも悪質なものをアップロードされてくる場合もあり得ます。
以前、PHP を用いたファイルアップローダーサービスを一時的に運営しておりましたが、実装の際に、気をつけていた脆弱性や攻撃などを、フレームワークや独自実装において気をつけるべきアップロードされたファイルへの対応についてお話できればと思います。
『個人情報漏洩』
おそらく多くの方が経験したくないインシデントのひとつでしょう。そんな個人情報漏洩が起こってしまった後、開発者にはどんな影響があるのでしょうか?
これは1人の開発者が個人情報漏洩事件の後に感じた、開発者への影響と心境の変化のおはなしです。
※個人の感想です
※企業の被害や対策内容についてはお話ししません
※PHPのコードが1行も出てこない可能性があります
PHP に新機能を追加したい!そう思ったことはありませんか?
もちろん PHP にはそれを実現してくれる Extension の機構がありますが、"言語として必要な機能だから PHP 本体に入れたいんだ!" ということも...
今回は PHP 8.2 に対する Random Extension 5.x を例として、 PHP に新機能を提案・追加するプロセスについてお話します。
※ このセッションは次のロングセッションのプロポーザルから RFC 周りに焦点を絞った短縮版となります
https://fortee.jp/phpcon-2022/proposal/c39b64af-506c-4b05-996c-bdb6df21ddc6
何かと話題の PHP の疑似乱数生成器。 "壊れたメルセンヌ・ツイスタ" は有名ですが、関数のエイリアス化により発生した問題やモジュロバイアスの問題、
初期シード値の生成に関する問題など、様々な問題を抱えていたのはご存知でしょうか?
今回はそんな PHP の疑似乱数生成に関わるディープなネタを改善の歴史と共に振り返ります。
※ このセッションは次のロングセッションのプロポーザルから乱数周りに焦点を絞った短縮版となります
https://fortee.jp/phpcon-2022/proposal/c39b64af-506c-4b05-996c-bdb6df21ddc6
PHPカンファレンスの初期の頃から続けている初心者向けのセッションです。
ショートセッションでPHPの概要と手元で実行する環境、簡単なコードの紹介をいたします。
PHPのご紹介
PHPを試せる環境
PHPはどんな言語か
このセッションをお聞きいただけるとPHPがどのような言語かを理解することができます
・対象となる方
このセッションではPHPを普段使われていない方、プログラミングを始めて間もない方を対象としています。
・対象とならない方
ご自分でマニュアルを見て環境設定、プログラミングが出来る方は対象外です。
現代のPHPには、既にComposerは欠かせないものになりましたね!
これ1つで、様々な機能やソリューションをもたらしてくれるツールです。
そんな便利なComposer、もっと仲良くなりたいことでしょう。
読んで、把握して、自ら作ってみるのはいかがでしょうか。
PHP自体の機能を利用しないと行けない機能(例えばPHP自体の実行を伴うCommandのフックなど)は難しくても、
「composer.lockを読み込んで(なぜなら純粋なJSONだから!)」「vendorディレクトリにソースを展開する(それってファイルのDLと展開ですよね!)」といった処理くらいならできそうに思いませんか。
やってみましょう!
composer install
の実行する単機能ツールをGoで作成し、その解説
composer.lock
が事前に生成されている事を前提PHP_CodeSniffer(phpcs)は、「コードの書き方に規則を持たせようよ!!」を支援してくれるツールです。
予め定義したルールセットに従って、開発時のローカル環境やCI環境上で「ルールに沿っていないコード」を検出し、指摘してくれます。
また、同梱のphpcbfコマンドを利用することで、簡単な整形を機械的に行うことも可能です。
そんなphpcs、利用中の方も多いと思います。
では、中身はどうなっているのでしょう。どうやってPHPで実現しているのか・・気になりませんか?
「なぜphpcs/phpcbfは動くのか」を実際のコードから紐解いて見ます。
エリック・エヴァンスの『ドメイン駆動設計』日本語版から11年。後発の書籍も多数出版され、各カンファレンスでDDDについて話す人も増えてました。PHPerの中にも実際にDDDで開発する(?)・DDDを実践する(?)人や組織も増えてきたと思います。
約10年前、まだPHPerでDDDを学ぶ人が少なかった頃から、私はPHPメンターズの指導を受けてDDD本を読み、楽しみながら・苦しみながらDDDを意識して開発してきました。コードサンプルを交えながら、実際にやってきた中で学んだこと、世間のDDDに対する言説に対して思うことについてお話しします。
リーダー未経験の私は、現職で働き始めてからの2年間で、初めてProject Leader→Tech Lead→Engineering Managerと任命されることになりました。
「影響力を発揮してね!」とか「リーダーシップを持ってね!」などと言われます。
・・が、一体どうしたら「それらをよく発揮してくれたね!!」と認められるようになるのでしょうか。
自分で道を切り拓いてこそリーダーだ!!という考え方も分かりますが…
マネジメント系のキャリアを目指す人、あるいは運命的にそれに任命された人、今の環境に何らかの物足りなさを感じる人、etc.。
私以外にも、色々なところに「じゃあリーダーシップって何?」に関心を持ったりモヤモヤしている人はいるかと思います。
このセッションでは、
アジャイル(主にScrumやXP)ついて勉強したり、メンバーとの1on1で聞いた声や反響、認定アジャイルリーダーシップ研修Ⅰ(CAL-1)で学んだことを踏まえながら
「(プロダクトの開発組織における)リーダーシップってなんだろう、何を求められているんだろう?」についての自分なりの考えを共有していきます。
「リーダーシップについて駆け出した/駆け出そうとしている人」に向けてのヒントになればと思います。
それらのテーマに向き合うことで、日常の仕事の中においての「自分が何を目指すか」「チームの進化にどう繋ぎ込むか」を探っていきましょう。
クラスに名前をつけるとき、どんな名前をつけていますか?どんな根拠で名前をつけていますか?
Webアプリケーションの寿命が長くなったとき、年月が経っても、メンバーが入れ替わっても、「このクラスはどんな働きをしているか」「この処理はどのクラスにあるか」を見つけやすい状態を保つためには、クラスの名付けはとても重要です。
より良いクラスの名付けをするために役立つ、原則と考え方をお話しします。
Laravel sail を使っている方なら、一回は目にしたことがある Mailhog。他にも MailCatcher といったローカルでメール送信のテストをすることがあるのではないかと思います。
実際にこういった SMTP サーバーの役割を果たすものは使ったことがあるものの、どういう仕組みでメールのやり取りがなされているのか
興味がある方もいらっしゃるかと思います。
そこで、本トークでは SMTP サーバーとしてのプロトコルの解説から、PHP だけで SMTP サーバーを作るにはどうしたらよいのか、テクニックも含めて解説します。
ほぼエンジニアがいない状態からある程度の人数までスケールした組織で、コードの変化や Developer Experience がどのように
変化したのか、時系列で語られることはそうそう多くないです。採用から始まり、プロダクトを作っていく過程で、避けて通れないのが組織の成長です。
少ない人数では上手く機能していたのに、エンジニアが増えた途端、組織が機能しなくなったという話もよく耳にします。
そこで本トークでは、組織規模が大きくなるにつれて、実践した Developer Experience への取り組み、取り組んだ結果、どのように PHP で書かれたプロダクトに影響が及ぼされたのか、ノンフィクションでお話します。