何百もの教会と長期にわたって協力することで、Rockを最高の体験のために構築し、維持するための最良の方法についての洞察を得ることができました。私たちには膨大な量のトレーニング教材と学習がありますが、私たちの目標は、最も一般的に必要とされ、役に立つ洞察をRockコミュニティと共有することです。成功を分かち合うことが最高の成功であり、ベスト・プラクティスを自由に分かち合うことで、私たち全員が#BetterTogetherになれると確信しています。
このマニュアルは生きている文書であり、私たちのチームが学び成長し続けるにつれて、時間の経過とともに変化していきます。また、最新のトレーニング・ビデオや便利なロック・ツールなど、ウェブサイトの「リソース」ページもご参照ください。
ロックの秘訣トップ10
ロックの魅力を最大限に引き出すためには、多くの重要なヒントがある。その詳細を紹介する前に、覚えておくべきコンセプトのトップ10を紹介しよう。
- デジタル戦略がリーダーシップの期待と投資目標を一致させる。ロックはデジタル戦略のエンジンです。ロックに十分なリソースを確保することが重要です。
- Rockを中心的なデータウェアハウスとしてお使いください。パーソナライズされたミニストリーの可能性を最大化するために、データを分割せずに一元化する方法で拡張します。
- すべてを文書化。ワークフロー、レポート、データビューから始めましょう。複雑なプロセスも忘れずに。
- システムは複雑さを増していきます。問題の発生を防ぐために、パフォーマンス、セキュリティ、設定の定期的な見直しに投資しましょう。
- コアファイルのソースを変更しない。必要であれば、バグを修正したり、機能を追加したり、アイデアを共有したりするために、コアのリクエストを行って ください。
- 変更は、サーバーのファイルシステムで承認されたディレクトリに限定してください。変更すべきフォルダは以下のとおりです:ContentとThemes(そしてあなたのテーマのみ)です。
- キャッシュはパフォーマンスの鍵です。キャッシュがRockでどのように機能するかについては、これらのビデオを参考にしてください:
- ロック内のキャッシング
- キャッシングの重要性
- JavaScriptでコア・ブロックや機能のDOMを変更したり、CSSでコア・ブロックのコンテンツを隠したり動かしたりしないでください。
- SQLやLavaでのビジネスロジックのハードコーディングは避ける。
- ワークフローは筋肉であって骨ではない。複雑にしすぎないこと。
インフラ
サーバーはロック体験の基盤です。サーバーが健全で十分なリソースがあることを確認することで、システムのパフォーマンスは大きく変わり、想定内と想定外の両方の事態に備えることができます。
初期インストール
Rock環境のホスティングには様々なオプションがありますが、コミュニティではMicrosoft Azureをクラウドホスティングや場合によってはオンサイトサーバーとして利用する傾向があります。コミュニティでこれらの基本的なガイドを見つけることができます。私たちのチームは、インフラストラクチャのセットアップとメンテナンスのためのベストプラクティスを文書化しました。
私たちの経験では、組織はRockサーバーのプロビジョニングが不足しがちです。これは教会全体のデジタル戦略のエンジンであることを覚えておいてください。スポーツカーに芝刈り機のエンジンを載せることはないでしょうから、Rockサーバーがあなたのミニストリーを増幅させるために必要なリソースを飢えさせないようにしてください。
サーバーの設定
初期構成によって、毎日やピーク時のインフラ・パフォーマンスが大きく変わる可能性があります。
- 本番環境とサンドボックス環境を分ける。1つのサーバー(またはVM)を両方の環境に使用することは魅力的に見えるかもしれませんが、金銭的な負担はほとんどないにもかかわらず、リスクを増大させることになります。別々のサーバーに置くことは、本番運用に影響を与える可能性のある問題を避けるためのセキュリティ対策です。
- 複数のドメインにIISバインディングを使用するのは避けましょう。ロック・インスタンスにIIS(インターネット・インフォメーション・サービス)バインディングを設定する場合は、前述のように各インスタンスに仮想マシン(VM)を持たせるのがよい。また、各インスタンスのバインディングはHTTP(ポート80)とHTTPS(ポート443)の2つだけにしてください。こうすることで、異なるドメインの新しいサイトを追加しても、ロックがトラフィックを処理し、設定に基づいて適切なサイトを表示するため、IISを再設定する必要がなくなります。追加のバインディングは必要なく、トリップハザードを引き起こします。
- ウェブサーバーとSQLサーバーの両方に定期的なバックアップを設定することで、システムを保護します。これにより、データを紛失したり、システムに問題が発生した場合でも、すぐにすべてを以前の状態に戻すことができます。バックアップの設定を検討する際には、短期的および長期的なリカバリの必要性を念頭に置いてください。
- IISの追加設定を考えてみよう。
- 圧縮を有効にする:圧縮モジュールをサーバーにインストールし、IIS内で圧縮を有効にします。ロックサーバーのコンテンツを圧縮することは、迅速なレスポンスのために重要です。
- WebSocketプロトコル(Microsoft Azure SignalRサービスで利用可能)を有効にします:RockのReal-time Engineは、サーバーからリアルタイムの情報を受け取ることができるWebSocket Protocolで最も効果的に動作します。これが有効でない場合、更新を受信するためにサーバーに対して繰り返しpingを受信することになり、はるかに効率が悪くなります。
リソースのモニタリング
サプライズはパーティーでは楽しいが、重要な建築に関しては別だ。
- 言うまでもないことですが、IISログを監視して経時的な傾向を確認し、リソースのニーズが高まっているかどうか、または対処が必要なパフォーマンスの問題があるかどうかを把握するようにしてください。少なくとも隔月でIISログを確認することをお勧めします。Rockサーバーのトラフィックについて何がわかるか、きっと驚かれることでしょう。
- さらに、仮想マシンとSQLデータベースを定期的に更新し、SQL Serverの互換性レベルをアップグレードして、最新の改良に対応するようにしてください。
- プロアクティブなモニタリングとアラートを設定する。私たちは、何か問題があることをアラートで知らせてくれる方が、牧師よりもありがたい。Better Stack Uptimeをお勧めします。PingdomやStatus Cakeで成功しているコミュニティもあります。
- v16の新機能として、RockはObservabilityという素晴らしい新機能を追加しました。これにより、NewRelicのようなオブザベーション・プラットフォームに詳細なタイミングやメトリックスを送信することができます。このデータを利用できるようにすることは、調整されたデジタル・プラットフォームを運用する上で非常に重要です。
ベーシックを超えて
基本をマスターしたら、これらの分野が自分にどのように当てはまるかを考えてみよう。
- スマートなスケーリング戦略:システムを拡張する場合、一緒に動作しなければならないサーバーを増やす(スケールアウト)のではなく、1台のサーバーにより多くのリソースを追加する(スケールアップ)方が良いでしょう。そうすることで、セットアップが複雑にならず、管理も容易になります。
- バッチ処理によるAPIリクエストの最適化: サービスの統合にRockのREST APIを使用している場合、APIリクエストのグループ化(バッチ処理)を行うか、カスタムエンドポイントを使用してAPIの使いすぎを防ぎましょう。これにより、複数のリクエストを1つにまとめることでシステムが効率化され、余分な作業が減り、全体的なパフォーマンスが向上します。
- コンテンツ・デリバリー・ネットワーク(CDN)の利用を検討する:今日のデジタル環境では、CDNはほぼ必須です。サーバーが多くのトラフィックを処理する場合は、コンテンツ・デリバリー・ネットワーク(CD N)の利用を検討してください。CDNは、ウェブサイトのコンテンツを世界中の異なるサーバーに分散させ、訪問者の読み込みを高速化し、遅延を減らします。外部ウェブサイトやモバイルアプリケーションをRockで運用している場合は、CDNは特に重要です。
コンフィギュレーション
Rockは非常に拡張性が高いので、幅広い設定オプションや組み合わせが利用できる。Rockでやりたいことを実現するための正しい方法はたいてい1つではないが、正しくない方法もたいていたくさんある。
目の前の問題だけを解決するのではなく、将来の保守性を考慮する。そうすることで、不安定になる「トランプの家」を作らないようにすることができます。可能な限りコアの製品で作業し、必要であれば資金を提供されたロックコアのアップデートを要求したり、コミュニティがアップヴォートできるようにアイデアボードにアイデアを追加したりもします。これは、コアのブロックをコピーして変更を加えるよりもはるかに安全な長期的な選択肢です。
データの状態はRockインスタンスのパフォーマンスにも影響を与えます。付属のデータ整合性設定とレポートを使用して、可能な限りクリーンで正確な状態を保つようにしてください。
お客様のニーズに合わせてRockをカスタマイズする際には、以下のコンフィギュレーションのベストプラクティスを念頭に置いてください。
一般
ロックのコンフィギュレーションに取り組むにあたって、高いレベルで考慮すべきテーマがいくつかある。
同じツールで作る
ロックの拡張や構築に使えるツールや技術は無限にある。できる限りコミュニティと同じツールを使うようにしよう。そうすることで、以下のようないくつかの有益なメリットが得られます:
- あなたの組織が長期にわたってサポートしやすくなる。他のコミュニティメンバーもそれを知っており、パートナーもそれを熟知している。
- より簡単に他の人と共有できるようになり、コミュニティ全体を前進させる。
- 参考文献は他にもある。
クリーンなインスタンスが鍵
また、比較的小さなことのように思えるかもしれないが、ロックのインストールを清潔に整理整頓しておくことは、物理的なワークスペースを整理整頓しておくことと同じであり、多くのスタッフと共有するものであるため、特に役に立つ。
- オプションを素早く区別するために、一貫してアイコンを使用する。
- Sparklinkの通知をトップページから消去する。
説明を義務付けるべき
説明フィールドを見かけたら、必須フィールドだと考えてください。ワークフローであれ、データビューであれ、ヘルパーテキストであれ、その他のものであれ、なぜそのようなものが存在し、何のために使われるのかについて、コンテキストとドキュメントを提供することは、将来的に非常に貴重なものとなるだろう。
特定のフィールドタイプに関するヒント
- 単一選択または複数選択のフィールド・タイプを作成する際には、値のキーを指定してください。これにより、データを失うことなく、後で名前を変更することができます。例えば、オプションを
リンゴ、レモン、サクランボ
代わりに次のようにリストアップする。 1^リンゴ、2^レモン、3^サクランボ
. - マトリックス属性の使用は、他のすべての解決策を使い尽くし、絶対に必要な場合以外は避けてください。これらのフィールドは強力ですが、効率は悪く、レポートツールもありません。
グループ
グループタイプに親-子-親の無限ループを作らないように注意してください(親グループタイプが子グループタイプの子として設定される)。特にチェックイン構成でこのような現象が見られます。
グループ・タイプの変更は基本的に避けるべきである。やむを得ない場合は、以下に特別な配慮が必要である:
- 当該グループがグループ同期を使用していないことを確認する。グループ・シンクが存在する場合は、グループ・メンバーの不一致による例外を避けるため、グループ・タイプを変更する前に削除し、変更後に再度追加する。
- グループ・メンバー・テーブルとグループ・メンバー履歴テーブルの両方で、グループ・メンバーのロールIDが更新されていることを確認してください。
- グループ・タイプに追加される属性を考慮する。これらの属性は新しいグループ・タイプには存在しません。そのため、それらの値を新しい属性に移行するか、不要になった場合は削除する必要があります。
セキュリティ
- ファイルタイプにはセキュリティをかけることができます。機密性の高いファイル・タイプには正しいセキュリティが設定され、Rockを通さずにファイルにアクセスできるようなURLが設定されていないことを確認してください(たとえば、FileSystemにセキュリティで保護されたファイルを保存しないなど)。
- 人はたくさんのセキュリティ・ロールに属することができます。ですから、カスタムセキュリティロールは、少数の関連するページ、ブロック、またはプロセスに対してのみアクセスを許可または拒否するという、非常に焦点を絞ったものにするようにしてください。複数のロールが必要な人がいる場合は、両方のセキュリティ・ロールに追加してください。セキュリティ・ロールを文書化し、よく管理することで、将来、スタッフやボランティアのオンボーディングやオフボーディングを行う際に、セキュリティ・ロールを理解できるようにします。
- 新しいセキュリティ・ロールを作成するときは、あなたの意図するユースケースに最も近いセキュリティ・ロールを選択することから始めてください。新しいセキュリティ役割は、既存のセキュリティ役割の基盤から、追加の役割を許可または拒否するようにします。次に、新しい役割が既存の役割の上に「積み重なる」ように、これらのセキュリティ役割の両方に人を追加します。
- ページやブロックレベルでセキュリティを編集する場合、可能な限り特定の個人を追加するのではなく、セキュリティロールを使用してください。
求人情報
- 実行に必要以上に時間がかかっているジョブを無視しないでください。最低限、ジョブの完了に時間がかかりすぎて、再スタートするはずの時間までに終わらないということがないようにしてください(Rockが同じジョブの複数のインスタンスを同時に実行させることはありませんが)。ジョブの完了に何時間もかかってはいけません。
- 少なくとも週に一度は職歴を見直し、問題のある仕事を探す。
ファイナンス
- ロック・バッチは帳簿システムのバッチと連動させることを意図している。毎月、帳簿が照合され、締められると、一致するRockのバッチも締められる。Rockの未解決バッチは、まだ照合されていない月の取引に関連するものだけであるべきである。
データビューとレポート
- データ・ビューの永続化を検討する。すべてのデータビューを永続化する必要はありませんが、このトピックにスマートに取り組み、永続化の頻度を慎重に考慮して設定するようにしてください。永続化により、データ・ビューのロードがより速くなり、パフォーマンスが向上します。ただし、レポートやスタックされたデータ・ビューを表示している場合は、各データ・ビューの永続性が表示されるデータの更新速度に影響することを忘れないでください。永続性が望ましいですが、各ユースケースに合わせて調整する必要があります。
- 基本的なデータ・ビューを再利用することは推奨されますが、可能な限り、同様のフィルタを使用する複数レベルのネストされたデータ・ビューは避けてください。これはパフォーマンスの問題を引き起こす可能性があります。特に、データ・ビューやレポートが多くのスタッフによって作成されている場合は、レポーティング戦略を随時見直し、重複するデータ・ビューを一掃する必要があります。
- レポートを作成する際には、エンティティコマンドを使用したり、他の関連するエンティティタイプからプロパティを取得したりするカスタムLava列の作成は避けてください。これらは、特に大きなデータセットを持つレポートの場合、パフォーマンスにすぐに影響を与える可能性があります。
ワークフロー
ワークフローは、プロセスを柔軟にする動的な筋肉のようなものだと考えてほしい。ワークフローは、骨のような基本的な構成要素になるのではなく、さまざまな機能をつなげ、物事を実現するのに役立つ。つまり、ワークフローはアクションに最適で、データをロックの適切な場所に移動させるために使われる。データを保存するためのものではない。また、一般的には、1つの大きな複雑なワークフローではなく、多くの小さなワークフローが一緒に動く方が良いということでもある。そうすることで、管理しやすくなり、何か問題が発生しても修正しやすくなる。
ワークフローはパフォーマンスに影響を与える
ワークフローは非常に強力ですが、正しく設定しないと、サーバーに大きな影響を与える可能性があります。ワークフローを効率的に管理するためのヒントをいくつかご紹介します。
- ワークフローを扱う場合、必要でなければ、それを持続させないようにしよう。何かが発生したときに、より素早くメモを取る方法がある。ワークフローを永続化する必要がある場合は、サーバーへの影響を軽減するために、どの程度の頻度で処理できるかを考えましょう。例えば、誰かがフォームに入力するのを待つワークフローは、10分ごとに処理する必要はありません。タイミングを調整することで、システムがよりうまく機能するようになります。
- また、ワークフローはタスクが完了したら必ず完了マークをつけること。スキップされたアクションは、プロセスを実行し続けることになり、システムを遅くする可能性があるので注意すること。ワークフローを設定する際には、完了までの最適な期間(日数)、ワークフローの保持、ログの保持について熟慮の上、決定してください。これにより、古いワークフローや終了したワークフローを取り除くことができ、システムをクリーンな状態に保つことができます。
- ワークフローロギングは、ワークフローの問題を特定するための便利なツールですが、一時的なサポートとして使用するのがベストです。ワークフローロギングは、問題解決に必要な期間だけオンにしておきましょう。トラブルシューティングを積極的に行っていないときはオフにすると、リソースを節約できます。
- 各ワークフローには、十分考慮した "処理間隔 "を設定してください。この設定により、Rockはどれくらいの頻度でワークフローを起動し、更新の必要がないかを確認することができます。ほとんどの場合、ワークフローは人との対話によってのみ変更されます。このような場合、処理間隔は非常に高い数値に設定することができます(1日1回、またはそれ以上)。
- また、"Maximum Workflow Age "設定は、Rockインスタンスが不要になったワークフローを繰り返し処理しないようにするための重要な設定です。ワークフローがこの設定された期間を過ぎてもアクティブな場合、Rockは自動的にそのワークフローを非アクティブにします。
一般的な設定のヒント
ワークフローには多くの設定やオプションがあります。ここでは、参考になりそうな考察をいくつか紹介しよう。
- ワークフロートリガーには注意してください。後で見つけるのが大変になったり、誤って永久にループさせたりして、システムに問題を引き起こす可能性があります。また、正しく設定されていなかったり、頻繁に変更されるエンティ ティにトリガが設定されていると、サーバーのパフォーマンスにも影響します。トリガーを作成する必要がある場合は、UIを遅くしない "Post-Save "トリガーを使用するようにしてください。
- ワークフローを通じてテキストメッセージを送信する場合は
SMSResponse
属性とSMS送信ワークフローアクションを組み合わせてください。そうすると、受信者はメッセージを2回受け取ることになります。 - SQLワークフローアクションをデフォルトで使用しない。本当に必要でない限り、SQLを使用するワークフローは使用しないようにしましょう。他に解決策がない場合は、代わりにコアの機能強化が 必要かどうかをよく考えてください。
- ワークフローは、作成時にセキュリティが組み込まれていないことを忘れないでください。特に外部の公開フォームを使用する場合は、ワークフローの最初のステップを慎重に設定し、1種類のワークフローしか許可しないようにし、さらにセキュリティを追加してください。
未来の自分を考える
プロセスを過剰に文書化するのは難しいだろう。説明文と変更履歴に、ワークフローに関するすべての詳細を書き留めましょう。これは、あなたの組織が何が起こっているかを理解するのに役立つだけでなく、将来の改善のための有用なガイドにもなる。私たちはこれを未来の自分へのラブレターと呼んでいる。
チェックイン
チェックインはロックの中でも複雑な部類に入る。ここでは、チェックインがあなたとご家族にとって最高のものになるためのヒントをいくつかご紹介します。
セキュリティコード
- セキュリティコードのプールは、1日のすべてのチェックインで共有されます(ラベルにコードが印刷されていないものも含む)。ロックがコードを生成する方法のため、1日に数千人以上チェックインする場合は、(3文字ではなく)4文字を使用した方がチェックインのパフォーマンスには有利です。
ラベル
- コアのRockラベルを修正しないでください。コア・ラベルはRockのアップデートで上書きされる可能性があるからだ。
- 魅力的でデザイン性の高いラベルは、あなたの教会を良く見せ、目立たせるということを心に留めておいてください!ラベルはZPLでフォーマットされます。Rockのラベル・ドキュメンテーションをご覧ください。
- ラベルをテストする際には、エッジケースをどのように扱うかを理解するために、テキストフィールドに可能な限り短い文字数と長い文字数を使用してテストすることを忘れないでください。
コンフィギュレーション
- 不必要にコンフィギュレーション、グループ、スケジュールを重複させない。可能な限り、異なるキャンパスで同じチェックイン設定、グループ、スケジュールを使用してください。シンプルが一番です!
- チェックインを設定する際、保護者のチェックイン体験を最重要視す べきである。保護者が理解できないような判断を求めないようにする(例えば、「どちらも選択肢の中にあるのに、AグループとBグループのどちらを選べばいいのか、どうやって判断すればいいのか」など)。
- ストックチェックインのワークフローを編集しないでください。
- 循環グループタイプの参照に注意してください。これらはCheck-in Managerをクラッシュさせます。詳しくはこのコミュニティのRecipeを参照してください。
ハードウェア
- 防弾」チェックインのためには、有線ネットワークが理想的で、次いでWi-Fi、Bluetoothの順で堅牢性が高い。
- RockにはZPL対応プリンタが必要です(チェックアウト・チェックインマニュアルの「プリンタ」セクションの推奨をご覧ください)。カッター付きのプリンタを使うと便利です!ラベルを切り離す必要がなければ、実質的にジャム防止になります。
- ラベルは特定の解像度用に設計されています(コア・ラベルは203ドット・インチ・プリンタ用に設計されています)。プリンタの注文は、納品されるまでに時間がかかることがあります。できるだけ余裕を持ってご注文ください。
- iT1 Sourceにプリンタとラベルを注文することを強くお勧めします。ベストプライスだけでなく、最高のサービスを受けることができます。
- ジャムを防ぎ、ラインをスピードアップするために、Zebraプリンター用のカッターを入手することを強くお勧めします。
エスキューエル
SQLはロックのツールキットの強力なオプションです。ここでは、SQLをいつ、どのように使えば最高の結果が得られるかを理解するのに役立つガイドラインをいくつか紹介します。
フォーマット基準
- 質の高いSQLを書くためには、標準的な規約を使うことが重要です。コア・チームは基本的なSQLスタイル・ガイドをロック・コミュニティに提供しています。SQLの書式がこれらの標準に従っていることを確認してください。この無料のオンライン・ツールで、SQLの書式設定の支援を見つけることができます。
- さらに、私たちのチームはSQLのベストプラクティスに関するビデオを作成し、フォーマットのガイドラインやクエリ構築を強化するためのヒントに関する貴重な洞察を提供しています。
SQLの使用時期
- ロックの領域では、SQLは城壁の外、つまり強力だが外部的なツールだと考えてほしい。SQLは最終的には正しい答えになるかもしれませんが、最初の選択としては避けるべきです。Rockの基本構造に動的に結びついた、より堅牢なソリューションを提供するからです。
警告
でデータ構造を変更する。 挿入
, 更新
そして 削除
ステートメントには、検証の欠如、ロックのビジネス・ロジックのバイパス、キャッシュの更新の無視など、いくつかの潜在的な問題がある。
SQLの使い方
- もしSQLがあなたの問題に対する正しい答えであるなら、必ず将来を念頭に置いてステートメントを構築してください。設定やビジネス・ロジックをSQLに埋め込むのではなく(たとえば
WHERE [Id] IN (23,24,25)
)、代わりに、時間の経過とともに維持しなければならない特定のIDを参照することは避ける。より将来性のあるアプローチを選択する。動的SQLの書き方についての洞察はこちら、 このビデオを見る. - 上記のリンク先のビデオでは、ロックの防護壁を越えてSQLがどのように動作するかをより深く理解し、SQLがプロジェクトにとって理想的な選択である場合の貴重なヒントを提供している。
- SQLをもっと深く知りたいですか?ロックSQLクラスの受講を強くお勧めします。
- もっと深く知りたいですか?この本を強くお勧めします:T-SQLの基礎。
その他
私たちのチームがSQLを深く掘り下げるにつれ、入門的なものから高度なトピックまで、私たちの洞察をウェブサイトで継続的に共有しています。以下はその一例です。定期的にチェックして、新しいコンテンツをお楽しみください:
- デートを使ったトリック
- SQLの実行順序
- ピボット・パターン
溶岩
Lavaはロック管理者のベルトにある信じられないツールです!プログラミングをすることなく、簡単にデータベースから情報を取り出し、ページに表示することができます。ごく少数の例外(例えば {sql %}。
コマンドと {相互作用の書き込み %}。
コマンド)、LAVAは読み取り専用なので、データが誤って削除されたり編集されたりする可能性を心配する必要はない。
テンプレートを注意深くデザインしないと、パフォーマンスが低下する可能性があります。
フォーマット基準
- SQLと同様に、フォーマットとドキュメントの標準は、読みやすさ、将来のアップデートやトラブルシューティングのために重要です。Lavaスタイルガイドに記載されているガイドラインに従ってください。そして、DotLiquidとFluidの間で留意すべき構文の違いは以下の通りです。
- さらに、設定や変数の宣言は、インラインで埋め込むのではなく、lavaセクションやスクリプトの一番上に置いてください。こうすることで、スクリプトの更新が容易になり、保守性が高まります。
- を使うな。
{コメント}
タグの方が好きです。 //-
そして /- -/
シンタックス - 読みやすくするために、タグにハイフンを付けないでください(例えば
{%- assign ... -%}.
ただし、空白の存在があなたのしていることを壊してしまう場合を除く。ほとんどの場合、空白を追加することは重要ではありません。
パフォーマンスに関する考察
- 気をつけないと、1つのエンティティ・コマンドが数千のデータベース・コールを引き起こす可能性があります。データベースから返されるデータ量を制限するために、エンティティコマンドを使用するときは、式、選択、プリフェッチ属性などの高度なフィルタを使用することを検討してください。また、パフォーマンスを向上させるために、'securityenabled' を false に設定することもできます。
- のようなキャッシュ戦略を使用します。 パーステッド・データセット また、リアルタイムのパフォーマンス向上にも役立つ。使用できるのは
{ベンチマーク
ショートコードは 溶岩ツールプラグイン ラバ・テンプレートのパフォーマンスに関する多くの情報を得るために、異なる戦略を使うかどうかの判断に役立つテンプレートを作成する。 - 流体溶岩エンジンをできるだけ早く使う。
設計上の考慮事項
他の道具と同様、溶岩を最大限に活用するためには、留意すべき点がいくつかある。ここではいくつかの重要な点を挙げてみた。
- 扱っているデータのフィールドタイプを認識し、以下のことを考慮する。 Lavaにおけるデータの存在 と
ヌル
そして 何もない
. - の使用は控えること。
{unless %}。
の最後の実行をチェックする場合を除く。 {に対して %}。
ループだ。
- ショートコードを使用してlavaタグの機能を拡張し、{% include %}タグを使用して複数のページでテンプレートを再利用します。
- ショートコードやインクルードの入れ子は避けましょう。変数のスコープを管理すると、すぐに複雑になります。
- 無償のLava Testerプラグインは、あなたのLavaを実世界のエンティティに対して素早くテストするのに多くの時間を節約することができます。
ウェブ
Rockの核心はウェブサイトです。Rockにはウェブサイト、ページ、ブロックでできるパワフルなことがたくさんありますが、ここでは罠にはまらないように、そしてウェブサイトをできるだけレスポンシブに保つためのガイドラインをいくつか紹介します。
マグナス
Triumphは、VS CodeとAzure Data Studioに深く統合するプラグイン、Magnusの開発に多大な投資をしてきました。Magnusを使用すると、これらの素晴らしいツールから直接Rockのコンテンツやデータを簡単に編集することができます。 Rockインスタンス内のRock ShopでMagnusを探してください。
外部サイト
- Rockをインストールすると、Rockの機能の一部を紹介するためのデフォルトの外部サイトが利用できます。しかし、このサイトはデモンストレーションとして設計されており、あなた自身のウェブサイトの出発点ではありません。
- バージョン・アップデートの際、このサイトでは時折ページや機能の追加や編集を行い、外部サイト用に推奨される機能を最新に保つことができるようにします。特に、まだ使い始める準備ができていない新機能の場合は、実際の外部サイトでこのような変更を行うことはありません!ですから、外部サイトとしてRockを使い始める準備ができたら(または、イベント登録、グループ検索、オンライン寄付などの機能を持つ部分的なサイト)、デフォルトの外部サイトのページを使用するのではなく、訪問者が閲覧できるように全く新しいサイトを作成することをお勧めします。
- もちろん、新しい外部サイトにはデフォルトのStarkテーマとは異なるテーマを使用したいでしょう。私たちは、すべての教会が同じテーマを使い、同じように見えることを望んでいません。
集中テンプレート
- Rockには、テンプレートを一箇所に保存し、複数のブロックで使用するための方法がいくつかあります。最も一般的なものはLavaを使用するもので、インクルードファイルとLavaショートコードです。
- インクルード・ファイルは、ソース・コントロールを使ってデプロイしたり、変更を追跡したりする場合には便利です。推奨されているFluid Lavaエンジンを使用している場合、変数はインクルードファイルとの間で受け渡しできないことに注意することが重要です。
- 一般的には、代わりに Lava Shortcodes にテンプレートを集中させることをお勧めします。これらのショートコードには組み込みのフィールドがあり、どこでどのように使用されることを意図しているのかのドキュメントを提供することができます。
高速ページロード
ロック・システムに存在するすべてのデータは、どこかに保存されなければなりません。ほとんどの場合、データはデータベースに保存されます。しかし、データはRAMにキャッシュすることもでき、その方がサーバーの検索速度がはるかに速くなります。そして、高速なデータ検索は、単にページが速いだけではありません。ここでは、キャッシュについて知っておくべきことを説明します。
- 一般的に、キャッシュされたものはデータベースから一度取得しなければならないが、キャッシュのポイントは、一度データベースからデータを取得したら、同じ情報を取得するために何度もサーバーをデータベースに戻したくないということだ。
- コンテンツチャンネルアイテム/ビューブロックやHTMLコンテンツブロックのようないくつかのブロックには、ブロックによって表示されるデータがキャッシュに保存される期間を制御できる設定があります。一般的に言えば、コンテンツを動的にパーソナライズする Lava がない限り(ページを読み込んでいる人に応じてなど)、これらのブロックのコンテンツは常にキャッシュする必要があります。
- しかし、Lavaを使用できる場所であればどこでも、特定のコンテンツをキャッシュするように指定することもできます。 {キャッシュ %} タグ.これらのタグは、特定のキー(あなたが指定したキー)によって保存され、後で再び検索されるため、非常に強力です。つまり、キャッシュタグを使用する場合、パーソナライズされたコンテンツがあったとしても、そのコンテンツをパーソナライズする内容をキーに含めることができます。たとえば、コンテンツを時間帯に基づいてパーソナライズする場合、キャッシュ・キーに時間帯を動的に含めることができます。
トップページ-ごあいさつ-モーニング
対 フロントページ・グリーティング・アフタヌーン
.そうすれば、コンテンツをカスタマイズする要素が変わらない限り、Rockはキャッシュされたコンテンツを使い続けることができる。しかし、ファクターが変更されるとすぐに、Rockは最新のコンテンツを取得し、新しいタグでキャッシュします。このコンセプトは、ページURLで提供されるパラメータ値など、他の要素でも使用できます。
保守性とアクセシビリティの高いHTML
テンプレートやブロックにHTMLを追加する場合、可能な限りセマンティックマークアップを意識する(使用する)ことをお勧めします。
- これはアクセシビリティの観点から重要です。
<article>
要素はセマンティックなHTMLであり、スクリーン・リーダーのような技術にとって、ページが表示するようにデザインされたメイン・コンテンツを識別するのが非常に簡単になります。のようなセマンティックでないマークアップを使うと、スクリーン・リーダーがこれを理解するのはずっと難しくなります。 <div class="article">
. - また、マークアップをより保守しやすくし、チームの他の人(あるいは半年後の自分自身!)にも読みやすくします。また、セマンティックマークアップにテーマを適用することは、より理にかなっています。
<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の量を減らし、簡素化しましょう。
ジャバスクリプト
Rockはブラウザを使用して一連のウェブページとして表示されるため、もちろんブラウザはページに含める可能性のあるJavaScriptを実行することができます。しかし、コア・ブロックの外観、レイアウト、機能を変更するためにJavaScriptを使用しないことをお勧めします。なぜなら、コア・ブロックは常に変化し、改良されているため、この方法でカスタマイズしようとすると、将来壊れる可能性が高いからです。もし、あるブロックが現在とは異なる方法で動作する必要がある場合は、Rockパートナーと協力してコアブロックのアップデートを行うことをお勧めします。
インテグレーションとエクステンションの選択
ロック・ベスト・プラクティスをお読みいただきましたが、コア・プラットフォームを拡張する方法や提携する組織についても、同じように熟慮してください。
携帯電話のアプリストアにあるアプリケーションがすべて同じ品質(アーキテクチャ、デザイン、メンテナンス、応答性を考える)であるとは限らないように、ロックの拡張機能や統合もすべて同じように作成されるとは限りません。必ず下調べをして、慎重に選んでください。
- 私たちは、サンドボックスサーバ上でテストされ、あなたの省庁のために必要と確認されたプラグインのみをインストールすることをお勧めします。さらに、それらが利用可能になり、あなたがそれらをテストしたように、最新のバージョンにそれらを更新することを確認してください。
- この統合に関するコミュニティ調査を読んで、信頼できる人たちのアドバイスを適用し、利用可能な統合に関するコミュニティのフィードバックを常に最新に保ちましょう。
- Rockエクスペリエンスを構築することと、Rockからデータを取り出して操作したりメンバーとコミュニケーションしたりする統合を追加することの長所と短所を考えてみましょう。Rockをデータウェアハウスとして維持し、深く豊かなパーソナライゼーションを可能にするのではなく、異なるデータベースにデータを「分割」する統合を使用すると、インタラクションや洞察における貴重なデータが失われます。
- 最後に、Rockインスタンスのコンサルティングと開発のパートナーを選ぶ際には、Sparkチームが推奨する質問を必ずしてください。また、各パートナーの専門知識、トレーニング、プロセスを示すアウトプットを確認し、長期的なRock体験に最適な選択をすることをお忘れなく。