Reputation
44,547
Next tag badge:
150/100 score
16/20 answers
Badges
13 111 202
Newest
 Nice Answer
Impact
~1.4m people reached

Feb
2
awarded  Nice Answer
Jan
21
awarded  Nice Answer
Jan
12
awarded  Nice Answer
Jan
11
comment Keeping git and TFS projects in sync
Don't get me wrong, it is possible. But you're going to have to manage it carefully. The merge process pulling from TFS can be laborious, when you have multiple merges in TFS and multiple merges in Git. I would avoid the problem, if you can. Why can't those devlopers use the same Git repository as everyone else?
Jan
11
comment Keeping git and TFS projects in sync
Brutal. Yeah, git-tfs is your way forward. Don't get it confused with git-tf, which struggles with certain edge cases. And don't let anyone commit directly to TFS; that'll cause you issues you don't want to deal with.
Jan
11
comment Keeping git and TFS projects in sync
That explains why you wouldn't use TFS. Why not settle on Git projects on a TFS server?
Jan
11
comment Keeping git and TFS projects in sync
Why would you complicate your workflow like that? Why not choose one or the other?
Jan
11
answered Interface Segregation Principle: What to do if interfaces have significant overlap?
Jan
10
awarded  Yearling
Dec
17
comment How to Code Faster (Without Sacrificing Quality)
@AndresCanella Every answer in this question is basically a long comment. You're right, there's a lot to discuss. This really isn't a good format for discussion (nor is it intended to be). But it was a good question to start with, which is why it's closed and marked as Community Wiki -- for which no one gets reputation points -- rather than deleted.
Nov
22
comment Creating database connections - Do it once or for each query?
@AlexVPerl: I'd need to profile and see evidence that a) there is an actual saving in not returning the connection to the pool and b) that cost isn't a result of hitting the max connection pool (cause, if it did, then any saving would mean a cost elsewhere -- potentially even timeouts waiting for a connection). I'd also need to know that there weren't any other costs, like problems caused by connections dropping between calls. I'd also need to be worried about millisecond-level efficiency savings. An unlikely use-case, but never say never.
Oct
6
awarded  Nice Answer
Sep
10
awarded  Good Answer
Sep
6
awarded  Nice Answer
Sep
2
awarded  Nice Answer
Aug
14
awarded  Nice Answer
Aug
10
comment Is that good idea to add ViewModel exactly same as Model
@MehdiDehghani: It's not as simple as yes or no, it's more that the security issues with direct access to data model are rare and easily coded around. If security were the only reason to use a View Model, I would suggest other solutions (server-side validation, for example). But I'd recommend a ViewModel for decoupling and it will, almost incidentally, help you protect your data model.
Aug
9
comment Is that good idea to add ViewModel exactly same as Model
@MehdiDehghani: Security isn't really a good reason to separate the two objects. The best reason is that the model as viewed in the UI (possibly in multiple formats) is not necessarily the same as the model stored in the database (never in multiple formats and more likely to "model" the business). Even if they look the same now, they are likely to diverge as an application scales; it's better to handle them separately, so there's no temptation to force one model into the other when that time comes.
Aug
6
answered are technical user stories allowed in scrum
Jul
30
comment What if the “catch” block is empty - “{}”
@Wilman: Whilst I agree that never is a strong word, NEVER catch (Exception) and swallow it. That will catch OutOfMemoryException, for example, which really should be thrown up to a handler at the top level. If you want to catch a specific kind of exception and swallow it then a comment is enough -- but that should be a rare case.