|
They seem to explain it pretty well in the doc link you provided[^]:
Quote: The MinimumLevel configuration object provides for one of the log event levels to be specified as the minimum. In the example above, log events with level Debug and higher will be processed and ultimately written to the console.
(highlight is mine).
As a general strategy, I think you would probably have a setting somewhere that changes the minimum log level and you would come up with rules like:
- Verbose level is for all function enrty/exit points
- Debug level is for parameters and results
- Info level is for start/stop of big actions
and so on, and so on...
Mircea
|
|
|
|
|
The reality is that first, regardless of logging library, this is never clear in terms of practical programming.
Additionally keep in mind that a potential exists that different logging levels might impact execution flow.
There are three usage scenarios
- Production
- QA
- Developer
Some would claim that Error/Warn is only appropriate for Production. That however is simplistic and it will not work in non-trivial situations.
That is because for larger systems debugging production problems often requires looking at execution flow. So logging that represents the successful execution of code (trace logging.)
A perfect example of this is a job system or microservice (ms). In production the question will come up as to 'why' the job/request is not being handled. With logging one can see that the job/ms is actually running. Not just a specific requests, but all requests.
Then trace logging shows or doesn't show that a specific request was handled. And how it was handled.
Trace logging would use a log level of 'Info'. So Prod would use Error/Warn/Info.
The claim would (and will) be made that the log level 'Debug' allows one to turn something on in production for more information. But often that doesn't matter because the failure occurred yesterday, so attempting to figure it out today with more logging is seldom going to help.
The 'Debug' level is often used by developers because of this. But developers often do silly things like log only the index of a for variable. So no context just the value. Which makes sense when they are figuring out a problem but will make no sense and likely add a LOT of noise if you really do turn on 'Debug' in production.
Because of that then one must do code reviews to insure at least that Debug logging provides a context and does not cause significant (useless) noise.
All of that then comes back to QA. What should they run? If you actually want to allow Debug logging and it will be turned on in production then you then need to test both with it on and with it off. So testing twice. Both to insure there is not too much noise and that it does not interfere with functionality.
Due to all of that for me I limit all code check ins to Error/Warn/Info. And in practice I haven't even used Warn for a very long time.
Kevin Marois wrote: Exception logging I get, but is this how you would Info and Debug?
Pseudo code for a trace log entry.
Log.Info("CreateRequest: RequestId=<id> AssetId=<assetId> Result=<resultCode>");
And should you log an exception for Info? Yes.
As one example because the exception occurs at a non-critical place. For example if you are collecting metrics in a database like how long an operation took, you do NOT stop the execution flow if there is a database error. But you probably do want to log it.
Kevin Marois wrote: Can someone shed some light?
Also understand that developers and only developers are the target for logging.
There will be requests that Operations, Product Support (customer service) and/or QA 'need' to use it.
If so then those are product requirements. Those people need to create tickets (stories/epics) to specify exactly what they need.
And then QA needs to verify it.
You might or might not use your standard logging for this.
You might also get request from Customers. Such as 'Audit Logging' or 'User login logging'. Those are NEVER implemented using the logging system. Rather it is implemented solely and completely within the product just like any other feature.
|
|
|
|
|
Alright, I thought I'd take up a new hobby project, and use it to try and implement some ideas on domain-driven design. In essense, the project is to develop a "Rigging Designer", that allows civil engineers to define rigging needed to lift heavy objects. I'm struggling a bit with how to implement the ideas of DDD, hence this question.
The hierarchy of domain objects is:
- Lift - a lift operation
- LiftObject - the thing to lift
- Weight - weight of the object, double
- Cog - centre of gravity, position in X, Y, Z
- Liftpoint - point where you can attach rigging, can have up to four
- Id: Id, local to Lift
- Position: position in X, Y, Z
- Hook - a hook, can have up to two
- Position - X, Y, Z position of the hook
- Type: 1, 2, 3, 4 leg hook
- Leg - a leg between a hook, and a piece of rigging, can have up to 4 legs per hook
- Id - Id local to hook
- LiftPointId
The library / app will have two major components: designing consistent lifts (i.e. you can't connect two hooks to the same lift points), and solving them (i.e. calculating the load on legs and hooks).
Alright, that's it for domain knowledge. Now my question: what do I treat as aggregates, entities and value objects? The way I see it now:
- Lift is aggregate, since you can't modify any of the sub objects without needed to see if it is still consistent with the other ones (i.e. changing the cog changes the validity of the lift points). It's also an entity, since we want to be able to model multiple lifts.
- LiftObject is an entity, although I expect that it can never be referenced by more than one lift (since modifying this entity would have implications to all connected lifts)
- Weight and Cog are clear value objects
- Hook is a (local) entity
- Leg is a (local) entity
First question: am I implementing the ideas of DDD correctly.
Now, for my second question. I'll work on this project with a colleague, who will be implementing the solver. I intend to implement the following modules:
- Common - contains interfaces describing the models
- Designer - contains concrete implementations of the models in Common, used for creating and changing the models
- Solver - uses the interfaces in common to calculate the loads on the hooks and legs
Second question: I like the idea of defining interfaces (which are very short and readible) in the Common namespace, which allows me and him to work very independently. However, this means he can't depend on concrete implementations for his unittest, so he has to create mock implementations of the classes. Is this good practice, or just a lot of overhead?
|
|
|
|
|
There's a physical model and a logical model; I don't see you addressing the logic model. ("value objects"?)
You're creating interfaces, and unit tests, while the overall design is still incomplete, IMO. Wouldn't be able to "approve" your plan,
Just what I "see".
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
But MS says it better.
Quote:
... The issue with the MVVM pattern is that it can inadvertently lead to apps that have too many layers and too many allocations.
... But strict adherence to any variation of the pattern can lead to apps with a lot more overhead than can be justified.
... consider putting event handlers in your code-behind ....
MVVM and language performance tips - UWP applications | Microsoft Learn
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
I'm shocked--shocked, I tell you--that MSFT would give a tinker's cuss for performance. For as long as I can remember, it doesn't matter what the hardware folks do to speed up CPUs or increase memory and disk space, because most of the software folks frivolously piss it away. I get the sense, admittedly somewhat superficially, that web-based applications in particular are absolute pigs in excrement when it comes to performance. Does performance still even matter?! If it does, and I wasn't retired, I'd be sorely tempted to find and work with folks who were aiming to blow all of this crapola out of the water.
|
|
|
|
|
Greg Utas wrote: Does performance still even matter?...If it does, and I wasn't retired
It really mattered in the 50/60s whether you used a bubble sort or a binary sort.
For the single application that one would write then.
Now companies do enterprise systems which can contain thousands or even tens of thousands of running instances which have far more serious issues with performance. None of which can be solved with tuning individual lines of code.
Complexity of course drives that. There are many, many other factors that also impact it.
As an example I once increased performance by about 60000% (10 hours to less than 1 minute) by changing requirements. Doubt increasing the CPU by 3% would have had that much impact.
On the other hand I have seen developers spending more than a week 'optimizing' code which would have no impact at all on the user experience.
Not to mention of course business practices that allowed customers to abuse the enterprise to such an extent (by not forcing them to pay for what they were using) that they then started complaining that the system was too slow.
Customers like to complain about performance but often can't even cite what that actually means. And it is very seldom that they are willing to switch product/services because of that. It is the other features that they need/want which drive their decision. Not to mention the cost.
|
|
|
|
|
I agree that optimizing the code is unlikely to help here. The problem is the high-level design, like how the many thousands of instances are supported. The mania for stateless servers that must continually recreate context is another problem.
Poor performance in these types of soft real-time systems usually means one of two things:
1. The response time annoys users.
2. A lot more must be spent on computing equipment than in a system that is better designed.
|
|
|
|
|
So, their "best practice" isn't exactly best practice for performance reasons? Color me "shocked."
|
|
|
|
|
Using a pattern, on purpose, that obscures the power and potential of the platform is beyond not making sense.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Gerry Schmitz wrote: MVVM pattern is that it can inadvertently lead to apps that have too many layers and too many allocations.
Remind me again which pattern is it exactly that guarantees that can't happen?
|
|
|
|
|
You're talking wrappers, frameworks and methodologies (MVVM). A "pattern" can be a simple plug-in that "adds" functionality instead of masking or contorting it.
MVVM is a "bunch" of patterns; all directed to "indirection".
A simple statement like: NO code behind ... is a pattern (of behaviour).
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Ok. But I don't see how that answers my question?
|
|
|
|
|
Quote: Ok. But I don't see how that answers my question?
I gave you an example: a plug-in. Where are the "layers" and "allocations"? One function reference. Are you saying a plug-in is not a pattern? What is a "door"?
Your "argument" is all patterns are "faulty". Back it up.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
And that guarantees that it will not have "too many layers"?
|
|
|
|
|
I'm searching for good, general literature* on how to design and implement access control management. I'd like to build up the knowledge to design a system myself and/or make informed decisions about the architecture of one.
My focus is authorization, not authentication.
*literature = online,offline,free,paid; anything goes.
Some concrete questions could be
- "in which roughness should I store permissions?"
- "in which format should I store my permissions?"
- "should I use RBAC, UBAC, ACL,... and how would I concretely implement them, cleanly?"
- "How do I combine all that with a system that contains several individual organizations with their own set of permissions?"
Does anyone have recommendations? Even a "look in this corner of the internet would help".
(I really cannot find anything useful about this topic. All search results contain the same hipster stuff)
Just to make sure ... what I'm not looking for:
- A cook book.
- Answers that just say "use this or that, because it's the standard"
- Some "hip" book after which you nod, say "yes, aha, I see", but didn't really make you smarter.
|
|
|
|
|
|
Do you have any recommendations of the many?
Also: Be aware that google is very different depending on the country you are searching from and the locale on your computer. You might get better results than linkedIn and companies trying to sell their products - which is what I get.
|
|
|
|
|
D4rkTrick wrote: Do you have any recommendations of the many?
You need to review what you find and decide for yourself which best meets your requirements.
|
|
|
|
|
D4rkTrick wrote: "in which roughness should I store permissions?"
Having considered that many times what I came up with is that you cannot answer that question without business requirements. And probably some business domain knowledge yourself.
Consider these cases...
Who should have permission to edit a social security number at a company? Who should be able to view it?
Contrast that with who should have permission to change the delivery address? Who should be able to view it? (Even more prickly can someone change a delivery address on an order that has already been delivered?)
Should there be a admin (root admin) that can change everything?
Are there assets that will be shared between companies? If so then who sets the permissions? (That was a very real business case that I had to deal with.)
Answering questions like that is FAR more important than how you implement it in general. But it will certainly drive implementation details.
I would be very wary of suggestions that you should 'plan for the future'. For instance in one of many parallel futures you might be asked to add a field on one form, so obviously the solution is that every single field on every form must have a permission from the beginning. And then the users (not developers) who will be actually setting that up will need to understand hundreds of permissions and implications (like what if the social security number is on two different forms?)
I worked for a company with hundreds of permissions. No one knew what they all did. There was also disagreement about what they should do. So those tasked with changing them just had to experiment.
D4rkTrick wrote: "should I use RBAC, UBAC, ACL,... and how would I concretely implement them, cleanly?"
I doubt 'cleanly' exists in any medium size application. And really unlikely when it gets bigger.
So just pick one and look at it in detail.
And then really study how to log changes that users make. All users. Log in this case means to a persistent data store. Adds and updates are easy. Deletes are much harder.
|
|
|
|
|
I didn't mean to try to find the answers here on the board, sorry for the misunderstanding. The questions were merely examples. I'm aware that "clean" or "good" are adjectives that are strongly coupled to the use case.
My main goal is to find good literature.
|
|
|
|
|
I understood that.
I was merely pointing out that there is no general answer. Rather you need to start with the domain space rather than than trying to find one solution.
If you don't have an actual domain space, or perhaps even if you do, then just pick one of the solutions and study it.
|
|
|
|
|
Can't tell if you want to secure a door or an app.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
App 
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
