トーク

私事ですが、身をおいている環境の変化により、自分より若手の開発者と接する機会が増えてきました。
そんな中、ある時「どうしたらコードをうまく書けるようになりますか？」と質問をされたのです。
私はふと「コードをたくさん読むと良いよ」なんて答えたような記憶があります。

ソースコードをたくさん読むことはとても良いものです。実に多くの理由があります。
その中でも2つの点を強調するとしたら、

1. 利用(依存)しているソフトウェアについて、「なぜ・どうやって動くのか」を自分の目で確かめられる。しかも、読めば読むほど「読むハードル」が下がる
2. お手本となるコード、多様な書き方を見て自身の引き出しを増やしたり考えを深める材料となる

といったものがあると思います。

例えば、普段の業務の中で「モデルにあるhogeメソッドに処理が来るまでに、意図したデータが渡ってこない」なんていう時に。「フレームワークのコードを読んだら、データの渡り歩く経路が追えたので、”どこでデータが加工されていそうか”の勘所が掴めるようになった」と、納得感のある形で回答を得られることがあります。
あるいは、「この外部通信クライアントのテストをどう書こう？」→「実通信部分を担っているドライバ層のライブラリは、どうやってテストを書いているかをみてみよう」・「クラス名がググラビリティの低い単語になってて、情報が探り出せん・・・」→「実装を見てしまえば一瞬で処理がわかった！」などなど。

「読めること」あるいは「読んでみようと思えること」の恩恵は、様々な部分で感じられるでしょう。
とりわけ、「OSSのコードを読んで見る」ことは、世界中の開発者の目を通して磨き上げられたコードにアクセスできる可能性を意味します。

本セッションでは、「あまりコードリーディングってしていないかもなぁ」という人を対象に、「実際にOSSのコードを読んで見るにはどういう感じで取り組んでいけばいいのかな？」の例を示します。
実例のパートでは、Composerのコードを例に取りながら「気になるあの処理のコードを読んでみよう！」という取り組みも行います。

Xdebugを活用していますか？ステップ実行の機能については、利用経験者も多いかと思います。
公式サイトを開き、トップページを見ると「Step Debugging」「Improvements to PHP's error reporting」「Tracing」「Profiling」「Code Coverage Analysis」と主要機能が列挙されています！

「知らなくて使っていない」のと「使っていはいないが知っている！」では、大きく違います。
まだ試してみたことが機能がありますか？
本セッションでは、これらの機能を紹介しながら「実際にどう使うものなのかな？」を共有していきます！

Discord Channel: #track1-7-b-xdebug

PHP8.1が近づいてきました！！enumにfiberにreadonlyにnew in initializersに・・楽しみがいっぱいですね！
さて、その前にPHP8へのアップグレードが必要だと思います。
PHP5.xからのアップグレードを・・・は大変そうですが、PHP7.xからのアップグレードであれば、
「いかに低コストに・安全にやれるか？」を考えてみる価値があるかも知れません。

本セッションでは、以下のような点に触れながら「リスクを最小化しながら、どうやってPHP8に上げていこうか？」を考えていきたいと思います。

• 「PHPのアップグレード」は何が大変なのか？
• PHP7->8変更時に(特に)気にしたい箇所
• アップグレードのスコープを決めよう
• 静的解析を利用した「要修正箇所」の洗い出し
• ツールを使った「変更の自動化」でPHP8対応を楽にする
• Composerをうまく使って「今のコードをそのまま動かす」

※ PHP7.x -> 8.0を想定しています

アプリケーション開発者にとって、「エラーが起きた」は恐ろしいことですか？それとも、安心できることでしょうか。
もちろん、「エラーを出さない」という心構えはとても大事です。
では、「出しちゃいけないもの」という信仰から「エラーが出るのは怖いこと」という価値観が発生しているのでしょうか。

最も恐ろしいのは「何が起きているのかわからない」ことのはずです。
裏を返せば、「何が起きているのかがわかる」ことは最重要ともいえる武器です。
最強の武器を普段から磨いて備えて使っていくことは、我々を良い未来へ導いてくれるに違いありません。

エラーと付き合い、使いこなしていきましょう。
アプリケーションで発生したエラーを把握していますか？
「把握している」というのは「何かが起きたことを知っているか」ではありません。
「何が起き、それがどれだけの異常で、どう影響し、原因を追求するのに十分な情報を効率的に取得できるか」です。

もし「ちゃんとエラーに気づける」という世界があったら、いったい何が変わるでしょうか？
ひとつには、「デプロイが怖いもの」ではなくなります。
「もし変更に失敗しても気づけるから」という自信に繋がります。
もうひとつには、「高く付いたかも知れないダメージをグッと軽減できる」ようになります。
エラーないしバグは、「出た瞬間に直す」のがもっとも損失を抑えられるし対応コストも抑制できます。

本セッションでは、アプリケーションエラー管理ツール(Sentryを想定しています)を利用して、「開発現場にどのような”エラーに対する心構え”を構築し、チームでどう運用していくか？」をお伝えします。

世の中から「クソコード」は無くせるものでしょうか？
せめて、地球や宇宙の全部とまではいわなくても、「私の身の回りにある世の中」であれば可能でしょうか？

私は、なるべく「クソコードなんて視界に入ってこないで欲しい」と考えています。
一体どうすれば奴らはいなくなるのか。すごく難しそうです。
ですが、「新しくクソを生まないようにしよう」というのは可能でしょう。

そのための一歩として、「クソコードと呼ばないようにする」ことを本セッションにて提案したいです。

「心理的安全性が高いチーム」「人として、周りに気を配れる」「社会性フィルター！オン！！」
どれも大事ですね。とても大事です。
ですが、私は、もっと利己的な理屈をもって「クソコードと呼ばない」というムーブメントに取り組んでいます。
「温かい空気を作るため」ではなく、「もっと自分が技術者として成長するため」に、「クソコードなんて言葉は使わないぞ！」と決めたのです。

コードや成果物に対する「批判」は大事です。しかし、それは決して「あげつらう」ことではありません。
共有可能な価値観を提示し、それに照らし合わせて、より適正な在り方を目指す・・・そうした「批判」です。

「なんでこんなコードを書くのだろう」。
その根本にあるのは「コードの書き主が知らないことがある」「自分が見落としている事がある」の何れかです。
ここで「それはクソコードだ」と言ってしまえば、思考は停止してしまうと思います。
もっとダイブ出来るはずです。書き手の気持ちを考えよう。「なぜこの書き方を？」「どういう思考プロセスを経てこの書き方をしたのか？」「自分だったら、どこで”こうじゃない”と気付くはずか？」「単に書き手の技量不足だろうか。その足りない知識は、自分がわかりやすく説明できるだろうか？」クソコードから学べることは多いと考えます。
自分で納得できるまで「そのクソコードの生まれた歴史」を突き詰めていますか。

改めて、クソコードを超越した開発者になりたいと強く念じます。
極めて個人的な主張、理屈になってしまうかも知れません。
ですが、このセッションを通じて、こらからの未来に1回でも多くの「クソコード」発言が減らせたら幸いです。

Yappliのサービスの一部は独自フレームワークなPHPで実装されています。この独自フレームワークはトランザクションスクリプトかつinclude Orientedで、重複コードが多くテストコードも無いなど様々な課題を抱えていました。その結果、開発や運用の心理的な障壁となっており、不具合が発生しやすく保守性の低いシステムとなっていました。また、当システムに対する機能追加・改善要望も多数ありました。

そこで、サーバを立ち上げて行う自動テストや静的解析により、既存コードを修正せずに品質を担保し、
autoload化、ライブラリの導入、リファクタリングによる既存コードを修正する改善で、開発・運用効率を上げていきました。

本セッションではヤプリが取り組んできた改善を例として、独自フレームワークPHPアプリケーションを安全に確実に改善していく方法をご紹介します。また、各改善のタイミングや改善を続けるためのメンタル的なTIPSも併せてご紹介できればと思います。

Discord Channel: #track2-1-b-framework-kaizen

オンライン勉強会やイベントが続くこと1年。
なかなか参加者の盛り上がりを登壇者や参加者間で共有することができずモヤモヤした日が続いてきました。
そこで効果音を共有することで課題を解決するサービス pong swoosh を公開しました。
開発の経緯、実際使ってみてどのような反応があったのかを紹介します。

これまで社内勉強会活動として、トイレ利用状況を可視化サービス「Toilet Evolution」、常駐先から出退勤するサービス「Dakoku」を開発してきました。
デバイスやセンサーを使った開発はオフラインが主体でしたが、コロナで活動自体が難しくなりました。
そこで実デバイスでなくThingをオンラインに参加する人の感情と見立て、共有することがオンライン時代でのガジェットになる、と考え新サービスの開発を始めました。
これまでのものを含め、勉強会主体でサービスを作ることと、開発中のサービス pong swoosh について紹介します。

初めての登壇チャレンジです。
Webセキュリティ脆弱性に恐怖と興味を抱き「OWASP TOP10」や「安全なWebアプリケーション入門」IPAの「安全なウェブサイトの作り方」とかを見て調べました。
これ結構ちゃんと対策しなきゃな...というものもあれば、これの対策が必要なWebシステムってそんななくない？と感じるものもありました。
どのシステムでも対策が必要そうなメジャーなWebセキュリティから順に素のPHPもしくはLaravelのコードを用いて解説できればと思います。
Webエンジニア歴は浅いのでご容赦ください。

トーク概要

自作フレームワークの話になります．

趣味で開発をする際にLaravelを多用していますが，Laravelの内部構造について「よくわからない」という感情を持ちながら利用しており，その内部構造を理解するために実際に自分でフレームワークを作りながらLaravelのようなフレームワークを作ってみるというお話をさせていただきたいと思っております．

他にも，オブジェクト指向や自作フレームワークについて，まだまだ勉強することはたくさんありますが，自分なりに実装をしてみたり，たくさんのかたに相談をして実装を進めており，その中で，これまでに得た知見を発表したいと思っております．

トーク対象・分野

オブジェクト指向，フレームワークなどの初学者がメインとなりますが，ベテランの方からのフィードバックもいただきたいと思っているため，対象や分野は広く取りたいと考えております．

その他

大きなカンファレンスなどに登壇するのは初めてです．

Discord Channel: #track2-1-a-build-framework

【お話しする内容...】
現在、世界の開発者1800名のユーザーが使用、有志の企業/開発者からの支援を受け「LaravelDB.com」を開発し、運営しています。
前回のPHPカンファレンス2020では「何故作ったのか？、仕様、主な使用方法」を解説しましたが、
今回は「Webサービスを作るまでの始まり、どのように進めて作ったのか？DB選択？」などお話できればと思います。
「言語解説」というより、開発者としてどうやって1ヵ月でプロダクトをリリースするまでやったのかという話をしたいと思います。
【ターゲット層】
PHP初・中級レベルの人がメインのターゲットになると思います。
1人で全てを作り切ったことが無い、個人開発してみたい、新規事業でβ版をリリースを考えてる人 向けになると思います。

今では当たり前となった、自身の知識や成果をGitHubに公開するということですが、今回は業務内で実際に書いたコードを、問題なく自然な形で公開する一連の流れを私の体験をもとにしてシミュレートしてみます。
今回はファイルのウイルスチェックをする機能がLaravelで書かれた業務コード上に直接実装されている状態を想定してみます。ウイルスチェック自体は業務とは何の関係もないため、何とか機能を分離してメンテナンスしやすくすることを考えます。
まず初めにやることは、InterfaceとDIを駆使して、ウイルスチェック機能を業務コードから切り離しです。
ここからウイルスチェック機能をいったん外部コードとして公開し、Composerを使って業務コードに逆輸入するように修正します。これで、業務に直接関係ないコードをリポジトリの外に追い出せるとともに、自身の実績を外部に公開することができます。
最後に、Laravelとの接続部分とウイルスチェックの本体実装を分離し、特定のフレームワークとの依存性も排除し、より広範囲に使える状態を実現します。
この発表を通して、InterfaceとDIの活用方法や、Composerによる依存性管理の便利さを再認識いただけると幸いです。

Discord Channel: #track2-6-b-composer-interface-di

オブジェクト指向プログラミングがどういったもので、どういうときに役に立つのかについて解説します。

多くの初学者はプログラミングを始めて手続き型の記述に慣れた頃、オブジェクト指向プログラミングに出会います。
クラスやオブジェクトといった用語を学び、オブジェクト指向プログラミングの機能を実際に記述して体感します。
そして、混乱に陥ります。
なぜなら、オブジェクト指向プログラミングを活用することで何が嬉しいのか、機能を体験しただけでは理解できないからです。

道具を使いこなすには、それがなんであるかを学ぶと同時に、その目的を知らねばなりません。
目的を知らずに道具を扱えば、よく切れる包丁で紙を切るといったおかしな事態が起きてしまいます。

本トークでは、オブジェクト指向プログラミングがどういったもので何ができるかを解説するのと同時に、どうしてそれが必要なのかについてを解説します。

※本トークがカバーする範囲はクラスによるカプセル化とサブタイプポリモーフィズムまでです

■トーク対象

• プログラミング初学者（条件分岐まで理解している）
• オブジェクト指向プログラミングの使いどころが分からない方

Discord Channel: #track1-2-oop

ソフトウェアはその生涯において、さまざまな要求を突き付けられます。
要求に応え続けるために必要なことは、コードをシンプルに保つことです。
ソフトウェアアーキテクチャは抽象化と問題の分割によって複雑性を減らし、コードをシンプルに保つことに貢献します。
ソフトウェアが中長期的に利用されることを前提とするのであれば、ソフトウェアアーキテクチャの理念やそれ自体を採用することは検討すべき事柄です。

しかしながら、ここにひとつの問題があります。
それはソフトウェアアーキテクチャが単一でないことです。

日夜進歩しつづけるソフトウェア開発の世界では、多くのソフトウェアアーキテクチャが生まれつづけています。
それらの中から、チームやソフトウェアの目的やライフサイクルに最適なものを選定するのは容易なことではありません。

そこで本トークでは「ソフトウェアアーキテクチャの選定」をテーマに、ソフトウェアアーキテクチャの特徴や実装例を紹介しながら、どういった観点で選定をしているかについてお話します。
本トークで取り上げる主なソフトウェアアーキテクチャは次のとおりです。

レイヤードアーキテクチャ
ヘキサゴナルアーキテクチャ
オニオンアーキテクチャ
クリーンアーキテクチャ
ADOP
※サンプルコードは Laravel を予定しています。
※本トークは JJUG CCC 2021 Spring で発表した内容を PHP にカスタマイズしたものになります

■トーク対象

• ソフトウェアアーキテクチャがどんなものか知りたい
• どういう観点でアーキテクチャを採択しているか知りたい

Input-Output (otherwise known as I/O) is commonplace in daily programming but is quite arduous. PHP, though robust, offers sequential, blocking I/O solutions that require one to await completion of one task before starting another. Blocking I/O is somewhat inefficient, especially in modern applications that are computationally intensive in nature. Enter ReactPHP, a PHP-userland affable suite of technologies - complete with an event loop, a NodeJS-akin server, and Promises.

ReactPHP offers the advantages of non-blocking I/O - present in runtimes like Node.JS - to the PHP developers who use it. It provides, via the Reactor pattern, a means of efficiently running I/O operations in an event-driven domain.

My talk titled Asynchronous Programming in PHP with ReactPHP is an attempt to distill asynchronous non-blocking I/O concepts for a PHP audience. The first part is an introduction to non-blocking I/O and describes the advantages of adopting event-driven approaches. The second part is a description of streams, promises, and the event loop. Lastly, the third and fourth parts - the respective focus points being usage and application of ReactPHP - conclude the session.

Discord Channel: #php4-8-php-async
Joind.in: https://joind.in/event/php-conference-japan-2021/asynchronous-programming-in-php

PHP 8.1 brings Enums, one of the most requested features in PHP.

Enumerations allow creating strict and type-safe structures for fixed values. An Enum structure can hold a number of values that can also be backed with integer or string values.

In this comprehensive session, we will discover what Enums are, why they are useful, how to apply them on PHP applications.
Audience

This session is for those who are familiar with modern PHP practices such as Object Oriented Programming, principles such as Liskov Substitution principle; familiarity with such concepts can help a lot.
What you will learn

• What are Enums.
• Why Enums are useful.
• How to use Enums
• Migrating from magic constants/values to Enums.
• Backed Enums and storing/fetching Enum values with a database.
• Using Enums in a Drupal context.
• Caveats when using Enums.

Author

Ayesh Karunaratne is the author of PHP.Watch (https://php.watch), where he provides in-depth articles and documents on PHP and latest changes to the language.

• PHP 8.0: https://php.watch/versions/8.0
• PHP 8.1: https://php.watch/versions/8.1
• Enums: https://php.watch/versions/8.1/enums

Discord Channel: #php4-6-php81-enum
Joind.in: https://joind.in/event/php-conference-japan-2021/php-81-enums

In recent years, more and more PHP developers are interested in asynchronous frameworks, like Swoole. However, Swoole brings to PHP not just asynchronous programming; there are a few mind-blowing features in Swoole that many developers are not yet aware of. In this talk, I will discuss how to use Swoole to build an application server to serve web requests, to handle cron jobs, and to process job queues without relying on any third-party applications or software.

Discord Channel: #track4-5-swoole
Joind.in: https://joind.in/event/php-conference-japan-2021/build-an-all-in-one-application-server-using-swoole

■トーク対象
Ruby + RailsとLaravel + PHPの比較(新規事業開発)

■トークの概要
・業務経験2年のWebエンジニア
・Ruby + Railsでマーケティング支援ツールの開発、運用を行ってきた。
・新規事業開発室に異動となり、MVP開発を任された。(チームメンバー2名のリーダー)
・技術好奇心でPHP Laravelを採用
・Railsは自由に書ける分、チーム開発時のRVに工数がかかる。(直感的に書けるRubyの弱点)
・一方Laravelは、PHPの型が整っているのでレビューがしやすい。
・Rails(Ruby)とLaravel(PHP)のメリデメを実際の開発工数を比較して行う。

技術があればある程度の物は作れると思うのです。会社や周囲を巻き込んで何か実現しようと思った際は企画書が有効です。
そもそも会社は稟議で承認を得てますが、その稟議も企画書なのです。一方で技術はできても企画書を書くのはちょっと苦手という方もいると思い、PHPer向け企画書の書き方と企画力の高め方を実例を用いて解説します。

企画書の本も出した企画者一筋30年の講演者が解説します。（うわっハードルを上げてしまったｗ）

本当の初心者のためのPHPセッションです。
例年開催しており、PHPが初めて、途中で挫折した、プログラミング言語に慣れていない人に聞いていただきたい基礎的な内容です。
PHPとは何か、実行環境は、簡単なサンプルを交えながらPHPについてお伝えします。