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

111–120 of 173 posts

Re: Redbox left PII on decommissioned machines

#111

Post by Kon-Peki »

dylan604 wrote: post #95
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.

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

Re: Redbox left PII on decommissioned machines

#112

Post by jessekv »

consp wrote: post #104
xnorswap wrote: post #103

Earlier quoted context omitted.

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

A good interface is testable, this is how you build up reliable abstractions to solve higher level problems. The devs on my team that take shortcuts here waste more time in the end.

There is no cost trade-off.

Re: Redbox left PII on decommissioned machines

#114

Post by stickfigure »

dogleash wrote: post #90
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…

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

"Software at scale" is different from "data at scale" is different from "compute at scale".

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

Re: Redbox left PII on decommissioned machines

#115

Post by mikeryan »

flomo wrote: post #31
dylan604 wrote: post #2

Take this as a lesson. If you've been a dev long enough, you've worked on a project knowing that how the project is being done isn't the best method with every intention of going back to make it better later, but not at the expense of getting the MVP up and running. You'll also have seen that never actually happening and all of those bad decisions from the beginning still living all the way to the bitter end. I'm gue…

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.

The end of Chicken Soup for the Soul media (who owned RedBox and Crackle at the end) was a complete shit show. I’d be unsurprised if they just walked away from the DVD boxes leaving the whoever had them on their property with the job of dumping them.

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.

Re: Redbox left PII on decommissioned machines

#117

Post by ipaddr »

vitorfblima wrote: post #89
ipaddr wrote: post #28

Earlier quoted context omitted.

I didn't bring 5 dollars cash the first time I took a plane to SF from the east coast. You end up watching a movie on a projector screen without sound. I end up reading through Microsoft foundation classes books. On the way back I had my 5 dollars ready. 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 irrespons…

I'm 'kinda curious to know which movie is this.

I've been trying to figure it out for awhile.

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.

Re: Redbox left PII on decommissioned machines

#118

Post by neilv »

ChicagoDave wrote: post #52

I worked at RedBox in 2010. C# with embedded Lua for the screens. The intent was to build a flexible architecture for CoinStar to use on many kiosk businesses. 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 c…

> He never cared if people understood his work, which is a common theme with old school engineering.

Not in my experience.

Re: Redbox left PII on decommissioned machines

#119

Post by gregmac »

xnorswap wrote: post #50
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…

Could or should there just be a `IConfigurationService` instead of a separate IConfigurationFileService? Yes, probably. "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.

Yeah, IConfigurationService implies separation of concern. Code using it doesn't have to care where the configuration came from, just that it is there. Someone separately can write the concrete ConfigurationFileService:IConfigurationService that reads/parses files.

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"));
All that code that used IConfigurationService is completely untouched and unaware of any of this, letting whoever is doing this as part of changing deployment (or whatever) be productive quickly with very little knowledge of the rest of the (possibly massive) app.

Re: Redbox left PII on decommissioned machines

#120

Post by [deleted] »

xnorswap wrote: post #81
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.

Perhaps a better example is a real world example I ran into just this week. 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…

[deleted]
Post reply on HN