|
I am still using Win 7 good as old days and as it is PC I had the liberty to choose.But I am thinking about buying new laptop hope that I should delay that a little further.
|
|
|
|
|
Microsoft do seem to have a habit of putting one feature into an OS that's guaranteed to p*** people off in a big way.
With Vista it was that godawful UAC system which soon had people screaming at their laptops: "Yes, I AM trying to run a goddamn program on MY goddamn computer, you stupid bloody OS! Why do you think I bought the bloody thing?"
Net result: an otherwise good version of Windows became quite possibly the most unpopular of the lot.
With 10, it's the overly assertive update system that raises the hackles. Yes, updates are necessary and that's often going to involve a restart and a little bit of nagging but the way that it has been implemented in 10 can only be described as downright rude.
Net result: there are still a lot of people out there pining for the good old days of 7.
98.4% of statistics are made up on the spot.
|
|
|
|
|
I totally understand the frustration, also having vented here (or in the lounge) about losing unsaved work (on multiple occasions) due to an unwanted forced restart on Winten. Sadly, I see there is still no guaranteed way to prevent it.
There is also the issue of resetting registry permissions and policies on some updates, but that's another rant!
"Go forth into the source" - Neal Morse
|
|
|
|
|
Sad to read such rants here on CP. "programmers" that don't know how to save work, how to install old drivers, how to setup Windows-Update (or are ranting about old versions and long solved problems), whining about how "good" Windows 7 was, it's a shame.
All workers should know the tools for the Job. As a programmer the OS is a big "tool" to know…
I think Noob-User discussions don't belong here...
|
|
|
|
|
What's sad is you missed the entire context of the rant.
Windows 7 *was* less invasive. Windows 8 was a steaming pile of ****, and Windows 10 primary feature is Microsoft trying to figure out someway to package it as a service.
Save work: I do save my work, but many times I have debug sessions going on for days (embedded systems). You think it's okay to reboot because of policy?
Install old drivers - why would I even have to do that?
You're an elephanting idiot.
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
So if you plan a debug-session just set out updates (it's max is 35 days) - so no restart or Installation will happen.
If you don't need old drivers everything is fine - if you Need, you can install even drivers that didn't work anymore on Windows7 for very old devices on Windows 10.
I have no problem, if you have some unrational "believe" or sympathy for old OSes. From an objective point of view Windows 10 isn't perfect but much better than it's predecessors -and the experience arround updates is constantly improving.
P.S. I don't think you an idiot - just a little "nostalgic" about something you shouldn't be in professional life. Win7 time is over - accept it...
|
|
|
|
|
You are missing my point entirely. thrice, so, rather than hash a dead horse, have a nice day.
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
modelTables.Single(kvp => kvp.Key == model.GetType()).Value.ForEach(mt => mt.BeginProgrammaticUpdate());
vs simply:
modelTables[model.GetType()].ForEach(mt => mt.BeginProgrammaticUpdate());
Oh yeah, I did!
At least there's an assert that the key exists in the dictionary.
Or equally amusing:
(from rec in context.GetTable<T>() select rec).ForEach(m => AppendRow(dv, (T)m));
vs.
context.GetTable<T>().ForEach(m => AppendRow(dv, (T)m));
|
|
|
|
|
Marc Clifton wrote: At least there's an assert that the key exists in the dictionary.
You'll get a different exception, but you will get an exception in both cases if the key doesn't exist.
But the first version has the added advantage of iterating over the entire dictionary, and calling model.GetType() once for every single item within it. Probably not a huge issue, but not the best for performance.
Also from x in collection select x seems to be fairly common with novice LINQ developers.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Richard Deeming wrote: Also from x in collection select x seems to be fairly common with novice LINQ developers.
And when I wrote that, I definitely was. Still learning actually. Just now re-discovered that Select has version that includes the index!
|
|
|
|
|
So you were looking for models that are single you old cad:
Quote: modelTables.Single
|
|
|
|
|
RickZeeland wrote: So you were looking for models that are single you old cad:
As of June 24th, 2018, not any more!
|
|
|
|
|
So that must be:
Quote: Love and marriage, love and marriage
They go together like a horse and carriage
This I tell you, brother
You can't have one without the other Congratulations !
|
|
|
|
|
My favorite columnist, the late Paul DiLascia used to write in the header of his code, "If this code works it was written by Paul DiLascia. If not, I don't know who wrote it."
modified 11-May-18 17:28pm.
|
|
|
|
|
Rick York wrote: "If this code works it was written by Paul DiLascia. If not, I don't know who wrote it."
An a shorter version: "If this code works, it wasn't written by you!"
|
|
|
|
|
A while back, I related the experience of losing FKs in a database, without having an inkling of what may have caused it.
Various people came up with (reasonable) suggestions, like removing a constraint to facilitate adding records, or bulk inserts etc.
However, I can now reveal the culprit. A product from a third party developer (who originally developed the system) that proceeded to go through the DB removing FKs without any attempt to reinstate them.
The process was run a few months ago, luckily it looks like we only have a few cases of erroneous data resulting. This is a small miracle in itself.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Rob Grainger wrote: However, I can now reveal the culprit. A product from a third party developer (who originally developed the system) that proceeded to go through the DB removing FKs without any attempt to reinstate them. "Sir, we're getting primary key exceptions!"
"Ah, just remove the constraints from their database, that'll fix it."
Makes me wonder about liability
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
"RDBMSs are inefficient - we can hand-roll our own referential integrity in code, using a couple of junior devs, in less than a week"
- Every development shop ever.
|
|
|
|
|
Essential for a fully abstracted repository layer, but if you're already married to a persistence technology...
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
And they would have gotten away with it too, if it weren't for you meddling kids!
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
The application must not rely on such things for proper functioning!
|
|
|
|
|
I had the following code in my app. Turns out you just CAN'T debug that code. At least with Visual Studio 2017,
It will crash your process instantly and you will be left without any clue as to what was wrong!!
Gotta report that to Microsoft..
Meanwhile, behold the evilest safe C# code that can be!
class Program
{
static void Main(string[] args)
{
try { Fail(); }
catch (Exception ex) { Log(ex); }
}
static void Fail()
{
throw new NotSupportedException("You Fool!");
}
static void Log(Exception ex)
{
var sb = new StringBuilder();
Log(ex);
Console.WriteLine($"Problem: {sb}");
}
}
[EDIT] To clarify, of course this code is buggy, it's a bug repro.
But most remarkably the program just crash without hint from Visual Studio. Even if you ask Visual Studio to stop on StackOverflowException, it won't!
[EDIT2] Setting breakpoints is not the problem...
But why would you put a breakpoint there if you didn't know the bug was there in the first place?
FYI it's about 1 month of work before this bug came to light!
modified 1-May-18 7:39am.
|
|
|
|
|
Recursion without exit condition is killing it ?
Zen and the art of software maintenance : rm -rf *
Maths is like love : a simple idea but it can get complicated.
|
|
|
|
|
Of course this code is buggy, that's the point.
But most notably the program just crash without hint from Visual Studio. Even if you ask Visual Studio to stop on StackOverflowException, it won't!
|
|
|
|
|
It's exceptions all the way down.
This space for rent
|
|
|
|