Pup Biru

that regex annoys me more than it reasonably should

(o|O){2}

as if we needed any more reasons to demand fibre

do NOT make mistakes

DROP *

much more preferable to

GRANT *

that is absolutely NOT the way that works in any functional environment

your ability to deploy quickly comes directly from your automation, and those automation tools - NOT developers - have the secrets in them

deploy to prod multiple times per day isn’t some win by itself… the ability for large teams (not 1 fuckwit and a goon squad of agents) to deploy without breaking things and in ways that are safe is the win here… anyone can deploy to prod multiple times per day… but anyone isn’t netflix (the originators of the “multiple times per day” line) with the uptime they achieve over years while doing it

if you talk AND type you can burn twice the tokens and get the same result! it’s a win win win

eventually they’ll just sell warm pizza food cubes and avoid the hassle of yeast all together because consistency is exactly what everyone wants, … right?

along with most modern languages… it’s the way we deal with async when you don’t want callback hell. it’s just a complex problem domain

like… what… JITs are complex so that’s a problem for V8 specifically?

they’re talking about inheritance as a suggested new way to pay for your copilot subscription

it’s like how the linux kernel isn’t semver: the number after the decimal point has a maximum of .19 and then the first number increments

except that one time

kernel version 4.20 is the only .20 kernel version

tmux > gnome

a great illustration of the dunning-kruger effect

hard disagree on what belongs in the same commit history… a single merge should be an entire feature, and your commit history should read like a change log

Squashed commits are not atomic … overall task requires modifying multiple different systems

that’s why monorepos exist

i’d say squashed commits aren’t always atomic, but this is one of the biggest reasons people add the complexity of a monorepo: if changes cross multiple systems, ideally their merge/revert should be an atomic operation

you either have deployment complexity (ensuring the feature is in all deployed systems before switching over), code complexity (dealing with the feature only maybe exiting in parts of the system), or repo complexity (where tools manage a monorepo and thus commits and PR/MRs are atomic across your system)

they’ll mug ya for a ciggie all right!

okay but like there are actual ways of doing gendered spaces in australia… or at least victoria

here in melbourne we have the laird - a gay bar that is a male only space. and australia-wide we have female only gyms. they have an exemptions to the equal opportunity act and are allowed to deny entry based on gender. you have to apply to the state for them

ignoring what you actually think about those examples specially, imo they’d have a pretty good case to get exemptions should they apply for them since it’s art… it’s more a case (imo) of not doing their paperwork and getting the correct permissions… boring? sure… necessary? definitely

though with those exemptions you must strictly adhere to your own gender requirements otherwise you’ll lose it

either… some apps have just started to do single factor login with just email, profile options can be optional, if there are required fields or terms of service to agree to then that can come after email validation

i think these days the best practice for mobile apps re retention (other than sso or passkey) is to just ask for an email, then from the validate link continue with register

reason being that more steps to register means more ways people are likely to drop out of the flow, and this is basically about as short as it can be

when the user has validated their email, then they’re more invested so they are more likely to complete

that also fits nicely with what we’re talking about with good security

the old logo still exists. this is a new mascot intended to increase user connection to the browser by providing a friendly anthropomorphised front for actions taken by the firefox team, browser, and congratulating users on taking actions. in furtherance of this idea, kit is represented by ambiguous pronouns when written about in order to avoid unnecessary gendering, and allow the user to imply their own gender as they like

that line is from the branding guidelines for kit

whilst it is legitimate, it misrepresents the purpose of both kit and branding guidelines: kit is a feature meant to invoke feelings; not a character having made a decision about its gender