Alternatively: if you're wasting a bunch of your time on the minor details how do you have enough time for the major ones? I'd much rather my restaurant owner worry about sourcing ingredients, keeping the kitchen clean, improving the taste of the food than anything else.
If you don't have the time or money to have actual menu photos taken, what are the odds you have the time and money to source high quality ingredients, keep the kitchen clean, or improve the taste of the food?
The minor details are precisely the ones that require the least time and money to handle, so if those are being skimped on, it's likely that the major details are too, in my experience.
It depends, probably. If we are talking about high end, off the beaten path places, marketing is important. For the $1.50 slice pizza at the hole in the wall in Times Square? I doubt those places are cleaned and no one is checking the reviews, people just line up because others are, and because the smell and taste is right.
Hell yeah I will ship you a box of ‘food’ for two hundred dollars. You know it’s going to be great because I don’t spend my time on stuff like describing or photographing it
Android's permission system conflates the Bluetooth scanning permission with the "Fine location" permission, because in theory any app that can enumerate nearby Bluetooth devices (including things like nearby Bluetooth Low Energy beacons commonly found in stores and malls) could use that information to locate your phone within a few hundred feet.
It seems like there's a newer build option to explicitly disable the "Fine location" permission prompt while still being able to scan for Bluetooth devices, but such beacons are somehow filtered from the list if it's enabled, and it's only available for builds targeting newer Android versions.
Dealing with dates becomes much simpler conceptually when you realize that you are actually dealing with two different ideas masquerading as one: dates, and the actual instants in time which they name. Instants in time can only be unambiguously referenced by measuring some fixed unit of time intervals from some commonly agreed upon event (e.g. seconds since the Unix Epoch).
Dates are a mapping from human-readable labels to instants in time; critically, this mapping is not a total function (there are dates that map to no instant in time in a particular calendar, such as October 5-14 1582 in the Gregorian calendar, or 2:30am March 8 2026 in US timezones due to DST), nor is it in fact a function at all depending on how you define your inputs (1:30am November 1 2026 in US timezones is ambiguous if you don't specify DST/ST).
Furthermore, the mappings (both for past dates and future dates!) can themselves change over time (changes to DST, timezones, and calendars such as in TFA), and you need to keep track of these changes in perpetuity, as well as at which instant in time they were implemented, and we don't necessarily have that information for some of these historical changes, we only have the date as written down, which itself can suffer from the ambiguity problem (is it the date pre- or post- calendar change?).
This makes dealing with past dates tricky, and dealing with future dates speculative at best. For instance, what's February 28th + 1 day? The answer depends on the calendar system and the year; we can answer it definitively for past years but not necessarily for future years (maybe in 2040 we'll move the leap day to December 32nd). This is why it's important to immediately convert past dates (and sometimes future dates, depending on the use case) to unambiguous instants in time, and only convert them back to dates for display purposes.
"Wednesday, August 12th 2026" and "8 days from now" are also semantically distinct for some purposes: if have 8 doses of a daily prescription left, I'm still going to run out in 8 days even if tomorrow the government decides to repeal the Gregorian calendar, thus changing the name of "8 days from now" from "Wednesday, August 12th 2026" to "Sunday, August 2nd 2026". My medication doesn't care what the government decides to call 8 days from now, I'm going to run out either way. The pharmacy, on the other hand, very much does care what the government decides to call 8 days from now, because perhaps they're closed on Sundays. The calendar change means that "8 days from now" went from being not-a-Sunday to a Sunday, affecting their operating hours.
It's really just another instance of one of the two hard problems in computer science: naming things.
I get what you're saying, but if the government repealed the Gregorian calendar (and went back to Julian) that wouldn't change the day of the week. The day of the week is historically independent of the day of the month. Catholics and Protestants agreed on this in the calendar change. The original papal bull that set up the Gregorian calendar has Thursday 1582-10-04 followed by Friday 1582-10-15; Great Britain and colonies (if we're taking the US perspective) followed Wednesday 1752-09-02 with Thursday 1752-09-14.
Interesting, I didn't know that! I suppose I could edit my post accordingly, maybe a better example would be "the pharmacy won't let me get a refill until the date written on my prescription: Wednesday, August 12th 2026"? I think the point gets across regardless.
Docker has made this much much easier than it used to be, and the ease of publishing images has led to many SaaS companies providing "dockerized" versions of their services.
I write a lot of Terraform to manage internal infrastructure with dependencies on other internal and external infrastructure that's outside of my control. I define a module parameter for each dependency (usually with a default value that points to the real service URL) and then create a second module that uses Docker to spin up and configure local instances of each dependency and overrides the corresponding parameter.
This makes local testing very straightforward: `terraform -chdir=tests apply`
Sometimes you're using git in a context where you don't control the filenames, or where a potential attacker could influence or fully control them, at which point edge cases like this can easily turn into exploits.
I also chafe whenever I run into artificial restrictions on things like characters in names of things, because there's no good reason for them besides the laziness of developers or the limitations and inertia of existing systems that might be used under the hood, like DNS for instance.
I doubt you need an LLM for that, a diffusion model or perhaps even a deep CNN could probably do a passable job. You could train it by taking consecutive triplets of images [A, B, C] and providing [A, C] as inputs with B as the expected output.
My equally uninformed guess is that the presence of six empty boxes communicates that the code entered must be exactly six digits long in a way that a generic text input doesn't. It clearly delineates the digits which makes it easy to see how many you've entered and how many are empty, and the presence of an empty box suggests that it needs to be filled while a number that's simply shorter than the input field doesn't. At least, that's my steelman; maybe browsers should check if a field's min-length and max-length are the same and style them similarly?
So I don't have to spend 10-15 minutes saving all my open files (including the scratchpad ones I haven't named) and then later reopening all my applications, recreating all of my tmux windows and panes, setting up my vim splits and tabs again, and starting all of my stopped Docker containers?
I have a feeling someone is going to jump in with a "solution" to each of these forgetting that lots of work is ephemeral/transient and undeserving of even the slightest bit of automation or pre-configuration.
reply