Teamstudio Snapper は、開発者の作業中にアプリケーション全体または個別の設計要素への変更を暗黙のうちに記録する自動アンドゥ機能によって、Lotus Notes 開発者の時間を節約しフラストレーションを減らします。開発者は、以前に保存した任意のコピーにいつでも速やかにロールバックできるという確信のもとで安心して作業を進めることができます。 詳しくは、データシート、ソリューション・ブリーフ、ベストプラクティスのヒントを参照してください。
Teamstudio Snapper の自動アンドゥ機能について詳しく書かれたデータシートのダウンロード
ソリューション・ブリーフ：定型開発業務の自動化
IBM Lotus Notes/Domino ソフトウェア開発環境における人為的ミスの回避
IT 予算が標準準拠の問題に投資されていると、ソフトウェア開発組織は既存リソースを最大限に活用せざるをえません。しかし、IBM Lotus Notes/Domino 開発者は、コードを解読したり同じような新しいコードを作成したりするためにかなりの時間を費やしています。また、これらを手作業で行うので、エラーが発生しがちです。Teamstudio ツールを使ってこのような定型業務の多くを自動化すれば、Notes 開発者は、生産性とコードの品質とを向上し、もっと重要なプロジェクトに時間を割けるようになります。
ベストプラクティスのヒント
Teamstudio Snapper を使った開発ベストプラクティス
ベストプラクティスを採用している Lotus 開発者は、時間を費やして、変更前にフォームやビューなどのコピーを作成します。こうしておけば、何かがうまく行かなかったときに旧バージョンに戻すことができます。 これは申し分なく正当な作業方法なのですが、理想的とはいえません。時間のかかる手作業による処理であり、多くのビューやフォームを同時に扱っている場合には混乱を招きがちです。 開発者は新バージョンのアプリケーションをデプロイする前に忘れずにコピーをすべて削除しなければなりませんし、複数の開発者が同じデータベースに取り組んでいる場合には、混乱の度合いは収拾がつかなくなります。
Teamstudio Snapper は、Lotus Notes 開発者にとって、動的でカスタマイズ可能なセーフティネットとなります。Snapper を使っていれば、いつでもデータベースの以前の「スナップショット」に戻ることができ、要素をコピーする必要がなくなります。
Snapper では、変更を追跡する周期的スナップショットの信頼性および安全性と、データベース全体のスナップショットを取る手動スナップショットの柔軟性が組み合わさっています。 少し時間をかけて自動および手動スナップショットのベストプラクティスを守れば、安心と最適なシステム・パフォーマンスという成果を上げることができます。
Teamstudio は、Snapper の設定時に次のベストプラクティスを守るよう推奨しています。
- バッファレベルを適度なスナップショット数に設定してください。バッファレベルには任意の数を設定することができますが、あまり大きな数にするとパフォーマンスが落ちる可能性があり、どうしても必要でなければ無制限のスナップショット（バッファレベルのフィールドにゼロを指定）は避けるべきです。
- スナップショット間隔を日または時間単位に設定します。半時間の作業さえ失いたくないのなら 30 分にしてください。自動スナップショットは前回のスナップショットからの変更を追跡するだけなので、頻繁に大きな変更を行うのでなければ、大きなサイズにはなりません。
- Snapper Server を使っていて、サーバー上でスナップショットが大きなスペースを占めるのが気になるのであれば、例えば 90 日を過ぎたスナップショットは削除するエージェントなどを設定してください。
Teamstudio Snapper は時間を節約できる分かりやすいツールであり、CIAO! と組み合わせて使えば、面倒なプラクティスを洗練された効果的なソリューションに置き換えて、Lotus Notes 開発者の頭痛の種の多くを解消することができます。
Teamstudio Snapper を使って文書を監視する
Snapper を使って文書を監視すると、構成設定に対して行った変更をすべてバックアップすることができて便利です。開発環境における文書の典型的な用途は、構成設定などや、場合によっては共通の Web ページを保存するためです。ただし、これらは文書であるため、デフォルトでは Snapper による監視は行われません。監視を行うには、データベースの設定を編集する時に［文書を含める］を選択してください。
さらに、文書に［$TMSTitle] というフィールドを含める必要があります。 通常これはテキストの計算結果フィールドで、ほとんどのビューで使われているフィールドと同じデータを含むよう設定されます。
計算結果フィールドを追加した後、データベース内の全文書を更新するエージェントを実行してください。@Command( [ToolsRefreshAllDocs] ) のようなコマンドで十分です。このエージェントを使って文書に対して変更を行うと、設計要素の場合と同じように、Snapper が変更前のコピーを Snapper ログに保存します。
Teamstudio Snapper の設定文書でワイルドカードを使用する
Teamstudio Snapper のアンドゥ機能をデータベースごとに設定しなくて済むなら楽だと思いませんか。作成または作業したテンプレートに自動的に Snapper のアンドゥバッファが作られて、失敗した設計変更以前のバックアップを取ってくれたら、便利ではないでしょうか。
新規開発で、特に多くのデータベースを作成するような場合には注意が必要です。Snapper のアンドゥのあまり知られていないある機能を使えば、すでに Snapper の監視下に置いている既存データベースの保守と同じように、心配せずに新規開発ができるようになります。これにはデータベースパスにアスタリスクを含めるだけで結構です。これでパターンに一致するデータベースは 一括してSnapper のアンドゥバッファで監視されることになります。
たとえば、サーバーの開発用ディレクトリ内のすべてのテンプレートとデータベースを必ず監視する必要があるとします。この場合、"Development\*" というパスを指定するだけで結構です。開発用ディレクトリ内のどのデータベースに対して行った変更もすべて、アンドゥバッファにキャプチャされます。また、"Development\*.ntf" とすれば、テンプレート・ファイルはすべて監視されてもデータベースは監視されないように Snapper を設定することができます。ファイル名が "dev_" で始まる、開発用ディレクトリ内のすべての NSF ファイルを指定したい場合は、"Development\dev_*.nsf" としてください。この機能を使うだけで、どんな変更も Snapper のアンドゥバッファに見逃されずに済みます。
