Custom furniture/cabinetry is already a pretty tough market, and woodworking is such a common programmer hobby that if a significant chunk of us decided to make a go of it the market would get heavily oversupplied pretty fast :).
I’ve had people tell me I should try selling some of the furniture I make and my response is always that I made the mistake of turning a hobby into a career once, I don’t intend to make that mistake again, and at least software still pays pretty well.
As I understand it, "to be trespassed" is a term of art that basically means "the cops were called, told that person was trespassing, the cops duly informed that person they are trespassing & had to leave the property, and the person left, but was not charged". It's basically establishing a legal trail so that if the person refuses to leave or continues to trespass at that location in the future they have a better basis for charging them.
I also use pass. Any forge you feel like is fine (I use gitlab). I backup my gpg key with `gpg —export-owner-trust` and store that backup elsewhere.
Pass has a pretty good ecosystem of plugins/other clients, as well. There are open source iOS/Android clients and browser extensions so once you’re setup the day-to-day experience is not far off from any of the popular hosted password managers.
My only real issue is the dependency on gpg, as it’s pretty long in the tooth and a hassle to operate. (If you are not comfortable using gpg, spend some time learning that before you go all-in on pass!) There’s a fork[1] which swaps gpg for age, but it hasn’t attracted enough attention to get a similar ecosystem of mobile clients/browser extensions, so it’s not a very practical choice IMHO.
Stores, no, but there are meetups of keyboard nerds where people bring a bunch of them. There’s one in NYC run by a former coworker of mine: https://nyckeyboardmeetup.com/. Schedule is somewhat sporadic, and unfortunately you just missed the most recent one, but you might enjoy checking out their next event.
I'm with you, but I do think the situation can be characterized differently in a couple important ways:
1. IE was the default browser for many users (i.e. anybody using Windows who didn't know better).
2. IE had a lot of bugs and and was often non-compliant with standards.
Those two things combined meant that supporting IE required additional work, and if you didn't put in that work you were going to get users from IE anyway they'd just get frustrated and confused when things broke. So "detect IE and tell them use something else" was at least a reasonable fixed-cost approach to not having users get totally stuck. (And IE went down to 2-3% at least in part because devs revolted against IE earlier and started serving those "don't use IE" messages when its usage was still higher.)
Neither factor is really true of FF. It's not the default for any major platform, its user-base at this point is largely power users who won't be easily confused, and outside of some non-standard APIs most sites don't need and some fairly edge-casey stuff, most sites that work on Chrome will work fine on FF as well without alteration. If anything, IME Safari is more likely to need special attention than FF (but of course Safari has much higher market share so it merits that effort).
So I totally get not wanting to spend QA budget on FF, and I could understand showing a small banner suggesting you use a different browser, but erroring/completely blocking usage of the site does feel excessive to me, and even a bit mean-spirited since it takes extra effort to detect FF to show the message and prevent using the site! I don't think these sites are going out of their way to block usage of other low-usage browsers (some of which can alter behavior that could break some sites even if they are Chromium-based).
We’re in very nitpicky terminology weeds here (and I’m not the person you’re replying to), but my understanding is “commutative” is specifically about reordering operands of one binary op (4+3 == 3+4), while “associative” is about reordering a longer chain of the same operation (1+2+3 == 1+3+2).
Edit: Wikipedia actually says associativity is definitionally about changing parens[0]. Mostly amounts to the same thing for standard arithmetic operators, but it’s an interesting distinction.
What kind of mobile functionality were you looking for? The (unofficial) iOS app is pretty good IMHO and integrates with iOS’s OS-level password filling, and also supports the pass-otp plugin’s format for 2fa codes if you use that plugin. There was a decent Android client I used a while back as well, though I don’t recall the name.
> Adding non-primitive props you get passed into your component to internal dependency arrays is rarely right, because this component has no control over the referential stability of those props.
I think this is wrong? If you memoize a callback with useCallback and that callback uses something from props without putting it in the dependency array, and then the props change & the callback runs, the callback will use the original/stale value from the props and that's almost certainly a bug.
They might be trying to say you just shouldn't use useCallback in that situation, but at best it's very confusingly written there because it sure sounds like it's saying using useCallback but omitting a dependency is acceptable.
IMHO useCallback is still a good idea in those situations presuming you care about the potential needless re-renders (which for a lot of smaller apps probably aren't really a perf issue, so maybe you don't). If component A renders component B and does not memoize its own callback that it passes to B as a prop, that is A's problem, not B's. Memoization is easy to get wrong by forgetting to memoize one spot which cascades downwards like the screenshots example, but that doesn't mean memoization is never helpful or components shouldn't do their best to optimize for performance.
The “stolen” one is a 1991 model according to the article, so not that new (just kept in immaculate condition as the photos show, I was surprised when I saw it was a ‘91), and only 6 years between the two vehicles involved. Given those ages, it’s not shocking Mercedes was using the same key patterns.
I can think of multiple “corner stores” that are the only business within a single-family home residential area within a few minutes drive of the house I grew up in in suburban NY. I’m pretty sure they all got grandfathered in and would not be permitted as new construction with the zoning, but they’ve all been in business since before I was born and are still going. These are mostly neighborhoods without sidewalks, and the stores have parking for only a handful of cars.
You’re right that “most” houses can’t be within walking distance of a corner store outside cities, but my anecdata experience is those residential communities can definitely support those businesses. They might require a short drive, but they’re still a lot closer than the shopping center, and a mix of “ran out of one thing”, deli/breakfast sandwiches, and beer keeps them in business.
Vlovich is describing the very last race only, where he did place the final bet. He takes her 4k and tells her he’s going to place the bet for her so how much she’ll win is a surprise. The horse he said he would bet on loses the race and then he reveals he actually bet on the winner. So for that race and that race only I do think he just bet on every horse and sleight-of-handed the right ticket to her. Timestamp 35:20 in the video you linked earlier. Right after that he explains how the “trick” worked for all the earlier races, which is what you’re referring to.
Our Django app was still 1.x when I joined, I’ve gotten us up to 3.2 and hope to be on 4.0 in January. It looks like this was added in 4.1, so this’ll be a nice QOL improvement to look forward to, thanks.
I believe `makemigrations` builds up its conception of "what the schema is" from the `CreateModel`, `AddField`, `AlterField`, etc. ops in the migrations files. But it doesn't incorporate `RunSQL` ops into building that model of the schema. If my migrations were just a bunch of `RunSQL` ops, I think `makemigrations --dry-run` would basically just see everything from models.py as always needing to be added.
This behavior is why `SeparateDatabaseAndState` is a necessary hack in Django: sometimes you need to do an `AlterField` where the SQL Django would generate is really bad, so you need to write your own `RunSQL` to do the right thing, but you also need Django to see the `AlterField` as applied or you'll have problems with future migrations.
I suppose I could modify my preference to "run makemigrations and then wrap every single op in SeparateDatabaseAndState", but that does not sound fun :).
I’ve had people tell me I should try selling some of the furniture I make and my response is always that I made the mistake of turning a hobby into a career once, I don’t intend to make that mistake again, and at least software still pays pretty well.