プロポーザル

2017年3月からPaykeという沖縄のスタートアップの3人目のエンジニアとして参加し、モバイルアプリのリードエンジニアとして開発を行っておりましたが、エンジニアの増加やサービスの成長に合わせて、より中長期的な視点でインフラやアプリケーションの改善を行う技術基盤/SREチームを立ち上げました。

技術基盤チームでは「サービスの成長を継続し、そしてさらに加速させる」という視点で、フレームワークのアップデート、PHPのバージョンアップ、ジョブキューシステムの開発、APIのパフォーマンス改善などを取り組んできました。

本セッションではこれらの改善を「なぜやったのか」、「どう取り組んだのか」、「結果どうなったのか」の視点で順を負ってお話することで、皆さんが日々の開発現場で行っている様々な意思決定の参考なるようにしたいと思います。

CPUが好きです。私は中学生の頃にMSXというパソコンを入手し、MSXのCPUであるZ80のマシン語をプログラミング言語として体験していました。

時を経ること25年、2016年にPHPで書かれたゲームボーイエミュレータのコードを読んで衝撃を受けました。ゲームボーイのCPUはZ80をベースに開発されたものであり、ゲームボーイエミュレータのコードで実装されていたのはまさにそのZ80の命令だったのです。

その瞬間、それまで「よくわからないけどすごいプログラム」だと思っていたエミュレータのコードが、ハードウェア仕様をソフトウェア的に表現したものであることが理解できました。

そしてその3年後。名著「CPUの創りかた」で紹介されている4ビットCPU TD4を実装し、そこでまた衝撃を受けました。そこに見たCPUは、プログラミング言語として見たCPU、エミュレータの対象として見たCPUのどちらとも違った、電気回路として表現された状態機械としてのCPUでした。

このトークではミニマムなCPUとしてのTD4を題材に、PHPでそのエミュレータを実装し、プログラミング言語として見たCPU、エミュレータの対象として見たCPU、そして電気回路として表現されたCPUがどの様に動作するのかを解説します。

このトークを通してみなさんがCPUの設計や動作に興味を持ち、いっしょにCPUについて語れることを楽しみにしています！

私は1980年代から1995年頃までのレトロゲーム機が大変好きです。
この頃のゲーム機は各社の工夫でどんどん進化する一方で、技術的な制約によりどのゲーム機でも同じ様な仕様になっているところもあります。

また、それ以前にゲーム機と言えどもそれはコンピュータであり、CPUについては現在のパソコンで使われている様なCPUと同じところもあります。

このセッションでは私が作成したPHPベースのファミコンエミュレータ php-terminal-nes-emulator を題材に、CPUの動作原理やレトロゲーム機に共通する仕様、それをエミュレータとして実装するための設計などをお話します。

そして、エミュレータのコードが「得体の知れない難しいもの」ではなく「ハードウェアの仕様をコードで表現したもの」であり、読んで楽しく、書いてみたくなるものであることをお伝えします！

エミュレータの設計やコードは、Webアプリやフレームワークのそれと違った特長を持っています。エミュレータのコードは、一言で言えばハードウェアの仕様をコードで表現した「Hardware specifications as Code」なのです。

このトークでは私がPHPで書いたファミコンエミュレータ php-terminal-nes-emulator を題材に、エミュレータのコードの特長や設計と、ファミコンエミュレータならではの実装について解説し、エミュレータのコードが「得体の知れない難しいもの」ではなく読んで楽しく、書いてみたくなるものであることをお伝えします！

• コンピュータのCPUはどの様に動作しているか
• CPUはメモリやビデオチップとどの様に情報をやりとりしているか
• CPUをエミュレートするとはどういうことか

「ファミコンエミュレータを作る」と聞いて何を思い浮かべますか？
多くの方は何をどうしたら良いのか全く想像が付かないと思いますし、私もそうでした。

2016年2月にPHPで書かれたゲームボーイエミュレータ php-terminal-gameboy-emulator が話題になりました。このとき、PHPならばということでコードを読んでみました。エミュレータのコードを読んだのは初めての経験だったのですが、大きな衝撃を受けました。それ以前からCPUやメモリ、この頃のゲーム機に共通する仕様のことは知っていたのですが、php-terminal-gameboy-emulator のコードに見たものはその仕様がそのままPHPのコードとして表現されたものだったのです！

そしてその2年後、あるカンファレンスでファミコンエミュレータに関するトークを聞いた時に、2度目の衝撃が私を襲いました。そこで紹介されたコードはその場で初めて見るにもかかわらず、断片を見るだけで内容が理解できたのです。

このトークでは2度目の衝撃を受けて私がPHPで書いたファミコンエミュレータ php-terminal-nes-emulator を題材に、エミュレータのコードの特長や設計、そしてその魅力をお伝えします。

• エミュレータでのCPU実装例
• ハードウェア仕様のソフトウェアとしての表現

エミュレータは決して難しいものではなく新しい言語の学習や設計の練習にちょうどよいテーマでもあります。このトークを聞けばきっと一度エミュレータを書いてみたくなるでしょう。

ファミコンの画面は8x8ピクセルで定義されたキャラクタを敷き詰めた画像（BG）の上に8x8ピクセルで定義されたキャラクタ（スプライト）を重ねて描画されています。その名の通り、多くの場合ゲームの背景をBGで、ゲームの主人公や敵キャラをスプライトで表現することになります。

この「BGとスプライトでゲーム画面を描画する」という設計はファミコンに限らず、PCエンジン, ゲームボーイ, メガドライブ等々、PlayStationより前のゲーム機に共通する設計でした。
すでに発売されているゲーム機より高い性能、より良い表現を求められるであろうゲーム機の設計においてなぜ画面描画に関する設計は共通になっているのでしょうか。それには当時の技術的な制約、出力先である家庭用テレビの仕様が影響していました。

このトークでは私がPHPで書いたファミコンエミュレータ php-terminal-nes-emulator を題材に、ファミコンの画面描画の仕組みや、画面描画をエミュレータでどの様に設計・実装しているのかを解説します。
そして、このトークを通してエミュレータのコードが「得体の知れない難しいもの」ではなく読んで楽しく、書いてみたくなるものであることをお伝えします！

PSR(PHP Standards Recommendations)とはPHP-FIG(PHP Framework Interop Group )が策定しているPHPコーディング規約の事を指します。PSRで策定されている内容としては、コーディングスタイル、オートローディング規約、インターフェイスがメインになっていますが、我々PHPerがPHPでコードを書く時にPSRをどこまで意識すれば良いのか?或いはどのような時にPSRの規約を準拠してコーディングをすれば良いのか?について、現在策定されているPSRの紹介や、実際会社で導入している事例を含めて発表をしようと思います。

「クリーンアーキテクチャ」聞いたことはありますでしょうか？私自身はドメイン駆動設計に興味を持ち始め色々調べていた時にクリーンアーキテクチャをはじめて知ったと記憶していますが、最初は、Web上のクリーンアーキテクチャの記事やクリーンアーキテクチャの本を読んでも私はまったくと言っていいほどその内容を理解できませんでした。

そんな状態の私がクリーンアーキテクチャをうっすらとでも読み解くことができるようになったのは、「依存の方向」と「処理の流れ」を理解できたことが出発点だと思っています。

クリーンアーキテクチャを学びはじめたけれどもよくわからない・・・というように挫折を感じている方がいるかもしれませんが、この「依存の方向」と「処理の流れ」を意識することができればクリーンアーキテクチャの理解の助けになると確信しています。

「→」(依存の方向の矢印)に惑わされた私がどんなように「依存の方向」と「処理の流れ」について理解しているかを、DIPやDIにも軽く触れながらお話しすることで、このセッションがクリーンアーキテクチャを理解するための一助となれば幸いです。

「PHP、なんか分かり辛くね？」
それが、初めてPHPに触れた素直な感想でした。

「PHPは初学者にも分かりやすいよ」と言われています。
これまでJavaとPythonとを勉強していた身としては「まあ大丈夫かな？」と思って初仕事に臨んだのですが、
見事に裏切られました。

・<?php の閉じタグしないの？ 何で？
・この変数についてる$って何？
・-> と => なんで両方使うん...
などなど...

今回の登壇では上記に限らず、PHP初学者（＝私）が行き詰まったポイントを列挙していきます。
なおPHPだけでなく、Laravel、設計の話も含みます。

初学者の方はこれから行き詰まることのないよう、経験者の方は後輩に教えるために、ぜひお聞きください！

スタートアップのサービスが順調に成長していくと、DBの負荷問題に悩まされることが多くなります。
その主な要因として「アクセスの増加」「データ量の増加」「DB負荷がかかる処理の増加」などが挙げられます。
DB負荷問題はSREの中で最も重要で、常に闘っていかないといけないテーマだと考えています。
日々のSRE業務で行ってきた、DB負荷問題の対策についてCakePHPを事例に紹介いたします。

CakePHP4のリリースが間近になってきました。
CakePHP2のサポートはCakePHP4リリース後18か月間となっているため、それまでにバージョンアップする必要がありますが、未だに多くのCakePHP2のシステムがバージョンアップできずにいます。
CakePHP3からは、ORMの返り値がオブジェクトになることをはじめ、大きな変更が行われているため、バージョンアップには困難が伴います。
ランサーズでは、CakePHP2のバージョンアップに着手しました。
CakePHP1.3→2.8へのバージョンアップはコントローラー単位で1年以上かけて徐々に移行しましたが、これを応用し、CakePHP2.8とCakePHP3or4を共存させながら徐々にバージョンアップさせる方法を紹介いたします。

みなさんの開発環境は現在どんな感じでしょうか？
今風だとDockerなどのコンテナを駆使して開発環境を構築するのがモダンなのかな？いやいやVagrantもまだまだ健在！漢は黙ってXAMPP！！など皆様の開発環境はまだまだ様々なのかな？と思っています。

我々は6年前の2つのバージョンのXAMPPを使った開発環境の時代から今現在はDockerを使った開発環境のように大きく開発環境を変化させてきました。

開発環境を改善するの正直とても大変でしたが、トライ&エラーを繰り返しながらチーム全体に取り入れられたことで、それによるメリットもたくさん得られたと思っています。

我々がどんな方法で開発環境の改善を進めてチームに浸透させてきたか？最終的にどのような環境になったのか？といった私やチーム全体で取り組み、変化を起こしてきたことをお伝えすることで、お聞きいただいたみなさまの現場における開発環境改善のヒントになれば幸いです。

Swoole is a production-grade async framework for PHP. It makes high concurrency possible for PHP in coroutine pattern like Go lang. The combination of PHP and Swoole can improve the performance of your PHP projects significantly.

What's more, not only web, developers can also build TCP/UDP server with Swoole easily. This talk will walk you through the lifecycle, server structure, coroutine and use cases of Swoole.

結婚や子育て、起業、留学などの局面でお金があると選択肢が増えます。PHPerの収入調査データとどうすれば稼げるのかを提案します。

サーバーレスは一般的な技術になりつつあります。

それに伴い私達PHPerが選択出来るサーバーレスバックエンドは進化し続けています。
各種クラウドベンダーが提供するランタイムの利用、コンテナの利用等、
各サーバーレスの環境の利用方法と比較を行います。

• お話すること
  　- Serverlessの魅力
  　- PHPにおけるServerless環境の選択肢
  　- 各Serverless環境の比較

• 利用する技術
  　- コンテナ
  　- 各種クラウドベンダー提供のServerless環境
  　　- AWS Lambda
  　　- AWS Fargate
  　　- GAE
  　　- Knative on GKE
  　　- Cloud Run

実際の開発経験の話を交えながら、Laravelでの設計のベスト・プラクティスについて考察・提案します。話すトピックの候補は以下の感じです。

• Serviceクラス
• Repositoryパターン
• 例外処理のハンドリングをする場所のベストプラクティスは？
• 関数の命名について
• 開発経験時のよかった設計や悪かった設計の話

最近、設計に対する関心高まりを感じています。
その一方で「名前は聞いたことあるけど、敷居が高そう......」「本は読んだけど実際に実装するイメージがつかない......」と感じている方もいらっしゃるのではないでしょうか？
本セッションでは設計に関するテーマとして「クリーンアーキテクチャ」を扱い、セッション前半ではクリーンアーキテクチャのコアとなる考え方を説明します。
後半では「フレームワーク非依存」を謳うクリーンアーキテクチャの考え方を、Laravel のプロジェクトに適用する方法を提案します。
※本セッションは、PHP カンファレンス福岡 2019 でお話した「Laravel でやってみるクリーンアーキテクチャ」を再編した内容になります。

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

総合認証プラットフォームAuth0を用いて、Laravel + Nuxt.jsで簡単に複数のSNS認証機能を実装した話をします。 Auth0はWebアプリやモバイル、APIなどに対して認証・認可のサービスをクラウドで提供している、いわゆるIDaaS (Identity as a Service)ベンダーです。

■対象
プログラミング初心者・中級者

■概要

1. もし、間違った認識でプログラムを書いたら？
2. 正しいと嬉しいことは？(完成が早くなる等)
3. 手法: 日本語を書いてから、プログラムに翻訳する
4. 手法: アンチパターン・登場人物の洗い出し
5. 抽象化・命名・設計は、全て『正しい意味』が重要
6. 『間違えた意味』で設計した場合は？(分離していなかった時の恐怖)

1.『ボタンをクリックしたら、このページのclassがspecial_itemsのパーツの色を変えてほしい』
2.『それはこの画面の上から4番目のパーツだ』

こう言われたとき、あなたはどんなプログラムを書きますか？

1. 対象のclassのパーツの色を変える
2. 上から4番目のパーツの色を変える

どちらも、正しく動くでしょう。・・・今は。
もし、一番上に新しいパーツが追加されたら・・・？

プログラムは言語です。『本当にやりたいこと』を正しく理解して、そのとおりにプログラムを書かなければ、簡単にバグは発生します。

1+1も、4-2も、結果は一緒なのでプログラムは正しく動きます。
しかし、仕様変更や他のプログラムを合体させると動かなくなり、再修正の時間が発生することがあります。

『正しく意味を理解して、それをプログラミング言語に落とし込む』
バグを減らし、変更に耐えやすくなり、再修正も減って、最終的に開発が早くなります。