|
|
|
used it for 7ish years back in the day for last company's flag ship product for communication between computers, it worked well, then WCF came out; and I believed the hype that it was so much better, and restructured the system for a big new release around WCF. In the long run it wasn't anything spectacular and I don't think it improved anything, now according to the latest news WCF will not be carried forward into Dotnet 5.
before that news came out though we had already made the commitment to leave WCF and start using REST services, it was more flexible and I could tie our java products into the same calls as the .net projects with no extra work.
|
|
|
|
|
|
I just recently left my last job, and they supported it quite heavily. The applications were extremely old. I avoided it as much as possible, but the little I did learn came down to you could replace the entire system with web services, of one flavor or another, and make life very easy. If I had to explain it to somebody who had never seen it, I would say .Net Remoting was the grandfather of web services, before anybody know what web services were.
One of the many problems that we faced, in working with Remoting, was the code had been built in Visual Studio prior to 2005. That was our guess anyway. We didn't have any licenses for an IDE that would work on it, and it was next to impossible to make changes. The programs that used it were on a 6 months cycle that lasted 3 months. They ran data in March through June and then again in September through November. That left us only 3 months to rewrite everything before the software had to be ran again and it was a fairly large and complex system. In general, dealing with it sucked. I don't know the final outcome but the program was on the board for a modernization to using web services.
|
|
|
|
|
.NET remoting is the same dead-born technology as WCF, EF, WF, you name it.
Simply because MS don't have even 5 smart guys to make good, perspective product.
|
|
|
|
|
Yes, these frameworks required architecting, and all the cool boys just wanted to sit down with something shiny new and code, so no buzz.
|
|
|
|
|
Which do you prefer:
Option 1:
Assert.IsTrue(token != Guid.Empty, "Token not received.");
or Option 2:
Assert.IsFalse(token == Guid.Empty, "Token not received.");
Personally, I go for option 1, because there's a bias to assert that things are true rather than false (except in politics) and it reads better. I have to process the false == into a true != . With Option 1, I don't have to do that. Interesting how the mind works.
Maybe a psychopath would go for option 2?
|
|
|
|
|
I'd go for first as well, coz it's more straightforward. Less mental operations = better readability. Unless you're writing negative tests of course 😆
Edit :- okay, you're saying the same thing. So I agree.
|
|
|
|
|
I always have a tendency to put positives first, eg.
if (thing == true)
{
}
else
{
}
...so, obviously, I would go for "Assert.isTrue".
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
In most cases I put the conditions which prevent code execution (like error cases) first and the condition in which the code must execute comes last.
|
|
|
|
|
I do the same - if only because the "failure case code" is generally shorter:
MessageBox.Show("...", "...");
return; And it's more obvious what is going on that way. Plus ... it's a layer less indentation:
if (goodThing)
{
...
}
else
{
MessageBox.Show("...", "...");
return;
} Vs:
if (!goodThing)
{
MessageBox.Show("...", "...");
return;
}
... And it groups validations at the top of methods, leaving the "good code" alone at the end:
if (!goodThing)
{
MessageBox.Show("...", "...");
return;
}
if (!otherThingIWantToSee)
{
MessageBox.Show("...", "...");
return;
}
...
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I once had to adhere to a rather arcane coding standard that required only one return statement per function. It made for some very deep indentation so I resorted to using many more very small functions. It's a bit less of an issue now with very high resolution monitors but back then it was very annoying.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
An adamant refusal to use GOTO
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
Using goto was forbidden. It was in C++ so that had something to do with it.
The irony of it was they had this arcane and tedious coding standard and used a library they wrote themselves that was utterly atrocious. It is easily the worst library I have ever had to deal with. Here's one little tidbit : the whole thing was built around a state machine that changed states by throwing an exception.
I would have to work really hard to come up with a design worse than that.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
Seen it; rewrote it. In (pre-Visual) BASIC code (ON ERROR GOTOs that would branch to different line labels depending on the ERRNO thrown) for nuclear weapons effects. Guess it's fitting, in retrospect, that "bomb code" worked by "blowing up"
|
|
|
|
|
That's an interesting coincidence. At the same job where I used that horrendous library the company built robots. They used Microsoft's BASIC as the embedded language and it had that ON ERROR stuff in it. It could get very tricky and downright dangerous when an emergency stop was activated because there was no telling where the robot would go next when the stop was cleared.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
Mycroft Holmes wrote: use GOTO Burn the heretic!
Software Zen: delete this;
|
|
|
|
|
<snicker> I have not used a goto in over 20 years and that was in VB, just poking the anthill
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
Now that you wrote it, I see why it is obvious. I didn't think about it that much when I posted. To me it just made better sense when coding probably because of the lesser/better indentation.
Also it really pays off when the code is called recursively.
|
|
|
|
|
Always Option 1. Thislike I can focus on "!=" or "==" for the complete information.
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
I also prefer #1. But shouldn't it be "Token received" if token isn't Guid.Empty ?
/ravi
|
|
|
|
|
Ravi Bhavnani wrote: But shouldn't it be "Token received" if token isn't Guid.Empty ?
A perfect illustration of the mental gymnastics involved here.
Assert.IsTrue displays the message if the assumption isn't met.
Assert.IsTrue(token != Guid.Empty, ... displays the message if token == Guid.Empty , meaning that "token not received" is the correct message.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Gaaah!
I'm going to blame it on lack of caffeine, even though the real reason is sheer stupidity.
/ravi
|
|
|
|
|
Richard Deeming wrote: perfect illustration of the mental gymnastic Or, perfect illustration of the twisted minds that defined 'Assert semantics
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
|
|
|
|