Related
I would like to implement CQRS and ES using Axon framework
I've got a pretty complex HTML form which represents recruitment process with six steps.
ES would be helpful to generate historical statistics for selected dates and track changes in form.
Admin can always perform several operations:
assign person responsible for each step
provide notes for each step
accept or reject candidate on every step
turn on/off SMS or email notifications
assign tags
Form update (difference only) is sent from UI application to backend.
Assuming I want to make changes only for servers side application, question is what should be a Command and what should be an Event, I consider three options:
Form patch is a Command which generates Form Update Event
Drawback of this solution is that each event handler needs to check if changes in form refers to this handler ex. if email about rejection should be sent
Form patch is a Command which generates several Events ex:. Interviewer Assigned, Notifications Turned Off, Rejected on technical interview
Drawback of this solution is that some events could be generated and other will not because of breaking constraints ex: Notifications Turned Off will succeed but Interviewer Assigned will fail due to assigning unauthorized user. Maybe I should check all constraints before commands generation ?
Form patch is converted to several Commands ex: Assign Interviewer, Turn Off Notifications and each command generates event ex: Interviewer Assigned, Notifications Turned Off
Drawback of this solution is that some commands can fail ex: Assign Interviewer can fail due to assigning unauthorized user. This will end up with inconsistent state because some events would be stored in repository, some will not. Maybe I should check all constraints before commands generation ?
The question I would call your attention to: are you creating an authority for the information you store, or are you just tracking information from the outside world?
Udi Dahan wrote Race Conditions Don't Exist; raising this interesting point
A microsecond difference in timing shouldn’t make a difference to core business behaviors.
If you have an unauthorized user in your system, is it really critical to the business that they be authorized before they are assigned responsibility for a particular step? Can the system really tell that the "fault" is that the responsibility was assigned to the wrong user, rather than that the user is wrongly not authorized?
Greg Young talks about exception reports in warehouse systems, noting that the responsibility of the model in that case is not to prevent data changes, but to report when a data change has produced an inconsistent state.
What's the cost to the business if you update the data anyway?
If the semantics of the message is that a Decision Has Been Made, or that Something In The Real World Has Changed, then your model shouldn't be trying to block that information from being recorded.
FormUpdated isn't a particularly satisfactory event, for the reason you mention; you have to do a bunch of extra work to cast it in domain specific terms. Given a choice, you'd prefer to do that once. It's reasonable to think in terms of translating events from domain agnostic forms to domain specific forms as you go along.
HttpRequestReceived ->
FormSubmitted ->
InterviewerAssigned
where the intermediate representations are short lived.
I can see one big drawback of the first option. One of the biggest advantage of CQRS/ES with Axon is scalability. We can add new features without worring about regression bugs. Adding new feature is the result of defining new commands, event and handlers for both of them. None of them should not iterfere with ones existing in our system.
FormUpdate as a command require adding extra logic in one of the handler. Adding new attribute to patch and in consequence to command will cause changes in current logic. Scalability is no longer advantage in that case.
VoiceOfUnreason is giving a very good explanation what you should think about when starting with such a system, so definitely take a look at his answer.
The only thing I'd like to add, is that I'd suggest you take the third option.
With the examples you gave, the more generic commands/events don't tell that much about what's happening in your domain. The more granular events far better explain what exactly has happened, as the event message its name already points it out.
Pulling Axon Framework in to the loop, I can also add a couple of pointers.
From a command message perspective, it's safe to just take a route and not over think it to much. The framework quite easily allows you to adjust the command structure later on. In Axon Framework trainings it is typically suggested to let a command message take the form of a specific action you're performing. So 'assigning a person to a step would typically be a AssignPersonToStepCommand, as that is the exact action you'd like the system to perform.
From events it's typically a bit nastier to decide later on that you want fine grained or generic events. This follows from doing Event Sourcing. Since the events are your source of truth, you'll thus be required to deal with all forms of events you've got in your system.
Due to this I'd argue that the weight of your decision should lie with how fine grained your events become. To loop back to your question: in the example you give, I'd say option 3 would fit best.
Updating can performance test script e.g. with LoadRunner can take a lot of time and be quite frustrating. If there has been some updates with the applications, you usually have to run the script and then find out what has to be changed, update and run again and so on. Does anyone have some concrete best practices how to ease this updating inferno? One obvious thing is good communication with developers.
It depends on the kind of updates. If the update is dramatic, like adding new fields for user to fill in, then, someone has to manually touch up the test scripts.
If, however, the update is minor, for example, some changes to the hidden fields or changes to the internal names of user-facing fields, then it's possible to write a script that checks the change and automatically updates the test script.
One of the performance test platforms, NetGend, automatically takes care of the hidden fields and the internal names of user-facing fields so it's very easy to create a script to performance-test a HTML form. Tester only needs to fill in the values that he/she would have to enter using a browser, so no correlation is necessary there. Please send me a message if you need to know more about it.
There are many things you can do to insulate your scripts from build to build variability. The higher up the OSI stack you go the lower the maintenance charge, but the higher the resource cost for the virtual user type. Assuming changes are limited to page level resources and a few hidden fields here and there for web sites or applications, then you can record in HTML mode. You blast the EXTRARES sections as the page parser in HTML mode will automatically parse the page and load the page resources even without an explicit reference - It can be a real pain to keep these sections in synch if you have developers who are experimenting quite a bit.
Next up, for forms which have a very high velocity in terms of change consider the use of a web_custom_request() for the one form. You can use correlation statements to pick up all of the name|value pairs as needed and build the form submit dynamically. There will be a little bit more up front work for this but you should have pay offs at around the fourth changed build where you would normally have been rebuilding some scripts.
Take a look at all of the hosts referenced in your code. Parameterize all of these items. I have a template that I use for web virtual users which pairs a default value and the ability to change any of the host names via the control panel extra attributes section. Take a look at the example for lr_get_attrib_string() for how you might implement the pickup and pair that with a check for NULL and a population with a default value in your code
This is going to seem counter intuitive, but comment your script heavily for changes that are occurring often so you know where to take the extra labor change up front to handle a more dynamic data set.
Almost nothing you do with any tool can save you from struuctural changes in the design and flow of the app, such as the insertion of a new page in the workflow, but paying attention to the design on the high change pages, of which there are typically a small number, can result in a test code with a very long life.
Of course if your application is web services based then there is a natual long life to the use of exposed public services. Code may change on the back end of the service, but typically the exposed public interface is very stable.
over time our information strategy has gone all over the place and we are looking to have a clearer policy and a more explicit way for everyone to be in sync on information sharing. Some things to note is that the org is 300+ people and is in multiple countries across the world. Also, we have people that are comfortable in Sharepoint, people that are comfortable in confluence, etc so there is definately a "change" factor here
Here are our current issues and what we are thinking about doing about them. I would love to hear feedback, suggestions, etc.
The content we have today:
Technical design info / architecture docs
Meeting minutes, action items, etc
Project plans and roadmaps
organization business mgmt info - travel, budget info, headcount info, etc
Project pages with business analysis, requirements, etc
Here are some of our main issues:
Where should data go - Confluence WIKI versus Sharepoint versus intranet site - we use confluence WIKI for #1, #2, #3, #5 but we also use sharepoint for #1, #3, #4, #5. We are trying to figure out if we should mandate each number to a specific place to make things consistent. We are using Sharepoint more a directory structure of documents, and we are using confluence for more adhoc changable content.
Stale Data - this is maybe a cultural thing with the org but at certain points in time data just becomes stale and is no longer relevant. What is the best way to ensure old data doesn't create a lot of noise and to ensure that the latest correct data is up to date. Should there be people in the org responsible for this or should it be an implicit "everyones job". This is more of an issue when people leave, join, etc . .
More active usage - whats is the best way to get people off of email and trying to stop and think "could this be useful for others . . let me put it in a centralized place instead of in email chains" . .
also, any other stories of good ways to improve an org's communication and information management
A fundamental root cause of information clutter is "no ownership".
People are assigned to projects. The projects end (or are cancelled), the people move on and the documents remain behind to gather "dust" and become information clutter.
This is hard to prevent. The wiki vs. sharepoint doesn't address the clutter, it just shifts the technology base that's used to accumulate clutter.
Let's look at the clutter
Technical design info / architecture docs. Old ones don't matter. There's current and there's irrelevant. Wiki.
Last year's obsolete design information is -- well -- obsolete.
Meeting minutes, action items, etc. Action items become part of someone's backlog in a development sprint, or, they're probably never going to get done. Backlogs are wiki items. Everything else is history that might be interesting but usually isn't. If it didn't create a sprint backlog items, update an architecture, or solve a development problem, the meeting was probably a waste of time.
Project plans and roadmaps. The sprint backlog matters -- this is what a "plan and roadmap" aspires to be. If you have to supplement your plans with roadmaps, you probably ought to give up on the planning and just use Scrum and just keep the backlog current.
The original plan is someone's guess at project inception time, and not really very interesting to the current project team.
Organization business mgmt info - travel, budget info, headcount info, etc. This is a weird mixture of highly structured stuff (budget, organization) and unstructured stuff ("travel"?)
How much history do you need? None? Wiki at best. Financial or HR System is where it belongs. But, in big organizations, the accounting systems can be difficult and cumbersome to use, so we create secondary sources of information like a SharePoint page with out-of-date budget numbers because the real budget numbers are buried inside Oracle Financials.
Project pages with business analysis, requirements, etc. This is your backlog. Your project roadmap and your requirements and your analysis ought to be a single document. In the wiki.
History rarely matters. Someone's concept at project inception time of what the requirements are doesn't matter very much any more. What the requirements evolved to in their final form matters far more than any history. This is wiki material.
How old is 'too old'?
I've worked with customers that have 30-year old software. The software -- obviously -- is relevant because it's in production.
The documentation, however, is all junk. The software has been maintained. It's full of change control records. The "original" specifications would have to be meticulously rewritten with each change control folded in. Since the change control documents can be remarkably pervasive, the only way to see where the changes were applied is to read the source and -- from that -- reverse engineer the current-state specification.
If we can only understand a 30-year old app by reverse engineering the source, then, chuck the 30-year old pile of paper. It's useless.
As soon as maintenance is done, the "original" specification has been devalued.
How to clean it up?
If you create the wiki page or sharepoint site, you own it forever.
When you leave, your replacement owns it forever.
Each manager is 100% responsible for every piece of information their staff creates. They have to delete things. The weak solution is to "archive" stuff. Which is just a polite way of saying "delete" without the "D-word".
Cleanup must be every manager's ongoing responsibility. If they can't remember what it is, or why they own it, they should be required (or "encouraged") to delete it. Everything unaccessed in the last two years should be archived without question. Everything 10 years old is just irrelevant history.
It's painful, and it doesn't appear to be value-creating work. After all, we work in IT. Our job is to "write" software, not delete it. No one will do it unless compelled on threat of firing.
The cost of storage is relatively low. The cost of cleanup appears higher.
How to stop the email chain?
Refuse to participate. Create a "Break the Chain" campaign focused on replacing email chains with wiki updates (or sharepoint updates).
Be sure your wiki provides links and is faster to edit than an email.
You can't force people to give up a really, really convenient solution (Email). You have to make the wiki more valuable and almost as convenient as email.
Ramp up the value on the wiki. Deprecate email chains. Refuse to respond to email chains. Refuse to accept "to do" action items through email.
You can use Confluence Wiki for storing documents as attachements and have the Wiki's paths work as the file paths in Sharepoint.
Re: stale data: have ownership of the data (both person and team) and ensure that deliverables for the owners include maintenance of ALL the data.
As far as "Off email", this is hard to do as you can't force people to do this short of actively monitoring all email... but you can try some deliverables with metrics regarding content added to the Wiki. That way people would be more likely to want to re-use the work already done on the email to paste into Wiki to meet the "quota" instead of composing fresh stuff.
Our company and/or team used all 3 of these approaches with some degree of success in the past
Is there a reason not to have the wiki hold the files?
Also, perhaps limiting the mail server to not allowing attachments on internal emails is too draconian, but asking folks to put everything in the wiki that needs to be emailed more than once is pretty darn useful.
Efficient information management is indeed a very hard problem. We found that "the simpler the better" principle can make miracles to solve it.
Where should data go - we are big believers of the wiki approach. In fact, we use Confluence for sharing possibly every type of information, except really large binary files. For those, we use Dropbox. Its simplicity is an absolutely killer feature. (Tip: you can integrate them with the Dropbox in Confluence plugin.)
Finding stale data - in our definition, stale data is something that is not updated or viewed for a specific period of time. The Archiving Plugin of Confluence can quickly and automatically find these, then report them to the authors and administrators, who may potentially update them (or remove them, see next item). There is, of course, information that never expires, but the plugin is able to skip them after you mark the corresponding pages.
Removing stale data - we are fairly aggressive on this. If the data is not (highly) relevant anymore, clean it up now! We can safely follow this practice, because we never actually delete data. We just move outdated data to hidden archive spaces using, again, the Archiving Plugin. If we changed our mind later, it is very easy to find it in the the archive, view it or even to recover it.
More active usage - our rule: if the information is required to be persistent, don't email it. Put it to a wiki page instead. The hard thing for some people is to find the best location for the information (which space? where in the page hierarchy?). Badly organized spaces with vague scope are another big efficiency divider, unfortunately. Large companies may consider introducing a wiki gardener to cure this.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
What should a good BugTracking tool be capable of?
Although there is a large set of features that a bug tracker can have I feel like it is a little overkill and was considering rolling out my own solution. With that being said I didn't want to remove any core functionality that might be used frequently with existing solutions.
The ones I can think of so far:
- creating bugs
- assigning bugs
- closing bugs
- adding description to the bug
Thanks!
Communication between the developer and the user.
Ability for the user to assign certain bits of information such as severity (how much that bug relates to them).
Ability for the developer to override that priority and, if possible, give a reason.
Ability to assign tasks to a developer.
Ability to sort between bug, enhancement, and feature request. The difference between an enhancement and feature request is very subtle but VERY important.
Ability to attach files (such as screen shots)
Ability to have custom fields (such as being able to select which OS, which service pack level, application version, etc).
Ability to have custom user profiles which also give detailed information about their hardware. It's also nice to be able to have the users phone number (if they are on your LAN) so you can ask questions, if needed.
Privacy. Some items, such as security exploits or information that deals with financial information, will need to be kept secret. Even OSS does this from time to time until they can get a patch ready. Everyone has their own rules.
Ability to show the changes between revisions so you can email out a Change Log so users know what you have and have not done.
Reminders about which items are left undone and are assigned to you / unassigned at all.
That's all I can think of...
A good search engine.
It's amazing how many bug tracking products that cost thousands of dollars get this horribly wrong.
Without a really decent search your bug tracking is more like a "bug logging" - log and forget - system which is pretty much useless.
create a bug
close a bug
this is sufficient for closure over the life-cycle of a 'bug' entity. Whether it is enough features for your purpose is another matter.
Take a look at the features of Mantis, choose the features that you need, calculate how long it would take you to write them, and then spend your time on something more useful unless you absolutely have to create your own. ;-)
For most systems like a bug tracking one, it's usually not the creation or editing of the data that makes the system useful. It all comes down to how easily you can navigate through the information to 'add-value' on top of just collecting the data.
Think about the people who will use the system, the programmers, managers, etc. For each group of people, what type of information will make it worth their while to come back to the system over and over again. How can you make it easier for them to get this information?
Collecting information is easy, adding value to it is the hard part.
Paul.
A bug tracker is nothing more than a list of things that need to be done.
It can be as simple as a text file in the software's directory to a fully fledged bug tracker with hundreds of users.
Start with what you need to work with, then expand as needed.
Use Jira, you'll be in good hands.
Here are some important features:
Assign priority to bug (e.g. critical, major, medium, minor, trivial)
Assign bug to a specific release in which it will be fixed
Watcher functionality (so you can be e-mailed when the status changes)
Workflow (i.e. who is working on it, what's the status)
Categorization, Prioritization, and Standardization.
And an easy way to query it so that you can reap the rewards of your hard work on the above three.
Also, make sure whatever you do is extensible! We always decide to add/edit our bug templates during the project depending on needs/fires.
There are a lot of great solutions out there, you probably don't need to roll your own.. But either way you're going to have to make the same decisions. We use a solution that allows us to roll our own templates, so at the beginning of every project we revisit this same discussion.
FWIW: When we rolled our own request tracking system, we built it around procmail and our existing internal web authentication system because we wanted it to be extremely unobtrusive to use: we just send e-mails to the developers (using group aliases if we want) and add a "[t]" to the subject to open a ticket. The recipients get a modified e-mail with the original request and an additional link to the web page that displays the ticket and allows them to close it with 1 mouse click. So the most common tasks are performed through the e-mail client (opening, requesting more information, replying, ...), although there is also a simple web interface for searching etc.
It took only a few hours to write and after more than 34000 request tickets in 7 years or so, I guess it's OK to claim that it has only the essential core features:
create a ticket (by e-mail with marked subject)
close a ticket (clicking on the link in the e-mail, then clicking on "done")
all communication goes over e-mail, not through a web interface(!)
people who were recipients or sender of the original e-mail (opening ticket) are notified about closed tickets ("Subject: <old subject> closed by <someone>" + link to ticket in the body, enough information for most people so they don't have to go look which ticket/bug that was etc.)
a simple web interface provides a search function for own/open/sent/team tickets
Notable absent features that might be needed for a bigger development team / more intense software development:
flexible status for the tickets (dupe, wontfix, reopened etc.)
priorities
reassigning tickets explicitly (in our dev team, the e-mail just gets resent to the unlucky guy who has to do it)
adding comments to the ticket that don't get sent to everyone
assigning the bug to a particular version of the software
YMMV, but it has worked very well for us so far, both for bugs and for simple requests that the sender wants to keep track of.
Define bug.
Thinking about that will most likely make you realize that you're gonna spend a lot of time "rolling your own".
This might be a little beyond what you had in mind, but for me, integration with source control is a must-have. To be able to view the diffs between versions associated with a bug/issue is very handy.
Please please please don;t spend much time "rolling your own". Your time is better spent researching and learning to use real tracking systems.
Some to look at
Trac, Bugzilla and FogBugz. The last one has free hosted solution for small (one or two man shops?) companies.
SO has lots of threads about this topic.
Try not to roll your own unless it is just a word doc or a spreadsheet. Any time you spend making your own is a TOTAL waste.
EDIT
Since you won't be dissuaded, then I'll maybe add some things others have not mentioned.
You need reporting functionality - users need to be able to run queries and they should be able to select the fields they want to "view".
Workflow/lifecycle of a defect is also a good feature. (basically a state machine of the states the defect will go through. ) In fact, this is a useful exercise for you to define all your use cases and functionality. Given that you are in college and did not start out as aa CS major, I doubt you will come up with many on your own. Take some time to browse the feature lists and demos of existing products.
Ability for emails to be sent to various interested parties.
Anonymous users able to see a SPECIFIC defect that they entered
Different access levels and authorities (admin, manager, developer, tester, end-user)
Our bug tracking system is one of the two essential links between my company and our customers ("live" product reviews where existing customers are encouraged to suggest improvements and user interface tweaks being the other).
A bug tracking system must, first and foremost, encourage trackable "dialogs" with your customers. It must answer the question "Have you fixed the problem (defined broadly) that I have been having yet?"
It must have (in no particular order):
A short description of the problem or feature request (the title)
Room for an extended description
The ability to attach files/images (screenshots)
The ability to prioritize bugs/features
The ability to categorize entries as bugs, features, inquiry, etc.
The ability to assign bugs/features to areas (UI, database, documentation, etc.)
he ability to assign bugs/features to products (we track bugs on five products)
The ability to assign bugs/features to releases ("to be fixed in version 5.1")
The ability to assign bugs/features to people (developers/writers)
The ability to assign bugs/features to customers (reporters)
The ability to re-assign to a different person (developer)
The ability to Resolve bugs/features (mark them as finished and ready for testing)
The ability to mark resolution status (fixed, won't fix, can't reproduce, etc.)
The ability to Close bugs/features (take them off list after resolution & testing)
The ability to Reopen bugs/features (restore to "Open" if testing fails)
The ability to inform customers the bug has been resolved (e.g. via email)
Date and Time stamp on every step (Open, Resolve, Close, Re-open)
The ability to report on the number of Open bugs! (how close to release are we?)
The ability to show bug reports versus resolutions
The ability to search on bugs/features by date, priority, product, person, etc.
The ability to list and sort bugs for easy scanning!
Those are the things that we typically use in our system (FogBugz). While this may seem like a long list, we really do use every feature that I've listed here!
On a particular project we're working with a total of 10 team members.
After about a year working on the project (and using Mantis as a bug-/feature-tracker eversince), the bugtracker gets more and more difficult to use, as no standard has been setup that explains how to create new tasks, how to comment tasks etc. This leads to multiple entries for the same bugs, inability to easily find bugs when searching for them etc.
How do you organize your bugtracker? Do you use a lot of (sub)categories for different portions of your application (GUI, Backend etc), do you use tags in the title of tasks (i.e. "[GUI][OptionPage] The error")?
Is anyone in your team allowed to introduce new tasks or is this step channeled through a single "Mantis-master" (who would then know whether a new report is a duplicate or an entirely new entry)?
Always link a version control system commit to an issue and back so that you know which commits were made do solve which issue and why a certain commit was done.
What we did is to introduce a role for approve entries to the bug tracker. This role can be shared by different people. The process is either to approve, to approve with a small edit, or to reject the entry with the request for further editing or clarification.
It is better for the general understanding if the role is not given to people working in the (core) team.
In a "large" mantis system on the open web, I've seen the rules go something like
New: Anyone can enter a bug.
Acknowledged: A select few people can upgrade it to this level. These people have seen every new bug for a while, and thus they'll know if it's a duplicate. Or they can pass it back to the reporter for clarification until they understand it well enough to do this job.
Confirmed: Set by decision makers who basically say "We will be doing this".
I don't actually remember where it was, and more importantly I don't know how well it worked.