abOut.nsf

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

タグ:Lotus

8月の「のの会 第17回」では@DbColumn@DbLookupをセットで扱いました。

特に、@DbLookupについては、比較的早い時期から、やってよとの声をこそっといただいていたけれども、
ちょっと相手が巨大なので、長らく保留していました。

いずれにせよ、一度の回で話しきるのは無理だなと、今回はベーシックな機能の理解を主眼にしました。
ベテランの方にはやや単調かもしれませんがご了承ください。@関数Talkとしては第15回。


いっぺんに学べるほうが効率いいよね。

@DbColumnと@DbLookupを横並びにし、ざっくりと2つに共通する引数から概観し、それから@DbLookupだけの引数に触れたという体裁です。

個々の引数の具体的なパターンについては今後の回で触れてゆくつもりなので、現時点では、留意点(初心者にとってのちょっとしたひっかけ)についても触れていません。

とりあえずは、初心者の方に、「ビューから答えをもらってくる」ことのイメージをつかんでいただければ幸いです。

ExcelでのLOOKUPやVLOOKUPといった関数をご存知の方は、それらと全く同じではありませんが、ある程度イメージが得やすいでしょう。


さて、今後の回をどんな風に展開させるかはまだ悩み中で、脇道や手戻りが出やすく恐縮ながら、おそらく次の「のの会」直前に成り行きで決まってゆくのだろうと。
この2つの関数は、使い方によってはNotes/Dominoの運用を複雑にしてゆく厄介さをはらんでいると、私は思っております。
そのあたりをふまえつつもビギナー開発者にも分かりやすく、展開できるかは保証の限りではありませんが、とりあえず次のトークは、「のの会」が9月をお休みするため、10月になると思います。

Notes/Dominoと、かかわる人々にとって、2019年7月は、17年ぶりに変化の7月でした。

17年前の2002年7月、製品の母体がLotusからIBMに変わりました。
日本での実感を申せば、このとき、そんなに変化した感はなかったです。
製品名は「Lotus Notes」「Lotus Domino」のまま。
当時、五反田にあったLotus社のビルへの出入り機会が多かったのですが、Lotus社でなくなっても、ビル看板のかけ替えもなく、外目にはここがIBMであるとはわからない状態のまま、しばらくここでの業務が継続されました。

「Lotus」の呼称は、IBMソフトウェアのいちブランド名として維持されました。

10年以上経ってから、製品名が冠するブランドは「IBM」になりましたが、「Lotus」は、まだ完全に無くなってはいません。「LotusScript」と、日本には「テクてくLotus技術者夜会」が残っており😉。


17年後のこの7月、製品の母体が今度はIBMからHCLに変わりました。
今回はだいぶ外見上の変化を伴います。HCLに転籍された皆さんは、IBMのビルを離れ、仮オフィスに移られました。
製品名も、「HCL Notes」「HCL Domino」に変わったようです。

「IBM」の呼称は、HCLソフトウェアのいちブランド名として維持される…なんてことも、常識的に考えると、なさそうです。



閑話休題。7月の第16回「のの会」における、第14回の「@関数Talk」では、そんな今昔の名前の変化とは直接関係ないものの、@Name関数を扱うことにしました。


前半は、そもそもNotes/Dominoが扱う「名前」の形って…?と、少し脱線。
「名前」「作成者」「読者」の3タイプのフィールドに共通の動作を、ややひねくれた観点から確認しました。

正しい適切な形式で設定されれば、
  • 内部データ上は「CN=」などの「構成要素名」がつく形
  • 表示上は構成要素名が略され隠されている形
というのが、この3種類の"名前型"フィールドの共通特徴といえるでしょう。


「@Name」の話に入ってからは、構成要素の取り出しを含む「アクション」について。
いま、公式なヘルプを使って学ぶ人は、いきなり23種類のアクションを目にするため、この関数が少々入りづらいのではないかと思います。ゆえに入りやすいようスライドでは工夫したつもり、ですが。 
そこまでアクションの種類が豊富でなかった昔のNotesエンジニアのほうが学習はしやすかったかも。

初心者にはやや高度で、自分でも説明し難かったのもあり、スライドでは触れなかったアクションの中には、電子メールの書式をあつかうものがあります。
公式のヘルプには「RFC 821、RFC 822アドレス形式」という言葉で説明していますが、それって何?は、ここでは分かりません。
仕方なくネットで調べても、簡潔な説明はすぐに見つからず、わかるのは、今ではもっと新しい形式が存在することくらい。こういったあたりも、本当は、ここで躓かないよう、ヘルプを工夫して欲しいです。

まずはスライドであげたNotesの名前形式で使用される構成要素と、それにまつわるアクションさえ認識いただければ、この関数の基本的なところは押さえられると思います。

6月の「のの会」でのトーク、スライドの枚数はいつもより多めですが、私のスライドはページ当たりの情報量が薄く、やたら大きなコマわりでページ数を稼いでいた一部の少年マンガのようなもの、さほど中身は濃くありません。
@関数Talkとしては13回目。


DEFAULTキーワード

私は、過去の開発・改修で、使ったことも、見かけたこともなかったので、
会場の皆さんも使ったことないでしょう?、
という予想をして臨んだのですが、IBMチャンピオン以外にも、「あ、そういえば使ったことある」何名かの手が上がりました。

関数の使い方として、ヘルプには3つ挙がっているのだけど、そのうちの1つしか実際の用い方を見つけられていないというのが私の現状です。
また確認できた使い方も、式の組み立てがより簡潔になるという以外の活用法が見つからないかな、と、引き続き探したいと思います。


Let(LotusScript)

脱線してロータススクリプトのステートメントについて。
実は、ロータススクリプトでの変数の代入にはLetというステートメントが隠れているというお話。
多くのベテランの方には既知だったのかもしれません(私は知らなかったけど)。とくに、VBに詳しい方にとっては。(ロータススクリプトはVBに準じた仕様で作られているので)


@Platform

このPCのOSは何?このサーバーのOSは何?というのを、見分けることができる関数なのですが…
いま現在、変な特徴を持った関数といえそうです。
スライドに出しましたように
  • 現状、古いバージョンしか表示できないOSがある(Windows)
その一方で
  • サポートされたばかりのデバイスに対応している(iOS)
iPadで利用できるNotesのクライアントアプリ「IBM Domino Mobile Apps」は、この(2019年)4月にようやくリリースされたアプリです。
「のの会」会場では、吉田さんに実機で見せていただけましたが
きちんと「iOS」が表示されるのを確認できました。


なお、こちらに書きました背景によるのですが、前回からNotesの検証には、10.0.1 英語版を使用しています。今回切り出しているDesignerのショットのように、製品画面は当面、英語版での提示になると思います、ご了承のほど…。

5月の「のの会」では、2つ前の回でやり残した感を持っていた「@Middle」「@MiddleBack」について改めて各引数の組み合わせパターンを確認しました。
@関数Talkとしては12回目。



3回にわたって「@Right」「@Left」「@Middle」および、それぞれに「Back」がつく名称の関数を扱いましたが
当初思っていたほど各関数間の動きに統一性をみつけられておらず、しかしまだ何か最小公約数的な説明のつけようがあるのではないか、というのをまだ気にしています。

発見したことを"@Randomに"、順次報告してゆくスタイルをとっており、あらかじめ6つの関数の動きを押さえたうえでトークを開始していれば、この3回分はもっとわかりやすい構成になったろうと思いまが、とりあえずはおゆるしください。

なるだけ共通の考え方で、もっと短く胸に落ちやすい解釈を見つけ、将来改めて説明できたとしても、@MiddleBackの不可視文字君だけは、例外として扱うしかなさそうですけど♪

6月の作文にて恐縮ながら、こちらは4月の「のの会」の補足。

3月に行った@Middle、@MiddleBackのお話が中途だったので、4月は続きをやるべきじゃないの?と、思いましたが、一回休みとさせていただきました。。

平成最後を締めるべく、中野さんがNotes/Dominoの改元対応に伴う日時表示のお話をされ、
直接リンクしないものの、私のパートでも何となく日時関数のお話をさせていただきました。「@関数Talk」としては第11回。



@Created
@Modified
「作成日」と「最終更新日」の@関数です。
    いえいえ。
    たしかに、メニュー上でも、そう表示している箇所があるけれど(スライドの4、5ページ目ご参照)
    厳密には「作成日」と「最終更新日」ですね。

    主として、「@Modifiedをフォームで使用した場合に、使い方によっては実際の更新日時とは違う値を出してしまうこと」にフォーカスさせながらお話しさせていただきました。一見おかしく思えるそのふるまいは、保存時の動作を考えた場合に、決しておかしな仕様とは言い切れないことも申し上げたかった次第ですが、そこまでうまく伝わったかな…。

    関連して…
    フォームに計算結果で置いた@Modifiedは、$Revisionsフィールドの最後の値と一致することに触れました。(スライド14ページ)
    $Revisionsは日本語で言うなら「保存履歴」でしょうか。
    この日参加していたコミュニティの大御所・御代さんから、
    $Revisionsに触れるんなら、その「エントリー制限」にも触れようよ、というリクエストが。

        @関数から少し外れますが
        この作文で補足しますと、標準の設定では文書を保存するたびに履歴が追加され増える一方であるところ、
        データベース(アプリケーション)のプロパティで保存する履歴のエントリー上限を設定することができます。
        10にすれば最大10件。履歴が10件に達すると、以降は保存する都度、最も古い先頭の履歴が消され、10件に保たれます。

        初期設定は0ですが、これは「履歴の数を制限しない」という意味です。
    イメージ 1
        したがって設定上は、$Revisionsに全く履歴を保存しない=0件にすることはできないわけです。
        新規保存時を除き、最低でも1件は履歴が残ることになります。


    最後に、「作成日」「更新日」に使用可能な式とフィールドの種類の組み合わせについて触れました。
    (スライド16ページ~)
    可能な組み合わせを一通り挙げたなかで、赤丸をつけているのが、私が適切と考えた組み合わせになります。
    赤丸の基準については会場でもあまり触れませんでしたが、以下のようなところかと思います。
    • 「わかりやすい」
    • 「計算回数が少ない」…作成時の計算結果は1回しか計算しないので
    • 「日付だけでなく時間も残る」…@Todayは時刻が残せません
    • 「サーバーの日時が取得できる」…@Todayは常にクライアントの時間になってしまいます
    なお、@Nowでサーバー日時を取得するためには、以前(第2回のトークで)少し触れた[SERVERTIME]引数の使用が必要になります。

    ↑このページのトップヘ