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

121–130 of 173 posts

Re: Redbox left PII on decommissioned machines

#121

Post by stickfigure »

pphysch wrote: post #105
stickfigure wrote: post #79

Earlier quoted context omitted.

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.

A totally reasonable approach! Sometimes.

Re: Redbox left PII on decommissioned machines

#122

Post by nucleardog »

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…

The interface in question is `IConfigurationFileService`. I can only guess at the actual interface, but based on the name it doesn't sound like it's abstracting away the need to put your configuration into files.

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.

Re: Redbox left PII on decommissioned machines

#123

Post by wtallis »

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…

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

Re: Redbox left PII on decommissioned machines

#124

Post by scrapcode »

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, that's called a fucking integration test.

Re: Redbox left PII on decommissioned machines

#126

Post by adolph »

Kon-Peki wrote: post #111
dylan604 wrote: post #95

Earlier quoted context omitted.

> and everything suddenly gets trucked-off into receivership. 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'…

The host locations are pissed off that the machines are sitting there taking up space and using electricity. They certainly aren't going to be happy with someone opening it up and making a mess. Or potentially creating some sort of additional liability for them. 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…

Theres probably lots of great robot disc handler stuff in those boxes.

Re: Redbox left PII on decommissioned machines

#127

Post by macintux »

Moru wrote: post #34
gscott wrote: post #25

Earlier quoted context omitted.

The beta version works fine, lets just keep it.

Never make the "Proof of concept" so good it is actually usable.

Write the proof of concept in a language that the company doesn’t want to support. Erlang, Haskell, Prolog.

Re: Redbox left PII on decommissioned machines

#128

Post by adolph »

michaelt wrote: post #40
raffraffraff wrote: post #37

Earlier quoted context omitted.

I know an employee in an IT company. He told me that they have hundreds of decommissioned laptops and no time to wipe them. And they won't pay someone else to do it because it's too expensive. So right now they are in storage. If they go bust, the storage company will likely dump them. 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 y…

> I've seen a lot of stuff in e-waste. [...] if you have a quiet word with the attendant you can usually walk off with stuff that someone else dropped off. 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.

> guarantee to remove and shred the hard drives

Now that storage is often an indistinct chip on the motherboard, I wonder how that works.

Re: Redbox left PII on decommissioned machines

#129

Post by miningape »

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…

You're mixing definitions - integration tests concern testing the "integration" between all parts of a solution. It has nothing to do with reading a JSON file, its perfectly acceptable to read from a JSON file and use its data in a unit test.

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.

Re: Redbox left PII on decommissioned machines

#130

Post by rbanffy »

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…

> And not when you want to have lots running in parallel, accessing and potentially making "changes" to the same files.

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.

Post reply on HN