Kissaki

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.

The abstract:

Two critical and interrelated questions regarding the design and study of programming languages are:

1. What does it mean to design a programming language? and
2. Why does minimal demographic diversity persist in the programming language community?

In this paper, we present feminism as a philosophical lens for analyzing the programming languages field in order to help us understand and answer the motivating questions above. By using a feminist lens, we are able to explore how the dominant intellectual and cultural norms have both shaped and constrained programming languages.

A key contribution of this analysis is the explanation of how marginalization in the programming language community limits the intellectual and demographic makeup of the field.

We see this paper as an invitation to everyone in the programming languages field to deepen our collective understanding of the forces shaping our field. Our goal is to illustrate opportunities for more inclusive practices that will introduce greater diversity to the design of programming languages and the demographic makeup of the programming language community.

The follow-up quotes

In your specific case, the problem is your employer is on that list [of sanctioned entities]. If there's been a mistake and your employer isn't on the list, that's the documentation Greg is looking for.

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 ✅

we should just write the code how it should be

Notably, that's not what he says. He didn't say in general. He said "for once, [after this already long discussion], let's push back here". (Literally "this time we push back")

who need a secure OS (all of them) will opt to not use Linux if it doesn’t plug these holes

I'm not so sure about that. He's making a fair assessment. These are very intricate attack vectors. Security assessment is risk assessment either way. Whether you're weighing a significant performance loss against low risk potentially high impact attack vectors or assess the risk directly doesn't make that much of a difference.

These are so intricate and unlikely to occur, with other firmware patches in line, or alternative hardware, that there's alternative options and acceptable risk.

Data Base - not a Database

I would hesitate to write to it given that it's a data base more than a database

or is it actually not about databases?

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:

• Contrary to most JS code, [for independent/new code] I use the non-semicolon-ending style following JavaScript Standard Style - see their no semicolons rule with reasoning; I don't actually know whether that's even valid TypeScript, I just fell back into JS
• I use oneliners for simple check-error-early-returns
• I commented what was confusing to me
• I do things like this to fully understand code even if in the end I revert it and whether I implement a fix or not. Committing refacs is also a big part of what I do, but it's not always feasible.
• I made the different interface to userService.create (a different kind of user object) explicit
• I named the parameter in validatePassword plainPasswort to make the expectation clear, and in the createUser function more clearly and obviously differentiate between "the passwords"/what 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.

2FA? But it said "with one click". So that's not true?

I don't remember whether I serious considered that. I don't see it in the Play store. I likely preferred original source.

Looking at the screenshots, it looks like a waste of space. A no go for me, given the alternative.

https://keepassxc.org/assets/img/screenshots/database_view.png

Compare that to the condensed, concise Keepass interface:

https://keepass.info/screenshots/keepass_2x/main_big.png

Being able to build the app as you are trying to do here is an issue we plan to resolve and is merely a bug.