こまぶろ

技術のこととか仕事のこととか。

Keynote で作成したスライドを Speaker Deck にアップロードすると Transcript が文字化けする問題への対処法

※以下の問題が発生しない場合もある。おそらく使用するフォントによると思われる。

Speakerdeckの既知の問題

登壇するエンジニア御用達のスライド共有サービス Speaker Deck だが、いくつか既知の問題がある。

たとえば、以下のようなものだ。

kakakakakku.hatenablog.com

kakakakakku.hatenablog.com

今回、別の問題に直面したので、対処方法をメモしておく(結論から先に言えば、 Speaker Deck の問題ではなかった)。

Transcriptが文字化けする問題

Speaker Deck には、「Transcript」という項目があり、スライドの各ページの記載内容をテキストで自動的に補ってくれる。

Keynote で作成したスライドを Speaker Deck にアップロードすると、以下のようになってしまう。

文字化けしている様子
文字化けしている様子

この問題は、企業が運営しているアカウントのスライド資料で発生している例もあり、様々な人がぶつかっている問題だと思われる。

対処方法

当初、 Keynote の問題だとわからなかったため、「Speakerdeck 文字化け」などで検索してもなかなか見つからなかったのだが、知人からCMAPの問題ではないかとの指摘をもらい、以下の記事にたどり着いた。

fu7mu4.hatenablog.com

結果としては、上の記事で記載されている通りの作業を実施することで、 Transcript の文字化けも回避することができた。

手順1: Keynote から「PostScriptとして保存」

PDFが必要な場合、Keynote から「PDFとして保存」するのが定番だが、問題を回避するために一度 PostScript を経由する。「プリント」から「PostScriptとして保存」を選択する。

「PostScriptとして保存」を選択
「PostScriptとして保存」を選択

手順2: PostScript をプレビューで開き、PDFとして書き出し

PostScfript を「プレビュー」で開いて、PDFとして書き出す。

PostScriptから「PDFとして書き出す」
PostScriptから「PDFとして書き出す」

※2024.3.9 追記

Macの新しいバージョンではPostScriptのビルトインサポートがなくなっているため、上記の工程を代わりにGhostscriptなどのツールで行う必要がある。

ky-yk-d.hatenablog.com

対応後

綺麗に Transcript が文字化けせずに表示されるようになった 🎉

綺麗に表示されている様子
綺麗に表示されている様子

補足

16:9 のスライドを上記の方法でPostScriptに書き出すとサイズの関係で余白ができてしまうので、以下のようにサイズを調整してアップロードするとよい。

  • keynoteで「プリント」
    • ページ設定でカスタムサイズ設定
    • サイズを横254mm*142.9mm
    • PostScriptとして保存
  • プレビューで開いて、PDFに書き出し

ソフトウェア開発者としての4年目を新しい会社で始めた

今年の4月から新しい会社で開発者として働いています。

2017年4月に新卒で前職に入社したのがソフトウェア開発者としてのキャリアのスタートでもあったので、この4月で4年目に突入していたこととなります。早いものです。

大学院(修士)卒で就職したので、25歳になる年に就職したわけですが、あっという間に28歳になる年です。あと2年で30歳になる年です。以前(当時は26歳)、id:nitt_san さんに投げかけられた「30歳のときにどうしていたい?」という問いに改めて向き合おうと思う今日この頃です。転職できたことに満足して一息ついていたら30歳になってしまっていたということがないように。。


色々書こうかなと思うことはあったのですが、まとまらないのでやめました。Amazonの欲しいものリストだけぶら下げておいてもよかったのですが、なんか気が乗らなかったのでそれもやめました。それなら転職エントリ自体書かないという手もあったのですが、まぁ一つの区切りとして書いておくとすっきりしそうだなと思ったので書きました。ふー。

このブログもだいぶご無沙汰になってしまっているのですが、また思い出したように何かを書き始めることもあるかと思います。乞うご期待。またTwitterの方は(アイコンもIDも何もかも変わってしまっていますが)相変わらず元気にやっていますので引き続きご愛顧ください(?)。

ソフトウェア業界におけるパターン・ランゲージの受容についての覚書:「付録C」を待ちながら

※本稿はあくまで覚書です。大事なことなので本文にも書きました。筆者はアレグザンダーの著作を限られた範囲でしか読んでいないことを予め表明しておきます。また、XP やスクラムについても書籍で得られる知識しか持ち合わせていません。専門家によるアレグザンダーについての分析は長坂一郎『クリストファー・アレグザンダーの思考の軌跡―デザイン行為の意味を問う』を、ソフトウェア業界における受容についての分析は江渡浩一郎『パターン、Wiki、XP ―― 時を超えた創造の原則 WEB+DB PRESS plus』をそれぞれご参照することをお勧めします。

追記(最終更新:2020/05/10)

同様のテーマについての(個人的には重要な)記事を忘れていたのでリンクを記載しておきます。

上記記事で取り上げられているエヴァンスのDDDを本記事で取り上げられなかったことの反省文です。

また、(上記ツイートのリプライツリーにも言及がありますが)アレグザンダーの日本のソフトウェア業界における受容の最先端(だと思う)きょん(id:kyon_mm)さんの上記記事を承けてのツイートと発表資料も転記しておきます(こちらもリプライツリーまでぜひご覧ください)

以上の観点を踏まえると、本記事で書いた自分の認識はやはり見落としているものが多いと早くも感じるのですが、それはそれで一つの認識なのでそのままにしておきます。

きょんさんは上記の発表資料の中で言及されていますが、Alan Kay のオブジェクト指向とアレグザンダーの思想、エヴァンスのDDDなどとの関連(これについても Coplien 氏が重要な手掛かりになると思いますが)機会があれば自分なりに整理できればと思います。 (以上、 2020/05/09 追記)

本稿で取り上げている事柄について、日本のソフトウェア業界にあってパターンに関わる実践を重ねてこられた懸田剛さんのまとまった資料(本記事執筆段階ではこの資料を直接参照していませんでしたが、懸田さんからはTwitterやその他の資料で学ばせていただきました)をご紹介いただいたのでこちらにも掲載しておきます。

(以上、 2020/05/10 追記)

パターン・ランゲージの付録C

建築家のクリストファー・アレグザンダー(1936-)のパターン・ランゲージの思想が、ソフトウェア業界に受容されてきたことは、周知の事実である。パターン・ランゲージという語に馴染みがなくても、GoFのデザインパターンや、最近ではAWSのクラウドデザインパターンを知っている人は多いだろう。

日本語で書かれたソフトウェア業界におけるパタン・ランゲージの需要についての文献としては、2009年の江渡浩一郎氏の『パターン、Wiki、XP』*1のほか、2011年の情報処理学会の会誌「情報処理」52巻9号の特集「ソフトウェアパターン−時を超えるソフトウェアの道」がある*2

しかし、パターン・ランゲージがソフトウェア業界に持ち込まれてから約30年が経ち、当初の脈絡や原典たるアレグザンダーの思想(それ自体、2000年代にかけても進展がある)との関連が見えづらくなっている。このような事態を、Kent Beckの『テスト駆動開発』の新訳版の訳者を担い、そこにこの20 年間のTDDをめぐる議論の流れを補足する「付録C」を執筆し挿入した和田卓人(id:t-wada)氏は、以下のように語っている。

パターンにも付録Cが必要なんですよ。歴史が切れてしまっている所があって、パターンってGoFのデザインパターンでしょ?みたいなところがあったりするから、やはり背景や意義を補わなければならない。

(出典:希薄化したTDD、プロダクトの成長のために必要なものは?〜『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談 (6) | by Takeshi Kakeda | 時を超えたプログラミングの道

数年前にこの業界に入ったばかりの自分としては、パターン・ランゲージについての「付録C」が書かれることを強く期待している。相応しい人物は、上記の対談の関係者など多くいるだろう。

本記事は、「付録C」が書かれることを待ちながら、なんとか自分なりの理解を形作ろうとしている筆者が、外出自粛の暇に任せて書き殴る覚書である。アレグザンダーの思想やデザインパターンについての紹介記事ではないことをご承知おき願いたい。また、筆者はパターン・コミュニティの一員ではなく、PLoPに参加したことも、パターン・ライティングの経験もないことを書き添えておく*3。パターンに詳しい方々におかれては、「ある若者にはこう見えている」という一例として読んでいただきたい(認識に誤りがあればぜひご指摘をいただきたい)。

ソフトウェア設計についてのパターン

ソフトウェア開発者にとって身近な「パターン」はやはりGoFのデザインパターン(オブジェクト指向における再利用のためのデザインパターン)である。ソフトウェアそのものについてのパターンとしては他に、POSA(ソフトウェアアーキテクチャ―ソフトウェア開発のためのパターン体系)、PoEAA(エンタープライズアプリケーションアーキテクチャパターン)などが挙げられる。

上記のようなソフトウェアそのものについてのパターン(=プロダクトについてのパターン)は、パターンの語はソフトウェアの設計において「繰り返し現れる、問題に対する解決方法」という程度のものとして使われている場合が多く、アレグザンダーのパターン・ランゲージの理論のうち、「無名の質(QWAN)」(これは難しい観念だが、価値的な要素を含んでいる)や、「ランゲージ」たる部分はあまり重視されていないように思われる。

このような用法における「パターン」は、良くも悪くも、深遠なものではない。おそらくアレグザンダーの原典を読まなくてもこれらのパターンは理解・利用できるし、もし読んだとしても混乱するだけだろう*4

Kent Beck による受容

そもそもパターン・ランゲージというアイデアが建築業界からソフトウェア業界に持ち込まれたのはどのようにしてであったか。一人の重要人物は、エクストリーム・プログラミングの祖であり、『Smalltalkベストプラクティス&パターン』(ケント・ベックのSmalltalkベストプラクティス・パターン―シンプル・デザインへの宝石集)などのパターン形式をとった書籍も複数執筆している Kent Beck である。

江渡氏によれば、「ベックは大学生のとき、生協で『時を超えた建設の道』を読み、大きな衝撃を受け、そのまま立ち読みで全部読み終えてしま」ったという*5。『時を超えた建設の道』が出版されたのは1979年で、 Kent Beck は(Wikipediaによれば)1961年生まれであるから、出版されて高々数年という時期に読んだと思われる。

Kent Beck は Ward Cunningham*6と共にソフトウェアの設計にパターン・ランゲージの考え方を持ち込む実践を行った。そこでは、ソフトウェアの利用者に参加してもらってユーザーインタフェースの設計*7を共同で行うこと、そしてパターン・ランゲージを用いることが試みられた。その成果は、1987年の OOPSLA で紹介され、ソフトウェア業界でパターンというものが流行する端緒となる*8

オブジェクト指向プログラムのためのパターンランゲージの使用 - kdmsnr.com

その後、Kent Beck は開発の手法としてのエクストリーム・プログラミング(XP)を生み出す。 XP とアレグザンダーの(主に『オレゴン大学の実験 (SD選書)』における)思想との類似性は江渡氏が指摘しているところであるが、当初の実践の要素のうち、(利用者参加は残っているものの)存在していたユーザーと共同でパターン・ランゲージを使用するという要素はXPには残されていない。これは、2002年に Ralph Johnson*9 が語っているように、マーケティング上の配慮もあったかもしれないが、現在手に入るいわゆる「白本」の第2版(『エクストリームプログラミング』、2004年)では(1999年の初版には参考文献でのみ言及されていた)アレグザンダーへの言及に1章を割いていることを考えると、ただ単に、設計行為の中でパタンランゲージを用いるというプラクティスは XP には持ち込まれなかったと考えた方がよいだろう。

Kent は,XPをマーケティングする際,パターンの時とは違ったアプローチを 取りました.両者に違いは多くありますが,重要なのは,XPについて彼が書い たものには,Chistopher Alexander が出て来ないということです.私が推測するに,典型的なソフトウェア開発者に Alexander を指し示すのは間違いであると彼は考えたのではないでしょうか.なぜなら,Alexander の考えは彼らに理解しにくく,Alexander をこの議論に持ち込むと,人々はすぐにソフトウェア開発の話題から逸れて行ってしまうからです.Kent は,みんなに「ソフトウェア」を考えて欲しかったのでしょう.

(出典:- XPとパターン Ralph Johnson'sの見解

パターン・ランゲージを用いる当初の実践から、 XP を経て、現在の「アジャイル」に至るまで、開発対象のソフトウェアの利用者(顧客)を開発に参加させるという考えは引き継がれている。しかし、そこではパターン・ランゲージの(利用者を含めた当事者による)使用というアイデアは見られない。

Jim Coplien の生成的プロセスパターン

XP を生んだ Kent Beck の他に、アレグザンダーの影響を受けて独自の議論を構築したソフトウェア業界の人物として、 Jim Coplien がいる。 Jim Coplien は、1994年頃からパターンに関する様々な著作を発表しており、その一つの種類として組織およびプロセスについてのパターンについての著作がある*10。前述の Ralph Johnson や江渡氏は、これらの著作が Kent Beck 、したがって XP に影響を与えていると推察している。組織についてのパターンが書籍化された『組織パターン: チームの成長によりアジャイルソフトウェア開発の変革を促す』の冒頭で紹介されているエピソード*11も、それを伺わせる。

着目したいのは、 Jim Coplien がアレグザンダーの「生成的(generative)」という概念を自身のプロセスについてのパターンの理論に持ち込んでいることである。

パターンの側面を組織の分析に取り込むことは、何も目新しいことはない。この研究での斬新なことといえば、パターンを生成的な方法で使おうとしていることである。(中略)パターンはすでに存在している組織を理解するのに役立つだけでなく、新しい組織を作り上げるのにも役に立つ。組織に関するパターンのよい集合は、“間接的”に正しいプロセスを作るのに役立つ。この間接的であるというのは、Alexander流の生成的方式である。実際のところ、組織に関するパターンは、ソフトウエア・アーキテクチャ・パターンへの最も生成的なアプローチであろう。Alexanderは、「アーキテクチャを作ることはできない、通常の人々の行動によって間接的によってのみ作ることができる。それは、花を作ることはできなくて、種からによってのみ作ることができることと同じである。」と述べている。

(出典:「生成的開発プロセス・パターンランゲージ」

アレグザンダーは、1967年*12の論稿 ”System Generating System" で、全体としてのシステム(system as a whole)と生成システム(generating system)という概念対を導入し、設計者の設計の対象を(通常の考え方がそうであるように)個々の事物(objects)ではなく後者の生成システムと規定する。特定の質をもった全体としてのシステムを生み出す生成システムの設計が、設計者の使命となる。

(出典:”System Generating System" ※引用者による私訳)

アレグザンダーは1968年に既にパターン・ランゲージを冠する著作を発表していたが、その後の成果は1977年に『パタン・ランゲージ―環境設計の手引』に結実する。ここで提示されているパターン・ランゲージは、まさに上記のような生成システムとしてのものである*13

Jim Coplien は、「生成的」という点を強調した上記の論文において、優れたアーキテクチャを生み出す開発のプロセスを生成するパターン・ランゲージを提示している。 Jim Coplien 自身が「間接的」と言っているように、ここではソフトウェア自体に現れるパターンが考察の対象になっているのではない。これは、アレグザンダーの建築についてのパターン・ランゲージとも少し次元を異にしている。

アレグザンダーのパターン・ランゲージで扱われるパターンは、最終的な生産物である町や建物に現れるものだった。これは先に言及したソフトウェアにおける「デザイン・パターン」と同様、プロダクトのパターンである。ソフトウェアにおけるデザイン・パターンとアレグザンダーのパターン・ランゲージが異なるのは、アレグザンダーのパターン・ランゲージが利用者をも巻き込むものであった点である*14

Jim Coplien は、このようなパターン・ランゲージの枠組みを、開発プロセスに適用する。このとき、ソフトウェアの利用者にランゲージとして共有され、ソフトウェア自体に現れるパターンというものは、存在しなくなっている。パターンは開発プロセスに現れるものであり、それはソフトウェアの利用者と共有されるものではない*15。その代わりに、開発プロセスの中で生きる開発メンバーこそがプロセスの利用者であり、パターン・ランゲージを使用しながら自らのプロセスを形作っていくというわけである。XP もまた同様である。再び Ralph Johnson の発言を引く。

しかし,XP 自体,一種のパターン言語です.私は,Kent は Jim Coplien のプロセスパターンから影響を受けていると思います.『デザインパターン』と『Smalltalk Best Practice Patterns』の中のパターンは「プロダクトパターン」であり,XP は一組の「プロセスパターン」だとも言えます.でも,もしXP を一組のプロセスパターンと見るならば,それは非常にうまく定義された,パターン言語になっています.そして,それは,多くの点でAlexander アプローチ(Alexanderian)だと言えるでしょう.特に,生成的(generative)であるという点です.XP には「信頼性」や「理解容易性」に直接関連するパターンが無いにも関わらず,「プラクティス」全体が結びついて,信頼性が高く理解が容易なシステムを生成(generate)しています.

(出典:- XPとパターン Ralph Johnson'sの見解

別の着眼点としては、上記の論文で Jim Coplien が、アレグザンダーの「無名の質(Quality Without A Name, QWAN)」の概念を借り、組織の「無名の質」について語っている点を挙げておく。

ある組織は“無名の品質(Quality Without a Name)” [Alexander]を持っている。彼らは、株主に利益を与え、顧客にうまく対応し、継続し条件を満たし支援的な職場を従業員に提供しているので、目的にかなっている。このような成熟レベルに達している組織は、他のすべての面でも優れていると思われる。ここで示されているパターンは、そのような組織を構築することを可能にするのであろうか?

(出典:「生成的開発プロセス・パターンランゲージ」

彼の議論においてアレグザンダーの「無名の質」が目指されるべきものとして措定されていることは確かだろう。しかし、上記の引用部分の最後の問いに、 Jim Coplien は暫定的には懐疑的な回答をしている。プロセスパターンと並んで語られていた組織パターンにおいても、「無名の質」は語られない。彼の影響を受けたとされる XP においても事情は同じであり、その後のアジャイル開発においても「無名の質」という側面は強調されてこなかったと思われる*16

Scrum Patterns におけるアレグザンダーへの回帰?

ソフトウェア業界におけるアレグザンダーの受容の2つの流れ、すなわちソフトウェア自体に現れるパターンを問題にするもの(「プロダクト・パターン」)と、ソフトウェアを開発するプロセスに現れるパターンを問題にするもの(「プロセス・パターン」)の両方において、アレグザンダーの思想はそのままの形では取り入れられなかったと思われる*17

ところが、大々的にアレグザンダーの「無名の質」に言及するものがある。Scrum Patterns である。最近になって書籍媒体で出版された『A Scrum Book』は、Scrum PLoP コミュニティが書いてきたスクラムについてのパターン・ランゲージである。書籍版の Introduction には、以下のような記述がある。

We believe that the patterns in this book have something special. The pattern community calls it “the Quality without a name,” or sometimes just “the Quality,” a kind of Wholeness that aspires to day-to-day excellence.

(出典: "A Scrum Book"

PLoP の主要人物の一人が Jim Coplien であることからすると、アレグザンダーへの言及があるのは不思議ではない。そもそも、スクラムはその初期において Jim Coplien の取り組んでいた組織パターンの研究に影響を受けている*18。パターンとしてスクラムを表現することも、1998年の時点で既に、 Jeff Sutherland らによって行われている*19

注目したいのは、先に取り上げた「生成的開発プロセス・パターンランゲージ」の「はじめに」において、著者自身がその獲得に懐疑的な態度を示していた「無名の質」が、上記の A Scrum Book では獲得できたとされていることである。「無名の質」以外にも、アレグザンダーの『時を超えた建設の道』で既に色濃く表現されていた東洋思想の影響が、 A Scrum Book にも現れている*20RSGT 2020 の Jim Coplien の基調講演で題材とされた十牛図も、 Preface において紹介されている。

本文のパターン・カタログには、アレグザンダーへの直接的言及は多くない*21。既にソフトウェア開発フレームワークとしての有効性を示し、地位を確立したスクラムであるから、「無名の質」などというものに言及せずとも成立しただろうし、多くの読者は気にも留めないだろう。それどころか、書物としての読者へのハードルを高めてしまう危険性すらある*22

それにもかかわらず、あえて A Scrum Book がアレグザンダーの影響を強く表現していることは、興味深い事実である。それは、単に Jim Coplien 氏の「色」が強く出ただけなのかもしれないし*23、良くも悪くも単なるフレームワークと化したスクラムに対するコミュニティ全体の切実な問題意識ゆえなのかもしれない。いずれにせよ、「無名の質」を語るスクラムがどのように受け入れられていくのかは注目していきたい。

所感

以上、アレグザンダーあるいはソフトウェア業界におけるその受容についての現時点での知識と理解を書き留めた。書きながら感じたのは、自分のアレグザンダーについての理解不足である。Kent Beck や Ward Cunningham 、 Jim Coplien をはじめとして様々なソフトウェア開発者を惹き付けたアレグザンダーの思想を、自分自身がまず存分に浴びたいと思った。また、 Jim Coplien 氏の考えにはオブジェクト指向との関連においても関心があるので、彼の著作についても読んでいきたいと思う。

TODO

  • アレグザンダーの著作を読む
    • 翻訳済みの主要著作を中心に
    • できれば未邦訳の後期著作The Nature of Order vol.2-4も
  • Coplien の著作を読む
  • 初期のスクラムの歴史を知る
  • パターン・ライティングの実際を知る
    • どこかの PLoP に潜りにいく
    • パターンを書いている人たちに話を聞く
  • 慶應・井庭研究室の研究成果を知る

関連資料

Christophor Alexander


Christopher Alexander - Patterns in Architecture

Kent Beck と Ward Cunningham

James O. Coplien


RSGT2020 Keynote by Jim Coplien


Jim Coplien — Symmetry in Design

スクラム、Scrum Patterns

www.slideshare.net

Togetter

その他

*1:紙媒体は中古のみだが、Kindle版は購入可能。

*2:特集のうち本稿の関心に近い寄稿のリンクのみを本文で掲載した。

*3:また、井庭研究室にも関わりがない。

*4:別の議論として、GitHubなどの「設計書共有サイト」がある現在では、この種のパターンがかつて果たしていた役割は縮小している、というものもある。

*5:江渡浩一郎『パターン、Wiki、XP』62ページ。

*6:Wikiの開発者。

*7:これはオブジェクト思考の関心事である。

*8:この辺りについても江渡氏の著作が詳しい。なお、1980年代半ばに既にパターン・ランゲージのアイデアのソフトウェア業界における受容が始まっていたことを指摘している文献として、「情報処理」41巻1号「連載解説:パターン - ソフトウェア開発のノウハウの再利用 第1回 パターンの発展と現状」がある。

*9:GoFの一人。

*10:Jim Coplien 氏の著作については、本人のWebページの著作一覧を参照。

*11:『組織パターン』2ページ。XP の創始者の一人であり、 Smalltalk に関連するもののみを「実際の仕事」と見なす著名なソフトウェアコンサルタントは、 Kent Beck その人だろう。

*12:ここで引用したWeb上の資料には1968年とあるが、長坂一郎『クリストファー・アレグザンダーの思考の軌跡―デザイン行為の意味を問う』の記述に従い、1967年とする。当該論文については同書115ページ以下を参照。

*13:参照、長坂一郎『クリストファー・アレグザンダーの思考の軌跡―デザイン行為の意味を問う』117ページ。

*14:アレグザンダーは、パターン・ランゲージが住民にも共有できるものであることを重視している。参照、『時を超えた建設の道』270ページ。

*15:利用者参加の過程で共有されることはあっても、そのパターンは生み出されたプロダクトには現れない。

*16:もっとも、後述するように、認識が及んでいなかった可能性もある。

*17:初期の Kent Beck と Ward Cunningham の実践は例外という位置付けになる。

*18:参照、Scrum as Organizational Patterns

*19:参照、SCRUM: An extension pattern language for hyperproductive software development(※PDFへの直リンク注意。邦訳は、SCRUM: 超生産的ソフトウェア開発のための拡張パターン言語)。

*20:いわゆる「パタン・ランゲージ」三部作だけでなく、後期の The Nature of Order にも言及があるのは注目に値する。

*21:アレグザンダーの『パタン・ランゲージ』のパターンを明示的に参照しているものもある。たとえば、「おやつ神社」パターンの説明では、アレグザンダーの「150 待ち合わせ場所」および「127 親密度の変化」を参照している。

*22:江渡氏は、アレグザンダーの『時を超えた建設の道』について、「この本はしばしば「分かりにくい」と評される.その理由の 1 つに,彼が明白に東洋思想の影響を受け,そこから都市や建築への考 えを巡らせているという点が挙げられる.「道」や「門」といった老子の言葉の借用にそれがよくあらわれている.」と指摘している。参照、江渡浩一郎「ソフトウェアパターン−時を超えるソフトウェアの道−:2.パターンランゲージからソフトウェアパターンへ」。

*23:Jim Coplien 氏は、スクラム関連以外の場面でもたびたびアレグザンダーの著作に言及している。例えば、Jim Coplien — Symmetry in Design

Smalltalkを学ぶ会@Skypeを開催しました

2020/05/04に、リモートにてSmalltalkを学ぶ会を開催しました。当日のまとめはこちらです。

オブジェクト指向やテスト駆動開発、デザインパターンなどに関心があり、それらの歴史の中でSmalltalkが果たした役割を考えるためにSmalltalkを学びたいと思っていました。

今回、外出できないGWということで、@tenjuu99 さん @sumim さん @Philomagi さんと一緒に、Smalltalkに入門するような内容で勉強会をしようということになり、開催に至りました。

僕はPharoを触り始めた程度だったのですが、「Smalltalkのファン」ことsumimさんの丁寧な説明に支えられ、自分の中のSmalltalkの像がクリアになる有意義な時間を過ごすことができました。

ツールはSkypeを利用しました。Skypeの会議機能は無料で利用することができ、画面共有も可能です。録画機能もついており、画面共有されていた場面も含めて映像データとして保存することができます。今回、ライブ配信までは行えなかったのですが、保存した映像データをYouTubeにアップロードしました。関心のある方はぜひご覧ください。


2020/05/04 Smalltalkを学ぶ会(1/3)


2020/05/04 Smalltalkを学ぶ会(2/3)


2020/05/04 Smalltalkを学ぶ会(3/3)

以下のページは、今回の勉強会の資料等をまとめたものです。当日の議論の中で、Smalltalkに関心はあるけどハードルが高いと感じている人にも気軽にSmaltalkについて質問できるような場を作ろうということで、GitHubのOrganizationを作成しました。まだ整備中ですが、もし興味があればご覧になったり、質問をquestionリポジトリのIssueとして立ててみたりしてください。

github.com

Smalltalkは単なる言語ではなく、長い射程をもったものだと思います。自分たちがその中で生きている文化、思想といったものの原点、あるいは今とは違ったあり方を示唆するものとして、理解を深めていければなと思っています。

『データ指向アプリケーションデザイン』を読む(3):2章「データモデルとクエリ言語」

『データ指向アプリケーションデザイン』の2章「データモデルとクエリ言語」についての読書メモ。

データ指向アプリケーションデザイン ―信頼性、拡張性、保守性の高い分散システム設計の原理

データ指向アプリケーションデザイン ―信頼性、拡張性、保守性の高い分散システム設計の原理

データモデルと抽象化

前章に続いて、抽象化というキーワードが出てくる。

それぞれのレイヤーはクリーンなデータモデルを提供することによって下位のレイヤーの複雑さを隠蔽してくれています。こうした抽象化によって、たとえばデータベースベンダーのエンジニアや、そのデータベースを使うアプリケーション開発者など、様々なグループの人々が効率的に共同で作業できるのです。*1

各言語(自分が念頭に置いているのはJavaだが)コレクションを取り扱うライブラリや、それを更に隠蔽したファーストクラスコレクションは、下位レイヤーの隠蔽のわかりやすい例だと言えるのではないか。インピーダンスミスマッチはこの文脈では言及されていないが、隠蔽が極めて複雑な仕方で行わなくてはならない異なるデータモデル同士の関係を言うものと理解できると思う。

ドキュメントモデル

ドキュメント型のデータモデルについて、紙幅を割いてその特徴を論じている。本文中では、ドキュメント型木構造が明示されている(それゆえ、個人の履歴書のような構造のデータには親和的である)ことや*2、ドキュメントデータベースの多くで結合のサポートが弱いこと*3が指摘されている。しかし、この書籍の特徴的な態度でもあるが、異質なものと理解されている複数のものをわかりやすく対比させるだけでは終わらずに、共通性や中間的なあり方についても言及している。たとえば、多対一や多対多の関係の表現において、リレーショナルデータベースでもドキュメントデータベースでも識別子による参照(外部キー、ドキュメント参照)が行われるという指摘などである*4

アプリケーションにおけるドキュメントモデルの利用については、以下のような原則を示しながらも、別の箇所では、「仮にアプリケーションの初期バージョンが結合が不要なドキュメントモデルにうまく適合したとしても、アプリケーションに機能が追加されていくにつれて、データ同士はつながりを持つようになるものです。」*5と指摘している。ドキュメント型に適合している例として挙げられた履歴書の情報が、どのようにドキュメント型の枠を超えてくるかという説明もわかりやすい。

アプリケーションのデータがドキュメントのような構造を持っている(すなわち一対多の関係からなるツリー構造を持ち、通常はそのツリー全体が一度にロードされる)なら、おそらくはドキュメントモデルを利用するのは良い考えです。リレーショナルな手法である細分化(shredding)、すなわちドキュメントのような構造を複数のテーブルに分割することによって、スキーマが込み入ったものになり、アプリケーションのコードが不必要に複雑になることがあります。*6

ドキュメントモデルの特徴であるローカリティについては以下のような指摘もなされている。大きなデータを一箇所にまとめておくことで一度に全体を取れるというメリットが、ドキュメントのサイズを大きくすること自体によるデメリットゆえに実際に享受しにくくなっているというのは面白い現象で、同種の事態はデータモデル以外の文脈でも見られるのではないだろうか。設計を考える際には頭の隅に置いておきたい。

ローカリティのメリットが生じるのは、一度のドキュメントの大部分が必要になる場合に限られます。通常、ドキュメントの一部にしかアクセスしない場合でも、データベースはドキュメント全体をロードしなければならず、これはドキュメントが大きければかなり無駄になるかもしれません。ドキュメントを更新する場合には、通常ドキュメント全体を書き直さなければなりません。変更の処理をその場所でデータを上書きして済ませられるのは、エンコード後のドキュメントのサイズが変わらない場合だけです。そのため、概してドキュメントは小さく保ち、ドキュメントのサイズを大きくするような書き込みは避けることが望ましいです。こうしたパフォーマンスの制約があるため、ドキュメントデータベースが有効になる状況はかなり減ってしまいます。*7

クエリ言語とグラフ型データモデル

様々なクエリ言語を紹介しながら、それぞれの特徴を記載している。大きく取り上げられているのは、宣言的言語、APIの魅力である。並列処理への適合性という文脈で宣言型を語るのはJavaにおけるforループとStream APIの違いなどと同じだ。また、書籍中ではスタイルの適用におけるCSSJavaScriptの違いも宣言型/命令型という文脈で捉えられている。具体的な例を挙げて両者の違いが影響を及ぼす理屈を説明していてわかりやすい。

宣言的な言語が魅力的なのは、通常それが命令型のAPIに比べて簡潔で、扱いやすいためです。しかしもっと重要なのは、それがデータベースエンジンの実装の詳細も隠蔽してくれることであり、そのおかげでクエリの書き換えなしにデータベースシステムはパフォーマンスを改善できるのです。(中略)最後に、宣言型の言語は並列実行に向いていることがよくあります。今日では、CPUの高速化はクロックを高速にするのではなく、コア数を増やすことによって達成されています。*8

クエリ言語と併せて細かく論じられているのはグラフ型のデータモデルについてだ。多対多のデータの関連が支配的になってきた場合には、ドキュメント型やリレーション型ではなくグラフ型のデータモデルが親和的になる。グラフ型のデータモデルには個人的に馴染みがなく、CypherやSPARQLといった、書籍中で紹介されているクエリ言語も知らないものばかりだった。SQLにおける再帰共通テーブル式WITH RECURSIVE)もグラフ型データモデルの文脈に位置付けられている。

これまでに、多対多の関係が様々なデータモデルの重要な機能の差異になっていることを見ました。アプリケーションの持つ関係のほとんどが一対多(ツリー構造)だったり、レコード同士が関係を持ったりしないのであれば、ドキュメントモデルが適しています。しかし、データ中で多対多の関係が一般的だった場合はどうでしょうか?リレーションモデルは多対多の単純なケースは扱えますが、データ同士の繋がりが複雑になっていくと、データをグラフとしてモデル化するほうが自然になっていきます。*9

上の一節では、関連の観点からドキュメント→リレーショナル→グラフという展開が示されている。のちの部分では、階層型の欠点を補うものだったリレーショナルモデルのあとに、「NoSQL」という括り方をされるものの方向性を異にする二つのものとして、関係の取り扱いを重視しないドキュメントモデルと、複雑な関係を取り扱うのに適したグラフモデルが登場したという歴史的な展開が示されている*10

スキーマレス」を巡って

データモデルを語る際にしばしば使われる「スキーマレス」の概念についても、わかりやすい説明がなされていた。以下の一節では、ドキュメントデータベースにおける「スキーマレス」(=スキーマオンリード)と、リレーショナルモデルにおけるスキーマオンライトとの対立を、プログラミング言語における動的型付けと静的型付けとの対立と類比させている。言われてみるとなるほどと思わされる説明である。

ドキュメントデータベースはしばしばスキーマレスだと言われますが、これは誤解を招く表現です。なぜなら通常、データを読み取るコードは何らかの構造があることを前提とするからです。もっと正確な言葉を使うなら、これはスキーマオンリード(データ構造は暗黙のものであり、データの読み取り時にのみ解釈される)であり、スキーマオンライト(リレーショナルデータベースにおける伝統的なアプローチであり、スキーマは明示され、データベースは書き込まれるすべてのデータがそのスキーマに従っていることを保証する)の逆です。スキーマオンリードは、プログラミング言語における動的(実行時の)型チェックに似ており、一方でスキーマオンライトは静的(コンパイル時の)型チェックに似ています。*11

感想

抽象化や宣言型、それに最後のスキーマと型付けの話など、この書籍では、アプリケーションのプログラミングの領域で馴染みのある物事の捉え方が、データモデルやクエリの領域にもうまく適用されているような印象を持つ。これまで主にアプリケーションの内部の設計やコードの記述方法について勉強する中で身につけてきた考え方が他の領域にも活かせる、ということを感じさせてくれ、勇気付けられる。抽象的になりすぎずに具体的な事例を交えつつこのような議論ができるというのは、経験と思考が高度に組み合わさっていてこそだと思われ、著者に対しては畏敬の念を禁じ得ない。

*1:30ページ。

*2:33ページ。

*3:36ページ。

*4:40ページ。

*5:36ページ。

*6:41ページ。

*7:44ページ。

*8:46ページ。

*9:51ページ。

*10:65ページ。

*11:42ページ。