abOut.nsf

新旧かまわず、またお役立ち度にあまりこだわらずに、 拡張子がnsfであるNoSQLなデータベースファイルと、それを扱うコラボレーション製品に絡んでのあれこれを。

2013/10

1回の勉強会「テクテクLotus技術者夜会」で、新たに「コミュニティ編」が始まりました。
1018日(金)の第1回では、まずはどのように運営してゆくか
参加者サイドも主体性を持ちつつ、これからどんなことをセッションテーマに取り上げたいかが主題といえました。
皆さんもアイディア/意見があったら、アンケートに書いてね、とのお話があったのですが、さて、意外に書きたいことが多いな。
時間が短かったこともあり、アンケート用紙には「ネットに書きます」と記しました。
それをここに書きます。
(思いつけば加筆訂正します)
 
"Classical"と云われる部分からの掘り起こし
クラシカルという表現になじみのない方もいると思われますが、大体Notes/Domino 8ないし8.5以降に登場したXPagesやソーシャル連携などの新しい機能に対して、それ以前から存在するNotes/Dominoの従来機能のことを、"Classical"と表現することがあり、英語圏の関連サイト上でよく見かけます。
しかし最新版においても、ユーザー利用の主体はNotesクライアントの従来機能だと思います。9から提供されるブラウザプラグインも、開発運用する場合のベース技術は"Classical"側ですし。
 
Classicalな情報の数々は、前世紀の終わり頃から、Lotus~IBMさん自身でご提供の技術リソースはもとより、個人サイト、掲示板などあちこちから提供されてきました。一見、既に十分にネット上にあふれているようにも思えます。
しかし、使用例、工夫のあれこれ、過去の提示物の結構な量は、今ではネットから消えうせてしまっています。
また、たとえば式言語について、Notes/Domino 6 で追加された関数って結構多いのですが、ループ型の関数を除いて、あまりネット上で詳しく用例が示されたり語られたりしていません。だからClassicalだけど新しい情報、の余地がけっこうあります。
 
あるいは「このアプリ、うちの社では大事な業務アプリなんだけど段々使いづらくなっててね」旧くて動作の悪いアプリケーションの再生の工夫とか、パフォーマンスや再利用性を考えたルールづくりのようなこともテーマにできるのでは。
 
 
IdeaJamの日本版みたいなもの
IdeaJamという提案提言サイトの存在は、以前夜会で紹介されて知りました。講師った解説をご参照いただければと思いますが、IdeaJamではNotes/Dominoの製品アイディアを投稿したり、そのよしあしを評価したりできます。
IBMの開発担当さんもチェックしており、アイディアは実際の製品に反映されることも多いとか。
いかんせん英語です。国境低いネット時代とはいえ自分を含む日本人技術者にとって、まだ物理的心理的敷居は高く、せいぜい覗くことはできても、思い付きを投稿するなんてとてもとても。。
この現状だと、もし日本人ならほしい機能があっても、英語圏での提案や支持がなければ結局採用の可能性は低そうな。。日本人が欲しい機能は実態以上に過小に扱われてしまってないかなという気がします。これを何かフォローできないか。
 
とはいえ具体的な形についての案があるわけではなく、月イチの夜会という形式に丸抱えさせるのも適切かどうか。。1度の夜会では扱いきれないだろうし、ネット上のサイトなど他のアプローチも要るものかもしれません。
 
Notes/Dominoの製品優位性、先進性について再認識する
夜会で話題になった際にすこし発言させて頂きました。発言自体はIBMさんのセミナーで見聞きしたことの受け売り半分でしたが。
Notesが普及に伴う「出る杭」でありつづけたため、競合製品への移行をうながすサイトや事例はけっこう目にします。逆に、「Notes移行」の事例は一見、余り見かけません。
肝であるアプリ機能では、わざわざ競合への移行のために使い勝手を落とさねばならないことが多々あるのですが、どうして競合側では生産性向上を高らかに掲げるられるのか、ここがいまいち分らないのですが、ともかく。NotesではR4くらいからかな、まぁ前世紀から普通にできるアレやコレを、競合ではできない、は、意外にNotes側の人にも知られてないのでは。。
競合からのUターン型のNotes移行事例が、実際けっこう多いと聞きます。世間が一方の情報にやや偏重している影響を横波としてかぶりがちな技術者にとっても、誇りを回復するきっかけにつながらないかなと。

NotesURLとは、"notes://"で始まるURL表記のことで、Notesクライアントがインストールされているマシンであれば、基本的に利用できます。
 
Outlookなど他のメールソフトからも、あるいはブラウザのアドレスバーからも、指定のデータベースアプリケーションや、ビュー、文書をNotesで開くことができます。
 
 
データベース(DB)部分の表記の違いで、次の2つに分けることができると考えています。

私の勝手な命名になりますが
  
1.「ファイルパス型」 DB部分がファイルパス形式
2.「レプリカID型」 DB部分がレプリカID形式
 
 
どちらを使っても同じDBが開くのですが、
複製されているDBの場合、この2つにはちょっとしたふるまいの差異が見られます。
 
それは、「常にそのサーバーで開いてくれるかどうかの違い」と云ってよいと思います。
  
名古屋で働くAさんは、普段「Nagoya1サーバー」のDBを使っています。
あるとき、広島支社のBさんから、同じDBのNotesURLをメールで受け取ります。
ただし広島でつくったURLなので「Hiroshima3サーバー」のURLです。
仮に、次のような「ファイルパス型」で受け取った場合。
notes://Hiroshima3/mail/TYamada.nsf
ー>URLどおり「Hiroshima3サーバー」にアクセスして開きます。
一方、「レプリカID型」で受け取った場合。
notes://Hiroshima3/4925xxxx00xxxxxx
ー>Aさんがクリックしても、「Hiroshima3サーバー」のDBを開こうとはしません。
身近な「Nagoya1サーバー」で開きます。


こんなことが云えそうです。
「ファイルパス型」は、常にサーバー名どおりで開くのに対し、
「レプリカID型」は、クライアントにとって一番手っ取り早いサーバーのレプリカを開く。
すなわち、以前開いたことがある、多くの場合、ワークスペースにアイコンのあるサーバーで開こうとします。

また、レプリカアイコンが積み重なってる場合は、前面に表示されているサーバーが優先されるようです。
  
DB部分
ふるまい
備考
「ファイルパス型」
DBアイコンに関わらず、
ServerAで開こうとする

「レプリカID型」
DBアイコンがServerBなら、
ServerBで開こうとする
NotesDBリンク・ビューリンク・文書リンクも
「レプリカID型」といえます
 
 どうしてふるまいの違いがあるのか、断言はできませんが、次のように類推しています。


 複製どうしのデータベースであれば、レプリカIDは常に同一ですが、ファイルパスやDBのファイル名は同一とは限りません。
別々にすることもできます。
Aサーバーでは「Gyomu/Keijiban.nsf」 だけど、
Bサーバーでは「work/MainBoard.nsf」 だよ。
ファイルパスは個々のサーバーに従属するものだから、ファイルパス形式の場合はサーバーも指定どおりのものを開くのではないか、と。


この違いを知っておけば
「ファイルパス型」は、DBのサーバーがOSをバージョンアップして新しいものに変わった場合など、確実に指定のサーバーで開いて欲しい場合に
「レプリカID型」は、ネットワーク的に近いサーバーで開いてもらえば良い場合に
といった感じで、使い分けができるのではないかと思います。


さて、IBM Notes 9.0 Social Editionから提供されるようになった Notes Browser Plug-Inでは、ブラウザ内でNotesURLを使用します。
おそらく、Browser Plug-Inでも、上記のふるまいはNotesクライアントと同様だろうと思います。ただ私のところでは検証できるサーバー環境がなく未確認です。

※今回の作文は、DOMINO懇談室での回答を自己検証して確認したことのまとめになります。
通常の複製を前提に書きました。クラスタ複製のレプリカ環境は想定していません。

↑このページのトップヘ