I don't think so. The cabinets were silk screened, but the control panels and marquees were different. The marquees, in particular, are large vinyl stickers that cover glass. Control panels were generally not silk-screened, either.
Volume was roughly similar (thousands to low tens of thousands of cabinets).
Things differed from game to game over time. My Missile Command had a silkscreened control panel, but I think they went to overlays which were more durable and could be replaced.
Go has good (enough) built-in arrays and maps. But if you want a tree, without generics, you're really limited. With generics, you can get a nice containerized type, but you don't get the nicer syntax that the builtins have.
It's not just types, either. Look at the signature for the built-in sort, which is amazingly cumbersome to use. A generic wrapper around it hides all the ugly.
Halted was an electronics surplus store. A really good one. They had old tubes, old ICs, stuff left over from Atari. They had aisles of capacitors, some with date codes in the mid '80s, and newer surface mount stuff. They had a whole wall of 1/4 W resistors at two cents a piece. They had all kinds of random parts for keeping old electronics running, and making new stuff. And they had a receipt for an oscilloscope they sold in the '60s to some kid in Palo Alto named Steve Jobs.
Unfortunately, the owner retired and sold it off for parts.
Seems like it should work for arbitrary byte strings (any charset, any encoding)but obviously the performance characteristics will differ because of non-uniform distribution. But that happens even in ASCII.
SASL came out as a generalization of the IMAP AUTHENTICATE mechanism. CMU wanted Kerberos to work and it had been done as something of a one-off in telnet, and initially in IMAP. There were a couple companion protocols proposed for IMAP (stuff like contacts) that the same group was working on, and they wanted to leverage the same mechanism. From there, might as well do the same thing for POP and SMTP, etc. So they started working on a library (which Cyrus IMAP didn’t use for at least a while, sorry my fault).
Kind of funny that SASL is the most durable piece of the effort.
(I doubt this is entirely accurate. I wasn’t there for a lot of it.)
DI at LinkedIn was used for development, for unit test isolation, and to reduce tight coupling.
One big problem with a giant "Application" class is that it means all of the dependencies are laid out there, and their dependencies, and their dependencies, all named and instantiated. But some dependencies are in libraries, and basic detail encapsulation means ... a factory.
Offspring wasn't much of a framework, more of a set of conventions and utilities for building that stuff in plain Java code (with key annotations). In particular, I think the Offspring setup wasn't opinionated about the framework of the rest of the application, although other parts of LinkedIn were (and presumably still are).
I overlapped at LinkedIn at the same time as the author. While there, I wrote my first (and to date only) FactoryFactory.
LinkedIn replaced its uses of Spring with a thing called Offspring. Offspring explicitly disavowed being a dependency injection framework, but it did a similar job for us. I rather liked it. Notably, you just wrote Java with it. Invariably, in Offspring, you'd have to write a FooFactory to construct your Foo object to inject it into some (other class. By convention, all of the factories ended in Factory.
Well, I had a use case for a runtime class that needed to make a per-request factory to make little objects. So to make my Bars, I needed a BarFactory; and to construct the BarFactory, I needed an Offspring factory, thus BarFactoryFactory. There it was. I felt a little weird after that.
I suspect the EventFactoryFactoryFactory code here was such an Offspring factory being used for dependency injection, but I can't explain why it produced a FactoryFactory.
Hear, hear! I used a 2018 MacBook for a little over a year; my work laptop is now a ThinkPad running Linux. My personal laptop is a 2015 MacBook. When it dies, I will not replace it with a butterfly-switch laptop.
(I also miss USB type A and MagSafe, but the keyboard was the deal breaker.)
Volume was roughly similar (thousands to low tens of thousands of cabinets).
Things differed from game to game over time. My Missile Command had a silkscreened control panel, but I think they went to overlays which were more durable and could be replaced.