chunkyfunky

I would have thought the tags on the question make it pretty clear it isn't dealing with languages like Rust.

>Heat it. Squirt it. Serve

Hey, that highly technical process is valuable Intellectual Property owned by the McDonald's corporation, careful they don't come after you!

Normally I'd be opposed to censorship in general, but in this case I'm kind of glad, but only because shit like this is actually happening even now: https://www.rte.ie/news/ireland/2021/0927/1249210-covid-pati...

AFAIC, anything they can do to suppress the raving lunacy of people like the ones who convinced that poor man to leave hospital, may he rest in peace, is a good thing in my book.

Well I understood it perfectly as in I read it as "modularity, type-safety, and maintainability"...then again I am familiar with DDD and thus understand the ubiquitous language from the original comment...which is kind of one of the main points from DDD ;)

Yep, keeping ur kids in the fridge is a great way to keep them fresh for weeks :)

I can't say I disagree with many of the points made in the article, but I am getting just a little tired of what I perceive to be the current trend of generalised manager-bashing these days...I transitioned from dev to manager a few years back and whilst I'm definitely not the greatest leader ever, I am also definitely not anything like the tired stereotypes portrayed in the article (case in point: when a dev tells me "two weeks" I smile and say "I believe you meant SIX weeks, right?". And then it takes 4, but everyone's happy cos the stakeholders got it 2 weeks "early" and the dev can sleep at night knowing the code is rock solid. etc.

This "Us vs Them" thing is bollox - we're all on the same team as far as I am concerned!

And, even though I have a good 20+ years of development behind me, I can honestly say that the two BEST engineering managers I ever had were people that could not have written a line of code to save their lives...they were just brilliant leaders and motivators who focused on me as an individual and trusted me enough to have the technical chops to get the job done whilst they meat-shielded us against waves of shite from the C-suite.

Well anyway, what would I know, I'm just a dumb-ass manager :)

I think that is a fair point and anecdotally at least it gels with what I have observed. I've worked in quite a few food service settings when I was younger and the margins (in general of course; Soup du Jour is like 5/600% margin at least) are very thin. However I wonder if this isn't just a symptom of the bigger problem; in order to pay better wages, consumer prices have to be raised because it's the only way to make enough margin to pay the employees BUT the real reason margins are so thin is because you are paying exorbitant rent to some faceless landlord who actually owns the building you operate out of; and it only ever goes up, never down; and your suppliers constantly raise their prices (or lower their quality) because they are in the same boat; and thus all that money that is generated by the tip of the spear (the restaurant, the retail store, the pub) is mostly being pushed back up to....the people who already have all the money...which is why they own all the buildings and rent them out to make more money....and so on. Just a thought :)

+1 - super achievment!

Was very disappointed too, I fully expected her to pull off a mask at the end and it would be Tom Cruise underneath :(

I'm not normally one to nitpick but Robert Boyle was Anglo-Irish, not English :)

If you look at the map on this page: http://raisedbogs.ie/what-is-a-raised-bog/ you will see how much of Ireland had quite a few natural - and very old - raised bogs up until the 1800s. And we've lost many of them forever in the last half a century or so. Agriculture & commercial scale peat harvesting is unfortunately directly responsible for the destruction of most of our raised bogs (as well as the near total collapse of many of our trout and salmon fisheries).

>This is precisely waterfall

I'm not sure I fully agree, unless we want to define waterfall as "anything where a bit of time is spent up-front to decide how a part of the system should work" :)

For me, waterfall is where every single aspect of the project is pre-defined, and cannot be changed during development without serious pain and lots of awful bureaucracy

But in the above workflow, there isn't anything stopping us from making a loop for example on a sprint by sprint basis, and using feedback from both the tests and changing requirements to improve the design, update the APIs, change the tests, etc.

I suppose we could argue that this is "mini-waterfall" but it works in my experience :)

That's a great point. And here is a real example that happened recently at work. One of my teams needs to create the ability for their low-level code to be able to respond to HTTP requests for command and control. So they have all immediately started trying to figure out how to do this. Except I happen to know that another of my teams already did this exact same thing in another project, packaged it up and published it...and the source code is already sitting there on github waiting to be re-used. There is zero overlap between the two teams (two totally different departments) except for me, so in this case I (as a lowly engineering manager whose coding days are long behind me) am able to solve a problem and save time/wasted effort Now, if we didn't do dailies, of course this would come up at some point but we'd have lost a week of productivity or more.

As someone who came from a fairly poor background (not half as as bad as the OP to be fair) and who has managed to "break out" I can say for sure that looking back I had a ton of lucky breaks - but, and this to me is crucial, only after I stopped worrying about what might go wrong and focus on what I could do right. If I had predicated my success on somehow getting lucky I don't think I would have made it.

So to me - and not wanting to speak for the OP of course - but the way I look at this is that the simple encouragement of "I made it and you can too" is more motivating than "I made it but then again looking back I had a ton of lucky coincidences that you probably won't have so, sure, try it, but don't expect success" :)

Scrutor looks great, I must take it for a spin! And that is a great point about DI - being able to extend code/behaviour by injecting a different implementation of a dependency

Neither, I'm a fully paid up and card-carrying DI-club member :)

I was kind of making the same point as you did, that you don't need to use any kind of DI library to achieve the DIP, but that in something like ASP.Net it is there and simple to use.

Page 150 of "Clean Code" says this about the DIP: "In essence, the DIP says that our classes should depend upon abstractions, not concrete details". This is very similar to pretty much any canonical definition you can find anywhere else. I'm quoting it here because the person who coined the principle is the same person whose name is on the book, so I am guessing his definition is correct.

If you're not using abstractions, you are not using the DIP. What is being described here with low-level modules depending on high-level modules is categorically not the DIP, and I am starting to wonder if this is perhaps part of the frustration that the poster we're replying to has experienced with DI, since turning your coupling upside down will have the same problems as just high coupling in general, except everything is upside down now and harder to read :)

Some fair points but I would disagree on the fundamental definition of the DIP. In my book it absolutely does not mean that low-level modules depend on high-level modules. That's just high coupling turned upside down. You have to have shared abstractions as the "loose coupling" between modules and nothing more, to say you are adhering to the DIP.

Simply, this means that no implementation module, high or low, depends on any other implementation module, ever. It only ever depends on abstractions which are shared between modules.

I don't see how using a DI container can change the program execution order, unless one is misusing it terribly - after all, its sole purpose is to provide the correct concrete implementation of a dependency to an object at the time of its construction, the execution order from the perspective of the program is 100% preserved. Sure, maybe the container itself creates my graph in a non-deterministic way, but why would I care? If my program depends on this that's just bad design imo, no amount of libraries is going to save it :)

And the object graph is not obscured, in fact it is clarified, because you look at a class constructor and immediately can see what it's invariants are! And I have yet to come across a DI library that wouldn't immediately halt and catch fire if you introduced a circular dependency chain, so it's literally not possible to have these amorphous blobs (great expression though!) in any proper DI container.

Not sure how Spring does it, but for example in ASP.Net Core, it's really simple. In the app startup class there is a method that's automatically called by the framework whereby it supplies a services container. In this method you "wire up" your interface->concrete mappings

  public void ConfigureServices(IServiceCollection services)
  {
      services.AddScoped<IMyDependency, MyDependency>();
  }

Later on when for e.g. an APIController is instantiated, once you've declare a constructor dependency on IMyDependency, it gets resolved for you automatically and whatever concrete class is mapped to gets created and passed to the constructor.

Outside of ASP.Net (console app for example) you can either do this manually, or you can get a ServiceCollection object from the framework, or you ca nuse a 3rd party DI library, etc.

Generally speaking if you don't configure this correctly you get a pretty simple message telling you that the container could not service the request for an IMyDependency or whatever and then it's pretty simple to figure out what you missed in the wire-up.

"The only reason was to inject mocks". Must disagree...the reason for DI is to support the Dependency Inversion Principle : "High-level modules should not depend on low-level modules. Both should depend on abstractions (e.g. interfaces)." Won't even go into the host of side-benefits that are gained from adhering to the DIP.

In C# the idiomatic way to achieve this is via constructor injection, which is made much easier to manage in ASP.Net with a DI library that works with the framework for you (either the built in one or AutoFac / SimpleInjector, etc.). But you don't have to use a library; many times I'm writing a simple-ish console app and just use good old "Poor Man's DI" where I manually construct my object graphs at startup.

"On the one hand, I'd love to be able to (for instance) outsource all CoC engagement and enforcement to a specialized body, that could manage a whole investigation / accuser / defense / jury system for a number of different organizations."

You know, that's a pretty good idea. And if there were actual laws backing it, then you already have a "working" system. Now I am starting to wonder, should CoCs even try to transcend the law, is that part of the problem, where we try to legislate for things that are in many cases subjective?

Agree that these are table stakes, and I speak as someone whose day job is managing a team that works on a fairly large open source project which is bound by the Linux Foundation CoC. And yes you are right, it is all about the money at the end of the day.

But here's the thing; if one of my devs made a gaffe at a conference, they'd have the full weight of myself and the company defending them, they definitely would not find themselves alone facing some kangaroo court that answers only to itself :)

"After they told me of the reports and their finding that I had violated the code of conduct, they asked if I had anything to say."

There really is only ever one thing to say in a situation like this, and it is "Yes, I refuse to participate any further in this farce; good day!" and then hang up. Personally I would not have been so polite :)

CoC committees are breeding grounds for idiots who think you can legislate for common sense and basic decency; and in my book that is a bridge that's worth burning every time.

I really hope the author finds some peace in all this, nobody deserves to be treated they way they have. And I hope that others who have found - and will in future find - themselves in this same situation, will have the courage to stand up to this kind of bullying by refusing to engage.

This is an excellent point. I don't get the polarised nature of the debate to be honest - there is room for all approaches in a "best tool for the job" way. I use EF Core a lot in my work, and it's the first tool I reach for, and if I need a view, then I use a view (EF Core has fantastic first-class support for these nowadays). For everything else there is Dapper.

I think a large part of the problem here is that developers who learn to leverage a database only through an ORM are missing out, and really they should also learn SQL (literally the only part of the article that is still objectively correct is the author's advice to learn SQL) to gain a better understanding of when (and when not) to use an ORM. Every other complaint in the article is either classic misuse of the ORM, or else a shortcoming of the ORM in question.

Somewhat tangential to the conversation at hand, but I feel part of the problem here is having two methods i.e. ReadOne/ReadAll. Why not just embrace OOP and go with one method (Read) that takes a specification which itself encapsulates the set of files you want to read? Then it works for none, one, and all files...and makes the argument about Mocking vs Faking somewhat moot; the mock is a simple "for any args return this" and the fake is just as simple.

I guess my point is that if you have to agonise over mock vs fake then really it's a sign that your design is not quite as testable as you might like :)

"effectively illegal to see other people as a consequence of your government's abject failure to manage an epidemic"

Surely though the current situation is as bad as it is because of other people's inability to manage themselves during an epidemic, as opposed to the government being to blame? I'm not having a poke, but I notice here in Ireland for example, when the government comes out with clear guidelines e.g. "Don't go around licking people's eyeballs. If you do you might get sick" then the general populace is all like "oh but it's so confusing! What if I only lick one of their eyeballs? What is the definition of 'might'? We need more guidance!". So then the guidance comes back "Do not lick people's eyeballs, ever" and BOOM - someone takes a constitutional challenge High Court because "Civil Liberties".

And I do think it's kind of the same in most countries, the government is not to blame, the general population is.

Just a thought :)