The problem was named after an incident in 1996 in which AOL’s profanity filter prevented residents of the town of Scunthorpe, North Lincolnshire, England, from creating accounts with AOL, because the town’s name contains the substring “cunt”.
haha
those are terms, this is substrings within words
I haven’t seen branches or variables being called arse
Then again, I do like to catch exceptions as up so I can throw up
Simple changes require only simple reviews.
Responsibility is shared. It’s not one or the other.
Many people don’t know what they’re doing. That’s kind of expected. But a tool provider and seller should know what they’re doing. Enabling people to behave in a negative way should be questioned. Maybe it’s a consequence of enablement, or maybe it’s bad design or marketing. Where criticism is certainly warranted.
Commit with Co-authored-by: Copilot
or maybe better --author=Copilot
It would certainly help evaluate submissions to have that context
he l p
looks like a multi-threading or concurrency issue
each function has its own independent metal toggle switch
one steering wheel to steer left, and one to steer to the right
they want to push a lot of buttons on those controls
LOL
Even with a lot of buttons available, good videogame controls are simple and narrow. Natural combinations add depth without overcomplicating things.
Have you considered creating a ticket called “Can’t ask questions without joining discord”?
Do you think it would have more answers if it were on GitHub discussions?
I’m not familiar with their products and product names, so I had to look them up, sharing that here, including the other two free non-comm mentioned in the blog post:
Release must be documented
It’s not a must [unless you put it into a contract], it’s a should or would be nice
Many, if not most, projects don’t follow a good, obvious, transparent, documented release or change management.
I wish for it, too, but it’s not the reality of projects. Most people don’t seem to care about it as much as I do.
I agree blind acceptance/merging is problematic. But for some projects (small scope/size/personal-FOSS, trustworthy upstream) I see it as pragmatic rather than problematic.
I would consider three four approaches.
1. Commit and push manually and deliberately
I commit changes early and often anyway. I also push regularly, seeing the remote as a safe and remote (as in backup) baseline and reference state.
The question would be: Do I switch when I’m still exploring things in the workspace, without committing when switching or moving away from it, and I would want those on the other PC? Then this would not be enough.
2. Auto-push all local git references into a separate space on the git remote
Git branches are refs, commit pointers, just like other refs are. And they can be put under arbitrary paths. refs/heads/ holds branches. I can replicate and regularly update all my branches under refs/pcreplica/laptop/*. And then on the other PC, list or fetch those, individually, or all of them, regularly automatically, or manually.
git push origin refs/heads/*:refs/pcreplica/laptop/*
git ls-remote
git fetch origin refs/pcreplica/laptop/*:refs/laptop/*
3. Auto-push the/a local branch like you suggested
my concern here would be; is only one branch enough? is only the current branch enough?
4. Remoting into the other system
Are the systems both online? Can I remote into / connect into it when need be?
Has features ✅
Code before:
async function createUser(user) {
if (!validateUserInput(user)) {
throw new Error('u105');
}
const rules = [/[a-z]{1,}/, /[A-Z]{1,}/, /[0-9]{1,}/, /\W{1,}/];
if (user.password.length >= 8 && rules.every((rule) => rule.test(user.password))) {
if (await userService.getUserByEmail(user.email)) {
throw new Error('u212');
}
} else {
throw new Error('u201');
}
user.password = await hashPassword(user.password);
return userService.create(user);
}
Here’s how I would refac it for my personal readability. I would certainly introduce class types for some concern structuring and not dangling functions, but that’d be the next step and I’m also not too familiar with TypeScript differences to JavaScript.
const passwordRules = [/[a-z]{1,}/, /[A-Z]{1,}/, /[0-9]{1,}/, /\W{1,}/]
function validatePassword(plainPassword) => plainPassword.length >= 8 && passwordRules.every((rule) => rule.test(plainPassword))
async function userExists(email) => await userService.getUserByEmail(user.email)
async function createUser(user) {
// What is validateUserInput? Why does it not validate the password?
if (!validateUserInput(user)) throw new Error('u105')
// Why do we check for password before email? I would expect the other way around.
if (!validatePassword(user.password)) throw new Error('u201')
if (!userExists(user.email)) throw new Error('u212')
const hashedPassword = await hashPassword(user.password)
return userService.create({ email: user.email, hashedPassword: hashedPassword });
}
Noteworthy:
password is. (In C# I would use a param label on call validatePassword(plainPassword: user.password) which would make the interface expectation and label transformation from interface to logic clear.Structurally, it’s not that different from the post suggestion. But it doesn’t truth-able value interpretation, and it goes a bit further.
So it really is that simple: a small bash script, building locally, rsync’ing the changes, and restarting the service. It’s just the bare essentials of a deployment. That’s how I deploy in 10 seconds.
I’m strongly opposed to local builds on any semi-important or semi-complex production product or system.
Tagged CI release builds give you a lot of important guarantees involved in release concerns.
I’ll take the fresh checkout and release build time cost for those consistency and versioned source state guarantees.
learned from 10 years/millions of users in production
10 years per millions of users is an interesting metric :P
deleted by creator
Maybe all bunnies are actually snails with a fur coat on.
I would like to see TS as the first class citizen however, with JS being deprecated essentially.
What do you mean by that.
From what I read, Deno does primarily use and target TS. They label all that JS stuff as backwards-compatibility and ability for a migration path.
It would certainly be an issue if you didn’t have one