トーク

ソフトウェア開発をやっていると、実に様々な「○○駆動」に出会います。
ドメイン駆動、ユースケース駆動、テスト駆動・・・

開発や設計の進め方だったり、考え方だったりについては、「駆動」以外にも似たような単語がありますね。
オブジェクト指向などの「指向」、ユーザー志向などの「志向」、人間中心デザインなどの「中心」、モバイルファーストなどの「ファースト」、etc。

その中にあってTDDやDDDなどは、どうして「駆動/ドリブン」なのか？を考えたことがありますか。
一歩留まって考えると、ただ「○○を最初にやること」ではないはずだ、と気付くはずです。
私は、この言葉を使う時、中核には「フィードバックを得やすくする」「あるべき姿の探索を推進する」ための仕掛けである！という主張が眠っているものと捉えています。

更に一歩踏み込んで、「なぜ、そうした仕掛けが必要なのか？」も考えてみましょう。
その答えは、「人間として、プログラミングを少しでも楽にするため」だと私は捉えています。

複雑で難しい問題を解く時、「できるところから始める」と進みやすくなります。
高度で曖昧な問題に取り組む時、「間違いに気づいて修正ができる」と正解に近づきやすくなります。
つまり、「認知負荷がキャパシティを超えないようにチャンクする」「適切なタイミングでフィードバックを得る」「軌道修正をする」を組み合わせることで、人間の問題解決能力が高まるのです。
「○○駆動」とは、正にこうした「人間が進むための杖」となるべきものでしょう。

このトークで話すこと

• 色々な「○○駆動」は、人間に楽をさせるための道具である
• どうやって楽をするか？に向き合うことが、プログラミングの能力に磨きをかける

このトークで話さないこと

• 特定の「○○駆動」についての解説や宣伝

一般的に「理系の専門職」と言われるプログラミングのお仕事について、
「実は国語力がとても大事だ！」という主張。
皆さんも、しばしば耳にした事があるのではないでしょうか？

多くは、「文章や会話の中から、要求を掴む」「表現すべきことを、構造化して記述する」といった点についての言及です。
なぜ、これらを「国語力」というのでしょうか？
あるいは、他にも要素があるのでしょうか？

例えば、「大学入試科目・現代文」の解き方をトレーニングすることで、職業プログラマーが学べる事とは──
もし、必要な能力が身につくのであれば、取り入れていきたいですよね。

そんなチャレンジをしてみましょう。

やること

• 「現代文(主に入試現代文)」の参考書で、どんなことが述べられているかを調べる
• 実業務と照らし合わせて、関連しそうなケイパビリティを紐解く

聴き手に提供すること

• 改めて「業務で求められる能力(のいち側面)」について分析し、言語化する
• 得意な人には自覚的な「強み」として、苦手な人には「鍛え方」「着目ポイント」として、国語力について考える機会にする

Composerで「パッケージを入れる」とは何なのか？について考えてみてください。

• 多くのパッケージにおいて、その他の様々なパッケージへの依存を持っています。
• 単純なパッケージ名だけでなく、各々が要求し許容するバージョン指定の範囲も、実に様々です。
• そして、その「その他の様々なパッケージ」もまた、その他の様々なパッケージへの依存を持っています。

・・・一体どうやって、こんなに複雑な仕事を達成しているのでしょう？
このトークでは、2つの観点から「どんな工夫をしているか」を解剖していきます。

提供する主な話題

1. Composerが複雑な「パッケージの組み合わせ」を解くための手続きとは？
   1. 「Pool」の最適化とは？
   2. SAT Solver、 2-Watched Literal Schemaといった概念についてざっくりと
2. メモリ節約のためのPHP的な工夫
   1. 各所で活躍するSPLデータ構造や実装に見られる構造面での工夫、おもむろに現れるgc_disable() 等

このトークで得られる体験

• 普段使っているツールが内部で「どんなエレガントな問題解決をしているか」に触れる
• PHPアプリケーションのいて大量・複雑なデータを扱う上での生きた例を垣間見る

対象者・扱うこと

• Composerの基本的な使い方を理解している方の方が望ましいです
• Composer全体の仕組みやパッケージ取得方法についての詳しい解説は行いません
  • ピンポイントで「パッケージとバージョンをどうやって決定しているのか」の話になります
  • ツールとしてのComopserの便利さ・使い方を紹介するトークではありません
• 数学・計算機科学的な踏み込んだ解説は範疇外です

ライブコーディングで、"Composerもどき”を作成します。

モチベーション

PHP Conference Japan 2024では、Composerの主要な機能を模倣的に作ってみるワークショップを実施しました。
その内容は、いくつかの機能を取り上げて、その内部の要素を掻い摘みながら実装していく流れでした。

そして今回は、発表者が与えられた時間の”LIVE”実装を披露します。
ワークショップという形式の都合上、端折った部分・お見せ出来なかった部分も含めて、全てお話します。

テーマ

Composerの仕組みについての簡単な解説(実況)を交えつつ、実際に動くものをゼロから書いてきます。
目の間で出来上がっていく様を見届けることで、普段とは違った角度からの理解の手助けになるでしょう。

※ 「Composerの機能」「導入や運用」について紹介することを目的としたセッションではありません。

ライブコーディングの内容

require コマンドの機能をベースにします

1. 任意のパッケージの指定を受け取るCLI
2. パッケージ情報の取得(※今回はPackagist限定)
3. composer.json相当のファイルの作成
4. 間接的に依存しているパッケージの情報の取得
5. 各パッケージの依存の解決(※今回はplatformやext系の情報は無視)
6. composer.lock相当のファイルの作成
7. パッケージ本体の取得
8. パッケージのvendorへの配置
9. autoloaderの作成

PHPのsocket拡張を利用するとsocketプログラミングができ、通信プロトコルもPHPで実装できます。
さらに、RAW socketという機能を使うとTCP/IPプロトコルもPHPで実装可能です。

今回のセッションでは、

• PHPのsocketプログラミングの基本
• TCPプロトコルの実装
• IPプロトコルの実装
• tcpdump, netstatによるデバッグ
  の話を通して、はまりポイントやプロトコル実装の楽しさを共有したいと思います。

プロトコルは仕様が決まっていて、その仕様を見てひたすら実装し、最終的にはサーバやクライアントと通信できるようになります。この通信できた時の喜びは非常に大きく、かつ大変勉強になります。通信できるまでの過程も含めて楽しさが伝えられたらと思います。

ある日突然、職場でWebアプリを作ることになりました。
最大の問題は、私にはWebアプリの開発経験がなかったことです。

そこで、完璧を目指すのではなく、まずは60点のWebアプリを目指すことにしました。
その結果、ほぼ知識ゼロの状態から小さなWebアプリを開発し、無事にリリースすることができました。

この経験を通じて、知識ゼロから実装に挑む方々に向けたポイントをいくつかお伝えします。

本トークでは、チームの協働によって生み出されたイベントストーミング図を実際の動作するコードへと変換する手法を紹介します。

イベントストーミングとは、ドメインイベントを中心に据えたワークショップ形式のモデリング手法で、付箋やポストイットを使って、ビジネスプロセスの流れを視覚的に表現していくものです。
ドメイン駆動設計の原則に基づいたシステム開発を実現する上で、開発者とドメインエキスパートの協働を支える効果的な手法として注目されています。

これまで、イベントストーミングのワークショップを行うことで、ビジネスプロセスの理解を深め、チーム間の認識を統一するといったことは成功させてきました。
しかしながら、その成果物を具体的なソフトウェア実装へ昇華させる段階でつまづくことがあります。

そこで、このトークではイベントストーミングで可視化された知識の宝庫を、どのように実装へ導くのかということをテーマに、具体的なアプローチを解説します。
ビジネスドメインの本質を損なうことなく、いかにモデルをコードに落とし込むか、そのプロセスと実践的なテクニックを共有していきます。
また想定コードは先進的なアーキテクチャでなく、一般的な Web サービスを想定としたコードとします。

理論と実装の間に存在するギャップを埋め、モデル図をコードへ落とし込む方法論を学びたい開発者、設計者、プロジェクトリーダーにとって価値ある内容となっています。

◆お話しすること
・イベントストーミング図からPHPコードへの変換手法
・イベントストーミング図を構成する要素の簡単な説明
・ドメインモデルのコード表現
◆話さないこと
・イベントストーミングワークショップの具体的な進め方
・ファシリテーション手法

Webプログラミングに欠かせない「正規表現」。でも、なんとなく 「怖い」「よくわからない」 と思っていませんか？
本セッションでは、業務で出そうな易しめの問題から、書いたら地雷なアンチパターン問題まで、全5問のクイズ形式で楽しく学びます！

動機:

1. 正規表現のシンプルな仕組みを伝えたい
2. 「魔法の道具」ではないことを実感してほしい
   • 通常の言語と「同様に」、関心を詰めこめば、それだけメンテナンスが厳しくなる
3. 複雑な正規表現を避けるための現実的な方法を紹介したい
   • 過去の発表で紹介した内容 (https://zenn.dev/shundeveloper/articles/e6405c323c555a) やライブラリなど

対象者:

1. 正規表現が「なんとなく怖い」プログラマー -> 楽しく学びを提供します！
2. 正規表現が大好きなツワモノ -> 目指せ全問正解!!

参照：

• https://zenn.dev/shundeveloper/articles/e6405c323c555a
• https://zenn.dev/shundeveloper/articles/8f74aa69ed9702
• https://zenn.dev/shundeveloper/articles/b5cc85b4d1e7eb

カンファレンスで今まで知らなかったことやテクニックを学ぶことは多いと思います。その中には下記を感じることはありませんか？

• 実際の業務にどう活用していけばいいのかわからない
• すごくいい発表だったけど、自分のチームに導入することができない
• その時はわかった気がしたが、実際に直面したら活用できなかった

私自身も最初は上記のことがあり、カンファレンスに行く必要があるのだろうかと悩んだ時がありました。
カンファレンスに行き初めて3年と短くはありますが、知識から経験にするために、大事にしている考えを共有できればと思います。

皆さんもここ数年、会社のいたるところで「自動化」を聞きますよね。
必ずと言ってもいいほど、「こういった処理を自動化したいんだけど、詳しいだろうからやってくれない？」みたいなこと起きませんか？
（場合によっては、「なんか動かないから直して！！」もあると思います）

ただし、言われたものをそのまま「自動化」をすると、「思ってたのと違う」「実はこういうことがしたかったんだよね」「コストかかりすぎない？」となることも多いと思います。

本トークでは、実際にあった「自動化」の例を取り上げながら、考えるべきこと、ヒアリングの仕方などを話していきます。

対象の読者

• よく事業部・営業部などに依頼をされることがある人
• 社内にあるあるフローを自動化をしたいと考えている人

プログラミング技術はこの長い歴史の中、Webではいろんな業種のナレッジが共有をされてきました。その中の一つに「共通化」を行い、「車輪の再開発をやめる」や「認知負荷を下げる」といったこと目的で取り組みするのをいたるところで聞きます。

ただし、「共通化」をすることで数年後に見るも無残な姿となり、逆にプロダクトの成長を抑制してしまったり、認知負荷を上げてしまうことがよくあります。

今回筆者が考える、プログラミングで考えるべき「共通化」の考えを中心に、過去経験したアンチパターンを元に話ができればと思います。

対象の聴講者は下記となります。

・プログラミング初心者
・悪い「共通化」がいたるところで見えるけど、どう伝えようか悩んでいる人
・失敗談を聞きたい人

多くのPHPプロジェクトで、知らず知らずのうちに技術的負債が溜まっていませんか？機能追加のたびに修正箇所が広範囲に及び、テストもままならない……。その原因の一つは、オブジェクト指向設計の基礎である SOLID 原則への理解不足や誤解にあるかもしれません。

SOLID 原則はソフトウェア開発において高品質で保守性の高いコードを書くための重要なガイドラインですが、やたら難しい言葉が並んでいるせいで理解が難しかったり、誤解が広まってしまっている面があります。

本トークでは、SOLID 原則に含まれる5つの原則について、アンチパターンやPHP での実践的な例を交えながら解説し、その活用方法や得られるメリットについてお話しします。このトークを聞けば、あなたはSOLID原則を「開発を楽にする武器」として捉えられるようになり、より変更に強く、テストしやすい、自信を持てるPHPコードを書くための第一歩を踏み出せるはずです。

こんな人に向けて話します

• SOLID 原則？何それ知らないよ！って人
• SOLID 原則、聞いたことあるけどよくわからん、って人
• SOLID 原則、完全に理解したけど実践できていない人
• SOLID 原則、理解しているけどどこまでやればいいのか悩んでいる人

自動ユニットテスト、書いていますか？

自動ユニットテストがコードの品質や変更容易性を向上させ、高い開発生産性の実現に寄与することは、もはやソフトウェア開発における共通認識と言えるでしょう。

しかし「どうやって書けばいいかわからない」から脱却できず、自動テストの導入に二の足を踏んでいる現場は未だに多く存在するようです。また「テストを導入した・している」という事実だけで満足してしまい、書いたテストが必ずしも効果を発揮していない、あるいは逆に開発の足かせになっている現場は後を絶たず、「テストは書いているけれど、逆に手間が増えてしまっている」「テストコードが増えすぎて保守が大変になった」といった声を聞くことは珍しくありません。

本トークでは、効果的な自動ユニットテストを書くための考え方やテクニックを、具体例やアンチパターンを通じてわかりやすく解説します。また、動的型付インタープリタ言語である PHP ならではの事情を交えながら、現場ですぐに役立つ知見を共有します。

このトークを聞いて欲しい人

• どうやってテストコードを書けばいいかわからず、導入に踏み切れていない人
• テストコードを書くのが「面倒くさい」「運用が大変」と感じている人
• 自動ユニットテストを書いているが、「これで正しいのか？」と不安がある人
• 良いテストコードを書く技術を身につけて、組織やチーム文化を改善したい人

お話しすること

• 効果的な自動ユニットテストを書くための基本的な考え方とテクニック
• よくあるアンチパターンと処方箋

お話ししないこと

• 自動テスト導入そのもののメリット
• 特定のツールやライブラリ、フレームワークの詳細な使い方
• インテグレーションテストやE2Eテスト、全体のテスト戦略について

ここ数年、私はRaspberry PiでCPUを作っています。
これは、Z80というCPUをコンピュータから取り外して代わりにRaspberry Piで作った自作CPUを取り付けて動かすというものです。

このトークでは私が作成した2つのバージョンのCPUを題材に、以下の様なことをお話します。

• 少ないGPIOで多くの信号線をコントロールする工夫
• CPUを作るというのは具体的に何をするのか
• 手配線で作るCPUと基板発注して作るCPU
• 自作CPUのデバッグ方法
• Linux上でプログラムを動かすことのメリットとデメリット
• 全てを手放して速度を得る - ベアメタル開発

このトークを聞いた方が「CPUを作るというのはどういうことか」をちょっぴり理解し、CPUやハードウェア自作が好きになることを願っています。そしてあわよくば一緒に自作CPUを楽しみましょう！

ここ数年、Raspberry PiでCPUを作っています。
これは、CPUをコンピュータから取り外して代わりに自作CPUを取り付けて動かすというもので、オリジナルのCPUの名前のZ80にちなんでPiZ80と呼んでいます。

PiZ80はZ80採用のパソコン・MSXをあわよくば高速に動かすことを目標にしています。
現在のPiZ80はMSXと同じZ80採用のシングルボードコンピュータ・SBCZ80でZ80よりも高速に動作する様になっていますが、ここに至るまでにはさまざまな改善がありました。

このトークではCPUを作るというのはどういうことか、CPUを作る時にどこに速度的な課題があるのか、そしてMSXでPiZ80を動かすまでの道のりをお話します。

このトークを聞いた方がCPUやハードウェア自作が好きになり、そしてあわよくばPiZ80のソフトウェアをいっしょに改善していけることを願っています！

CPUやプログラムの実行といったコンピュータの"低レイヤ"を知るためにCコンパイラを作成するのはとても良いアイデアです。
Rui Ueyamaさんの「低レイヤを知りたい人のためのCコンパイラ作成入門」はまさにそんな目的で書かれていて、手順どおりに進めていくだけで演算、変数、関数やポインタなど十分にそれっぽいCコンパイラを作れます。
ですが、このドキュメント、C（言語）でCコンパイラを作っていて、それ自体はごく普通のことですがPHPerにとっては若干ハードルが高いんですよね…。
OK。それならPHPでやってみましょう。
このトークではRui Ueyamaさんのドキュメントに従いながらPHPでCコンパイラを作る方法を解説します。
このトークを聞いた方がご自身でもPHPでCコンパイラを作成し、コンピュータの低レイヤを楽しめる様になることを願っています。

2024年1月、「なぜキャッシュメモリは速いのか」が話題になりました。
この質問に答えるのはなかなか難しいのですが近年のコンピュータの高速化はすべてキャッシュによるものと言っても過言ではないぐらいキャッシュは重要な技術です。

このトークでは「なぜキャッシュメモリは速いのか」の説明から、なぜキャッシュが必須の存在なのか、そしてキャッシュが引き起こすCPUの脆弱性について初心者の方にもわかりやすくご説明します。

コンピュータアーキテクチャの勉強、というよりはキャッシュを取り巻くハートウォーミングストーリーを聴きに来るつもりでいらしてください。きっと「CPU脆弱性って言っても思ったより難しくないな」「おもしろいな」と思って頂けると思います。

2024年1月、「なぜキャッシュメモリは速いのか」が話題になりました。
この質問に答えるのはなかなか難しく、X（Twitter）ではいろいろな回答がされていました。この回答はさまざまな立場・理解からされていて、Xのタイムラインをご覧になっていた方はいまいちしっくりこなかったのではないでしょうか。

このトークでは「なぜキャッシュメモリは速いのか」に答えるのに必要な知識を、初心者の方にもわかりやすくご説明します。

• キャッシュメモリとは何か
• なぜキャッシュメモリを使用するのか
• キャッシュメモリとメインメモリは何が違うのか
• 結局なぜキャッシュメモリは速いのか

キャッシュの使いこなしは現代コンピュータにおいて避けることはできず、キャッシュを制するもののみがコンピュータを高速に動作させられると言っても過言ではない状態です。キャッシュを理解し、キャッシュを楽しみましょう！

毎年行っており初心者向けのセッションです！内容は毎年アップデートしております。

【対象】　PHP・プログラミング未経験者、デザイナー、途中で挫折した学習者、非エンジニア

【ゴール】　ChatGPTなどAIを“相棒”に自走学習できる。

【概要】

1. PHPとは ─ Webの大半を支え続ける実態と最新動向をデータで示し、「もう古い」という誤解を払拭。
2. PHPの環境 ─ ローカル環境からクラウドまで様々な環境での利用を紹介。
3. AIと連携したPHP基礎 ─ PHPの簡単な基礎からChatGPT などを用いた学習計画・サポート、VsCode,Cursorなどでのコーディングの仕方など。
4. PHPで動くプログラム ─ 簡単なプログラムをAIを使いつつ、何を考えるべきかを共有します。

セッション後、参加者は「まずは VS Code を開き、ChatGPT に相談しながら最初の PHP スクリプトを動かす」自信と手順を持ち帰れます。

皆さんは、インプットだけでなく、記事を書いたり、LTをしたりといったアウトプットをしていますか？僕は、1年前Qiitaに記事を投稿し始めるまではほとんどアウトプットをしていませんでした。

そんな僕が、去年の2月からQiitaに毎日記事を投稿し始め、約1年でなんと160記事を公開しました。
テーマは主にPHPやReactなど、日々の学びや実践で得た知見です。

「アウトプット経験ゼロ」からスタートした僕が、どのようにして投稿を続け、何を得たのかについてお話しします。

お話しする内容：
• どんな内容の記事を書いたのか（例：PHPのTipsなど）
• 毎日投稿して感じたメリット（知識の定着、反応がもらえる楽しさなど）
• デメリットや大変だったこと（ネタ切れ、モチベ維持など）
• 投稿を通して得られた成長
• やってみて感じた素直な感想

アウトプットって実際どうなの？毎日投稿ってどうやるの？といった疑問に、僕なりの答えを届けられたらと思います。
「自分も何か書いてみようかな」と思ってもらえるきっかけになれば嬉しいです！