ジャストプレイヤー株式会社、11月2日で10周年です。

本当に、本当に、みなさまのご愛顧のおかげで、弊社も10年たちました。

10年続かない会社の方が多い中、私のような人間が社長をやっている会社が10年も持つなんて、奇跡みたいなもんです。従業員にいっちゃ怒られちゃいますが。

大切にしてきた縁、絆をもとに、これまで以上の努力をしたいと思いますので、皆様、これからもごひいきに。よろしくお願いします。

今後のジャストプレイヤー株式会社は、日本のIDCやISPがクラウドサービスを行うにあたり、役立つソフトウェアを色々作っていきたいと思いますので、よろしくお願いします。

---

ちなみに、11月2日は、弊社従業員は創立記念日でお休みをいただいております。

WIKIPLUS 2での技術的なこだわりについて

前回は、ソフトウェアのコンセプトについて書きましたが、今回は技術的な改修点と、イノベーション的なことを書こうと思います。というわけで、ここから先は技術屋向けなので、ビジネス屋の人は一気に一番最後まで読み進めてください :)

それぞれのWIKIPLUSの技術的特徴

Nadeshiko (WikiPlus 1.x系)

Nadeshikoは、2005年初頭に、PukiWiki 1.4.6からForkし、スタートしました。

なぜWikiベースか？と言われますが、それは編集画面が公開画面からすぐに編集できるためです。

ウェブ制作会社としての営業を続けていたので常々感じていたのですが、お客さんが一番わからなくなるのは、実はタグとかそういうルールよりも、

• こちらを変えるには、あそこを設定する

というルール。これが、もっとも難しいのです。

コンピュータというのは何でもそうで、誰かが「勝手に(笑)」決めた「あっちでぽんと叩くと、こっちでにゃあと無く」ルールが、とにかく難しいわけです。たとえばWordが勝手に行う処理とかを、どこでOFFにすればいいのか、なれてる人でも難しいでしょう？

私もコンピュータを30年間使っていますが、こればっかりは人が決めたことなので、想像するしかなく、ぶっちゃけ超能力がないとわかりません。

そこで、WIKIPLUSプロジェクトは、

• 今、見てるところを編集したければ、編集ボタンを押す

このルールから始まっています。

ちなみに、我々が最初のWikiPlusをリリースしたすこし後ぐらいに、さまざまなウェブ会社さんがBlogベースでCMSを作り始めました。我々が始めたのはBlogがまだコモディティ化するまえなので、なぜBlogベースでは無かったか？といわれたら、別にBlogベースのCMSが流行ったあとに作り始めたからではないためですね。

やり始めた時期は早かったので、最初から猛ダッシュすれば相当すごかったと思うのですが(笑)

Nadeshikoは最終的に、大幅な拡張が行われたり、かなりのソースコードが差し替えられました。それでもいくつかの部分は、良いことも悪いことも含め、PukiWikiの特徴を継承しています。たとえば同じような所を上げればWIKI記法の基本構文がほとんど同じであったり、ページ名ベースの管理、プラグインの作り方などは(拡張されたものの)PukiWiki風に書けたりします。

Nadeshikoの特徴は、

• 設定は管理画面でできる
• 裏(編集可能)と表(編集不可能)という概念がある
• Smartyでデザインを作る
  • これらのデザインはページ毎に切り替えができる。
  • デザイナーは、ftp経由でSmarty(HTML内に特殊変数が入ったもの)でファイルをアップロードできる。
  • 多くのBlogでは、Blogを複数作ってデザインを切り替えるという概念があるが、WikiPlusでは元々、ページ毎にデザインを持つことができた。
• ペインという概念があり、デザインに無制限にWIKIページを埋めることができる
  • PukiWiki風に言うと、menubarが無制限にデザイン中に設置できるイメージか？
• パーマリンク機能(XXXX.html)
• 下書き保存機能
• かんたん承認プロセス
• WIKIモード中にリッチテキスト(ワープロモード：WYSIWIG)を入れることができる
• WIKI支援エディタ
• 動作モード、ユーザ情報がDBに保存されている。
• FTPデーモンと連結しており、WikiPlusのユーザと統合されている
• WikiPlusのインスタンスを動的に作成するDeploy Daemonがある
• 画像のアップローダ、リサイザ
• 各種プラグイン
• その他、色々

5年メンテナンスされてきたので、ここに記載されてない機能も山ほどあります。この段階ですでにNadeshiko自体、PukiWikiとは全く異なる作りをしているので、最後はForkというか「一部のソースを使ってる」と言った方が正しいと思われます。

Kasumiso (Enterprise WikiPlus系)

Nadeshikoをエンプラ向けに拡張したものです。行政や大学などのウェブサイトで使われています。

技術的なコンセプトは、

• ストレージエンジンのリライト
  • 完全にDBに収容
  • ロールバックなどの、コンテンツ消去に関する安全機能
• 強固な承認プロセス
  • 多段、複数承認など
• エディタの強化
  • WIKIモード←→ワープロモード をかんたんに切り替えができるようにする
    • WIKIの画面とワープロモードの画面を、タブから一発切り替えができる。
  • ドラッグアンドドロップで複数ファイルのアップロード
  • 様々なツールからコピペで貼り付ける機能
  • ワード風のリアルタイムアクセシビリティチェック機能
• などなど、たくさん（笑

と、なります。

実は、普通のWEBアプリが逆立ちしてもできなそうなことが行われています。それは、エディタがJavaAppletで全て作られているためです。

技術的に面白いところは、JavaAppletとJavaScriptの連携です。AJAXが生まれたときのような、古い技術を組み合わせてイノベーションを作り出したのが特徴です。連携しているのは、証明書がついたJavaAppletの網羅範囲とJavaScriptの網羅範囲が微妙に異なるため。また、JavaScriptが得意なこととJavaAppletが得意なことが異なるためです。それで、大きなブレークスルーを作っているのです。

このベネフィットとして、複数のファイルをエディタにDnDで放り投げると、マルチスレッドでファイルをアップロードしたり(JavaAppletはローカルファイルを触れるため)、ワードみたいにリアルタイムでアクセシビリティチェックをしたり(マルチスレッド)、様々なアプリから直接データをペーストしたり(JavaAppletはローカルクリップボードを直接参照できるため)、実にいろいろなことを実現しました。

さらにWIKIモードとワープロモードの切り替えができるようになったのですが、この話はKikyoのところでまとめて。

残念ながら、Oracleになってから、Javaがあんな感じになってしまったことと、JavaFXがらみでJava自体が結構互換性を失うアップデートをされていたりして、技術的に我々では解決が困難な問題も出始めています。

現状はちょっと不遇な状態になっています。

Kikyo (WIKIPLUS 2)

コンセプトは先日、書いたとおり、CMSではなく「かんたん編集できるウェブサイトそのもの」にするというのが目的です。そのためにUIから見直しが入っており、CMSを売りたいからデザイン集をセットにしたんだぞ！というものとは全く違う作りになっています。

とはいえ、この説明は技術屋的には「はいはい、それで?」とあしらいたいとはおもいますが。

このコンセプトでエンジニアリングチームにUIも含めた形で新たな仕様が降りてきた時、様々な仕様の大きな見直しが必要になりました。さらにKikyoでは、NadeshikoとKasumisoを経ているので、2つのプロダクトの技術的な問題をクリアすることが必要でした。

• 全体のリファクタリング
• 全体の高速化
• よりプラガブルにする
• ストレージエンジンのリライト
• WikiParser(wiki to xhtml)の高機能化
• XhtmlParser(xhtml to wiki)
• UIのフルリニューアル
• エディタの大幅強化
• DocumentRootをデザイナー管理下に置く

全体のリファクタリング

大きなソフトウェアの流れの大整理が行われ、ほとんどスクラッチからロジックの流れが書き換わりました。

部分最適と全体の高速化

ありとあらゆる箇所のボトルネック解析や、使われていない機能を解析することがから開始しました。

phpのx-debugなどを使うこともできたのですが、実際にアクセス数が多量にある本番機で、本当にかかる負荷を測定しないと見えないものがあります。

そこで一番活躍したツールがSolarisのD-Traceです。SolarisのD-Traceにはtoolkit内に、phpの関数単位で処理速度を測るソフトがあったりします。これを本番機にかけてみると、本当のボトルネックを探しやすいメリットがあります。

たとえば、

1. １つのリクエストで発生するボトルネック関数
2. １つのリクエストが呼ぶページ要素全てを読み込んだとき出てくるボトルネック関数
3. 複数のページを乱雑にページビューされたときに出てくるボトルネック関数

これらは、それぞれ異なる可能性があります。もちろん、ボトルネック関数は全て原因を考えないとならないのですが、

• サーバの収容率をあげるのは3。
• ユーザのレスポンスをよくするには1。
• ページの表示を速くするには2。

が重要です。

さらに開発という事情もありますが、1つのソフトウェアを長く作っていると、メイン開発者が途中で変わったり、短い時間しかいなかったエンジニアが、システムを余り把握せずに作ったソースなどが埋まってきます。

普通、安定性を考えると「動いているプログラムはさわらない」ものです。

となると、「とある実績のある関数A」を使って値を取得し、加工し、別の用途に使う関数ができていきます。もう接ぎ木だらけです。

ところがその関数Aはとても遅い関数だったら？

接ぎ木によってボトルネックがどんどん隠蔽され、遅い関数が再利用されたりしていきます。

さらにphpはリクエスト毎に全てが毎度呼ばれるため、そのような関数も毎度実行されます。こうなると、同時アクセスに弱いプログラムができ、1つのサーバで収容できるリクエスト数が大幅に減ります。

そこでこのような関数を洗い出す必要があります。これにつかうのが、D-Traceで、先の3つのシチュエーションでデータを取得し、ボトルネック関数を見つけ出します。

ボトルネック関数を見つけたら、原因を分析します。

たとえば、データの持ち方を変えプログラムの流れを考え直して再設計。あるいは、何度も呼ばれるならば、static変数にキャッシュ、場合によってはmemcachedを使って、無駄なインスタンス作成をなるべく行わないようにします。

このようにボトルネックを様々な場所で分析し、これ以上、どうしようも無いよな、というところまで詰めていくと、簡単に部分最適化ができます。

---

NadeshikoもKasumisoも、Wiki構文を毎度、馬鹿正直にパースしているから遅い部分があったので、これを解決するために複数の箇所でのキャッシュもします。ページに含まれたプラグインが動的なものであれば、AJAX化したり、プラグイン関数がデータ有効期限をWIKI2XHTMLコンバータに返したりして、キャッシュの為のヒント情報を渡し、キャッシュを行います(後述)。

さらに、リクエスト単位でphpが必ずしも動かなくても良いような実装も必要です。

実はphpというのはとても遅い言語で、いったんapacheからphpにハンドラが移るだけで、桁が増えるほど遅くなります。つまりphpに処理がうつったら「負け」という、側面があるのです。

そこで、手前のWEBキャッシュ(Reverse ProxyやWAFなど)で、キャッシュが行いやすいように、HTTPのレスポンスヘッダを工夫したり、1つのURIで結果が変わらないようにするなど、ウェブキャッシュが動作しやすい実装にもしています。これがヒットすれば、phpがインストールされたpreforkのapacheにリクエストがまわりませんから、レスポンスはその手前で脊髄反射です。

よりプラガブルにする

pukiwiki由来のプラグインの作りは、cmd呼び出しのaction、ブロックプラグインのconvert、インラインプラグインのinlineの固有global functionがあり、呼び出し部分はWikiConverter内に埋まっています。

Kikyoのプラグインは全く違うもので、その全てがBasePluginの継承となっています。BasePlugin内のメソッドのオーバーライドすれば、それぞれの呼び出しポイントで、そのプラグインが実行されるようになります。

プラグインはコール単位で1つのインスタンスになっています。さらに、呼び出し側のソースコードに、プラグインインスタンスの事情が残るのは微妙なので、プラグインと呼び出し側の依存関係をなるべく断つようにつくられています。いわゆるJavaでいう、Dependency Injectionです。

その他、インスタンスが呼び出し単位ではなく、ページビュー単位になるSingleton型など、継承元をかえれば動作モードが異なるようにできています。

また、なるべく多くの部分をプラグインで作れるようにするため、プラグイン呼び出しが様々なポジションで実行されるようになっています。たとえば、起動直後に呼ばれる、ヘッダ出力、Smartyに値を差し出す、Smartyフィルタとして動作する、終了時に呼ばれる、エディタに代替HTMLを返す、エディタの機能の拡張(UI)、エディタ自体の拡張、ページにアトリビュートを持たせる、承認プロセスなどを追加するなどなど。

拡張だけでなく、自分が何秒キャッシュして良いのか?とか、プラグインから様々な値をシステムにフィードバックできるようになっています。

以上のように、プラグインによって、実に様々なことができるように作られています。なぜそう作られているかといえば、

• とりあえず一通りのサイトはWIKIPLUSベースで作れるようにする

為です。ページが実質カード型データベースのようになっているのも、様々なサイトで応用がきくように作るためです。弊社は10年ほど様々なウェブサイトを作ってきましたが、これらで経験したことのフィードバックがWIKIPLUS 2は入れられているため、大抵のサイトはWIKIPLUS 2ベースに載せ替え可能になるのではないか？と思うぐらいです(根本的に無理なのは除く)。

ただ残念ながら、ユーザが独自に作ったプラグインを設置できるWIKIPLUSのサービス予定は、今のところ、弊社ではありません。

WIKIPLUSは多くのレスポンスを1つのApacheで返せるように、ユーザ同士の隔離をApacheのVirtualHost単位で行っており、全てのユーザがwebservd(apache)権限で動作しているため、phpのプログラムをWIKIPLUSのコアシステムに紛れ込ませると、同一収容サーバの権限を得てしまいます。そこで、弊社が現在サービスしてるWIKIPLUS 2は、プラグインが設置できない構造になっています。

しかし、技術的には安価なVPSと組み合わせ、1つのVPSを1サイト管理者(エンジニアリング的な意味で)にすれば、独自のプラグインをftp経由でアップロードできるWIKIPLUSのOEMサービスも可能でしょう。もしこれを呼んだ方で、そういうサービスに興味がある方はこちらまでお問い合わせください。

残念なことに弊社の事業規模では、あまり安価にVPSは作れません。ですから、特定用途向けのWIKIPLUSサービス(俗に言う、言われたら作る裏メニュー)以外ではできません。もしかすると、VPSを安く提供できるどこかの業者がOEM版を始めてくれたら、そのうち使えるようになるかも知れませんね。

ストレージエンジンのリライト

KasumisoではDBに保存されていたこともあり、DBの速度に非常に影響されやすいという問題がありました。実はKasumisoは、事実上、速度は、ほぼDBで決まってしまっていたのです。DBがPostgreSQL専用だったこともあって、どうにもスケールアウトできず、スケールアップしかできない自体が発生していました。

こういうと、最近は決まって「ioDriveが良いんじゃない？」といわれるのですが、使えば確かに速くなるでしょうけれど、それほどは変わらないでしょう。なぜかといえば、DBのCPU利用率がボトルネックだからです。Solaris上で、iostatをとるとスカスカで、prstat -mLをすると、PostgreSQLのUSRがCPUを使い尽くしています。

ディスク速度が高速化することで短縮できるのは、基本、SYSの部分です。USRはPostgreSQLの本体の中での処理時間なので、これは要するに、

• はき出すクエリが悪いか、多すぎる

為です。

ところが一言で片付けたくても、KasumisoではDAO層で様々なことをしており、これを最適化するのは本当に至難の業です。さらにストアドやVIEWも酷使しています。ウェブはリードが多いので、大抵はIndex Scanがかかるように作ってはいるものの、ここまでくると、もうミクロでの最適化ではなく、マクロでの最適化をしなくてはなりません。つまり、クエリロジックを投げるプログラムそのもの置き換えるということです。

「そこでOracle Databaseですよ!」と言われそうです。確かにそうかも知れないんですが、ソフトウェアがPostgreSQLに特化してしまったこと。もう一つ、そもそもDBにロジックの片棒(ストアド、View)を担がせるアーキテクチャの問題点ともいえるでしょう。

オープンソースDBだけでやるのはここから先は茨の道っぽいので、Kikyoでは、Hadoopかファイルベースかどちらかが良いかなという考えに至りました。Hadoopも良いのですが、大型データでの速度を上げるにはいいものの、レスポンス(反射神経)を上げる最適化にはそんなに向いているものでもありません。memcachedと併用してうまくハンドリングすることも考えたのですが、その切り分け点をうまくするノウハウは、それなりに時間をかけなくては溜まらなそうな気配だったので、今回は全てのデータを、ファイルに工夫して保存し、検索を速くするため様々なメタデータをmemcached上に乗せるようにしました。

こうすることでNFSを使えば、NFSのパフォーマンスの限界までスケールアウトできます。NFSには結構速いアプライアンスがありますし、SolarisベースのNFSでも相当なリクエストを裁くことができます。しかもmemcachedを使ったキャッシュアーキテクチャだと、ファイルアクセスがかなり少ないため、ウェブのデータアクセスの典型である「参照ばかりである」「人気コンテンツは見られるが不人気コンテンツは滅多に見られない」というアクセスパターンに合致します。

もう少し合致するには、memcachedのキャッシュアルゴリズムをLRUではなく、ZFSのようなARC型にするパッチを当てる、あるいはタグ・インデックスをつけて、ページスキャナーを回して確実に人気コンテンツをキャッシュするなど考えてみたのですが、そもそも現在のアーキテクチャでも相当量高速に裁けるので、そこは今後平均レスポンス速度向上のための技術的なバッファということで取っておくことにしました(つまりやってないということ)。

UIのフルリニューアル

UIは、「かんたんに編集できるウェブサイト（ホームページ）WIKIPLUS」ということで、最も力を入れた部分です。

まず、

• 今、見てるところを編集したければ、編集ボタンを押す

このコンセプトをさらに追求していくことにしました。

WIKIは基本1つのページに1つのWIKI要素しかありません。

そのため、編集ボタンが1つあれば、当然、そのページを編集することになります。

しかし、WIKIPLUSはマルチペインといって、デザインの中に様々な編集箇所が「WIKIページ」として含まれています。Bodyペインと呼ばれるページメタ情報を持つページを除き、その他は透過的に別のページが見えています。これはエンジニア的な言い方ですが。

ユーザからすれば、ページに編集箇所が沢山ある。デザイナーからすれば、デザイン中に編集箇所を沢山作れる。という感じでしょうか。

ユーザは、編集箇所をそれぞれをクリックしたら、編集ウインドウが開き、閉じれば編集が完了する。

こうすれば、動きはシンプルです。

このシンプルな動きを実現するとき、ページ遷移があったり、編集エディタなど多くのプログラムを読ませてしまうと、編集ボタンを押すのにためらいがでてしまいます。実は、KasumisoのエディタはJavaAppletなので、このときJavaでかかれたエディタが立ち上がるため、やはり長く使っているとエディットボタンを押すことにためらいが出るのです。

そこで、Kikyoはjavascriptベースで、かつ、エディタは常にページ遷移時に読み込まれています。ページの最新版のロードや、ページロックがかかるため、ノーリクエストで編集開始はできないものの、エディタは保母ノーリクエストで開き、必要最低限のリクエストでページ編集ができます。そして、かつ編集終了ができるように工夫しています。

• 思い立ったら即編集。

WIKIPLUSがめざしている形がこうして実現しました。

エディタの大幅強化

エディタ自体も激しくコンセプトから見直しました。

まず、WIKI記法をメインにするのをやめ、ワープロ風の画面にすること。

実はNadeshikoにもワープロモード(WYSIWYGエディタ)といわれるものがありましたが、これはJavaScriptで作られたFCKEditorを購入したものです。データ的には、Wikiの中にFCKで作られたHTMLが入り込む仕様でできており、あくまでWiki中のコンポーネントです。ですから、複数設置することができます。また、ページ内で、ワープロモードの部分と、Wikiモードの動的なプラグイン(ニュース、カレンダー、お問い合わせ等々)を同居させることができます。

Nadeshikoではこのように実装したものの、これが実にわかりにくい。やむを得なかったものの、僕が本当に失敗したなと思った実装です。

実は、もう一つの実装検討したものは、ページの新規作成時に、ページ単位でHTML型ページ、Wiki型ページと切り替える方法です。しかし、いったんHTMLで始めるとWikiモードにあるプラグインを当てはめることができなくなり、逆にWikiモードで始めると、別のスタッフがWiki文法を知らないと編集の継続ができなくなります。これはこれで大問題です。

そして、なぜやむを得なかった実装にしないとならなかったか。

通常、JavaScriptで作られたリッチテキストエディタ(ワープロモード)は、ブラウザに表示してるHTMLを直接編集し、最後にHTMLを出力します。大抵の世の中のCMSはこう言うHTMLエディタを購入したり、フリーのものを組み込んだりして使っています。

これを内部Wiki形式に変換するには、HTML to Wiki Converterが必要になります。この再現性をあげるには、ものすごく大変であることはエンジニアの人なら分かると思います。

これはちょっと無理だろうというとで、KasumiSoではエディタをJavaAppletで記述し、内部データフォーマットを、Wiki形式してセーブできるようにしました。その結果、同じページを、Wikiビューとワープロビューのどちらのビューでも編集できるようになったわけですが、代わりに失ったことがあります。JavaAppletで作ると画面表示も自作しなくてはなりません。つまりブラウザのレンダラーのサブセットのようなものを実装しなくてはならないのです。弊社に、たまたま優れたエンジニアがいたので、これを実現することができたわけですが、問題はそうやって作ったサブセットレンダラーと、ブラウザの互換性の問題がでてきます。

そりゃそうですよね。ブラウザ同士だって、こんなに互換性の問題が出てるんですから。

そうなると、ワープロモードってWYSIWIGじゃなかったの？という問題が出てきます。これがKasumisoにかせられた課題の一つです。

---

そこで、ブランニューで作るKikyoは、JavaScriptで、優れたエディタを作る必要がありました。

世の中の大抵のCMSは、コンテンツの入力系の柱であるJavaScriptのエディタを、どこかから購入して来ていると書きましたが、もってきたJavaScriptで作られたエディタの仕事はHTMLを出力するまでが仕事です。CMSはそのHTMLデータを貰って、ポスト処理を行います。つまりコンテンツに関係するメタ情報や、CMSが保有する動的コンポーネントを、エディタからは貼り付けることができません。そのためにどうしても不自然なUIが生まれたりします。なぜ、デザイナーがブロックを積み重ねるようにデザインしないとならないCMSが多いのか？それは、買ってきたエディタが出力するHTMLと「動的要素」を、並列に扱わないとならないためです。

エディタの中から画像をかんたんに動的要素（プラグイン）として貼ったり、思ったときにページ名を治したり、パーマリンクを治したり、メタ情報を変えたりするには、UIをコンセプトからエディタとシームレスなUIの再設計が必要になります。

WIKIPLUS 2のUIがエディタとその他でシームレスに繋がっているのは、そのコンセプトから絶対だったからです。

では、先の、「ワープロビュー←→WIKIビュー(WIKIPLUS 2ではコードビュー)切替」はどうするか？

WIKIPLUSは内部WIKIで管理しているため、HTMLからWIKIに変換しなくてはなりません。それ以外の方法は、WIKIをすっかりやめて、XHTMLで管理する方法です。最後の最後までメリットとデメリットを考えてみたのですが、内部がWIKI化されたメリットを重視しました。メリットは下記の通りです。

• データバリデーション
  • 実はJavaScriptベースのXHTML出力はブラウザ毎に異なり、結構乱れている。アクセシビリティや、SEO的にも良くないこともある。
  • WIKI形式はデータの重み付けをつけやすいため、データバリデーションが行いやすい。
• 動的要素(プラグイン)を設置しやすい。

この理由で、本プロダクトがWIKIPLUSシリーズを継承し、WIKIベースであることとなったのです。

Xhtml to Wiki Converter

そこで出てくるのが、XHTMLをWikiに変換する技術です。XHTMLをWIKIに変換する為には、DOM構造を抽出し、それをWIKI構文に変換しなくてはなりません。

しかもこのデータコンバートは、Kikyoのエディタの下部の「コードタブ」、「ワープロタブ」を押す毎にAJAXで呼び出されて走ります。この変換をJavaScript側でポスト時に変換する方法もあるのですが、その場合、JavaScriptがプラグインの事情を知ることが難しいので、php側で行った方が無難です。

phpはなんと言ってもやはり遅い言語なので、普通にXHTMLをWikiに変換するには、ループとデータハンドリングを最小にしなくてはなりません。ループの深いところで正規表現を使いまくったりすると、遅いため、なるべくC言語で書かれたDOMパーザを利用し、PHPプログラムをシンプルな処理にすることで高速性を実現しています。

実はWIKIPLUS 2.0.0では、再現性はまだまだ満足がいくものではないのですが、かなりのものを変換します。

Wiki to XHTML Converter

両輪で拡張されることになったのが、Wiki to XHTML Converterの部分です。実はこれ、NadeshikoからKasumisoまで、pukiwikiからほとんど手を入れられていませんでした。

詳しい事情はしらないのですが、pukiwiki自体もこの部分が聖域のように作られていて、様々な箇所にアドホックな実装として、「前処理」→「Wiki to XHTML Converter」→「ポスト処理」などが行われています。

さてWIKI構文は、XHTMLの表現性より低いため、様々な拡張を行う必要があります。

たとえば再帰処理、

私が、&style(red){WIKI to &style(bold){XHTML}; Converter};を、拡張しました。

こんな風な記述ができることで、色、ボールドなどの文字修飾を重ねがけしたり、様々なインライン要素の重ねがけができます。

変数処理。メタ情報をコンテンツ内に埋め込むこと等に使われます。

このページの名前は$pagenameです。

マルチライン実装。pukiwikiでExperimentalで実装されていましたが、本質的な実装になっています。

#style(bold,red,wrap){{
中央寄せ。もちろん&style(id=foo,blue){ここだけ青でスタイルシートでid操作する};こともできます。
}}

インライン要素中の&style(red){{マルチライン
も可能です。
が、中はインライン要素しか許されません。}};当然ですよね。

マルチラインの再帰的入れ子

#style(red){{
#style(bold){{
ここは赤くてボールド
}}
ここは赤いだけ
}}

左右ブロックのレイアウト処理

#style(width=50%,center,float){{
#image(あれこれ)
ここは右ブロックです。
ブロック要素なので何でも置けます。
}}
#style(width=50%,left,float){{

- こっちに
- 箇条書きを置いたり

|A|B|
|C|D|

テーブルを置いたりもできます。
}}

エレメント修飾節(親エレメントにパラメタを追加する要素)

STYLE(center,id=mokeke):
この行が入るべきpタグにはclass=centerと、id=mokekeが入ります。

しかし、ここには影響しません。また、テーブル内要素、リスト要素、ヘッド要素など、様々な箇所にこの表現を使うこともできます。
ちなみに、このエレメント修飾節のSTYLEも、プラグインなので独自のプラグイン拡張もできます。

以上、これは一例です。color、sizeなどを統合した、styleプラグインが例としては多かったのですが、インライン、ブロックなど、様々なものが利用可能です。

それから、今回のKikyoで、ほとんど唯一、最初のpukiwikiのソースの一部を流用しているエリアですが、上記のように大幅な拡張が行われています。

DocumentRootをデザイナー管理下に置く

WIKIPLUSは、「デザインを編集するのはデザイナーの仕事、コンテンツを編集するのはサイトオーナーの仕事」という役割分担に関する設計思想があります。逆に、デザイナーは、使い慣れたウェブデザインツール（Dreamweaver等）でかんたんにデザインを作ったり変更できたり工夫されています。

ただし、デザイナーの権限は非常に広くなっています。もちろん、デザインを崩すことも動作モードを変えて、壊すこともできます。したがって、WIKIPLUS2では、アドバンストモードという機能強化されたモードに入らない限り、ftpを有効にすることができません。なお、アドバンストモードに入ると、もれなくデザインが崩れたり、動作の保証ができなくなるのでご注意を。

アドバンストモードにするには、機能メニューからユーザの追加を行い、そのユーザにftp権限をつけます。IDは、WIKIPLUSのログインユーザと若干異なるので注意が必要です(ftpにはVirtualHostという概念がないため)。

ftpでアクセスし、ファイルを設置すると、普通のレンタルサーバのように、ファイルを参照することができます。そのため、普通にサイトをデザインすることができるのです。

WIKIPLUSは.htmlファイルをページとして解釈しますが、ページとして存在しない場合は、DocumentRoot以下の.htmlファイルを表示するため、旧サイトの移行にも便利です。

WIKIPLUSのデザインは特殊な名前である、*.design.default.tplなどといった名前で保存します。このtplがSmartyテンプレートで作られていますが、例によって、Nadeshiko/Kasumisoから大幅にできることが拡張されています。

とりあえずスタティックでデザインをして、少々の変数とタグを覚えれば、WIKIPLUSにデザイン反映できる。これがWIKIPLUSシリーズの大きな特徴です。

これについてはデザイナー向けの資料をそのうち書くのでそこで記載します。

マルチペインの強化

tplのデザイン中に、paneというものを作ることで、様々なページを張り込むことができます。

たとえば、次のようにすると、divのmenu内に、menuというパーマリンクが着いたページを設置できます。

<div id=menu> {pane permalink="menu"} </div>

pane命令は、インライン要素フィルタを通したり、ページに変数が使えたり、複数のページを列挙したり、無名paneといってページとして存在しないWIKIPLUSプラグインを設置したりできます。

デザイナーがpaneに入る横幅を制御したいときもあります。たとえば、下記のようにするとサイドメニューの横幅が150pxに制御できます。この編集エリアに「最近のデジカメでとったでかい写真」をアップロードしても150pxにリサイズさせることもできるのです。

<div id=sidemenu> {pane permalink="side1" width=150px} </div>

以上、かんたんにデザインできるが、本気になれば相当制御できるのも、WIKIPLUSの特徴です。

これらについてもデザイナー向けの資料をそのうち書くのでそこで記載します。

プロダクトデザインに対するリーダーの役割

最後に、ある場所で聞かれたことに関する、回答を。

弊社、ジャストプレイヤーは、ウェブ制作（企画、デザイン、システム）と、ウェブアプリ作成、インフラ保守、ネットワーク構築など、ウェブに関わるものを垂直的に色々と行う会社です。基本的に受託で生きてはいるのですが、受託の仕事は忙しいときもあれば、枯れるときもあります。

仕事がないときはスタッフは暇なので、その間を無駄にしないように自社プロダクトを作るという、よくあるパターンでWikiPlusは生まれました。日本中にきっとよくある受託脱却への道筋です。ところがこれがまた思うとおり行きません。なぜうまくいかないかは、また後日、ここに書こうとは思いますが、結論だけ言うと虻蜂取らず状態になるのです。

だからもし、同じようなことを考えている私と同じような立場の方がいたら、「僕ならきっとうまくできる！」と、思わずに、このことを忘れないようにした方が良いです。

• プロダクトは勝手にできあがらない。

スタッフの仕事がないときに、スタッフは勝手に良いものを作ってくれるなんて思ってたら、それは大きな責任転嫁です。

リーダーの仕事は導くことであって、

• 僕らはどんなコンセプトで
• 何を作っていくのか？
• どういう人達のために？
• 何が必要なのか？

こんなことを常日頃、制作スタッフと語り合ってやり取りしないと、良いものができるわけがないんですよ。現場に自主性を持たせましょうとはよく言いますが、責任転嫁はダメです。だから、こう言う客にこう言うものを売りたいんだというヴィジョンがあったら、現場で色々ディスカッションしあって、制作スタッフとあれこれ話し合い、時には喧嘩したり、技術的な裏付けを導き、最後に決まったことはリーダーが責任を持って方針を決めないとダメなんじゃないかなと。

ところがどっこい。実は会社に仕事がないときは経営者は奔走します。時に次の仕事を見つけるため。時に金策のために走り回ります。超忙しいのです。こんな中でそんな現場指揮なんてできません。

てなわけで、

• やるなら覚悟して、執念で一気にしないとだめ。

という、受託脱却に向けてどこかの先輩社長さんが書いた手記のような流れと、全く同じ所にたどり着きました。ええ。

そこで、今回のかんたんに編集できるウェブサイト、WIKIPLUS 2は、10ヶ月、ほとんど別の仕事を入れずに、私自身が現場に立って我々の優秀なスタッフ達と作り上げた、まさしく汗と涙の結晶になっているわけです。

ということで、やたら長いブログエントリでしたが、ここまで読んでくれ方、ご苦労様でした。