昔作成したPHPUnit/TDDの記事内容を更新してGitHubに置きました

昔CodeIQにPHPUnitでTDDを行う記事を寄稿したのですが、CodeIQが閉鎖になって以降、「あの記事また読みたい」とリクエストがあったため、内容をわずかに更新してGitHubに置きました。

github.com

以前作成したコードの日付をみたら5年前だったんですね。書き方がいろいろ古い箇所があったため、比較的最近っぽい(PHP 7の)書き方に修正してあります。

解説の仕方や図など、今見るとうーんとなってしまう点もありますが、この内容でもリソースとして役立ちそうなので、そのあたりはいずれブラッシュアップするということで、一旦公開します。

 

メモ:ドメイン駆動設計におけるモデルの効用と、モデルが満たすべき3つの基本的用法(私訳)

日本語版『エリック・エヴァンスのドメイン駆動設計』p.3の、「ドメイン駆動設計におけるモデルの有用性」の部分、大事なことを言っているような箇所なのに、文章のつながりや意味がイマイチとれなかった。そこで原著Kindle版を購入し、原文から自分なりに訳してみた。(私の訳文は若干補足的な文章になっている)

なお、この箇所は見出し(効用/有用性)と、中の箇条書きの構造とがマッチしていないので読みづらいのだと思う。各箇条書きの最初の文が「基本的使用方法」、つまり、モデルに求める条件となっていて、それを満たすとどのようなありがたいことがあるのか(=効用/有用性)の説明が続く、という構造なのだと思う。

 

The Utility of a Model in Domain-Driven Design

ドメイン駆動設計におけるモデルの効用

 

In domain-driven design, three basic uses determine the choice of a model.

ドメイン駆動設計では、モデルが満たすべき3つの基本的用法をチェックして、モデルの候補の中から使うモデルを決定する。

  1. The model and the heart of the design shape each other.
    そのモデルは、設計の核心と相互に方向付けあっていること。
    It is the intimate link between the model and the implementation that makes the model relevant and ensures that the analysis that went into it applies to the final product, a running program.
    モデルと実装とのリンクが徹底されていることこそが、モデルを実用的な地に足のついたものにする。また、モデルに行われた分析を最終的なプロダクト、つまり動くプログラムに適用することを保証する。
    This binding of model and implementation also helps during maintenance and continuing development, because the code can be interpreted based on understanding the model.
    このようにモデルと実装が結びついていると、メンテナンスや継続的な開発においても役立つ。モデルの理解に基づいてコードを読むことができるからだ。

  2. The model is the backbone of a language used by all team members.
    そのモデルは、チームメンバー全員が使う言語の骨格となること。
    Because of the binding of model and implementation, developers can talk about the program in this language.
    モデルと実装とが結び付けられているおかげで、開発者がプログラムのことを話す際に、この言語を使える。
    They can communicate with domain experts without translation.
    開発者がドメインエキスパートとやり取りする際に、言葉を翻訳して伝える必要がない。
    And because the language is based on the model, our natural linguistic abilities can be turned to refining the model itself.
    言語がモデルに基づいているため、私たちが持つ自然言語能力を、モデルそのものの改善に役立てられる。

  3. The model is distilled knowledge.
    そのモデルは、知識を蒸留していること。
    The model is the team's agreed-upon way of structuring domain knowledge and distinguishing the elements of most interest.
    モデルは、ドメイン知識をどのように構造化するか、および、ドメイン知識の中で最も興味のある要素をどのように識別するかについての、チームの合意を表す。
    A model captures how we choose to think about the domain as we select terms, break down concepts, and relate them.
    私たちがドメイン知識のなかから用語を選び、概念を分解し、それらを結びつけていくにつれ、モデルは、ドメインについてどのような見方を選択したのかを捉えるようになる。
    The shared language allows developers and domain experts to collaborate effectively as they wrestle information into this form.
    開発者とドメインエキスパートが、ドメイン知識に取り組みモデルを形作っていくにつれ、共有された言語が生まれ、開発者とドメインエキスパートが効果的にコラボレーションできるようになる。
    The binding of model and implementation makes experience with early versions of the software applicable as feedback into the modeling process.
    モデルと実装とが結びついていると、ソフトウェアの初期バージョンの利用経験を、モデリングプロセスへのフィードバックとして使えるようになる。

 

PHPカンファレンス関西2018で「続・SOLIDの原則ってどんなふうに使うの? オープン・クローズドの原則 センパイのコーディングノート編」を話しました

7月14日に開催されたPHPカンファレンス関西2018で、『SOLIDの原則ってどんなふうに使うの? オープン・クローズドの原則 センパイのコーディングノート編』というトークをしました。

2018.kphpug.jp

今回のスライドは以下です。60分という長めのセッションでしたが、聞きにいらしてくれた皆様、ありがとうございました!

 

SOLIDの原則シリーズのトークはこれで完結

PHPerKaigiから3回にわたって、「SOLIDの原則ってどんなふうに使うの?」シリーズのトークをしてきました。私の中では、それぞれのトークのポイントは次のようになっています。

どの回も私にとってはチャレンジングな内容でした。PHPerKaigi版では、いかにオープン・クローズドの原則のポイントのようなところを、腑に落ちるように伝えられるかというところが難しく、最終的な形式になるまでにかなり苦労しました。なお、オープン・クローズドの原則を直球で説明している部分も、「アジャイルソフトウェア開発の奥義」に書かれていることをベースに、よりクリアにした私オリジナルの内容になっています。

PHPカンファレンス福岡版では、PHPerKaigi版の内容をブラッシュアップしつつ、伝えたい内容を追加してすこしフォーカスをずらしたので、話のまとめ方、そして時間配分に苦労しました。

最後のPHPカンファレンス関西版では、福岡とはまた違った内容をプラスしていて、この部分の話をちょうど良い感じにまとめるだけでもかなり苦労しました・・・。追加したい内容の部分がかなりのボリュームになってしまったので、削りつつ、ストーリーを変更するということの繰り返しですね。

そして今回の関西のトークで、オープン・クローズドの原則を軸にした一連のトークは、完結となりました。聞いていただいた方には、やや消化不良な箇所があったかと思いますが、それは今の所の私の力量不足です。スミマセン! この一連の話は私の持ちネタとして、少しずつ改良を重ねていく予定です。

裏話:掛け合い方式がなぜ生まれたか?

センパイとコウハイの掛け合い方式は、最初からそのように考えて作ったものではなく、偶然の産物としてできたものでした。私はソフトウェア開発者としてある程度の経験を持っており、そのような立場として設計などについて説明すると、どうしても説明を端折ったり、そんなこと知っていて当たり前、というような空気で前提を作ってしまうところがあります。そういう、言い方は良くないですが「上から目線的」な話がウケる場合もあることは確かですが、今回の一連のトークでは、それとは違うアプローチにしようと思っていました。それは、より多くの人にきちんと伝わるトークにする、というものです。そのために、話の細部に渡って、聞いている人が「なぜそうなるの?」とか「あれ? わからない」となって話についていけなくなる、という箇所がなくなるよういろいろ工夫しました。その工夫の中で、話す内容についていちいち自分で「なぜそう言えるのか?」「新人が聞いても分かるか?」「新人ならどう考えるか?」などと自問しながらストーリーを磨いていました。そんなことをしていると、ふと、「この質問自体を共有した方が伝わるんじゃないか?」と気づいたんです。

これを入れたのは、今の私のトークスキルとしては、成功だと思っています。

もっとうまいやり方はあると思いますし、話者が質問を最初からいれなくても、会場からのリアルタイムな質問を引き出せれば、もっと面白いですよね。そして、熟練した話者なら、そんなリアルタイムの質問にうまく答えつつ、それさえも自分の話の流れに組み込んでしまうものですよね。そんなふうになれるよう修行せねばと思います。 

今回のトークの反省

  • スクリーンの左側に立つパターンに慣れていなかった。マイクを左手で持って、右手でスライド操作&水を飲むという感じで、スクリーンの方を指す場合は右手を使うのだけど、方向が逆なのでちょっとやりづらかった。右手マイクでやれる方がよいのかもしれない(対策未定)。
  •  思っていたより、スライドの下の方まで見えるようにスクリーンが調整されていたので、スライドでは下いっぱいまで使った方がよかったかも。
  • スクリーン表示が予想よりちょっと小さく、クラス図やコードの文字は読みづらそうだった。このあたりは、コード量が多いプレゼンテーションの場合の正解が分からない。(話している部分を拡大というのを手軽に作れればよいのだけど。。。)

イベントについて

PHPカンファレンス福岡でも感じましたが、このPHPカンファレンス関西でもスポンサーさんがたくさん集まっているというのが本当にすごいなと思いました。また、参加者もたくさんいらっしゃって、カンファレンスがすごく盛況だなと感じました。

スポンサーブースを回ってカードを集めるという面白い企画も用意してあって、このカード集めの際に、自然とブースの方と話せるようになっていて、上手い企画だなとも思いました。

いろいろな工夫をしてカンファレンスを準備してくださったスタッフの方々、ありがとうございました!

次回は?

未定です!

東京で開催されるPHPカンファレンス(12月15日) か、何か他の小さなイベントなどでも、気分やネタの準備状況によっては参加するかもしれません。

参加するならやはり発表者として参加し続けたいので、次なる渾身のトークアイデアを練ろうかと思います。

phpcon.php.gr.jp

 

PHPカンファレンス福岡2018で「SOLIDの原則ってどんなふうに使うの? オープン・クローズドの原則編(拡大版)」を話しました

6月16日に開催されたPHPカンファレンス福岡2018で、『SOLIDの原則ってどんなふうに使うの? オープン・クローズドの原則編(拡大版)』というトークをしました。

phpcon.fukuoka.jp

 

スライドは以下です。スライドだけでも十分内容が伝わるように作っていますが、しゃべりでしか言っていないこともたくさんありますので、動画がアップロードされたらそちらを観ていただきたいです。

 

このトークにかける思い

私はプログラマになりたての頃から、ソフトウェアの設計が好きでした。これまで独学だったり師匠や先輩方からのご指導だったりで揉まれながら、さまざまなことを学んできました。そんな学びの結果、私に身についたといいますか、師匠や先輩方から授かったという方がよいのかもしれませんが、ソフトウェアやコードの設計に対する「目」というものがあります。この「目」は、ソフトウェアのソースコードを見た時に、その設計の具合を嗅ぎ取る目です。

自分のことを振り返ってみても、決して最初から意識してこのような目を手に入れることを目指した、ということはありません。さまざまなことをしてきた結果、そのようなものが身についているらしいということにやっと気づいたというのが正直なところなのです。

ですので、「この目を手に入れる方法」を自分ではっきり見いだせているわけじゃないんです。そのかわりに、「この目では、物事がどのように見えているのか」を伝えてみよう。それが、今年の一連の「SOLIDの原則ってどんなふうに使うの?」シリーズのトークにかける私の思いです。

この「私の目に見えている物事」は、言い換えると「コードの設計的側面の機微」というものかと思います。それはとても些細な違いだったり、僅かな兆候だったりするものなので、表現して人に伝えるには、緻密で正確な描写が必要になるものだと思っています。

しかし、このような描写は言うほどたやすいことではありません。また、そもそもこのような描写を行うためには、対象となる物事自体を相当緻密に観察し、かつ、理解し、自分のものとなっていなくてはいけません。このような点でいえば、今の私の観察、理解、表現はまだまだ発展途上です。今年の一連のトークを通して、より緻密に自分の「見え」を伝えられるよう、磨きをかけていきたいと思っています。

このようなトークで私に見えているものをお伝えすることで、「設計の面白さ」を一人でも多くの方に味わっていただけたらと思っています。

 

今回聞きにいらしてくれた皆様、どうもありがとうございました!

イベントについて

オープニングのスポンサー紹介を聞きながら、あらためてスポンサーがたくさん集まっているということに驚きました。スポンサーブースの数も多く、スポンサーブースの部屋に活気がありました。この部屋にAsk The Speakerのコーナーもあり、私もそこで質問に答えていましたが、部屋自体に活気があるからなのか、質問者の方と楽しい雰囲気で会話することができたように思います。このような場の空気が作れているのは、素晴らしいことだと思いました。

 

トークの反省

  • しゃべりはじめの頃、マイクの音量がつかめなかった。ボリュームが大きくてハウっていたようで、スタッフさんが途中で調整してくれたとのこと。最初の段階で自分から調整した方がよかったかも。
  • 前回のPHPerKaigiでは、水をこぼしてしまうという事件が発生したので、今回はコップに水を注いで飲むようにした。これは安心感があってよかった。 

次は

7月15日のPHPカンファレンス関西2018で、懲りずに同じテーマの『続・SOLIDの原則ってどんなふうに使うの? オープン・クローズドの原則〜センパイのコーディングノート編〜』というトークをします!

2018.kphpug.jp

今回とはまた少し違った設計の観点を攻めるトークです。

ぜひ聞きにいらしてください!

そして、よろしければご感想、ツッコミ、提案、批判、その他いろいろな声をお聞かせください!

 

村上春樹の小説を初めて読んだ(雑文集、職業としての小説家、騎士団長殺し)

私はこれまで、村上春樹の作品を避けてきた。まともに読んでもいないのに。

まわりから聞こえてくる噂から、私の中で村上春樹作品は、(いろいろな方面で失礼な書き方になってしまうかもしれないが)官能小説のようなものとカテゴライズされ、そして未熟な頃の私は、それを自分には不要なカテゴリーだと決めつけて人生を生きてきたように思う。

ところがここ最近の私は、小説というものになぜだか興味が湧いている。そこで語られるストーリーはもちろんなのだが、どちらかといえば、ストーリーの語り方、語る順番、言葉の選び方などといった部分に。「小説技術」とでも言うのだろうか。何らかの意図を伝えるのに必要な構造としての小説、そのような側面にすごく興味が湧いている。もちろん、そこに「設計」と通ずるものがあると個人的に感じているからだ。

 そのような最近の傾向もあって、書店へ行くとかなり幅広くいろいろなジャンルの棚を回って、目についたタイトルの本を手にとってパラパラとめくってみる。その時その時で自分の追いかけているテーマやキーワードがあって、そのものズバリではないのだけれど、ふと引っかかる言葉が見つかったりする。過去に気になって調べていたことや、どこかで聞いた言葉が、それとは思いもしなかったタイトルの本の中にたまたま出てきたりする。そういう期待ばかりを求めているわけではないのだけれど。

 

そんな風にして書店で偶然手に取ったのが『村上春樹 雑文集』だった。手に取る時点で私には若干のためらいがあった。何しろこれまでの人生で、ずっと避けてきたカテゴリーのものだったのだから。しかし私の「小説そのものへの興味」がその時はわずかに勝ったようだった。

村上春樹 雑文集 (新潮文庫)

村上春樹 雑文集 (新潮文庫)

 

この本に収められている、最初のエッセイ「自己とは何か(あるいはおいしい牡蠣フライの食べ方)」は、次のような文で始まる。

小説家とは何か、と質問されたとき、僕はだいたいいつもこう答えることにしている。「小説家とは、多くを観察し、わずかしか判断を下さないことを生業とする人間です」と。 

この一文を読んで、私は続きを読まずに本を閉じた。一文を見ただけで、この本を買うことに決めてしまったからだ。

私がこの本と出会った頃、ある人と「ソフトウェア設計者の資質」について話していた。何らかの領域を生きる道として歩いている人に備わる傾向、それがソフトウェア設計という領域ならばどのようなものなのか。何らかの基準なのか、能力なのか。先天的に持つものなのか、後天的に獲得しうるのか。そんな話をしていた時だった。そのようなテーマを脇に抱えていた私は、この「小説家とは」という文に強く惹かれた。

雑文集には牡蠣フライのエッセイ以外にも、エルサレム賞受賞時の挨拶文や、音楽についてのエッセイなどが掲載されていた。短いエッセイからでも、この文章を書く村上春樹という人が、小説というものをどのように捉えているのか、そして小説という構造をどのように生みだしているのかが、垣間見えた。

そうこうしているうちに、村上春樹という作者への興味がだんだんと強くなってきた。もう一冊村上春樹の本を読んでみよう。その時点でも、村上春樹の小説作品はまだ、私にとって「避けたいカテゴリー」に属したままだと感じていたが、この雑文集のようなエッセイはとてもおもしろく、同じようなものが他にあるのではないか、あれば読みたいと思った。そして見つけたのが、『職業としての小説家』だ。

職業としての小説家 (新潮文庫)

職業としての小説家 (新潮文庫)

 

 タイトルを見た瞬間に探していたのはこれだと思った。そして、ものすごく興味深く読んだ。この本を読んでいるある時点から、私の中では「村上春樹とはすごい人だ」という認識に変わった。

またソフトウェア設計の話にそれるが、最近学んでいる本で大きなテーマとして取り上げられているキーワードの1つに「長期的」というのがある。「時を超えた」とも表現される。かなり長い時間を基軸として物事を考える姿勢だ。たとえばスチュアート・ブランドのTHE CLOCK OF THE LONG NOWには、1000年や10000年で1まわりする時計を自己の内側に概念として持つことが提案されている。そのような概念的な時計を持つことで、長期的な視点に立てるのだと。

「職業としての小説家」には、いくつか時間にまつわる話が書かれている。物事を語るリズムとしての時間、オリジナリティと時間といったもの。それはこの本のメインコンテンツではないけれど、今の私にはよく響く内容だった。 

そして私はついに、このような考えや態度のもとに、この村上春樹が書いた小説は、どのようなものなのか知りたくなった。もうこれは読んでみるしかないと思った。そうして選んだのが、村上春樹のもっとも新しい長編小説『騎士団長殺し』だ。

騎士団長殺し :第1部 顕れるイデア編

騎士団長殺し :第1部 顕れるイデア編

 
騎士団長殺し :第2部 遷ろうメタファー編

騎士団長殺し :第2部 遷ろうメタファー編

 

本屋へよく通う私は、「騎士団長殺し」の存在を発売前から認識していた。どの本屋でも大きくキャンペーンされていたからだ。しかし私はできるだけそれを避けるようにしていたので、どのような内容なのかはまったく知らなかった。

読んでみようというタイミングになって本を手に取った時、そのサブタイトルに驚いた。「第1部:顕れるイデア編」「第2部:遷ろうメタファー編」。私は哲学も大好きなのだ。このサブタイトルを見ただけで、「何、何、どういうこと?」と好奇心を抑えられなかった。この本は最後まで読むだろうと直感し、1部と2部を同時に購入した。

内容には特に触れないが、私のいろいろな感情や知識や魂を刺激してくれるもので、読み終わってとても満足している(だからこうしてブログまで書くことにしたのだ)。

私は騎士団長殺しという物語を読みながら、その背後や物語の中に村上春樹自身を見、それと同時に、自分自身を見ているようだった。この本に至るまでの流れからも、必然的に読まれるべき作品を読んだような気がする。それはとても不思議でもあり、また、それはありふれたことなのかもしれないとも思う。

 

引き続き村上春樹の小説を読むかどうかはまだ分からない。今回は運良く読まれるべき本に出会えただけなのかもしれない。しかし、もう少し幅広くいろいろな小説を読んでみようという気持ちは強くなった。