トーク

鳴り止まないアラート…天を仰ぐ上司…黙々と戦うエンジニア。
トラブルはとても厳しいシーンです。
しかしその反面、トラブルシューティングはエンジニアの腕の見せ所とも言えるのでは無いでしょうか。

そこで今回はWebサービスによくあるトラブルを題材に実際にどのようにトラブルを解決していくかの勘所をお話します。

• Webサービスが突然落ちた
• RDBMSのコネクションが溢れる
• Webサーバのロードアベレージが青天井

このような経験がある人もまだ無い人も昔から変わらないテクニック、今だからこそ出来るテクニックを交え、 楽しみにながら！ 未来に役立つ話をお伝えします。

このトークは『スキルエンジン株式会社』の提供でお送りします。

--

数百以上のプロジェクト開発経験を踏まえ、プログラマに必要なスキルとは？
数年後、10年後先を見据えどのようなスキル・考え方を身につければ
プログラマとして圧倒的に成長できるか？

上記について徹底的に分析し、成長するためのエッセンスを凝縮した
教育カリキュラムを紹介いたします。

そのカリキュラムを実践した弊社メンバーは
未経験から2,3ヶ月程度でSE/PGとして数千万レベルプロジェクトに参画

<一部抜粋>
・超高速PDCA？？(当日までに名前を決めます汗)プログラム開発
1.現状把握
正確に現状を捉える。捉え方についてはエラー文/ログ解析など。
正確に捉えるには、正確な知識が必要。
正確な知識を習得する為はどうしたらいいか？など
2.根拠に基づいた仮説を立てる
複数の仮説を洗い出しする。その中から実現可能性の高い仮説を選ぶ。
3.コーディング
2で洗い出したパターンを実装する。
一気に作らない、細かく動作確認しながら実装していく。
１行１デバッグを行う。

・スクラッチ開発
いきなりフレームワークから入ると、応用力が身につきにくい。
スクラッチ開発を通して、応用力のつく学習の流れを紹介。

このトークは『BASE』の提供でお送りします。

ビジネスを実現するために我々はさまざまな技術から選択する場面に出くわします。技術選択は適材適所で行うべきと問われつつもその技術に開発運用の知見がない場合、短期的に見た自分たちの慣れという優位性に引っ張られ、より適しているとは言えない選択をしてしまうというのは一般事象としてみうけられることだと思います。知見のない言語・フレームワークの採用における大きな懸念点は、短期的に見れば学習コスト・コード品質を保てるのか、長期的に見ればその技術で構築されたサービスを保守できるかという点が挙げられます。
このトークでは、BASEの新規事業において、知見のない言語を選択し、列挙された懸念を監視設計・コード検査・テストなどを駆使して乗り越えリリースしていった際の知見を話します。次の技術選定に立ち向かう戦略・ひとかけらの勇気をお持ち帰りいただければ幸いです。

PHPの言語仕様は変化の歴史であり、常にほかのプログラミング言語の特徴を取り入れることで発展してきました。その変化はときに断絶を生んできましたが、同時に我々に多くの可能性をもたらしてきました、このトークでは一人のプログラミング言語好きとしてPHPの言語仕様の歴史的経緯と強力な機能を紹介していきます。

この話は、オレオレフレームワークで作られたアプリケーションに秩序をもたらすべくヒィヒィ言いながらリファクタリングをし続けた男の5ヶ月間の記録である。

この話には以下のような内容が含まれる予定です
・OSSのフレームワークを使っていないアプリケーションの泳ぎ方
・テスト環境が整っていない状況でいかにテストを書くか
・テストとリファクタリングはどの程度のバランス感でやって行くといいのか
・リファクタリングにコストをかける意味はあるのか

※大規模なカンファレンスでの登壇は初となります

Webアプリケーションの脆弱性は、どこに潜んでいて、いつ狙われるのか分かりません。ひとたびサイト改ざん・情報漏えいが発生したらビジネスに及ぼす影響は甚大です。

未然防止策として外部脆弱性診断・検査ツールなどがあり、脆弱性の発見・事前検知ができます。WAFを導入することで、外部からの不正な攻撃からWebアプリケーションを守ることも出来ます。

しかし、それで本当に万全でしょうか? いえ、そうは思いません。根底として大切なのは、エンジニア自身がWebセキュリティの正しい知識を持ち、安全なアプリケーション開発を行うことであると考えます。

Webアプリケーションエンジニアの皆さん、今改めてWebセキュリティを一緒に見直しませんか。本セッションでは、Webアプリケーションエンジニアが遭遇しやすい脆弱性の概要と危険性、そして対策方法についてお話します。

「クリーンアーキテクチャ」とは、DDDの文脈における「ドメインモデル」をシステムの中心にすえ、「入力」「永続」「出力」などの多方面で抽象化を行うことで、高度に変化への強さを獲得できるアーキテクチャです。昨今の変化の早さに対応するべく「アジャイル開発」や「マイクロサービス」が叫ばれているように、「クリーンアーキテクチャ」もまた日増しにその注目度は上がっているように感じます。

しかし、やや取っつきにくいアーキテクチャであることからか、現状参考になる資料が無数に転がっているというわけでもありません。そこで、エキテンで現在Laravelベースで開発中の新しい予約システムを題材に、実際にアーキテクチャを形作っているコンポーネントの紹介や、開発する上で行ってみたちょっとした工夫、開発フェーズにおける現場の生の声などをお話しようと思います。

PHPスクリプトの実行時には「コンパイル」と呼ばれる処理が行われ、スクリプトはZend VM（PHPの仮想的なCPU）の命令列に変換されてから実行されます。このZend VMは本物のCPUと似た命令も持っていますが、本物のCPUではあり得ない命令も持っています。その一つが例外処理に関わるものでしょう。

本講演では、例外処理をZend VMはどのように実現しているのか、Zend VMと本物のCPUとの違いは何か、といった実装の詳細をPHPのCソースコードを交えて紹介します。

中学生の頃にMSXというパソコンのCPUであるZ80のプログラミングを体験していました。

その約25年後、2016年にPHPで書かれたゲームボーイエミュレータのコードを読んで衝撃を受けました。ゲームボーイのCPUはZ80ベースであり、エミュレータで実装されていたのはまさにZ80の命令だったのです。この体験で、エミュレータがハードウェア仕様をソフトウェア的に表現したものであることを理解しました。

そしてさらにその3年後。名著「CPUの創りかた」で紹介されているCPU、TD4を実装し衝撃を受けました。そこに見たCPUは電気回路として表現された状態機械でした。

このトークではPHPでTD4のエミュレータを実装し、マシン語実行環境、エミュレータの対象、そして電気回路としてのCPUがどの様に動作するのかをメモリアクセスを中心に解説し、CPUの魅力をみなさまにお伝えします！

安全なインターネットサービスを提供するにあたっては、ソフトウェアバグとしての脆弱性対策だけではなく、ビジネスモデル・サービス仕様・アーキテクチャ設計・ソフトウェア設計・実装・サーバーなどの多方面からセキュリティ検証が重要となります。本セッションでは、架空のQRコード決済サービス「オニギリペイ」のセキュリティ事故を題材として、サービスの企画・要件定義・設計・実装の各フェーズに起因する問題とその対策を具体的に紹介します。

--
徳丸 浩

1985年京セラ株式会社に入社後、ソフトウエアの開発、企画に従事。2008年に独立し、Webアプリのセキュリティを専門分野とするHASHコンサルティング株式会社を設立した。著書に「徳丸浩のWebセキュリティ教室」 「体系的に学ぶ安全なWebアプリケーションの作り方」がある。

フィールディング博士のREST論文に登場する６つのアーキテクチャ制約（クライアントサーバー、ステートレス、キャッシュ、統一インターフェイス、レイヤ、コードオンデマンド）と４つのインターフェイス制約（リソースの識別、表現によるリソース操作、自己記述的メッセージ、ハイパーメディア制約）を解説し、REST(Hypermedia)のAPI設計戦略を検討します。

RESTはコンポーネントや創造性を強調するのではなく、適切な制約を構築し抑制と理解を強調する手法で設計されました。RESTそのものだけでなく、RESTの設計手法をも知ることでRESTの深い理解を目指します。API設計者のためのREST解説です。

Quality Assurance 各種ツールについての紹介をします。
コーディング規約チェック・静的コード検査・テストツール・リファクタリングを中心に、あまり着目されてない数多のツールを俯瞰します。
コーディングやレビューでの参考にしてもらえればと思います。

章立ては以下の予定です

• サンプルコードを例に、いくつかのQAツールの使いどころ·段階的導入での改善ポイントの紹介
• QA ツールの昨今の競争/共存事情
• ここ近年のQA ツールのざっくり紹介 〜 そのQAツールが解決したい問題の背景を交えて

取り上げる予定のツール·用例は、
phan / phpstan とプラグイン / psalmとスタブ、 infection、rector、slevomat/coding-standard、roave/you-are-using-it-wrong …

今年で15周年を迎えたWebサービスにテストコードとCI/CDを導入しました。
アプリケーションは何度かのリプレイスを経て、現行はPHP7とLaravelを基盤としたシステムで稼働しています。
一方で、データベースは古くから稼働したままのため、システム間の依存が多く見られ「サイトの規模の割にテストコードの実装が十分でなく、改修が怖い」といった課題がありました。
今回はマイグレーション管理されていないデータベース環境へのテストコードの導入とCI/CDの設定についてお話しします。
また、複数のシステムリプレイスの間に試行錯誤しつつ育てたテスト環境の歴史、CIによる継続的なパッケージアップデートとセキュリティチェックについてもご紹介したいと思います。

【初心者向け】
PHPは言語としては初学者にもやさしく、入門しやすい言語かもしれません。
一方で、実際にWebアプリケーションを作るにあたり、知らなければいけない周辺知識はたくさんあります。
ではまず、Webアプリケーションフレームワークのチュートリアルをやっておけば良いのでしょうか？
また、どこから学んだら良いかわからず、入門書っぽい本で学習するのが良いでしょうか？
このセッションでは、初学者（Web系の言語入門者を含む）にとって、Webアプリケーションを開発することを学ぶにはどこから取り組むのが良いのか？ということを紹介します。
60分枠も申し込んでいますが、こちらは短縮版となっています。

My talk will be about implementing new not traditional methods to increase performance of PHP applications using tools like RoadRunner, Swoole, ReactPHP and etc. Will introduce these methods, explain how each of them work and how it affects development, pros & cons and real-life example if Wifi will be present I'll show live example how each of these tools increase performance over typical setup's

Apacheを長らく運用していて秘伝の .htaccess があって、Apacheを離れられないという方いらっしゃいませんか？
LiteSpeedを使うと、rewriteルールをそのまま利用することができて、Apache+mod_phpと違って静的コンテンツの処理プロセスとPHPプロセスが分離しつつイベントドリブンな世界に突入できますし、Nginx+php_fpmと違ってそれぞれ別々に管理する必要もありません。
PHPer界隈では、Webサーバーと言えば Nginx か Apache かの2択のことが多いですが、ロリポップ！レンタルサーバーの新プランでも採用した LiteSpeed という第3の選択肢があることを説明したいと思います。

スタートアップ企業が自社サービスを開発するにあたって、
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を利用しているので、
利用中の課題点と自分が感じた「クセ」について、簡単にお話しできればと思います。

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