21,552 reputation
657101
bio website
location Toronto, Canada
age
visits member for 3 years, 9 months
seen 9 hours ago

"Enterprise" developer/architect with an EE background and experience/interest in:

  • Microsoft .NET / Visual Studio
  • Delphi
  • VB/VBA (although I try to forget)
  • SQL Server, SQL CE
  • Web Services (SOAP, WSE, WCF)
  • Web Applications (WebForms, MVC, JS)
  • Embedded Systems (HCxx, PIC, etc.)
  • UI Design & Data Visualization
  • Project Management
  • and probably a bunch of other things...

9h
comment Programming for future use of interfaces
The builder is unnecessary here (and quite frankly, an overused/over-recommended pattern in general); there are no complex rules around how the parameters need to be set up, so a parameter object is perfectly fine if there's a legitimate concern over the method parameters being complex or frequently-changed. And I agree with @BenAaronson, although the point of using a parameter object is not to include the unnecessary parameters right off the bat, but make them very easy to add later (even if there are multiple interface implementations).
Jul
2
awarded  Curious
Jun
25
comment So Singletons are bad, then what?
@Pacerier: The fundamental basis of the singleton pattern is its absolute and exclusive control over object lifetime. The instance cannot be created or destroyed by anyone else, lest it invalidate the guarantees made by a singleton. So yes, this is a matter of definition; an instance with a public destructor is ipso facto not a true singleton.
Jun
25
comment So Singletons are bad, then what?
@Pacerier: No, they aren't. Read the answer. The Singleton pattern is intended to have an object lifetime equivalent to the application itself. Therefore, it can't be freed. (Of course, in non-GC'ed languages it can be freed, but it is illegal to do so.) Please feel free to link to a Singleton implementation that permits this behaviour if you disagree.
Jun
20
awarded  Great Answer
May
17
comment I am making 4-5x more story points than average, but producing bugs at half the rate. Graphs say it's 2x more bugs, how to deal with that?
This is relative and rather subjective, isn't it? I don't know what "regular" code means. I would argue that top programmers attempt to utilize all the libraries and language constructs available to them to their maximum benefit in terms of productivity and expressiveness, which should make the code very easy to understand by other high-functioning programmers... but could in fact be extremely difficult to understand by junior to intermediate programmers, particularly those who are not familiar with the more advanced architectural concepts, control flow, data structures...
May
16
comment I am making 4-5x more story points than average, but producing bugs at half the rate. Graphs say it's 2x more bugs, how to deal with that?
Your third paragraph is actually a misinterpretation of the statistics. Bug rates are fairly constant across programming languages, but not across programmers. And in fact the highest-performing programmers are not only more productive but also produce far fewer bugs. If you're producing 2x as many bugs per LOC or function point then it means you're not actually 5-10x as productive, you're simply trading correctness and design quality for speed, and wasting other devs' time on reviewing the bugs that don't slip through. As Brandon says, slow down!
Apr
30
comment What's wrong with circular references?
@BlueRaja-DannyPflughoeft: I consider that an anti-pattern, as do many other practitioners of DI, because (a) it's not clear that a property is actually a dependency, and (b) the object being "injected" can't easily keep track of its own invariants. Worse, many of the most sophisticated/popular frameworks like Castle Windsor can't give useful error messages if a dependency can't be resolved; you end up with an annoying null reference instead of a detailed explanation of exactly which dependency in which constructor couldn't be resolved. Just because you can, doesn't mean you should.
Apr
15
awarded  Good Answer
Apr
9
comment Why is “Select * from table” considered bad practice
This is utter nonsense. String comparisons are used everywhere in practice, and they're not slow. The fastest databases available today are distributed hash tables that take strings as keys. I can assure you that I'm very fussy about performance and know a whole lot about optimization, and the penalty for string comparisons vs. primitive type comparisons is completely irrelevant in every instance except maybe for operating systems and microcontroller software. The primary factor in performance is I/O; secondary is the computational complexity, e.g. O(N²) vs. O(N).
Apr
8
awarded  Good Answer
Apr
8
comment Why is “Select * from table” considered bad practice
No other points that I can think of - this pretty much covers it. Too bad my +1 can't put this over the crap that the OP accepted way too quickly...
Apr
8
comment Why is “Select * from table” considered bad practice
You've got to be kidding me. The string comparisons are several orders of magnitude less expensive than the actual database operation. The fact that you would even suggest that this matters one whit in practice is proof positive that you've never even attempted to profile it.
Apr
6
comment Why do projects opt to stay on an older version of the .NET Framework?
Being 5-10 years old usually is a pretty good reason. If it were a car, it would be out of warranty. It's a similar situation with software; unless releases are very slow/infrequent, it's probably no longer supported or only minimally supported as a legacy product. If there's any notion of plugins or integration, most of it probably won't work on the old version. And lack of updates means that potentially serious security flaws or other show-stopping bugs haven't been fixed and might never be. And of course, as you mention, going up 1 version now is far less expensive than 3 versions later.
Apr
6
comment Why do projects opt to stay on an older version of the .NET Framework?
I've never heard this quote from Pournelle. Are you sure you're not referring to "perfect is the enemy of good"?
Apr
6
answered Strategy for storing passwords/credentials in the context of continuous delivery
Apr
6
comment If TDD is about design why do I need it?
How can it not be what you're saying? Your answer starts with the phrase, TDD doesn't only help me come to the best final design.... I don't care about the rankings of answers, I just happened to be brought back to this question due to an inbox alert. I think your answer would be fine if it didn't use the phrase "the best", that's all.
Apr
6
comment Why is “Select * from table” considered bad practice
Really? You think accessing columns by index instead of by name is a good idea because it's faster? Talk about micro-optimization... you're talking about queries that are, at minimum, on the order of several milliseconds, and you're saving maybe a dozen CPU instructions at the very high cost of any kind of maintainability. Hard-coding column indexes is "an error waiting to happen" - doing SELECT * is almost never going to affect the correctness of any half-decently designed program.
Apr
6
comment Why is “Select * from table” considered bad practice
This is a better answer than the accepted one (at time of writing this comment), but it still misses the most important point, which is that retrieving all columns virtually guarantees that no index will ever cover the entire query. The "overhead" of a few extra columns is nothing compared to the overhead of doing table scans, index scans, and bookmark lookups instead of faster seeks/range scans/skip scans.
Apr
6
comment Why is “Select * from table” considered bad practice
Terrible answer. Almost none of the major frameworks today care about having extra columns in the result set. Even if you don't use a framework, most of the time SELECT * should work - I mean, you are referencing columns by name, and not by index, aren't you? Index-based mapping is just bad. There are plenty of reasons not to use SELECT *, but this isn't one of them.