スタートアップ企業が自社サービスを開発するにあたって、
Laravel、Nuxt.js、Firebaseを使用し、開発コストとエンジニアのDX(Development Experience)も意識し、
SPA(Single Page Application)開発を実現した話をします。
技術的な面では、Laravelとどのように組み合わせて、全体のプロダクト設計したのか、
API設計、認証周り(JWT、SNS認証など)の工夫点などをお話します。
開発体制で工夫した点としては、Nuxt.js、Firebase、cypress(e2eテスト)、
GitlabCIなどの技術を採用する事によるDXの向上。
新しい技術を採用する中で、開発コストとのバランスを上手く調整した点。
スクラム開発による開発の効率化、チームの開発スピードの可視化などです。

【3年ぶりくらいのスピーカー応募】
Swooleで非同期処理
JS遅延読み込み
Webp自動変換で遅いサイトを早くする的な話

近年、マイクロサービスの流行とともにプロトコルとして
gRPCが使われるのをよく目にします
PHPでgRPCを使おうと思ったとき、他の言語できるけれど
PHPでできないことはあるでしょうか？
Swooleを用いて、gRPCサーバを検証してみました

PHPの開発でコーディング規約をどうするかはどの現場でも悩ましい話だと思います。
キャメルケースにする / スネークケースにする、などある程度の選択は個々に必要になるものの、
PHP-CS-Fixerに整形を委ねるのも１つの手ではないかと思います。

現在自分が所属している開発プロジェクトではPHP-CS-Fixerを利用しているので、
利用中の課題点と自分が感じた「クセ」について、簡単にお話しできればと思います。

大規模なカンファレンスでの「初めてのスピーカー」にチャレンジさせていただければ幸いです。

私の携わっているプロジェクトにはテストがありません。
それにより、画面変更時に、人手でページを1ページずつアクセスして確認する必要がありました。
その確認作業はエンジニアにとっては苦痛です。
そこでビジュアルリグレッションテストを導入しました。
導入によって得られた知見を話したいと思います。

※ 大規模カンファレンスでは初めてのスピーカーとなります。

AWS Lambda Custom Runtimes が利用できる様になって随分たちました。

我々PHPerとしては、張り切ってPHP on AWS Lambda するしかありません。

AWS LambdaにおけるPHPのパフォーマンスと利便性を時間が許す限りトークします。

• お話すること
  　- PHP on AWS Lambda
  　　- パフォーマンス
  　　- 利便性

• 利用する技術
  　- AWS Lambda

社会人になってほぼ初めてPHPを触ることになりました。PHPerになって2年目のエンジニアがPHPをもっと使いこなして、エンジニア力をあげるために、PHPで競プロ(atcoderの過去問)にチャレンジ！

会社でコードを書いていて、まだあまり意識できていない部分、競プロを利用して学べる部分があるのか検証します。
大規模カンファレンスで話すのは初めてですが、よろしくおねがいします！

タイトルどおりですが、中途半端に「設計をする」という文化を浸透するためのやり方に不具合が生じるとチームが思わぬ方向へと向かうこともしばしば。
今回はそんな失敗した一例と解決した方法について、簡単に発表できればと思います。

既存サービスの運用を行っていると、本腰をあげてリファクタリングをしない限り根本の設計はずっとそのままです。
運用がメインで、しっかりとした設計（例えばDDDやクリーンアーキテクチャなど）の実務経験がほとんどない中、新規サービスを開発することになりました。
せっかくならより良い設計のサービスにしようと思い立ち、未経験で奥深い「設計」の世界にチームメンバーも巻き込みながら挑戦してみました。

■対象の人

1. アウトプット続かない
2. アウトプットの良さわからない
3. アウトプットで何かが変わる未来が見えない

■内容

1. アウトプットって本当に意味あるの？
2. 『あなた』はアウトプット『すべきか』
3. 私が本当に起こったこと
4. アウトプットはいいぞ

私はもともと『落ちこぼれ』でした。自分に全く自信がありませんでした。
そんな私が、今Conferenceで登壇したり、勉強会でLTをしたりしています。

『エンジニアがアウトプットしろというの意味わかんない』
『アウトプットとか絶対続かない』

いやいや、エンジニアこそやると良いと思います。
一年間で生活が大きく変わった私から、私の思いを話したいと思います。

一歩先のエンジニアになるために、アウトプットしませんか？(beyondのテーマ回収)

ユーザーに素早く価値を届けること、より良いコードを追求すること、ビジネスに向き合うこと。
仕事としてコーディングをする上でどれも大事なことです。
しかし、精神的・物理的な"余裕"が無いためにそれらを犠牲にせざるを得なかった経験はないでしょうか。

本セッションでは、開発プロセスの中の"コードレビュー"に焦点をあてて、
手戻りをなくしつつ、より本質的な作業に時間を使えるようにするために
私が実務で実践してきた"余裕"を生み出すtipsをご紹介します。

tips

• 未来の読者のためのコメント
• "既存コード" の 歴史的経緯を素早く紐解く
• コードレビューだけで100点を目指さない
• 単純な作業は機械に任せる
• コードレビューの内と外でレビュイーと対話する
• コードレビューが自分を成長させてくれる
  ...etc

レガシーシステムの開発中に訪れるPHPのEOL。バージョンアップ後は全機能テストが待っています。
既存のテスト仕様書では重要機能を網羅していない、書かれている単体テストは重要機能をテストしていない・・・
このような状況でユニットテストを書くためには、問題の分割と、テストで担保したいこと(目的)の設定が重要です。
18年にわたって運用されているシステムに対して、PHPUnitと、PHPの挙動を操作するuopzという拡張を利用してテストをどのように行ったのかをご紹介します。

このトークは、Hamee株式会社の提供でお送りします。

みなさんは開発合宿に参加されたことはありますか？

Hameeの開発部では、毎年開発合宿を開いており、はや5年になります。
エンジニアでありながらも、基本的にPCを持ち込みません！
弊社のビジョン「クリエイティブ魂に火をつける」ためにどういう合宿をしているのか？お話したいと思います。

もし、開発合宿に興味を持っている方がいれば、
Hameeは神奈川県の端、開発合宿がよく行われる湯河原や箱根の近くの「小田原」にありますので、是非弊社に立ち寄ってみませんか？