トーク

これまで、AWSのサーバレス実行環境であるLambdaで実行できる言語は限りがあり、場合によっては新たな言語を習得しなければなりませんでした。
しかし、昨年の追加されたLambdaのカスタムランタイム機能により、(ある程度の準備こそ必要ですが)PHPを初めとする自分が今まで使い慣れている言語で開発及び実行できるようになり、より手軽にサーバレス開発が行えるようになりました。
本セッションでは、Lambda+PHPという環境を通じて、
・PHPカスタムランタイムの動かし方や作り方
・どのように動くのか
・どのような用途に向いているのか
といった概要や、各種フレームワークを動かしてみた結果といった調査結果などについてお話します。

PHPStanは優秀な静的解析ライブラリではありますが、あらかじめ提供されているRuleの利用に留まってはいませんでしょうか？
同ライブラリにはCustomRuleという独自のルールを作成できる機能があります。

自分でルールを書けば外部のツールと連携したチェックなども可能で、例えばGitと連携させることで新しく追加されたクラスのみチェックして「これから新しく作るクラスは戻り値型宣言必ず書いて！」みたいな複雑なルールも作れます。

CustomRuleはあまりドキュメントに記述は無いので、基本的に自分で既存のコードを調べて作る必要があり少し面倒です。
今回は「こんなのだったらすぐ出来る」みたいなPHPStanの解析機能を列挙することでみなさんに独自ルールを作ることの一助になれればと思います。

設計への意識の高まりとともに、クラスの依存関係をコントロールすることに関心を持つエンジニアが増えてきましたが、現状依存ルールを順守するには人間の目で確認せざるを得ません。
クラスの依存関係を人間の目で一瞥するのは基本的に難しく、うっかり循環依存になってしまってないかレビューするのも手間です。

そこでPHPStanをベースに依存関係を解析するライブラリを作成しました。
これによりルールの順守を機械的にチェックすることが可能になるほか、そのリポジトリの依存ルールを設定ファイルとして管理し、ルールを明示することができるようになります。

また全クラスの依存関係を解析してグラフ化することも可能（予定）ですので、初めて見るリポジトリを解析する時にその依存関係から大まかな構造を把握できるような使い道もあります。

今回はこのライブラリの紹介をさせていただければと思います。

毎日のルーチン作業、忘れがちになっていませんか？
月末になって慌ててやっつけていませんか？
そんな課題を、私たちのチームではチャットボットで解決しています。
アイディア的には単純なリマインドボットですが、Docker や Kong を用いたマイクロサービスに仕上がりました。
今ではボットの主であるフリ●ザ様が、毎朝作業忘れを通知してくださいます。
チームに欠かせない、遊び心満載のチャットボットをご紹介します。

転職の関係で、３・４年モダンなWebアプリ開発から離れていた人が
ごりごりのWebアプリ開発が恋しくなり、CakePHPとJavaScriptを使った
他社さんの開発をお手伝いさせていただけることに・・・！

この経験を経て、CakePHPとJavaScriptをメインに、
どういった所に技術的な難しさを感じているかと
副業はじめて良かったぞって話をします。

昨年度まで登壇経験 0 だった開発組織が、昨夏の PHP カンファレンス関西 2018 を皮切りに、今年度、国内 3 つの PHP 系カンファレンスに社内から延べ 5 名のエンジニアが登壇を果たしました。この発表では今年度の取り組みの総まとめとして、開発組織の思惑とエンジニアとしてのやっていき、業務としてイベント登壇を推進するための取り組み、そしてこれからの目標など、今年度のできごとを余すことなくお話します。この発表が今後社外への発信に取り組んでいきたい開発組織やエンジニア個人にとっての後押しとなれば幸いです。

昨年度まで登壇経験 0 だった開発組織が、昨夏の PHP カンファレンス関西 2018 を皮切りに、今年度、国内 3 つの PHP 系カンファレンスに社内から延べ 5 名のエンジニアが登壇を果たしました。この発表では今年度の取り組みの総まとめとして、開発組織の思惑とエンジニアとしてのやっていき、業務としてイベント登壇を推進するための取り組み、そしてこれからの目標など、今年度のできごとを余すことなくお話します。この発表が今後社外への発信に取り組んでいきたい開発組織やエンジニア個人にとっての後押しとなれば幸いです。

uzullaさんのPHPerKaigi2018「大統一PHP」（https://speakerdeck.com/uzulla/da-tong-php）で紹介されているSwooleという非同期かつ、Coroutineの仕組みをもったPHPのextensionがあります。
Swooleを用いたフレームワークはいくつかあります。
今回、EasySwoole(v2,v3)、Swoft、Laravel-Swooleの３つの比べてみた結果をお話しします。
それぞれのフレームワークのISUCON8予選のベンチマークの結果をお伝えします（恒例）
No.1 Swooleフレームワークはどれだ！

サービスが成長し機能が追加され、データ量が増大してきたある日、サービスが速度面で劣化してきます。そのような状況ではウェブアプリケーションの処理速度を改善するためのチューニングが求められます。しかし、チューニングの経験がない場合、何をすべきか分からず、効果のない改善作業を繰り返してしまいます。本トークでは実際の例を参考にして、どのようにウェブアプリケーションのチューニングを行っていくべきなのかを丁寧に解説します。

PHPでSocketを使ったネットワークプログラミングを自作すると、Unix系OSの非同期IO・ブロッキングIOについて理解が深まります。PHPでブロッキング、ノンブロッキングなWebサーバを書いて、Webサーバへの理解を深めましょう。

コマンドラインPHPを使っていますか？バッチ実行だけではなく便利な使い方がたくさんあるんです。小技を憶えてライバルに差をつけましょう。

Facebookが公開し、GitHubのAPI v4にも採用されたことでも知られるGraphQL。旧来のRESTfulな形式のAPIを爆発的に置き換えていっている！とは言えませんが最近少しずつ国内でも採用事例を聞くようになりました。
GraphQLとは何なのか？どういった強みがあるのか？ツラミはないの？等について話したいと思います。

APIを開発する際にSwaggerなどを用いてAPIドキュメントを書くことも多いかと思います

ですが、放置するとすぐにドキュメントは腐っていき、APIとドキュメントの内容に差異がでます

腐ってしまったドキュメントはときにドキュメントが存在しないことより厄介です

では、どうやってドキュメントの内容を担保するべきでしょうか？

このLTではBEAR.SundayにおけるAPIドキュメントと整合性の担保についてお話します

社内ベンチャーやスタートアップでは少ない人的リソースで高速にプロダクトを開発していくのが重要です

しかしながら、大きなピボットや急な仕様変更の可能性も高く、こういった状況でのAPI開発は様々な課題があらわれます

• 大きなピボットや急な仕様変更の可能性を踏まえて、どういう設計にするべきか
• アプリエンジニアとスムーズに連携するにはどうすればいいのか
• なにを大事にして、なにを後回しにするのか

このセッションでは上記の課題にどういう解決策を考え、BEAR.Sundayでどういったかたちで解決していったのか

そして、少し珍しいフレームワークであるBEAR.Sundayでの実務例をご紹介いたします

エンジニアとして入社して約1年が経ちました！
私は15年目になる老舗メディアに配属されましたが，その中でサイトが多くの技術的負債を抱えていることを知りました．
技術的負債は，障害発生率を高めるだけでなく，余計な工数を発生させることが多いため，システム的な課題として早期の解決が求められます．

しかし，これらの負債はKPIには直結せず，ビジネス的な優先度が低いため，見送られることが多いという性質を持っています．
このような状況下では，技術的負債はたまる一途を辿ります．

「そうは言っても... 返済していかないと，いつか取り返しのつかないことになる...」
そう考えた私は，新卒1年目ではあるものの，社内に負債返済の文化を作るために動くことにしました．

このトークでは，負債返済の文化づくりの第一歩として，企画・開催した負債返済の社内イベントについてお話したいと思います．

「リーダブルコードさえ書けば, 爆速で開発さえできれば評価される, Code wins arguments...」
こんなイケイケエンジニアになれることを妄想して入社してから約1年が経ちましたが,
この中で学んだのは, キレイなコードを書くことだけがエンジニアの仕事じゃないということです．

このトークでは, がむしゃらに1年間働く中で学んだ, エンジニアとして "本当に評価される" ために理解・実行すべきだと思ったことをお話します．

いわゆる技術の学び方・リーダブルコードの書き方等の技術の話ではなく,
エンジニアが苦手になりがちな「コミュニケーション・マインド・行動」について詳しく触れる予定です．

先日、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でよく見る「ベンチの欺瞞」あるいは「現実との乖離」、「先入観」についてかんがえてみませんか。