00:04
はい、10月9日、日曜日ですね。遅刻は朝9時を回りました。
今日の東京は良い天気なんですけども、やっぱり寒いですね。もう完全に寒いですね。
では、本日も朝活を始めていきます。
今日はですね、いろいろ設計周りの記事を読みたくなったんですけども、
いろいろ見てですね、3つ4つ候補があったんですけど、やはり設計周りの記事って、どうやったってソースコードが出てきたりとか、図が大量に出てくるので、
なかなか朝活で読みづらいんですよね。というので、今日はちょっと俯瞰的な話というか、抽象的な話ばっかりになってしまいますけど、
2つの記事を読んでいこうかなと思います。
片方はパターンランゲージの話ですね。もう片方が、書いてある通りデータフロープログラミングってやつですね。
データフロープログラミングって僕名前全然知らなかったんですけど、軽く調べてみて、結果的にWikipediaの記事がやっぱり良さそうかなと思ったので、
Wikipediaそのものの情報の信頼性どうなのっていうところはあれど、ざっと読んだ感じそんなに間違ってないというか、
他のいろんな記事と比較して良さそうだったので、これを読んでもらおうかなと思いました。という感じです。
では早速入っていきたいと思います。
1つ目の記事はちなみにクリストファー・アレクサンダーさんから入っていこうと思います。
建築家でありデザイン理論家であるクリストファー・アレクサンダーは、この精神、エネルギー、魔法のことを名前のない品質、つまりQWANと呼びました。
彼はそれを定義しようとしただけではなく、誰もが意味のある建築、アーキテクトを想像できるようにすることを目的とした運動を行いました。
彼の1977年の著書、パターンランゲージですね。
アレクサンダーは史上最も売れた建築の本だと言われています。
この運動が言葉発端とか始まりで、彼はそのパターンランゲージ運動の父という称号を得ました。
プログラマー、開発者、デザイナーがアレクサンダーの理論を取り入れ、自分たちの仕事を体系的に整理するようになったからだというふうに仰っています。
この世界の人間であれば一度は聞いたことがあると思います。アレクサンダーですね。
著名な方だし、一つの時代を作ったと言っても過言ではない方なので、尊敬しかないですけどね。
その方のパターンランゲージを読んでいくということですね。
どこまで取り上げられているかわからないですけど。
アレクサンダーのパターンランゲージという書籍は、実用的な建築システムとして紹介されていますが、
いわゆるIKEA的な部屋や建物や街の建て方を正確に説明するマニュアルではありません。
この本は、普通の人なら誰でも使える生きた世界を作るための実証済みの要素で満たされたシンプルなガイドであり、
その世界と相互作用する人間にとって最も有益なものであります。
シムズのような、しかし現実の世界にあるゲームだと言ってますね。
面白いことで、シムシティの作者であるウィルライトは、アレクサンダーの作品が彼の有名なコンピューターゲームの起源に影響を与えたと述べています。
03:01
シムズという名前からしてシムシティに続いてたって感じですかね。
名前をもらったのかなと思いますけど、僕全然シムシティやったことないんですけどね。
確かにあのゲームは建築というか街を作るゲームですからね。
アレクサンダーから強く影響を受けたんですね。
続いて、パターンランゲージの基礎というのは、中世の都市を観察したことにあります。
中世の都市というのは全て地域の規則に従って設計されていましたが、建築家、またはアーティスト、デザイナー、あるいは単に人ですね。
各部屋、レベル、建物を特定の状況に合わせることができました。
アレクサンダーはそのような特定の状況とは、ユーザーが快適さを感じ、満たされ、余計な機能や芸術のための芸術に惑わされることなく、彼らのニーズを満たすために必要なものだと考えています。
そのため、アレクサンダーは、人々は自分たちのために建築するべきだと言い、彼のパターンランゲージというのは誰でもどんなグループでも美しく機能的で意味のある場所を作ることができるというツールを広くできるようにしたのが鉱石だというところですね。
なるほどですね。全然読んだことないですけど、そんなに僕ら一般ピーポーでも導入できるような書籍だとしたらすごい。本当にその原点を読んでみたいですね。
アレクサンダーの基本的な構成要素から始めて、それを適応させていくという考え方は、アクションではなくオブジェクトを中心に組織化されたプログラミング言語モデルであるオブジェクト思考プログラミングにも現れています。
やっぱり建築から来てるんですね、オブジェクト思考って。
パターンランゲージが出版されてから20年後の1987年、コンピューター科学者のケントペックとワード・カニンガムがプログラミングにデザインパターンを使用するアイデアを検討し始めた。
数年後彼らがオブジェクトオリエンティティプログラミングシステムランゲージアンドアプリケーションズというようなカンファレンスでその成果を発表すると、ソフトエンジニアリングのコミュニティでは完成上がり、プログラミングの新しい一部には形成され始めたのです。
アレクサンダーの著書が出版されてから40年以上経った今でも開発者、プログラマー、デザイナーはその革新的な理論を適用する新しい方法を今でも見つけて続けているというふうに言ってますね。
その流れを作ったというのも一つですなと言ってました。
さっき言ったケント・ベッグとワード・カニンガムがカンファレンスで発表した1987年が僕の生まれた年ですね。
なるほど、本当にレジェンドたちなんだなーって改めて突きつけられるというか、現実を目の当たりする感じですね。
このお二人の名前もすごい著名な方ですからね、このプログラミング界隈の中でも。
何度もお二人の記事だったりとか僕も読んだことありますけど、
すごいですね、今でも全然通用する、やっぱり根幹的なところに論を語っているというところが流石だなと思いましたね。
その上に乗っかって物事を作っている僕らとしては、神様までいかないですけどやっぱり父だなという思いはありますね。
続いていきます。現代のデザインパターンの応用ですね。モダンデザインパターン、アプリケーションですね。
06:03
アレクサンダーの仕事を建築の新しい形と呼ぶ人もいます。
アレクサンダーが建築の物理世界に情報を提供するためにデザインパターンを作成した一方で、
デジタルアーキテクトっていうのが彼の理論の自分たちの仕事への応用をすぐに認識したことは驚くに当たらないだろうと。
とはいえ、でもこの当時でしょ、1900、まだ後半ぐらいですよね。
ところでそのデジタルアーキテクトっていうのはどんどん取り入れていったっていうのは、やっぱり革新的だと思いますけどね。
パターンランケージでは、その各パターンは私たちの環境で何度も何度も発生する問題を記述し、その問題に対する解決策の革新を記述しています。
どんなデザイナーにとってもこのコンセプトは素晴らしくなじみ深いもので、あらゆるデザインシステムの基礎となるものです。
今日デザインパターンっていうのは一般的な設計上の問題に対する解決策を文書化した正式な方法である。
デザインパターンはそのベストプラクティスを調整し、優れたデザインの要素を記述されるための普遍的なリソースであり、
最も重要なのは他の人々が簡単にこれらのソリューションを再利用できるようにするためのリポジトリを提供することであります。
既に完璧に良いものが存在しているのになぜシャリンを発明するのでしょうか。
現代のデザイナーは新しいデザイナーがブランドのニュアンスに迅速に対応できるようにするために、
時間と人を超えた集合値を獲得するため、チームに共通言語を提供するため、
ダブルワークに費やす無駄な時間を排除するため、
そして媒体やデザイナーに関係なくエンドユーザーが予測可能な体験を得られるようにデザインパターンに頼っているのです。
シャリン再発明の話は以前もあさかつでしたが、一旦置いておきます。
アレクサンダーは全体が部分の相話よりも大きくなるようにパターン間の関係性を強調する言語を作りました。
ロゴは最高のもの、色はブランドを的確に表現するもの、
レイアウトは心地よい情報の風景であっても、すべての要素間の繋がりに意味がなければ何も生まれません。
ただただ集めてガチャンと置いただけだと意味はないと言ってますね。
フィタゴラス、エンドクレス、エンベッドクレス、プラトンといったギリシャの哲学者に習い、
アレクサンダーは最初に作られ、最も試されたパターンがどのように進化するのか、そのヒントとインスピレーションを得るために自然に目を向けました。
最終的にネイチャーにたどり着くんですね。
その結果アレクサンダーはステップワイズシーケンスと呼ばれる全段階のものを再利用する現象、つまり要素の連続的な変化を認めました。
この現象こそがアレクサンダーが考えるデザインの次のフロンティアなんです。
新しい技術や高度なメディアを使ってアートを作るのではなく、これまでのものを使いながら現在の人間の行動や要求を満たすようにアレンジしていくのです。
アレクサンダーはこの実践こそがデザインに名前のない品質というものはあったり、それがデザインを優れたものにするのだというふうにおっしゃっています。
というところでこの記事は締められています。
これは単純にこのアレクサンダーのパターンランゲージを読んだ感想だというか、そういうまとめという記事だったんですね。
09:00
すごい短かったんですけど、ざっくりとアレクサンダーの歴史を知るという意味では、後、功績を知る意味ではとてもいいんじゃないかなと本当に思いましたし、やっぱり参考になりましたね。
一応いろんな追加の記事ですね。
リンク載っています。
Additional ResourcesとSourcesというところですね。
ありますので見てみてくださいと。
結構Wikipediaがやっぱり多めですね。
Wikipediaにもクリストファー・アレクサンダー本人のものとパターンランゲージというものもありますし、書籍そのものも出てきたりしますし、いろんなのがあるので後ほど見てみてください。
一応パターンランゲージそのもののホームページもありますね。
www.patternlanguage.comというドメインがすでにありますね。
知らんかと。
で、BookstoreとArchiveとGalleryみたいなところに記事がリンクが貼られていますね。
このサイトはちゃんと2001年から2022年までコピーライトがあるので、ちゃんと更新されているようですね。
なので興味のある方は見てみてくださいと。
ニュースとイントラクション、ツールズ、リソーシーズといろんなところまでちゃんと他の外部でのリンクも貼られているので、これは面白そうですね。
というところでした。
もし今後の朝活で、いくつかザッと見て面白そうだったら読んでいこうかなと思っています。
というところで一旦Alexanderの方の記事は終了にしたいなと思います。
歴史的な偉人の方々の功績を聞くたんびに心がすごくワクワクするといいますか。
高揚しますね。
はい、では行きましょう。
続いてですね、続きはデータフロープログラミングです。
こちらはですね、昨日朝活で読んで、昨日だっけ?一昨日だっけ?
何回か前に読んだ、株式会社イッキューさんのCTOされている伊藤直生さんですね。
この界隈でもかなり有名な方ですけど。
その伊藤直生さんがご登壇されたスライドの中で名前を見つけたデータフロープログラミングということですね。
僕がこのデータフロープログラミングっていう名前すら全然、申し訳ないですけど知らなかったんですよね。
なのでそれを調べてちょっと勉強したくなったというものです。
実際に書いてみないとわからないと思いますけど、一応抽象的ですけど読んでみたいなと思いました。
朝活でやっぱり行動を見るのって結構難しいんですよね。
前は実はツイキャスをやってたんですよ。
ツイキャスでやってたらもちろん画面共有もできたりするんですけど、やはりツイキャスだとなかなか参加される方も少ないし、
そもそもツイキャスなんてやってませんみたいな人も全然いらっしゃるので、どうしようかなと思って今Twitterのスペースにしているという感じですね。
今後考えていることとして、全然余談ですけど、
やっぱりYouTubeで自分の学習を垂れ流すだけの動画を作ってもいいかなと思ったりしました。
作るといっても多少の動画の編集はしますけど、こんな感じでやってますよとか、今こういうものを見てるなとか、
チュートリアルをだらだらと触ってみたりとかするような動画をしようかなと思ったりしてます。
需要があるかどうかは別として、やっぱりちゃんと勉強するには手を貸すのが欲しいよねってなった時に、
個人だけでやるとモチベーションが上がらなかったり、他のことに時間が取られたりとか、結局ゲームをしたりとかしたので、
僕は配信が一番勉強に適しているらしいので、配信しながらやろうかなと思ったりしてます。
12:02
興味ある方は見てみてくださいって感じですね。
じゃあ戻ります。データフロープログラミングの記事いきます。
データフロープログラミングっていうのは、データフローの原理とアーキテクチャに準拠したプログラミングパラナイブであり、
コンピュータープログラムをオペレーション間のデータフローの有効グラフとして模型化します。
データフロー言語っていうのは関数型言語の特徴を共有しており、より数値処理に適したものになっていると。
だからエルムアーキテクチャーを引用に出されてたのか。
エルムが関数型言語ですからね。
言語というかライブラリーというかなんていうかですけど。
ちなみに余談ですけど、その記事内に途中で貼られていたエルムアーキテクチャーっていうサイトのリンクもありましてですね。
ちゃんとGitBookで公開されてます。
guide.elm-lang.jpっていうサイトがあってですね。
ここを見てみるとエルムアーキテクチャーっていうところですね。
ちゃんとブックにまとまっていますので、もし興味ある方は見てみてください。
エルムアーキテクチャーですね。
もともとの記事ですね。公式ガイドがあって、それをエルムJPコミュニティのメンバーによって翻訳したものになりますね。
というところです。
やっぱりアーキテクチャー設計周りのところって、どの言語とかフレームワークでも参考になるものがいっぱいあると思うので、興味ある方は見てみてください。
後ほど共有します。
戻りまして、概要に戻りますね。
データフロー言語っていうのは、命令型プログラミングモデルなどの他の主要のプログラミング言語とは対照的になります。
命令型プログラミングでは、プログラムは一連の命令文で構成され、データの流れはやっぱり見づらいですと。
何なら見えないと。
この違いは狭末に覚われるかもしれないですけど、パラダイムとしての違いは非常に大きくてですね。
データフロー言語っていうのは、マルチコアシステムやマルチプロセッシングシステムを自由に使えるというところが特徴になります。
プログラミングにおける重要な概念として、状態っていうのがあります。
状態とは基本的にシステムの各種条件、もしくは変数の測定値のスナップショットであります。
多くのプログラミング言語は正しく動作させるために多数の状態情報というのが必要としますが、
一般にプログラマーからそれらの情報は隠蔽されていることが多いです。
実世界の例として、3方向の電灯スイッチがあるとしましょう。
一般にスイッチを上にすれば電灯が点きますけど、3方向スイッチでは後ろの電灯が消えるかもしれないし、
結果はおそらく視界からは見えない、他のスイッチの状態によって決まることが多いですね。
なかなか3方向スイッチはないと思いますけど、考えてみたら作ることはできました。
それは予期しないところで管理されたりとか、状態が決まるということですね。
実際に状態というのはコンピューターから見ても隠蔽されていることも多く、
ある情報の断片、一時的にすぐに捨てられる情報だとしても、
その状態を符号化したものかどうかというのはコンピューターの感知することほどではないと。
並列処理マシンでは状態情報を複数のプロセッサー間で共有する必要もあるため、
これは重要な問題になりますよねということでした。
どの状態が重要かを知らない場合、多くの言語ではコードやデータの重要性を示すために、
15:02
大量の特別なコードを追加する必要があります。
ああ、冗長になっていくって感じですかね。
そのようなコードは性能も低下させ、デバッグも非常に難しくなりますね。
性能コストの大きいコードというのは単一プロセッサで動作させた時もある程度のコストがかかってしまいますよ。
このような並列性の問題はデータ集約型で非OLTP型アプリケーションを
エンタープライズJavaBeansで組んだ時の性能の低さの主な原因であります。
ちょっと後半何言ってるかちょっと僕もわからなかった。
OLTP型アプリケーションってなんだ。
オンライントランザクション処理。
ちなみにオンライントランザクション処理とは、トランザクション志向のアプリケーションを管理するプログラムの総称であり、
一般にデータの入力と検索のトランザクション処理を扱うと。
それの非だから非オンライントランザクション処理なんですね。
のようなアプリケーションをエンタープライズJavaBeansで組んだ。
JetBeans仕様と同様のものをネットワーク分散型ビジネスアプリケーションのサーバーサイドで実現した仕様のこと。
仕様なんですね、これは。
セキュリティ機能などを備えています。
3がJava EEの仕様の中でビジネスロジックモデル化やビデータの持続化をしてみたいというものですね。
データフロー言語ではデータがプログラムの中心的概念となることを促進します。
ただしプログラムは常にデータを入力され、それを処理して結果を出力するものとは限りません。
古いプログラムなほどそのような前提が深であることが多く、
UNIXオペレーティングシステムにおける単機能ツールをパイプで繋いでデータをやり取りするという形態が典型的であります。
なるほどね、確かにね。
繋いで繋いでいくってことですか。
データフロー言語でのプログラムはコマンド行パラメータなどの入力を起点として、
そのデータがどのように使われ更新されるかというのを記述します。
データは明示的でありパイプや線で情報の流れが物理的に描かれることも多いですよと。
処理とか操作は入出力のあるブラックボックスであり、全てが明示的に定義されます。
その入力が全て妥当となった途端に実行されます。
従来のプログラムは一連の命令文で構成されていますが、
データフロープログラムは組み立てラインに労働者が並んでいるようなもので、
各労働者はその材料が到着した途端に割り当てられた作業を開始します。
データフロー言語が本質的に並列的であるというのはこのためであります。
各処理操作には保持すべき隠蔽された状態をもたらず、
どの処理操作も同時に実行可能であります。
なんとなく、アリツなんだっけ、
すべてエブリッシングストリームのあれなんだっけ、
あー出てこない、RXですね。
RXのプログラミングと結構似ているなと思いました。
RXJSを僕軽く触ったことあるんですけど、
明確にどのような処理をする、処理自体は書くんですけど、
順番とかは特に書いてなくて、サブスクライブのイベントだけ発火させるんですね。
それに引っかかったものがイベントが来たときに処理をするみたいな書き方ですね。
これと結構似ているのかなと思いました。
もしくはこの思考がRXに入っているのかな、わからないですけどね。
想像の意味は池で喋ってますけどね。
データフロープログラムというのは一般にコンピューター内部でも通常のプログラムとは全く異なった表現をされます。
18:02
従来のプログラムは単に命令が実行すべき順序に並んでいるだけであると。
データフロープログラムは巨大なハッシュテーブルとして実装されることもあり、
入力をキーとしてデータとしてのコードへのポイントをあげます。
ある処理とか操作が完了すると、プログラムはすべての入力が利用可能となっている処理、
操作をリストから検索しそれを実行します。
処理とか操作が完了したとき、一般に出力データが新たに入力データとなって、
それによって入力が揃った別の処理とか操作が実行可能になります。
共有すべき並列処理はリストの検索部分だけであり、このリストがプログラム全体の状態を表しています。
したがって状態を管理する作業はプログラマの手を離れ、言語処理系がその役割をします。
並列処理向けの処理系を単一プロセッサのコアのマシン上で動作させるとオーバーヘッドが生じますが、
これは異なる実装の処理系統を置換することでオーバーヘッドのない実行が可能となります。
データフロープログラミングを効率的に実装することを志向したハードウェアアーキテクチャも各種存在します。
グレッグ・パパドポルスという方はMITのタグ付きトークンデータフローアーキテクチャというのを実際に設計しましたよということを言っています。
あと特徴とか歴史とかがガッと語られていますけど、特徴は結構有効グラフをベースに定められているので難しいので端折りたいと思いますし、
時間も30分きたので一旦ここで終了しようかなと思います。
これ読んだ感じで伊藤さんのプレゼンを改めて振り返ると本当にその通りだなというか、
まさにデータフロープログラミングのアーキテクチャの設計も加味したりとか参考にせず作っていったなと思いますね。
スライドを見られた方はわかると思いますけど、まさに状態ごとにタイプスクリプトの型を作っていくんですね。
この状態に来たらこの型、この状態に来たらこの型っていうので型定義をしていくっていうのが僕の中では結構新しかったんですけど、
確かにこのデータフロープログラミングはまさにそういう流れをしますよね。
一つの処理系のところを終わったらその出力が次の入力になっていくっていう、当たり前っちゃ当たり前なんですけど、
その状態ごとでのタイプスクリプトの型定義をしてデータの信頼性とかバリデーションを測るっていうのは確かに理にかなってていいなと思いましたね。
もちろん型定義がどんどん増えるっていう例外はありますけど、実際に動かすっていう意味ではそんなに重要ではないし、
プログラミング、アルゴリズムそのものに大きな影響を与えるかってそこまでではないと思いますので、
なかなか興味深い設計だなと今改めて感じましたね。
というところで、では今日の朝活はこちらで終了しようと思います。
毎回そうですけど雑談が多すぎて大変に申し訳ないですね。
気をつけたいんですけど、こういう朝活をするのが僕の想定だったのでごめんなさいっていう感じです。
では今日の朝活はこちらで終了したいと思います。
3連休中日ですね。また明日もお休みがありますけど、ゆっくりお休みいただければなと思います。
今日もご参加いただいたプロデューサーありがとうございました。
また明日もゆるーく何か読んでいきたいと思いますので興味ある方は参加してください。
21:01
というわけで終了したいと思います。お疲れ様でした。
