Reputation
6,784
Top tag
Next privilege 10,000 Rep.
Access moderator tools
Badges
3 21 30
Newest
 Nice Answer
Impact
~181k people reached

Jul
27
comment Why is filesystem preferred for logs instead of RDBMS?
@Andy and where did I say that it was ok to pretend everything is fine? There is a difference between continuing as best you can with restrictions in place, exiting gracefully, and crashing. Boy, do you assume a lot.
Jul
27
comment Why is filesystem preferred for logs instead of RDBMS?
@Andy, Read back my original comments again and then tell me where I am applying dogma. As far as I can tell, I am asking questions. You on the other hand are the one making assumptions and statements based on those assumptions. The only relevant point you made was that the file system is moot when you are logging to a remote db. My counter point would have been that when you are logging remote, the manner in which that log service stores the log messages should not be a concern of the sender It should just call some API. And then for that "logger" machine we are back to the original issue.
Jul
26
comment Why is filesystem preferred for logs instead of RDBMS?
@Andy yes, whether you like it or not, error recovery is part and parcel of developing applications. Out of disk space and programs running out of memory may not occur as frequently as they once used to do, but that doesn't mean they are in the realm of "acceptable to crash over". Rationalization doesn't come into it.
Jul
26
comment Why is filesystem preferred for logs instead of RDBMS?
@Andy out-of-disk space is a normal operating condition, not an exception (even though you may be made aware of it through a run time exception). That is not what I consider a file system failure. A file system failure is when the file system fails to operate at all, regardless of the amount of available disk space.
Jun
28
comment ASP.NET user control best practices, programmatically or markup?
+1 I don't know who downvoted you, but I certainly upvoted. Very nice overview! Bookmarked.
May
22
comment Using prefix/postfix increment operator for simple incremental array access rather than actual index numbers
+1, Would add another one for the correct application of DRY principle (avoiding repeat of knowledge, not avoiding repetition per se)
May
22
comment Class design for an app that reads data from Active Directory
Design your app for what it needs to do. Hide the AD details behind wrappers that just expose what your app needs. These wrapper classes will also serve as a perfect "insulation" seam allowing you to unit test all of your app without any dependency on AD (except for the wrappers themselves). In other words: treat AD as you would a database.
May
22
comment Call method in a disposable object at the beginning of a “using” statement
? While I understand the intention of your example, how/where is CollectionUpdateContext<T>.UpdatingCollection being called? Did you perhaps intend UpdatingCollection to be the constructor of CollectionUpdateContext<T>?
May
22
comment C# obtain derived class from base
+1 for the overload approach, but your WidgetToJavaScriptConverter instance could be called from a simple loop without the added indirection of a visitor pattern.
May
22
comment C# obtain derived class from base
You could construct a parallel hierarchy of javascript generating classes and then use a dictionary or other "linking" mechanism to first register and later select the correct javascript generating class for each widget class. ("Is there a way to loop through all the widgets, but determine what type of widget it is?" - TypeOf() method?)
May
19
comment Advantage/Disadvantage of having all variables declared in a JUnit Test
+1 for the case you make. And test code should be production grade code. That said, DRY is not so much about not repeating yourself at all. It is about not repeating knowledge. The DRY principle is stated as “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.” (en.wikipedia.org/wiki/Don%27t_repeat_yourself). The misunderstandings arise from "repeat" I think, as does: hermanradtke.com/2013/02/06/misunderstanding-dry.html
May
19
comment Advantage/Disadvantage of having all variables declared in a JUnit Test
+1 absolutely, but please bear in mind that DRY is less about avoiding repeating code than it is about not repeating knowledge. See hermanradtke.com/2013/02/06/misunderstanding-dry.html. The Dry principle is stated as "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system." en.wikipedia.org/wiki/Don%27t_repeat_yourself
May
19
comment Advantage/Disadvantage of having all variables declared in a JUnit Test
@CandiedOrange: DRY is less to do with avoiding code duplication than it is about avoiding the duplication of knowledge (facts, rules, etc). See: hermanradtke.com/2013/02/06/misunderstanding-dry.html The Dry principle is stated as "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system." en.wikipedia.org/wiki/Don%27t_repeat_yourself
May
15
answered Unit-testing on higher levels of architecture
May
9
comment Do I need to use an interface when only one class will ever implement it?
Found a perfect use case for an interface implemented by a single class just now, in this thread: programmers.stackexchange.com/questions/281979/…
May
9
comment Is my usage of explicit casting operator reasonable or a bad hack?
You could avoid the copying by using an ISmallObject interface implemented by BigObject and simply return a reference to this in the ToSmallObject implementation.
May
9
comment Is my usage of explicit casting operator reasonable or a bad hack?
This sounds like a perfect use case for an ISmallObject interface which is only implemented by BigObject as a means to provide access to a limited set of its extensive data/behavior. Especially when combined with @Telastyn's idea of a ToSmallObject method.
May
9
answered Application plugin system - interfaces - adding new features
May
9
comment Do I need to use an interface when only one class will ever implement it?
How about the only class implementing that interface does more than just implement that particular interface and you don't want the code needing only the methods of said interface to have access to the rest of the public methods of the class. For eaxmple classes that implement both "immutable" and "mutable" behavior and you want most of your code to have an extra "insulation" layer between them and the methods that change an instance's state (insulation provided by having to "ask" whether the "mutable" interface is supported) so it is easy to spot the code that messes with state.
May
4
comment Web API Design advice
"which seems to be going against RESTful approach or dealing with resources?" you are confusing resources with entities. A resource can consist of many attributes and sub objects containing lists as well. The same way that a view is not restricted to any particular entity. You can structure your resources any way you see fit given the needs of your application. Considering that you plan to use this thing in many places, I would certainly opt for a single resource that pulls everything together for me.