ブログ始めました

　Notes/Domino のサポートをしていて色々感じる事はあるのですが、中々発信する機会が無いのでブログを始めてみる事にしました。

　実際にどんな反応が来るのかも分からないし、どれくらいの頻度で更新できるかも分からないのですが、読んでいる人にも有益な情報が投稿できるように頑張るのでよろしくお願いします。

紹介記事書いて頂きました

大川さんと村上さんから紹介記事書いて頂きました。

http://domblogjp.blogspot.com/2008/10/notesdomino.html
http://d.hatena.ne.jp/munesora/20081106/1225989311


どっちももったいないような紹介記事で恐縮ですが、もう少し役に立ちそうな話を書けるように頑張ります。。

また紹介していただきました

　Notes/Domino のブログでは大御所になると思うのですが、岩間さんからも紹介して頂きました。

IBMのサポートの方のBlogが開設 !!

僕がブログを書き始めようと思った大きな動機の一つには、岩間さんのブログが余り更新できなくなりそうだ、と言う事を聞いた事もあります。
　非常に残念がるお客様の声などを聞くと、やはりIBMとしてこのようなコミュニケーションを保っていく努力をしないといけないのではないかな、て思って自分の知っている事だけでもいいからブログにしてみよう、と思うようになりました。

まだまだどんな記事を書いていくのがよいのか悩んでいるところはあるのですが、少しでも長い間継続出来るように頑張ります。

調査/解析ツールの理想ってどんなでしょう？

今日はTips とか技術情報じゃなくてちょっと障害解析で思うことでも話してみようかな・・・と。

　IBM では昔Autonomic Computing の具現化の一つとして、 Project eLiza と言うのを推進していましたよね。自己修復機能って言うのでしょうか。障害情報を勝手に特定して勝手に直す、Software・・・
サポートにとっても理想の形態の一つです。　
　この手の話をすると、Serviceability とか First Problem Data Capture （FFDC)とか色々なキーワードが出てきますが、「実環境に負担をかけず、問題解析の上で十分な情報を解析するための情報を自動的に収集する」と言うような意味で様々な実装が考えられている事が多いように思えます。
　この点で今最も理想に近い実装を行っているものはどこなのでしょうか？　個人的にも参考にすべき見本としてHW/SWやベンダーを問わずそういう製品は勉強してみたいです。Tivoliなどの運用管理ツールも製品固有の問題解析まで行うと言うよりは一元管理を容易に実現する、と言う意味のほうが強いのではないかと思います。

　僕が考えるFFDC を実現する理想の解析ツールは「問題を再生できる」ログを取るものです。コアダンプやプロセスダンプ、NSDログはどれだけ詳しくとってもスナップショットでしかありません。
そのログがあれば、別の端末上でも問題を「再生」出来て、直したらその再生ツールで修正確認まで行える・・・そんなツールがあればサポート・お客様・開発の負担もどれだけ減るか分からないのに・・・てよく思います。　実際問題解析で一番厄介なのは再現性が無い複雑な問題を調査するときなので。。これは多くのソフトウェア・ハードウェア・ミドルウェア共通の悩みなのではないでしょうか？

　実は私が調査した件で昔、お客様側からOS側のインシデントもオープンされたために私もOS側と連携して調査をした事があるのですが、似たようなツールが提供されたことがありました。
　広く配布しているようなツールではないようなので名前や詳細は控えさせて頂きたいのですが、そのツールを導入して、アタッチした状態で問題を再現させると、別の端末ではその録画情報のようなものを使ってデバッグ出来るようなのです。（ただこの辺の再生技術までは確立していないようで、非常に多くのマニュアル作業を伴う再生作業になるようですが。）

　解析作業などは見れたわけではないので、実際にこのログが僕が前述した「理想の解析ツール」にどれだけ近づいたものなのかは分かりません。ただ、自分と同じような事を考えて本当に実現を考えている、と言う話は頼もしく思えました。リリースされる事があったら、お小遣いでその製品を買ってでもいいので勉強してみたいと思っています。

　お客様のITインフラも複雑になってきて、問題がいかに容易に解決するか、と言うのは製品の品質向上の上でも重要性が増してきています。このような技術がもっともっと台頭してくることを1エンジニアとして心から楽しみにしています。。。

年末・年始は更新をお休みします

あけましておめでとうございます。

　今年の年初の話題と言うと、Lotus Notes/Domino では8.5のリリースが1月6日に控えていますね。サポートとしてもどんな問い合わせが入ってくるのか今から心配していますが、今年もどうぞよろしくお願いいたします。

　まだブログの方は初めて一ヶ月ちょっとなので、更新間隔が空いてしまうと読者が離れてしまわないか心配なのですが、年末年始はお休みします。

次回更新日は1月5日になると思いますので、そのときにまたよろしくお願いいたします。

索引と一口に言っても・・・

　全文索引の問題などのお問い合わせでお客様と話していると、「全文索引」と「ビュー索引」がごちゃごちゃになって話しているのかな？て思うことがあります。両者は無関係じゃないので中々判断が難しいのですが・・・

「全文検索の結果がおかしいので、Updall -rを実行してみました」と言われても何も間違いはありません。と言うかサポートからもよくこの手のお願いをしているのではないかと思います。

・　Updall は全文索引も更新します。
・　ビューの状態がおかしいとビュー検索からの全文検索は影響を受けてしまいます
etc・・・

ただ、よくよく話しているとこの後Ctrl+Shift+F9を実行してみてもまだ・・・となるといよいよビュー索引と全文索引と混同しているのではないかな・・・？と言う気がしてくるので、少し確認をしてみたりします。

これは自分自身サポートを始めた当初、違いが分かっていなくてヘルプなどを読み進めていくうちに訳が分からなくなってしまったこともありました。

このようなことが起こる原因は、全文索引が*.ft と言うフォルダが形成されて比較的可視性が高いのに対し、ノーツのビュー索引と言うのが非常に見えにくいものである事がひとつの要因なのではないかと思います。

全文索引は*.ftがなければ何となく全文索引が出来ていないことはわかるし、ファイルサイズが増えていなければ索引が全く変化が無いことも予想が付くのですが、ビュー索引はNotesPeekなどを使っても見えないし、なかなか厄介です。

あえて言うならビューの索引サイズだけが、Show Database xxx.nsf コマンドや、log.nsfから確認できるデータベース情報が分かるくらいです。索引なのでNSFをバイナリエディタで直接見ても文書へのリンク状況が分かったりすることはありません。
　この点がビュー索引の非常に厄介なところなのではないかと思います。 UI上正しく表示されていれば、問題ない、と考えるしかないのではないかと思います。

ただ、ビュー索引も階層構造とかカレンダービュー、ソートなど複雑な要素は多くあるのでもう少しこの辺の可視性が高まっていくと、トラブルシューティングももう少しやりやすくなるのではないかな、と思っています。なかなか難しいとは思うのですが・・・・

インターネットメールを判別する

　たいしたネタ思いつかなかったのと、元々書こうと思っていた話は案外壮大な話だったので今日はもうちょっと何気ないお話で・・・


　昔インターネットメールを判別するいい方法ないかなあ・・・て思い悩んでいたのですが、不在通知エージェントってインターネットメールで処理を変えたりする設定があるから判別できているはずだよな・・・・て言う事に気がついて調べてみた事があります。


8.x からは不在通知処理をRouterがやるようになったので、この辺の処理は消えているみたいですが、LotusScriptエージェントで書かれていた頃は、SMTPOriginator フィールドがあるかないかでインターネットメールかどうかを判別しています。

これは他のエージェントを書く場面でも使えるかもしれないですね。
たまにテンプレートのアイディアも役に立ったりするので一度じっくり見てみると意外と色々な発見があるのではないかと思います。

全文検索： Web スタイル構文

今日はこのTechnoteから。


ビュー検索のデフォルトが Web スタイル構文になっていない

Lotus Notes　8.x からWeb スタイル構文と言うのが使える事をご存知でしょうか。
「A B」と入力して検索すると「A AND B」と解釈して検索してくれるような構文形式です。
ビューから全文検索を行う場合などUIからの処理のみに影響するので、FTSearchメソッドなどバックエンドの処理には影響しません。

Technoteでも記載があるとおり、英語版ではデフォルトで有効になっているので、バージョンアップして、「Lotus Notes」 と検索すると「Lotus AND Notes」に解釈されるので突然大量に文書がヒットしてしまったりするのです。

やはり製品のデフォルトでは、もっとも下位互換性が高いものにし、明示的にこの設定を有効にしたユーザーだけがこの構文を使うようにするのがよいのではないか？と言う議論を重ね、最終的には日本語版だけでも・・・と言う話になってこのような結果になりました。

結果としてこの辺の混乱はあまりなかったので、落ち着くところに落ち着いてよかったなー、と今でもビューから「Lotus Notes」とか入れて全文検索をするたびにほっとしたりします。

自己満足なのかもしれませんが。。。

送信メールダイアログ

Notes Design Blog でこんなトピックがあったのですが、ちょっと興味深いですね。
Send Mail Dialog Today and a Proposal to Change it

編集中のメッセージを終了しようとしたときに、メール送信ダイアログで以下のような選択肢が表示されます。(クリックすると拡大します)



この状況で、メールを送信したいことってあまりないので、「メールをドラフトとして保存しますか？」のようなメッセージにして、

はい：　ドラフト保存
いいえ：　メッセージ破棄
キャンセル：　編集続行

だけにする、と言う提案です。リンク先には画面ショット例もあります。

これは面白いですね。個人的にも賛成です。

OpenNTF Project : Google Calendar との連携をする

　大川さんが最近NotesとGoogle Calendarとの連携を模索していたのは知っていたのですが、あっさりOpenNTF にプロジェクトを立ち上げていてびっくりしました。

オープンソースプロジェクト”GooCalSync”起動中。
OpenNTF.org - GooCalSync


こういうのをやりたかった人はたくさんいると思うのですが、以下のような点を考慮して挫折した人は多いのではないでしょうか。

・　OpenNTFの運営が分からない
・　時間が無い/よいプロトタイプが無い
・　英語でProjectを回す自信が無い

大川さんがあっさり日本語でOpenNTFにプロジェクトを立ち上げていたのですが、その行動力には感服しました。

Open Source などでGlobalに活躍しているエンジニアの方ではこのようなOpen Sourceの利用の仕方には異論があると思うのですが、OpenNTFを完全にProjectのプレースホルダーと割り切ってしまったところに潔さを感じてしまいました。

個人的にはGoogle Calendarは使っていないのでこのツール自体の必要性は感じていないのですが、試みとしては本当に興味があるのでぜひとも支えて生きたいな、と思います。