I used to blindly rely on google maps until it misdirected me on my way to Redwood National Park. It led me to a house in the mountains that had a sign saying something like - google maps has misdirected you and there is no path through this house to the Redwood national park. It was a place where even the cellphone did not work. This happened ~6 years ago and hopefully google fixed it by now.
Similar story. Was in a caravan with friends on a road trip and apple maps had us going onto a dirt road to save time. We go overlanding a lot, so dirt roads aren't weird, but we decided to stop and double check before proceeding too far on the road.
About a minute later, a border control agent pulls up next to us and starts with the standard interrogation. Turns out, apple maps had been telling people to use a dirt road to circumvent a border control checkpoint - which according to the officer was a felony. We proceeded back onto the pavement and through the checkpoint where they waved us through. The dirt road wouldn't have been faster at all, so it was puzzling why it was giving those directions.
One possibility that occurs to me is that various people might have reported the border checkpoint to Apple Maps as a blockage in the past, in order to get it to give them a route around it.
Not that this absolves Apple, of course, since they should absolutely be checking these things better.
They probably haven't and even if they have there's probably some other bogus data in there.
A lot of these maps will have a couple 'tells' added, things that don't really exist to say that if a set of things was copied it came from a different place.
Really sucks when you happen to need to go somewhere you haven't been before, that's actually where that place is next to. Yes, that does happen. E.G. when relatives and friends live on private roads in the middle of nowhere.
Yep “paper cities” is what to google if you’re interested. We have a “paper bus route” in my neighborhood at bus stops that were removed 10 years ago, that serve the same purpose, as far as I can tell.
>If you had a database and some separate messaging like ZeroMQ, Rabbit, Kafka, you’re going to get race conditions. There’s always going to be a potential race where you have two messages - one is going to the disk and one is going to the network. If someone else is listening and sees both of them, they could potentially get them in either order. So it’s much, much simpler to just have one path. Foundation is really fast, so it works great.
Having difficulty parsing this justification. How will a client code listening to an event get two events - one from network, and one from disk in case of any of the queuing systems mentioned here? I am also curious to know how the FoundationDB act like a messaging system apart more than a message store?
I think he's talking about how with FoundationDB, pub/sub notifications ("watches") are transactional – the notification is only sent if the transaction succeeds. because FoundationDB can guarantee transactions across multiple key writes, you can write your state at the same time you write an event/message/job somewhere else, in one transaction, with the subscriber only being notified on success. I think this is impossible(?) to achieve without the message queue and data store being the same service.
otherwise, you have a transaction to write to your database and a separate call to the message queue, which introduces the race condition.
Depending on the context of course - retire from a career to pursue one's passions.
Retire as a software engineer, pursue business ideas. Tinker. Maybe build wood cabinets and chairs.
Picture someone that just spent the last 30 years writing C, C++, Java (whatever) code, and maybe doing various lower level management roles. The age of AI has broken into an open gallup; said person is 55-65 years old, maybe now is a good time to have fun with their capabilities instead. So now they're learning Python instead of punching a 9-5 time clock, messing with LLMs or Stable Diffusion extensions. You get the idea.
We have hit an inflection point the scale of the World Wide Web circa the mid 1990s. There's a lot to do. Vast new territory to explore and it's moving fast. It feels a lot like the mid 1990s did in terms of speed. It feels like "internet time" has returned. It's damn exciting again.
For younger people here that are completely unfamiliar with the phrase "internet time." Vaguely the idea or sense of experience that development online circa the 1990s was moving abnormally fast compared to everything else (this is from 2001, when people still understood the original context of the phrase):
I sincerely think that the present corporate culture can suck the air out of anyone's life and force to seek contentment elsewhere very soon. Doing a research work and solve problems, where one does not have to seek approval (easier when you NL next to your name), on a daily basis can keep one engaged and energized.
Feels like a nice dream interrupted for most of the googlers. Probably they felt tenured and even 6 months of severance cannot assuage the hurt feeling. Looking around and doing some reality check might help. Every company is trying to improve the bottom line when the topline is not moving up. The layoff didn't just happen this year, it has been in the corporate world all the time.
If there are true friends in the company then they will find a way to reach out. Others are just lunch/coffee buddies and they might be already enjoying their pastime with someone else. Find a way to put this in the rear-view mirror as soon as possible.
Few missing details that are crucial to usage within an organization:
1. what is the type of service instrumentation needed to capture the data? Wonder why this is needed when typically the data is already captured in an APM log? The instrumentation might add performance and security concerns.
2. what is the sampling logic to capture the traffic? It might compromise the fidelity of the test data and give a false sense of test accuracy.
3. what is the duration of data capture? Is it a week's or month's or quarterly data? Meeting 90% coverage on a week's production sample data will provide a false metric.
4. can it faithfully handle data privacy and customer anonymization? This is critical for API's dealing with PCI and other sensitive data.
Yeah, 4 is key. Many privacy regulations stipulate that account data must be deleted within a certain period of time, usually days or less, after a requested account deletion. In this system, all recorded requests would have to be discoverable by the requestor's ID and production systems would have to remember to perform deletions when necessary. Also, this database and all related testing systems would have to be held to production level standards for data access because anyone who can see test data to root cause errors can see people's and business' real, private information. Especially for data controlled and regulated industries like government and health care, this would be a nightmare.
It's a neat idea. These kinds of systems often require lots of care and grooming. Since it's used to retroactively test features after they're in production, there's a repeating process of discovering we're saving data we shouldn't, scrubbing, filtering, anonymization, etc. In most cases, I've watched them eventually get replaced by fuzzers. Still, having a central service used by lots of companies may allow this solution to scale up, develop necessary features to solve these problems and function well. I hope it works out!
> 1. what is the type of service instrumentation needed to capture the data? Wonder why this is needed when typically the data is already captured in an APM log? The instrumentation might add performance and security concerns.
Implementation is very similar to an APM log. So the same performance and security concerns apply. We are working on giving both at the same time (Automated tests, and APM), to reduce overhead.
> 2. what is the sampling logic to capture the traffic? It might compromise the fidelity of the test data and give a false sense of test accuracy.
It is random sampling. I feel, 1M or 10M randomly sampled requests should cover all cases.
> 3. what is the duration of data capture? Is it a week's or month's or quarterly data? Meeting 90% coverage on a week's production sample data will provide a false metric.
I was thinking 1 week should be enough. Maybe we will have to add some custom sampling logic for lesser frequency calls (like monthly crons).
> 4. can it faithfully handle data privacy and customer anonymization? This is critical for API's dealing with PCI and other sensitive data.
Yes. Additionally, for compliance, we offer a self-hosted solution- Our code runs on your servers and no data ever leaves your cloud / on-prem.
I've been having to put together a test suite at $work similar to what the product tries to offer. If there were a sufficiently advanced product to buy, I'd petition for it to be adopted at my org.
> It is random sampling. I feel, 1M or 10M randomly sampled requests should cover all cases.
1. I suggest providing alternate approaches to sampling:
The input itself may have bias towards a single use case. If 70% of the input exercises the same code path, there's no benefit to having a uniform sample. Ideally it would be stratified amongst customers, or perhaps on other dimensions to allow for covering the most surface area.
2. Requests don't happen in a vacuum. They likely have data dependencies on prior requests. I recommend some way of sampling sessions rather than individual requests. Replaying the 3rd request in a series of 6 is likely just going to be exercising failure paths.
3. Behaviors may vary between requests with respect to time. If requests were sampled over a number of days but replayed within a short time period, there are behaviors that could differ from what actually occurs in production.
I didn't see any explanation on how results are determined. I think it's important to surface those types of details on the website. I'm not going to watch the video on it in hopes of learning.
> 2. Requests don't happen in a vacuum. They likely have data dependencies on prior requests. I recommend some way of sampling sessions rather than individual requests. Replaying the 3rd request in a series of 6 is likely just going to be exercising failure paths.
This is so true. I ran into this problem when I was trying to implement a kind of sampling that limited total RPS.
Thanks for reminding. I am definitely looking into more sophisticated methods of sampling.
> I didn't see any explanation on how results are determined. I think it's important to surface those types of details on the website. I'm not going to watch the video on it in hopes of learning.
The Generative AI is the AI for the masses. While people were getting overhyped with all the possibilities and promises of AI and deep learning etc. it is for the first time that they can also tinker and get surprised by its results. People feel creative interacting with it.
>“Depositors shouldn’t get anything beyond the insured $250,000”. Then what do we do with the billions in remaining assets? Appropriate them, and leave small and mid businesses hanged to dry?
To me such statements feel like - either you are with me or against the humanity. Of course, the government should not gobble the money that belongs to the depositors and the fund should be distributed fairly to the depositors post liquidation. But making whole the deposits through the tax payers money will not be right. This is a business failure and what is insured is only what is guaranteed to be paid back. That is the risk business take when they engage in such transactions.
Individuals who had more than $250k sitting in bank account must be well-off and prudent enough to decipher the FDIC insurance limit.
