CPUやプログラムの実行といったコンピュータの"低レイヤ"を知るためにCコンパイラを作成するのはとても良いアイデアです。

Rui Ueyamaさんの「低レイヤを知りたい人のためのCコンパイラ作成入門」はまさにそんな目的で書かれていて、手順どおりに進めていくだけで演算、変数、関数やポインタなど十分にそれっぽいCコンパイラを作れます。

ですが、このドキュメント、C（言語）でCコンパイラを作っていて、それ自体はごく普通のことですがPHPerにとっては若干ハードルが高いんですよね…。
OK。それならPHPでやってみましょう。

このトークではRui Ueyamaさんのドキュメントに従いながらPHPでCコンパイラを作る方法を基礎から解説します。

・x86マシン語とプログラム実行の基礎知識
・最小限のコンパイラの実装
・ユニットテストを書きながらの1ステップずつの機能追加
・自作したコンパイラで自分自身をコンパイルする"セルフホスト"に向かう道

このトークを聞いた方がご自身でもPHPでCコンパイラを作成し、コンピュータの低レイヤを楽しめる様になることを願っています。

Clean Architectureを使えば変更に強いソフトウェアが作れる、アプリケーションの寿命を時代の進歩に合わせて更新し、ビジネスに価値を届け続ける
そんな理想を夢見て、Clean Architecture を導入した、または導入したいと考える方は多いのではないでしょうか

ユースケース層まで丁寧に分離したつもりでも、実際には DB 依存が思わぬ場所に残り、「この設計は本当に変更に耐えられるのか」と不安になる瞬間があります
Clean Architecture は理想的だと言われますが、いざ大きな変更が発生したときに本当に価値を発揮するのか、設計原則の“手応え”を確かめたいと思ったことはありませんか

本セッションではその疑問を検証するために、Laravel のアプリケーションを設計ごと Symfony へ移行するプロセスを可視化します
対象とするのは 2 種類のユースケース：①ドメイン層が純粋に保たれているロジック、②Eloquent 依存が進んだロジック、それぞれの移行過程を比較し、前者では構成と DI の置換だけで動作し、後者では Repository 抽象の導入など、追加のリファクタが必要になることを示します
その過程を示し比較することで設計が継承できる / できない境界線を感覚ではなく、コードで理解します

Clean Architecture がなぜ必要か、そのためにどれだけの実装コストがかかるのか、そして構造を超えて設計を継承する方法を一緒に学びましょう

• お話すること
  • Clean Architectureが変更に強いか設計ごと移行して検証
  • ドメイン層の純度による移行の難しさとリファクタの観点を紹介
• 想定聴講者
  • Clean ArchitectureやDDDに関心がある方
  • 設計を再利用・継承したい方

「抽象化していますか？」ーー抽象化と聞くと、設計やモデリングをイメージするかもしれません。他にも、interface のような言語機能を利用することを思い浮かべる方もいるかもしれません。たしかにこれらも抽象化の一つですが、それだけではありません。また、抽象化には難しそうなイメージを持たれがちですが、実はソフトウェア開発を行なっている私たちにとっては日々利用している身近なものです。

本セッションでは、抽象化（と具体化）という考え方を整理し、設計や言語機能だけでなく、物事の理解や共有、課題解決、トラブルシューティングといった開発現場の広い場面でも活用できる「思考の技術」として具体的な例とともに紹介します。

「使える思考のツール」として抽象化を一緒に見ていきましょう。

転職を機に新規でアプリケーションの実行環境を作ることになり、0から構築しました。もちろん今までに構築した環境をベースしましたが、セキュリティの向上という課題を踏まえて、
ここ数年話題に登ることが増えてきたDevOpsにセキュリティを意識した取り組みを組み込むDevSecOpsを意識して環境を構築しました。

新たな環境の構築に際してセキュリティを意識した自動化の取り組みをどのように組み込みつつ、効率的な開発プロセスを維持するために意識したことや、取り組みの具体的な方法と実践例をご紹介します。

はじめに

PHPの最新版は8.4になり、かなり進化しました。7.0が出たのはすでに10年前。
巷ではモダンなフロントエンド技術が流行っており、PHPerは圧倒的な高齢化の一途を辿っています。
「うちの会社は割と若い人もいるよ！」と思ったそこのあなた。では一番コード書ける人、一番技術力ある人も同じく若い人たちですか？

10年前、第一線で活躍してた人が今もポジション変わらずの状態であればイエローサインです。
PHP界の高齢化を防ぎ、若手が育ちやすい“新陳代謝のある”文化をつくっていきましょう。

ちなみに私は過去COBOLのプログラマーを「おじいちゃんばっかりじゃん」と思っていた時期がありますがそんな自分を殴りたい。

話す内容

• PHPは素敵な言語
• 勉強会による間口を広げるご提案
  • 老害化の注意点
• 他言語とのコラボを狙う
  • 例えばSPAのフロントはJS、API側PHP、というご提案
• PHPの普及ではなくPHPで作られたものの普及を考えてみる
  • 言語の良さを説いても限界がある
  • 魅力的なPHP製品の良さを伝えて、メンテをする楽しさを伝えてみる。WordPressとかEC-CUBEとか

技術の話よりかはPHPerのコミュニケーションの話です。
意見も聞きたいので、みなさんにも意見を聞きながらセッションを進めて行きたいと思っています。
一緒に高齢化阻止の方法を考えましょう

こんな人は聞いてほしい

• PHPの良さを改めて知りたい人
• PHPの良さって何なんですか？と言われてアピりたいけど答えに詰まってしまう人
• 最近若い人減って来たなぁと嘆いてる人
• もっとPHPerを増やしたい人
• ↑のように思ってるのに若者にマウントを取ってしまう人

ライブコーディングで、"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の作成

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

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

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

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

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

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

【概要】

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

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