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つ」ともいえる程度の変更でもあるようなので、期待したいとこ ろです。