2005/11/17

ND7移行

ND7への移行の話も徐々に耳にしますが、早速USでは移行のガイドブックが公開されていました。割と網羅されているし、十分に役に立つかもしれない、と思います。

2005/11/16

テスト環境構築に関する独り言

ガチャガチャとローカルのテスト環境をいじってみています。
私のテスト環境は、ループバックアドレスを大量につけており、R4が1つ、R5が3つ、Domino 6が3つ入っていたのですが、それに加えてDomino 7も3つ入れてみました。心配されたLanguage Packも、普通に置換が成功して、何事もなかったかのように動いています。6と7の混在環境も、一度6を擬似アンインストールしたら上手くいきました。

一方、Notesクライアントは 4,5,6 と入っていたのですが、日々使うクライアントを6から7に移行したため、6なしになってしまいました。まあ6はいつか別途入れます。
それはさておき、6の環境を7に移行したのですが、そんなマルチリリース環境のため、ディレクトリの名称が Notes6\data という名前になってしまっており、悲しいかなそのまま 7 で動くことになりました。なかなかテスト環境のネーミング設定も難しいところがあります。

ND7壁紙

ND7が少しでも盛り上がるようにと、私もこの壁紙を使うことにしました。
壁紙というもの自体は、無駄なリソースを使うことになるので、あまり好きではないのですが・・・。

2005/11/01

Web Forms 2.0

AJAXもDHTMLも面白いですが、なかなかコーディング(特にDHTML部分)は大変です。

本日、Codestore の記事を読んでいたら、世の中には、 Web Forms 2.0 という規格があり、それを遵守したブラウザでは date 属性を使うだけで、ブラウザが自動的に日付ピッカーを表示してくれるそうです。

オープンソースのDHTMLコードを使えば、Notesクライアントに似た日付ピッカーが、Domino Webアプリでも簡単に作成出来るのですが、ブラウザで実装されるとなったら、これは嬉しいし、こうなればDominoのHTTPタスクも(さすがに)標 準対応してくれるでしょう。

Webの未来って、AJAXやDHTMLチックに、Web開発者が頑張り続けるのだと、いかにオープンソースライブラリが充実しても大変なところはあるけれど、標準技術としてブラウザで必要部分が実装されるなら、敷居は低くなっていくでしょうね。

追伸:Domino 7って今日ですよね。日本語版はLanguage Packになるそうですが、インストールは上手くいくかな。

2005/10/21

更新なしの日々が続いてしまいました

全くもって無名なこのブログですので、しばらく記事を書かなくとも何ら問題はないのですが、いろいろと思うところがあって、少しずつ何か書こうと思います。

USでは、ついにDomino 7がリリースされ、日本でももうそろそろなようです。まだ 7 は触っていないので、それ系のネタは書けないけれど、何かDomino関連ネタ書くことで、少しはLotusコミュニティが盛り上がるとよいのですが。
Lotusから目を離すと、今年はWeb系の技術がAJAXや Web 2.0ブームでやけに盛り上がってます。DominoのWebにも応用出来そうな部分もありますし、いろいろと考えながら。(AJAXは既に、海外の有志 たちによって、わりとDominoエリアも開拓されてきていますね)

目標は週に1本でも更新出来れば、の、のんびりペースですが。

2005/06/16

Hannover

今週は、あちこちで、"Hannover祭り" 状態です。まずは CNET の日本語記事より。

「未来のLotus Notesはこうなる」--IBMが開発の進捗をアピール


ここにあるとおり、Hannoverとは Notes 7の次期バージョンのNotes(気のはやいサイトでは、Notes 8 なんて書いてあるところもありました)

この手の情報は、まず Ed Brill のBlogにて取り上げられます

画 面自体は確かにFancyですし、RSS Feedが見えるなど次世代的な要素が組み込まれているように見えます。これまでのNotesクライアントのイメージはなく、見るからにEclipseな 匂いがしますが、Edのコメントを読むと、IBM Workplace Clientの技術を使っているというので、そうなのでしょう。機能としてはNotesクライアントの機能をそのまま移植したみたいなことが書いてありま す(It will do everything that Notes has always done)。これまでとはベースとなるエンジンが全く違うというのは不安ですが、Notesとの互換性が維持された上で、Eclipseベースになるなら ば、クライアントのプラグイン開発も容易になるでしょうし、配布や管理などももっと楽になるでしょうし、期待が出来ます。
ポイントは、やはり、 Notesとの互換性。過去の資産に手を入れなくてすむか。が、一番手で、後は初期配布の方法(Smart Upgradeが使えるかも、という期待はありますが)、必要とされるクライアントリソース(Eclipse重そう...)といったところでしょうか。

それにしても、コードネームで盛り上がるのは久しぶりに思います。反論もありそうな発表だけれど、EdのBlogに寄せられたコメントは、おおむね賛成派のようです。

2005/06/15

Sametime と QuickPlace

この2つの製品の正式名称が何かというのは、日本でも実はあまり知られわたっていないのかもしれません。いまだに、Sametime、QuickPlaceという声をよくききます。

本日、Ed BrillのBlogにて発表されていましたが、これらの2つの製品は、無事呼び名が、SametimeとQuickPlaceに戻るそうです。どうでもいい話ではありますが、すっかり旧名称のイメージがついてしまっていることを考えると、よい判断だと思います。そもそも、なんであんな名前にしたんだろうか・・・。

QPというと、Domino業界の人はQuickPlaceを想像しますが、普通はマヨネーズを想像すると思います。最近知った話では、アメリカの幼児教育における3つの重要な言葉、Please, "Thank you", "Excuse me" をまとめた用語、という解釈もあるようで、略語というのは面白い限りです。

2005/06/12

メール本文と改行

ノーツメールを使っていると、改行の入れ方が人によって違うことを感じます。インターネットメールの世界では、引用記号を意識した上で、70文字程度で改行するのが一般的なマナーになっており、長い文章を書くときは、メールソフトの自動改行機能か、本人自身による改行を行うことが一般的です。
一方、ノーツメールに関しては、メール本文に関する厳しい規定は特にありません。このため、ウインドウにあわせた表示時の自動改行機能にまかせる例も多いです。

どちらが正解ということはないでしょうが、私個人の意見では、メールに関しては、ユーザーは段落を変える以外では、改行を行う必要はないと思います。リッチテキストフィールドは、もともとワープロ的な機能があり、文章の途中(例えば読点)で改行を入れるのは、ワープロだと明らかに不自然ですし、例えばMTA機能を使ってインターネットメールになる場合は、MTAにより自動改行が入ることを考えると、相手方には美しくない改行で届くことが有り得るからです。

実は私がノーツに始めて触れた頃、メールに関しては改行を入れており、右端を意図的にある程度そろえていたのですが、あるきっかけで改行は使わないようにしました。全画面利用するかどうかなどはユーザーによっても異なるし、解像度もPCによって異なるため、自分の端末での改行が必ずしも相手端末では美しく見えない、というのが一番の理由です。最近はPCの解像度も上がり、1行にたくさんの文字が記述出来るようになりましたが、改行派の方はあらためて社内ノーツメールというものを見直してみてもよいと思います。経験的にも新人や、ノーツに詳しくない方ほど、改行派が多い気がしております。

技術的なことではありませんが、ふと日常で気になることがあったため、意見を記述しておきます。

2005/05/30

Notesクライアントでスキン

Notesクライアントでスキンといえば、NeoPlanetを利用した、Notes 6のPreRelease1が有名で、この機能は残念ながらPreRelease2で落ちてしまったものです。わりと賑やかで楽しい機能だったので、やや残念でした。

ところが、Alan Lepofskyのブログ(こここそまさに有益な「コネタ」の提供スポットです)にて、現在フリーで使えるNotesスキンがあることを知りました。

これはICODEX Software AGというところが開発、公開しているもので、こちらにて紹介されています。
実体は、dllが1つと、notes.iniに記述されるEXTMGR_ADDINS、あとはリソースの入ったDBです。EXTMGR_ADDINSを使うのは、ちょっと抵抗がありますが、まあそうはいっても、この手のことをしたい場合は必須ですので仕方がないです。あらかじめいくつかのスキンが入ってますし、自作も出来るようです。
基本的には、ワークスペースが派手に変わる程度なので、やはりNeoPlanetのようなウインドウごと派手に変わるほうが見栄えがよかったかな、、、とも思いますが、たまにはこういうお遊びも楽しいものです。

2005/05/24

DominoでAJAX

最近、Webの世界では、AJAX (Asynchronous JavaScript+XML) という言葉をよくききます。Google SuggestGoogle Mapを使うと、その技術に驚かされます(iNotes Web AccessやK-stationを見たときも感動でしたが)。

そこで、必ずネタがあると思ってましたが、「DominoでAJAX」です。Google Suggestをみると、やっぱりドミノディレクトリのタイプアヘッド検索が有力だろう、と思ったら、予想通りありました

早速、手元のテスト環境で試してみましたが、設置も簡単だし、効果もわかりやすいです。
で、気になる実装方法ですが、基本的にはクライアント部分で動くJavaScriptが、入力にあわせてサーバーのエージェントを OpenAgentで呼び出し、その引数に入力文字を渡しています。サーバー側は、XMLではなくプレインテキストで返事をし、それをクライアントが解釈するようです。
正直なところ、1文字入力するたびにOpenAgentなんてしたくないけれど、まあ、サンプルならこんなところでしょうか(本番環境なら、サーブレットがいいです。サーブレットはサーブレットで、パフォーマンス以外の面で利便性などDominoとしてどうかとも思いますが)。
Web化したときに、タイプアヘッドに対するニーズって大きいと思うのですが、これで1つは解決できそうです。AJAX自体は面白い技術ですし、他にも可能性が大きいと思うので注目ですね。

2005/05/12

Bob Balaban Lotus復帰

先ほど、Ed BrillのBlogをよんでいたら、IrisでLotusScript/Javaのクラス階層を作ったり、その後独立してDomino/JavaのエバンジェリストをしていたあのBob BalabanがIBM/Lotusに復帰するそうです。


http://www.looseleaf.net/looseleaf/LSIHome.nsf/612AD3D77C83A706852567E7006B9A50/C42ECE3A2D46834685256FFE006719AC?OpenDocument

DHTMLセクション

最近発見したのですが、Domino 6.5.1からセクションをDHTMLで提供する機能が備わっているようです。こちらのSPR対応という位置づけになるみたいです。

http://www-10.lotus.com/ldd/r5fixlist.nsf/0/47529bfeabc18af585256e1600527b41?OpenDocument

設定などの詳細はWeb Server: Additions to dynamic HTML generated for sectionsに記述されています。(日本語のリリースノートにももちろん記載されていますが、英語版しか直接リンク貼れないので)


従来までは、セクションは展開すると、いったんWebサーバーにアクセスして、展開されたHTMLを毎回ドミノサーバーが発行していました。

一方、DHTML対応すると、もともと全ての情報をHTMLとしてもらっておき、クリックにあわせてダイナミックに展開されます。この秘訣は、セクション部分をid付きの div
タ グで定義し、その部分(getElementbyID)の表示/非表示(.style.display)をJavaScriptでダイナミックに指定して いるのですが、このためNotesクライアントのセクションと同じようにみえます。従来までも、JavaScriptで関数さえ定義しておけば、同様なこ とも出来たでしょうが、セクションというのはユーザーがリッチテキストの中に書き込むこともあって、多少コントロールが難しかったこともあったと思いま す。Dominoサーバーとしていよいよ標準でDHTML対応したことは素晴らしいことだと思います。(実際問題としては、Notesクライアントユー ザーがコンテンツを作る必要があるため、Web中心の環境ではどこまで有用かというと微妙ですが)


コードもhtml内部に埋め込まれており(というのには賛美両論あると思いますが)、簡単に見ることが出来ます。



<script language="JavaScript" type="text/javascript">

<!--

function _dSectionExpand(sec) {

document.getElementById("cSec"+sec).style.display = "none";

document.getElementById("xSec"+sec).style.display = "";

}

function _dSectionCollapse(sec) {

document.getElementById("xSec"+sec).style.display = "none";

document.getElementById("cSec"+sec).style.display = "";

}

// -->

</script>

<div id="cSec1" style="position:relative; "><a onclick="return _dSectionExpand('1');"><img src="/icons/expand.gif" border="0" alt="Show details for セクション"><font size="2">セクション< /font></a></div>

<div id="xSec1" style="position:relative; display:none;"><a onclick="return _dSectionCollapse('1');"><img src="/icons/collapse.gif" border="0" alt="Hide details for セクション"><font size="2">セクション< /font></a>



クロスブラウザを意識してかデフォルトではオフになっているようですが、browser.cnfを多少変更するだけで簡単に出来るので、ブラウザが特定されている社内環境では積極的に使ってもよいかと思います。

2005/05/05

DominoデータにアクセスするDXL

developerWorksに、新しい記事が公開されていました。今回のテーマは、DXLについてで、DominoのデータにDXLでアクセスしようというものです。特に目新しい内容ではないのですが、興味深いエリアでもあるのでちょっと眺めてみます。

A custom DXL framework for accessing Notes/Domino data

DXL(Domino XML)というのは、Domino DTDと呼ばれる、Dominoの構造を記述したフォーマットに従って、Dominoのデータ(文書情報)や設計をXML形式で記述したもののことです。スキーマ言語はDTDを使ってますが、Domino 7からは、XML Schemaも提供されるそうです。
DXL 自体は文書情報などDominoデータをXMLで表現しただけのものですが、開発者のアイディア次第で活用方法はいくらでもあると思います。ここで は、一例として、DIIOPでもプログラムアクセスは出来るけれど通常はFirewall超えが出来ない・・・なんということが書いてあります。(つま り、XMLの利点の一つはテキストフォーマットであることであり、HTTP上で扱える。さらには、HTTPならFirewallが超えられる、という、は やりのWebサービス的な考え方、に行き着く・・・。他にも用途は多いと思うのですが、代表例ならこれということでしょう)

「Viewの データをXMLで取得してプログラム処理させる」というのは、最近ではわりと一般的になってきました。?ReadViewEntriesとい うURLコマンド一発でXMLデータを取得出来るということもあり、Domino開発者側はビューだけ作っておけば、あとはデータを利用する側の開発者 (サーブレットなど)がXML APIを使って頑張ればよいですから。なお、DXLのようにデータ構造が決まっているというのは最低条件として非常に重要だと思いますが、 ReadViewEntriesのように、XML取得のための標準インタフェース(特にHTTPメソッドとして)があるというのも重要だと思います。

この記事では、文書単位でDXLアクセスする場合のフレームワーク(ちょっと大袈裟な言い方ですが)を考えています。
文書単位でのDXLアクセスといえば次が想定されます。
  • 選択文書(UNID)に対するDXLベースの情報更新
  • DXLフォーマットのデータを新規文書として生成する
  • 選択文書(UNID)のDXL情報を表示する

これに対して、DXLUpdateDoc/DXLCreateDoc/DXLViewDocという3つのエージェントをURLコマンドとしてインタフェースにする方法(つまりエージェントのソース)が紹介されています。
こ のエージェントは、Query_StringというCGI変数で引数(UNID)を受け取り、必要な処理を実施しています。Domino 6では、DXLに関するLotusScriptのクラスが実装されたので、これらのエージェントは全部LotusScriptで、しかもかなりシンプルに 実現されています。ソースの詳細は記事本文を見て下さい。

DXLによる文書操作がどの程度必要なのかはわかりませんが、ともあれ文書操作 に関するURLベースでの標準インタフェースを持つということは、SOAや Webサービスなどがキーワードになっている近年、非常に重要だと思います。今回の例ではエージェントで実現していますが、各DBにエージェントを配置 し、リクエストをエージェントで処理するのは、サーバーパフォーマンスも気になりますし、コードの配置の点でも最適かどうか微妙です。この点を追求すれ ば、サーブレットなどを使って他に選択肢が全くないわけではないですが、現状の製品機能ではいずれにせよ一長一短であったりして、今回の記事がやはり最適 解だと思います。ですが、この程度の機能くらい、ReadViewEntriesと同様、Domino URLコマンドとして実装して欲しいと思います。(引数がUNIDだけでよいかどうかには議論があり、GetDocumentByKeyと同じものは欲し いです)

2005/05/02

JavaScript 10のベストプラクティス 2005年度版(3)

今回は、10項目の3番目から見ていきます。最後まで一気にいきます。

3. 便利なJavaScriptを作ろう

Webページの使い勝手とは、 「情報の構造」「明確で直感的なデザイン」「優れた機能」などで判断されます。前述の"unobtrusive JavaScript"手法を使うことで、使い勝手をあげることが出来ます。使い勝手があがらないJavaScriptの使い方なら、考え直したほうがよ いでしょう、とのことです。

4. 簡単に適用可能なJavaScriptを作ろう

デザイナーとプログラマーのギャップと いうのは存在するもので、「XHTMLとCSS」を知っていながら、DOMやJavaScriptの知識がないデザ イナーが存在するケースはよくある話です(これはJ2EEのMVCモデルにも共通しそうですが、JSP処理などのViewの部分だけでもクライアント処理としてさらに2階 層に分かれてしまうということですね。Dominoの場合は一人の開発者が全部やってしまいがちですが。もちろん何でも一人で出来る優秀な開発者になるこ とは重要ですけれど。)。
これも、ロジックの分離をしておき、JavaScript部分を簡単に適用可能にしておくことが重要です。コードもメンテナンス出来ないくらい大量なものになることがよくありますが、極力最小化して、再利用が出来るようなコードにします。

5. 将来性が保証されたJavaScriptを作ろう

ブラウザ情報を検知するロジックではなく、オブジェクトを検知させて、ブラウザをハンドルするロジックが望ましいです(例えばdocument. でエラー発生状況を見るなど)。
XHTMLの利用はJavaScript記述上でいろいろと注意が必要です。まず、ケースセンシティブであり、各要素は小文字で記述される必要がありま す。また、そのほか、document.関連の操作では、各種の注意が必要になるようです。Dominoでは、XHTMLへの適切な対応は先になりそうで すが、いずれDomino技術者の知識としては避けられないものになっていくのでしょう(とはいえ、HTMLとXMLの基本さえ知っていればそれほど難し くはないと思いますが。パススルーHTMLなどでは、既にXHTMLの文法に注意しておいたほうがよさそうですね。)。
最先端の技術情報が必要なら、W3CやECMA、ブラウザベンダからの情報に注意しておくべきです。

6. JavaScriptの弱み、欠点、バグは理解しておきましょう

JavaScriptは、批判を浴びることが多い背景もあり、ほとんどのブラウザでは簡単に機能をオフにすることが出来ますので、注意が必要です。また、ブラウザの中には、メモリリークがあったり、ということもあります。

7. もっとよい選択肢が存在するかもしれません

JavaScriptは柔軟な言語なので、いろいろな形で記述することが出来ます。書き方は1つではないことを理解しておく必要があります。

8. 自分でコードを書くか/信頼出来るサイトからコードを拝借するか

良かれ悪しかれ、最近はいろいろなタイプのコードがインターネット上に存在します。中には古い記述や、お作法の悪いものも存在します。使いまわしをするときは、自力で多少修正することがよいケースが多いでしょう。

9. パフォーマンスチューニングされたコードを書きましょう

ダウンロード速度、実行速度を意識したコードを書きましょう。JavaScriptはローカルにダウンロードされて実行するため、実際に利用しないような 巨大なライブラリは望ましくないです。コメント文も遅くなる原因ですが、手元にはコメントが入ったものを残しておいたほうがよいでしょう。
これは、JavaScriptの塊ともいえるDomino Web Accessなどで、激しくチューニングされているのが見れます。ダウンロード速度については、HTTP1.1のgzip圧縮などもあるので、多少救いは あるかもしれないですね。(ネットワーク屋さんから言わせると、HTTPのトラフィックはかなり無駄が大きいため、gzip圧縮して欲しいそうなのです が)

10. 開発支援ツールを使いましょう

JavaScriptの開発も、JavaScriptコンソールから、文法チェッカーなど、様々なツールが存在するようです。こういったものを使うとよいでしょう。


最後に。(あまり開発が得意でないDomino技術者の独り言)

実は、この10の方法は、Domino関連サイトをネットサーフィン中に見かけて飛びついた記事です。この手の記事は割と読みやすいことが多いのですが、 読み進めてみるとDOM関連の深い技術話が多く、最後はかなり読み飛ばしてしまいました。正直DominoでのJavaScriptといえば、入力チェッ クやWindow操作、イベントハンドルで使われている程度だと思うのですが、最先端なところでは、DHTML的なコードを、いかにクロスブラウザ対応 で、かつ美しく記述出来るか、というところまで進んでいるようです。読み進めていると、とにかくキーワードは"unobtrusive JavaScript"という手法にあるようですが、いずれ時間があるときにじっくりと読んでみたいと思います。

2005/04/30

JavaScript 10のベストプラクティス 2005年度版(2)

(2)と書いていますが、10の項目の中のまだ1つ目の途中からのスタートです。このオリジナル記事は、たくさんの記事へのリンクが多々使われており、そ れらの記事もまた次々と他の記事にリンクされているため、全て追いかけると莫大な量になってしまいます。今回は、(普段あまりJavaScriptを書か ない私にとって)いきなり最新のJavaScript情報を扱うということなので、10項目の上っ面を眺めていくことにし、そのうち機会があれば深く掘り 下げていくことにします。なお、ここで「JavaScript」と言っているのは、むしろ「DHTML/DOM」などにイメージとしては近く、普段ドミノ の技術者が基本的に作るアプリケーションに使われるJavaScriptと比較しても高度な技術です。

前回は、HTML/CSS/JavaScriptのバランスについてを記述しましたが、実際この第1項目のタイトル「JavaScriptをバランスよく 使おう」で意図しているのはまさにこのことで、この後いろいろと続きが書いてありますが、ようは「HTMLでは構造を記述し」「CSSでスタイル、見栄え を定義し」「JavaScriptで動きをコントロールする」ことが重要で、あとはCSSやJavaScriptがクロスブラウザ問題にたいして正しく動 作し、また3要素の曖昧な部分を正しく使えればよいということだと思います。

2. アクセシブルなJavaScriptを使おう

Webアプリケーション(Webサイト)を利用するユーザーの、ブラウザ、もしくはデバイスにかかわらず、きちんとアクセス出来るようなサイトにすること が重要です。これは、いろいろな可能性があり、例えば「スクリーンリーダーのような支援ツール」「マウスのない環境」「JavaScriptが実行出来な い環境」「プログラムやサーチエンジン」などに対して、適切にコンテンツを提供する必要があります。さらに、これを維持した上で、JavaScriptが 実行出来るユーザーに対しては高機能を提供することも重要です。この方法の1つとして、"unobtrusive techniques"とよばれるものがあるそうですが、Dominoのビューのカテゴリ展開などに応用出来そうです。

"Dominoのコネタ"のつもりではじめたのですが、随分偏ってしまいました。ともあれ、最後まで目を通して、またDominoのコネタ巡りに戻ります。

2005/04/26

JavaScript 10のベストプラクティス 2005年度版(1)

Ten good practices for writing JavaScript in 2005

この記事が、Domino開発者(はもちろん、Web開発者)の間ではやっているようです。JavaScriptや、その拡張技術は、Notesクライア ントという非常にリッチなクライアントを持つNotes/Dominoにとって、Web化のための必須項目と言えます。つまり、Notesクライアントが 専用クライアントであり、数々のクライアント能力(スクリプト実行環境など)を備えているために、Web化したときの貧弱なUIが問題になることが多いの ですが、その差を埋めてくれるのがJavaScriptだからです。現に、普通にコーディングするだけでは不可能とも思える、Domino Web Access(DWA)などは、こういったScript技術のまさに集大成ともいえます。

一言にJavaScriptといっても、その幅は広く、例年進化し続けています。「10のベストプラクティス」というタイトルは非常によくあるもので、実 は当たり前のことが書かれていることが多いのですが、この記事はさすがに「2005年」と入るだけあって、技術的にも普段Web UI技術をやっていないとなかなか厳しい、深い情報のようです。そこで、ちょっと背伸びしながら、Domino技術者の視点から、この記事を少しずつ時間 をかけて勉強してみたいと思います。

1. JavaScriptをバランスよく使おう
Web技術は、3本足といわれています。
  1. コンテンツの構造と意味を表現する(X)HTML
  2. プレゼンテーションを担当するCSS
  3. 動きを担当するDOM
HTMLは、パススルーHTMLを使って、記述することが多いですね。CSSについては使う人ぞ使う、というところでしょうか。
最後のDOMとは、Document Object Model(よくUSの人が嬉しそうに「Domino Object Model(Dominoのクラス階層)じゃないと言ったりしますが)の意味です。文書をツリー構造で解釈して、プログラミングアクセスさせるための APIといった意味でしょうか。ある一方向に拡大解釈すればJavaScriptと言ってもいいと思います。
この3つの要素「構造」「表示」「動作」を完全に分離させることが、最も重要である、との主張です。

まだまだこの第1項目だけで先は長いのですが、まずはここまで休憩にします。

2005/04/21

驚きのR4.6.2

Notes/Domino 6/6.5もだいぶ浸透したとはいえ、まだまだR4でご利用のドメインは多いのも事実だと思います。
ところが、Ed Brill氏のブログにて公開されていた、この記事は強烈。
http://www.edbrill.com/ebrill/edbrill.nsf/dx/a-surprising-domino-4.6.2-website

本当にどうでもよい話ではありますが、MBS(Microsoft Business Solutions)のサイトがドミノR4.6.2が使われていたという話です。微笑ましいです。

そういえば、昔は、ソースやHTTPヘッダで、サーバーのリリースがわかったんですよね。いつから変わったんだろうかと、調べてみたくなります。
Domino HTTP サーバーが返す Web 応答の変更について

なるほど、ヘッダはDomino 6からセキュアに、ソースはR5でいろいろと変化があったのですね。

2005/04/19

Dominoとブログ

LDDの日本語版に、「Domino によるブログ: ブログとブログ作成」という面白い記事がのっていました。
http://www-6.ibm.com/jp/software/lotus/developer/library/blogging.html

これは、もともとは、英語版の記事の翻訳になります。
http://www-128.ibm.com/developerworks/lotus/library/blogging/

もともと、Dominoはコラボレーションに強いソフトウェアという位置づけですし、ブログのようなものは本来得意であるべきと期待しますが、ビジネスア プリケーションであるDominoサーバーに対し、日本では「個人的な日記」という位置づけが強いブログなので、なかなか実際には国内では「Domino でブログ」ということはおきないのでしょう。とはいえ、我々Dominoを普段から扱っている人からすると、興味深い分野です。

この記事によれば、現在Dominoの世界では、有名なブログテンプレートが3種類ほど存在するようです。DominoでBlogをする最大のメリット は、きちんとしたテンプレートさえあれば、ブログサイトを作成するのが非常に容易であることでしょう。また、Notesクライアントから記事の入力が出来 れば、オフライン環境との親和性もよいと思います(もちろん、DOLSというアイディアがないわけではないですが)。

アプリケーションサーバーとしてのDominoサーバーのメリットは、直感的には微妙な気がします。1文書1ブログ記事であった場合、よくあるBlog標 準の画面が埋め込みビューのカスタマイズだけでどれだけ表現出来るかは微妙ですし、サーブレット的な使い方(HTMLソースをプログラムで動的に作る)を することは、(パフォーマンスの悪い)エージェントを使うのはもちろんのこと、Dominoサーブレットを使っても、あまりDomino向きとは言えない 気が直感的にはします。これは、私も既存のDominoブログテンプレートの設計を読んで勉強する必要があります。

記事の中では、ビジネス用途におけるDominoブログについてが記述されています。これはいろいろなアイディアがあると思います。営業日報的に使うのも よいでしょうし、純粋に掲示板の置き換えも可能だと思います。その他、「部門ブログ」のようなものも考えられるし、このようなビジネスユースとなった場 合、現行でDominoサーバーがあるならば、活躍の場は大きいと思います。

この記事では、抽象的な話と、いくつかのリンクだけですが、このトピックは、「アプリケーションサーバーとしてのDominoの可能性」はもちろんのこと、「ビジネス向けにどのような使い方が考えられるか」など、奥の深いテーマだと思います。

2005/04/11

TeamStudio

海外のDomino関連Blogを読んでいると、TeamStudioがいかに人気があるかということがわかります。特に、最近リリースされた、TeamStudio Script Browserは、フリーで利用可能ということで、いろいろなDomino関連Blogサイトで絶賛されている姿を見かけます。

最近、一番面白かったのは、この記事です。
http://www.chadsmiley.com/chadsmiley/home.nsf/d6plinks/One_Teamstudio_Icon_1_1

TeamStudioは、既に9のアイコンがあり、上記のフリーツールを入れると10になって、もうどのアイコンだかわからない。という背景で、1つのアイコンに統合するためのコードを書いた人がいるようです。

私自身は、普段はあまり開発しないので、ConfiguratorとAnalyzerくらいしか使いませんが、こういう記事を読むと、いかにDominoコミュニティーで愛されているか、というのがよくわかります。
Configuratorがあると、ちょっとアプリケーションロジックが気になる場合、UIに表示されているメッセージを検索キーワードにして、設計要素が検索出来るので、非常に便利です。Sandboxなどで拾ったアプリケーションの設計が気になる場合などで、重宝しています。

2005/04/07

トラブルシューティング アプリケーションパフォーマンス

developerWorksの記事で、アプリケーションパフォーマンスの話が書いてありました。このトピックも、何回も繰り返されるトピックで、永遠のテーマでもあるのでしょう。
http://www-128.ibm.com/developerworks/lotus/library/app-troubleshooting1/
いったい、どのようなことが書いてあるか気になるので、少し読んでみました。

まず、最初のパフォーマンストラブル解決のアプローチとしては、次の3つがあるようです。
  1. 問題は、どこにあるのか
    Dominoアプリ、サーバー、ネットワーク、どこに問題があるかを特定させます。1つのアプリだけなのかどうか。また、他のサーバーではどうか。ユーザーのロケーションによって違うか。時間帯は。問題発生のユーザーのクライアントに特徴はあるか。クライアントのOSは。
  2. 問題は、どこにあるのか
    現象が発生するアプリケーションの範囲や、ユーザー操作をしぼります。DBを開くときか、ビューを開くときか、ビューのスクロールか、特定のビューか、全てのビューか、文書の閲覧/保存時か、どんなアクションのときか、特定ボタンを押したときか
  3. 変更はあったか
    以前からそうだったか。ユーザーやデータが増えたときからか。新機能追加のタイミングからか。ソフトウェア/ハードウェアのアップデートからか。
これは、確かに、書いてある通りだと思います。少しでも経験があれば、誰もがこのアプローチをとると思います。

次に、こうして集めた情報をもとに、悪いと考えられる場所を特定し、その部分をアプリケーションの観点から見直します。これも、当然といえるでしょう。

次はデータの収集です。データが集まれば真の問題点が明確になってきます。
収集すべき箇所は、問題にょって違いますが、通常は notes.ini などをベースにした、詳細なログの収集を行います。例えばビューに問題がありそうなら、log_update=1を使います。

最後に、集めたデータを解析して、問題点の箇所がそこにあったかどうかを判別します。
基本的には、このサイクルに従って、問題点を見極め、そこのチューニング、改善をするということですが、これもまあ、その通りだと思います。

実際のトラブルシューティングでは、アプリのパフォーマンス問題は、経験的に以下の3種類に分類されることが多いそうです。
  • フォームのデザイン
  • エージェント
  • ビュー索引
私の数少ない経験からいっても、これらはあてはまると思います。

ここからは、ここで紹介されている、トラブルシューティングの実例です。
この例では、日中の多くの間、アプリが遅いという問題が発生していたそうです。話を聞いてみると、ビューの操作が遅いということで、ビュー索引のところから問題追求がはじまりました。
log_update =1を使ってみたところ、1つのビューの更新サイクルが30分以上だったようです。DominoのUpdateタスクはデフォルトで 15分単位で動きます。文書更新が全くない場合は動かないため、30分以上間隔があくこともありますが、ビュー索引の更新に非常に時間がかかって、15分サイクルが遅延し ているという可能性もあります。今回の、トラブル対応チームは、まずここに目をつけたようです。
15分サイクルの遅延において、DBやビューの数が多すぎて更新が本当に間に合わない、というこ ともありますので、特定のビューが悪いのかを見極める必要があります。今回はlog_update=2を使って個々のビューのログ状況を確認することにしま した。このケースでは、少数のビューの索引更新に非常に時間がかかっていることが判明し、ビューはアクセス時に「再作成」されるように記述されていること がわかりました(つまり選択式、列式に@Today/@Nowが入っていたのです)。
こうして、ビューのロジックを変更し、問題は無事におさまりました。問題判明に要したのは5日ほどで、あとは10-20日でロジック変更、テストをして解決したようです。

いかにも、というかんじで、、、ビューの@Todayが問題なら、もう少しすぐにわかってもよいのではないでしょうか、、、とも、思いますが、ともあれ、事例だそうです。

問題となるコードとしては、経験的に以下のことが多いそうです。
  • 時間依存なビュー
    @Now/@Today などが選択式、列式に入ったものは、「再構築」されるので時間がかかります。(なお、Domino6のUpdateタスクは賢いこ とに、このビュー再構築をスキップするため、実際にはユーザーアクセスがトリガーになったものだけ再構築するようです。)
    ビューには更新オプションがあるため、これの調整などを組み合わせれば、実用も不可能ではないそうです。
  • クリック可能な列のソート
    こ れらの列が増えてしまうと、結果的にはビューのインデックスが非常に大きくなり(列のソートをするということは、オリジナルのビュー相当なものを、もう1 つ作成するというイメージであり、例えばもともと10Mのビューに、4つのソート可能列を加えると、インデックスは50M程度になってしまう)、当然更新 にも時間がかかる、ということです。
  • ドキュメントコレクション
    文書をつかんで、中身を取り出す場合、ビューに表示されているデータであるならば、ViewEntry関連のクラスを使ったほうが速いです。
    また、GetNextDocumentを使うときは(よく使いますよね)、「view.AutoUpdate = False」を使うのがよいようです。特にパフォーマンスの観点から。
いろいろなテクニックが紹介されていますが、今回は主にビュー特集というかんじです。Dominoの経験が長い方はご存知なテクニックが多いと思いますが、改めて見直すよい機会でもあったと思います。お行儀のよいアプリを作って、快適なDominoライフを。

2005/04/04

DWA LightUI/パフォーマンス

developerWorksの記事を読んでいたら、DWA(Domino Web Access)の軽量UI(Lightweight UserInterface)の記事を見つけてしまいました。面白かったので、ちょっとご紹介します。
http://www-128.ibm.com/developerworks/lotus/library/dwa-clientperf/

6.5.4 から、もしくは、6.5.3にhotfixを適用することで、DWAクライアントのパフォーマンスが高速になる、というのが記事の内容です。何 でもクライアントレスポンスタイムが、30-40%はやくなるそうです(こういう数値はまともに信じてはいけないわけですが、最もパフォーマンスが影響し やすい、低スペックのPCでテストすると、ベスト時にはこうなるそうです)。

DWAはどのように動くか
  • DWAのメールテンプレート(inotes6.ntf)ベースのDBに、データを蓄積
  • Forms6.nsfという、共通のロジックやフォーム(HTMLやJavaScript)を使ってクライアントに表示させる、全員共通のDB
  • さらにHTTPタスク自身にも機能を持たせている
HTTPリクエストに対して、適切なフォームがロードされ、ユーザーのメールDBデータを使って、HTTPレスポンスが作成されます。レスポンス自体は複 雑で、このレスポンスには、関係するデータやスクリプト、スタイルシートなどとセットとなり、ブラウザが頑張って表示する、という仕組みだそうです。

ということから、DWAのパフォーマンスは以下の影響を受けます。
  • クライアントハードウェアスペック
  • ネットワーク転送時間
  • Webサーバーのリクエスト生成時間
  • ブラウザ側の処理時間
まあ、確かにそりゃそうだろうと思います。ちなみに、推奨は、IE6.0かMozillaを、Pentium IV 1GHz の、512Mメモリマシンだそうですが、私の感覚的にも、そんなところが妥当でないかと思います。
DWAの場合、多くのJavaScriptをクライアント上で実行させるので(しかも、XMLデータの加工表示などを行うので)、クライアントスペック、いかにも大事そうです。

パフォーマンステストについて
  • DWA LightUIを使う限り、ネットワーク圧縮はレスポンスタイムにほとんど影響がない
  • テスト結果をみたかんじ、確かにhotfix/lightUIは軽そうです。MozillaよりはIEがよさそう
  • DWA StandardUIでは、ネットワーク圧縮は、細い回線においてレスポンスタイムに効果がありそう(速い回線だと、解凍処理のオーバーヘッドで微妙なところ?)
パフォーマンスアップについて
  • Webサイトルール文書を使って、アイコン情報を使いまわさせる
  • GZIP圧縮は、高速マシンには有効、低速マシンには逆効果なので、マシンをみて様子を考える。(なお、ブラウザ単位でオフにすることも、ブラウザの設定で可能)
  • ブラウザのキャッシュ管理
  • Light UI(なぜ軽いか、というと、GIFイメージやグラディエーションを極力減らしているそうです。iNotes_WA_UI=inotes_liteというnotes.iniを使うそうです。)
  • 子ウインドウの使いまわし(これも新機能で、やはり、notes.iniにてiNotes_WA_ReuseChildWindows=1とするそうです)
  • ドラッグ&ドロップ使用不可オプション(DWAカレンダーディスプレイオプション)
  • カレンダーのサマライズビューの利用
  • ブラウザの設定(スムーズスクロールの使用不可など...)
  • サードパーティ製のアクセラレータ(ネットワーク圧縮、SSLなど、だそうです)
ということで、わりと6.5.4はパフォーマンスが期待出来るのかも、という記事でした。LightUIと話をきくと、PortalUIやら通常のWeb メールに加え、UIの数が増えるぶんだけ、現場のノーツ屋さんは大変になるかと思いましたが、どうも、みためがちょっぴり変わるくらい? 確かに、この記 事を読むだけだと、「無意味にリッチ」な部分を落としたようにもみえる、「チューニングの1つ」ともいえる程度の変更でもあるようなので、期待したいとこ ろです。

2005/03/29

ページ開設

最近はやりのトピックとして、「ブログ」というキーワードがあがっています。日本では、皆さん、日記の延長で記述されることが多いようで、IT業界関連を トピックとしたブログも見かけはするものの、サーチエンジン関連やMozilla関連などで、なかなかDomino関連の情報が見当たりません。
一方、USでは、有名なEd Brill氏のブログや、 そこにリンクされている数々のブログサイトを見ていると、相当な数のDomino関連技術者が、日々何かをつづっているみたいです。USでは、優秀な技術者の多く が、自身で独立していたりするので、書きやすいのかもしれませんが、日本でも少しでも多く、何か情報があれば、と、続かないかもしれませんが、日々、 Domino関連のお仕事の中から、ふと思うトピックなどを、書いてみようかと思い、サイトを作ってみました。
当面の目標は、週に1トピック、数行でも投稿する、のんびりペースの予定です。