マイクロサービスやCI/CDの実現を目的として検討されることが多いコンテナ技術ですが、本セッションではコンテナを使ったことがない方、またはほとんど知らない方向けに、コンテナそのものの概要に加え、アプリケーション開発者がコンテナを活用することによるメリットや実際の利用についてデモを交えてご紹介します。
いまどきの PHPエンジニアに知ってほしい AWS についての情報をまとめてお届けします!そもそもクラウドとは?といった基本的なところを押さえた上で、あなたの PHPアプリを一味違うものにするための各種サービスを紹介します。
世の中すべてのシステムからポーリング処理を消し去りたい。そんな想いを持った人は少なくないはずです。本セッションでは、Event Sourcing/CQRS といったキーワードを中心にイベント・ドリブンなシステムを実現する上で押さえておくべき概念と、それらと切り離すことのできない結果整合性という考え方について説明します。また、セッション後半では実際に AWS の各種サービスを用いてこれらの概念を実装する方法を紹介します。
最近さまざまな開発コミュニティで「 GraphQL vs REST 」という形で紹介されており、Rest APIの次のパラダイムとして注目されている GraphQL 。AWS AppSync というマネージドサービスを利用することで簡単に GraphQL を使い始めることが可能になります。 スキーマをベースにした設計、Query / Mutation / Subscription のシンプルな利用、クライアントからのレスポンス形式の指定などの特徴があり、チャットアプリのようなリアルタイムアプリケーションを作成するのに非常に力を発揮します。 本セッションは GraphQL 入門セッションという立ち位置で、 GraphQL やそれを簡単に使うための AWS AppSync の使い方を紹介させていただきます。
CI/CD 、コンテナという技術はDevOpsにおいて重要なプラクティスの一つとなっております。
このセッションではコンテナや CI/CD がなぜ重要なのかについて解説していきます。また、具体的にどのようにコンテナ環境でCI/CD を実現していくか、その環境にPHP Appsをデプロイしていくかを紹介させていただきます。
みなさんは GitHub issues を使っていますか?
世の中にタスク管理ツールはあるけれど、結局(GitHubを使ったことのある)エンジニアにとって一番使いやすいのは GitHub issues なのではないのかと個人的には思っています。
このトークでは
「一番便利なのはGitHub issuesではないか」とはいったものの、一番伝えたいのは「プロジェクトの進捗を見える化し、ちゃんと管理していくことはとても大事だよね」ということなので、他のタスク管理ツールを使う方にも参考になるような内容のトークとなるかと思います!
PHPのアプリケーションをどのような環境で動作させているでしょうか?PHP アプリケーションを開発しておわりということはなく、どこかしらの環境にデプロイし安定したアプリケーションを提供しつづけることはどんな環境でも同じです。AWS では PHP アプリケーションを動作させる様々な環境があります。EC2 / Fargate / ECS/ Lambdaなどなど。このセッションは よくあるAWS を使ったPHP アプリケーション構築パターンを紹介し、それぞれのメリットデメリットなどを紹介していきます。このセッションを受けることで、簡単に運用の手間を極力なくした形でのPHPアプリケーションの運用が可能になります。
多くのWebサイトが急速にHTTPS化し、現在日本では70%以上の通信がHTTPSに対応していると言われています。
しかし、安易に設定しただけではセキュアな状態とは言えません。
このセッションでは、HTTPSの歴史を振り返りながら、どのようにすればセキュアになるのかを解説したいと思います。
Hackにはアノテーションとして作用させることができるAttributesという機能が提供されています。
デフォルトではメモ化を表すものや、PHPにはないクラス継承を制限するsealedを付与するものなどがあります。
これはクラスやメソッドはもちろん、引数に対して利用することもできPHPとは全く異なるアプローチが可能で、
独自のアノテーションを実装することもでき、開発時に多用することも少なくありません。
PHPと異なるランタイムと言語機能を持つHackのAttributesに焦点を当てて、
アプリケーションで実践するAttributes活用方法と、マニュアルにはないAttributesを紹介します。
PHPはそれ自体がWebに特化した機能を持つ開発環境ですが、使用方法を誤ると予期せず実行が中断されたり、脆弱性の温床になるようなパターンがいくつもあります。このトークでは時間の許す限りパターンの紹介と解決策の提案を紹介します。 (タイトルの10の進数表記は任意の整数とする)
これまで、AWSのサーバレス実行環境であるLambdaで実行できる言語は限りがあり、場合によっては新たな言語を習得しなければなりませんでした。
しかし、昨年の追加されたLambdaのカスタムランタイム機能により、(ある程度の準備こそ必要ですが)PHPを初めとする自分が今まで使い慣れている言語で開発及び実行できるようになり、より手軽にサーバレス開発が行えるようになりました。
本セッションでは、Lambda+PHPという環境を通じて、
・PHPカスタムランタイムの動かし方や作り方
・どのように動くのか
・どのような用途に向いているのか
といった概要や、各種フレームワークを動かしてみた結果といった調査結果などについてお話します。
昨年度まで登壇経験 0 だった開発組織が、昨夏の PHP カンファレンス関西 2018 を皮切りに、今年度、国内 3 つの PHP 系カンファレンスに社内から延べ 5 名のエンジニアが登壇を果たしました。この発表では今年度の取り組みの総まとめとして、開発組織の思惑とエンジニアとしてのやっていき、業務としてイベント登壇を推進するための取り組み、そしてこれからの目標など、今年度のできごとを余すことなくお話します。この発表が今後社外への発信に取り組んでいきたい開発組織やエンジニア個人にとっての後押しとなれば幸いです。
サービスが成長し機能が追加され、データ量が増大してきたある日、サービスが速度面で劣化してきます。そのような状況ではウェブアプリケーションの処理速度を改善するためのチューニングが求められます。しかし、チューニングの経験がない場合、何をすべきか分からず、効果のない改善作業を繰り返してしまいます。本トークでは実際の例を参考にして、どのようにウェブアプリケーションのチューニングを行っていくべきなのかを丁寧に解説します。
Facebookが公開し、GitHubのAPI v4にも採用されたことでも知られるGraphQL。旧来のRESTfulな形式のAPIを爆発的に置き換えていっている!とは言えませんが最近少しずつ国内でも採用事例を聞くようになりました。
GraphQLとは何なのか?どういった強みがあるのか?ツラミはないの?等について話したいと思います。
先日、AWSのLambdaでPHPがサポートされました!
しかし…ネイティブサポートというわけではなかったですね(残念)まあ、色々な都合はわかる所です、PHPのバージョンが固定されないという意味ではよいですよね!
※ 別に5.4に長いことロックされていた某サービスに文句をいっているわけではない
それはそうとして、発表直後こそ大喜びした私ですが、公開されたコードを読んで少々うーん?と思う所もありました。
「これはたしかにPHPだ、PHP-ismになるようにしてある。でも、こうしなくてもよいのでは…?」
他の言語バインディングなどを確認し、PHPならではの設計となっていることに疑問を覚えた私。「こういうふうにしたほうが良いのでは?」というお話をいたします。
また、普通のウェブアプリを普段書く方向けに、構造(使い方ではない)や「一見微妙に見えるこの実装」がなぜ良いのか(勝手なエスパーで)等をお話してみたいと思います。
注意: このトーク自体がLambdaを使う上で直接的に役立つかというと、多分役立ちません!
PHPにはhttpdがない(諸説あります)
そうすると様々な方法で、Httpd(ApacheやNginx)と付き合っていく必要がありますね、
そのあたりの設定についてコピペで済ませる人が多いですが、それってどうなのっておもいませんか?(えっ、おもわない?)
実は「よく知られている(検索で出てくる)設定はセキュリティ的にまずい」、「あるフレームワークだとなんか動かない」とか、しばしば見かける話だったりします。
様々な設定項目を確認して、それぞれの意味を見直してみませんか?
秘伝のconfからの脱出を図りましょう!
私には「Packagist監視おじさん」として活動する顔があります(自称です)。@call_user_funcというTwitter botで、Packagistに投稿されるパッケージを日々監視しています。
Packagistに日々大量に登録されるライブラリですが、私が最近気になっているパッケージをたくさん紹介いたします!
※100連発とかいてありますが、これは「たくさん」という意味で当日100連発になるかは不明です!
聞いたこともない、みたこともない、日本では知られていない、本当に流行っているとは思っていなかった様々なパッケージに付いてご紹介いたします。
PHPがまた早くなった!そういう話結構多いですよね。僕もぐんぐんと伸びるグラフやベンチを貼って「PHPははやくなった!他の言語に負けていない!」とか言ってみる事もしばしば(?)あります。
でも、そうなのかな?本当にPHPって速いのかな?本当に速かったら、皆がgoとかに民族移動しなくてもよいのでは…?(無論、速い以外の理由もあるのでしょうが…!)
いやいやでも結構PHPも速い(ような気がする)し…。
ということでPHPでよく見る「ベンチの欺瞞」あるいは「現実との乖離」、「先入観」についてかんがえてみませんか。
みなさんPHPでサービス提供していますか?何をつかって提供していますか?
Nginx+php-fpm?h2o+php-cgi?IIS+php-fpm?swoole?builtin server?HHVM?Roadrunner?PHP-pm?いやいや、Apache+mod_phpですよね?あるいは諸般の事情でapache+php-cgiかもしれない。
Apache+mod_phpはいろんな人が「いまどきApacheとかないわ〜」とか「もうそもそも考えてもいなかった」とか言っています。でもどう考えてもApache+mod_phpで8割のケースは十分ですよね??
(勿論、2割のケースにいらっしゃるかもしれません。勿論そうなら泣く泣く(??)Apacheを使わないのは正しい!!)
これらを比較して、mod_phpを見直してみましょう!
弊社はクチコミ掲載数日本最大級を誇る結婚準備クチコミ情報サイトのウエディングパークをはじめ、ブライダル専門の5つのメディアを自社で開発・運営しています(主要技術:PHP/Laravel/MySQL/Goなど)。約1年前にQAチームを立ち上げ、不具合を前年度比で半減させることをミッションに日々活動を行っています。特に2004年から運営するウエディングパークでは、長く運用するWebサービスだからこその課題や悩みが多くありました。その中でQAチームとして取り組んだことから成功したこと・失敗したことなどをリアルにお話しさせて頂きます。