ブログ更新が２か月ほど滞っておりました。いろいろなアプリ開発にいそしんでいたり、業務が忙しかったりもしたのですが、まあ言い訳はやめます。失礼しました。
で、その「いろいろなアプリ開発」の中の１つを何回かにわけて紹介したいと思います。もともと公開前提では作ってなかったのですが、友人の助言などから考えを変えて、とりあえずツールとしては近い将来に最初は招待制みたいな感じで（無料で）公開しようと思っています。
で、そのツールは名前を nsf2dxl2web（読み方は「えぬえすえふ・つー・でぃーえっくすえる・つー・うぇぶ」）です。正式名称ではないので公開時には変えるかもしれませんが、現在はこの名前でいくつもりです。この名称が用途を表しているともいえるのですが nsf2dxl2web は「ノーツデータベースのウェブ化」ツールの１つです。ただユースケースは限られていると思っています。
このシリーズの第一回目は紹介編と位置づけ、 nsf2dxl2web の持つ機能と、自分が考えているそのユースケースを紹介します。
【機能】
本当はまず開発背景を紹介したい気持ちもあるのですが、まずは nsf2dxl2web がどんなツールなのかを簡単に紹介します。以下のような機能と特徴を持ったツールです：
・指定したノーツデータベース (.nsf) をウェブ化する（ツール利用後は Domino サーバーは不要で、nginx などの HTTP サーバーで動きます）
・ノーツデータベースはウェブ用に作られている必要はない（実行時に HTTP タスク不要、というか Domino サーバー不要）。ノーツクライアント向けの UI をウェブで可能な限り再現することを目指しています
・対象ノーツデータベースの設計を理解している必要はない。標準データベースでも独自データベースでもノーツデータベースの設計内容から UI を再現します
・ウェブ化対象コンテンツはビュー／フォルダ一覧、全ビュー／フォルダ、ビュー／フォルダからリンクされた文書だけ（文書が参照するフォーム／サブフォーム／共有フィールドも対象、ページやアウトライン、ナビゲーター、エージェントなどは対象外）。オプションで検索エンジンによるコンテンツの検索が可能になる
・文書やフォーム内のリッチテキストは画像や添付ファイルを含めて再現される（添付ファイルはウェブ化後もダウンロード可）
・文書内の DB リンク、ビューリンク、文書リンクも再現される。リンク先が他 DB の場合、その DB も nsf2dxl2web でウェブ化されていれば各種リンクが有効になる
・UI はカスタマイズ可。文書の UI はウェブ化後のフォームの UI データをカスタマイズすることで全文書の UI が変わる
・ウェブ化されたコンテンツは ACL がなく、リードオンリーとなる
2023-11-06 の現時点で上記はすべて実現できています。ノーツのウェブ化ツールは数あれど、誰が作ったかもわからないような（作った人と連絡が取れなくなっているような）カスタムデータベースまでツール一発でウェブ化できるというのはかなり珍しいはず。
（上がノーツ、下がブラウザで同じビューの同じ文書を見ている様子です。以下同様）
またノーツの超便利な機能といえるリッチテキストは可能な限り再現することを心掛けています。テーブルやタブ、セクション、フォントなどの情報はもちろん、画像（添付されていたり、イメージリソースだったり、画像データのコピペだったり、・・）や添付ファイルも再現します。添付ファイルはクリックすればダウンロードできる形で表示されます：
DB リンクやビューリンク、文書リンクも再現され、リンク先が同じデータベース内である必要はありません（ただし外部データベースの場合、そのリンク先のデータベースも nsf2dxl2web でウェブ化されている必要があります）：
ただし「ノーツをウェブで完全に再現するツール」ではありません。この辺りは↓の背景で補足します。自分の思いが含まれていて長いので（笑）、背景に興味はなく単に使ってみたいという人は読み飛ばしてください。
【背景】
そもそも何故この nsf2dxl2web を作ろうと思い立ったのか？ 理由は１つだけではないのですが、最も大きな理由を紹介します。
まず私自身が元ノーツの製品開発者として働いていた時期があり、ノーツはその設計思想含めて非常に素晴らしい製品であると思っています（今もです）。
そして様々な理由でノーツデータベースは「塩漬け」と呼ばれるような運用形態になることがあります。ノーツからウェブに移行したいけど技術的なものも含めた様々な理由からあきらめるか、膨大な移行コストを覚悟する必要が生じてしまい、「それならやっぱりノーツで」と判断されるケースです。といっても引き続き有効活用されるというよりは「過去のデータ資産を捨てるという決断ができない」ために仕方なく使い続けるような形態です（この状態を「塩漬け」と呼んでいます）。これは利用者にとっても残念ですが、以前ノーツを提供する立場にあった自分としても非常に残念な運用形態です。積極的に使いたいわけではないのに移行できないから、参照のためだけであってもノーツを使い続けなければならない、というのは誰もが不幸な状態であって、そのような状態を解決できないだろうか、とずっと考えていたのでした。
このような背景の中で nsf2dxl2web を設計しています。つまりこれが nsf2dxl2web の設計思想の１つです。このような背景があるため、上述の機能一覧の最後に記述されている「ウェブ化されたコンテンツは ACL がなく、リードオンリーとなる」があります。今でもノーツを使って業務で新規に文書データを作ったり、編集したりしてる人に向けたウェブアプリケーション化ツールではありません。そのようなケースの場合は（今でもノーツの機能を使っている場合は）私自身はノーツを使い続けることが正しいと考えています。
【パフォーマンス】
ノーツの .nsf ファイル（データベースファイル）を nsf2dxl2web ツールを使ってウェブで（HTTP サーバーで）参照できるようになるまでに必要な時間は従来の方法と比べて劇的に改善されていると思っています。数字は私の手元にあるノーツのメールデータベース（文書数＝約 75,000 、ファイルサイズ＝約 12 GB）を私が使っている Windows 11 PC （AMD Ryzen 5 Pro 6650U + 16GB メモリ）で変換した場合の参考速度だと思ってほしいのですが、約４時間弱でした（作った私の感覚ですが、このツールに関して GPU は高速化にあまり役立ってないかも）。これは文書数が多いことに加えて設計自体がかなり複雑なデータベースでしたが、それでも４時間あればなんとかなる、ということです。ここまで文書数が多くなく、1000 程度の普通（？）の独自設計ノーツデータベースであれば変換に必要な時間は軒並み一瞬でした。
我ながらかなりの高パフォーマンスが実現できていると思います。12 GB のノーツデータベースの設計なんて調べるのも嫌なレベル（苦笑）だと思っていますし、そんなノーツデータベースのビューなんて何も考えずに <table> などでウェブ化したら、ビューを開こうにも（ブラウザが） out of memory エラーを多発することになるはずです。それをコマンドを数回実行して４時間待つだけ、でウェブ移行できるならかなり楽ですよね。
【カスタマイズ】
残念ながらすべてのノーツデータベースのすべての文書でフォーム定義された通りの UI を完全再現することはできていません。最大の理由は式言語やスクリプトといったマクロでカスタマイズされているケースが多く、例えば画面内に表示される値がマクロの実行結果に依存していると（このツールはマクロの実行エンジンを再現しているわけではないので）、ツールで変換しただけでは表示結果が期待通りにならないことがあります。
ノーツ標準のディスカッションテンプレートから作ったデータベースの例。上がノーツで下が nsf2dxl2web で変換後。式言語を使った複雑なフォーム定義を完全に変換することができず、表示が乱れてしまっています：
このような標準ツールだけでは UI が乱れてしまうケースのためにカスタマイズを可能にしています。nsf2dxl2web ではノーツの（サブフォームや共有フィールドを含む）フォームに相当する設計ファイルを設計から自動生成し、文書データを表示する際には、その文書が表示用に使っていたフォームの設計ファイルを参照して文書 UI を動的に生成します（具体的にな仕組みには XML と XSL を使っているのですが、そのあたりはまたいずれ詳しく・・）。なので、フォームの XSL をカスタマイズすることでそのフォームを使う全文書の見栄えをまとめて変更することができるようにしています。この辺りはノーツの設計思想を残しつつウェブ移行していて、これによってカスタマイズ作業そのものを容易にできています（ノーツ標準のメール、ディスカッション、ドミノディレクトリーのカスタマイズサンプルを提供します）：
nsf2dxl2web が標準で提供するサンプルを適用してカスタマイズすると↑のように表示の乱れを修正することができるようになります。自分があまり UI が得意でないこともあって、実際の業務データベースをウェブ移行する際にはこの「カスタマイズ」が必要になるケースもあるのではないかと思っていますが、この辺りを（有償サービスのような形で）支援していただけるような人に使っていただけないかと考えています。ただその場合であってもゼロから移行支援するのではなく、ある程度動くようになっている状態での UI カスタマイズになるので、作業量を減らすことはできるのではないかと考えています。
【ユースケース】
想定ユーザーというか「想定利用シーン」として、「ノーツデータベースをノーツの機能としては使っていないのにデータのウェブ移行ができなくて困っている」というユースケースを想定しています。そのようなケースであればほぼカスタマイズ不要（見栄えを変更したい場合にカスタマイズが必要になるかも）でウェブ化できます。ノーツデータベースをファイルサーバーとして利用しているようなケースであればピッタリだと思っていますが、そのようなケースがどのくらいあるのかは正直よくわかってないです。
逆に「ノーツをノーツとして使っているんだけど、ライセンスのコストを下げたいからウェブ化したい」というケースにはあまり当てはまらないと思っています。このツールでウェブ化したノーツデータベースは参照可能になりますが、新規作成や既存データの編集はできなくなります。繰り返しになりますが、このようなケースは個人的にはノーツを使い続けるべきケースだと思っています。
というわけで、そんなツールを現在進行形で作っています。このブログエントリのタイトルにもありますが、これは自分のプログラマーとしての「（色々な意味での）挑戦」の意味合いが強いものだと思っています。 とはいえ夢物語を語っているつもりはなく、スクリーンショットがあるように一応稼働できる状態には開発できています。次回は nsf2dxl2web がノーツデータベースをウェブ化する上での仕組みについて紹介する予定です。
（続きはこちらです）
nsf2web2dxl の挑戦（１）
nsf2web2dxl の挑戦（２）
nsf2web2dxl の挑戦（３）
nsf2web2dxl の挑戦（４）
nsf2web2dxl の挑戦（５）
で、その「いろいろなアプリ開発」の中の１つを何回かにわけて紹介したいと思います。もともと公開前提では作ってなかったのですが、友人の助言などから考えを変えて、とりあえずツールとしては近い将来に最初は招待制みたいな感じで（無料で）公開しようと思っています。
で、そのツールは名前を nsf2dxl2web（読み方は「えぬえすえふ・つー・でぃーえっくすえる・つー・うぇぶ」）です。正式名称ではないので公開時には変えるかもしれませんが、現在はこの名前でいくつもりです。この名称が用途を表しているともいえるのですが nsf2dxl2web は「ノーツデータベースのウェブ化」ツールの１つです。ただユースケースは限られていると思っています。
このシリーズの第一回目は紹介編と位置づけ、 nsf2dxl2web の持つ機能と、自分が考えているそのユースケースを紹介します。
【機能】
本当はまず開発背景を紹介したい気持ちもあるのですが、まずは nsf2dxl2web がどんなツールなのかを簡単に紹介します。以下のような機能と特徴を持ったツールです：
・指定したノーツデータベース (.nsf) をウェブ化する（ツール利用後は Domino サーバーは不要で、nginx などの HTTP サーバーで動きます）
・ノーツデータベースはウェブ用に作られている必要はない（実行時に HTTP タスク不要、というか Domino サーバー不要）。ノーツクライアント向けの UI をウェブで可能な限り再現することを目指しています
・対象ノーツデータベースの設計を理解している必要はない。標準データベースでも独自データベースでもノーツデータベースの設計内容から UI を再現します
・ウェブ化対象コンテンツはビュー／フォルダ一覧、全ビュー／フォルダ、ビュー／フォルダからリンクされた文書だけ（文書が参照するフォーム／サブフォーム／共有フィールドも対象、ページやアウトライン、ナビゲーター、エージェントなどは対象外）。オプションで検索エンジンによるコンテンツの検索が可能になる
・文書やフォーム内のリッチテキストは画像や添付ファイルを含めて再現される（添付ファイルはウェブ化後もダウンロード可）
・文書内の DB リンク、ビューリンク、文書リンクも再現される。リンク先が他 DB の場合、その DB も nsf2dxl2web でウェブ化されていれば各種リンクが有効になる
・UI はカスタマイズ可。文書の UI はウェブ化後のフォームの UI データをカスタマイズすることで全文書の UI が変わる
・ウェブ化されたコンテンツは ACL がなく、リードオンリーとなる
2023-11-06 の現時点で上記はすべて実現できています。ノーツのウェブ化ツールは数あれど、誰が作ったかもわからないような（作った人と連絡が取れなくなっているような）カスタムデータベースまでツール一発でウェブ化できるというのはかなり珍しいはず。
（上がノーツ、下がブラウザで同じビューの同じ文書を見ている様子です。以下同様）
またノーツの超便利な機能といえるリッチテキストは可能な限り再現することを心掛けています。テーブルやタブ、セクション、フォントなどの情報はもちろん、画像（添付されていたり、イメージリソースだったり、画像データのコピペだったり、・・）や添付ファイルも再現します。添付ファイルはクリックすればダウンロードできる形で表示されます：
DB リンクやビューリンク、文書リンクも再現され、リンク先が同じデータベース内である必要はありません（ただし外部データベースの場合、そのリンク先のデータベースも nsf2dxl2web でウェブ化されている必要があります）：
ただし「ノーツをウェブで完全に再現するツール」ではありません。この辺りは↓の背景で補足します。自分の思いが含まれていて長いので（笑）、背景に興味はなく単に使ってみたいという人は読み飛ばしてください。
【背景】
そもそも何故この nsf2dxl2web を作ろうと思い立ったのか？ 理由は１つだけではないのですが、最も大きな理由を紹介します。
まず私自身が元ノーツの製品開発者として働いていた時期があり、ノーツはその設計思想含めて非常に素晴らしい製品であると思っています（今もです）。
そして様々な理由でノーツデータベースは「塩漬け」と呼ばれるような運用形態になることがあります。ノーツからウェブに移行したいけど技術的なものも含めた様々な理由からあきらめるか、膨大な移行コストを覚悟する必要が生じてしまい、「それならやっぱりノーツで」と判断されるケースです。といっても引き続き有効活用されるというよりは「過去のデータ資産を捨てるという決断ができない」ために仕方なく使い続けるような形態です（この状態を「塩漬け」と呼んでいます）。これは利用者にとっても残念ですが、以前ノーツを提供する立場にあった自分としても非常に残念な運用形態です。積極的に使いたいわけではないのに移行できないから、参照のためだけであってもノーツを使い続けなければならない、というのは誰もが不幸な状態であって、そのような状態を解決できないだろうか、とずっと考えていたのでした。
このような背景の中で nsf2dxl2web を設計しています。つまりこれが nsf2dxl2web の設計思想の１つです。このような背景があるため、上述の機能一覧の最後に記述されている「ウェブ化されたコンテンツは ACL がなく、リードオンリーとなる」があります。今でもノーツを使って業務で新規に文書データを作ったり、編集したりしてる人に向けたウェブアプリケーション化ツールではありません。そのようなケースの場合は（今でもノーツの機能を使っている場合は）私自身はノーツを使い続けることが正しいと考えています。
【パフォーマンス】
ノーツの .nsf ファイル（データベースファイル）を nsf2dxl2web ツールを使ってウェブで（HTTP サーバーで）参照できるようになるまでに必要な時間は従来の方法と比べて劇的に改善されていると思っています。数字は私の手元にあるノーツのメールデータベース（文書数＝約 75,000 、ファイルサイズ＝約 12 GB）を私が使っている Windows 11 PC （AMD Ryzen 5 Pro 6650U + 16GB メモリ）で変換した場合の参考速度だと思ってほしいのですが、約４時間弱でした（作った私の感覚ですが、このツールに関して GPU は高速化にあまり役立ってないかも）。これは文書数が多いことに加えて設計自体がかなり複雑なデータベースでしたが、それでも４時間あればなんとかなる、ということです。ここまで文書数が多くなく、1000 程度の普通（？）の独自設計ノーツデータベースであれば変換に必要な時間は軒並み一瞬でした。
我ながらかなりの高パフォーマンスが実現できていると思います。12 GB のノーツデータベースの設計なんて調べるのも嫌なレベル（苦笑）だと思っていますし、そんなノーツデータベースのビューなんて何も考えずに <table> などでウェブ化したら、ビューを開こうにも（ブラウザが） out of memory エラーを多発することになるはずです。それをコマンドを数回実行して４時間待つだけ、でウェブ移行できるならかなり楽ですよね。
【カスタマイズ】
残念ながらすべてのノーツデータベースのすべての文書でフォーム定義された通りの UI を完全再現することはできていません。最大の理由は式言語やスクリプトといったマクロでカスタマイズされているケースが多く、例えば画面内に表示される値がマクロの実行結果に依存していると（このツールはマクロの実行エンジンを再現しているわけではないので）、ツールで変換しただけでは表示結果が期待通りにならないことがあります。
ノーツ標準のディスカッションテンプレートから作ったデータベースの例。上がノーツで下が nsf2dxl2web で変換後。式言語を使った複雑なフォーム定義を完全に変換することができず、表示が乱れてしまっています：
このような標準ツールだけでは UI が乱れてしまうケースのためにカスタマイズを可能にしています。nsf2dxl2web ではノーツの（サブフォームや共有フィールドを含む）フォームに相当する設計ファイルを設計から自動生成し、文書データを表示する際には、その文書が表示用に使っていたフォームの設計ファイルを参照して文書 UI を動的に生成します（具体的にな仕組みには XML と XSL を使っているのですが、そのあたりはまたいずれ詳しく・・）。なので、フォームの XSL をカスタマイズすることでそのフォームを使う全文書の見栄えをまとめて変更することができるようにしています。この辺りはノーツの設計思想を残しつつウェブ移行していて、これによってカスタマイズ作業そのものを容易にできています（ノーツ標準のメール、ディスカッション、ドミノディレクトリーのカスタマイズサンプルを提供します）：
nsf2dxl2web が標準で提供するサンプルを適用してカスタマイズすると↑のように表示の乱れを修正することができるようになります。自分があまり UI が得意でないこともあって、実際の業務データベースをウェブ移行する際にはこの「カスタマイズ」が必要になるケースもあるのではないかと思っていますが、この辺りを（有償サービスのような形で）支援していただけるような人に使っていただけないかと考えています。ただその場合であってもゼロから移行支援するのではなく、ある程度動くようになっている状態での UI カスタマイズになるので、作業量を減らすことはできるのではないかと考えています。
【ユースケース】
想定ユーザーというか「想定利用シーン」として、「ノーツデータベースをノーツの機能としては使っていないのにデータのウェブ移行ができなくて困っている」というユースケースを想定しています。そのようなケースであればほぼカスタマイズ不要（見栄えを変更したい場合にカスタマイズが必要になるかも）でウェブ化できます。ノーツデータベースをファイルサーバーとして利用しているようなケースであればピッタリだと思っていますが、そのようなケースがどのくらいあるのかは正直よくわかってないです。
逆に「ノーツをノーツとして使っているんだけど、ライセンスのコストを下げたいからウェブ化したい」というケースにはあまり当てはまらないと思っています。このツールでウェブ化したノーツデータベースは参照可能になりますが、新規作成や既存データの編集はできなくなります。繰り返しになりますが、このようなケースは個人的にはノーツを使い続けるべきケースだと思っています。
というわけで、そんなツールを現在進行形で作っています。このブログエントリのタイトルにもありますが、これは自分のプログラマーとしての「（色々な意味での）挑戦」の意味合いが強いものだと思っています。 とはいえ夢物語を語っているつもりはなく、スクリーンショットがあるように一応稼働できる状態には開発できています。次回は nsf2dxl2web がノーツデータベースをウェブ化する上での仕組みについて紹介する予定です。
（続きはこちらです）
nsf2web2dxl の挑戦（１）
nsf2web2dxl の挑戦（２）
nsf2web2dxl の挑戦（３）
nsf2web2dxl の挑戦（４）
nsf2web2dxl の挑戦（５）
