|
I think you mean flaws 
Life should not be a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming “Wow! What a Ride!" - Hunter S Thompson - RIP
|
|
|
|
|
|
A real long shot.....
How about Reversed = changing the order
like = re
vital part - verse
to make it 8 letters long - d
|
|
|
|
|
Nope...
“Real stupidity beats artificial intelligence every time.”
― Terry Pratchett, Hogfather
|
|
|
|
|
Wordle 341 3/6
🟩⬜⬜🟩⬜
🟩🟩🟨🟩⬜
🟩🟩🟩🟩🟩
|
|
|
|
|
Wordle 341 3/6
🟨⬜⬜🟩🟨
⬜🟨🟨🟩🟨
🟩🟩🟩🟩🟩
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Wordle 341 2/6
🟩⬜🟨⬜🟩
🟩🟩🟩🟩🟩
Had a good first guess 
|
|
|
|
|
Wordle 341 3/6
🟨⬛⬛🟩⬛
⬛⬛🟨🟨🟩
🟩🟩🟩🟩🟩
|
|
|
|
|
5/6
🟨⬜🟨⬜🟨
🟨🟨🟨⬜🟨
🟨🟨🟨🟨⬜
⬜🟨🟨🟩🟨
🟩🟩🟩🟩🟩
I had 4 letters at the second try but couldn anagram them for the life of me.
GCS/GE d--(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--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
Wordle 341 5/6*
⬜⬜⬜🟨🟩
🟨⬜🟨⬜🟩
⬜🟨⬜🟨🟩
⬜🟨🟩🟨🟩
🟩🟩🟩🟩🟩
Happiness will never come to those who fail to appreciate what they already have. -Anon
|
|
|
|
|
Wordle 341 5/6
⬜⬜⬜⬜🟨
🟩⬜⬜⬜🟨
🟨⬜⬜⬜⬜
🟩⬜🟨🟩⬜
🟩🟩🟩🟩🟩
|
|
|
|
|
Wordle 341 3/6
🟩⬛⬛⬛⬛
🟩⬛🟨⬛🟩
🟩🟩🟩🟩🟩
Get me coffee and no one gets hurt!
|
|
|
|
|
Wordle 341 3/6
🟨🟨🟨⬛🟨
⬛🟨🟨🟨🟩
🟩🟩🟩🟩🟩
|
|
|
|
|
Wordle 341 3/6*
🟨⬜🟨⬜⬜
🟩🟨⬜⬜⬜
🟩🟩🟩🟩🟩
|
|
|
|
|
In 2008 or something, Microsoft had some "Enterprise Block" demo or some other codename, for a MEF driven IoC/DI thing for desktop app.
I never saw more confusing app. We used the pattern a bit and we got lost and confused in our own small codebase all the time.
IoC has continued but has become less confusing I reckon. At my previous work (WebDev) we had simple IoC (MS unity container) with constructor injection (typical .NET Core / MVC stuff). And even my own home made projects, as someone who unapologetically despise IoC/DI, has little bit of it (with my own container thingy, anyway).
I can't quite put the finger on it, but IoC/DI as it is used today seems simpler to understand than how it was in those 2008 earlier iterations I think....
To come to my point, the app I am working on at work remind me of those earlier 2008 IoC samples... It's so bloody confusing all the time. I can't quite put my finger on it though. It all seem reasonable in isolation...
Not sure what's my point here. What's your thinking on the evolution of IoC/DI in the last 15 years perhaps?
|
|
|
|
|
This month is my 40th anniversary developing frameworks--the term didn't even exist back then--so IoC happens naturally. But there's already enough boilerplate without this DI rubbish.  I suppose I'd use it if the value was obvious in some situation, but so far I haven't felt compelled--or maybe have done it without realizing! I don't ascribe much value to unit tests, greatly preferring integration and regression tests, so DI does nothing for me on that front. Frameworks have to be tested using serious applications; anything less just scratches the surface and proves little.
|
|
|
|
|
DI/IOCs[^]
IOC and DI are completely foreign to me. I guess I am too old school. If I interpret these concepts its seems that the libraries are directing the program flow. Sort of like DLL's on steroids. I guess I need to do some more reading. Any suggestions for a newbie to these concepts.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
A framework is very different from a library. A library has lots of things that can generally be used on their own, like the C++ STL. A framework is a sketch for how to implement an application. Developers then plug in the pieces that contain the application logic, which the framework glues together. A library will be useful to a broader range of applications, whereas a framework is usually intended for a particular domain.
|
|
|
|
|
Got it. I need to better understand frameworks. Thanx so much.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
A library is something you can use.
A framework is something that uses you! 
|
|
|
|
|
Haha. Wag the dog.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
This rather old book introduced me to DI: Dependency Injection in .NET[^]. Even though I don't program in .NET (or C#), I found it very inspirational. It offers a critical stance towards DI (on which I completely agree), while introducing and explaining the concepts.
|
|
|
|
|
Back in 2010 I started doing WinForms development.
I had completely forgotten about it, but now that you mention it, I looked at MEF and MAF at the time and I don't think I understood.
I was especially interested in MAF as you could create add-ins for your application.
Ultimately, I rolled my own (scan a folder for dll's, read the dll's and look for IMyInterface, instantiate implementing types), which was much easier than MAF and did exactly what we wanted.
So anyway, DI isn't much of a thing for WinForms applications, although I'd currently do it by creating instances in the main form and passing them to the other forms, or something like that.
Googling for "WinForms dependency injection" now gives some questionable results and they all use different methods.
In 2015 I started working for a new employer who did web development.
By then I'd read about IoC and DI, even though we didn't use it in WinForms, and this company used it.
However, the method they were using was weird, confusing and added no benefit.
They had this container which they'd instantiate in each page and/or class and then they did something like container.GetInstance<ISomething>().
It didn't work so well when the implementation of ISomething needed constructor parameters (which was, of course, a huge hassle and we didn't use the container in many places, instead instantiating directly completely invalidating our method).
I think they wrote the container thing themselves, and like many subjects there, they'd read about them, knew they had to do something with it, but they didn't understand it.
Then I got assigned to a new project with a coworker from another team and he did understand the concept and he used a third-party DI library in ASP.NET MVC.
That's when it really clicked for me as the pros became immediately apparent.
Then .NET Core came along and it had built-in DI in ASP.NET.
Been using that ever since and it's completely natural for me.
|
|
|
|
|
The first time I saw DI in action, I was horrified and discouraged. It really broke my heart that that was what modern software had become. In this application, there were controller constructors with upwards of 40 arguments each -- tons of services being injected, many with very similar names (DocumentService, WebDocumentService, ExtendedDocumentService). The problem was very much in how the features were factored into services. But there was also a deeply irrational mania about this -- like people sincerely believed that having tons of services made your project "easy to maintain." So, this really soured my view of DI for a long time. There was a similar craze around interfaces and extracting an interface for every single class. There was a religious belief that this made your code "easy to maintain" because of the "D" in SOLID. ("D"epend on interfaces, not concrete classes.)
The thing about this is there is a good case for DI, but you have to strip away the dogma and apply it smartly. And not every class or service needs and interface. Yes, it's a good idea to minimize biz logic in your controllers (for example) to assure testability. And when you get into testing, you'll find that -- yes -- you need to pay attention to what various classes depend on. Interfaces are a miracle when you have truly more than one implementation of a service, but they are just clutter (mental and physical) if you think they belong absolutely everywhere.
So, today I see the benefit of DI, but I had to learn it in a cleansheet way and see the benefits on my own. The abusive implementation I had to deal with early on set me back a long time.
|
|
|
|
|
I wrote my reply (The Lounge[^]) before I read yours, but I see we got to the same place on DI. Very interesting. Great post.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
