定期的なイベントをサポートするイベント スケジューリング システムの構築を任されたとしたら、どのようにしますか? 定期的なイベントが削除された場合、どのように処理しますか? 将来の出来事がいつ起こるかをどうやって知ることができますか?
つまり、イベントを作成するときに、「毎日繰り返す」(または毎週、毎年など) を選択できます。
回答ごとに 1 つのデザインをお願いします。Ruby/Railsには慣れていますが、デザインを表現したいものは何でも使ってください。
面接でこう聞かれたのですが、なかなかいい返事ができませんでした。
注：ここですでに質問/回答されています。しかし、以下に詳述するように、より実用的な詳細を取得したいと考えていました。
Martin Fowler によって概説されているように、いくつかの一時的な表現を実装することから始めました。これにより、スケジュールされたアイテムが実際にいつ発生するかを把握できます。これは非常にエレガントな方法です。私が最終的に得たのは、記事の内容を積み上げただけです。
次の問題は、表現を世界でどのように格納するかを考え出すことでした。もう 1 つの問題は、式を読み上げたときに、それほど動的ではないユーザー インターフェイスにどのように適合するかということです。式を BLOB にシリアル化するだけの話もありましたが、式ツリーをたどってその意味を知るのは難しいでしょう。
解決策 (私の場合) は、ユーザー インターフェイスがサポートする限られた数のケースに適合するパラメーターを格納し、そこからその情報を使用してその場で時間式を生成することです (最適化のために作成されたときにシリアル化できます)。そのため、Schedule クラスには、オフセット、開始日、終了日、曜日などのいくつかのパラメーターが含まれることになり、そこから時間式を生成して難しい作業を行うことができます。
タスクのインスタンスを持つことに関しては、N 日間のタスクを生成する「サービス」があります。これは既存のシステムへの統合であり、すべてのインスタンスが必要であるため、これは理にかなっています。ただし、このような API を使用すると、すべてのインスタンスを保存せずに繰り返しを簡単に予測できます。
@Joe Van Dykは、「将来を見て、今後のイベントがいつになるかを確認できますか？」と質問しました。
イベントの次のn回の発生を表示/表示する場合は、a ）事前に計算してどこかに保存するか、b）その場で計算して表示する必要があります。これは、どの夕方のフレームワークでも同じです。
a）の欠点は、どこかに制限を設け、その後b）を使用する必要があることです。そもそもb）を使うだけで簡単です。
スケジューリングシステムはこの情報を必要とせず、次のイベントがいつであるかを知る必要があるだけです。
プロジェクトのデータベースの終わりを管理していたとき、私は以前にこれをしなければなりませんでした。各イベントを個別のイベントとして保存するように要求しました。これにより、オカレンスを1つだけ削除することも、スパンを移動することもできます。1つのオカレンスを変更して、2つに変換するよりも、複数を削除する方がはるかに簡単です。次に、繰り返しの情報を含むrecurrenceIDを持つ別のテーブルを作成することができました。
私の頭のてっぺんから（タイピング/思考中にいくつかのことを修正した後）：
必要な最小再発解像度を決定します。それがアプリの実行頻度です。多分それは毎日、多分5分ごとです。
定期的なイベントごとに、最新の実行時間、実行間隔、および必要に応じて有効期限などの他の機能を保存します。
アプリが実行されるたびに、すべてのイベントがチェックされ、（today / now + recurrenceResolution）と（recentRunTime + runInterval）が比較され、一致する場合はイベントが発生します。
イベントを保存するときは、スケジュールをストアに保存します (これを「Schedules」と呼びましょう。次にイベントがいつ発生するかを計算し、それも「Events」などに保存します。次に、 「イベント」を見て、次のイベントがいつ行われるかを把握し、それまでスリープ状態にします。
アプリが「ウェイクアップ」すると、イベントが再び発生するタイミングが計算され、これが「Events」に再度格納されてから、イベントが実行されます。
繰り返す。
スリープ中にイベントが作成されると、スリープが中断され、再計算されます。
アプリがスリープ イベントなどから起動中または回復中の場合は、「イベント」で渡されたイベントを確認し、それに応じて対処します (見逃したイベントをどうしたいかによって異なります)。
このようなものは柔軟で、不必要な CPU サイクルを必要としません。
何年も前に自分用にカレンダー アプリを作成したとき、基本的には cron からスケジューリング メカニズムを盗み出し、それを定期的なイベントに使用しました。たとえば、1 月を除く毎月第 2 土曜日に行われる何かには、"repeat=* 2-12 8-14 6" という命令が含まれます (毎年、2 ～ 12 月、第 2 週は 8 日から 14 日まで、曜日に 0 ベースの番号付けを使用したため、土曜日には 6 です)。
これにより、特定の日付にイベントが発生するかどうかを簡単に判断できますが、「N 日ごと」の繰り返しを処理することはできず、UNIX に精通していないユーザーにとっては直感的ではありません。
個々のイベント インスタンスと削除/再スケジュールの一意のデータを処理するために、イベントがどれだけ計算されたかを追跡し、結果のイベントをデータベースに保存しました。オリジナルの再発イベント情報。新しい定期的なイベントが追加されると、既存の「最後に計算された」日付まで、すべてのインスタンスがすぐに計算されました。
これが最善の方法であるとは言いませんが、これは方法であり、前述の制限内で非常にうまく機能する方法です。
毎日、毎週、または週に数日などの単純な繰り返しイベントがある場合、スケジューラ/cron/at 機能で buildt を使用することの何が問題になっていますか? 実行可能/コンソールアプリを作成し、いつ実行するかを設定しますか? 複雑なカレンダー、イベント、時間管理は必要ありません。
:)
//W