トーク

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

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

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

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

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

とある日に、いつものようにPHP 5.6でmbstringの関数へ引数をarray()にして挙動を楽しんでいました。
同じように当時の PHP 7.3.0 RC5 に対して、挙動を楽しんでいると、
mb_check_encodingのときに、Segfaultになりました。

報告したところ、修正いただきました。

今回は、そのバグをどう見つけて、どう報告したのかということと、
php-src上での問題か、スクリプト上の問題かを切り分ける方法、

そもそもPHPのビルトイン関数へ(わざと|誤って|たまたま)マニュアルにない引数を加えるとどうなるのか、
7.2からmb_check_encodingとmb_convert_encodingにはarrayが使えるようになっていること

などの発見したこと、報告した後の心境を共有させていただきたいなと思います。

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フレームワークはどれだ！

laravelを触ってみたいと思っても、環境構築が面倒くさいと思って挫折した人いませんか？
また本に書いてあるやり方だと実践的ではないと思ってやる気がなくなっちゃった人いませんか？
これ2つとも2018年までの私です。

でもそんな自分でも作ってみて、Laravelの使いやすさ、楽しさが最近ようやくわかってきました。
ぜひ皆様にもLaravelのよさをわかっていただけたらと思います。
そのために環境構築を試してみて、どのやり方がどんな感じでオススメかを紹介できたらと思います。
以下の3つを紹介できたらと思います。

・Laravel 内蔵サーバ
・MAMP(XAMPP)
・Docker

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

HTTPはRPCではなく、RESTはHTTP上のCRUDシステムではありません。RESTはハイパーメディアアフォーダンスという発見性を持ち、進化可能性(evolvability)、スケーラビリティ、自己記述性、といったアプリケーションをパワフルにする力を持ちます。このトークでは、RESTの本来の力がアプリケーションにどのようにパワーとパフォーマンスを与え、アプリケーションアーキテクチャとどう作用できるのかフレームワーク製作者の視点を交えてお話します。

プログラムを書くときに計算量を意識していますか？計算量の基本を理解することで、サービスが成長したときに問題を起こしにくいプログラムを作成することができます。簡単なプログラムを例にして、まず計算量という概念に慣れてみましょう。

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

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

Facebookが公開し、GitHubのAPI v4にも採用されたことでも知られるGraphQL。旧来のRESTfulな形式のAPIを爆発的に置き換えていっている！とは言えませんが最近少しずつ国内でも採用事例を聞くようになりました。
このトークではGraphQLの魅力について話し懇親会で話のネタに出来るくらいに分かった気になるトークをしたいと思います。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

文字をシェアするtwitterから画像をシェアするインスタグラムへとSNS市場は変化し続けています。そして、動画をシェアするSNS TikTok。
そのTikTokを利用してプログラミングを勉強するコンテンツがあると面白いんじゃないかと思っています。
LTではなぜTikTokなのか、ネタ作りの観点などを共有できればと思います。

「抽象」という言葉に抵抗を感じるプログラマは多くいると思います。抽象的＝フワっとしていて理解しづらいという抵抗や、抽象化＝プログラムを分かりづらくするという抵抗など。では、プログラムを書く上で、抽象化は不要なのでしょうか？
この講演では、私達人間にとっての抽象化と、プログラミングにおける抽象化について掘り下げ、プログラミングにおいて役立つ抽象化がどのようなものなのかをお話します。

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

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

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

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