長年にわたり数百の教会と協力してきた経験から、最高の体験を実現するための「Rock」の構築・維持方法について、多くの知見を得ることができました。当社には膨大な量の研修資料やノウハウがありますが、私たちの目標は、Rockコミュニティの皆さんに、最も頻繁に必要とされ、役立つ知見を共有することです。私たちは、成功を分かち合うことこそが真の成功であると認識しており、ベストプラクティスを自由に共有することで、私たち全員が#BetterTogetherになれると確信しています。
このマニュアルは随時更新されるものであり、私たちのチームが学び、成長し続けるにつれて、内容も変化していきます。ぜひ時々確認していただき、当社のウェブサイトにある「リソース」ページをフォローして、最新のトレーニング動画や便利なRockツールなどをご活用ください。
ロックに関するヒントトップ10
Rockを最大限に活用するための重要なヒントはたくさんあります。詳細に入る前に、まず覚えておきたい「トップ10の概念」をご紹介します。
- デジタル戦略が、経営陣の期待と投資目標と整合していることを確認してください。Rockは、デジタル戦略の原動力です。Rockに十分なリソースが確保されていることを確認することが重要です。
- 「Rock」を中核となるデータウェアハウスとして活用しましょう。データが分散することなく一元管理されるよう拡張することで、一人ひとりに合わせた牧会活動の可能性を最大限に引き出しましょう。
- すべてを文書化しましょう。まずはワークフロー、レポート、データビューから始めましょう。複雑なプロセスも忘れずに。
- システムの複雑さは増しています。問題の発生を防ぐため、パフォーマンス、セキュリティ、および設定を定期的に見直すことに注力してください。
- コアファイルのソースを変更しないでください。バグの修正、機能の追加、アイデアの共有などが必要な場合は 、コア開発チームにリクエスト を行ってください。
- 変更は、サーバーのファイルシステム上で承認済みのディレクトリに限定してください。変更を行ってよいフォルダは、「Content」と「Themes」（ただし、ご自身のテーマのみ）のみです。
- キャッシュはパフォーマンスの鍵となります。Rockにおけるキャッシュの仕組みについて理解を深めるには、以下の動画をご覧ください：
- Rock 内のキャッシュ
- キャッシュの重要性
- JavaScript を使用してコアブロックや機能の DOM を変更したり、CSS を使用してコアブロックのコンテンツを非表示にしたり移動させたりしないでください。
- SQL や Lava内でビジネスロジックをハードコーディングしないようにしてください。
- ワークフローは「筋肉」であって、「骨」ではありません。あまり複雑にしすぎないようにしましょう。
インフラ
サーバーは、Rockの利用体験を支える基盤です。サーバーが正常に稼働し、十分なリソースが確保されていることを確認することは、システムのパフォーマンスに大きな差をもたらし、予期される事態にも予期せぬ事態にも対応できるよう備える上で役立ちます。
初期インストール
Rock環境をホストする方法にはさまざまな選択肢がありますが、コミュニティではクラウドホスティングにはMicrosoft Azureが、場合によってはオンプレミスサーバーが利用される傾向にあります。これらに関する基本的なガイドはコミュニティ内で確認できます。また、当チームではインフラストラクチャのセットアップと保守に関する追加のベストプラクティスをまとめました。その概要は以下に示します。
これまでの経験上、組織はRockサーバーのリソースを過小に割り当てがちです。これは、教会のデジタル戦略全体を支えるエンジンであることを忘れないでください。スポーツカーに芝刈り機のエンジンを搭載したりはしないでしょう。ですから、ミニストリーを拡大するために必要なリソースをRockサーバーに十分に確保し、リソース不足に陥らせないようにしてください。
サーバーの設定を行う際
初期設定次第で、日常的な運用時だけでなく、利用がピークに達する時間帯においても、インフラのパフォーマンスに大きな差が生じる可能性があります。
- 本番環境とサンドボックス環境を分離してください。両方の環境に1台のサーバー（またはVM）を使用するのは魅力的に思えるかもしれませんが、その代償として、経済的なメリットはほとんどないにもかかわらずリスクが高まります。これらを別々のサーバーに配置することは、本番運用に影響を及ぼす可能性のある問題を回避するためのセキュリティ対策となります。
- 複数のドメインに対して IIS バインディングを使用することは避けてください。Rock インスタンスの IIS（Internet Information Services）バインディングを設定する際は、前述の通り、各インスタンスに専用の仮想マシン（VM）を割り当てることをお勧めします。 また、各インスタンスのバインディングは、HTTP（ポート 80）用と HTTPS（ポート 443）用の 2 つだけに限定してください。こうすることで、別のドメインを持つ新しいサイトを追加する場合でも、Rock がトラフィックを処理し、設定に基づいて適切なサイトを表示するため、IIS の再設定を行う必要がなくなります。追加のバインディングは不要であり、トラブルの原因となります。
- WebサーバーとSQLサーバーの両方について、定期的なバックアップを設定してシステムを保護してください。これにより、データが失われたりシステムに問題が発生したりした場合でも、迅速に以前の状態に戻すことができます。バックアップの設定を検討する際は、短期的および長期的な復旧ニーズを念頭に置いておくようにしてください。
- 以下の追加の IIS 設定についても検討してください。
- 圧縮を有効にする：サーバーに圧縮モジュールをインストールし、IIS内で圧縮を有効にします。Rockサーバーからのコンテンツを圧縮することは、応答を高速化するために重要です。
- WebSocketプロトコルを有効にする（Microsoft Azure SignalRサービスを通じて利用可能）：Rockのリアルタイムエンジンは、WebSocketプロトコルを使用することで最適なパフォーマンスを発揮し、サーバーからリアルタイムの情報を受信できるようになります。これを有効にしない場合、更新情報を受け取るためにサーバーに対して繰り返しpingを送信することになり、効率が大幅に低下します。
リソースの監視
パーティーでのサプライズは楽しいものですが、重要な建築物に関してはそうはいきません。
- 言うまでもありませんが、IISのログを定期的に確認し、経時的な傾向を把握することで、リソース要件が増加しているのか、あるいは対処すべきパフォーマンス上の問題が発生しているのかを把握するようにしてください。IISのログは、少なくとも2か月に1回は確認することをお勧めします。Rockサーバーのトラフィックについて、思いがけない発見があるはずです。
- また、仮想マシンとSQLデータベースを定期的に更新し、SQL Serverの互換性レベルをアップグレードして、最新の機能改善に対応するようにしてください。
- 予防的な監視とアラート設定を行ってください。何か問題が発生した際は、牧師から報告を受けるよりも、アラートで通知される方が望ましいでしょう。優れた選択肢として、「Better Stack Uptime」をお勧めします。コミュニティ内の他のメンバーも、「Pingdom」や「Status Cake」をうまく活用しています。
- v16の新機能として、Rockには「Observability」という画期的な新機能が追加されました。これにより、詳細なタイミング情報やメトリクスをNewRelicなどの監視プラットフォームに送信できるようになります。こうしたデータを利用できることは、最適化されたデジタルプラットフォームを運用する上で極めて重要です。
基本を超えて
基本をマスターしたら、これらの分野が自分にどのように当てはまるか考えてみてください。
- スマートなスケーリング戦略：システムの拡張にあたっては、連携して動作する必要があるサーバーを追加する（スケールアウト）よりも、1台のサーバーにリソースを追加する（スケールアップ）ほうが望ましいです。これにより、構成が簡素化され、管理しやすくなります。
- バッチ処理によるAPIリクエストの最適化：サービスの統合にRockのREST APIを使用している場合は、APIリクエストをまとめて（バッチ処理）実行するか、カスタムエンドポイントを使用して、APIの過度な使用を避けるようにしてください。これにより、複数のリクエストを1つにまとめることで、余分な作業を削減し、全体的なパフォーマンスを向上させ、システムの効率を高めることができます。
- コンテンツ配信ネットワーク（CDN）の利用を検討してください：今日のデジタル環境において、CDNはほぼ必須と言えます。サーバーのトラフィック量が多い場合は、コンテンツ配信ネットワーク（CDN） の利用を検討してください。CDNは 、ウェブサイトのコンテンツを世界中のさまざまなサーバーに分散させることで、訪問者にとっての読み込み速度を向上させ、遅延を軽減します。Rock上で外部ウェブサイトやモバイルアプリケーションを運用している場合は、CDNが特に重要になります。
設定
Rock は非常に拡張性が高く、幅広い設定オプションや組み合わせが可能です。Rock では、目的を達成するための「正しい方法」が通常複数存在しますが、その一方で「間違った方法」も数多く存在します。
目の前の問題を単に解決するだけでなく、将来的な保守性も考慮してください。そうすることで、不安定になりがちな「砂上の楼閣」のような構造を避けることができます。可能な限りコア製品を活用し、必要に応じて資金提供されたRockコアのアップデートを依頼したり、アイデアボードに提案を投稿してコミュニティからの支持を集めたりしましょう。これは、コアブロックをコピーして変更を加えること（これは推奨されません）に比べ、長期的にははるかに安全な選択肢です。
データの状態は、Rockインスタンスのパフォーマンスにも影響を与える可能性があります。データができる限りクリーンで正確な状態を保つよう、付属のデータ整合性設定やレポートを必ず活用してください。
Rockを自分のニーズに合わせてカスタマイズする際は、以下の設定に関するベストプラクティスを念頭に置いてください。
概要
大まかに言えば、Rockの設定に取り組む際には、考慮すべきテーマがいくつかあります。
Rockを拡張したり、Rockを基盤として開発したりするために利用できるツールや技術は数え切れないほどあります。できる限り、コミュニティと同じツールを使用するようにしてください。そうすることで、次のような多くのメリットが得られます：
- これにより、組織が長期的にサポートしやすくなります。他のコミュニティメンバーもそれを認識し、パートナーもその内容を熟知することになります。
- 他の人とより簡単に情報を共有できるようになり、コミュニティ全体の発展につながります。
- 参考資料として、他にもさまざまなリソースが用意されています。
クリーンなインスタンスが鍵となる
比較すると些細なことのように思えるかもしれませんが、Rockのインストール環境をクリーンで整理整頓された状態に保つことは、実際の作業スペースをきれいに保つことと同じです。特に、多くのスタッフと共有している環境であるため、これは非常に役立ちます。
- アイコンを一貫して使用することで、各選択肢を素早く見分けられるようにします。
- ホームページ上のSparklink通知を削除し、通知が溢れかえるのを防ぎましょう。
説明文は必須とする
説明欄を見つけたら、それを必須項目だと考えてください。ワークフロー、データビュー、ヘルパーテキストなど、どのようなものであれ、その項目が存在する理由や用途に関する背景情報や説明を提供しておくことは、将来的に非常に役立つでしょう。
特定のフィールドタイプに関するヒント
- 単一選択または複数選択のフィールドタイプを作成する際は、各値にキーを指定してください。これにより、後で名前を変更しても、データが失われたように見えることを防げます。たとえば、選択肢を次のように列挙する代わりに、
リンゴ、レモン、サクランボ, 代わりに次のようにリストアップしてください。 1^リンゴ、2^レモン、3^サクランボ. - 他のすべての解決策を尽くし、どうしても必要である場合を除き、マトリックス属性の使用は避けてください。これらのフィールドは強力ですが、効率が低く、レポート作成ツールも利用できず、値を取得するには多大な労力がかかります。
グループ
グループ型において、親子-親子-親といった無限ループが生じないよう注意してください（親グループ型が子グループ型の子として設定されてしまう場合）。特にチェックイン設定において、このような現象が発生することが確認されています。
原則として、グループタイプの変更は避けるべきです。やむを得ない場合は、以下の点に特に留意する必要があります。
- 対象のグループが「グループ同期」を使用していないことを確認してください。グループ同期が設定されている場合は、変更を行う前にそれを削除し、グループの種類を変更した後に再度追加する必要があります。これにより、グループメンバーの不一致による例外が発生するのを防ぐことができます。
- 「グループメンバー」テーブルと「グループメンバー履歴」テーブルの両方で、グループメンバーのロール ID が更新されていることを確認してください。
- グループタイプに追加された属性については、適切な処理を行ってください。これらの属性は新しいグループタイプには存在しません。そのため、それらの値を新しい属性に移行するか、あるいは不要になった場合はまず削除する必要があります。
セキュリティ
- ファイルの種類によってはセキュリティ設定が適用される場合があります。機密性の高いファイルの種類には適切なセキュリティ設定が適用されていることを確認するとともに、Rockを経由せずにファイルにアクセスできるようなURLが含まれていないことを確認してください（例えば、セキュリティ保護されたファイルをFileSystemに保存しないなど）。
- 1人のユーザーが複数のセキュリティロールに所属することがあります。そのため、カスタムセキュリティロールは、関連する少数のページ、ブロック、またはプロセスへのアクセスを許可または拒否するように、対象を絞り込んで設定するようにしてください。あるユーザーに複数のロールが必要な場合は、該当する両方のセキュリティロールにそのユーザーを追加してください。また、将来、スタッフやボランティアの採用や離職の際にも理解しやすいよう、セキュリティロールを適切に文書化し、管理してください。
- 新しいセキュリティロールを作成する際は、まず、目的のユースケースに最も近いセキュリティロールを選択してください。新しいセキュリティロールでは、既存のセキュリティロールを基盤として、追加のロールを許可または拒否するように設定します。その後、これらのセキュリティロールの「両方」にユーザーを追加することで、新しいロールが既存のロールの上に「重ねられる」ようにします。
- ページやブロックレベルでセキュリティ設定を編集する際は、可能な限り、特定の個人を追加するのではなく、セキュリティロールを使用してください。
求人
- 通常よりも実行に時間がかかっているジョブは無視しないでください。少なくとも、ジョブの完了までに時間がかかりすぎて、次の実行開始時刻までに終了しないような事態は避けるようにしてください（Rockでは同じジョブの複数のインスタンスが同時に実行されることはありませんが）。ジョブの完了に数時間もかかるようなことはあってはなりません。
- 少なくとも週に1回は職務履歴を確認し、問題が発生している案件がないか確認してください。
金融
- Rockのバッチは、基帳となる会計システムのバッチと照合されることを前提としています。毎月、帳簿の照合と決算が行われる際、対応するRockのバッチも決算処理を行う必要があります。Rock内で未決算のバッチは、まだ照合が完了していない月の取引に関連するものに限られるべきです。
データビューとレポート
- データビューの永続化について検討してください。すべてのデータビューを永続化する必要はありませんが、この問題には賢明に取り組み、慎重に検討した上で永続化の頻度を設定するようにしてください。永続化を行うことで、データビューの読み込みが高速化され、パフォーマンスが向上します。ただし、レポートや積み重ねデータビューを表示している場合、各データビューの永続化設定が、表示されるデータの更新頻度に影響を与えることを忘れないでください。永続化は推奨される手法であり、各ユースケースに合わせて適切に調整する必要があります。
- 基本的なデータビューの再利用は推奨されますが、可能な限り、類似したフィルターを使用するデータビューを複数階層にわたりネストさせることは避けてください。これにより、パフォーマンスの問題が発生する可能性があります。特に、多くのスタッフがデータビューやレポートを作成している場合は、レポート作成の戦略を定期的に見直し、重複したり重複したりするデータビューを整理する必要があります。
- レポートを作成する際は、エンティティコマンドを使用したり、他の関連エンティティ型からプロパティを取得したりするカスタムLava列の作成は避けてください。これらは、特にデータセットの規模が大きいレポートにおいて、すぐにパフォーマンスに影響を与える可能性があります。
画像およびファイルの保存
Rock を使用する際、画像やドキュメントなどのファイルをアップロードする機会は頻繁にあります。ファイルの保存場所を不適切な場所に設定してしまうと、Rock のパフォーマンスやストレージ容量、さらにはファイルのセキュリティに深刻な影響を及ぼす可能性があります。それぞれの状況に最適なオプションを、早い段階で決めておくことが重要です。
いずれにせよ、スタッフへの教育を徹底し、画像のサイズを小さく保つための対策を常に講じる必要があります。幅20,000ピクセルの画像は印刷媒体には最適ですが、ウェブ上では不要であり、ページの読み込みを遅くしてしまいます。2.5MBを超えるファイルは、使用を制限するか、あるいは使用を控えることをお勧めします。
バイナリファイル
Rock のファイルのほとんどはバイナリファイルとして保存されており、次のような Rock のファイルハンドラを使用して取得されます。 GetImage.ashx そして GetFile.ashx.
そのようなURLを見かけた際は、以下の点に留意してください：
- Rockは、ファイルを配信する前にセキュリティチェックを実行しますが、これはこのようなファイルハンドラを使用している場合に限られます。
GetImage.ashx サイズ変更や回転などの変換に対応しています。GetFile.ashx ファイルを直接ストリーミングします（大容量のファイルの場合、処理が速くなります）。
おまけ：GetImage.ashx を使用する際は、スタッフが巨大な画像をアップロードした場合でも、画像を取得する URL を適切に設計することで、ブラウザに送信する前に画像を縮小してキャッシュした小さなバージョンを生成できることを覚えておいてください。詳細については、Rock ドキュメントの「ファイルのサイズ変更」の項目をご覧ください。
バイナリファイルの挙動は、ファイルの種類によって異なります。ファイルの種類によって、ファイルが物理的にどこに保存されるかが決まります。
「ファイルの種類」設定では、主に3つの保存オプションを設定できます
ファイルシステム
通常は推奨されません
- Rockではクラウドストレージを自動的に設定できないため、このオプションは初期状態で含まれており、設定も済んでいます。ただし、基本的には可能な限りこのオプションの使用は避けることをお勧めします。
- このオプションを選択すると、ファイルはWebサーバー上に保存されます（例：c:/inetpub/wwwroot/App_Data/Communications/filename.jpg）。
- これらは依然として GetImage.ashx や GetFile.ashx を通じて提供されていますが、URL（例：https://mychurch.org/App_Data/Communications/filename.jpg）が判明すれば、直接アクセスできることもよくあります。
- そのため、機密性の高いファイルやアクセスが制限されているファイルには、ファイルシステムストレージを使用しないでください。
- この構成は、複数のWeb（IIS）サーバーがある環境ではまったく使用できません。ファイルは、保存に使用された1台のサーバー上にのみ存在することになります。
データベース
セキュリティ保護されたファイルの設定が簡単に行える
- ファイルはRockデータベースそのものの中に保存されます。
- これらはRockのファイルハンドラを介してのみアクセスできるため、常にセキュリティが確保されます（ただし、セキュリティを有効にしたファイルではパフォーマンスの低下が生じるため、本当に必要なファイルタイプにのみ有効にしてください）。
- デメリット：
- すべてのリクエストは、Rockサーバーとデータベースに送信されます。
- このオプションを選択すると、多数のファイルや大容量のファイルが保存されている場合、データベースのサイズが大幅に増加します。
クラウドストレージ
ほとんどの用途に最適
- ファイルは、Azure、Amazon S3、Google Cloud 用のプラグイン、あるいはCloudinary のようなより専門的なサービスを利用して、オフサイトに保存されます。
- データベースとサーバーのストレージの両方の負荷を軽減します。
- ファイルが保護されているかどうかは、クラウドの設定によって異なります。セキュリティが重要なファイルについては、Rockのみがそれらをリクエストできるようにする必要があります。
Triumph Storage Moverプラグインを使えば、バイナリファイルを後から別のストレージへ簡単に移動させることができます。
資産
「アセット」は、Rockでファイルをアップロードするためのもう1つの方法であり、アセットを使えば、以前にアップロードしたファイルを閲覧したり再利用したりすることも可能です。これらは、特定の用途に向けた高度なオプションとして捉えるべきものです。
これらは「ファイルタイプ」やRockのセキュリティモデルを使用していません。Rockは単に、ファイルへの直接URL（通常はAzure、AWS、Googleなどのクラウドプロバイダー上にあるもの）を提供するだけです。
つまり、
- セキュリティチェックはありません。URLを知っている人なら誰でもファイルにアクセスできます。
- Rockのデータベースやサーバーには負荷がかかりません。ファイルはストレージプロバイダーから直接配信されます。
- 公開ページに表示される画像やメディアなど、一般公開用またはリスクの低いファイルに最適です。
資産は後から移動させるのが非常に困難です。例えば、HTMLブロック内にURLとして埋め込まれている場合など、ファイルの保存場所を変更する必要が生じた際、こうした参照箇所をすべて見つけ出して変更するのは容易ではありません。
ワークフロー
ワークフローは、プロセスを柔軟にする「ダイナミックな筋肉」のようなものだと考えてください。ワークフローは、骨のような基本的な構成要素というよりは、さまざまな機能を結びつけ、物事を前進させる役割を果たします。つまり、ワークフローは「アクション」を実行したり、Rock内の適切な場所にデータを移動させたりするために活用するのが最適です。データを保存するためのものではありません。また、1つの巨大で複雑なワークフローを作るよりも、多くの小さなワークフローを連携させて運用する方が、一般的に望ましいと言えます。そうすることで、管理が容易になり、万が一問題が発生した場合の修正もスムーズに行えます。
ワークフローは非常に強力ですが、正しく設定されていないと、サーバーに過大な負荷をかけてしまう可能性があります。ここでは、ワークフローを効率的に管理するための重要なヒントをいくつかご紹介します。
- ワークフローを扱う際は、必要がない限り、その状態を永続化しないようにしましょう。何かが発生したことを記録するには、もっと手っ取り早い方法があります。どうしてもワークフローを永続化しなければならない場合は、サーバーへの負荷を軽減するために、処理間隔をできるだけ長く設定できないか検討してください。たとえば、誰かがフォームに入力するのを待っているワークフローは、10分ごとに処理する必要はありません。処理間隔を調整することで、システムのパフォーマンスが向上します。
- また、タスクが完了したら、必ずワークフローを「完了」としてマークしてください。スキップされたアクションには注意が必要です。これらがプロセスの実行を継続させ、システムの動作を遅くする可能性があるためです。ワークフローを設定する際は、完了までの最適な期間（日数）、ワークフローの保持期間、およびログの保存期間について、慎重に検討してください。これにより、古いワークフローや完了したワークフローを削除し、システムをクリーンな状態に保つことができます。
- ワークフローのログ記録は、ワークフローの問題を特定するための便利なツールですが、あくまで一時的な補助手段として活用するのが最適です。ワークフローのログ記録は、問題の解決に必要な期間のみ有効にしておきましょう。トラブルシューティングを行っていない間はログ記録を無効にすることで、リソースを節約できます。
- 各ワークフローについて、慎重に検討した上で「処理間隔」を設定するようにしてください。この設定により、Rockは更新が必要かどうかを確認するために、どのくらいの頻度でワークフローを起動すべきかが決まります。ほとんどの場合、ワークフローの変更は人による操作によってのみ行われます。そのような場合は、処理間隔を非常に長い間隔（1日に1回、あるいはそれ以上）に設定しても問題ありません。
- 「ワークフローの最大有効期間」の設定は、Rockインスタンスが不要になったワークフローを繰り返し処理しないようにするための重要な設定でもあります。設定された期間が経過してもワークフローがまだアクティブな状態である場合、Rockはそのワークフローを自動的に非アクティブ化します。
一般的な設定のヒント
ワークフローには多くの設定やオプションがあります。以下に、参考になるかもしれないいくつかのポイントをご紹介します。
- ワークフローのトリガーについては注意が必要です。後でその所在を特定するのが困難な場合があり、誤って無限ループを引き起こし、システムに問題を生じさせる恐れがあります。また、設定が不適切だったり、頻繁に変更されるエンティティに設定されたりすると、サーバーのパフォーマンスに影響を与える可能性もあります。トリガーを作成する必要がある場合は、UIの動作を遅くしない「保存後」トリガーを必ず使用してください。
- ワークフローを通じてテキストメッセージを送信する際は、
SMSResponse この属性を「SMS送信」ワークフローアクションと組み合わせて使用しないでください。そうすると、受信者にメッセージが2回届いてしまいます。 - SQLワークフローアクションを安易に利用しないようにしましょう。どうしても必要な場合を除き、SQLを伴うワークフローの使用は控えてください。他に解決策がない場合は、代わりにコア機能の拡張が必要ではない かを慎重に検討してください。
- ワークフローを作成した時点では、セキュリティ機能が標準で備わっていないことを覚えておいてください。特に外部の公開フォームを使用する場合は、ワークフローの最初のステップを慎重に設定し、特定の種類のワークフローのみを許可するようにすることで、セキュリティをさらに強化してください。
未来の自分を想像してみてください
プロセスの文書化は、いくら徹底してもやりすぎることはありません。ワークフローに関する詳細をすべて、説明文や変更履歴に書き留めておきましょう。これは、組織が状況を把握するのに役立つだけでなく、将来の改善に向けた有益な指針にもなります。私たちはこれを「未来の自分へのラブレター」と呼んでいます。
チェックイン
チェックインは、Rockの中でも特に複雑なプロセスの一つです。ここでは、あなたやご家族にとってチェックインを最大限に活用するためのヒントをいくつかご紹介します。
セキュリティコード
- セキュリティコードのプールは、その日のすべてのチェックインで共有されます（ラベルにコードを印刷しないチェックインも含みます）。Rockによるコード生成の仕組み上、1日に数千人を超える人数をチェックインする場合は、3文字ではなく4文字を使用する方がチェックインのパフォーマンスが向上します。
ラベル
- Rockのコアラベルは変更しないでください。代わりに、Rockに同梱されているコアラベルのコピーを作成し、そのコピーを編集してください。コアラベルはRockのアップデート時に上書きされる可能性があるためです。
- 魅力的でデザイン性の高いラベルは、教会を良い印象でアピールし、他と差別化を図るのに役立つことを覚えておいてください！ラベルのフォーマットはZPL形式です。使い始めるために必要な情報はすべて、Rockのラベルに関するドキュメントに記載されています。
- ラベルのテストを行う際は、テキストフィールドに可能な限り短い文字数と長い文字数を入力してテストし、エッジケースがどのように処理されるかを確認することを忘れないでください。
設定
- 設定、グループ、スケジュールを不必要に重複させないでください。可能な限り、異なるキャンパスでも同じチェックイン設定、グループ、スケジュールを使用してください。シンプルが一番です！
- チェックインの設定を行う際には、保護者のチェックイン体験を最優先に考慮すべきです。保護者が理解できないような判断を迫ることは避けてください（例えば、「グループAとグループBのどちらを選べばいいのか、どちらの選択肢もあるのに、どうしてわかるの？」といった具合です）。
- 標準のチェックインワークフローは編集しないでください。
- 循環参照には注意してください。これによってCheck-in Managerがクラッシュする可能性があります。詳細については、こちらのコミュニティの「レシピ」をご覧ください。
ハードウェア
- 「万全」なチェックインを実現するには、信頼性の観点から、有線ネットワークが最も適しており、次いでWi-Fi、そしてBluetoothの順となります。
- Rock を使用するには、ZPL 対応のプリンターが必要です（『Checking Out Check-In』マニュアルの「プリンター」セクションにある推奨機種をご参照ください）。参考までに：カッター機能付きのプリンターがあると、作業が格段に楽になります！ ユーザーにラベルを手で切り取らせる必要がなくなれば、紙詰まりは事実上発生しなくなります。
- プリンターをご注文の際はご注意ください。ラベルは特定の解像度に合わせて設計されています（コアラベルは203ドット/インチのプリンター用に設計されています）。プリンターの注文は、納品までに時間がかかる場合があります。できるだけ余裕を持ってご注文ください。
- プリンターやラベルのご注文は、iT1 Sourceを強くお勧めします。最安値で入手できるだけでなく、最高のサービスも受けられます。
- 紙詰まりを防ぎ、印刷速度を向上させるため、Zebraプリンター用のカッターの導入を強くお勧めします。
SQL
SQLは、Rockのツールキットにおいて強力な選択肢の一つです。ここでは、最適な結果を得るために、いつ、どのようにSQLを使用すべきかを理解するのに役立つガイドラインをいくつか紹介します。
- 質の高いSQLを書くには、標準的な規約に従うことが重要です。コアチームは、Rockコミュニティ向けに基本的なSQLスタイルガイドを提供しています。SQLの書式設定は、必ずこれらの基準に従うようにしてください。この無料のオンラインツールを利用すれば、SQLの書式設定に関するサポートを受けることができます。
- さらに、当社のチームでは「SQLのベストプラクティス」に関する動画を作成しました。この動画では、書式設定のガイドラインや、クエリの構築を改善するためのヒントなど、有益な知見をご紹介しています。
SQLをいつ使うべきか
- Rockの世界において、SQLは城壁の外にあるもの、つまり強力ではあるが外部のツールだと考えてください。最終的にはSQLが正解となる場合もあるかもしれませんが、最初からSQLを選ぶことは避けるべきです。まずはRockの内部設定オプションを徹底的に検討してください。それらは、Rockの基盤となる構造と動的に結びついた、より堅牢な解決策を提供してくれるからです。
- SQL を使用して AttributeValue レコードを挿入または更新する際は、必ず IsDirty = 1 を設定してください。Rock は、AttributeValue テーブルの生の Value 列とは別に、属性値の永続化されたバージョンを管理しています。SQL を使用してこのテーブルに直接書き込む場合、明示的にフラグを設定しない限り、Rock は永続化された値が古くなっていることを認識できません。 影響を受ける行のいずれかで IsDirty = 1 を設定することで、「Update Persisted Attribute Values」ジョブ（デフォルトでは毎晩午前 2 時 15 分に実行されます）が変更を確実に検出し、整合性を確保します。ユースケースの要件により、次のジョブ実行を待たずに永続化された値を直ちに更新する必要がある場合は、SQL の実行後に手動でジョブをトリガーする必要があります。
警告
データ構造を次のように変更するには 挿入, 更新、および 削除 この記述には、検証の欠如、Rockのビジネスロジックのバイパス、キャッシュの更新の怠りなど、いくつかの潜在的な問題があります。
希望 modifyentity 可能な場合は、直接SQLよりも。利用可能な場合は、Rockの modifyentity コマンドを使用するのが推奨されるアプローチです。キャッシュの更新やビジネスロジックを自動的に処理してくれるからです。
SQLの使い方
- もし結局のところ、SQLが問題の解決策として適切であるならば、将来を見据えてステートメントを構築するようにしてください。設定やビジネスロジックをSQLに埋め込むのではなく（例えば、
WHERE [Id] IN (23,24,25) )、その代わりに、長期的に管理し続けなければならない特定のIDを参照することは避けてください。将来を見据えたアプローチを採用しましょう。動的SQLの記述に関する詳細については、 この動画を見てみてください. - 上記のリンク先動画では、Rockの保護機能の枠を超えてSQLがどのように動作するかをより深く理解できるほか、プロジェクトにおいてSQLが最適な選択肢となる場合に役立つ貴重なヒントも紹介されています。
- SQLをもっと深く学びたいですか？その場合は、「Rock SQLクラス」の受講を強くお勧めします。
- さらに深く学びたいですか？ それなら、この本『T-SQL Fundamentals』を強くお勧めします。
その他
私たちのチームはSQLについてさらに深く掘り下げていく中で、入門編から上級編に至るまで、さまざまなトピックに関する知見をウェブサイト上で継続的に発信しています。ここでは、その一例をご紹介します。以下のコンテンツをはじめ、新しい記事が随時追加されますので、ぜひ定期的にチェックしてください：
- 日付を使った小技
- SQLの実行順序
- ピボットパターン
溶岩
Lavaは、Rock管理者にとって非常に頼りになるツールです！これを使えば、プログラミングを一切行わなくても、データベースから情報を簡単に取得し、ページ上に表示することができます。ごくわずかな例外（例えば、 {% sql %} コマンドと {% interactionwrite %} コマンド）に加え、Lavaは読み取り専用であるため、データが誤って削除されたり編集されたりする心配はありません。
ただし、Lava を利用する際は、意図的なアプローチを心がけることをお勧めします。テンプレートを慎重に設計しないとパフォーマンスの低下を招く恐れがありますし、作業内容をできるだけ明確で読みやすい状態にしておけば、将来、きっとその努力が報われるでしょう。
- SQLと同様に、可読性や将来の更新、トラブルシューティングの観点から、書式やドキュメントの標準化は重要です。Lavaスタイルガイドに記載されているガイドラインに従ってください。また、DotLiquidとFluidの構文の違いについては、以下の点に留意してください。
- また、設定や変数の宣言は、インラインで記述するのではなく、lavaセクションやスクリプトの先頭にまとめて記述するようにしてください。これにより、更新が容易になり、スクリプトの保守性が向上します。
- 「」は使用しないでください。
{% コメント %} タグですが、むしろ //- そして /- -/ 構文。 - 可読性を高めるため、タグにハイフンを入れないでください（例：
{%- assign ... -%} 空白の存在によって、現在行っている処理に支障をきたす場合を除き、ほとんどの場合、余分な空白があっても問題にはなりません。
- 注意を怠ると、たった1つのエンティティコマンドで数千件ものデータベース呼び出しが発生する可能性があります。エンティティコマンドを使用する際は、式やselect、prefetch属性などの高度なフィルタを活用し、データベースから取得するデータ量を制限することを検討してください。また、状況に応じて「securityenabled」をfalseに設定することで、パフォーマンスを向上させることもできます。
- 次のようなキャッシュ戦略を用いて 永続化されたデータセット また、リアルタイム性能の向上にも役立ちます。次のように使用できます。
{[ベンチマーク]} 無料版のショートコード Lava Tools プラグイン Lavaテンプレートのパフォーマンスに関する多くの情報を収集し、さまざまな戦略の採用を判断するためのテンプレートを作成する。 - できるだけ早く「Fluid Lava Engine」を使用してください。
設計上の考慮事項
他のツールと同様、lavaを最大限に活用するには、いくつか留意すべき点があります。ここでは、その主なポイントをいくつか挙げました。
- 扱うデータのフィールド型に注意し、それを考慮に入れてください Lava 内のデータの存在 ～と
null そして 空. - 使用を控えてください
{% unless %}、ただし、の最終実行の確認としての場合を除き、 {% for %} ループ。
- ショートコードを使用してlavaタグの機能を拡張し、{% include %}タグを使用して複数のページ間でテンプレートを再利用します。
- ショートコードやインクルードのネストは避けてください。変数のスコープを把握するのが、あっという間に複雑になってしまいます。
- 無料の「Lava Tester」プラグインを使えば、Lavaを実世界のエンティティに対して素早くテストすることができ、時間を大幅に節約できます。
Web
Rockは、本質的にはウェブサイトです――いや、正確には一連のウェブサイトと言えるでしょう。Rockのウェブサイト、ページ、ブロックを使ってできることはたくさんありますが、ここでは、自分自身で落とし穴を作らないようにし、ウェブサイトのレスポンシブ性を可能な限り高めるためのガイドラインをいくつか紹介します。
マグナス
Triumph社は、VS CodeおよびAzure Data Studioと緊密に連携するプラグイン「Magnus」の開発に多大な投資を行ってきました。Magnusを使用すれば、これらの優れたツールから直接、Rock内のコンテンツやデータを簡単に編集することができます。お使いのRockインスタンス内のRock Shopで「Magnus」をお探しください。
外部ウェブサイト
- Rockをインストールすると、Rockの機能の一部を紹介するためのデフォルトの外部サイトが利用可能になります。ただし、このサイトはデモ用として設計されており、ご自身のウェブサイトの出発点となるものではありません。
- バージョンの更新に伴い、外部サイト向けの推奨機能に関する最新情報を皆様にお届けするため、当サイト上のページや機能を追加・編集することがあります。 特に、まだ利用開始の準備が整っていない新機能の場合など、実際の外部サイトでこれらの変更が行われることは避けたいでしょう。そのため、Rockを外部ウェブサイト（またはイベント登録、グループ検索、オンライン献金などの機能を備えた部分的なウェブサイト）として利用開始する準備が整った際には、デフォルトの「外部ウェブサイト」のページを使用するのではなく、訪問者が閲覧するためのまったく新しいサイトを作成することをお勧めします。
- もちろん、新しく立ち上げる外部サイトには、デフォルトの「Stark」テーマとは別のテーマを使用することをお勧めします。このテーマは意図的にシンプルなデザインにしており、ついそれを使いたくなってしまうことがないようにしています。すべての教会が同じテーマを使い、見た目が似通ってしまうような事態は避けたいからです。
一元管理されたテンプレート
- Rock には、テンプレートを 1 か所に保存し、複数のブロックで再利用するための方法がいくつか用意されています。最も一般的なのは Lava を利用するもので、具体的には「インクルードファイル」と「Lava ショートコード」です。
- インクルードファイルは、ソース管理システムを使用してデプロイを行ったり、変更内容を追跡したりする場合に便利です。しかし、Rockでトラブルシューティングや編集を行う際、インクルードファイルを素早く読み込んで確認するのは困難です。また、推奨されているFluid Lavaエンジンを使用している場合、インクルードファイル間で変数をやり取りすることはできないという点に注意が必要です。
- 一般的には、テンプレートをLava Shortcodesに一元化することをお勧めします。Lava Shortcodesには、テンプレートの使用方法や使用場所に関する説明を記載できるフィールドが組み込まれており、渡されたパラメータに基づいて動的に動作させることが可能です。また、Rock UIで簡単に読み込んで、必要に応じて確認や編集を行うこともできます。
ページの読み込みが速い
Rockシステム内に存在するすべてのデータは、どこかに保存される必要があります。その大部分はデータベースに格納されていますが、データはRAMにキャッシュされることもあります。RAMにキャッシュされたデータは、サーバーが読み出す際に非常に高速です。データの読み出しが高速であるということは、単にページの表示が速くなるだけでなく、より多くのユーザーが同時にシステムを利用できる処理能力の向上にもつながります。ここでは、キャッシュについて知っておくべきことを解説します。
- 一般的に、キャッシュされるデータは一度はデータベースから取得する必要がありますが、キャッシュの目的は、一度データベースからそのデータを取得した後は、毎回同じ情報を取得するためにサーバーが何度もデータベースにアクセスすることを避けることにあるのです。
- 「コンテンツチャンネルアイテム／ビュー」ブロックや「HTMLコンテンツ」ブロックなど、一部のブロックには、ブロックによって表示されるデータがキャッシュに保存される期間を制御できる設定があります。一般的に、コンテンツを動的にパーソナライズするLava（たとえば、ページを閲覧しているユーザーに応じてコンテンツを変更する機能など）がない限り、これらのブロックのコンテンツは常にキャッシュするようにしてください。
- ただし、Lava を使用できる場所であればどこでも、特定のコンテンツをキャッシュするように指定することも可能です。その際は、 {% cache %} タグ. これらのタグは非常に強力です。なぜなら、特定のキー（ユーザーが指定できるキー）に基づいて保存され、後で再び参照されるからです。したがって、キャッシュタグを使用する場合、コンテンツがパーソナライズされている場合でも、そのコンテンツをパーソナライズする要素をキーに含めることができます。例えば、時間帯に基づいてコンテンツをパーソナライズする場合、次のように、時間帯を動的に含めたキャッシュキーを設定することができます。
トップページの朝の挨拶 対 トップページの午後の挨拶. そうすれば、コンテンツをカスタマイズする要因が変わらない限り、Rockはキャッシュされたコンテンツを使い続けることができます。しかし、その要因が変わるとすぐに、Rockは最新のコンテンツを取得し、新しいタグを付けてキャッシュします。この仕組みは、ページのURLに指定されたパラメータ値など、他の要因にも応用できます。
メンテナンスしやすく、アクセシビリティに配慮したHTML
テンプレートやブロックにHTMLを追加する際は、可能な限りセマンティックマークアップを意識し（そして活用する）ことが望ましいです。
- これはアクセシビリティの観点から重要です。例えば、
<article> 要素はセマンティックHTMLであり、スクリーンリーダーなどの技術が、ページで表示されることを意図したメインコンテンツを識別することを非常に容易にします。もし次のような非セマンティックなマークアップを使用した場合、スクリーンリーダーがこれを判別するのははるかに困難になります。 <div class="article">. - また、これにより、マークアップの保守性が向上し、チームメンバー（あるいは半年後の自分！）にとっても読みやすくなります。さらに、セマンティックマークアップにテーマを適用することも理にかなっています。a
<b> tag (which is not considered semantic) is just supposed to make text bold. And even though you can specify that all <b> tags should also be colored red for emphasis, it's not likely that anybody reading your markup would assume that there's any styles ただし これらの要素には太字が適用されているため、分かりにくい。一方、セマンティックな <strong> このタグには、このタグ内のテキストがページ上で際立って目立つということ以外、特に先入観は伴いません。こうしたセマンティックタグには、太さの指定だけでなく、色の指定（そしておそらくその他のスタイルも！）を適用するほうが、はるかに理にかなっています。
CSS
Rockには、強力なCSSユーティリティクラスが用意されています。可能な限りこれらを活用して、カスタムCSSの記述を簡素化し、その量を減らしましょう。
JavaScript
Rockはブラウザを使用して閲覧する一連のウェブページとして扱われるため、当然ながら、ページに組み込んだJavaScriptはすべてブラウザ上で実行可能です。ただし、コアブロックの外観、レイアウト、または機能を変更するためにJavaScriptを使用することは絶対に避けてください。その理由は、コアブロックは常に変更や改良が加えられているため、この方法でカスタマイズを行うと、将来的に機能しなくなる可能性が高いからです。 ブロックの動作を現在の仕様とは異なるものにする必要がある場合は、Rockパートナーと協力してコア部分の更新を行うことをお勧めします。これにより、あなたが要望した機能を利用できるようになるため、他の教会にもメリットがもたらされます。
連携機能と拡張機能の選択
当チームがまとめた「Rock」のベストプラクティスの中でも特に人気の高いものを一通りお読みいただいたところで、コアプラットフォームの拡張方法や提携先組織の選定についても、同様に慎重に検討してください。
スマートフォンのアプリストアにあるすべてのアプリが同じ品質（アーキテクチャ、デザイン、メンテナンス、応答性など）であるわけではないのと同様に、Rockの拡張機能や連携機能もすべてが同等の品質で作られているわけではありません。必ず事前に十分な調査を行い、慎重に選択してください。
- サンドボックスサーバー上でテスト済みであり、各部署の業務に必要であることが確認されたプラグインのみをインストールすることをお勧めします。また、最新バージョンがリリースされ、テストが完了次第、必ずそれらを最新バージョンに更新してください。
- 信頼できる人々のアドバイスを参考にし、統合機能に関するコミュニティのフィードバックを常に把握するために、統合機能に関するこのコミュニティアンケートをご覧ください。
- Rockの管理権限をデータベースに自動的にインストールするAPI連携は避けてください。これは、玄関のドアを開けっ放しにするのと同じようなセキュリティ上のリスクです。その代わりに、各連携では、必要なデータのみへのアクセスを許可するよう、カスタムエンドポイントまたは特別に調整されたエンドポイントを使用する必要があります。これにより、そのプラットフォームでセキュリティ侵害が発生した場合のリスクを最小限に抑えることができます。
- Rockの機能を拡張する場合と、データを操作したり会員とコミュニケーションをとったりするためにRockからデータを抽出する連携機能を追加する場合の、それぞれのメリットとデメリットを検討してください。Rockをデータウェアハウスとして活用し、深く豊かなパーソナライゼーションを実現するのではなく、データをさまざまなデータベースに「分散」させるような連携機能を使用すると、インタラクションやインサイトに関する貴重なデータが失われてしまいます。
- 最後に、Rockインスタンスのコンサルティングや開発を依頼するパートナーを選ぶ際は、Sparkチームが推奨する質問を必ず確認してください。また、各パートナーの成果物を精査し、その専門知識、トレーニング、プロセスを把握することをお忘れなく。そうすることで、長期的なRockの利用において最適なパートナーを選定できるでしょう。