個人の Wiki に 2009 年に参加したトークセッションのメモ書きが残っていた。2019年の今読むとまた面白いのでブログの記事として公開してみる。トークセッション自体は 2009 年に行われたものだ。 パターン、Wiki、XP ーー 時を超えた創造の原則 20090710:トークセッション「時を超えた創造の原則」参加報告。 『パターン、Wiki、XP』という本の刊行を記念したトークセッションへ参加してきました。これらの源流に建築家クリストファー・アレグザンダーの思想と思考と哲学を見出し、ソフトウェア開発との接点を探るという内容でした。 構成は 『パターン、Wiki、XP』の概要説明 (江渡浩一郎さん) XP とアレグザンダーについてのトークセッション (かくたにさん、懸田さん) の二部構成。 『パターン、Wiki、XP』について。 Wiki qwikweb の開発者 機能拡張をするときに機能を追加したのに悪くなることがある.なぜだろう？と考えた Wiki の本質を強化する機能は良い機能である しかし Wiki の本質って何ですか？ パターン デザインパターンで何だろう？ アレグザンダーのパターンランゲージを元にしたと紹介されるけど、全然違う 一番最初のパターンの論文 (ケント・ベックとワード・カニンハムの書いた論文) を読んでみた。おもしろい！ そこにあった言葉。「コンピュータユーザーは自分自身のプログラムを書くべきなのである」 つまり、本来目指したのは「使う人間のためのパターン」 使う人間が自分のほしいものを表現し実現するためのパターンランゲージを志向していた。 XP クライアントと開発現場の関係を根本から見直す必要がある オンサイト顧客のような開発に参加するクライアントという関係を築くためには、いついつまでに何を作りますよ。それで支払はいくら発生しますよ。というコミットメントの関係ではむずかしい。 その関係性自体を変えるよう切り込まないと本質的な解決にならない Wiki, XP, パターンはあるものでつながっている。それは問題意識。顧客との関係性という問題意識でつながっている。Wiki はパターンや XP の土台になるもの。 クリストファー・アレグザンダー 初期と後期で全然言っていることが違う 「形の合成に関するノート」(1964) デザインするという行為を数学的な問題に落とし込む 「都市はツリーではない」(1965) 自然都市と人工都市の二項対立 「オレゴン大学の実験」(1975) 利用者参加の建築へ舵を切る 「パターンランゲージ」(1977) 建築は要求条件が多すぎてデザインしきれない 利用者が建築の設計を自分たちで参加できないか 「時を超えた建築の道」(1979) パターンランゲージの背景を解説した理論書 「無名の質」 自然都市に表れるような言葉で表現できないけれど何かよいというような質 形を科学することの本質的困難性 量や長さを科学することは比較的たやすい 一方、形を科学することはむずかしい 中谷宇吉郎「科学の方法」(1958) 雪の結晶(という形)を科学した人 パターンは形を科学の対象とすることに挑戦している。(形の要求の再現性にトライしているという意味。) トークセッション。テーマはXPとソフトウェア開発。 パターンに「それに従えば成功する正解の型」というイメージがついてしまった。

『オブジェクト指向入門』という本がある。今は第2版が出版されていて、原則・コンセプトをテーマにしたものと方法論・実践をテーマにした二分冊になっている。この本はオブジェクト指向によるソフトウェア構築 (Object-Oriented Software Construction) とはなにかについて、緻密に基礎の基礎から話を積み上げ、その全体像を描き出す他にない名著だ。ぼくはまつもとゆきひろさんが推薦する本として最優先に挙げていたのを見て当時出ていた第一版の翻訳を買って読んだ。 最近になって必要があって読み返して驚いたのだけど、今でも自分の設計の指針となっているベースはとことんこの本の内容だった。技法ではなく、設計をするというときに考える思考の観点はこの本からもらったもので、その観点を実現するにはどんなことを理解し考えないといけないかをその後学んで実践し続けてきたのだということに気付くことができた。ソフトウェアを設計するということができるようになるために、方法論を理解しその実践を通して設計ができている状態を目指しているような人にこそ読んでみてほしい本だ。 この本は丁寧に理論が構築されているので、いきなり美味しいところから入ったりはしない。最初はソフトウェアの品質から始まる。 工学の目的は品質である。したがって、ソフトウェア工学は、品質の高いソフトウェアの生産を意味する。 自分の設計の指針となっているベースと書いた内容は第 3 章にある。ここでは、モジュール性をテーマにその 5 つの基準 (criteria)、5 つの規則 (rule)、そして 5 つの原則 (principle) が説明される。 5 つの基準 基準は「モジュール性がある」と呼ぶときに満たしている必要がある基準を挙げている。 分解しやすさ (Decomposability) 組み合わせやすさ (Composability) 分かりやすさ (Understandability) 連続性 (Continuity) 保護性 (Protection) 5 つの規則 これらを保証するために守らなければならない 5 つの規則というのが規則として挙げられているもので、これが「設計の指針となるベース」として設計のことを考えるときに常に頭の中で考えている観点そのものだった。 直接的な写像 (Direct Mapping) 少ないインタフェース (Few Interfaces) 小さいインタフェース (弱い結び付き) (Small Interfaces (weak coupling)) 明示的なインタフェース (Explicit Interfaces) 情報隠蔽 (Information Hiding) 直接的な写像 ソフトウェアシステムというものは何らかの問題領域の必要に対処しようとする。ある問題領域を記述する良いモデルがある場合、ソフトウェアによって提供される解決手法の構造と、モデルとして表現される問題の構造の間の写像 (マッピング) を、明快に保つことが望ましいことに気づくはずだ。このことから次の第 1 の規則が導き出される。 『ソフトウェアシステムの構築過程で考案されたモジュール構造は、それに先立つ問題領域のモデル化の過程で考案された任意のモジュール構造との互換性を維持していなければならない。』 少ないインタフェース 少ないインタフェースという規則により、ソフトウェアアーキテクチャに含まれるモジュール間の通信チャンネルの全体数を限定することができる。 『すべてのモジュールができる限り少ない数のモジュールとの通信で済むようにすべきである。』 通信はモジュールの間でさまざまな方法で発生する。モジュール同士が呼び合う (それらがプロシージャの場合) こともあるし、データ構造を共有することなどもある。少ないインタフェースの規則は、このような接続の数を限定する。

Ruby で自分のための問題を解決していく話 (個人の Wiki を esa に移行した話) の続き。前回は文章とコードでの説明ばかりになってしまったので全体的にやっていることを図にしてみた。 <a href="/images/articles/purkiwiki2esa.svg" rel="noopener" target="_blank">PukiWikiをesaへ移行する流れ</a> 作戦としては、 一連の PukiWiki のファイルはローカルに置いて失敗があれば最初からやりなおせるようにする esa の記事作成以外は繰り返し実行可能にする Markdown の変換で PukiWiki と esa の仕様の差分を吸収できるようにがんばる 最終結果を esa 上で確認し、意図しない表示になっているものは Markdown の変換からやりなおして差分が出た記事について esa へ更新をかける という流れで、実行制限のある esa の API 呼び出しを最小限にしつつ、Wiki 内のページリンクなど PukiWiki 資産を最大限に活かせる形を考えた。実際はここまで全部最初から考えてやったわけではなくて、やりながらやっぱり Wiki 内のページへのリンクも有効にしたいなとか #ls もただ機能をつぶすのじゃなくて活用したいなとか考えては実装し、そして再度手順を実行し、という繰り返しだったのでやりなおせる構成にしたのは正解だった。 ここからは esa への新規投稿による記事 URI 確定と、二度目に Wiki 内リンクを解消した更新をかける流れを説明し、最後に繰り返し修正と更新を繰り返す中でどんな PukiWiki の仕様で引っかかったかとその対処を説明する。

はじめに 遅くても 2008 年ごろから使っている個人の Wiki があって、調べたことや頻繁に探すことをメモしたりして使ってきた。当時職場で使っていたのが PukiWiki で使い慣れていたという理由だけで使い始めた PukiWiki をそろそろさすがに別のものにしたいなと感じていたので esa に移行をした。そのときに考えたことやこうやって移行をしたという記録。移行対象となった PukiWiki のバージョンは 1.5.0 のため、以後の各仕様は v1.5.0 のものになっている。 最初に考えたこと まずなにはなくとも PukiWiki 記法を Markdown にする必要がある。それから自分の用途としてダウンロードした各種スライドを添付していて、中にはすでに WWW 上では見つけられないものもあるので添付ファイルを完全に移行したい。そこまでどうにかできればあとは互換性のない移行をあきらめることでどうにかなるだろう。 と、まあ、あまり細かいことは考えずに始めた。 PukiWiki 記法を解釈して Markdown に変換する 検索すると正規表現を使ってごりごりと変換していくサンプルはいくつか見つかったのだが、自分でこれを修正しながら互換性を上げていく土台としてはきついなというものが多かった。そこで、パーサジェネレータを使ってみたかったという興味もあり、Parslet で PEG スタイルのパーサを書いてみることにした。 Parslet のパース結果はツリーで Array として返され、Hash が入ってる。Hash は Symbol と Parslet::Slice でできてる。Parslet::Slice は出自の位置をもった String みたいなもの。to_s をすると文字列を取り出せる。 {:toc=>"#contents"@0} #=> [Symbol, :toc] [Parslet::Slice, "#contents"@0] 実装進めるにあたっては、他の実装を参考にするのが一番イメージがつかみやすかった。 https://github.com/kschiess/parslet/tree/master/example frsyuki さんの MessagePack パーサの実装 できあがった実装が pukiwiki2md として公開されている。この Gem を使うと、Parslet に則って、Parser#parse でパースし、その結果を Transform#apply で Markdown へと変換することができる。 parser = Pukiwiki2md::Parser.new transform = Pukiwiki2md::Transform.new tree = parser.parse(wiki_text) markdown_text = transform.apply(tree) テストを書きながら、ある程度できあがったところで実際の自分の Wiki のテキストに対して適用して、正しく変換ができなかったものを修正しつつ、という形で開発をしていった。

Pukiwiki2md を公開するときに README.md にバッジを貼りたかったのでよいかんじの Coveralls の導入を調べたのでそのメモ書き。 手元ではすでに SimpleCov を使っているし、あまりプロダクトのコードへ干渉されるのはうれしくない。そこで Ruby on Rails の導入に書いてある Rake task として導入する方法を使ってみる。 今回は gem だったから pukiwiki2md.gemspec へ追加したけれど、通常だと Gemfile へ coveralls gem を追加することになる。 gem 'coveralls', require: false 今回、CI は TravisCI を使う。.converalls.yml ファイルへ次のように記入する。 service_name: travis-ci test_helper を汚したり、普段使わない Coveralls が呼ばれるのは気持ち悪いので Rakefile に Minitest の test タスクへの依存関係を追加して必要なときに明示的に coveralls を使うようにする (Rake task レベルでの依存も気持ち悪ければ別ファイルで用意すればいいのだけど、今回はそこまではしなかった)。 require 'coveralls/rake/task' Coveralls::RakeTask.new task :test_with_coveralls => [:test, 'coveralls:push'] .travis.yml で Travis で CI 時には Coveralls を呼び出すようにする。 script: bundle exec rake test_with_coveralls ちなみに、Rakefile の全体はこんなかんじ。

仕事で聞く要望のうちいくつかは CMS 使うほうが今後のメンテが楽そうだなと感じる機会がよくある。Hugo でサイトを構築するとして、動かすのはなるべく楽に面倒見ずにすませたい。でも独自ドメインだったりある程度機能は求めたい。というわがままを Netlify なら叶えてくれるんじゃないかということで Netlify を試している。 その中で、本番はいいんだけど動作確認用の環境をどうしようかなーというので迷って Deploy previews で対応したことの記録。結論には Business plan で有効になる site access control by roles が必要なので仕事とはいえお金は Pro までしかかけられないという場合は使えないけど、そういうときはトレードオフで URL がばれなきゃいいっしょの精神でいけばいいと思う。 なお、同じ会社で Netlifyが仕事で使えるか試す（追記あり） という方法でやっている話へのアンサーソングでもある。 やりたいこと まずやりたいことから。 Netlify で動作確認をする環境は public に見える状態を避けたい Netlify を使う動機がリポジトリをつくったらあとはなるべく環境構築やその後のデプロイの手間をかけたくないというものなので手間かけたくない 本番となるべく近い形で動作の確認をしたい 考えてたこと 同じ会社で同僚が似たことをやっていたのでまずはその repo を見たり、軽く話を聞いたりしてたんだけど、好みからいくと本人も書いているとおり “しかし、Productionはデプロイの方法を別で作っておかないといけないという面倒なことになってしまう。つらいね。” についてはだいぶ後で嫌になりそうで回避したいなと感じたのと、Heroku で Review Apps の便利さを享受したことのある身としてはぜひ Deploy previews を活かしてやりたい。そして、環境に応じたあれこれをビルド時に考慮してやれば稼働環境は同一でいけそうな気がするので Selective Password Protection のやり方は筋がよさそうに感じる (というか Basic 認証ならこれでいい)。 ということで、 Identity と Visitor Access Control を使ってやってみた。 やってみたこと Makefile じゃなくて rake でやりたいなーとごちゃごちゃやった結果、 Makefile で書くのが一番シンプルだったというサンプル があるのでこのコードを見ながらやってみたことを解説。 環境ごとにビルドを変える (production/deploy-preview) 環境ごとのビルドについては Selective Password Protection に倣って netlify.toml で制御した (repo では rake でやってるが困るまで make でいいと思う)。