I learned “test your mocks” long ago from Sandi Metz, and that advice has paid off well for me. Have some set of behavioral conformance tests for the kind of thing you expect (e.g. any database worth its salt should be able write and read back the same record). Then stick your mock right under that same battery of tests alongside your implementation(s). If either deviate from the behavior you depend on, you’ll know about it.
Bang on Sandi! I hadn’t heard that quote but she’s my favorite speaker on testing and OO.
Another way of looking at this advice is that every time there’s a mock there needs to be a test that shows that the real code can be used in the same way that the mock is used.
You're free to come up with a better example. The point is that dependencies have behavioral properties that software depends upon. We can write tests for those behaviors. Mocks that are correct and remain so should implement those same behaviors we expect from the prod implementations of those dependencies.
Can confirm. It also has a mode to jump through the captive portal. I just set it up with the same SSID and PSK as my home wifi and everything we bring connects automatically. It also routes everything through Tailscale.
Yep, I have the same set up. Use GL router to connect to the hotel wifi, and all devices are automatically connected, without captive portal on each one.
Added bonus that I can use tailscale on the GL router to route remote traffic through my tailnet -- including devices where I can't install tailscale client (e.g. corp laptop).
If you’re ever “down the Cape” (Cape Cod, that is), visiting the Gorey house is worth your while! They have a very fun scavenger hunt based on the Gashleycrumb Tinies which was actually quite challenging.
> So it’s definitely AI. I felt betrayed and a little foolish. But why?
Because the prompter is basically gaslighting reviewers into doing work for them. They put their marks of authorship on the AI slop when they've barely looked at it at all which convinces the reviewer to look. When the comments come back, they pump the feedback into the LLM, more slop falls out and around we go again. The prompter isn't really doing work at all—the reviewers are.
> In contrast, when overcommit is enabled, the kernel simply allocates a VMA object without guaranteeing that backing memory is available: the mapping succeeds immediately, even though it is not known whether the request can ultimately be satisfied.
When overcommit is enabled, the kernel is allowed to engage in fractional reserve banking.
Every parking lot is an opportunity for community. In my experience tailgating is considerably more than minutes and has a very strong community. Admittedly I do not have much experience with tailgating but my limited experience strongly suggests that it is a very tight knit community that goes beyond the actual event.
Parking lots are private spaces where the store management can ask you to leave at any time. That some don't is almost a happy accident.
Compared to a public park where anyone is free to loiter and play. Plus parks are usually segregated from cars so you don't have to worry about a random car not paying attention killing you, the ground isn't hot pavement everywhere, there might be playground equipment and benches and picnic tables, etc.
Cities own parking lots but privately owned parking lots are generally easier to get access to for events, far less red tape and who ever owns it gets brownie points with the community.
Who said anything about big stores? Every big city I have lived in has had a stadium and parking lots owned by either the stadium or third parties which allow tailgating and I have been to/was involved in a good many events held in private parking lots. Big stores open 7 days a week if not 24 hours a day are obviously not going to sacrifice their parking lots but a good number of parking lots are mostly vacant on the weekends, they serve the 5 days a week, 9-5 buisness world and they are more willing to sacrifice their mostly empty weekend lots.
> Every big city I have lived in has had a stadium and parking lots owned by either the stadium or third parties
So not the city, the stadium corporation (which might have ties to the city, but usually a wholly separate organization) or private third parties. Like I said.
> they are more willing to sacrifice their mostly empty weekend lots.
Once again I've had a lot of very mixed experiences on this one. Some don't care, some see it as an insurance liability. I've spent a lot of my life adjacent to commerical property management, I can't imagine most of these groups being thoroughly OK with unknown groups using their lots for whatever. Seems like a good chance to get sued.
> This task is not easily idempotent; it involves writing a ton of intermediate state and queries to determine that a step should not be repeated
The problem with durable execution is that your entire workflow still needs to be idempotent. Consider that each workflow is divided into a sequence of steps that amount to: 1) do work 2) record the fact that work was done. If 2) never happens because the worker falls over, you must repeat 1). Therefore, for each step, "doing work" happens at least once. Given that steps compose, and each execute at least once, it follows that the entire workflow executes at least once. Because it doesn't execute exactly once, everything you write in a durable execution engine must be idempotent.
At that point, the only thing the durable execution engine is buying you is an optimization against re-running some slow tasks. That may be valuable in itself. However, this doesn't change anything about good practices writing async worker tasks.
I think a lot of the original temporal/cadence authors were motivated by working on event-driven systems with retries. They exhibited complex failure scenarios that they could not reasonably account for without slapping on more supervisor systems. Durable executions allow you to have a consistent viewpoint to think about failures.
I agree determinism/idempotency and the complexities of these systems are a tough pill to swallow. Certainly need to be suited to the task.
> The problem with durable execution is that your entire workflow still needs to be idempotent.
Yes, but what that means depends on your durability framework. For example, the one that my company makes can use the same database for both durability and application data, so updates to application data can be wrapped in the same database transaction as the durability update. This means "the work" isn't done unless "recording the work" is also done. It also means they can be undone together.
A lot of work can be wrapped inside a database transaction, but never everything. You're always going to want to interact with external APIs eventually.
Yes of course. External calls still need to be idempotent. But the point is some frameworks allow you to make some, or even most, of your work safe for durable execution by default.
No it's different. Idempotent would mean that it can be replayed with no effect. What I'm saying is that this guarantees exactly once execution, taking advantage of the database transactions that make multiple data updates idempotent together.
> that your entire workflow still needs to be idempotent
If just meaning workflow logic, as the article mentions it has to be deterministic, which implies idempotency but that is fine because workflow logic doesn't have side effects. But the side-effecting functions invoked from a workflow (what Temporal dubs "activities") of course _should_ be idempotent so they can be retried upon failure, as is the case for all retryable code, but this is not a requirement. These side effecting functions can be configured at the callsite to have at-most-once semantics.
In addition to many other things like observability, the value of durable execution is persisted advanced logic like loops, try/catch, concurrent async ops, sleeping, etc and making all of that crash proof (i.e. resumes from where it left off on another machine).
It feels like the price should vary by how many a legal entity has. It would be nice for one to be super cheap, 5 to be perfectly acceptable for a business to afford, and 100 to be unfathomably expensive. And maybe trademarks would get you a big break (on domains that contain your trademark) since you’re not hogging anything anyone else could legally use.
Of course, this is fantasy though because it’s not worth forcing people to tie their identity documents to registrations.
I learned “test your mocks” long ago from Sandi Metz, and that advice has paid off well for me. Have some set of behavioral conformance tests for the kind of thing you expect (e.g. any database worth its salt should be able write and read back the same record). Then stick your mock right under that same battery of tests alongside your implementation(s). If either deviate from the behavior you depend on, you’ll know about it.
reply