Reputation
Top tag
Next privilege 20,000 Rep.
Access 'trusted user' tools
Badges
8 64 133
Impact
~581k people reached

1d
reviewed Reopen Is my mentor's concern for code quality excessive?
1d
reviewed Reopen Does writing tests make sense for visualization software?
1d
reviewed Reopen How to Gauge Junior Developer Knowledge
1d
reviewed Reopen Packaging structure of Java collections (java.util) - why does Iterable sit in java.lang?
Jun
27
awarded  Notable Question
Jun
25
awarded  Great Question
Jun
19
comment How to choose NOT to use a framework (Caliburn.Micro, etc.) in a given MVVM application?
Yeah, I thought that could be the case too. My only real experience with the framework is StackOverflow questions I see on it :)
Jun
19
comment How to choose NOT to use a framework (Caliburn.Micro, etc.) in a given MVVM application?
Honestly I've never used Caliburn Micro, so I feel I am a bad judge of the framework. I recall getting the impression that the View was created first and was responsible for deciding the code-behind objects, which is one aspect I did not like as I don't like View-First development. Another was the automagical bindings that relied on how you Name XAML components, as I thought it tied the UI to the business layer too much. I have heard good things about the framework though, and would not suggest avoiding it just on my opinion. Try it out for yourself and see if you like it :)
Jun
19
comment How to choose NOT to use a framework (Caliburn.Micro, etc.) in a given MVVM application?
I've never used the Caliburn framework because I didn't like how closely it seemed to tie the Views to the Model/ViewModel layer. In your case, I don't see any reason why you couldn't use a RelayCommand from another library if the one used by Caliburn Micro does not work for you.
Jun
19
comment How to choose NOT to use a framework (Caliburn.Micro, etc.) in a given MVVM application?
Personally I pick and choose items out of each framework to use for specific behaviors, and I ignore the rest. For example, I like using Microsoft PRISM's EventAggregator for messaging, and NotificationObject for a ViewModelBase, and MVVM Light's RelayCommand for commands. The important thing is to identify what problems the framework is going to solve for you, and only use those solutions. Don't feel like you're forced to use the entire framework library.
Jun
4
reviewed Close What exactly is “computer systems”?
Jun
4
reviewed Leave Open Java: why do collections accept a Comparator but not (a hypothetical) Hasher and Equator?
Jun
4
reviewed Leave Open Why is .compareTo() in an interface while .equals() is in a class in Java?
Jun
4
reviewed Leave Open Does needing the ability to extend a class at runtime imply poor design?
Jun
4
comment Clean Code comments vs class documentation
@gnat I disagree that this is an exact duplicate of that question. This question is specifically addressing documentation comments and when/how to use them, and there are already some good answers here that address this specific question. The other question is about in-line comments, and even explicitly says it is not about "javadoc style method or class comments". The answers there are tailored to in-line comments, and do not address this specific question. Plus, its closed and locked, so no new information can be added.
Jun
4
comment Clean Code comments vs class documentation
I really appreciate your distinction between inline-code-comments and documentation comments, and the examples given :)
Jun
4
reviewed Leave Open Clean Code comments vs class documentation
Jun
3
comment Is there a name for the anti-pattern of having low-level components controlling higher-level ones?
I don't really think this is a "primarily opinion-based" question, so I've edited it a bit to try and remove any wording that may suggest it is looking for opinions, and am voting to reopen. I also think @KilianFoth is close with the term "high coupling", or "tight coupling". A quick search on "tight coupling programming" gives you plenty of examples and explanations on why programmers try to avoid this, such as this one, although that's more about separating interfaces from implementation, and not necessary about program flow and separation of concerns.
Jun
3
awarded  Informed
Jun
3
revised Is there a name for the anti-pattern of having low-level components controlling higher-level ones?
I don't see anything wrong with this question, so have rearranged things a bit to try and make it less "opinon-based" and am voting to reopen.