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

141–150 of 173 posts

Re: Redbox left PII on decommissioned machines

#141

Post by IggleSniggle »

nonameiguess wrote: post #101
abrookewood wrote: post #72

Earlier quoted context omitted.

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 applic…

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

Re: Redbox left PII on decommissioned machines

#142

Post by IggleSniggle »

miningape wrote: post #140
IggleSniggle wrote: post #137

Earlier quoted context omitted.

There's a lot of room for nuance. If you "just read the fucking file" but the file isn't a "real" configuration file then isn't it just a "mock?" If you replace all network calls with an interceptor that forwards all calls and responses, and just check what's happening as a "listener," aren't you mocking out the network calls to a non-real implementation? At the end of the day, tests are necessarily a mock-up of what…

Yeah don't get me wrong, I'm not anti-mock - real code is messy, and the ideal of the same tests running everywhere will never work, so mocks are necessary. But I do think there's a lot more harm from over-mocking, than under-mocking. > 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 informa…

Just to work this out together a little more in discussion form, since I appreciate your attitude:

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.

Re: Redbox left PII on decommissioned machines

#143

Post by Jach »

JoachimS wrote: post #70
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…

Not an old school engineering. There a fresh engineers rolling of the production line everyday that behaves exactly like this. 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…

I agree on the management aspect, and even promoting good engineers "too high" on the "parallel promotion track" can effectively take them out of the engineering work just as much as if they went into pure management. "Does the CTO still code at least sometimes?" is the only tell I have for whether a company has fallen into that trap or not.

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

Re: Redbox left PII on decommissioned machines

#144

Post by pnw »

Kon-Peki wrote: post #134
adolph wrote: post #126

Earlier quoted context omitted.

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

There was an article in some source (sorry, I forget which) that interviewed a person somewhere in the Southeast US that has been paid to remove a dozen or two of them. It had some photos of the inside of the machine. You should look for it!

There's a Discord where people are sharing ideas on sourcing and modifying the kiosks. https://discord.gg/ZNXy722W5t

Re: Redbox left PII on decommissioned machines

#145

Post by miningape »

IggleSniggle wrote: post #142
miningape wrote: post #140

Earlier quoted context omitted.

Yeah don't get me wrong, I'm not anti-mock - real code is messy, and the ideal of the same tests running everywhere will never work, so mocks are necessary. But I do think there's a lot more harm from over-mocking, than under-mocking. > 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 informa…

Just to work this out together a little more in discussion form, since I appreciate your attitude: 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…

yeah - I don't think we should go so far as to write a config file for a test. But if we have something that is already readily convertible to/from json, it should be used. Not seeing it so much as a config for a test but as an argument we're storing in a separate file.

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.

Re: Redbox left PII on decommissioned machines

#146

Post by PyWoody »

cruffle_duffle wrote: post #93
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 am lost is that a code comment or the author commenting on something they found? 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?

I'm sure you've seen this, but "The Simpsons Hit & Run Source Code Comments, Read by Comic Book Guy" (https://www.youtube.com/watch?v=R_b2B5tKBUM) is an all-timer.

Re: Redbox left PII on decommissioned machines

#147

Post by throwaway365x2 »

pylua wrote: post #82
throwaway365x2 wrote: post #54

Earlier quoted context omitted.

I don't follow .Net closely, but it seems like there should be a better alternative. Java has a library called "Mockito" that can mock classes directly without requiring an interface. I assume something similar exists for .Net, as they have similar capabilities. Making an interface for one class, just so another class can be tested seems like we allow the tool (tests) to determine the architecture of what it is testi…

What’s wrong with having an interface with one implementation ? It’s meant to be extended by code outside the current repo most likely. It’s not a smell in any sense.

In that case you have more than one implementation, or at least a reasonable expectation that it will be used. I don't have a problem with that.

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"

Re: Redbox left PII on decommissioned machines

#148

Post by Alupis »

As an aside, I see we've re-invented Twitter-style blog posts - but did anyone stop and ask why?

This format is so tedious to read - one sentence fragment at a time. It's like reading someone's subconscious inner-dialog shower thoughts.

Re: Redbox left PII on decommissioned machines

#149

Post by bombcar »

adolph wrote: post #128
michaelt wrote: post #40

Earlier quoted context omitted.

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

About as well as it always did, which was some variation between “they shredded it whilst I watched” and “they probably wiped it before letting someone take it home” to “it shows up on eBay in three days untouched.”

Re: Redbox left PII on decommissioned machines

#150

Post by qwertycrackers »

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…

Your unit tests should just take the result of loading the file as an argument or other type of injection param. Then you can hardcode your unit test config parameters in the test code itself. That's the appropriate place for this kind of indirection.
Post reply on HN