トーク

私は学生時代に学園祭実行委員会に所属し、PHP を用いた学園祭 Web サイトの開発・運用や情シス業務に携わっていました。その頃の経験を振り返り、学園祭 Web 開発の過去と未来に触れつつ、一般のエンジニアでも他人事ではないような話をします。

こんな話を時間の許す限りします

• 学園祭 というドメインならではのチーム・プロダクトの特徴
• PHP での開発をどう学び、後輩に伝承するか
• 現代における学園祭 Web サイトの設計論
• 社会人エンジニアとなった今役立っている経験

参考リンク

関連する内容について、ブログエントリを公開しています：

• 学園祭のWeb開発を語る: 具象編1 講習会と砂場遊びで支える組織
• 学園祭のWeb開発を語る: 具象編2 開発体験・保守性を投げ捨てる
• 学園祭のWeb開発を語る: 抽象編 自分たちの責務をどう絞り、どう委嘱するか

プログラムにおいては処理の結果を何らかの方法で伝達し、成功と失敗を切り分けたいことがないでしょうか。

PHPにおいても、ファイルを読み込む file_get_contents() 関数は string|false のような型宣言になっています。
標準関数においてはそれ以外にもエラーや例外など異常事態を伝えるための機構が組み込まれています。

そのほかにも、成功と失敗を表現するにはその他にも数多くのアイディアがあります。
このトークにおいては、PHPでは馴染みのない手法も含め、事態をより安全に異常と正常を切り分けて扱うための方法を扱います。

キーワード

• エラー・検査例外
• 型安全・静的解析・PHPUnit
• 直和型・ユニオン型・タグ付きユニオン

2021 年 11 月、PHP の処理系と言語そのものの開発に一大転機が訪れました。

• PHP の様々な側面での近代化に関わってきたコア開発者 Nikita Popov さんの活動規模縮小
• それを契機とした The PHP Foundation の発足

The PHP Foundation は寄付を募り、PHP 処理系の実装と言語仕様の改善へ取り組むコア開発者へ資金を提供して、日中の仕事として PHP の開発を行えるようにする団体です。寄付が集まるほど PHP の開発が加速し、私達 PHPer がその恩恵を受けられることになります。
https://thephp.foundation/

すでに日本を含めた世界中から多くの寄付が集まり、The PHP Foundation によって雇われた数人の開発者によって、実際に多くの言語改善が成し遂げられました。このような PHP の開発事情をすでによく知っていて、所属会社からも寄付を行っている、という方もいれば、「PHP という言語自体の開発を生身の人間がやっていて、彼等がどう日々のご飯を食べているかが我々のビジネスに強く関係している、なるほどその発想はなかった」という方もいらっしゃるかと思います。

このトークでは The PHP Foundation の成り立ちと意義、これまでの活動内容をあらためて紹介し、「そういうわけで皆も会社のお金で The PHP Foundation に寄付をしよう！」というお話を、The PHP Foundation の関係者でもないのに外野から勝手に力強くやっていきます。

LT 枠でめっちゃ早口になって舌も回りきらずよく聞き取れない部分が多くなる可能性がありますが、その場のライブ感とともにパッションをぶつけるのがきっと大事なことなので、細かいことはあまり気にしない感じでやっていきます。

PHPを使用している方にとっては、PHPの中身に興味がある方も多いと思います。そんな時は、PHPのソースコードを読んだり、改造したりすることで理解が深まることがあります。
PHPを改造した場合、その動作を確認するためには、コンパイルする必要があります。また、PHPをWeb上で表示するためには、Apacheなどのサーバーソフトウェアのインストールも必要になります。
そこで、このトークでは、PHPを実際にコンパイルしてWeb上で表示させる手順について、Dockerfileをお見せしながら解説します。

対象者
・PHPをコンパイルしてみたい方

話すこと
・PHPをコンパイルする手順
・PHPとApacheをコンパイル・インストールする上ではまったポイント

話さないこと
・Cコンパイラの選択
・PHPの内部実装

2021 年 11 月、PHP の処理系と言語そのものの開発に一大転機が訪れました。

• PHP の様々な側面での近代化に関わってきたコア開発者 Nikita Popov さんの活動規模縮小
• それを契機とした The PHP Foundation の発足

The PHP Foundation は寄付を募り、PHP 処理系の実装と言語仕様の改善へ取り組むコア開発者へ資金を提供して、日中の仕事として PHP の開発を行えるようにする団体です。寄付が集まるほど PHP の開発が加速し、私達 PHPer がその恩恵を受けられることになります。
https://thephp.foundation/

すでに日本を含めた世界中から多くの寄付が集まり、The PHP Foundation によって雇われた数人の開発者によって、実際に多くの言語改善が成し遂げられました。このような PHP の開発事情をすでによく知っていて、所属会社からも寄付を行っている、という方もいれば、「PHP という言語自体の開発を生身の人間がやっていて、彼等がどう日々のご飯を食べているかが我々のビジネスに強く関係している、なるほどその発想はなかった」という方もいらっしゃるかと思います。

このトークでは The PHP Foundation の成り立ちと意義、これまでの活動内容をあらためて紹介し、「そういうわけで皆も会社のお金で The PHP Foundation に寄付をしよう！」というお話を、The PHP Foundation の関係者でもないのに外野から勝手に力強くやっていきます。

2023年4月時点で、CakePHPは5.0βの開発が進行中です。
およそ3年ぶりのメジャーバージョンアップとなり、PHP7へのサポートを終了する最初のバージョンとなります。
コードネームはChiffon(シフォンケーキ)と言います。

まだまだ機能のスコープは安定しませんが、どんな変化が予想されて、使い勝手はどう変わるのでしょうか？
このトークでは、カンファレンス当日までのなるべく最新の情報を取り込んで、開発状況・個人的な所感や予想について共有します。

話すこと

• CakePHPの4.3辺りからの「どういう変化が起きているか」のおさらい
• CakePHP5.0で計画されている変更点
• それらを総じて、「このFWはどういう方向に向かおうとしているのか」の所感

テスト書いてますかー！と聞けば、書いてますよー！と元気に答えてくれる人って多くなっていそうですよね。
では、得意ですかー！とか、他人に教えられますかー！とかって聞くと・・？難色を示す人も多いのではないでしょうか。

「テストを勘で書いてきたし、書けるようになってきたけど、そろそろ品質とか理論とかを学びたい」という人に向けたトークをします。
ただし、これは非常に深く広大な話題だと思うのですよね。
そこで、単体テストにフォーカスを絞って、「考え方を身に着けたり、引き出しを増やすために役立ちそうな情報はないのか？」に応える「手引き」となるようなトークをします。
どういう課題を持っているか・どういう知識を身に着けたいのかというケース別に、処方箋となりそうないくつかの書籍や情報リソースを紹介します。

想定対象者

• 「普段の仕事では単体テストを書いている」くらいのレベルにはあるけど、自分の書くテストに自信がない人
• 「テスト中級者」よりも手前のレベル感だなぁ、と感じている人
  • 「全く書いたことがない」という人はスコープから外れます！

話すこと

• テストについての(一般化された)知識、理論を学ぶための情報
  • 主に単体テスト
• 日頃から「テストをスラスラと書けるようにする」ための学び方、鍛え方

話さないこと

• PHPUnitなど、特定のテスティングフレームワークの利用者練度を高めるためのtips
• テストの「動かし方」やテスティングフレームワークの内部構造など、実装に関する話

人工知能ってやばいですね！！私はあまり中身については分からないのですが、「きっとヤバいね」という噂をたくさん聞くので、すっごいヤバそうだなという事を知っています。

TestGen AIは、RectorやEasy Coding StandardsといったOSS活動でも有名なTomas Votruba氏のプロジェクトです。
https://testgenai.com/

テスト対象のコードを入力すると、自動的にPHPUnitのテストコードを生成してくれます。
(動作イメージは、↓のツイートなどを見ると分かりやすいかと思います)
https://twitter.com/testgenai/status/1639331232151371804

何をしてくれて、どんな感じに動くのでしょうか？
このLTでは、実際に触ってみて&これからどんな発展の可能性がありそうかを共有します。

もっとデプロイを増やしましょう。
ここ数年、国内のPHPコミュニティの勉強会やカンファレンスでも、Four keysを始め「開発組織の生産性・健全性」の計測や向上に関心が高まってきているのを感じます。
その源流となるのは、DevOpsのムーブメントでしょう。
「開発と運用が分離されていることが、天井になっているのではないか」というDevOpsの精神は、自ずと「もっと高速にデプロイ出来る、頻度をあげられる、それによってプロダクトの提供価値を増やせるはずだ」という夢を追う事になります。

翻って言ってみれば、それほど「DevとOpsは反対の動機で行動しかねない」というリスクを背負うということです。
すなわち、「安定して、信頼性が高いソフトをデリバリーして欲しい」と願うOpsと、「思い描いた機能を、速やかに出していきたい」と願うDevの対立です。
結果として、「対岸」の怖い人に迷惑を掛けたくないし、あるいは「同じ側」にいる人のためにも信頼を損なうような事をしたくない・・・・「デプロイ恐怖症」のトラップに陥っていきます。

そうした背景が、現実世界には存在する事は想像に難くありません。
ですが、それは突破できると嬉しい世界が広がるはずの、突き破るべき天井です。

私の職場では、この半年〜1年ほどで「デプロイ数を今までに何倍にも出来た」「最近はデプロイするのが怖い！って気持ちが減った」という声を、開発メンバーからチラホラと聞くようになりました。何が起きたのでしょうか？

主に「開発者の心理的な面」の改善・向上に焦点をあてて、その変化をもたらした要因やプラクティスについて共有します

主なトピック

• やっぱりマージまでを早めよう！デプロイの粒度もちっちゃくしよう！は大事
• 「壊れても気付ける」という安全のためのシートベルトを用意していく
• 「もし欠陥があっても対処できる」という自信、「大騒ぎにならずに沈下できる」というanti-緊張感を備える
• 開発に歓びを取り戻すのじゃ！！

プロジェクトを成功させるためには、「効率よく仕事を進める」「手戻りや足止めの時間を減らす」みたいな事を頑張りたいですよね。
タスク間の依存関係をほぐしたり、属人性の高いタスクにスペシャリストが良いタイミングで着手できるように整えるのは、いわゆるプロジェクト管理といわれる領域の成果であり責務です。
それと同時に、いかにソフトウェアを設計するか？によっても、プロジェクト管理のリスクのコントロールに影響します。すなわち、設計次第で「手戻りやタスクのブロックを軽減する」ことに繋がるのです。
これは、突き詰めると「変更容易性」「開放閉鎖原則」で説明することが可能です。

このトークでは、「どのようにして、ソフトウェア設計の観点からプロジェクト管理の難しさを和らげるか」について共有します。
設計と、スケジュール管理と、チームによる分業を総合して考えることで、よいプロジェクト人生を手に入れましょう！！

話すこと

• 「どこから作っていけば良いのか」で考えるPJの進め方
• 「ハリボテ」を活用して、実装の意思決定を遅延させる
• それでも「後回しに出来ない実装」にチームで如何に立ち向かうか

主な参考書籍

• アジャイルソフトウェア開発の奥義
• ライティングソフトウェア
• 実践テスト駆動開発

仕事をしている時など、「ムッ」とする場面はありませんか？
そうした際に誰かを悪者にしていませんかね。
悪者って、何でしょうか？──自分の目的達成や生存に対して、阻害をもたらす存在だとします。
イラッとすることがある、上手く行かないことがある、それらを「誰かのせい」にすることで、ギクシャクしてしまったり衝突を起こしたり・・・そんな経験はないでしょうか。その多くは、望んで起きた結果ではなく、望まずして生じて避け難かった「事故」のようなものである事も。

「問題の外在化」という技法があります。
これは「(問題を起こした)誰か」や「自分」に疑問を向けるのではなく、「問題を起こさせた要因があるはずだ」と考えることで問題そのものと人とを切り分け、本質的に「問題と向き合いやすくする」というものです。
「スプリントゴールが達成できなかったのは、Aさんの実装が遅かったから(Aさんが悪い)」ではなく「チーム全体でのコミュニケーションが以前より減っていて、アラートに気づけなかったから(チームが悪い)」「コミュニケーションが減っているのは、「執務室で会話を減らせ」と伝達を出してきたから(環境が悪い)」といった形で、問題の構造を変えさせます。

このような視点も含め、「解決したい問題が発見された時に、その背景や出どころに働きかける」という考え方として「システムズ・アプローチ」と呼ばれるアプローチがあります。
「誰か」から「仕組み」に意識の向け先を変更することで、憤りや不満と言ったネガティブな感情を和らげ、それまで「問題の主体」と考えられていた人物も含めた関係者で一体となって「コトに向かう」「他責的に考えず、当事者として解決可能な課題として扱う」ようになりやすいと言われます。

プログラマー職は「問題を解決する」「仕組みでどうにかする」が得意な職種だと思うので、この思考はとても相性が良いはずです。また、自然と「システムの問題として捉える」ができると、効果的な改善施策やアクションが浮かびやすくなります(例えばレトロスペクティブの場面などを想像してみてください)。
結果、深く広い学習のループが進むようになり、強いチームを手に入れられるようになるのです。

本トークでは、そんなシステムズアプローチの世界に触れつつ、「問題をシステムで捉えること」「実践しやすくするための視点・発想法」を共有します

ソフトウェア開発は複数人が関わる事が多く、特に業務の場合は単独の開発者で完結することは少ないでしょう。

人が複数集まると、「組織」となり「社会」が成立します。
そうした集団の力が、うまく活きれば強大なものになり、そうでなければ摩擦や抵抗により低減します。
うまく「チーム」で動いて行きたい、あるいは自分を取り巻くチームを良い方向に動かしていきたい…そう思ったことはありませんか！

「なぜ他人は動かないのか」「人はどうしたら動くのか」の両方向の力学を知っておくことが、ヒントになるはずです。
私は、マネジメントやリーダーの立場から、いくつかのチーム・個人に対して内外から関わっていく中で、「どのようにして、目の前の他人を前に進ませるか」を探求するようになりました。
本トークでは、チームやコミュニケーションに関する理論や考え方を紹介しつつ、協働するチームを築くための働きかけの技術について紹介します

伝えたいこと

• チームとグループの違い、目的を共有する集まりになることの重要性
• 進みたい方向性を示す・具体化し共有する、ただし他人に何かを「押しつけ」ないようにする
• 人ではなく課題に向き合うようにする
• 他人を尊重する、それと同じくらい自分も尊重する

参考書籍・関連分野

• あなたのチームは、機能してますか？
• なぜ人と組織は変われないのか
• 他者と働く
• プロフェッショナル・ファシリテーター
• ファシリテーター完全教本
• インターベンション・スキルズ
• プロセス・コンサルテーション

【前口上】
ありがとうPhpStorm、寛容で叡智に富んだあなたがいてくれて、私のPHPはどんどん良くなっていく───
コードエディタの領域だけではない、ソフトウェア開発を幅広くサポートする強力なツール・機能群。静的解析ツールやテスティングフレームワークといったPHPコミュニティの資産との力強い連携。そして、あらゆる面でコードのクオリティを底上げしてくれる静的解析機能！！

今日では、こんなにも進歩した相棒によってPHPの開発が支えられております。
便利で馴染み深いツールだからこそ、しっかり使いこなして普段の開発をより心地よく・生産的なものにしたいですよね。

【本題】
そんな事を感じながらも、あなたはPhpStormのInspectionについて、どのくらい把握できていますか？
当たり前のように目にしており、時には自分で調整をしてみるものの、あまり網羅的に内容を観たことがない・・という人も少なくないのではないでしょうか。

本トークでは、PHPについてのInspectionを全体的に眺めてみつつ、現場で実践的に活用するための方法を共有します。

主に話す内容

• PhpStormのInspectionってどんなものがあるの？
• ちょっとした付き合い方のコツ、個人やチームで上手く使う
• 自作のインスペクションを追加する

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

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

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

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

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

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

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

あなたの組織はアジャイルですか！スクラムのフレームワークやXPのプラクティス、スクラムパターンや組織パターンを利用して独自のパターン・ランゲージを構築したりしていますか！！
こう聞かれると、「うちはアジャイルかどうか」を考えたり、あるいは「全然できていないのでは…」「本当のアジャイル教えてよ」なんて少し寂しい想いが湧いてくるかも知れません。
私の身近でも、「私のはアジャイルか」「あなたのはナンチャッテでは」と気を揉む様子が見られる場面があります。

個人的には、「良い事をやろうとしている人は、それだけで自信を持って良いし、幸せでいて欲しい」と思います。自分が取り組んでいることを「まがい物だから」と卑下したり、疑念を抱いて凹んだりして欲しくないのです。
「アジャイルになるぞ」と「アジャイルかどうかは気にしなくて良い」の精神性を両立することが必要だと感じていまず。実際、それは可能なはずです。

私は、独学でアジャイルについて学びを深めたり(コレとかコレとか)、Scrum Allianceの認定研修(CSM、CAL-1)での教育を受ける中で、そして組織の中で考え実践し他者との対話を重ねる中で、「定義や形式に拘り過ぎる必要はない、地に足をついた活動と理想を探求することは矛盾しない」と思うようになりました。

「be agile」へのジャーニーは、一朝一夕で成るものではなく、果てしなく長い終わりのない旅路です。
ましてや、booleanで「である」「ではない」を判断できるものでもないでしょう。

─では、アジャイルを意識して理想に向かい前進しよう！！とする時に、何が大事なのでしょうか。

このトークでは、「アジャイルソフトウェア開発宣言 / 背後にある原則」「XPの価値基準」「スクラムの理論と価値基準」「モダンアジャイルの原則」を改めて眺めてみて、我々が意識すべき「ありたい姿」を探っていきます。
その上で、マインドセットとプラクティスの面で「アジャイルリーダーとして、明日からあなたが取り組めそうなこと」を提言します。

MVP, Minimum Viable Product 顧客に価値を提供できる最小限のプロダクト。
よくアジャイル開発の文脈で「プロダクトはMVPから作りましょう」という話を聞くと思います。
たとえば初日にシステム全体のサイトマップを書き始めたり、ユーザーModelやログイン機能から作っちゃダメということです。
「価値を提供できる最低限」を見極めて、顧客の課題を解決するコアとなる機能から作る考え方とコツをお伝えします。

今や、CIを回して静的解析を活用して、コーディング規約の運用は機械で自動化するのが当たり前です！！
カンファレンスや勉強会に参加している皆さんにとっては、きっと「そうだそうだ！」と強く頷いていただける主張なのではないでしょうか。

・・・本当にやれていますか？
現実には、きっとそんな甘くないぜ！と唇を震わせている人もいるのではないでしょうか。
今まで使っていない方法や仕組みを取り入れるのは、心理的な抵抗感や不安も生じますよね。

まずは「ノーコストで入れてみる」という方法をとれないものでしょうか？それが出来れば、導入に向けた障壁が1つ解消しそうです。

このLTでは、実際にそうしたアプローチを実施して、PHP_CodeSnifferを既存プロダクトに導入した際の話＋今後の展望をお話しします。
私の戦略は、「既存コードに影響のないSniffを入れる」「それによって、まずは”CIでスタイルチェックが動いている”状態を作る」「そのために、既存コードの適合状況を機械的に分析する」「自転車置き場の屋根の色の議論を避けるために、トップダウン的にPER Conding Styleをベースにする」「今後の進展のための仕組みを作り、運用・展開を移譲する」などを組み合わせたものでした。

この手立てを使って、「何年もスタイルチェッカーを入れたい声はあったが実現されていなかった、10年以上の歴史を持つプロダクトコード」に対して、今ではCIによるチェックが稼働しています！

PHPにはプリロード(Preload)があります！！パフォーマンスが上がります！
・・・噂は聞いたことがある・存在は知っていても、実際に使ったことはありますか？
何となく難しそうだなぁ。。複雑な事をしなければいけないそう。。そんな風に、遠い存在に感じている人も多いのではないでしょうか

ayesh/composer-preload というパッケージがあります。
see: Packagist

これはComposer Pluginです。
READMEを見ると Composer Preload is a composer plugin aiming to provide and complement PHP opcache warming. と記述されています。
正に「プリロードを気軽に使ってみよう」を支援するツールであり、私達にとってプリロードを「遠い存在」から「身近な存在」に近づけてくれる可能性があります。

どんなアイディアでそれを実現し、どんな仕組みになっているのでしょうか？
簡単に内部に触れてみましょう。
それによって、「プリロード完全に理解した！」という人を増やすLTになります。

私は、学生時代に地方の大学で技術コミュニティー（サークル）の運営に取り組んできたので、地方大学のコミュニティーについてお話ししたいと思います。

私は新卒のエンジニアですが、昨年まで地方の大学で技術コミュニティの運営に取り組んできました。私が大学生の頃、2019年12月からコロナが流行し、大学はリモート授業になり、サークル活動も対面で行うことが難しくなりました。また、「地方のITコミュニティー」と「大学のサークル」では特性が異なりオンライン化に伴い、それぞれのコミュニティーで苦戦したことがあると思います。

このような環境の中で行ったことや、苦戦したことや上手くいかなかったことについて発表します。また、「大学生のコミュニティー特有の課題」や「地方大学のコミュニティーの課題」についてもお話ししたいと思います。

「学生で参加される方」や「学生コミュニティーに携わっている方」に少しでも多くのことが共有できればと思っています。

Google Apps Script（以下、GAS）とは Google が提供するローコードプラットフォームです。

普段 JavaScript を書くのほぼ同じ感覚でコードを書いて実行できますが、単なる JavaScript 実行環境にとどまらず Google の提供する各種サービス（スプレッドシートやフォーム等）との連携を容易に行えたり、動的な Web ページを表示できたりと、まさに「ローコードプラットフォーム」と呼ぶにふさわしい機能を備えています。

何が正解かわからないビジネスの世界において、誤った方向性でプロダクトを作り込んでしまうことを避けたいもの。
そのためにコストをかけずにプロトタイプを作って仮説を検証するのですが、GAS の備える特性はそのサイクルを回す際に強力な助けとなります。

本トークでは、そんな仮説検証を回すため知っておくと役に立つ

• GAS でできること
• GAS を使うときのコツ、Tips
• GAS の限界、使うべきでないところ

についてお話します。