皆さん、ASN.1をご存知ですか？

ASN.1とはX.509証明書や電子署名などのデータ形式の定義に使われている抽象構文記法(Abstract Syntax Notation)です。
ASN.1で定義されたデータはPEM/DERなどの形式でエンコードされます。

証明書や秘密鍵などを作成する際のファイル形式としてPEMやDERといった文字を見たことがある方も多いのではないでしょうか。

「DERはバイナリ形式、PEMはそれをBase64エンコードしたテキスト形式」と説明されることもありますが、ではDERのバイナリデータがどのような形式になっているのか説明できますか？

私は最近「電子署名から内部に記載された情報(署名に使われた証明書の発行者情報や有効期限)を取り出したいな」「仕様を読めばライブラリなどを使わなくても独自実装でパースできるのでは」と思い、調べている内にASN.1の存在を知りました。

ASN.1のデータ定義とそれがどのようにエンコードされるかを理解すればバイナリから欲しい情報を取り出せるようになります。

このトークでは証明書からシリアル番号や発行者情報・有効期限などを取り出す実装を例とし、以下について発表します。

• ASN.1やそのエンコード方法(BER/DER)
• それを踏まえたBER/DER形式のデコードのPHPでの実装例
  • PHPでのバイナリのパース方法
  • バイト列の読み取り・管理
  • ビット演算を用いた特定ビットの判別や複数バイトで構成される値の読み取り

身近にある存在の仕組みを少し深堀りしてみると面白い世界が広がっています。

この発表を通して、色々な仕様に使われているASN.1の面白さ(とややこしさ)に触れてみましょう。

常に最新のセキュリティ更新を取り込み続けるためには、PHPのバージョンアップだけでなく、将来予定されているPHP 9の破壊的変更にも備えておく必要があります。

20年以上開発が続いている巨大なコードベースを持つプロダクトにおいて、使用している静的解析ツールの見直しを進めましたが、長い歴史の中で積み重なったコードとの互換性の課題や解析速度の問題に直面しました。移行作業を進める中でPhanのアップデートもあり、さらにPhanで見つかった一部の問題を自分たちでコントリビュートして解決しました。その結果、継続可能性と現実的な保守コストを踏まえ、引き続きPhanを使うという判断に至りました。

本トークでは、こうした検討と意思決定の過程を踏まえ、PHPのバージョンアップ時に発見した静的解析ツールの問題をOSSへのコントリビューションによって解決した事例や、個人的に注目している高速なMagoの検証例を通じて、巨大で歴史あるコードベースにおける静的解析ツールの効果的な活用法を考察します。

ActiveRecordは爆速開発を支える「手軽さ」の象徴ですが、プロジェクトの成長と共に「DB構造とロジックの密結合」という呪縛を生みます。本セッションでは、クリーンアーキテクチャの理想を掲げ、Laravel Eloquent（ActiveRecord）からDoctrine（DataMapper）への移行を試みる中で私たちが直面している、「手軽さと堅牢さの折り合い」についての葛藤を共有します。

移行の大きな動機は、インフラ層での「Eloquentモデルとドメインモデル」の二重管理による、泥臭い値の詰め直し（インピーダンスミスマッチ）を解消することにありました。DataMapperがマッピングを吸収することで、ドメインは純粋なPOPOとして振る舞い、開発者は「値の移し替え」という苦行から解放されるはずでした。

しかし、そこで待ち受けていたのは、一筋縄ではいかない設計の「コシ」でした。不変条件を守るための「イミュータブルな設計」を目指すと、DataMapperの核心である「Unit of Work（変更検知）」の仕組みと真っ向から衝突します。「手軽さを維持したいが、堅牢さも譲れない」。この両者の間で、私たちは今まさに最適なバランスを模索しています。

・EntityとValue Objectの役割分担をどう定義し直すべきか ・セッターを排しつつ、UoWとも共存できる「制御されたミュータビリティ」の探求 ・ドメインイベントを明示的に扱うことで、設計の透明性をどう確保するか

本セッションでは、現在進行系で理想のアーキテクチャと選定技術の「相性」にどう折り合いをつけ、チームで納得感のある設計を言語化してきた内容を紹介します。「手軽さ」と「堅牢さ」。その間で揺れ動きながら、長く愛されるシステムのための「最高のコシ」を共に考えてみませんか。

全国各地で開催されているPHP系のカンファレンス。
それぞれの地域には、異なった「空気」や「こだわり」があります。

PHPコミュニティは技術だけでなく、人の熱量や思想によって形作られています。
本セッションでは、各地のPHPイベント主催者・実行委員長を招き、表側には見えにくい部分＝「コシ」の作り方に焦点を当てます。

あまり語っていないような「実行委員長の裏側」を掘り下げます:

• 何を大事にしているのか
• 譲れないこだわり・細部へのこだわりは何か
• 他地域のカンファレンスにどんな魅力を感じているか
• 今後行われるカンファレンスの"みどころ"を勝手に語る

参加者は以下のようなエッセンスを持ち帰れます:

• PHPコミュニティの雰囲気がわかる
• 各地域イベントの違いが見える
• 「魅力づくり」の彩色の幅を知る
• 主催者の“コシ”を感じられる

深夜メンテ。
まれであれば遠足気分（？）で楽しかったりしますが、頻繁にあると生活リズムを崩してしまいますし、不慣れな作業なら「もし未知のトラブルに遭遇してサービスを長時間ダウンさせてしまったら・・・」など、不安も尽きません。

本トークでは主にWebアプリケーションのメンテナンスを日中にやるための交渉術や、ユーザー影響を抑えて日中に行うためのテクニックについてご紹介します。

想定観客

• 深夜メンテをしたくない、部下・同僚にさせたくない人

お話しすること

• 深夜メンテをしない合意形成のポイント (お気持ち、リスク、賃金など)
• 落としてはいけない機能と時間を明らかにする
• 後方互換性の確保、並走

JetBrainsのMPSは、外部DSL(ドメイン固有言語)を作成するためのIDEです。
DSLの文法自体を定義し、それをターゲット言語に変換するための仕組みを用意できます。
つまり、「独自の使いやすい文法で書いてもらって、PHPのコードに変換する」ことが可能です。

DSLの利用は、あなたのチームの開発の効率を高めるかも知れません。
余計なことが出来ない・無駄なことを考えなくて良いように、「必要なことにだけ集中する」ための強力なガードレールとして機能します。

必ずしも「独自の文法」を利用する必要はなく、JSONやYAMLを利用したり、あるいはPHPの文法の範疇で書かれた内容でも、多くの場合は事足りるでしょう。
とはいえ、「もっと良い方法」の引き出しがあるに越したことはありません。例えば、非開発者とのコラボレーションの手助けにもなりえます。
(・・・一度はやってみたくなりませんか？)

そして、MPSは普段使っているようなIDEとはかなり様子が違った、
悪く言えばクセが強い、よく言えばクセになるようなIDEです。
公式ドキュメントの表現を借りると、
「テキスト形式を避けることによって他の多くの言語ワークベンチとは一線を画しています。あなたのプログラムは常に AST で表されます。」
と記述されています。ちょっと面白そうだな、と感じませんか？
この独自の世界観を、ちょっと体験できるようなトークをします。

話すこと

「素朴なDSLの作成」を題材としてウォークスルー的に追体験しつつ、MPSとその基本的な概念について紹介します。
今後ふとした時にちょっと便利な武器になるかもしれない、そんな知識を持ち帰ってください。

あなたも Laravel 用のパッケージ（composerライブラリ）を作って公開しませんか？

実際に作成したパッケージを例に、アセットの公開、config や migration の活用、オーバーライド可能な view など、開発者にとって使いやすいライブラリを作るための勘所をご紹介します。