It's insane to me that Stripe cancels accounts when they get used for card testing. I get that it's because the onus would be on them otherwise, but the problem is that the onus is on anyone but the card companies in the first place.
Nonviolent noncompliance, work stoppages, boycotts, sanctions, divestment, and further peaceful and effective measures until there are uniformly people in critical positions of power not beholden to the billionaire robber barons. Make it a criminal offense to be a paid lobbyist, abolish PACs and Citizens United, and every elected official profiteering. Keep going until wealth is firmly subordinate to civil authority. There is no perfect or magical plan that can be conveyed by a few sentences, so if you're out for a gotcha answer, you're not going to find a risk-free, batteries-included, cookie cutter blueprint anywhere from anyone.
PFS is valuable largely in stable, small groups that rarely change shape or association.
PFS in an open, freely-associable environment is far more complicated when you move beyond even the smallest of group sizes. Realistically, once the group size is beyond Dunbar's number you can reasonably assume that PFS is moot, because you no longer can depend on maybe four or five people's personal security, but 150+. Statistically, someone's opsec failure will be guaranteed.
You can if the manufacturer has a track record that refutes the notion, and especially if they have verifiable hardware matching publicly disclosed circuit designs. But this is Intel, with their track record, I wouldn't trust it even if the schematics were public. Intel ME not being disable-able by consumers, while being entirely omitted for certain classes of government buyers tells me everything I need to know.
It's simple. Don't comply. Software engineers, despite not having the same requirement of mechanical engineers, should uphold the ethical obligations of their craft. This law is harmful. Given the requirement of compelled speech, given code has been _proven_ to be such, Do. Not. Comply.
I had the same confusion reading this – what kind of go-based webservice framework can you discretely deploy new handlers without restarts/redeploys? Would be a really awesome thing to have!
TBH it sounds like it would be extremely against the whole "simplicity, even at high costs" philosophy the Golang people strive for. Deploying new handlers into a running web service seems much more like something the Erlang people would be interested in.
(and lo, the BEAM does indeed allow hot code reloads. I don't think this is commonly used in BEAM-based Erlang/Elixir web services though. Certainly the Gleam people don't seem to like hot reloads very much...)
Any good rule of thumb like the one in GP's comment is wrong sometimes, and that's ok. Adding more caveats just dilutes it without ever really making it watertight (if you'll forgive the very mixed metaphor).
But even in complex applications, there's still truth to the idea that your code will get simpler over time. Mostly because you might come up with better abstractions so that at least the complex bit is more isolated from the rest of the logic. That way, each chunk of code is individually easier to understand, as is the relationship between them, even if the overall complexity is actually higher.
The best code, eg for embedded systems, is as simple as it can possibly be, to be maintainable and eg to let the compiler optimise it well, possibly across multiple targets. Sometimes very clever is needed, but the scope of that cleverness should always be minimised and weighed against the downsides.
Let me tell you about a key method in the root pricing class for the derivs/credit desk of a major international bank that was all very clever ... and wrong ... as was its sole comment ... and not entirely coincidentally that desk has gone and its host brand also...
Simple code means just doing the thing. It's often misinterpreted to mean code made of lots of small pieces (spaghetti with meatballs code) but this is simply not the case. Often, avoiding abstractions leads to simpler code.
At my job we're disqualifying candidates who don't use enough unnecessary classes. I didn't use them, but they proceeded with my interview because I happened to use some other tricks that showed good knowledge of C++. I think the candidate who just wrote the code to solve the task was the best solution, but I'm not in charge of hiring.
Without revealing the actual interview task, let's pretend it was to write a program that lowpass filters a .wav file. The answer we're apparently looking for is to read the input into a vector, FFT it, zero out the second half, unFFT it, and write the output file. And you must have a class called FFT, one called File, FrequencyDomainFile, and InverseFFT. Because that's simple logical organization of code, right? Meanwhile, the actual simple way to do it is to open the input and output files, copy the header, and proceed through the file one sample at a time doing a convolution on a ring buffer. This latter way involves less code, less computation, less memory, and is all-around better. If you think the ring buffer is too risky, you can still do a convolution over the whole file loaded into memory, and still come out ahead of the FFT solution.
But if you do it this way, we think you didn't use enough abstraction so we reject you. Which is insane. Some time after I got this job, I found out I would have also been rejected if not for a few thoughtful comments, which were apparently some of the very few signals that "this guy knows what he's doing and has chosen not to write classes" rather than "this guy doesn't know how classes work."
> Often, avoiding abstractions leads to simpler code.... But if you do it this way, we think you didn't use enough abstraction so we reject you.
I think you've unwittingly bought into your hiring team's fallacy that classes are somehow essential to "abstraction". They are not. Wikipedia:
> Abstraction is the process of generalizing rules and concepts from specific examples, literal (real or concrete) signifiers, first principles, or other methods. The result of the process, an abstraction, is a concept that acts as a common noun for all subordinate concepts and connects any related concepts as a group, field, or category.[1]
The fundamental abstraction in computer programs is the function. A class is principally a means of combination that sometimes incidentally creates a useful (but relatively complex) abstraction, by modeling some domain object. But the most natural expression of a "generalized rule" is of course the thing that takes some inputs and directly computes an output from them.
Of course, we also abstract when we assign semantics to some part of the program state, for example by using an enumeration rather than an integer. But in that case we are doing it in reverse; we have already noticed that the cases can be generalized as integers, and then explicitly... enumerate what it is that we're generalizing.
(The reason that "FFT" etc. classes are so grating is that the process of that computation hardly makes sense to model; the input and output do, but both of these are just semantic interpretations of a sequence of values. You could staple a runtime "time-domain" or "frequency-domain" type to those sequences; but the pipeline is so simple that there is never a real opportunity for confusion, nor reason for runtime introspection. I almost wonder if the hiring team comes from a Java background, where classes are required to hold the code?)
If I were writing the convolution, it would still probably involve quite a few functions, because I like to make my functions as short as feasible, hewing closely to SRP. Perhaps the ring buffer would be a class — because that would allow a good way to separate the logic of accessing the underlying array slots that make the ring buffer work, from the logic of actually using the ring buffer to do the convolution.
(I'm not sure offhand what you'd need to convolve with to get the same result as "zeroing out the second half" of the FFT. I guess a sinc pulse? But the simple convolutions I'd think of doing to implement "low-pass filter" would certainly have a different frequency characteristic.)
Well, I substituted the task for a different but related one, so the substitute task is not fully specified in detail and perfectly mathematically correct - just good enough to show the principle.
We have given extra points to a candidate for having an FFT class even though it should obviously be a function. And the comments clearly indicated that candidate simply thought everything should be a class and was skeptical of things not being classes.
reply