Chienomi

PureBuilder Simplyを政府統一サイトに採用して欲しい

開発::util

  • TOP
  • Articles
  • 開発
  • PureBuilder Simplyを政府統一サイトに採用して欲しい

序

本記事は少し複雑な話をする。

本記事は“政府統一Webサイト構築に向けたサービス基盤及びデザインシステム等の実証に関する調査業務”を受けた内容である。

本記事の趣旨はPureBuilder Simplyソフトウェアの解説ならびに売り込みである。 決して私自身の業務の売り込みではなく、応札する意思もない。 PureBuilder Simplyが採用されることによって私に金銭的利益があるわけでもない。

当該資料を見たときに「それはPureBuilder Simplyである」ということを強く感じたため、あまりにも知られていないからこそ、その選択肢を気に留めて欲しいと思ったのだ。

当該資料には

CMSはAPIベースのHeadless CMS（OSS）を用い、サーバサイドで静的ページを生成・公開する仕組みを想定

という要件があるが、これが難しいと認識されているらしい。 しかし、PureBuilder Simplyは

  • Headless CMS
  • OSS
  • サーバーサイドで生成・公開

のいずれをも満たす。(ライセンスはApache License 2.0)

ついでにいうと、日本人作者ひとりであるから、国産である。

PureBuilder Simplyの概要

ソフトウェア概要

PureBuilder Simplyは「ウェブサイト構築ソフトウェア」である。

ごく簡単に言えば、Pandocを用いてPandoc Markdown、またはReSTrucured Textの文書をウェブサイトに構成するためのユーティリティであると考えて良い。 実際はCMSで要求されるような動的生成の仕組みをカバーしており、拡張可能性はとても高い。 これは、拡張可能(extendable)ではなくプログラム可能(programmable)と言っていいレベルであり、非常に柔軟である。

動作要件は非常にシンプルだ。

ドキュメント生成部ではPandoc(GNU GPL v2のOSS)を使う。 また、PureBuilder Simply自体はRubyで書かれており、Ruby 3.0に対応する(要求はRuiby 2.6以上である)。 現在、開発版ではPandocに変えてKramdown(MIT LicenseのRuby gem)を用いることができるようにしている。

完全にOSS指向であり、ライセンス的な制約はゆるく、また動作条件も非常にゆるい。

ライバルとしてJykillなどが挙げられるが、大きな特徴として

  • 柔軟である
  • 制約が少ない
  • シンプルである

というところが挙げられる。

例えば、一般的にはこうしたソフトウェアはファイルの配置やプラグインに使用する言語などは「定められた規則に従う」ものだ。

しかし、PureBuilder Simplyのファイル配置規則は

  • 「ソースドキュメントルート」と「ビルトドキュメントルート」のディレクトリを持ち、ソースドキュメントルートディレクトリに設定ファイルを置く

しかない(ONLY)。

強いて言うのであれば、ACCSを用いた「シリーズドキュメント」を使う場合、それはひとつのディレクトリにまとめられる必要がある、というのはあるが、これは実際のところごく自然なことなので制約とも言えないだろう。 もちろん、ACCSを用いない場合は特に必要ない。ACCSを使うメリットは、「自動で目次ページを作る」「ページ間の前記事/次記事を検出できる」といったことくらいしかない。

また、プラグインも「実行可能であること」しかなく、実行可能であればどのような言語で書いても構わない。 さらに、一部スクリプト言語を使う場合、実行ファイルでなくとも拡張子をもとに処理系を起動するため、実行ファイルである必要もない。 私が実際に使っていた範疇では、RubyのほかにBash, Zsh, Perl, Sedを使っていた。もちろん、Python, C, C++, Rust, Nim, Go, Lua, CommonLispなどなんでも良い。 (標準入出力を使うため、Node.jsはあまり向いていないが、できることはできる)

ソースドキュメントをいつ、どこでビルドするかはユーザーに委ねられている。 例えば手元のマシンでビルドし、ビルドされたドキュメントをrsyncでコピーする、というのでも良いし(この場合、rsyncよりもGitやMercurialなどDVCSを使うほうがより便利である)、ソースドキュメントをサーバーにアップロードし(もしくはサーバー上で執筆し)、サーバー上でビルドしても構わない。

これはごく単純な仕組みであるため、どのようにでもできる。 アドバイスするならば、DCVSを使うと非常に便利である。

PureBuilder SimplyはLinuxをベース環境としているが、Unix環境であれば問題なく動作する。 そして、Windowsでの動作も消極的にサポートされており、WSLを使う方法だけでなく、Windows PowerShellを用いてビルドすることも可能だ。

この手の事前に静的ビルドするタイプのソフトウェアは更新が遅いという問題が指摘されることがあるが、PureBuilder Simplyは更新が必要なドキュメントのみを生成するため、最低限の処理量である。

PureBuilder Simplyの具体的な処理については別記事に詳しい。

歴史

PureBuilder Simplyは2017年にリリースされたプロダクトである。 そこから継続的にメンテナンスされ、現在もアクティブだ。

歴史的には、2005年に原型となるソフトウェアがある。 ACCS, PureBuilder, PureDocという3つのソフトウェアの複合であるため、その流れを説明するのは少し複雑になってしまうが、特に大きなトピックスだけ拾えば5代目ということになる。

PureBuilderシリーズはそれほど推せるソフトウェアではなかったのだが、PureBuilder Simplyは何も困らず、最も優れたアプローチであると感じ続けられているため、安定したソフトウェアになっている。

現在のバージョンは1.14.1である。開発中のバージョンは2になるので、次バージョンは2.0だ。

実績

PureBuilder Simplyはマイナーなソフトウェアである。 私が知っているユーザーは10人程度。関心を持っている人はそれより多いようだ。

PureBuilder SimplyはGitHub Arctic Code Vault Projectになっている。

私のウェブサイトはすべてPureBuilder Simplyを用いており、計14サイトをPureBuilder Simplyで構築している。 また、私の業務としての納入も4件ある。

もちろん、それはこのChienomiも含む。 また、リニューアルが進行中のMimir Yokohamaのウェブサイトは、PureBuilder Simplyで作られた最初のウェブサイトであり、まだ機能が少ない頃のバージョンで作られていることもあり、PureBuilder Simplyの柔軟性を駆使して激しい拡張を施している(多くの機能が、現在のバージョンであればより簡単かつキレイに実現できる)。

デザインと拡張

PureBuilder Simply 自体 は基本的に多少のプログラミングができる人が扱うことを想定している。 「プログラマブルなソフトウェア」であるからこそ、その実力をフルに引き出すにはプログラミング能力が求められるし、そもそもHTMLとCSSが書ける人がフルに書きやすい、ということが重要な要件として設定されている。

ただし、これはPureBuilder Simplyを直接扱う上での話である。 一回構築してしまえば、MarkdownあるいはReSTでドキュメントを書いてダブルクリック、程度の処理であり、むしろ求められるリテラシーは非常に低い。 実際、WordPressが難しくて使えないという人や、Confluenceの記述が面倒であるという人向けに構築したことがあるが、ハードルが低く更新が楽であるという点がとても喜ばれた。

構築時のデザインにおいてHTML, CSSを記述する必要があるという点だが、最低限で良いのであれば、公式ディストリビューションにサンプルドキュメントが同梱されており、手順に従ってコピーするだけで良い。

ここは単純にソフトウェアの人気における辛い問題であり、WordPressのように豊富なテーマが存在するわけではないし、「作る」のが基本ではある。 だが、これはサードパーティで作る人がいないマイナーソフトウェアの宿命という話であって、もしPureBuilder Simplyが普及すればそのような部分がPureBuilder Simplyの弱い部分であるとみなされることもなくなるだろう。 シンプルにCSSやHTMLを書くことができるという点は当然ながらテーマを作りやすいということでもある。 また、CSSはソースデータをPureBuilder Simplyから直接扱うとかいう話ではないため、例えばSCSSを使うということも自由である。

適性

PureBuilder Simplyの美点を、構築・維持・運営が非常に用意であるという点以外で言うならば、「ドキュメント生成にPandocを使う」というのが中核的な価値だと言っていいだろう。

Pandocは非常に強力なドキュメントコンバーターであり、ウェブサイトというところでいうと、Markdownなので書くのが簡単であるというのもあるが、Pandoc MarkdownはHTML直書きに頼らずに実質なんでも書けるようになっている非常に強力なものである。 ここに、essentialだが十分に強力なテンプレート機能が備わっているため、これを基盤とすることでPureBuilder Simplyの強力さが実現できている。

なお、テンプレート機能に関しては、Pandoc templateでは不十分なことがないではないため、eRuby templateも利用可能にしている。 ただ、私はごく初期のMimir Yokohamaのウェブサイトを除けばeRuby templateを使ったことはない。

Pandocによる簡単かつ強力なドキュメントを記述できるということは、つまり

  • 頻繁に、あるいは多くの記事を書く
  • 長文の記事を書く

ことに適しているということを意味する。

だから、PureBuilder Simplyは 文章サイトに適しており、デザインコンシャスな、例えばドキュメントを全文表示しないようなサイトや、1ページ単位でスクロールするようなサイトには適さない。 言い換えれば、情報発信や解説を行うようなサイトに良いわけで、もちろんこのChienomiには非常に適している。 そして、政府のサイトにもきっと適しているだろう。 逆に適さないのは、商品のプロモーションなどのためのウェブサイトだ。

もっとも、「できない」というわけではない。 実際、Mimir Yokohamaは文章はほとんどなく、イメージを優先したプロモーション向けのページやランディングページを持っていた時期もある。 ページ遷移がめんどくさい」という理由で今やなくなってしまったが。

私のウェブサイトがシンプルでトラディショナルなものであるのは、あくまで私の思想的な問題(「アクセシビリティが第一」「無用に大きな通信量を発生させるのは迷惑行為である」)であり、別にPureBuilder Simplyの制約というわけではない。

このChienomiとMimir Yokohama以外では、例えばよりトラディショナルなデザイン指向を持ったPiecesやessentialだがより意欲的な技術を用いたHarukamy’s Chatshow、極めてessentialだが個性を持ったProject Radio Harukamyなどがある。

応用例としては、先日外殻はReactで制御し、文書部分だけPureBuilder Simplyで生成する手法に関する記事を書いた。 これもそのための機能があるわけではなく、PureBuilder Simplyの柔軟性を活用した話である。

PureBuilder Simplyは「動的要素を含む」「文章主体のウェブサイトを」「プリミティブな部分の制御も含めて」「少ない労力で構築・執筆・公開・運営する」ということに最大の適性を持つが、それに制約するわけではない。 ReactとPureBuilder Simplyという2つのソフトウェアは思想が違うので相性が良いとは言えないが、それでも受け入れることができ、故に組み合わせることができる。 WordPressからの移行機能も存在し、幅広い活用方法を持つ。

また、Pandocを使っているもうひとつのメリットとして、そのままLaTeXソースとして扱うことができるため、印刷用文書を生成するのも簡単というのもある。 特にChienomiは印刷したい要望が強いため、print CSSを用意した上でLaTeX/PDF出力も考慮してある。 (試したことがない人はChienomiで印刷を開くとびっくりするかもしれない。)

Chienomiで印刷を開いた場合

開発と拡張

各々が簡単かつ自由に拡張できるようになっており、小さなツールと組み合わせるのも容易だから開発は容易だ。

PureBuilder Simply自体を拡張したい場合、issueを立ててもらえれば、私は前向きに対応するようにしている。 実際、これまでPureBuilder Simplyには色々と直接もらった要望を実現可能にするために拡張をしてきている。

CONTRIBUTINGファイルはないけど、これはコードの思想を伝えるのが難しく、受け入れ体制があるとは言えないからで、 もちろんissue立ててPRしてもらえば前向きに対応する。

なお、issueは日本語で大丈夫だ。 実際、ときどきPureBuilder Simplyの使い方に関する質問を様々なメディアで直接もらうのだが、返信率は割と高かったりする。 (さすがに詳細にサポートすることは難しいが)

導入・納入の依頼

これについては、「Mimir Yokohamaでも一応受けている」程度の答えになる。

というのは、まずそもそもウェブサイト構築のお仕事はやたら手間がかかるケースが多く、その時間を捻出することが結構難しいこと、その割に価格が安いので足が出ることも少なくないこと、ちゃんと検収してもらえないことがあること、が理由。

Mimir Yokohamaでは最もシンプルなケース(ソースドキュメントプロジェクトを構築し、ビルドバッチスクリプトを書き、用意されたテーマをベースにカラーデザインを調整する)では5万円でやっている。 ただし、このプランの購入が現在可能かどうかは別である。 (サイトが更新できていないが、現在購入可能なサービスはだいぶ限られている)

Chienomiの構成・ビルド・公開

  • ソースはMercurialでローカル共有して、様々なマシンで書いている
  • 複数マシンでの共有と同期はMulti-Machine utilsを利用
  • 文書の作成・ウェブサイトの構築ともに使っているのはCode OSS
  • ビルドは特定マシンで行うことにしているので、最終的にはMercurialで集約し、メインデスクトップでビルドしている
  • ビルドはローカルビルドで、メインデスクトップ上にビルトドキュメントがある
  • ビルトドキュメントはGitリポジトリになっていて、GitでConoHa WINGのベアリポジトリにpush
  • ConoHa WINGではpushのHOOKでの更新にはなっておらず、保留される (予約更新のため)
  • SSH経由、あるいはat, もしくはcronを用いてgit pullすることで反映
  • このとき、検索インデックスの更新もかかるスクリプトを叩くようになっている

より付加的な話

  • ChienomiはTemplateとBless scriptが少しボリュームがあるものになっている
  • テンプレート更新時は自動的に全ドキュメントを更新するようになっている。これはWordPressからインポートしたドキュメントや、検索などアプリが出すページがあるため
  • アプリケーションはRack/CGIで、ConoHa WING上にRuby 3.0をビルドして置いている
  • 検索機能はpbsimply-searchutil
  • 画像でlightboxアプリケーション(vanilla JavaScriptで書いた簡単なもの)を使うかどうかはBlessとファイルパスで処理されている
  • 画像圧縮やリサイズはスクリプト処理だけど、この処理自体は手動(タイミングを手動制御したいため)。なお使っているのはImageMagickとpngquant
  • サブカラムの内容はtemplateに組み込まれているが、このためtemplateは動的生成になっている
  • 画像やCSS、スクリプトなどをビルドに含める処理はrsyncを使っており、これらの処理はスクリプトによって自動で行われている
  • トップページの記事リスト、記事一覧、Atom Feedの更新も同じく更新スクリプトによって行われている
  • topic pathはBless scriptで実現している

ちなみに、ChienomiでBlessとして使っていいる機能はちょいちょいPureBuilder Simply本体に取り込まれている。 (Chienomiだけはこれに伴ってBless scriptの削減が行われている。)

より多くの情報

このサイトのサブカラムにPureBuilder Simplyの関連記事がリストされているので、そこに色々と情報がある。 動画もある。

むすびに

一回使ってみれば「筋が良い」ということがわかるよ。

使ってみて!!!!!