このブログの更新は Twitterアカウント @m_hiyama で通知されます。
Follow @m_hiyama

メールでのご連絡は hiyama{at}chimaira{dot}org まで。

はじめてのメールはスパムと判定されることがあります。最初は、信頼されているドメインから差し障りのない文面を送っていただけると、スパムと判定されにくいと思います。

参照用 記事

「プレBPStudy」または「やっぱりパスタの会」の後日メモ

「プレBPStudy」または「やっぱりパスタの会」 参加者:

  1. hiroki_f さん
  2. tMiya さん
  3. publichtml さん
  4. sugi さん
  5. ardbeg1958 さん
  6. たけを さん
  7. 村岡 さん
  8. hiratara さん
  9. Kuwata さん
  10. 檜山

ありがとうございました。


以下、雑多なメモですが、昨日印象に残ったこと/反省したこと。

僕は、「デザイナ」「プログラマ」という2つの言葉、それしか使わなかったけど、これはどうもまずかったみたい。

「実際に何人でどう作業するか」とは別に、ロール(役割)については、もっと詳細にしないと分かりにくいようです。現状、次のロールが考えられるかと:

  1. 発注者(サイトのオーナー)
  2. (狭義の)デザイナ
  3. スーパーバイザ
  4. コマンド・プログラマ
  5. ファシリティ・プログラマ

5人で作業しろってことじゃなくて、5つのロールがありますよ、ってことね。

「スーパーバイザ」ってのは適当な言葉が見つからなかったんでデッチ上げた用語ですが、サイト全体の構造、ページ遷移とデータの流れ、情報の配分などを設計する人のことです。静的ファイル、テンプレート、プログラムの境界線の設定もします。

「ファシリティ」というのはCatyジャーゴンで、OSに例えるならデバイスドライバにあたり、ストレージアクセスを抽象化するレイヤです。ファシリティはプラッガブルなので、「ファシリティの書き方」が文書化されれば、ユーザープログラミングで追加拡張可能です。が、サイト(プロジェクト)ごとに作るようなシロモノではありません。

僕の想定と言葉遣いでは、デザイナが発注者と相談しながらスーパーバイザを兼任し、コマンド・プログラマを下請的に使う、という作業形態。つまり、「デザイナ」という言葉にスーパーバイザのロールも含めていたのでした。僕(檜山)自身の完全に個人的な想定は、スーパーバイザ能力を持ったデザイナに発注し(檜山が発注者)、下請けプログラマの作業も自分でやってもいいかな、と。あくまで個人的なケースだけど。

概念的にスーパーバイザ・ロールを導入してみると、Catyが備える各種言語の利用者を分類しやすくなるね。

  1. (狭義の)デザイナ -- テンプレート言語
  2. スーパーバイザ -- スキーマ言語とCatyスクリプト
  3. コマンド・プログラマ -- スキーマ言語のコマンド宣言部分とネイティブ(ホスト)プログラミング言語
  4. ファシリティ・プログラマ -- ネイティブ(ホスト)プログラミング言語

「スーパーバイザって、すごく知的でスキルフルなんじゃないの?」と言われれば、そのとおりなんだけど、これも程度問題で、サイトへの要求が低いならば、スーパーバイザにすげー高度なスキルが要求されるわけじゃないと思う。そもそも(程度の差はあれ)サイト全体の構造を誰かは考えなきゃならないので、このテの能力と作業をゼロにはできないよねー。まったく能力を持たない人間でも何かをできるってツールは … そりゃ魔法だよ(人は魔法を欲するが)。

スーパーバイザの要求スキル/作業を低減する目的で、サイトの雛形やパーツが使えます。Catyは、柔軟性は低いのだけど、サイトの雛形やパーツは実現できます。厳密分離が効いているので、可搬性やモジュラリティは非常に高い。雛形/パーツ、それと汎用で小さいコマンドが増えれば、デザイナがスーパーバイザを兼任することも十分可能だろう、と僕は期待してるんです。

今書いたごとく僕は、デザイナがスーパーバイザを兼任するという想定をしているのだけど、プログラマがスーパーバイザを兼任してもいいし、完全に独立した職種・職能としてのスーパーバイザを想定してもいいと思います。それは、ソフトウェアのなかの話じゃなくて、現実世界の仕事/作業の話なので、作業ロールやワークフローは現場ごと案件ごとに工夫してくださいな、とも言える …

なんだけどーー、Catyの目的から言えば、作業ロールやワークフロー(の典型的ケース)は、ソフトウェアとコミにしないとダメなんじゃないか、とも感ずるわけで -- ロールやワークフローについて、僕はろくすっぽ分かってないから、このへんは「誰か助けて」だな。


といったタグイの話は、絶対に必要だし、もっと色々と詰めていく必要があるんだ、とは認識しています。けどさー、あんまり僕の得意分野じゃなくてね、ストレスたまるわ(苦笑)。

Webフロントエンドを取り除いた、言語処理系部分だけを取り上げて、コテコテに技術的な話だけをする機会も設けようー、っと。副作用のないパイプラインは、圏論的クリーネスターを持つ半環圏(semiringal category)でモデル化できます。副作用を引き起こすファシリティは、モナド/余モナド/両モナドなので、直積スタンピングと直和スタンピングのベック・スワッパー(Beck swapper, distributive law in the sense of Beck)と組み合わせて、副作用(と例外)付きパイプラインはクライスリ・ライクな拡張圏でモデル化するんだよーん。