abOut.nsf

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

2021年4月に行われた「第31回 のの会 」での私のスライドです。@関数Talk としては第28回。


@Dialogbox について、この回から3回にわたってトークするのですが、当初はそこまで見通せてなくて、このスライドのおわりでは「もう1回くらいつづきをやるかも」と記しています。


@Dialogbox は、どの設計要素をダイアログボックスとして表示できるか。
スライドの通り、結論は「フォーム」「サブフォーム」「ページ」の3種類。
実は「ビュー」「エージェント」「ナビゲータ」…などなど、他の各設計要素についてもいちおう、@Dialogboxで指定したら表示できるかを試してはみたのですが、予想通り上記3種類以外は表示できませんでした。

さてその3つをどう使い分けるのがよいか、P.14にて個人見解として
    文言が固定のガイドやヘルプの表示を行うダイアログ用には
    「ページ」を
    表示だけでなくフィールド項目のセットも行う場合は
    「フォーム」よりは「サブフォーム」を
と記しました。
"「フォーム」よりは「サブフォーム」" と書いたのは、開発者としては「フォーム」はなるべく文書用であってほしいなと感じるからです。
未知のDBアプリを開き、デザイナーで見たときに「実際に文書としては使用されていないフォーム」が多く含まれていると、紛らわしく、設計の理解が微妙に妨げられるから。どちらでもよい場合にはサブフォームを選んでほしいな、と思う次第です。

ひとつ前の作文につづき、2021年1月のスライド、
こちらは「テクてくLotus技術者夜会」での年初ライトニングトークです。


なお、他のAmbassadorの各位のスライドと合わせ、テクてくLotus技術者夜会のページ内でも公開されており、こちらにはトークの際のビデオなんかもあります。

私のはテーマを明確にしておらず、年初のまったりした雑感雑談プラスおまけの小ネタです。

文書プロパティの作成日消えちゃった問題」に関しては、その後HCLから修正プログラムが提供されております。とはいえ、別に致命的な問題ではないことから、修正を一人一人のユーザーのPCに適用することはせずに、そのまま利用を続けておられる場合もあると思いますので、作成日を確認したい場合には提示の方法をご参考に。


そして作成日ではなく、更新日更新者に関するTIPSを付けました。

私は設計要素の更新日更新者に関する情報を「なるべく維持したい派」です。
たとえば、Notesの改修を行う際は、DBアプリのすべての設計要素を署名しなおす行為を、なるだけ避けています。この作業を行うと、すべての設計要素の更新日と更新者が、今日署名したそのIDに、統一されてしまいますが、そうすると、その時改修が行われた設計要素であるかどうかが、わからなくなってしまいます。また、過去にどういう経緯で作成されてきた設計要素なのか見えづらくなることも嫌っています。たとえばAさんが10年前に個人的な用途で作ったきり改修されてない設計であるらしい、なんてことが見えづらくなって、いつまでも無駄な設計要素が残り続ける要因となってしまいます。

そんな次第で、設計置換禁止のチェック(「更新時に再設計/設計の置換を禁止する」)がついている設計要素で、ほかの内容変更がないのに、チェックを解除するだけで更新日更新者が最新化されてしまうのもなるだけ避けたいと思う次第です。

なお残念ながら、設計要素に設計テンプレート名がついている場合に、これも更新情報を変えずに消せたらな、と思うのですがそこまでの方法は未発見です。




年明け後の1月の「のの会」は日本から選出の HCL Ambassadors によるトーク回となりました。
私も、幸いにも Ambassador のひとりとして再度任用いただきましたので、
いつもの「@関数Talk」ですが、少し短めのバージョンでトークしました。
スライド内の式では、選出されたほかのAmbassadorsのお名前を拝借しています。

ただしこれ、昨年(2021)の1月のお話です。。

ただでさえペースがノロいのに何か月かサボってしまい、本Blogでの振り返りは、
とうとう1年前の発表を追いかけてる状況になっちゃったのです。
時系列をまもって、スローでも順次、載せていきたいと思います。 
(なお、ことし2022年も Ambassadorに選んでいただけました。オミクロン株の影響で1月のトークはなかったのですが)




 スライド通り、「@Begins」「@Ends」は開発者の間でも意外と知らない人が多そう、というのは他の人が開発したアプリでこれを使ったものをあまり見た記憶がなく、かくいう私も長らく「@Left」「@Right」に文字数を添えて開発していました。


検証してみたように、「@Begins」「@Ends」のそれぞれの引数は、複数値にも対応しています。
なお、考えたら当たり前なのですが、引数の文字数が同じに揃っている必要もなさそうです。

@Begins( Address ; "東京":"神奈川")

という式で「東京」または「神奈川」で始まる住所かどうかを判別できる、といった感じです。
これを@Leftを使う式で行おうとすると、「東京」「神奈川」の文字数の違いを式に入れ込まねばならず、ちょっと面倒そうです。




2020年12月「テクてくLotus技術者夜会」でのライトニングトークに参加した際のプレゼンをSlideshareに載せました。


プレゼンはこれが初出ではなく、PDFのかたちで既に夜会のサイト内で公開されています。こちらではほかの方のトークも併せて確認いただけます。

以前も触れましたが、HCL Domino Volt の開発をやってみたい、となったら、当時も現在も、無料のsandboxサイトが使用できます。
今も、登録さえすれば、特に利用内容に制限はないようです。

夜会での私のトークは、
 あまり時間が取れないから、電車内でiPhone触りながらでも、sandboxからVolt の開発ができないか?
を、軽く検証してみたものです。

制約はあるものの、どうやら開発はできそう、というのがいちおうの結論です。

…が、この発表から9か月経ちましたけど、電車内でVolt開発…正直、おこなっていないですね。電車の乗車時間がそう長くないのもあるけど、あくまでライトニングトークのネタだったということで。


スライドの最後に「他に気づきがあればblogで作文の際に追記いたします」とあります。
9か月遅れでようやくその作文をここに記しているものの、そんなわけで追加の気づきはありませんが、2点補足を。

・スライド前半に記した、iPhoneからはsandboxへのリンクが表示されない状況、現在の構成ではもう、発生していません。
 今はこちらから入っていただくのがわかりやすそうです。
 https://www.hcljapan.co.jp/software/hcl-digital-solutions-sandbox/

・Voltはいま、1.0.4 がリリースされたところで、sandboxも9月30日よりバージョンアップに対応していました。HCLさんがこちらに書かれた新機能もsandbox上で、もうご確認いただくことができます。
 個人的には、提案出ししたリッチテキストが実装されたので、そわそわしながら触っています。主にPC上ですけど(笑)。

昨年11月のトークは、少し前の体験をネタにしたものです。「@関数Talk」としては第26回。


つまり、文字として設定された、体裁の違う日付、
たとえば「平成30年01月02日」「2018/01/02」「01/02/2018」
いずれも@TextToTime関数をかけることで表記をそろえることができる、というものです。

先に、第4回 のの会 での @関数Talk 第3回 についておさらいします。
スライドの P.17 より、@Text関数で 日時を 扱う場合について触れているのですが
ユーザーの環境(おもに国と地域にまつわる設定)によって、
出てくる年月日の順序が異なってしまうことに触れています。

式言語の @Text に限らず、LotusScriptのnotesDateTime.LocalTimeでテキストでも環境の影響を受け、
違う年月日の形式がセットされてしまうことが考えられます。

注意してそうした作り方を避けるに越したことはないのですが、
もし、すでにそうしたコードの影響で設定されてしまった日付を見つけてしまった場合、
@TextToTimeで、少なくともある程度は是正が効く、と言えそうです。

ただし、スライドでは、ビューの列式上で是正を行っていますが
これは、わかりやすいものの、本当の解決策とは言えないと思っています。
ビュー上の列式は、結局ビューを開いた人の環境の影響を受けるはずで
日本の元号を理解しない人の環境でビューが更新された場合は正しく是正されないのでは。
などと考えると、
本当の解決策はビュー表示している文書上の元のフィールド値の修正になるだろうと思います。




「のの会」会長?のOさんよりちょっと提案があり、自分では「しちめんどくさそうな関数だな」「なんでこんな関数があるの」と敬遠していたこちらを扱うことにしました。@Abstract  は文字列の内容を省略してくれるという関数。ただし、日本語は実質対象外…

「@関数Talk」としては第25回です。
毎回、好きなようにトークしてはいるものの、いつもの「のの会」であれば、もう少し説明を加えるところなんですが、今回に関しては、@Adstract の特徴をさっとさらっただけでおしまいにしています。
リクエストがあればつづきをしますが、7カ月たった現在も、特にそういう要望はなさそうに思います。

「のの会」の場でも、
こんな関数、使ってる方はいない(誰も使ってるわけない)ですよね✋❓」
尋ねてみたところ、当然、手は挙がりません。

と、予想していたのですが。。。
開発歴の長い参加者さんたちから、✋「使っていたよ」という声があがりました。😮

よくよく伺ってみると「省略すること」に使われているわけではないのでした。


…ここでお話は「リッチテキスト」のことに移ります。

前回記しましたように、「リッチテキスト」の内容は、ビューに表示できません。
でも、リッチテキストらしい体裁や添付されたファイルの中身までは諦めるとしても、
文字部分だけでも、なんとかビューに表示できないか?

そんな時、こんな手を使います。

フォーム内に、テキストフィールドをひとつ、追加する
・テキストフィールドは、常に非表示としておく(別に表示してもいいけどふつうは隠すでしょう)
テキストフィールドは計算結果で、式として例えば
@Abstract([TEXTONLY] ; 200; ""; "リッチテキストフィールド名")
 を設定する。(200とあるところは任意の文字数)

こうするとリッチテキストのテキスト部分だけがこのフィールドに保存されるようになります。
このフィールドを、ビューに表示する 

つまり@Abstractは、リッチテキストフィールドのテキスト値だけを取り出すのに使えるわけです。

ただし、これは、過去の方法とも言えるようです。

というのは、Notes/Domino 6 以降、@Text を使ってリッチテキストフィールドのテキスト値を取り出すことができるためです。
Notes/Domino 6 のリリースは日本で2002年の11月なので、ずいぶん前のお話です。

よりポピュラーな関数でサポートされたことで、
@Abstract のほうは、いまではあまり活用されなくなっているようです。

とはいえ、もちろん @Abstract も引き続き使用することはできますし、
古いアプリケーションや、その設計を再利用して作成したアプリには、
コード中に@Abstract が残っていた、なんてことがあるかもしれません。




 

8カ月も前の会を振り返るとなると、スライドを見ても、その時の自分の考えていたことになかなか追いつけずに我ながら困るのですが、まあ追ってみます。こちらは昨2020年9月の「のの会」より。「@関数Talk」としては第24回。


「フィールドを消す」関数を前の回でお話ししたのに続き、
「フィールドが消えているかどうか」を表す関数を扱いました。まとめて再掲すると、
  • @Unavailable と @DeleteField …フィールドを消すのに使用
  • @IsUnavailable  …フィールドが無いことの確認
  • @IsAvailable  …フィールドがあることの確認

その項目が、あるとかないとか、消すとか。
こんな関数が準備されているのは、Notes/Dominoのデータ的な特性を反映している、と云ってよいかもしれません。

いま現在も、ポピュラーなデータベースといえば、OracleやSQL Serverなどに代表されるリレーショナルデータベース(関係データベース、RDB)でしょう。Dominoと競合するソリューションでも、基盤となるデータベースそのものはRDBである、というものが目立ちます。

RDBでは、こうした用途の関数は考えにくいか、たぶんありえないでしょう。
RDBではすべてのレコードに、DB(表)で定義されたフィールド(列)が、漏れなく、存在します。

個々のレコード(行)ごとにフィールドを消したりは、できない、
値がないということはあり得ますが、入れ物であるフィールドは、値が空でも、あります。
ある以上、あるかどうかを聞く必要もないわけです。

一方で、ついでに触れた、
  • @IsNull …フィールドに値がないことの確認
は、フィールドの有無ではなく値の有無を聞くものなので、
RDBでも、存在の余地があると思われます。

Notesの式言語は簡易言語、今風に言えばローコードですが、
今風に言えばNoSQLであるデータベースの柔軟な構造に対応して、
かゆい所に手が届くような関数のバリエーションが存在する、ということで。


さて、スライドではまとめとして、ビュー画面のサンプルで補足をしています。

各列は見出し通りの式を設定しているのですが、最後(P.28)でふれたように、右端の列、
@IsAvailable(Body)
の式は、どの行も結果はすべて「0」でした。

と、いうのは、リッチテキストフィールドは、値をビューに表示することができません。
実際のフィールドがあろうがなかろうが、結果は常に「0」となってしまう次第です。

これ、伏線として入れたわけではなく偶々だったんですが… この続きは、次の回にて。

コロナ禍の影響もあって「のの会」も、ときどき開催間隔が延びています。その間に、ここで作文するまでの遅延を取り戻せばよいのに、なぜかむしろ悪化させてしまい、昨年8月に行ったトークを、3月が終わる夜に振り返ろうとしております。余談ですが、自分の所属する会社が消滅する夜でもあったりします。
「@関数Talk」としては第23回。


ヘルプに「同じです」と明記されている @DeleteField と @Unavailable は、ほんとに同じなの?と意地悪な期待も寄せつついじってみたのですが、確認できた範囲内では、やっぱり同じ関数でした。

前説に使った @SetField と FIELDキーワード も、構文は違いますが、機能としては同じと言えます。
昔ばなしをすれば、古いバージョンでは、使える場所に少々差があったりしたのですが、最近のバージョンではそれも意識しなくてよいようです。


そんなわけで…22ページ目でちらっと触れたお話になります。

 @DeleteField と @Unavailable を使用する際の構文。
 ヘルプに掲載されている構文は、FIELDキーワードを使用するものだけですが、
 実際には  @SetField の引数として使う構文でも問題なさそうです。


まとめの29ページ目で、「内部のフィールドそのものを消す」と記しました。
LotusScript がわかる方には、「フィールドの Itemそのものを削除する」と申せば通じやすいでしょうか。

フィールドをクリアする方法としては、ほかに

 FIELD TextA := "" ;   FIELD NumberB := 0 ;

などと、ヌル値や0をセットする方法も考えられます。
これはクリアしているようでありながら実際には、ヌル値や0を明示的にセットしているとも言えます。
これに対し @DeleteField と @Unavailable を使った場合は フィールドItemそのものが消え、
ただし設計上にフィールドの定義が存在していれば、
保存した時には新規文書と同様に初期値がセットされる形でフィールドが復活する。

こんな風に云ったらご理解いただけるでしょうか。



まもなく自分の勤め先も @Unavailable となります。具体的には合併で消滅会社となり、存続会社である合併先の社名に変わるので、単に無くなるわけではなく、新たに初期値化される、といってよいのかな?


2021年を迎えてから、こんな事象が発生しています。

Notesの文書プロパティで、年明け後に作成した文書の作成日が表示されていません。


現象と、複数の環境での再現性を確認してから、内外それぞれのHCL Ambassadorsどうしのコミュニティでポストしました。すぐ中野さんが応じられサポートに投げてくれ、また検証を重ねてくださいました。海外でも応答があり、そのうちPer Henrik Lausten 氏がTweetで拡散してくれました。これにHCLの関係者が反応してくれたため、今後何らかの対策が出てくるものと思われます。


再現は簡単です。
もしNotesクライアントがお手元にあれば文書を作成してそのプロパティをご確認ください。
9, 10, 11などの現在サポート中のバージョンだけでなく、手元の古いクライアントで6.5でも再現しました。

ざっと検証した範囲で、あくまでプロパティ上での表示の問題のようで、
式言語の@Createdや
LotusScriptのNotesDocument.Createdで文書の作成日を取り出すことはできるので
深刻な問題ではないのかもしれませんが、何かと不便感はあるかもしれません。
なお中野さんからはエージェントの作成日にも再現があるとのご報告があり、当面は様子見ですね。。


<追記>中野さんの方でも確認された内容を記事化くださいました。よくまとまっていますのでぜひご参照ください

<2021Jan10追記>HCLさんからのサポート技術情報が掲出されました。

2020年もあとちょっとで終わりという今ですが、7月の「のの会」でのトークの振り返りです。
「@関数Talk」としては第22回。


@AllChildren と @Alldescendants は、いずれもビューの選択式のために存在するといってよい関数です。が、単体では活動することができず、"|" (or) とセットで使用されるのが常です。

いっぽう、最後に触れた @IsResponseDoc は、そうした使命?を帯びていません。

だからもし「返答」「返答への返答」文書だけを表示したいビューを作るなら

SELECT @IsResponseDoc

という式が使えます。

ただしビューのプロパティで「返答文書の階層表示」にチェックしなければ。

プレゼンの最後で触れたことですし、「返答文書の階層表示」についてざっと。

ビューは指定されたソートに合わせた順序で並ぶのが常です。
それは「返答」「返答への返答」とても例外ではなく
例えば作成日順のビューでは文書の種類にかかわらず作成された日の順に並びます。

それが、「返答文書の階層表示」のチェックがついたときに、そのソート順を無視しメインの「文書」に連なり、スレッドに適した順序で表示されるのです。

ただし「返答文書の階層表示」がチェックされた状態だと、親となる「文書」抜きでは「返答」「返答への返答」文書は、連なるべき相手がないので、表示すらされなくなります。


したがってもしメインの文書抜きで「返答」「返答への返答」を表示したいという場合があれば
「返答文書の階層表示」はチェックしないのが正解、です。



12月の現在に戻って。

12月の中旬に恒例の発表があり、幸いにもHCL Ambassadorとしての認定を継続することができました。
(このブログでは触れたことがなかったかも。HCL Masterの名称が夏に変更され、HCL Ambassadorとなりました)

前身のIBM Championのときは1回だけでしたが、のの会やテクてくなどのコミュニティで発表の機会をいただいたりしたのを
どうにか引き続き認めていただけたようです。
1年前の投稿ペースの遅れが取り戻せていませんが、引き続き活動させていただければと思います。

前回の流れを引き継ぎ、日時系のねたでお話させていただきました。
第23回「のの会」、@関数Talkとしては21回目です。


スライド内でも触れましたが、「メジャーな使い方」「マイナーな使い方」というのはあくまで私の主観でした。

6月4日にトークした会場では、”マイナー”と分類した側に「あれ、私はこっちのほうをよくつかうなあ」というお声がありました。他の回でも、会場でトークしていると、けっこうそういうことがあるのですが、使われ方は千差万別。業務経験がそれなりに長いつもりでいても、安易に「メジャー」「マイナー」なんて断定は、やはりイケナイようです。


今回発見した、60秒・61秒が有効に変換される謎については、「うるう秒対策ではないか?」というのが真っ先に考えられます。ネット検索によれば、1972年から昨2019年までの間にうるう秒は27回あったそうですから、1~2年に1回発生しているわけです。
もし実際に、うるう秒の時刻を関数が変換することになっても、値が返せないことがないように配慮されているのでしょう。
ただ、過去のうるう秒はいずれも「60秒」の1秒が挿入された事例ばかりで「61秒」というのはないはずなのです。が、ここは念のためにバッファーをとって許容しているのではなかろうか、といった趣旨のご意見が、会場に居たエキスパートさん(御代さんだったかな?)からありました。

第21回、3月の「のの会」を振り返ります。
@関数Talkとしては第20回。
第2回のトークで語ったことにこじつけて
時間の調整に使われる @Adjust について確認しました。


3月の会では、@Adjust から派生した、「日時定数」のお話のところで参加者からの質問があり、その場で一緒に検証してみると意外なことがわかって「えーっ」と声があがりました。

要はこんなことが分かった感じです。
「日付だけの定数には、48時間近い幅がある?」

その時の会場での検証方法と、たぶん式は違うんですが、
例えばこんな式。

@Adjust([2020/01/01];0;0;0;23;59;59)

戻り値は 2020/01/01 です。

ところが

@Adjust([2020/01/01];0;0;0;-23;-59;-59)

こちらの戻り値も 2020/01/01 なのです。

もちろん、時間まで明示された式では、戻り値は期待通りのものを返します。

@Adjust([2020/01/01 00:00:00];0;0;0;0;0;-1)

戻り値は 2019/12/31 23:59:59 、という感じです

ひとつ前の式と違い、たった1秒しかマイナスしていないのに、きっちり日付も変わっています。

どうやら、日付だけの日時定数と、日付+時間 の日時定数は内部値が同じではないと考えたほうがよさそうです。

ことし2月の実施、第21回の「のの会」でのトークを振り返ります。
「@関数Talk」としては第19回。

@Dbcolumn・@DbLookup の シリーズ4回目と
@DocumentUniqueID・@InheritedDocumentUniqueID の シリーズ2回目を
ちょっとした関連を糸口にして、なんとか1つに押し込んだような感じです。


この回では @DocumentUniqueID・@InheritedDocumentUniqueID の 2つ目の使い方として@Text(@DocumentUniqueID) と組み合わせた方法を記したのですが、@InheritedDocumentUniqueIDについては、かなり制限された利用しかできないことを補足しておきたいと思います。

前回、1つ目の使い方としての文書リンクのところでも少し触れましたが
@InheritedDocumentUniqueID は基本、返答文書や返答への返答文書が作成されたタイミングに警鐘元である親文書のIDを拾ってきます。それ以外のタイミングに @InheritedDocumentUniqueID を用いても結果は 自文書のID、@DocumentUniqueID と同じです。

ということは、今回記したような、ビュー上の列に @Text(@DocumentUniqueID)  を記載する方法は、
カッコ内を @InheritedDocumentUniqueID に変更したところで 親文書のIDにはなりえないわけです。

前回と合わせてまとめると、大雑把には次のことが云えると思います。
  • @DocumentUniqueID は、主として @Textと組み合わせて使う。
    (文書リンクとしての利用は非常に限定的)

  • @InheritedDocumentUniqueID は、主としてそのまま文書リンクとして使う。
    (@Textと組み合わせての利用はある程度限定的)

今年(2020年)2月、今思えば、コロナ前の会場開催としては最後だった「テクてくLotus技術者夜会」でのスライドになります。
もともと、5分程度でお話ししたもので、
既に夜会サイトで公開されているファイルもありますが、少し手直ししたものをSlideShareに掲載いたしました。


スライドにて書いている通り、ローカルのnsfファイル(Notesデータベース)をBox上に置いて管理するなら、

「ファイルを読み取り専用にして」「Box Driveから利用する」ことがおすすめですが

少し補足情報を加えたいと思います。


〇個人ビューを表示するには
私は業務上、大抵のデータベース上で「DB内に個人ビューを保存する権限」を有していますが
この方法でBoxにデータベースを置くと、たとえデータベース内に既存のビューであっても
個人ビューが見れなくなってしまう場合があるようです。
対策としては、一時的にファイルの読み取り専用チェックを外し、
いちどNotesからデータベースを開くと直りました。
個人ビューが確認出来たら、再度、読み取り専用チェックを付します。

〇フォルダリンク(ディレクトリリンク)は機能しないみたい
Box Drive のエクスプローラ上でのフォルダパスを、Notesのデータディレクトリ側でフォルダリンクとして設定したら、ファイルが探しやすいのではと思い試してみましたが
まったくダメでした。


なお、私の環境では、ローカルデータベースは暗号化しない設定にしています。
暗号化による影響(暗号化した状態でもBoxから開けるかどうか)は
現時点では未検証となります。

HCL Domino Volt がリリースされたのは4月。翌5月に sandbox が公開されました。
誰でも、無償で、 Volt でのアプリケーション開発をお試しすることができます。
今のところ期限も示されていないので、当面の間、試し続けることができそうです。

でも、
「無償なのはいいけど、でも、お試しサイトは、"英語" 版でしょ」

と、日本では、コトバの壁が要因になって敬遠してる人がいるんじゃないかな、と思っています。

そんな人のフォローになればいいな、というのが本作文の目的です。実はさほどの壁ではありません。


まずは登録について。

sandbox のサイト にアクセスすると「Register for an Account」というリンクがあります。
Voltsandbox1

クリックすれば登録画面。こちらに入力してゆきます。
Voltsandbox2

「* First Name」「* Last Name」 ← 名前と姓をアルファベットで。
「* Requested Password」「* Password Confirmation」 ← パスワードを決めて、2か所入力
「* Email Address」 ← ご自分のメールアドレス
「* Company Name」 ← 勤め先の英語名、企業にお勤めなら多くの場合自社のWebサイトの企業情報に載っているかと。
「* Country」 ← 国…これを読まれている大半の方は「Japan」を選択
「* Phone Number」 ← 電話番号…きちんと入れるなら日本の場合は「+81」に続けて先頭の「0」を除いた番号。固定でも携帯でも。なお、IBM時代からこうした登録は何回か行っていますけど、英語の電話が来た経験はありません。
「* Existing Deployment」 ← ここから4択。まずはDominoの利用者かどうかを選択
「* Do you have plans to deploy a Low-Code solution?」 ← "ローコードソリューションを展開する予定はありますか?"…つまりVoltの(とは限りませんが)導入予定ですね。もしすでに1年以内のご予定があれば上の3つから。未定なら最後の選択肢
「* What is your role in this evaluation?」  ← あなたの役割は?と聞いていますがつまり立場ですね。「いちユーザー」「意思決定者」「開発者」「管理者」「その他」から選択という感じでしょうか。

最後に「あなたは米国政府の関係者じゃないですよね」といった一文がありますが、ほとんどの方が該当しないでしょうから「I Agree」にチェックします。


「SUBMIT」のボタンを押せば登録完了です。と云いたいところですが、設定したメールアドレス宛に登録コードが送られてきます。
届いたメール上の「Click Here」から、アクセスしたページで届いたコードを入力するのをお忘れなく。


利用するには。
再び sandbox のサイト にアクセスし、今度は「Access the Sandbox」のリンクから
Voltsandbox3

ログインを求められるので、登録時に入力した 「名 姓」と「パスワード」を入れます。
Voltsandboxlog-in

いざ、入ってみると。あれ?
VoltsandboxWelcome
「ようこそ」ですと?
なんと、sandboxそのものは日本語表示だったりします。

この作文で本当にお伝えしたかったのはこの点です。

軽く検証してみたところ、必ず日本語になるわけではありません。
ブラウザの設定言語にあわせてsandbox上のインタフェース言語が自動的に決まるみたいです。
すなわち、ブラウザの言語が「日本語」である方には日本語で表示されるかと

英語と付き合わなくてはならないのは、登録時とログイン時だけだったようです。

後は日本語ベースのメニューで、存分に開発をたのしんでいただければ。
以上、「お試しサイトは日本語OKですよ、やらない理由はないかも?」というお話でした。

Notesでグラフを出す方法はないかな、
5年くらい放置していた案を、昨年12月の「テクてくLotus技術者夜会」で発表してみました。

グラフ表示は、けっこういろんな方が頭を絞ってきたテーマです。
Web版でのHTMLベースの実現方法、XPagesでDojoを交えての実現…など、
探せばいくつかのやり方や事例が見つけられます。

また、新ソリューションのHCL Domino Volt では、現時点で2種類のグラフを標準で実装します。
確認・体験したい方はぜひ、こちらなどで概要を確認いただくか、
sandboxに登録すれば無料で自由にアプリづくりが行えますので、こちらをご参照の上、軽い気持ちでお試しください。

一方で、私がやりたかったのは
「従来からのNotesクライアント上で、それなりのグラフを出すこと」
でした。

こちらが、テクてくLotus技術者夜会のライトニングトークに使ったプレゼンの公開版です。


夜会の際は、当日になってから慌ててプレゼンを作り、分かりづらいところが多分にあったのをトークで補っていました。
それを、プレゼン単体でも多少は主旨をわかっていただけるよう、今年になってから手直しを加えた「公開版」となります。


ところで調べてみると、やはりこの分野でも「先達」たちがおりました。次に挙げるのは2007年にそうしたアイディアを出しあった3人の開発者のアプローチを紹介した記事です。

Lotus Guru :: Blogger Recap: Gantt Charts in Notes Views

「Notes Chart」などに彼らの名前を加えて Web検索すると、他にも関連するアプローチを見つけられます。
先達たちのディスカッションに、だいぶ遅ればせながら、参入できてたらいいなという淡い希望を抱いています。
ただ、いかんせん、ほぼ13年前の記事です。残念ながらリンク切れしていて今では詳細を知ることができないものもあります(2020年6月現在)。

私の実現案は、イメージリソースを使用している点で、Vitor Pereira氏の案と共通していそうです。ポップアップで図形の名前が表示されてしまう弱点も同様。

特徴は長さを細かく表現できること。1pixel単位で1,000ちょっとまで刻めます。

グラフの種類としては「横棒グラフ」だけなので、バリエーションは限られますが、
こんなことはできます。

  • Notesなのでカテゴライズの中にグラフを入れて、広げたり畳んだりできる
CategorisedChart
  • 右寄せと左寄せを併用することで 男女比のピラミッドグラフなど「バタフライチャート」の表示ができる
ButterflyChart
この例ではグラフの画像も2色分用意

前述のようにNotesクライアントをターゲットに考えましたが、夜会で発表した際には、Webブラウザでの表示なら、名前が出てしまうポップアップの欠点も気にしなくてよいのではとの助言もいただきました。

昨年12月の実施、第20回の「のの会」でのトークを振り返ります。
「@関数Talk」としては第18回。@Dbcolumn・@DbLookupのシリーズが続いていたのですが、息切れしたので別の関数を挟むことにしました。


今回のネタは、@DocumentUniqueIDと@InheritedDocumentUniqueID。
ちなみに後者は名前の長さが目に付くことから、私は「@関数の中で最長だろう」とずっと思い込んでいました。この作文にあたってよくよく確認してみると、同率で3番目でした。

通常、@関数が返す値は、文字とか数値とか日時なのですが、
@DocumentUniqueID、@InheritedDocumentUniqueID を、そのままフォーム上で使うと、
戻ってくるのは黄色い文書リンクです。

しかし、この「文書リンク型」の利用法、どう役に立つのかはいまいち謎でした。
とくに@DocumentUniqueIDについてはクリックしても何も発生しない「自分へのリンク」です。

のの会当日、(Sさんからだったかな、)もしもNotesの文書それ自体がコピーされた場合に、
コピー後の新しい文書から、元の文書に飛べるのでは、とのご意見がありました。

改めて確認してみると、「表示用の計算結果(Computed for display)」でない限り、その通りに動きます。

また、それで思い出し検証したのですが、バージョン管理の設定を使用しているフォームでは
リンクが機能することを確認できました。

英語版画面で恐縮ですが、バージョン管理の設定とはこれです。

設定すると文書を編集し保存する都度、新規文書が追加されます。
「新規文書を返答文書に」「以前の文書を返答文書に」「新規文書を兄弟文書に」
の3通りから選択しますが、
「表示用の計算結果(Computed for display)」でなければ、新規文書からのリンクが以前の文書へのリンクとなりました。

バージョン管理の機能自体、そんなに頻繁に使用されているとは思いませんが、
もし機会があったらご参考に。

電車通勤しない生活が続いていますので、その間に残した宿題をさっと片付けたいところですが、ついついコロナ系のニュースばかりを眺め暮らす日々です。

昨年11月の「のの会」でのトークを振り返ります、「@関数Talk」としては17回目。
@DbColumn@DbLookupをセットで探索する第3弾となります。



"Recache"については前々回での認識不足もあって、改めておさらいをさせていただき、その有意性を確認しました。
なおP.17 - 19で紹介しているヘルプ記事ですが、のの会開催当時はリンク切れしていたものが
現在ではHCLさんのサイト内に移管・復活していますので、代わりにこちらをご参照ください。


スライド上は前後しますが、冒頭でおまけをつけ、@DbName、@ReplicaIDについて軽く触れました。
現在のNotesのアプリケーション(DB)を特定するための関数です。

「サーバー名とファイルパス」の形で返すのが@DbName、
「レプリカID」の形で返すのが、@ReplicaIDです。

@DBColumn や@DBLookupでは、
2番目の引数に@DbName・@ReplicaIDのどちらを使っても(あるいは””で略しても)、
現在のDBを指定したことになります。

現在のDBではなく、ほかのDBを指定したい場合は
「サーバー名とファイルパス」型・「レプリカID」型のいずれかで対象DBを明示するのですが、
どちらで明示するのがベターか、スライドの P.27 では明言しませんでした。

「サーバー名とファイルパス」型のほうがソースを見たときわかりやすいのですが
「レプリカID」型のほうが、複数サーバーで運用している環境では融通性が高いことになります。

今は、コロナ騒ぎ真っ最中、オリンピックまで延期が決定し、新学期はいつ始まるの?それどころか非常事態宣言がでるかも…
と、落ち着かない世間なのですが、
ここでは、まだコロナのコの字もなかった昨10月の「のの会」を振り返ります。

前回に続き、@DbColumn@DbLookup を並べてお話しする第2弾でした。
「@関数Talk」としては第16回。


このシリーズは結局2月までかけて4回お話しし、通しで見ると構成がややいびつです。。この回のお話の半分はもっと後にまわしたほうがわかりやすかったと思います。
でもまあ…そもそもが "@Randomに" お話ししているものなのでお許しください。


また、@IsErrorとエラーに関するお話しを合間に挟みましたが、P.7で参考として挙げたURLが、案の定というべきか、IBMさんサイトから記事が消え、3月時点の今は現存しません。移管先のHCLさんのサイト内にも今のところは、見当たらないようです。HCLさん側で情報が充実するのを待つしかなさそうです。

<2020Apr05追記>復活していました、こちらです。
(参考)@DBLookup および @DBColumn で出力されるエラーのリスト - HCL KB0025977



@DbLookupのキーワード引数[FailSilent]について少し余談を。

[FailSilent]は@DbLookupで起きうるエラーをすべて吸収してくれるように思っていませんか?
そうではないんですよ、ということを今回説明していますが、P.24に触れたように、私自身もかつてはそのように思っていました。

実は…
思っただけではありません。思い込みに基づいた提案を行っちゃっています。

この回の2カ月前、Notes/Dominoの機能拡張に関するアイディアを投稿できるサイト「#dominoforever | Product Ideas Portal」で、私はこんなアイディアを出しております。

「(@DbLookupだけではなく)@DbColumnでも[FailSilent]を使えるようにして」 

勘違いに気づいたのは、つまりこのシリーズの準備検証中。

[FailSilent]は、@DbLookup特有のキー探索時のエラーだけをスキップするものだったのか。
ということは、キーで探索しない@DbColumnにつけても意味がないではないか。

そんなわけで、このアイディアは結果的に私の無知をさらしているのですが、今のところは誰からもそうした突込みは入らず、それどころか、なぜかいま現在「Likely to implement」(実装するかも)というステータスになっています。
もっとも、「実装するかも」ステータスに分類されているアイディアは700余りもあり、あまり「期待」はできません。
もし本当に実装されてしまう場合は、[FailSilent]の仕様自身が変わる…キー探索以外のエラーも対象になる、ということだろう、と思います。

読み終える時間: ~1 分👻

発表は12月でしたが、IBM Championとして認定された2015年以来、5年ぶりに後継のHCL Master としての認定をいただきました。

私がしてきたことは、関連記事を見つけたらつぶやくというBot活動のほかは、 Notes/Dominoの従来機能のおさらいや隠れたネタの掘り起こしが占める割合が高いと思います。
最新版V11がどうとか、トレンドなツールとの連携など、目新しい情報の啓蒙的な要素は薄いので、これで認定してくれるのかなぁと心もとなかったのですが、開き直って自薦し、今回は幸いMastersに加えていただきました。
支えてくださった各位に喜んでいただけたのはとても幸いでした。

祝賀パーティーが1月27日にありました。
日本から選出のMasters は今回8人ですが、全員の認定を後押ししてくれたと云える、「ニッポンの応援部長」Oさんが毎回の旗振り役。HCLソフトウェアの方々、コンソーシアム、テクてく夜会、のの会など各コミュニティの方々にお祝いいただきました。
Mastersには1人にひとつ食パンサイズのハニトーが届き
IMG_9411
私は周りに分けずにそのまま独り占めしてしまいました😋
例年より時間は長めだったと思うけど、気がつくと、宴たけなわでは〜のタイミングとなりまして。少々残念だったのは、ハニトー攻略にかまけすぎたのか、お祝いに参加くださったみなさんとあまりコミュニケーションが取れてなかったこと。その意味では十分なお礼も云えてないので、もしお読みの方がおられましたら、ありがとうございました。
お土産はこちらのノート
IMG_9415
世界?はまだわかりませんが、加藤Gマスターからハッバをかけられるのかな、ネイティブからの反応は稀なんだけど怪しげ英語でのつぶやきは続けます。




これからも引き続き精進してまいります!と云ってしまえば聞こえはよいのですが、さしあたって本Blog、5本ほど作文予定を貯めたまま年越ししちゃっています。
  • 1. 9月「のの会」でのトーク
  • 2. 10月「のの会」でのトーク
  • 3. 12月「のの会」でのトーク
  • 4. 12月「テクてくライトニングトーク」
以上、自分が年末の4半期に行ったプレゼン類の振り返りと
とりあえずはこれらを追いかけたいと思います。

↑このページのトップヘ