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

51–60 of 173 posts

Re: Redbox left PII on decommissioned machines

#51

Post by guax »

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…

Why do you need the interface? You can extend/mock the class itself. Refactoring code is easy and cheap. There is no reason for complex abstractions that protect implantation outside of libraries and frameworks.

Re: Redbox left PII on decommissioned machines

#52

Post by ChicagoDave »

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 common theme with old school engineering.

Re: Redbox left PII on decommissioned machines

#53

Post by guax »

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…

The good practice of last year is the bad pattern of today.

Re: Redbox left PII on decommissioned machines

#54

Post by throwaway365x2 »

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.

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 testing. Adding complexity in the name of TDD is a close second on my list of triggers

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.

Re: Redbox left PII on decommissioned machines

#55

Post by hggigg »

jordigh wrote: post #5

Where does Foone keep finding this stuff? Earlier, Foone finds a NUC: https://news.ycombinator.com/item?id=41294585

I know someone who worked at a recycler who was paid to physically destroy and certify media as destroyed. It took time and money to destroy media so it just sat in a warehouse for months and the paperwork was lies. Eventually they went bankrupt and another company bought the stock and sold it on eBay by the palette load as is.

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.

Re: Redbox left PII on decommissioned machines

#56

Post by xnorswap »

throwaway365x2 wrote: post #54
xnorswap wrote: post #50

Earlier quoted context omitted.

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.

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…

I'm sure the same exists for .NET ( Moq can probably do it? ), but writing against an interface and having concrete implementations supplied by the DI framework is pretty much the ordained way to do things in .NET.

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.

Re: Redbox left PII on decommissioned machines

#57

Post by proikan »

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…

Isn't ```dependency injection``` (aka passing arguments) the big thing that's supposed to solve this?

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

Re: Redbox left PII on decommissioned machines

#58

Post by xnorswap »

proikan wrote: post #57
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…

Isn't ```dependency injection``` (aka passing arguments) the big thing that's supposed to solve this? 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);

Yes, and the typical pattern for .NET DI is to do so with interface based parameters.

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
    }
Then elsewhere you'd set up your DI framework to inject your ConfigFileService to satisfy IConfigurationService in prod.

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.

Re: Redbox left PII on decommissioned machines

#59

Post by throwaway365x2 »

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

I'm sure the same exists for .NET ( Moq can probably do it? ), but writing against an interface and having concrete implementations supplied by the DI framework is pretty much the ordained way to do things in .NET. 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 standard…

I think you have good approach. I also tend to go with the flow and follow the common practice. If I tried to do "Java in C#", it would make it more difficult to follow my code and decrease maintainability.

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.

Re: Redbox left PII on decommissioned machines

#60

Post by Jerrrrrrry »

throwaway365x2 wrote: post #59
xnorswap wrote: post #56

Earlier quoted context omitted.

I'm sure the same exists for .NET ( Moq can probably do it? ), but writing against an interface and having concrete implementations supplied by the DI framework is pretty much the ordained way to do things in .NET. 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 standard…

I think you have good approach. I also tend to go with the flow and follow the common practice. If I tried to do "Java in C#", it would make it more difficult to follow my code and decrease maintainability. 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…

You are both over thinking it.

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#
Coincidentally, that is where my patience for abstraction for C# had finally diminished.

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.

Post reply on HN