トーク

便利なものが大好きなので、「Composerを使いこなしたい」「ここ数年で現れた機能も試してみたい」という願望が私にはあります。皆さんもきっとそうです。
その中でも「書き味が良くなるやつ、便利なやつ」と「パフォーマンスが上がりそうなやつ、便利なやつ」がありますよね。
前者について、例えばPHP7.4のプリロードがあります。

プリロードと初めて聞いた時に、「ではフレームワークやライブラリのコードを予めメモリに乗っけちゃおう！」と興奮した人も多いかと思います。
・・・本当に乗せていますか？

さて、そんな時に助けてくれそうなayesh/composer-preloadというパッケージがあります。
see: Packagist
これはComposer Pluginです。
READMEを見ると Composer Preload is a composer plugin aiming to provide and complement PHP opcache warming. と記述されています。

どんなアイディアでそれを実現し、どんな仕組みになっているのでしょうか？
簡単に内部に触れてみましょう。

「オブザーバビリティ」や「可観測性」という言葉は、耳にしたことがある人は増えてきていると思います。
あるいは、「全く知らない、想像もつかないよ」「また新しい "ﾅﾝﾁｬﾗlity" が出たんですか？」なんて人も多そうです。

PHPを趣味や仕事で使っている人は、Webサービスやモバイル等のバックエンドを提供しているケースが中心でしょうか。
「今もどこかの姿が見えない誰かが使っているかも知れない」「その人たちが、自分たちが提供しているサーバーにアクセスしている！！」
というのが、Webサービスの難しさであると同時に単純・嬉しいところでもありますよね。
すなわち、「何が起きているか」は「自分たちの目の届く所に集約されている」と。

オブザーバビリティとは、「いかに状態( = 上手くいっていること・問題が起きていること)が把握可能になっているか」という性質です。
放っておいても実現されるものではありません。
意識して、設計して、運用して・・・初めて手にすることができるものです。

これは単なる「ツール」「技術」の話ではないのです。
チームないし文化まで含めて、「どう向き合っていくか」を突き詰めた先にオブザーバビリティがあると考えています。

本セッションでは、「継続的に、かつ自信を持ってサービスを提供し続ける」ために大事なことを、
書籍「Observability Engineering」の内容をベースにしながら紹介していきます。
「SRE」「インフラ」「運用」 ではない 人達に向けた 、どうしてアプリケーション開発者が向き合っていくべきなのだろう・・？という話です。

皆さんはコードを読む時の工夫って、どんなものがありますか？
私は「脳内にスタックトレースを溜めておくの大変だぜ〜、すぐ混乱するぜ〜」となるので、その辺りは便利な道具で補いたいなあと思っています。

ここ暫くは、デジタルホワイトボードツールのMiroというサービスがお気に入りでして、ある時に「これは自分の思考を整理したらアイディアを繋ぎ止めておく時に使うツール・・・という事は！何かの複雑なコードを読む時にも、大活躍してくれるのでは！？」と閃きました。

実際に使ってみると、とても良かったのです。

本トークでは、実際にどんな風に使ったの？どう便利だったかな？？を、体験談を盛り込みながらお話します。
複雑なコードや難しいソフトウェアも、これで少しは読みやすくなるかもです。

ソフトウェア開発、色々な場面で人とのコラボレーションを求められがちですよね？
例えば、アジャイル系のフレームワークやプラクティスを採用している・していないに関わらず、ふりかえり(retrospective)を行っているチームは増えてきていると思います。
それ以外にも、チームビルディングの場面だったり、プロダクト開発のためのブレインストーミング、もしくはポストモーテムにおいても参加者それぞれの視点が出揃うことが求められます。

理想的なのは、そこにいる全員が同一の目的を持って主体的な意思表示と議論に参加できている状態です。
そのために、場をファシリテーションする人には「発散」と「収束」を効果的に行うことが求められます。
しかしながら、単純に意見を求めるだけでは達成が困難な事も多いです。その壁を破るためには工夫や知見が必要になります。

どのようにしたら、参加者に思考を促し、高いレベルでのコラボレーションが実現されるでしょうか。
思考を促進するための接し方として、「問いかけ」や「発問」と呼ばれるものがあります。
ファシリテーターが、これらの概念や観点・技法を自らの引き出しに入れておくことで、今までとは少し違った議論が生まれるかも知れません。

本セッションでは、テクニックと態度の両面から「どのように場を回す工夫をするか」を共有します。

話すこと

• 参加者の主体性を引き出すための会議の基本設計
• 「問いかけ」とは何か
• 創発的な場作りのためのいくつかの工夫、引き出し

主な参考書籍(一部)

• 問いのデザイン / 問いかけの作法
• ファシリテーター完全教本
• ゲームストーミング
• アジャイルレトロスペクティブズ
• 会議のマネジメント

概要

• xUnit Test Patternsって、どんな本なの？どんな事が分かるの？を紹介します

想定する対象者・レベル

• ユニットテストを書いているけど自信がない/しっかり勉強したことがないかも・・という人
• その本の名前は聞いたことがあるけど、実物は見たことがない・読んだことがないぜ・・という人
• 「良いテスト」あるいは「テストを書く時に考えるべきこと」を言語化したい、理論を身につける術を探している・・という人

イントロ

現代的な開発において「テスト」は欠かせません。
そして、「ソフトウェアテスト」あるいはその中の「自動化テスト」といっても、それぞれに様々な手法や戦略、ねらいと目的、それらを実現するためのツールなどがあります。

その中でも、普段の開発において、我々のような開発者・プログラマーにとって最もなじみ深いのは「ユニットテスト」ではないでしょうか。
この分野における古典的ともいえる名著の一つに、「xUnit Test Patterns(xUTP)」があります。名前だけは聞いたことがある・・という人も沢山いるかと思います。
一体どんな本なのでしょう？内容が気になるものの・・・気軽に手を出すには、分量的にも価格的にも重い一冊と言えます。

読んだ方が良いぞ！！！と思っていても、未読のままの人も多いのではないでしょうか。
重い本を読むための勢いが欲しいですよね。
まずは、「どんな事が書かれているのか」「(頑張って読むことで)どんな知識を得られそうなのか」という期待値設定のための案内があれば嬉しい・・・と思いませんか？
本セッションは、そんなガイドとなるべく、「xUTPの入り口まで近づいて見てみる」をテーマに話をします。
xUTPが、テストに強くなりたいあなたの味方になるかも知れません！！

本セッションで得られること・ゴール

• 「有名だけど読んだことがないメッチャ重そうなあの本」について、内容を把握できる
• それによって、今の自分に必要か？が想像できるようになる

本セッションで話すこと

• xUnit Test Patternsとはどんな本なのか
• 各パート・各章にはどんなことが書かれているのか
• 書名にもなっている「パターン」は、どんなものが書かれているのか
  • サンプル的にいくつかのパターンの紹介
• どんな時に読むと良いか。どんな使い方をすると良さそうか

プログラミングを始めてから、一定のペースで「プログラミング歴」が伸びています。
最初の1年、暫く経った5年、それすらも超えて10年・・・と時間は流れていきますが、それでも変わらないのは「学び続ける課題がある」という事です。
環境の変化も伴いながら、それでも学び続けるのです。
例えば「後輩や部下に対して指導するようになった」とか「マネジメントの仕事が増えて、業務でコードを書く時間や必要性が減った」など。

学習方法や身につけるべきスキル・知識などは千差万別で、一般化して語ることは難しいですが、「いちヒントとして、どのような姿勢で学びを得ていく事が出来そうか」を本セッションで共有します。

参考にしそうな書籍など(仮)

• アプレンティスシップ・パターン
• スーパーエンジニアへの道
• ソフトウェア職人気質
• Clean Craftsmanship
• プログラマが知るべき97のこと

Composerはとても便利で、生活必需品ですね！！
ただし、狭い意味での composer install を考えると、 「composer.lockを読み取って」「ファイルをDL・解凍・規定のパスに配置する」というだけです。

もし、Composerの中身(実装)を読んで、仕組みを理解して、気持ちに寄り添う事ができれば・・・
必ずしも「PHPプログラム」ではなくても良いかも知れない。PHPの世界を飛び出して、Composerを実現する！！！
そんな夢を、私は見ました。

本LTでは、「composer installのためのツールを、Goで作ってワンバイナリで動かせるようにする」をテーマに

• どのような実装になるのか
• (PHPと比べて)実装の差異はどのように現れてくるか / PHPの弱点を補ったり、Goらしい味を出せるのか
• もしかしたら何かの実用性もあるのか

と言った点に触れてお話をします。

現代のPHPには、既にComposerは欠かせないものになりましたね！
これ1つで、様々な機能やソリューションをもたらしてくれるツールです。

そんな便利なComposer、もっと仲良くなりたいことでしょう。
読んで、把握して、自ら作ってみるのはいかがでしょうか。
PHP自体の機能を利用しないと行けない機能(例えばPHP自体の実行を伴うCommandのフックなど)は難しくても、
「composer.lockを読み込んで(なぜなら純粋なJSONだから！)」「vendorディレクトリにソースを展開する(それってファイルのDLと展開ですよね！)」といった処理くらいならできそうに思いませんか。

やってみましょう！

やること

• composer install の実行する単機能ツールをGoで作成し、その解説
  • composer.lock が事前に生成されている事を前提

本セッションで得られるかも知れないこと

• 一歩引いて考えた「Composerの仕事は何で、どういう仕組みか」という理解
• 「非PHP実行環境で、ワンバイナリでcomposer installが実行可能になったら何か便利なことある？」という考察

PHP_CodeSniffer(phpcs)は、「コードの書き方に規則を持たせようよ！！」を支援してくれるツールです。
予め定義したルールセットに従って、開発時のローカル環境やCI環境上で「ルールに沿っていないコード」を検出し、指摘してくれます。
また、同梱のphpcbfコマンドを利用することで、簡単な整形を機械的に行うことも可能です。

そんなphpcs、利用中の方も多いと思います。
では、中身はどうなっているのでしょう。どうやってPHPで実現しているのか・・気になりませんか？
「なぜphpcs/phpcbfは動くのか」を実際のコードから紐解いて見ます。

話すこと

• phpcsの基本的なライフサイクルや概念
• phpcsの中身(コード、実装)
  • 例えば「Sniff」とは何であり、どのように読み込まれて利用されるのか
• phpcbfの基本的なライフサイクルや概念、処理の流れ

得られるかも知れないこと

• phpcsを”理解”することによって、独自のsniffやrulesetを扱いやすくなるかも知れません

イントロ

リーダー未経験の私は、現職で働き始めてからの2年間で、初めてProject Leader→Tech Lead→Engineering Managerと任命されることになりました。
「影響力を発揮してね！」とか「リーダーシップを持ってね！」などと言われます。
・・が、一体どうしたら「それらをよく発揮してくれたね！！」と認められるようになるのでしょうか。
自分で道を切り拓いてこそリーダーだ！！という考え方も分かりますが…

マネジメント系のキャリアを目指す人、あるいは運命的にそれに任命された人、今の環境に何らかの物足りなさを感じる人、etc.。
私以外にも、色々なところに「じゃあリーダーシップって何？」に関心を持ったりモヤモヤしている人はいるかと思います。

概要

このセッションでは、
アジャイル(主にScrumやXP)ついて勉強したり、メンバーとの1on1で聞いた声や反響、認定アジャイルリーダーシップ研修Ⅰ(CAL-1)で学んだことを踏まえながら
「(プロダクトの開発組織における)リーダーシップってなんだろう、何を求められているんだろう？」についての自分なりの考えを共有していきます。
「リーダーシップについて駆け出した/駆け出そうとしている人」に向けてのヒントになればと思います。
それらのテーマに向き合うことで、日常の仕事の中においての「自分が何を目指すか」「チームの進化にどう繋ぎ込むか」を探っていきましょう。

想定する聞き手

• Engineering ManagerやLead/Leaderとして駆け出した人
• そうしたポジションをこれから目指したいと考えている人
• 職場で「リーダーシップ」を求められるけど、それが言語化されていなくてモヤモヤする人

参考にする書籍の例(一部)

• みんなでアジャイル
• エラスティックリーダーシップ
• LEADING BEYOND CHANGE
• The Agile Leader
• ポジティブ・チェンジ

アプリケーション開発をしていると、どうしても不具合は生まれます。
バグ、障害、故障、エラー…近接する概念が色々とありますが、その中でも「プログラムetcの修正で修復できるもの・根治できるもの」が確かに存在します。

実際の所、皆さんのサービスで、それらはどのくらい発生しているでしょうか？その内、直せるはずの「バグ」「欠陥」はどのくらいあるでしょうか？
パッと答えが浮かばない、という方も多いと思います。
どうやってこの状況を脱していきますか。

とにもかくにも、「可視化」「現実的な目標」「コントロール可能な状況を作る」「割れ窓状態を脱する」のが重要だと思います。
そして、それに勝るとも劣らず「なぜ、エラーを少ない状態を実現したいのか。そこにどんな価値があるのか」という認識の統一も欠かせません。
チーム全体を方向づけ、小さな実践を押し進めながら「それらは夢物語なんかじゃない」と勇気づけるような成果を上げていきましょう。

本セッションでは、まずは「エラーやバグがもたらす不経済」について説明します。併せて「なぜ、検知と修復を急ぎたいのか」「遅れが何をもたらすか」も扱います。
その後に、自身の体験も踏まえながら「どうやって・何を努力していき、チーム一丸となって”エラーを減らす”を実現していくか」について共有します。

想定するオーディエンス

• 「エラーを減らしたいな」「バグを減らしたいな」という気持ちのある人
  • もしくは「減らせるのだろうか」と気にしたこともなかった人
  • とはいえ「ガチガチのレギュレーション」や「窮屈さ」は望んでいない人
• チームの生産性に課題を感じている人、向上させたいと考えている人

本セッションで得られるもの

• 「なぜエラーを減らしたいか」の理論的な背景、根拠となりそうな情報
• 組織として、どのようにエラーやバグを減らしていくか？という導入-出口の戦略
• アプリケーションエラートラッキングツールの活用方針
  • Sentryの利用を想定しています

本セッションで話さないこと

• アーキテクチャや「良いコードの書き方」といった、品質面の話

関連リンク、参考書籍

• ウェッブアプリケーションのエラーを無くしていきたいわよねという話 - 大好き！にちようび
  • 過去に、エラー管理についてのスタンスについて吐き出した自ブログの記事
• LeanとDevOpsの科学
• This is Lean
• レガシーコードからの脱却
• アート・オブ・アジャイル・デベロップメント
• アジャイルプラクティス