abOut.nsf

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

コロナ禍の影響もあって「のの会」も、ときどき開催間隔が延びています。その間に、ここで作文するまでの遅延を取り戻せばよいのに、なぜかむしろ悪化させてしまい、昨年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半期に行ったプレゼン類の振り返りと
とりあえずはこれらを追いかけたいと思います。


昨日(12月18日)HCLさんから、
Android版のNotesクライアント「HCL Nomad 1.0.6」のリリースが公表されました。

Android版 HCL Nomad がリリースされました | HCL Software (Japan) Blog


iPad版の次はAndroidかあ。iPhoneの方がリリースが後になったな…と思いつつ。

いや、ついでにiPhoneで動くものも出たりしてないかなと、淡い期待を抱き、ストアを検索したけど、ありませんでした。そりゃそうだ。


ところが翌未明に偶々ある海外の方のツイートをタップしたところ、
あれっ。

IMG_9298

ストアが開き、上図の画面。いつの間にかiPhone版が出てるよ!

そんなわけで、さっそく入手し、
今までベータ版を入れる機会を持てなかったせいもあり、

のの会で使ったDBがちゃんと開くことや
FullSizeRender
FullSizeRender(ご参考ですがDominoサーバーは9.0.1)

Safariでのnotesリンクを確認したりとか、
FullSizeRender
⬇︎
出勤中に楽しみました。


7月に、コラボレーション製品群の主体がHCLに移管されてから、
ありとあらゆることがぱっと切り替わることわけにはゆかなくて、
3カ月くらい、いろんなことが変更途中…という感じでした。
だいぶ落ち着いて来ましたが、Web上で見る限り、まだIBM→HCL移行途上のものも残っている現在ですね。


さて、IBM時代の2010年から、「テクてくLotus技術者夜会」というコラボレーション製品の勉強会が毎月行われていました。

最近耳にしなくなったけど、HCLになったら無くなっちゃった?
どっこい。HCL移行後、最初は8月、次に10月と、既に2回のワークショップが実施されています。


8月はHCLサイドからの「ザ・HCLはじめまして編 」
資料がこちらに公開されています。
https://www.ibm.com/developerworks/community/files/app#/folder/eabd0ff3-d363-47f3-aef4-56242e11a9e0/ (現時点でのリンクのため、今後変わるかもしれません)
資料にないところで、HCL移行にまつわる本音話も聞けましたが、
切替にまつわるご苦労や、クラウドに関して残念な発表があった直後で矢面に立たされている辛さもあるけど、それらを上回るやりがいもあるようで、社員の方々がHCLに変わったことをとてもポジティブにとらえておられるのがよく伝わりました。


10月はコミュニティ篇で、私が6回目の「テクてく・カフェ」を担当させていただきました。
ディスカッションの成果だった、参加者の書きこんだ模造紙も入れたいところでしたが、私が勝手に載せてよいか未確認のため、現時点では割愛します。
強く印象に残ったことを書けば、いずれのテーブルでもHCLさんの強いプロモーションを期待する声が高かったこと。そして、HCL側ではなく「我々」が行いたいこととして女子会コミュニティの設立、という声が出てこれへの支持がテーブル間で広がったことでした。


次は12月の開催となりそうです。
Notes/Domino関連のコアなイベントが目白押しであるせいもあり、今月11月の開催はなく
(11/20時点情報として)コーディネータの御代さんが例年のライトニングトークで企画案を練っていて、HCLさんにて調整中、タイミングが合えば12月20日あたりに開催されそうです。

新たな開催情報があれば、こちらで告知されます。

Googleで本夜会のことを検索しても、このリンクはまだ上位に表示されず、IBM側の古いページが並ぶのが少々もどかしいですが、関心のある方は上記リンクをブックマークいただけたらと思います。



したがって移行後の2019年後半は隔月開催というペースでした。
移行前は毎月だったため、単に半減と見えるかもしれません。
しかし、
  • まだHCL側は仮オフィスで、まだ相当量残っている移行期の調整を続けながら、業務も並行されていること、
  • 対象会場確保も今は絞られること、
  • 対象社員が全員HCLに移ったわけでなく、この夜会に関しては、けっこうコアなスタッフが去られ、残った方々が引き継ぎ運営くださっていること、
などを考えると、その中で、コミュニティ維持のために時間を割いていただいていること、かなりありがたい状況だと感じていることを述べておきたく思います。

Yahoo!ブログのサービス終了に伴い、Livedoorさんのブログに引っ越しさせていただきました。
過去の作文もまるまる引っ越しましたが、いま現在、ブログ内の相互リンク箇所が、多くはまだYahoo!を向いております。
申し訳ないのですが、時間のある時においおい直してゆこうと思います。


なんの変哲も無いNotesアプリのフレームをわざわざつくる その1

タイトルに「その2」とついていますが、「その1」は1月の作文です。
(実際は1月にドラフト作成したものを、9月初め、Yahoo!が凍結される直前に手を加え、駆け込み公開したものですが)
「その1」では昔ながらのシンプルなDBに、フレームセットを始めとした設計要素を追加してみました。

このあと、追加した各設計要素のプロパティを指定してゆきます。
「その2」ではフレームセットについて。

〇本作文内で決めた名前にはマークをつけました。実際には別の名前でもかまわないと思います。
〇手元に英語版しかないので、項目見出しは実際の日本語版での表現とずれがあるかもしれません。ご容赦ください。


<フレームセット>
構成するフレームを以下のように変更します。

左のフレーム
名前: NotesNavigator
タイプ: 名前付き設計要素 - ページ
値: Outline Page
フレーム内リンクのデフォルトターゲット: NotesView
NotesNavigator
境界線のスタイル: 3-D境界線 すべてのフレームに適用
境界線の幅: デフォルト
境界線の色: (システム)
NotesNavigator_border

右上のフレーム
名前: NotesView
タイプ: 名前付き設計要素 - ビュー
値: 計算結果(次の操作によって計算結果になります)
NotesView
「@」のボタンを押した画面で、名前付き要素の名前の式: @ViewTitle
NotesView_@
ここは、あまり自信がないのですが、「@ViewTitle」ないしは「""」にしておけば、こちらが意図した動きを阻害しないようです。

高さ: 1 - 相対(または100 - パーセント)
NotesView_Size

下(右下)のフレーム

名前: NotesPreview (ここは前回お伝えした通り)
高さ: 0 - 相対(または0 - パーセント)
NotesPreview_Size
続きを読む

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の不可視文字君だけは、例外として扱うしかなさそうですけど♪

↑このページのトップヘ