トーク

便利メソッドが豊富で、高速に開発を行いたい時にももってこいなPHP！
しかし、アンチパターンを踏んでしまうとチームメンバーが入れ替わった際などの、技術的負債を大きく残してしまいます。

本LTでは、今までチーム開発を行う中で「ここ辛いよね」と話題に上がったパターンを、なぜ辛かったのかと共に紹介します。
また、それらの回避策も合わせてお話しします。

皆さんはテストを書いていますか？
テスト駆動開発をしていますか？

テスト駆動開発と言っても、どの部品の単位でテストを書けば良いか悩む方も多いのではないでしょうか。
テストを書く上ではソフトウェア設計への配慮が欠かせません。

ソフトウェア設計の大切さ、テスト駆動開発で単体テストを書く利点について理解を深め、その後にオニオンアーキテクチャを採用したソフトウェアでテスト駆動を行う手順を語っていきます。

当セッションでは下記のような話をする予定です。
・なぜテストを書く上でソフトウェア設計が大切なのか
・単体テストを書く利点
・オニオンアーキテクチャの解説
・オニオンアーキテクチャでTDDを行う手順

※アーキテクチャは触りだけ説明し、メインはテストの話になります

Track ID: Track4-3-A
Discord Channel: #track4-3-a-laravel-onion

昨年、最低限の機能でリリースとなった新サービス。
今も開発が続いているのですが、機能追加をリリースするたびに何かしらトラブルが発生してしまい、切り戻して終わる、ということが頻発していました。
この状況をなんとかしようと思い、足りてない施策をいくつか始めていきました。
Unit Test の自動化、PSR-4 チェック、そして、Laravel Dusk での Browser Test。
このセッションでは、開発から本番へ進む際にめぐりあった数々のトラブルをどう乗り越えて来たのか、と、
量産体制に入ることができている Laravel Dusk の Test 整備方法の一例を、デモを交えてご紹介できればと思います。

Track ID: Track4-4-A
Discord Channel: #track4-4-a-laravel-dusk

30年以上前に作られたDNSの仕組みが今もなお同じように動作し、私たちのインターネットを支えている。2020年、令和の時代に熱いDNSの話をして、インターネットの基礎を支える技術に興味を持ってもらいたい。

DNSレジストラの脆弱性によりドメインハイジャック事件が起こりました。この事象を防ぐのは難しく、いかに早く改ざんを検知するかにかかっています。
そこでDNSのネームサーバ情報を定期的にチェックして改ざんを検知し、通知するツールを作成してOSSで公開しました。
https://github.com/ichikaway/nschecker

本セッションでは、DNS改ざんによるドメインハイジャック、DNSの基本的な仕組み、検知方法、キャッシュとの戦いを紹介し、DNSプロトコルの実装を解説します。
基本的にDNSパケットはUDP 512バイトでやりとりされ、その制約から1bit単位で意味を持つようになっています。この意味を解説しながら、先人たちが1ビットまで大切にしてきた想い、考え抜かれた仕組みを紹介します。

普段の開発では知らなくても動いているDNSですが、DNSキャッシュや権威サーバのツリー構成など知っておくとトラブルシューティングやサイト移転時に役立ったりします。

Track ID: Track3-4-A
Discord Channel: #track3-4-a-dns-packet

Functional Programming is a programming paradigm that has, since its inception, gradually pervaded through the realm of programming. After all, in theory, it holds that any entity capable of simulating a Turing Machine is Functional Programming-affable. PHP is not outside the parameters of Functional Programming and is, in fact, eligible for the paradigm despite appearing to be ill-equipped for such a purpose.

Functional Programming, though currently in the zeitgeist, has a parlance whose perceived complexity poses some trouble in understanding its cornerstone principles. My talk, titled Functional Programming in PHP, is another in a long line of trials at effectively distilling Functional Programming knowledge for PHP audiences. I will, in the time afforded to me, attempt to discuss the foundations of the paradigm, its relevance and history, PHP's aptness for FP, technical hallmarks - immutability, composition, referential transparency, and function purity - as well as applicable meta concepts like Functors and Monads for building real-world applications.

Track ID: Track6-6
Discord Channel: #track6-6-functional-programming-php

Laravel Artisan コマンドの突然の Segmentation fault。他に出力は無かった。

手がかりが無い中、core dump さえ吐ければセグフォ対応は出来るという情報だけを覚えていた。
core dump といえば gdb。gdb といえばバイナリの再コンパイル。茨の道に決まってる。
実際には再コンパイルしなくても 1. gdb コマンド、2. core dumpファイル、3. Segmentation fault を吐いたバイナリ、の三種のパーツが揃えばデバッグ可能であった。

PHPerとしてはややハードルの高いツールたちを使って問題解決にこぎつけた方法を共有します。

プログラミング覚えたての時、電卓を作るといったことをした方や、今現在プログラミングを学習中で電卓を作っている方もいらっしゃるかと思います。
電卓を作るといえば「1+1」と入力したら単純に「2」が出力されるイメージでしょうか。作っているうちに、「あれ？「((1 + 2) × 3)-((1 + 2) × 3)」みたいな式はどうするんだ？」と疑問に思った方も少なくないと思います。そこで本トークでは3分間という短い時間で、複雑な式を計算できる、もう一段階上の電卓を作る方法についてお話します。

弊社のシステムはバックエンドのフレームワークは Laravel を使用、そして OpenAPI と呼ばれる API の設計書を書けば CRUD に対応した API が自動的に実装されるような仕組みを用いて自動生成し、最後にバリデーションを書けば、一つの API が完成します。
もともと弊社の社内システムは SaaS 上にしかなかった、かつバックエンドエンジニアが私一人である中で、どう効率的にゼロベースからプロダクトを組み上げてプロダクトのローンチを早められるかが鍵でした。
CRUD に対応した API 実装、正常系・異常系テストの生成自動化、API のドキュメントの記述、全文検索エンジンへどう自動的に繋ぎこむか、例外処理はどうするか？といった全ての事情を汲み取りながら基盤開発に邁進し、
今では一つあたりの API の実装は 10 分もかからないレベルになりました。本トークでは、この基盤の構築をした経験を元に、考えてきた事、実行してきたこと、判断に迷ったこと、そして Laravel を使った実装についてのお話をできればと思います。

弊社のシステムはバックエンドのフレームワークは Laravel を使用、そして OpenAPI と呼ばれる API の設計書を書けば CRUD に対応した API が自動的に実装されるような仕組みを用いて自動生成し、最後にバリデーションを書けば、一つの API が完成します。
もともと弊社の社内システムは SaaS 上にしかなかった、かつバックエンドエンジニアが私一人である中で、どう効率的にゼロベースからプロダクトを組み上げてプロダクトのローンチを早められるかが鍵でした。
CRUD に対応した API 実装、正常系・異常系テストの生成自動化、API のドキュメントの記述、全文検索エンジンへどう自動的に繋ぎこむか、例外処理はどうするか？といった全ての事情を汲み取りながら基盤開発に邁進し、
今では一つあたりの API の実装は 10 分もかからないレベルになりました。本トークでは、この基盤の構築をした経験を元に、考えてきた事、実行してきたこと、判断に迷ったこと、そして Laravel を使った実装についてのお話をできればと思います。

Track ID: Track4-2
Discord Channel: #track4-2-laravel-openapi

弊社にはプロダクト開発部というものがありませんでした。物流のオペレーションは全て SaaS のシステム一つのみ。そのシステムを内製化するため
プロダクト開発部のチームをゼロから設計し、今ではエンジニア 3 名、デザイナー 1 名の小さいですがチームが組み上がってきました。
チームを組み上げていくにあたって大切にしてきたこと、そしてチームにおける技術の価値観の定義についてお話できればと思います。

弊社では顧客管理システムを SaaS で管理していたのですが業務要件が拡大するにつれて SaaS が提供している API のコールが頻繁に発生し Rate Limit になってしまったり、顧客 1 人の詳細を開くのに
5 秒以上かかる、そしてシステムがスケールできないといった課題がありました。その課題を解決するための一歩として顧客管理システムの内製化をはじめました。
本トークでは、どのように内製化を進めていき、そして稼働するまでの軌跡をお話できればと思っています。

PHPや他の言語とも親和性も高くスケーラブルな検索エンジンのElasticsearchを活用し、
現代のWebアプリケーションでは必要不可欠なユーザーに対するレコメンデーションを実現することができます。
今回は実例を交え、その仕組みと大規模なアプリケーションでも対応可能なアーキテクチャ、
ミドルウェアの組み合わせも交え、PHPなどの言語でそれらを如何に実現するか、
機械学習の入門や、簡単にレコメンデーションを実現したい方すべての方へヒントになる様に詳解します。

Laravelで運用しているサービスをNuxt.jsにリプレイスした（している）状況を共有したいと思います。
Laravelで使われているロジックはそのままに、LaravelをREST APIとして稼働させてNuxt.jsでフロントエンドを構築しています。
サービスを無停止で移行する方法やインフラアーキテクチャ、苦労していることなどを共有して似たようなことを検討している人の助けになればと思います。

Track ID: Track4-1-A
Discord Channel: #track4-1-a-laravel-to-nuxt

人生においてお金があることで選択肢が増えることがあります。磨いてきた技術力を何らかの対価に変える方法の一つに企画があります。このコーナーではペチパー向けにできるだけ多くの実例をもとにした、採用される企画書の書き方をご説明します。また、より深く知りたい方向けに抽選で10名様に拙著「ITエンジニア向け企画力と企画書の教科書」（2020年3月出版）をプレゼントいたします。