I have been having some difficulties differenciation the two recently. More specificly I have browsed stackoverflow and there is a statement that Events can be named in two different ways:
with "ing" or with past tense "ed". This can be seen here Events - naming convention and style
https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/names-of-type-members
At the same time the CQRS states that names need to be in past tense and then following their guidelines the events named above with "ing" form would be commands. This gets me a bit confused? Do events mean different things in depending on the architectural context and movement. Is there a unified view on what an event and command is ?
CQRS you've been reading only had past-tense event names likely because they didn't consider pre-events. A command commands something to happen, and as such is typically formed in imperative ("click!", "fire!", "tickle!"). It makes no sense for a command to be a gerund ("clicking! clicking faster, you! or I fires you!") As it precipitates an action, it will likely trigger one or more notifications (=events) that something of note is about to happen, and afterwards that something of note did happened.
-ing events (e.g. ("Clicking") happen before the event is handled, e.g. in case someone wants to stop it. Sometimes, they are called "before" events (e.g. "BeforeClick"), or "will" events ("WillClick").
-ed events (e.g. "Clicked") happen after the event is handled, e.g. in order to affect dependents. Sometimes, they are called "after" events (e.g. "AfterClick") or "did" events ("DidClick").
Which specific scheme you follow does not really matter, as long as you (and your team, and your potential partners) are consistent about it. Since CQRS (under that name) is largely a Microsoft thing, follow what Microsoft says. Should you code for Mac, the concepts are similar - but you'd do well to go with the Apple guidelines instead.
Is there a unified view on what an event and command is ?
Unified? No, probably not. But if you want an authoritative definition, Gregor Hohpe's Enterprise Integration Patterns is a good place to start.
Command Message
Event Message
Within the context of CQRS, you should consider Greg Young's opinion to be authoritative. He is quite clear that command messages should use imperative spellings, where events use spellings of changes that completed in the past.
Names of Commands and Events should be understood to be spelling conventions -- much in the same way that the spellings of URI, or variable names, are conventions. It doesn't matter at all for correctness, and the computer is for the most part not looking at the spelling (for example, we route messages based on the message name, not by looking at the verb tense).
Events describe a change to the state of a model; all events are ModelChanged. However, we prefer to use domain specific spellings for the type of the event, so that they can be more easily discriminated: MouseClicked, ConnectionClosed, FundsTransfered, and so on.
Use of the present progressive tense spelling for an event name is weird, in so far as the message is a description of the domain model at the point of a transaction, where the present tense semantically extends past that temporal point. More loosely, present progressive describes a current state, rather than a past change of state.
That said, finding a good past tense spelling for pre-events can be hard, and ultimately it is just a spelling convention; the work required to find an accurate spelling that is consistent with the past tense convention may not pay for itself compared to taking a natural but incorrect verb tense.
Related
If one is attempting to build a desktop program with a semi-complex GUI, especially one in which users can open multiple instances of identical GUI components such as having a "project" GUI and permitting users to open multiple projects concurrently within the main window, is it good practice to push the event listeners further up the widget hierarchy and use the event detail to determine upon which widget the event took place, as opposed to placing event listeners on each individual widget?
For example, in doing something similar in a web browser, there were no event listeners on any individual project GUI elements. The listeners were on the parent container that held the multiple instances of each project GUI. A project had multiple tabs within its GUI, but only one tab was visible within a project at a time and only one project was visible at any one time; so, it was fairly easy to use classes on the HTML elements and then the e.matches() method on the event.target to act upon the currently visible tab within the currently visible project in a manner that was independent of which project it was that was visible. Without any real performance testing, it was my unqualified impression as an amateur that having as few event listeners as possible was more efficient and I got most of that by reading information that wasn't very exact.
I read recently in John Ousterhout's book that Tk applications can have hundreds of event handlers and wondered whether or not attempting to limit the number of them as described above really makes any difference in Tcl/Tk.
My purpose in asking this question is solely to understand events better in order to start off the coding of my Tcl/Tk program correctly and not have to re-code a bunch of poorly structured event listeners. I'm not attempting to dispute anything written in the mentioned book and don't know enough to do so if I wanted to.
Thank you for any guidance you may be able to provide.
Having hundreds of event handlers is usually just a mark that there's a lot of different events possibly getting sent around. Since you usually (but not always) try to specialize the binding to be as specific as possible, the actual event handler is usually really small, but might call a procedure to do the work. That tends to work out well in practice. Myself, my rule of thumb is that if it is not a simple call then I'll put in a helper procedure; it's easier to debug them that way. (The main exception to my rule is if I want to generate a break.)
There are four levels you can usually bind on (plus more widget-specific ones for canvas and text):
The individual widget. This is the one that you'll use most.
The widget class. This is mostly used by Tk; you'll usually not want to change it because it may alter the behaviour of code that you just use. (For example, don't alter the behaviour of buttons!)
The toplevel containing the widget. This is ideal for hotkeys. (Be very careful though; some bindings at this level can be trouble. <Destroy> is the one that usually bites.) Toplevel widgets themselves don't have this, because of rule 1.
all, which does what it says, and which you almost never need.
You can define others with bindtags… but it's usually not a great plan as it is a lot of work.
The other thing to bear in mind is that Tk supports virtual events, <<FooBarHappened>>. They have all sorts of uses, but the main one in a complex application (that you should take note of) is for defining higher-level events that are triggered by a sequence of low-level events occasionally, and yet which other widgets than the originator may wish to take note of.
I'm learning cqrs/event sourcing, and recently I listen some speach and speaker told that you need pass as few parameters to event as possible, in other words to make events tiny as possible. The main reason for that is it's impossible to change events later as it will break the event history, and its easelly to design small events correctly. But what if for example in UI you need fill in for example form with 10 fields to create new aggregate, and same situation can be with updating the aggregate? How to be in such a case? And how to be if business later consider to change something, but we have huge event which updating 10 fields?
The decision is always context-specific and each case deserves its own review of using thin events vs fat events.
The motivation for using thin domain events is to include just enough information that is required to ensure the state transition.
As for fat events, your projections might require a piece of entity state to avoid using any logic in the projection itself (best practice).
For integration, you'd prefer emitting fat events because you hardly know who will consume your event. Still, the content of the event should convey the information related to the meaning of the event itself.
References:
Putting your events on a diet
Patterns for Decoupling in Distributed Systems: Fat Event
recently I listen some speach and speaker told that you need pass as few parameters to event as possible, in other words to make events tiny as possible.
I'm not convinced that holds up. If you are looking for good ides about designing events, you should review Greg Young's e-book on versioning.
If you are event sourcing, then you are primarily concerned with ensuring that your stream of events allows you to recreate the state of your domain model. The events themselves should be representations of changes that a domain expert will recognize. If you find yourself trying to invent smaller events just to fit some artificial constraint like "no more than three properties per event" then you are going to end up with data that doesn't really match the way your domain experts think -- which is to say, technical debt.
I'm trying to help my team streamline a data ingestion process that is taking up a substantial amount of time. We receive data in multiple formats and with attributes arranged differently. Is there a way using RapidMiner to create a process that:
Processes files on a schedule that are dropped into a folder (this
one I think I know but I'd love tips on this as scheduled processes
are new to me)
Automatically identifies input filetype and routes to the correct operator ("Read CSV" for example)
Recognizes a relatively small number of attributes and arranges them accordingly. In some cases, attributes are named the same way as our ingestion format and in others they are not (phone vs phone # vs Phone for example)
The attributes we process mostly consist of name, id, phone, email, address. Also, in some cases names are split first/last and in some they are full name.
I recognize that munging files for such simple attributes shouldn't be that hard but the number of files we receive and lack of order makes it very difficult to streamline a process without a bit of automation. I'm also going to move to a standardized receiving format but for a number of reasons that's on the horizon and not an immediate solution.
I appreciate any tips or guidance you can share.
Your question is relative broad, so unfortunately I can't give you complete answer. But here are some ideas on how I would tackle the points you mentioned:
For a full process scheduling RapidMiner Server is what you are
looking for. In that case you can either define a schedule (e.g.,
check regularly for new files) or even define a web service to
trigger the process.
For selecting the correct operator depending on file type, you could
use a combination of "Loop Files" and macro extraction to get the
correct type and the use either "Branch" or "Select Subprocess" for
switching to different input routes.
The "Select Attributes" operator has some very powerful options to
select specific subsets only. In your example I would go for a
regular expression akin to [pP]hone.* to get the different spelling
variants. Also very helpful in that case would be the "Reorder
Attributes" operator and "Rename by Replacing" to create a common
naming schema.
A general tip when building more complex process pipelines is to organize your different tasks in sub-processes and use the "Execute Process" operator. This makes everything much more readable and maintainable. Also a good error handling strategy is important to handle unforeseen data formats.
For more elaborate answers and tips from many adavanced RapidMiner users, I also highly recommend the RapidMiner community.
I hope this gives a good starting point for your project.
Events in an event store (event sourcing) are most often persisted in a serialized format with versions to represent a changed in the model or schema for an event type. I haven't been able to find good documentation showing the actual model or schema for an actual event (often data table in event store schema if using a RDBMS) but understand that ideally it should be generic.
What are the most basic fields/properties that should exist in an event?
I've contemplated using json-api as a specification for my events but perhaps that's too "heavy". The benefits I see are flexibility and maturity.
Am I heading down the "wrong path"?
Any well defined examples would be greatly appreciated.
I've contemplated using json-api as a specification for my events but perhaps that's too "heavy". The benefits I see are flexibility and maturity.
Am I heading down the "wrong path"?
Don't overlook forward and backward compatibility.
You should plan to review Greg Young's book on event versioning; it doesn't directly answer your question, but it does cover a lot about the basics of interpreting an event.
Short answer: pretty much everything is optional, because you need to be able to change it later.
You should also review Hohpe's Enterprise Integration Patterns, in particular his work on messaging, which details a lot of cases you may care about.
de Graauw's Nobody Needs Reliable Messaging helped me to understan an important point.
To summarize: if reliability is important on the business level, do it on the business level.
So while there are some interesting bits of meta data tracking that you may want to do, the domain model is really only going to look at the data; and that is going to tend to be specific to your domain.
You also have the fun that the representation of events that you use in the service that produces them may not match the representation that it shares with other services, and in particular may not be the same message that gets broadcast.
I worked through an exercise trying to figure out what the minimum amount of information necessary for a subscriber to look at an event to understand if it cares. My answers were an id (have I seen this specific event before?), a token that tells you the semantic meaning of the message (is that something I care about?), and a location (URI) to get a richer representation if it is something I care about.
But outside of the domain -- for example, when you are looking at the system as a whole trying to figure out what is going on, having correlation identifiers and causation identifiers, time stamps, signatures of the source location, and so on stored in a consistent location in the meta data can be a big help.
Just modelling with basic types that map to Json to write as you would for an API can go a long way.
You can spend a lot of time generating overly complex models if you throw too much tooling at it - things like Apache Thrift and/or Protocol Buffers (or derived things) will provide all sorts of IDL mechanisms for you to generate incidental complexity with.
In .NET land and many other platforms, if you namespace the types you can do various projections from the types
Personally, I've used records and DUs in F# as a design and representation tool
you get intellisense, syntax hilighting, and types you can use from F# or C# for free
if someone wants to look, types.fs has all they need
I've noticed that error messages tend to be written in a handful of common styles. Either in full-form, casual-friendly sentences, or in shortened passive ones that don't always form a full sentence. The latter of the two seems to be the more common - though maybe not as common as the haphazard mixing of styles that I see in a lot of applications.
Does anyone include error messages in their style guide? I'm more curious about opinions on the consistent grammatical construction of these things than about the content of them, which has already been discussed.
Both the iPhone Human Interface Guidelines and the Apple Human Interface Guidelines contain sections on alerts.
Also, the Windows User Experience Interaction Guidelines have information for a few different types of dialogs, including error messages.
(iPhone)
As you compose the required alert title:
Keep the title short enough to display on a single line, if possible.
A long alert title is difficult for
people to read quickly, and it might
get truncated or force the alert
message to scroll.
Avoid single-word titles that don’t provide any useful information, such
as “Error” or “Warning.”
When possible, use a sentence fragment. A short, informative
statement is often easier to
understand than a complete sentence.
Don’t hesitate to be negative. People understand that most alerts
tell them about problems or warn them
about dangerous situations. It’s
better to be negative and direct than
it is to be positive but oblique.
Avoid using “you,” “your,” “me,” and “my” as much as possible. Sometimes,
text that identifies people directly
can be ambiguous and can even be
interpreted as an insult.
Use title-style capitalization and no ending punctuation when:
The title is a sentence fragment
The title consists of a single sentence that is not a question
Use sentence-style capitalization and an ending question mark if the
title consists of a single sentence
that is a question. In general,
consider using a question for an alert
title if it allows you to avoid adding
a message.
Use sentence-style capitalization and appropriate ending punctuation for
each sentence if the title consists of
two or more sentences. A two-sentence
alert title should seldom be
necessary, although you might consider
it if it allows you to avoid adding a
message.
If you provide an optional alert message:
Create a short, complete sentence that uses sentence-style
capitalization and appropriate ending
punctuation.
Avoid creating a message that is too long. If possible, keep the message
short enough to display on one or two
lines. If the message is too long it
will scroll, which is not a good user
experience.
Avoid lengthening your alert text with descriptions of which button to
tap, such as “Tap View to see the
information.” Ideally, the combination
of unambiguous alert text and logical
button labels gives people enough
information to understand the
situation and their choices. However,
if you must provide detailed guidance,
follow these guidelines:
Be sure to use the word “tap” (not “touch” or “click” or “choose”) to
describe the selection action.
Don’t enclose a button title in quotes, but do preserve its
capitalization.
-
(Mac)
Alert message text. This text, in emphasized (bold) system font, provides a short, simple summary of the error or condition that summoned the alert. This should be a complete sentence; often it is presented as a question. See “Writing Good Alert Messages” for more information.
Informative text. This text appears in the small system font and provides a fuller description of the situation, its consequences, and ways to get out of it. For example, a warning that an action cannot be undone is an appropriate use of informative text.
A good alert message states clearly what caused the alert to appear and what the user can do about it. Express everything in the user’s vocabulary.
To make the alert really useful, provide a suggestion about what the user can do about the current situation. Even if the alert serves as a notification to the user and no further action is required, provide as much information as needed to describe the situation.
-
(Microsoft)
The characteristics of good error messages
In contrast to the previous bad
examples, good error messages have:
A problem. States that a problem occurred.
A cause. Explains why the problem occurred.
A solution. Provides a solution so that users can fix the problem.
Additionally, good error messages are
presented in a way that is:
Relevant. The message presents a problem that users care about.
Actionable. Users should either perform an action or change their
behavior as the result of the message.
User-centered. The message describes the problem in terms of target user
actions or goals, not in terms of what
the code is unhappy with.
Brief. The message is as short as possible, but no shorter.
Clear. The message uses plain language so that the target users can
easily understand problem and
solution.
Specific. The message describes the problem using specific language,
giving specific names, locations, and
values of the objects involved.
Courteous. Users shouldn't be blamed or made to feel stupid.
Rare. Displayed infrequently. Frequently displayed error messages
are a sign of bad design.