3,419 reputation
926
bio website
location
age
visits member for 3 years, 5 months
seen Nov 16 at 12:29

Jan
10
comment Creating huge decision tree
That's an interesting idea but I'm afraid it won't help. My conditions in this DSL would be long, long lines with lots and lots of asterisks. If we found the problem originates in input modules, there's no point analyzing any of 50 or so output module conditions, and vice versa - although at any point in analysis these two origins the data may finally point to power supply, or timing, or... you get the idea.
Jan
10
comment Creating huge decision tree
@DocBrown: Most conditions (nodes) will be based on unique, singular variables. Things like finding whether a message of specific type appears or not in the message queue (estimate queue length 100 messages), then analyzing the payload of the message, internal state flags, database entries etc. You can safely assume 70% of inputs will appear within only one node each in the tree. Great most of test conditions will need to be hand-crafted. So think rather 70 variables and many of them not readily available but to be extracted from unfriendly sources.
Jan
9
comment Is looking at random code snippets useful to quickly determine the quality of a project?
It helps, sure, but it doesn't determine the overall quality. A brilliant programmer working under stupid manager will write great code for awful architecture of the project. Each module will be great but the way they interact will be an unfixable bottleneck. You need a broader look besides checking code quality.
Jan
9
comment Creating huge decision tree
The structure doesn't really have to be a tree from the developer's point of view - may be flattened into independent strings of clauses leading to conclusions, but multiple re-evaluating the same topmost conditions (often involving SELECTs etc) over each leaf isn't really acceptable, so the actual compiled result should be more tree-like. Yes, a DSL is the answer, now the question is what should it look like. Also, with flat strings of conditions we lose perspective on how clauses conflict, interact or leave us with dead ends (undefined leaves). (still, maybe visualizing that is possible?)
Jan
9
comment Creating huge decision tree
@lorus: Modifying source is okay. Still, each node has unique meaning, which must be understandable - trivially readable by the developer, and each end result is a certain combination of these (usually logical AND), and its path should be easily readable and reasonably modifiable too. Note that 100 nodes isn't too much in a fairly flat multi-branched tree maybe 2-3 nodes deep. Not if its structure is resembling more a balanced binary tree. I wouldn't call a 7-level nested if() a maintainable structure...
Jan
9
comment if ('constant' == $variable) vs. if ($variable == 'constant')
@crazy2be: Speak for yourself. CppCheck currently warns against this kind of errors and saved my neck a couple times. If you mean assignment, it suggests extra pair of parentheses, if((q=!p)) goes without warning.
Jan
9
asked Creating huge decision tree
Jan
9
accepted Representing a rule in a ruleset
Jan
4
comment Representing a rule in a ruleset
Actually, yes, in essence you could say that - but it would be quite narrowly specialized (so broad, general DSL rules would apply only marginally) and this question pertains to internal representation of its fundamental tokens. If we have a simple engine at the core, we can start building syntax and features from there. This is to work in resource-limited environment and on a budget, so no "let's think up some fancy syntax and then write a complex compiler and a sophisticated engine for that", but rather "get a working engine, add some rudimentary user-friendliness when it's done.")
Jan
4
asked Representing a rule in a ruleset
Jan
4
comment Are immutable/stateless singletons bad?
I really wonder what real-life scenario could require this kind of feature.]
Jan
4
comment Root cause analysis in event correlation
As I wrote, "tokenized", I meant the logs are primarily machine-readable, and only then parsed into something user-readable. Bit flags denoting conditions of specific detection points etc. I can read internal state of the main module but must depend on (tokenized) messages of external modules. Reinventing the wheel may be necessary because this is to work on an embedded device, JBoss is far, far too heavyweight. Adding a lightweight interpreter of some programming language might be viable but I'm afraid it still may be too much.
Jan
4
comment Are immutable/stateless singletons bad?
@StampedeXV: Yes, a stateful singleton certainly. A stateless and immutable one - I'd be really curious to hear any examples but I'm not holding my breath.
Jan
4
answered Are immutable/stateless singletons bad?
Jan
4
asked Root cause analysis in event correlation
Jan
2
answered How to effectively do manual debugging?
Jan
2
comment How to effectively do manual debugging?
1. Eliminate half the possible causes. Problem vanishes. 2. Restore that half, and eliminate the other. Problem vanishes. 3. Eliminate only few possible causes. Problem vanishes if you eliminate any arbitrary 20% of them. 4. Start examining performance, underlying engine and running in circles. 5. Panic.
Dec
21
awarded  Nice Answer
Dec
21
comment Are all security threats triggered by software bugs?
A chance of a computer system corrupting the permission bits on random files is entirely possible. A file that is globally writable and SUID root can be trivially edited to elevate user permissions.
Dec
21
comment Are all security threats triggered by software bugs?
@DocBrown: Yes - sometimes reduction of security is required as cost-performance tradeoff...