Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Redbox left PII on decommissioned machines

digipres.club

Post reply on HN
Print view View original

101–110 of 173 posts

Re: Redbox left PII on decommissioned machines

#101

Post by nonameiguess »

abrookewood wrote: post #72
xnorswap wrote: post #46

> Redbox.HAL.Configuration > .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…

Kind of off topic, but can someone explain why else C# has factories and interfaces? Is it just mocking? I really don't understand the pattern at all. FWIW I am no dev. 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".

I don't think it's off-topic at all. The ideal this kind of thing is trying to achieve is separation of concern. One developer or team or even entire organization is writing things like serializers for specific kinds of file formats or other sources of persisted data like databases and environment variables or things like the Java Springboot externalized config. Another organization is just trying to create an application that requires configuration. They don't necessarily want to have to worry too much about where it comes from. Especially in places that strictly separate development and operations, they'll probably have no say anyway and it'll change over time and they're not gonna want to change their own code when it does.

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.

Re: Redbox left PII on decommissioned machines

#102

Post by mempko »

aidenn0 wrote: post #96
xnorswap wrote: post #46

> Redbox.HAL.Configuration > .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…

If you need to make your code more baroque and harder to understand in order to unit-test it, that seems like the tail wagging the dog.

Exactly! It's like that Skinner Simpsons meme. Are unit tests the problem and I'm wasting my time? No, it's the config files that are wrong.

Re: Redbox left PII on decommissioned machines

#103

Post by xnorswap »

burnte wrote: post #100
xnorswap wrote: post #46

> Redbox.HAL.Configuration > .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…

> 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. 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. Th…

Those are integration tests. Integration tests are great, but not when you want to run thousands of them in a few minutes. And not when you want to have lots running in parallel, accessing and potentially making "changes" to the same 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
and

    function string -> parsedType -> result
The second is cleaner and neater, and you can separately test:

    function string -> parsedType
    function parsedType -> result
The second is more testable, at the cost of being more indirect.

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.

Re: Redbox left PII on decommissioned machines

#104

Post by consp »

xnorswap wrote: post #103
burnte wrote: post #100

Earlier quoted context omitted.

> 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. 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. Th…

Those are integration tests. Integration tests are great, but not when you want to run thousands of them in a few minutes. And not when you want to have lots running in parallel, accessing and potentially making "changes" to the same 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…

Unit test are nice to have if you want to make test coverage or have sufficient time to implement them properly. In practice they contain only vague assumptions (the test passes, but the integration stops due to those assumptions being false) or contain things any basic code review should catch (and if you keep paying peanuts they won't do that so you make more unit tests).

Re: Redbox left PII on decommissioned machines

#105

Post by pphysch »

stickfigure wrote: post #79
rcxdude wrote: post #74

Earlier quoted context omitted.

But why is it so hard to read a file during a unit test? Files are pretty easy to mock in many different ways, all of which are pretty fast. You don't need a special-purpose interface to be able to test the code that uses a config file.

Let's say you want to test bootstrapping your system with various configurations. 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…

> Now you're maintaining a bestiary.

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.

Re: Redbox left PII on decommissioned machines

#106

Post by pphysch »

throwaway365x2 wrote: post #63
Dalewyn wrote: post #29

Earlier quoted context omitted.

There is nothing more permanent than a temporary solution, and nothing more temporary than a permanent solution.

That's very true. 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 imm…

I agree. Temporary / bandaid solutions are totally great if they are straightforward to implement AND unimplement.

Re: Redbox left PII on decommissioned machines

#107

Post by jessekv »

burnte wrote: post #100
xnorswap wrote: post #46

> Redbox.HAL.Configuration > .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…

> 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. 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. Th…

Yeah modeless software is one honking great idea. (RIP Larry Tesler)

Re: Redbox left PII on decommissioned machines

#108

Post by 01HNNWZ0MV43FF »

scott_w wrote: post #71
nextlevelwizard wrote: post #35

Earlier quoted context omitted.

What are they going to do? Sue the bankrupted company?

If a company dealing in toxic chemicals goes bankrupt, is it functionally legal to just dump them in the nearby river? I’d be amazed if countries don’t have legal processes in place to deal with situations like this and maybe the courts haven’t caught up to this use case?

I think there's supposed to be an escrow account where you say like "I'm going to handle X amount of petrol / nuclear material, here's a big pile of cash set aside for cleanup if I dissolve"

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

Re: Redbox left PII on decommissioned machines

#110

Post by flomo »

qwery wrote: post #77
flomo wrote: post #31

Earlier quoted context omitted.

They might have had the most perfectly developed decommissioning process. And nobody is going to care when their paychecks stop showing up, and everything suddenly gets trucked-off into receivership. 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.

I think you're right in general -- that is, regardless of the original company's practices, the entity selling off the assets should be required to do that responsibly -- but then: > 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 chec…

I recall being surprised to see people using a Redbox in the grocery store. Like, wow, (a) this company still exists, and (b) ppl still watch DVDs. And that was years ago. I think it's not unlikely the company was already in total zombie-mode by 2015.
Post reply on HN