> You should validate that the request is signed correctly
I agree with you here, but wondering what you see the benefit of per-app PKI is, versus signing all webhooks with the same cert. Is it to prevent having to do a key rotation that would impact every webhook consumer?
If you specify one public key for all endpoints, It means all consumers can verify each other’s webhook data which is not what you want. You want each consumer to be able to verify only webhooks intended for them and fail otherwise.
We wrote a detailed guide on generating and rolling public key/secrets for your endpoints here [1]
> Hasn't this pandemic pretty well proved that when people aren't at the office they want a little more space?
Yea, and they want a pool and a free pony too. Given that people can't all get the housing they want, how do we solve for the housing problems we've run headlong into?
Building more housing is absolutely a meaningful way to attack the problem, and zoning reform is a part of that.
> Do people actually want to live in highrises in megacities? Or do they just do it so they can land a decent job?
Of course jobs are the driver here, but that means that incidentally, yes they do want to live in high-rises in megacities. There's no real sign of large cities releasing their hold on productivity and good paying jobs, the current remote work in a pandemic thing not withstanding.
> The zoning reform people only ever look at one side of that equation.
As someone who has faced the SF Bay Area housing crisis over the last ten years, I'd be fine with people moving out. But it's not a realistic solution, given that the good jobs are still here. Not to mention, there's not much we can do to reverse the economic incentives that bring people to places like San Francisco, but there is something we can do about local zoning rules. So it's entirely rational that people focus on building housing in these cities rather than trying to convince people not to move here in the first place.
Hey man, as someone who also formerly worked in a different industry, thank you for raising this question. The longer I'm in software development (six years now) the more confident I am that all the varying rationalizations for this stuff are complete BS.
Please keep raising these questions so that those of us who don't believe in bizarre guru-based project management approaches can have a home in this industry.
The claim that "we get our money from our customers" is, on its face, wrong. Of course we're paid by the company, not the customer. The simple truth this article misses is that your wage is simply the price of your labor, and it is the firm that is paying it. The "value you add for customers" (however that might be measured) really doesn't come into the picture. The job market is competitive, and the amount your company pays you is primarily determined by how much they would have to pay someone else to do the same job.
> the amount your company pays you is primarily determined by how much they would have to pay someone else to do the same job.
This is true, but the thing you're missing is that there's not many folks out there that can add value for customers. That's why engineers who create value get paid so well, which is the articles point.
I've noticed that engineers that get paid the most tend to understand the technical and business trade-offs that come from decisions they make.
If January had the highest number of jobs since the Great Depression and we have returned to the March mean, this could still be true while there was absolutely nothing interesting going on.
If there was an unusually high peak of seasonal jobs just prior to the months in question, that would be an utterly meaningless statistic. If it's a moderate random drop coinciding with the end of a somewhat high seasonal number, it's still not relevant to long-term outlook. That's why monthly numbers are difficult to use in isolation.
Came here to say the Technics 1200 turntable. Everything you need in a turntable and nothing you don't: pitch adjustment, 45rpm adapter, 33/45rpm speed buttons, and a light. The few controls it has are all intuitive and the quality of the manufacturing is obvious the moment you use it. I've had mine for 16 years and the only thing I've ever needed to replace is the needle.
From the article: "New high-end cars are among the most sophisticated machines on the planet, containing 100 million or more lines of code."
Does anyone know where this number comes from and if its realistic? It's hard for me to imagine unless you're counting all the LOC from Microsoft Windows: Car Edition or something.
Can't answer where they came up with that number but it does seem rather larger. The only comparable machine where we do know the number is the Mars Curiosity Rover running somewhere around 2.5 Million LoC. Now, given that there are upwards of 200 micro controllers in a luxury car, I can see that number growing exponentially, but 100 Million???
2.5 MLoC sounds extremely high even for a Mars Rover. I really wonder how it's counted? Is it C code or ASM instructions? Does it include all standard libraries that get referenced, even if they end up not being compiled into the final binary? Or is everything just written in Java and configured with XML?
Yes, that has always been my assumption -- they're probably counting operating system, libraries, etc. in those mlocs. It's X MLOCs in the car, not X MLOCs written by the car manufacturer.
We're not just talking about one computer here -- it's not unusual for a modern car to have ~70 ECUs. Of course, many of those will be quite small, simple devices.
Ah so in your view, why was the order flow of retail brokerages worth hundreds of millions of dollars per year to these HFT firms?
Michael Lewis is not the only person accusing HFT firms of front-running trades. Joseph Stiglitz, a nobel laureate in economics, has made similar accusations. Does he too just not understand the market?
why was the order flow of retail brokerages worth hundreds of millions of dollars per year to these HFT firms?
Order flow from retail brokerages can be assumed to be "non-directional", which means that it comes from people who are buying or selling for some reason other than "I have better-than-market knowledge of information which will shortly be relevant to this stock."
One extremely important example of directional order flow is when you have the knowledge "100k shares of this stock are shortly going to be shopped on various exchanges" because you're doing the selling. This will typically cause price impact (i.e. the price of the stock declines), meaning that market makers who take your first few hundred/thousand shares are going to get shellacked. They generally don't love this.
In the (virtually guaranteed) absence of directional order flow, market making is a license to print money. Both sides pay you the spread and you don't accumulate much inventory risk. (i.e. You buy, you sell, you sell, you buy, and you're rarely left with a meaningfully sized position in either direction which would expose you to the stock at issue.)
That's why you pay for non-directional order flow. It's like leasing a toll bridge.
It does seem like the fee being paid for order flow should be able to be captured by those making the orders in the form of further reduced spreads rather than by brokerage firms selling the flow. Though perhaps the issue is that with stocks regulated to trade in penny increments that's hard to do?
I think you're confusing two different issues. If a retail customer's order is actually sent to an internalizing firm, then trading ahead of it would be _actual_ front-running, is already illegal [1], and is taken very seriously by the regulators.
What Lewis _calls_ front-running in his book is something completely different, and involves reacting quickly to public information rather than misappropriating private information.
The book explains that one company was running their own fiber optic cable between Chicago and New York to shave a handful of milliseconds off the latency. HFT firms also built their trading desks as close as possible to where the fiber terminated in New Jersey. This isn't the speed of your mom's google query, they were literally running up against latency caused by the speed that light travels down a cable.
Right. If you're totally unfamiliar with HFT, you don't realize how far they go to get latency down. Computers are too slow for HFT. There are trading algorithms written in VHDL and loaded into FPGAs which are looking at packets as they come in over gigabit Ethernet.[1] (That description is four years old and out of date.)
All this is really to achieve front-running, executing an order after another order has been submitted but before the first order is executed. This is betting on a sure thing. It's also illegal.
Your understanding of what defines front running is incorrect.
Front running is when your stock broker gets an order from you but then turns around and executes an order on his own behalf before he executes yours. This is illegal because your broker has a fiduciary duty to you, his client.
It's not front running when I see an order on one exchange and then, very quickly, go make an order on a different exchange. It's not illegal because I have no fiduciary responsibility to any of the other people involved.
You have no right to execute multiple orders on different exchanges atomically.
If that's true, you should be able to cite a statute, an SEC/FINRA/CFTC rule, a court ruling, or an exchange rule to explain how (allowed and prohibited behavior on markets being defined by all four of those kinds of sources, frustratingly enough).
I suspect you won't be able to find any such source. Malfeasance by trading firms makes career cases for prosecutors.
That's not to say, normatively, that that's how things should be: obviously, prosecutors are not making much of a dent in the trustworthiness of big financial firms.
Can you explain in detail how an HFT would use an FPGA to "front-run" a trade? I suspect you're using that term differently than either professionals or the SEC do.
I agree with you here, but wondering what you see the benefit of per-app PKI is, versus signing all webhooks with the same cert. Is it to prevent having to do a key rotation that would impact every webhook consumer?