|
Quote: The current OneDrive client will set up KFR and then move any files from their original location to the new OneDrive location. If you can't even get your main OS to market without showstopping bugs like this, how the hell can we trust your frigg'n cloud??? And with storage at such low prices, why would anyone not want a local copy??? Wake up and think about customers before shareholders for once!!! Reinstall at least the most basic of QA teams, instead of relying on your 'Home' users to bitch and moan!!!
|
|
|
|
|
Obligatory Dilbert
When you are dead, you won't even know that you are dead. It's a pain only felt by others.
Same thing when you are stupid.
modified 19-Nov-21 21:01pm.
|
|
|
|
|
Visionary
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
It's nice to have an explanation finally. Given that, I don't use KFR (at least, not to my knowledge, haha) and I never put stuff in the Documents, Desktop, Pictures, and Screenshots folders. Never have, since, what was it, Windows ME introduced the "My" root path?
Latest Article - A Concise Overview of Threads
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
I've worked for companies that were so strict on the security of your local box, those were the only folders you had access to. Just imagine all of your project files in the documents folder and support pushes out an update like this.
Yes, I do keep multiple backups of all of my project files.
When you are dead, you won't even know that you are dead. It's a pain only felt by others.
Same thing when you are stupid.
modified 19-Nov-21 21:01pm.
|
|
|
|
|
Thankfully, it didn't make it to my PC during its brief availability. I definitely would have got hit by it. I use KFR all over the place. Though, it probably would have done minimal damage. I'm good about backups...and backups of my backups...and so on. OK, maybe a little paranoia at work there?
|
|
|
|
|
Eric Lynch wrote: Nowadays, they seem to use their customers as a QA department. Nowadays? It's always been the case.
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
What mechanism did it use to delete the folders? What happened to 'folder not empty, can't delete' errors?
|
|
|
|
|
Whatever happened to "make a backup before you change anything"? Of course, if the update sneaks up on you then you don't get to make that backup.
Incidentally, what's with all the garbage that gets pushed out with all these updates.
For the record, I don't have a 3-D printer. I don't use virtual reality, I'm having enough trouble with real reality. I don't like 3-D paint. It's horrible. I no longer use Skype since MS broke it.
The Mail app is useless to me. Cortana seems to be deaf in my part of the world.
And so on. All this stuff gets re-installed whenever I try to remove it. Just to please the sales department I guess.
We're philosophical about power outages here. A.C. come, A.C. go.
|
|
|
|
|
Herbie Mountjoy wrote: All this stuff gets re-installed whenever I try to remove it.
Have a look at Windows 10 Decrapifier, 1803/1809 - Script Center - Spiceworks[^].
If you read the notes/instructions you are meant to run this during the installation of Windows to do it right. If you run it it won't affect the current logged in user but, and I mean but, it might work for you if you enable and login as the Builtin Administrator, then login as yourself and disable Administrator again.
Haven't had time to play with this myself yet so can't vouch for it.
Michael Martin
Australia
"I controlled my laughter and simple said "No,I am very busy,so I can't write any code for you". The moment they heard this all the smiling face turned into a sad looking face and one of them farted. So I had to leave the place as soon as possible."
- Mr.Prakash One Fine Saturday. 24/04/2004
|
|
|
|
|
Thanks Michael. I will look at this.
We're philosophical about power outages here. A.C. come, A.C. go.
|
|
|
|
|
Under no circumstances I will leave updates enabled on my computer. I update when I need to. That holds true for Linux distributions too - I had several systems killed by some package update.
GCS d-- s-/++ a- C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
I'm learning about DI, and it kind of makes sense, but I'm not convinced it solves the loose coupling issue.
So, here's my stupid question of the week: code that uses an external object still has to know about it's properties and methods in order to use them, so how does passing the object or interface to the constructor or a setter make the code any less dependent than using the concrete object with the 'new' keyword?
I'm sure I'm missing the point somewhere.
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
With dependency injection, usually the target code depends on an interface, which is usually in a separate library/dll/assembly from the actual implementation. If not, and your target code references a concrete class, then yeah there's no loose coupling.
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
Exactly.
|
|
|
|
|
Seems to me that regardless of whether you're using an interface or concrete object, you still need to know what's available in the object so you can write the code that uses it.
I think maybe I'm misunderstanding what is meant by loose coupling in this context. And maybe that's the least important advantage of DI anyway.
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
In my house I have some lighting fixtures that are hard-wired to the wall/ceiling (~tight coupling). Others just plug into an electrical outlet (~loose coupling). Guess which ones are easier to switch out for new models? And when I do so, I can be confident that the new lamp will work as long as it has a matching interface (which, in this country, is AC 120V).
So at work, when I am testing code that includes a DatabaseConnection Object, if that object was injected rather than hardcoded, I can happily swap it out with a mocked version that shares the interface. So, thanks to that loosely-coupled DB object, my tests run much faster.
|
|
|
|
|
|
Interfaces. The implementation is loosely coupled, not the interface.
Edit: believe or not, I actually learned a lot about DI via this product: Ninject - Open source dependency injector for .NET[^]
Play around with it, use it, and learn from the docs and making mistakes. You will be a DI god in no time.
Actually, any good DI product will work, I prefer the one listed for most stuff.
modified 10-Oct-18 14:14pm.
|
|
|
|
|
In my experience, DI as a concept is valuable especially for testing - For example, if you inject your external dependencies you may write unit tests for a given purpose without having to care to setup anything beside the stiff within your test scope. This is especially valueable if you are, for example, accessing a config heavy API, or internal service. With proper DI in place you can mock the test scope to stay within boundaries within seconds.
(of course this does not replace proper integration testing, but it gives you a fair chance to validate changes on your side of the code).
I only have a signature in order to let @DalekDave follow my posts.
|
|
|
|
|
Our shop uses the same website for different clients. We use DI for custom logic and UI stuff, that is client specific. Absolutely a work of art. DI is so powerful, yet so simple, really.
Edit: that is using DI for non-testing functionality. Of course, testing is benefited as well.
|
|
|
|
|
I agree, I understand all the other advantages of DI, I think I just misunderstand what loose coupling means in this context.
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
An example says more than a thousand words...
Let's say you have some class that connects to a database.
This class is used by another class that does some business logic with data from a database and uses your database class.
public class DatabaseClass
{
public List<Customer> GetCustomers()
{
}
}
public class BusinessLogicClass
{
public int GetCustomerCount()
{
var db = new DatabaseClass();
var customers = db.GetCustomers();
}
} Now there is no way to unit test GetCustomerCount because you always need your database because there is a tight coupling with DatabaseClass which directly goes to the database.
So instead of using new DatabaseClass we can "inject" an interface instead.
public interface IDatabaseClass
{
List<Customer> GetCustomers();
}
public class DatabaseClass : IDatabaseClass
{
public List<Customer> GetCustomers()
{
}
}
public class BusinessLogicClass
{
private readonly IDatabaseClass db;
public BusinessLogicClass(IDatabaseClass db)
{
this.db = db;
}
public int GetCustomerCount()
{
var customers = db.GetCustomers();
}
} Now, we can use the BusinessLogicClass with the DatabaseClass or with some mock object for testing purposes.
var bl = new BusinessLogicClass(new DatabaseClass());
var count = bl.GetCustomerCount();
var bl = new BusinessLogicClass(new MyMockObject());
var count = bl.GetCustomerCount();
Assert.Equals(5, count); Now that's a lot better, our business logic does not depend on the DatabaseClass, and by extension the actual database, anymore.
However, using new DatabaseClass() everywhere in your code isn't ideal either.
You may want to switch database systems at some point or whatever.
So that's where a DI framework comes in.
It let's your register your concrete types for any interface and that type gets injected.
To switch implementations you'll only need to change your registration.
How registration is done depends on the framework you use.
For example, Unity can do registration by convention (DatabaseClass is injected for IDatabaseClass) or it just injects the first (or only?) class it finds that implements IDatabaseClass.
Other frameworks (and Unity too) make you explicitly register types for interfaces.
In .NET MVC, for example, the frameworks creates your Controller classes and can inject any registered implementations in your Controllers constructor (in the example above IDatabaseClass would be injected with DatabaseClass).
You could also have an IBusinessLogicClass of which the implementation requires an IDatabaseClass etc.
In any case, the bottom line is that your code becomes testable because it depends on abstractions (interfaces) and not on implementations.
It's a tough subject, so good luck.
I hope this helps
|
|
|
|
|
TNCaver wrote: code that uses an external object still has to know about it's properties and methods in order to use them, so how does passing the object or interface to the constructor or a setter make the code any less dependent than using the concrete object with the 'new' keyword?
Imagine a door. On that door is a knocker. Imagine another door. On the side of that door is a doorbell. Imagine an interface. The interface has one method: "Announce" -- Announce someone is waiting at the door."
Now go knock on the door or ring the doorbell. They both implement "Announce". I think I'll stop now about injecting knockers.
TNCaver wrote: I'm learning about DI, and it kind of makes sense, but I'm not convinced it solves the loose coupling issue.
It does, if you don't abuse it. And boy, have I seen abuse. However, I avoid DI like the plague because it flips the problem on its head. Most DI's that I've seen basically express in metadata (XML, JSON, whatever):
Property-of-instance-Foo-gets-initialized-with-interface-Eye.
And worse, some of those DI's will instantiate Foo for you if it doesn't exist at the point in time of the injection. Massive entanglement of dependencies ensues -- what if the instance of Foo is itself a dependency?
Now, you also have another choice. Foo itself can implement an interface that defines the property (of some interface type) that the DI is told about and can set. That's pretty quick. Otherwise, the DI has to rely on reflection to set the property of Foo, because it doesn't know what type it is and has no interface to map Foo's property to a "known" interface. Reflection is slow.
Now magnify that problem with hundreds, if not thousands, of entangled dependencies, all specified in some XML file (yes, I've actually seen this) and you get a nightmare that is impossible to debug, slow to instantiate, and brittle to changes.
I'm old fashioned. Give me a factory pattern. DI is a bad solution looking for an already solved problem.
Latest Article - A Concise Overview of Threads
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
I think you may have scared him off. I know I would be if I didn't know any better. Just saying...
|
|
|
|
|