Is it possible to trigger an event only when there are multiple actors in the trigger volume?
For example a background music starts playing only if there are two specifically tagged actors placed at a trigger volume?
Yes, it is possible, but you have to count the number of overlapping actors somewhere. I think the simplest solution is to create your own "trigger volume" by adding a collision box to a new actor and listening to the "begin overlap" and "end overlap" events.
Once your actor has counted enough overlaps you can start your background music or whatever it is that you want to do.
Related
Problem
I am trying to create a single ICS file containing multiple events without a pattern but have them behave as a series. By making them behave as a series, I am hoping to have options such as "RSVP/delete this and all future events". These events are copies of each other except the dates.
I know that it is possible to add multiple VEVENT items in a single file but the problem with this approach is that they behave as separate events. So features like "delete this and all future events" don't work.
What I have tried
The other approach is creating a recurring event with daily frequency and marking the days without events as EXDATES. The problem with this one is that calendars like Google and Outlook show this event as "Daily", which can cause confusion.
It is probably not recommended to group multiple events without pattern but I was wondering if there is a way to either have them behave as a series or fix the "Daily" text in calendars if EXDATE approach is used.
at the moment, I am learning Event Sourcing. I used CRUD for a long time now and I guess I'm still kinda stuck in the CRUD-way.
Well, now to my question:
I event-sourced a part of my application, where I create something called a Job. A Job can have:
title
description
created_at
So creating this Job is easy - but what do I do when it comes to updating?
Is it an anti pattern to dispatch an event like JobUpdated, which contains changes to the title and possibly the description? Or should I dispatch multiple events like:
JobTitleChanged
JobDescriptionChanged
In this particular case, where Updated events seem to be the best you can do, a lot will come down to whether it's more common for one of title or description to be edited or for them to be edited together. If the former, specific field updates (e.g. JobTitleUpdated) are better, as they at least allow for consumers which don't care about the title field to easily ignore those events, but if a particular transaction issues both JobTitleUpdated and a JobDescriptionUpdated events, the context that those events were in the same transaction is difficult to reliably reconstruct from the separate events.
In general, Updated events aren't particularly rich: they capture what changed, but lose other context (most often the why). In a hotel, for instance, you could have a RoomStatusUpdated event (e.g. RoomStatusUpdated(VacantDirty)), but there are a lot of different reasons for that, so it might be better to have GuestCheckedIn, GuestCheckedOut, RoomCleaned, RoomOutOfOrder etc. events.
I'm trying to simulate a movie theater. Movies start and end at specified times, no matter when a customer arrives and sits down. I want to be able to start and end the delay by time based units, kicking everyone out at the same time (once the movie is over)
I've tried googling - because I am a student and this was way too ambitious to try but I really wanted to. I'm literally hoping for any kind of insight
Select output, 4 different services (not ped), ped go to, then all same sink
I want it to work and it doesn't
Try thinking of your movie as an agent. Each movie can have its own event, which you could set to go off at a specific calendar date/time. In the action of the event, you could send a message to all your customers that they can now leave the theater...or, if your customers are in a queue with a hold block for that particular movie, you can just unblock the hold.
With movies as agents, you could have a start/end time and then create your population of movies from a database linked to Excel. That is, you would be able to set up your movie schedule outside of AnyLogic, which would probably be easier for whoever your stakeholders are.
Your question is probably too broad to answer fully in stack overflow. There are a million different ways to model a movie theater, and approach would depend on what you are trying to answer, animation requirements, your comfort level with programming, user interface requirements, etc.
I have recently been building an application on top of Greg Young EventStore as my peristance layer and I have been pondering how big should I allow an event to get?
For example I have an UK Address Aggregate with the following fields
UK_Address
-BuildingName
-Street
-Locality
-Town
-Postcode
Now I'm building the UI using React/Redux and was thinking should I create a single FAT addressUpdated Event contatining all the above fields?
Or should I Create a event for each of the different fields? and batch them within the client until the Save event is fired? buildingNameUpdated Event, streetUpdated Event, localityUpdated Event.
I'm not sure if the answer is as black and white ask I have asked it what I really would like to know is what conditions/constraints could you use to make the decision?
should I create a event for each of the different fields?
No. The representations of your events are part of the API -- so you want to use spellings that make sense at the level of the business, not at the level of the implementation.
Now I'm building the UI using React/Redux and was thinking should I create a single FAT updateAddress Event containing all the above fields?
You don't need to constrain the data that you send to your UI to match that which is in the persistence store. The UI is just a cached representation of a read model; there's no reason that representation needs to have the same form as what is in your event store.
Consider the React model itself -- your code makes changes to the "in memory" representation of your data, and then the library computes the new DOM and replaces it, which in turn causes the browser to update its view, which in turn causes the pixels on the screen to change.
So taking a fat event from the store, and breaking it into field level events for the UI is fine. Taking multiple events from the store and aggregating them into a single message for the UI is also fine. Taking events from the event store and transforming them into a spelling that the UI will recognize is also fine.
Do you have any comment regarding Arien answer regarding keeping fields that need to be consistent together? so regardless of when your snapshop the current state of the world it would be in a valid state?
I don't believe that this makes sense, and I'm not sure if it is possible in general.
It doesn't make sense, because "valid state" is a write model concern only; events are things that have happened, its too late to vote on whether they are valid or not. For instance, if you deploy a new model, with a new invariant, it still needs to respect the history of what happened before. So you can build a snapshot for that new model, but the snapshot may not be "valid". Too bad.
Given that, I don't think it makes sense to worry over whether each individual event in a commit leaves the snapshot in a valid state.
In particular, if a particular transaction involves multiple entities, it is very likely that the domain language will suggest an event for each entity (we "debit cash" and "credit accounts receivable"). The entities themselves, of course, are capable of changing independently of each other -- it's the aggregate that maintains the balance.
You have to bundle al the information together in one event when this data has to be consistent with each other.
So when you update one field of an address you probably get an unwanted address.
This will happen when the client has not processed all the events at a certain time due to eventual consistency.
Example:
Change address (City=1, Street=1, Housenumber=1) to (City=2, Street=2, Housenumber=2)
When you do this with 3 events and you have just processed one at the time of reading you could get the address: (City=2, Street=1, Housenumber=1).
If puzzled, give a try to a solution that is easier to implement. I guess "FAT" event will be easier: you will end up spending less time for implementing/debugging/supporting.
It is usually referred as YAGNI-KISS-Occam's Razor principles.
In theory and I find it to be a good rule of thumb is to have your commands and events reflecting the intent of the user staying true to DDD. You can find a good explanation of the pros and cons about event granularity here: https://medium.com/#hugo.oliveira.rocha/what-they-dont-tell-you-about-event-sourcing-6afc23c69e9a
What happens, if I send multiple ShellToast notifications from background agent at once, for example in ToDo list app I want to notify that 3 tasks should be finished today?
Is it allowed or recommended? Would the user see all three toasts or only the first one?
The scheduled agent only runs once and it's up to you to manage which toast will be shown. In those scenarios you should be using a counter...possibly.
The way I've worked around this sort of thing in the past is just track a time or which toasts have been shown in sort of a queue and just show one every update so you could just rotate through your queue throughout the day until the tasks in app are no longer valid. Or, based on the phone's time, determine what to show (they fire every 30 min or so).
Ultimately, the optimal way is probably having one toast that says "You have 3 tasks to complete" etc etc.
Hope one of those solutions might help!
// Jed