> .ConfigurationFileService implements IConfigurationFileService
> STOP MAKING SERVICES AND FACTORIES AND INTERFACES AND JUST READ THE FUCKING
> JSON FILE YOU ENTERPRISE FUCKERS
I know it's cool to "hate" on OO, but "just read the fucking file" doesn't work if you want to run your unit tests without reading a fucking file.
It makes sense to abstract configuration behind an interface so you can easily mock it our or implement it differently for unit testing.
Perhaps you also want to have some services configured through a database instead.
This isn't a ConfigurationFileServiceFactoryFactory.
Then don't do that, if in the real world it'll read a fucking file, then test with reading a fucking file. Tests aren't there to just be passed, they're to catch problems and if they're not testing the same workflows that the code will see IRL then the test is flawed. The first test should be reading a fucking file and that fucking file could be full of all sorts of garbage.
Same goes for non-fucking files.
I'm happy to have a long running integration test suite that runs on a build server.
But while working on a project, I need fast running unit tests that I can edit and run to get fast feedback on my work. I find that "time to iterate" is key to effective and enjoyable development. That's why hot module reloading is an amazing innovation for the front-end. The back-end equivalent is quickly running affected unit tests.
So I'd rather unit test my FooFileReader to make sure it can read parse (or not) what's in various files, and unit test my service which consumes the output of my FooFileReader by either parameterising the FooFile result or having an IFooFileReader injected. ( Either works to separate concerns. )
While unit testing, I'm going to test "given that System.IO.File can read a file", and write tests accordingly. I don't want a test sometimes fails because "read errors can happen IRL". That doesn't help test my business logic.
I can even test what happens if read failures do happen, because I can mock my mock IFooFileReader to return a FileNotFoundException or any other exception. I'd rather not have to force a real-world scenario where I'm getting such an error.
In a functional world, it's the difference between:
function string -> result
function string -> parsedType -> result
function string -> parsedType
function parsedType -> result
Interfaces and factories are just an idiomatic .NET way of doing this indirection over services and classes.
Of course you can also write more in a functional style, and there are times and places to do that too.
Also reading / parsing a JSON file is fast enough for hot reloads / auto rerunning unless you have multiple GB files - so the argument for speed makes no sense. I'd argue it's slower as a whole to have to code up mocks and fill in the data than copy paste some json.
I do agree with the second being neater, however past a certain point of enterprise coding it's a negligible difference compared to the overall complexity of the code - so taking a shortcut and making your tests simpler through JSON files actually ends up being the cleaner / neater solution.
>While unit testing, I'm going to test "given that System.IO.File can read a file", and write tests accordingly. I don't want a test sometimes fails because "read errors can happen IRL". That doesn't help test my business logic.
Since you're given that - use it. If your test fails because a "low level" dependency is failing it's indicating something is seriously fucked up on your machine.
Basically too many unit testing tutorials were simplified too far, so the vast majority of people think a "unit" is syntactic rather than semantic. Like, a single function rather than a single action.
That sounds pretty squarely in the "you ain't gonna need it" category. If your test harness cannot make a temporary directory and populate it with a copy of the test config file that's stored in the same SCM repo as the test case code, then you simply have a broken CI server. There's no need to complicate your codebase and make your tests less realistic all to avoid hypothetical problems that would almost certainly break your test suite before the test case gets around to attempting an fopen. Just read the damn file.
There are more complicated instances where mocking and dependency injection is needed. "fopen might fail on the CI server" usually isn't one of them.
Reading a file is a fast operation these days. Re-reading a file shortly after a read is less than a memory copy.
Making the structure more complicated so that you can avoid reading a file during unit tests is a poor investment of resources - that complexity will haunt down the team forever.
You see it everywhere where someone handrolls a "ServiceResolver" or "DtoMapper" that wrap what DI or ORM already handle on your behalf, simply because it is consistent with ancient badly written code that originates from practices that came from heavier Java and before that C++ codebases.
There is no cost trade-off.
There is a case where I think it is justifiable to not write a single test: Startups. Specifically pre-seed & seed round funded I think are allowed to skip the majority of tests - however critical paths, especially those that are important to customers (i.e. transactions) must be tested.
By the time you have built out that mvp and have a few customers then you should transition to writing more tests. And as the number of engineers, scope, or complexity grows you need to add tests.
Would unit tests have avoided the Therac-25 incident?
So many developers don't understand this simple concept - it manifests in 2 ways: 1. Not writing tests 2. Writing too many / too specific tests
Testing should always be focussed on the OUTCOMES never the implementation. That's why they're so good for making sure edge cases are covered - since we are able to assert the input and expected outcome of the code. I like to use the mental image that in an ideal world I could put the same tests on a completely separate implementation and it would still pass (mocks/stubs, and implementation specific tests don't pass this).
I'm always far more frustrated by 2 than by 1 - since 2 adds so much unnecessary code / complexity that doesn't need to be there, growing technical debt through the tool that should help us manage it. They make changing implementations painful. And worst of all they think they're doing something correctly and when combined with the sunk-cost fallacy they're incredibly resistant to changing these fucked up tests.
Don't get me wrong 1 is annoying too but he'll at least add the tests when you ask him to and not over engineer everything.
At the end of the day, tests are necessarily a mock-up of what's real. You just happen to disagree with where some people put the abstraction layer. I also would like to make my tests more "real" but I have a lot of sympathy for folks that are trying to test something smaller without involving eg a file. After all, the whole point of "everything is a file" in Unix is that we shouldn't need to worry about this detail, it's an OS concern. If you write to a file that's not actually a file on disk but actually a device, that it should fundamentally be okay and work as expected.
> file isn't a "real" configuration file then isn't it just a "mock?"
I want to say "no" but I haven't thought about it enough yet. My reasoning is that the file itself contains information about the expected messages to/from systems, since it is the body of whatever the system should respond to. And while it is only 1 layer separated from just creating the same object in memory for your test this "feels" different because you can't just pull it out of your codebase into curl.
Consider these two scenarios:
- read "test1-config.json" from disk, into whatever most easy JSON-adjacent format makes sense for your lang
- just use the JSON-adjacent format directly
Isn't the difference between these that one requires coupling input configuration of the environment to the tests (possibly inclusive of env vars and OS concerns around file I/o), making running the tests more confusing/complicated in aggregate, while the other requires coupling input configuration to the tests, making the unit under test clearer but potentially less reflective of the overall system?
Effectively this is just an argument between integration tests and unit tests. Unit testers certainly have the rhetorical upper hand here, but I think the grug-brained developers among us feel that "the whole program should be a pure function."
That can ultimately be reduced to a P-NP problem.
For example if we had a dto that serialises to/from json we should be storing json not creating this dto manually - I would push it further and say any structure which is also easily/transformed from json, like extracting a certain property and using that in the test (although this is also context dependant, for example: if there are other tests using this same file). As a counter example I wouldn't advocate for using json config files to test something completely unrelated to an underlying json structure.
> That can ultimately be reduced to a P-NP problem
Yeah ideally the goal should be to write the simplest code possible, however we get there - shoehorning an approach is always going to add complexity. I think there's a lot of danger from taking rhetoric too far, sometimes we push an abstraction to its limits, when what's really required is a new perspective that works well at these limits.
Effectively I think there's a range in which any argument is applicable, its a matter of assessing if the range is large enough, the rules simple enough, and it solves the actual problem at hand.
This sounds like a great candidate for the facade pattern: https://en.m.wikipedia.org/wiki/Facade_pattern
Basically you hide dependencies behind a small interface, which lets you swap out implementations more easily. The facade is also part of your codebase rather than an external API, so it gives you something stable to mock. Rather than a building facade like the name is based on, I think of these as a stable foundation of things a module calls out to. Like your code is a box with an interface on one side (what tests and the rest of the codebase interact with) and the facade(s) are on the other side (dependencies/mocks of dependencies).
Using the known baked in stdlib functions for standard behavior removes a lot of potential uncertainty from your codebase (while also making it sometimes harder to test).
isn't that an oxymoron?
"Interface all the things" is a bit lazy, but it's easy, especially if you have Moq as a way to auto-mock interfaces and a DI framework to setup factory methods.
But spinning into rage just because you see an interface or abstract factory isn't healthy.
There's nothing that triggers* me more than seeing an interface that only has one implementation. That's a huge code smell and often a result of pre-mature architecture design in my opinion. It also often leads to complexity where if you have an interface, you create a factory class/method to instantiate a "default" implementation. Fortunately it seems that it is not used as often as before. Our code has no factories and only a few interfaces, that actually have a practical use. The same applied to my previous workplace
* The trigger applies to 2024 Java code written as if it was 2004. I may have a form of PTSD after many years of interfaces and FactoryFactory, but fortunately times have changed. I don't see much of that today except in legacy systems/organizations.
I used to be in the "Interfaces with only a single implementation is a code smell" camp, but I prefer to follow the principle of least surprise, so going with the flow and following the way the MS standards want you to do things makes it easier to onboard developers and get people up to speed with your code base. Save "Do it your own way" for those parts of the system that really requires it.
And technically the auto-generated mock is a second implementation, even if you never see it.
I sometimes work on legacy C# code that we inherited from another team and I try to follow the style as close as possible. I just haven't invested enough time to make any informed decisions about how things should be.
GIT? unit tests? and i thought debuggers spoiled us?
although cavemen-esque in comparison to 'modernity'; it wasn't a nightmare to Pause/resume program flow and carefully distill every suspected-erroneous call to Console.Log(e)/stdout/IO/alert(e)/WriteLine(e); `everything to find the fun/troublesome bits of one's program - instead of a tedious labyrinth of stack traces obfuscating out any useful information, further insulted by nearly un-googable compiler errors.
Tests were commented out functional calls with mock data.
If you never need to instantiate another instance of a structure so much so that it would benefit from an explicit schema for its use - whether it be an object or class inheritance or prototype chain - then sure, optimize it into a byte array, or even a proper Object/struct.
But if it exists / is instantiated once/twice, it is likely to be best optimized as raw variables - short-cutting OOP and it's innate inheritance chain would be wise, as well as limiting possibly OOP overhead, such as garbage collection.
>interface in C#
yield and generators gave off awkward syntatic-over-carmelized sugar smell as well - I saw the need, to compliment namespaces/access modifiers, but felt like a small tailored class would always outweigh the negligible time-save.
My comment was regarding interfaces used internally within the code, with no expectation of any external use. I wrote from a modern Java perspective, with mockable classes. Apparently interfaces are used by .Net to create mocks in unit tests, which could be a reason to use that approach if that is considered "best practice"
An interface with a single implementation sometimes makes sense, but in the code I've seen, such things are cludges/workarounds for technical limitations that haven't been there for more than a decade already. At least, it looks that way from the perspective of a polyglot programmer who has worked with multiple interface-less OOP languages, from Smalltalk to Python to C++.
IConfigurationFileService implies abstraction of file system-based configuration. Are we planning that there's going to be a different way to read configuration files in the future, and what exactly is that? If no one can articulate it, it just seems like architecture astronautism and: YAGNI.
IConfigurationService makes writing unit tests for anything that uses it way easier, too. There can be a simple TestConfigurationService:IConfigurationService that just implements everything as settable, and in your test code you can provide exactly the properties you need (and nothing more), and easily have 100 variations of configs to ensure your code is working. Without the headache of dealing with actual files separate from your test code, or worse, shared with other test code.
I've actually written multiple long-lived pieces of software this way, and more than once ended up implementing stuff like environment variable-based configuration, REST API-sourced configuration, and even aggregations that combine multiple sources, eg:
new AggregateConfig(new ServerConfig("https://whatever"), new EnvironmentConfig(), new FileConfig("/some/path.config"));
I don't understand how this is the case. If anything, an interface is MUCH easier to understand than a variety of functions strung together.
I mean, this is the whole reason we have APIs. If I'm a consumer, I would much rather read and understand the API and its contract than try to read through the code to find out requirements.
I have waded through such code in Java, rather than C#. At least some of it is fighting the language; Java is pretty hostile to writing DI style code.
On top of that, even in languages that are more DI friendly, DI significantly decreases the lexical locality of code that is dynamically very close.
Config config;
// production
config_from_file(&config, "config.json");
run_production_stuff(&config);
// unit tests
Config config;
config_from_memory(&config, &some_test_values);
run_tests(&config);So let's say you have a service FooService that requires some configuration.
( Ignoring the System.configuration namespace for now)
You'd have:
class FooService(IConfigurationService ConfigurationService){
// Access Configuration Through IConfigurationService
}
Yes, it can sometimes feel a bit like "turtles all the way down", where sometimes you just wish you had a bunch of concrete implementations.
In unit tests, you'd auto-mock IConfigurationService. For integration tests you might provide a different concrete resolution.
There are some advantages to service based DI though. The standard ASP.NET DI framework makes it trivially easy to configure it as a singleton, or per-request-lifetime, or per-instantiation, without having to manually implement singleton patterns.
This gives you good control over service lifetime.
But I just wanted to illustrate idiomatic .NET DI, and on reflection picking configuration was probably the worst way to illustrate it.
You could make a few dozen different configuration files. Or maybe it's more than that because you want to test permutations. Now you're maintaining a bestiary.
So instead you think "I'll write code that generates the config file for each test". And that's reasonable sometimes.
On the other hand, the single-responsibility principle can be reasonably applied here and "reading the config data" is a good single responsibility. You don't want to have to write code to muck with json or xml every time some component needs a configuration value. So there should already be a clean boundary here and it often makes sense to test the components separately.
There's not one rule. The article author sounds like an excitable jr engineer that's never written software at scale.
Is this like a never version of that insult where people would say someone's opinion doesn't matter because they worked on a project that never shipped (regardless of how much or how little they contributed to the failure)? Just replacing it with an AWS bill-measuring contest?
But yeah, when I hear "STOP MAKING SERVICES AND FACTORIES AND INTERFACES AND JUST READ THE FUCKING JSON FILE YOU ENTERPRISE FUCKERS" I think "developer who's never worked on anything more complicated than a chat app, and isn't old enough to have learned humility yet".
Could just be a case of bad naming and it solves everything you're saying. But it sounds like pointless enterprise-y fuckery to me.
I would not say the same thing about `ConfigurationFileService : IConfigurationLoader` or something.
Any battle-hardened test suite is already a bestiary. Having a subfolder of diverse & exemplary config files, that could be iterated over, is not adding much to the pile.
I found out that our unit test suite would only pass when run under elevated credentials. Our internal developer tooling had been running under semi-privileged credentials for years, and was the usual way of triggering a full unit test suite run, so no-one really noticed that it didn't work when run at a lower elevation.
When run from a lower privilege, a unit test was failing because it was failing to write to a registry key. I first double checked that I wasn't accidentally triggering integration tests, or that the test should be tagged integration.
But no, we had simply failed to abstract away our registry writes within that service. Of course no unit test should be writing to the real registry, but this settings manager was just being new'ed up as a concrete class, and there was no interface for it, and so it was just naively making registry edits.
This settings class wrote directly to the windows registry as it's data-store wasn't noticed as an issue for years, because all the times it had previously been run, it had been under credentials which could access that registry key.
And yes, there are different ways we could have mocked it, but favouring a concrete class meant this registry edit was happening unnoticed across all our unit test runs. And I suspect this might have been behind some of the dreaded flaky test syndrome, "I just tweaked a CSS file, why did my PR build fail?". Because 99% of times it was fast enough that it didn't cause issues, but with just the right concurrency of test execution, and you'd have a problem that wouldn't show up in any meaningful error message, just a failed test "for no reason".
Why shouldn't unit tests read real-world files? Because that introduces brittleness, and an inherent link between tests. If you want fast and easy to parallelize tests they need to have no real-world effects.
A test suite which is effectively pure can be executed orders of magnitude more quickly, and more reliably, than one which depends on:
- Files
- DateTime.Now (Anywhere in your code. A DateTimeFactory which you can mock might sound ridiculous, but it's perhaps the best thing you can do for your code if your current code / tests run on real dateTimes. Even for production code, having a DateTimeFactory can be really helpful for relieving some timing issues. )
- Databases ( This is more "obvious", but still needs to be said! )
This can also be the difference between a test taking <1ms and taking <10ms.
As a final point, you're usually not wanting to "test the code that uses a config file", you want to test code which you don't care if it uses a config file.
The "Code that uses a config file" should be your Configurator class. What you actually want to test is some service which actually produces useful output, and that contains business logic.
Yes, "separation of concerns" can be taken too far, but having something else responsible for the manner in which your service is configured so that your service can just take in a business-domain relevant typed settings object is helpful.
As I've said elsewhere, config is actually a terrible example, because it's essentially a solved problem, MS released System.Configuration.ConfigurationManager ( https://www.nuget.org/packages/system.configuration.configur... ), and you should probably use it.
If you're not using that, you ought to have a good excuse. "Legacy" is the usual one of course.
I've got this in several places.
I have code that needs to check if other date is within two weeks of today. I have test data.
I could either modify the test data based on today's date (adding other logic to tests that itself could be faulty), do something while loading the test data... or have the date to be used for comparisons be injected in.
That date is July 1, 2018. It was selected so that I didn't have difficulty with reasoning about the test data and "is this a leap year?" or across a year boundary on January 1.
Its not a "I don't trust it to work across those conditions" but rather a "it is easier to reason about what is 60 days before or after July 1 than 60 days before or after January 1.
And returning to the point - injectable dates for "now" are very useful. Repeatable and reasonable tests save time.
EDIT: Found xnorswap's comment below about configuration, which makes sense I get - but as they mentioned, it does feel like "turtles all the way down".
So, for example, I could have a IGadgetStore with methods for creating, retrieving, updating, and deleting gadget instances and then I can have a bunch of different classes implementing that interface. An obvious example is to have a PostgresGadgetStore and a MysqlGadgetstore and CsvFileGadgetStore. If the user wants to implement their own store that I haven't written, they can.
It is.
Nowadays, .NET is usually able to do away with the abstraction cost of such interface abuse luckily, but it remains an additional item you mentally have to deal with, which isn't good.
Single-implementation interfaces are still considered an anti-pattern, and teams that over-abstract and mock everything out when writing unit tests usually just waste time in pursuit of multi-decade old cargo cult. These also often test that modules comprise of specific implementations and not whether they simply satisfy the interface contract, which is terrible. And often turn stateless parts of logic that could have lived on some static class into an interface and an implementation injected with DI, that is then mocked out, instead of just calling methods on a class. More difficult to remove, worse locality of behavior, does not answer the question "if tests are green, are we confident this will work in prod?", sadness all around.
I agree with your sentiment. It's much more practical to write functional and component-level tests with coarser granularity of individual test items, but with more extensive coverage of component inputs. There's a wealth of choices for doing this with little effort (e.g. testcontainers).
You can analogize this to non-software use cases. I've got phillips head and flathead screwdrivers and ideally don't want to have to worry about the specific qualities of a particular kind of screw when selecting one. It either has one slot on the head or two. That's the interface to the screw and it should be the only thing I have to worry about when selecting a screwdriver.
Unfortunately, this kind of thing can balloon out of control, and in the worst kinds of "enterprise" Java shops I was involved in deep into my past, where concrete classes were injected at runtime by xml file loaded into the framework, it was literally impossible to tell what code was going to do simply by reading it, because it is impossible to know what is being injected at runtime except by inspecting it during runtime. It's a pretty frustrating experience when reading an entire code base doesn't tell you what the code actually does.
I've worked in "legacy" nodejs code since node 0.x. Glad to hear that there might be hope of codebases that don't have this problem. I thought typescript would help, but I've learned that fancy generics can ensure that it's still quite possible to have no idea what something will actually do in a real world environment, you'll just have a lot more cognitive overhead in wondering about it.
To be clear, I love ts and fancy generics that try to impose a Haskell-like determinacy on js Object structure with exclusivity and exception guarantees and all the rest; I just also hate it/them, at the same time.
"Mock" can be a loaded word in this context, so please excuse me if I'm looking at it through a difference lens, but if you're using some sort of mocking set of tooling (like Jest or similar), I'd argue that those mocks are much more confusing than an interface with an implementation.
I personally love an interface because it defines the most narrow set of operations an object needs to support to be passed in, and the implementation of those are completely irrelevant for calling. In many cases, I personally find that a lot simpler and cleaner to read.
So in this case, is this entire file being handed to clients to do what they will with it? Does that make sense as an interface.
If you are building an app, and you want other parts of the app, or clients of the app, to use this data, does it make sense to just hand over the entire file as the interface.
Basically :
Programmer 1: "Hey man, show me your data interface so I can build a quick lookup on something"
Programmer 2: "here is the whole damn file, do whatever you want and leave me alone. Figure it out yourself, and no I'm not going to give you a schema and I'll change it whenever I want".
Because I always enjoy leaked code comments. It’s like “tell me how you really feel about this shitty bloated enterprise framework you are using”.
There were some good ones in the leaked windows source code, weren’t there?
The PII is likely log files that should have been erased nightly, but I don’t remember.
I know the guy that designed the architecture. He’s a friend that I’ve argued with about over-engineering things. He never cared if people understood his work, which is a common theme with old school engineering.
I would even venture to say that senior engineers are probably much better at documenting, writing clean code, not over engineer things. My personal experience is that bad engineers move into project management, administration much faster. Which is a problem in itself since they end up being the boss of the engineers that are better than what they are.
For the engineers themselves, though, I think it's a mixed bag when it comes to "older" ones. That is, correlations on just age in the field are weak. Sometimes they're great, sometimes they're really meh. Whether something is over-engineered or not really is case-by-case, part of the problem is sometimes something looks over-engineered but is just the normal thing to them by now, nothing special, even though its architecture handles a lot of concerns that a more naive and obviously not over engineered style would have produced. In that case, they're validated sooner or later.
Sometimes they're more up to date about various new things than even the energetic young bucks, sometimes they're too stuck in their ways. I've seen examples of both knowing about modern hardware details (and being able to take advantage of them) and having a stale idea of how CPUs work that wasn't even quite accurate in the 70s. (So, not too different from a lot of fresh engineers who get educated on such simple models.) I've noticed no correlation with age on whether someone has completely mistaken ideas about JVM performance.
Being stuck in their ways in particular applies to things beyond the pure code and coding style -- and it's not necessarily a bad thing. If they've managed well so far without pick-any-of good documentation, good debuggers, good source control, good editors, good open source, methods to thoroughly avoid various causes of engineering pain, etc., why bother doing or taking advantage of those things now? And if they're skilled, they might even be right, it's probably best not to disrupt them if they're not a bus factor risk. But if they're more on the meh side of things overall, they can hold things back too much.
(By "older", I mostly mean those who were practicing since the late 90s/early 2000s. But I keep in mind that the global supply doubles every several years or so, so it's quite possible for someone with only around 5 years of experience to be in the top half of seniority already.)
Guys that adhere ruthlessly to their own framework designs without regard for onboarding timeframes.
They truly believe if you can’t understand their framework designs, you’re not smart enough.
I’ve always believed a critical aspect of software architecture is making sure the developers that will maintain it are a part of the design. If they’re junior and mid-level, your architecture better accommodate their skills.
Not in my experience.
These over-engineered systems usually came out of client server architectures using heavy inheritance object pyramids, which we definitely don’t build as much anymore.
I'm guessing not one person involved would have ever imagined their code being left on a machine just left out in the open exposed to the public completely abandoned by the company.
Given the era and constraints, I don't see how it was irresponsible or 'sloppy' to have a local database on these things. This most likely is not on development.
That's the problem. These things aren't getting collected and trucked off. They are just left rotting in their installed locations. I'm pretty confident that you could just show up to any of these with a tool box to just start opening one up to take out whatever you wanted from the insides, and not one person would question you. They already said they don't care if you never returned any discs you had in your possession, so nobody would care if you emptied their inventory of discs within. And until now, I'd wager not one person inside the company ever thought they might be vulnerable to a PII attack like this either.
But if you show up with a van or a large truck, they'd probably pay you money to take the whole thing off their hands. And you can tear it apart in your own garage.
how hard would it be to unplug the units? if these things are on a shared electrical circuit with anything else in the store, then that's on them. If they are separated, then just flip the breaker. otherwise, there's going to be j-box some where near the thing connected to some conduit. ten gets you twenty that there's some wire nuts in that j-box that could be disconnected in less than a minute.
also, just show up with a clipboard, and if anyone asks you, just say you were hired to collect certain items from within but not remove the entire thing. just print up a fake work order. i don't think i'm thinking too far outside the box on this one.
I often wonder what was left behind when the financial crash happened. Watching documentaries and movies about it, it looked me like several large banks and insurers closed up shop overnight, and people were leaving the next day with boxes containing their personal effects.
> the unit I've got an image for has records going back to at least 2015.
Whether or not it's "on development" -- that's sloppy. Like how it would be a problem if your preferred grocery store kept your details on the cash register you checked out through almost ten years ago. It's a point-of-sale terminal holding on to high risk data for no reason.
CSS just stopped paying vendors before the Redbox acquisition to make their balance sheet look better then just never paid after that until going bankrupt a year later. (My company was a vendor who had to get our attorneys involved to reclaim some payment prior to their bankruptcy and will never get the rest)
I’ve seen a bunch of these SPAC style (there’s usually some sort of penny stock starting point so the company is publicly traded from the jump) rollups of bankrupt or failing media and entertainment brands over the years and they all blow up.
When a customer has a problem, you create a solution to it. Often the problem is part of a much larger space, so you tend to have discussions of all the possible features you could implement. This is a necessary step to gain knowledge about the problem space, but it can lead you to think that the solution have to cover it all
Time restraints leads to a "temporary" feature to solve the customer's immediate need. Most of the time it turns out that all the other features are neither necessary nor important enough to spend time on.
Projects without time restraints or focus tends to create a complex system that will "solve" the entire problem space. Most of the time it turns out that our assumptions are wrong and we need to do a major refactoring.
"Temporary" solutions may not have the best code structure or architecture, but it is not necessarily a bad technical debt, as many new developers to the project seems to think it is. Also, the time restraints of a temporary solution encourages the developer to create simple code and not "clever" code, because they can always blame time restraints for their lack of cleverness. If the code has been mostly unchanged for years, somewhat maintainable and solves the customer's problems, it's not really a problem.
Picking up the latest and greatest web stack today will likely be a rotting, unused stack next year. Pick up rails or django and it will be largely unchanged and you'll still be able to hire for it.
Also, this really is the 'engineering' discipline with the lowest level of craftsmanship and regard for rigor, isn't it? Because the failures are usually intangible, not directly life-threatening.
I have a feeling that someone already had that hammer ready and was in search of a nail. :)
Earlier, Foone finds a NUC:
I've seen a lot of stuff in e-waste. There are several facilities within 5 miles of my home, and you can walk right in and drop off your old TVs, toasters and laptops in large metal bins. And if you have a quiet word with the attendant you can usually walk off with stuff that someone else dropped off. "Good for the environment mate! I can use this for parts!"
If social engineering works at banks, you can be damn sure it works at an e-waste facility. And if that fails, a few bank notes help.
I don't do this but I have intercepted e-waste coming from family and friends. In one case I found a treasure trove of photos from my deceased sister. Nobody had ever seen them before. I also found personal documents, internet history and saved passwords in the browser, which got me into her iCloud account which, until then, nobody could access. This lead to more photos and documents. And it was all destined for e-waste.
In my country, there are specialist e-waste disposal companies large IT organisations can hire, which guarantee to remove and shred the hard drives before recycling the rest.
Companies leaving their waste as someone else's problem to deal with is a common occurrence (heck, even before they go bankrupt), and in many cases they would never have existed in the first place if they had to pay for all of it, for instance :
https://www.desmog.com/2019/12/20/fracking-oil-gas-bankruptc...
(Note also that there are funds set aside for cleanup, but they are typically woefully insufficient.)
How to prevent companies that are a net negative for society from existing remains an unsolved problem.
(Aside of course from disallowing companies altogether, I wonder when is the point that the limited liability company as a concept is a net negative to society ? Could it be in the past already ? Of course comes the question of whether any alternative can have a positive contribution, in a context of overshoot...)
This is the relevant bit. It's cheaper just to pile the old computers in storage vs doing something about it.
Its not that such entities that will correctly handle the e-waste don't exist, its that the company doesn't want to pay to have it donem esp when storage is cheap, let those containers of old laptops and towers be someone else's (budgetary) problem.
Now that storage is often an indistinct chip on the motherboard, I wonder how that works.
They built new infrastructure at the new site, then just decommed the old building.
Pretty standard stuff, but the old building was like, 1930s era or something. After the hardware was deracked, it was left in a loading dock, in a now abandoned building, behind an unlocked roller door for like 6 months before it was recovered for data destruction.
The only companies that do a proper job are the ones that turn up to your office and shred the hardware in front of you. Paperwork is worth shit otherwise.
99% of the stuff they sent us was boring corporate desktops running standard, secure soe.
1 laptop however, booted into windows with saved credentials, connected to a vpn automatically, logged into the rail companys in house software automatically, and began displaying what I can only assume was a live map of the rail network. Little green lines running along red lines, the green lines would come to junctions and stop. It had buttons. I think I shucked the hard drive and drilled it within 60 seconds and had the hardware completely disintegrated.
One other time a games company that got liquidated sent us a pallet of computers that had source code for a relatively popular strategy game on the drives.
Another games company shipped us their test kits one of which had a dev build of a relatively well known action adventure game. The warehouse guys would play the dev build of the game on their lunch breaks.
Basically no one gives a shit.
All of that before I worked for a business that stored their customer info including credit cards in plain text one dirwalk away on their public website. When we complained we were told that it was fine because they "encrypted" the card numbers. The encryption was adding 1 to the card number. I died.
On a codebase I worked on, accepting an expanded range of data in a field required modifying seven files in three repositories and two (or three) programming languages. Someone thought that's the right way of doing it.
This does not seem to be an isolated case, it just happening more and more with advance of technology.
One could do the same for pii. Of course it's cheaper not to, so I'm not sure if anyone actually does this kind of insurance policy
In the former, short of dying, it’s not possible to “disappear,” because you’re personally liable for everything. I’d guess that includes data breaches.
In the latter, it’s also not really possible because the company must be wound up if it goes bankrupt. In the worst case, the government appoints administrators to wind the company up, who would be responsible for handling the assets.
Now, if the processes aren’t up to scratch, maybe that’s a thing that needs to be fixed, but the structure is there to do it. At least in the UK.
But this does not answer my question. So basically many people here are unaware where such legal framework exist at all.
Because if you have to invent the config file then isn't that creating a DSL and we're back to over engineering?
For configuration these days XML is generally not used, they have a configuration system which can use a variety of underlying sources (like environment variables and JSON files) and you can either access these settings by key from a dictionary or trivially hydrate a plain old C# classes, including with collections.
People may still manually read their own configuration independent of this system or perhaps they’re just generally deserialising XML.
There are (I think) at least a few ways to work with XML in .NET.
For well known schemas I definitely generally recommend the C# class approach where you somewhat simply deserialize a file into well typed C# classes.
From your question it sounds like the XML API which allows you to arbitrarily query or manipulate XML directly was used here. I have on occasion used this when I don’t have the full schema for the XML available and need to tweak a single element or search for something with XQuery. It’s a useful tool for some scenarios, but a poor choice for others.
You mean a separate function? Or a separated method in some class? (Given that C# can't do top level functions...)
Or else, you may want a type parametrized function that uses reflection to populate an object of any class you want. That would depend on how many different kinds of file you have, but the C# standard library has this function so you just use it.
It's also been a long while since I wrote any C# for real, and even longer since I had to deal with .NET's XmlSerializer.
It used to be a pain in the backside to deal with XML in .NET if you wanted to just deserialise a file to an object. You'd need to mark up the class with attributes and stuff.
I remember being very happy when JSON.NET came out and we could just point at just about any standard object and JSON.NET would figure it out without any extra attributes.
I'm not sure if XmlSerializer ever caught up in that regard.
e: Also, without seeing the code and where else it might be deployed it's not easy to know whether this is a case of over-engineering.
This same code might be deployed to a phone, webserver, lambda, whatever - so having an IConfigFileLoader might make 100% sense if you need to have another implementation that'll load from some other source.
Not really. The one thing that exists to make this easier is xsd.exe, which can generate the code for these classes from and XML Schema file.
https://learn.microsoft.com/en-us/dotnet/standard/serializat...
I had a ton of scripts that generated classes from XML and SQL Tables. I forget exactly how.
This format is so tedious to read - one sentence fragment at a time. It's like reading someone's subconscious inner-dialog shower thoughts.
Every time I would go browse their movie collection I always walked away uninterested in anything. Most of it was what I call direct-to-inflight-video.
Perhaps a better description would be "even worse than Netflix originals"...
The only real regression I've seen in my life time in in-flight entertainment is ANA removing their partnership with Nintendo to run SNES emulators to all the seats. A 14 hour flight to Narita used to involve Super Mario All Stars
The movie was about a brother who returns to a small town to visit his sister in a southern town. He ends up staying and helping her with the kids. But his irresponsible ways causes frustration with the sister and the kids he is watching. He leaves. End of movie.
Truly awful. I wonder what the first movie was like.
It would be in the early 2000s. Let me try AI. Found it. What an age we live in.
You Can Count on Me - 2000 Sammy is a single mother who is extremely protective of her 8-year old son. She is satisfied with living in the small town she grew up in and working in a local bank. When her brother Terry visits he fits the void in the life of both her and her son. Temporarily free of the constraints of single motherhood she begins to break free of her normal routine. In a string of traumatic events Sammy is torn between helping her brother and her maternal instinct to protect her son from getting hurt.
95% rotten tomato score. Someone liked it.
Sidenote: As a personal mental quirk, does anyone else ever accidentally read "Redbox" as "Roblox" and then have to double-check?
Tried to convince them to stop, and even setup a service on lunch breaks to attempt and sanitise them using open guidelines available at that time - an automated service that would display drive sanitisation status on a text based panel next to a multi disk bay caddy in the storage room.
I resigned because of this, and many other similar business practices - all just to make more money (it was not malicious otherwise).
The business is rather successful to this day. I only hope they have stopped such activities.
And yet I still lose sleep about this..