|
Fair enuff Ruff! I would write silly things in 104F too. 
Life is too shor
|
|
|
|
|
megaadam wrote: I would write silly things in 104F
Silliness and profundity: another polarity bound by a strange attractor; another phenomenon so altered by the act of observation that whether the observer is scratched by the half-dead kitty, or the half-alive kitty, is ... a toss-up.
cheers, Bill
«There is a spectrum, from "clearly desirable behaviour," to "possibly dodgy behavior that still makes some sense," to "clearly undesirable behavior." We try to make the latter into warnings or, better, errors. But stuff that is in the middle category you don’t want to restrict unless there is a clear way to work around it.» Eric Lippert, May 14, 2008
|
|
|
|
|
BillWoodruff wrote: 104F degree heat
Anyone know what that is in real money?
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Because he can't handle irony?
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
megaadam wrote: I misread your post completely
You are not alone.
Three different reads of the same words, there, Bill. For comedy/irony, you need to be really tight.
6/10 Must try harder
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Mark_Wallace wrote: Three different reads of the same words
The only thing I infer from three interpretations is that three interpreters were naive enough to assume there is any interpretation possible, most likely without ever reading the article by Hoffman, and actually thinking about it.
"Wisdom tells me I am nothing. Love tells me I am everything. Between the
two, my life flows." Nisargadata
«There is a spectrum, from "clearly desirable behaviour," to "possibly dodgy behavior that still makes some sense," to "clearly undesirable behavior." We try to make the latter into warnings or, better, errors. But stuff that is in the middle category you don’t want to restrict unless there is a clear way to work around it.» Eric Lippert, May 14, 2008
|
|
|
|
|
Y'know, I used to talk to people like that (almost precisely, but with more big words, more Milton and Shakespeare quotes, and less name-dropping) when I was seventeen, but I soon realised that doing so was going against the very purpose of language.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
every time I get my binoculars out they shut their curtains 
|
|
|
|
|
They're watching you too. How else would they know you're getting your binoculars out?
|
|
|
|
|
|
There have in the past been some people who sit in the car facing my house. Parke on the street for no obvious reason.
I have 15x 70mm binoculars. They are big.
Me standing on the porch, looking back through it. They drive away 
|
|
|
|
|
Get a telescope and you'll see half of it.
|
|
|
|
|
We all know that we should program against interfaces not implementations, because when we decouple that we get a lot more manageable code. There is no question about that.
I think almost all IoC-frameworks (Castle Windsor, Ninject, etc.) are able to scan assemblies for interface implementations and instantiate those classes at run-time. That means that we do not even need a reference to the assembly which is implementing the needed functionality. Cool, a lot of decoupling is going on... But that means, that we have to copy all the needed assemblies manually somehow. VS can't do this for us any longer. Same with the VS-Setup project. It isn't able to detect the necessary assemblies any more.
Is that a goal? It feels to me like this makes life harder as it needs to be...
What do you think?
|
|
|
|
|
That's what I tell my wife, but she just doesn't see it that way.
|
|
|
|
|
And in this case a decoupled solution would make life easier 
|
|
|
|
|
Is there a problem in adding a reference to the dependent assemblies?
Quote: Same with the VS-Setup project. It isn't able to detect the necessary assemblies any more.
For sure, VS Setup project will not have an idea about the DI Container or has knowledge about the interfaces and it's concert implementation.
Thanks,
Ranjan.D
|
|
|
|
|
The goal is to have a working application that is even easier to write / maintain / debug than last one.
Over engineering is a pain in the neck!
It's a balance you have to strike. You can now it's is over engineered after a little bit of use, if all the "framework" in place feels like pointless drudgework going in the way of simpler implementation then something is wrong.
In my previous job in a web shop, I did meet an overengineering PM. Boy what a pain. And that created lots of bug and slow down too.
On the other hand I wrote my own 2 all in one IoC, DiY, which I use everywhere and they make my life so much easier!
Evidently I am biased towards it.. But I found an easy way to check the value of something is to put it, explain it to your coworker and let them adopt it (or not) anyway they see fit. Adoption will be a measure of fitness and value! 
|
|
|
|
|
Bear in mind that interfaces were only introduced because so many people either couldn't or wouldn't use common sense and code robustly. It was one solution, and it was easy for people to get their heads around, so it was adopted as a standard.
If you have a robust solution that doesn't decouple in quite the same way, go ahead and try it out.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
I personally would NOT get carried away with all the decoupling crap and over engineering (as others have mentioned). Sounds to me that you are questioning this mantra that engineers have been touting as of late.
I have worked on systems that became so complex due to all this unnecessary B.S. that developers were doing in the name of "proper software design" that it became completely, and utterly unmanageable, which is what the were "trying" to avoid in the first place.
Sven Bardos wrote: Is that a goal?
No, that is not the goal. It was never intended to be the goal.
Sven Bardos wrote: It feels to me like this makes life harder as it needs to be...
Very true and it is only getting worse from what I can tell.
|
|
|
|
|
My take on this sort of thing is that it's possible to become obsessed with a particular framework and insist on using it, becoming an "evangelist" for this sacred new framework.
On the other hand, it's possible to become obsessed with getting something out as quickly as possible with code hacked together from the recesses of Google.
Neither of these extreme approaches is a good idea - if a framework helps then use it while being aware of its limitations and allowing yourself some slack as you probably have a deadline to meet. On the other hand writing poorly thought out code is going to cause you a headache and worse in a few month's time.
I don't think there is a clear boundary of where the emphasis should go as you don't have infinite time, in which to write the perfect code, nor do you have omniscience with which to see every possibility that may not be covered by your code(even code that gets into aircraft is buggy!).
If you can't look back on code that is a year old and think "I would probably not do things that way nowadays" - you are probably not learning from your experience.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
Thanks all for sharing your opinion! I will try to stay away from this kind of decoupling!
|
|
|
|
|
| 1.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
1. I usually...oh look, shiny!
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
Initiative comes to thems that wait.
- Alex
|
|
|
|
|
- CodeProject
- CodeProject
- CodeProject
- CodeProject
- CodeProject
- CodeProject
- CodeProject
- CodeProject
- CodeProject
- Girlfriend
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
