“There is another theory which states that this has already happened.” — Douglas Adams

It’s unfortunate too, because history has a lot of stories that would make for great media. But it seems there is a war on history these days. At least recent history.

You say that like it’s a bad thing. 😉

Ha! Yes. Thanks for asking.

I was woken up this morning by my dog yakking. She’s fine, but it got me thinking how I don’t usually get up so easily with a regular alarm.

That’s a great idea. Maybe make it so you can load up as many customizable sounds as you like, and they randomly shuffle each time.

If this is true, then it’s not a setting that users can access. At least not that I can find.

Best you can do is auto wipe after 10 failed pins.

Did you floss for me big daddy?

Yeah. But they’re spitters.

Those commit messages though 🤣

bottombottominate

FTFY

I don’t understand why they don’t just migrate .io into a non-country code domain. Hell, they could auction it off to anybody (company, country, or person) who wants it bad enough. Let it live alongside the other custom domains.

We’re kind of seeing that with those private jet trackers. But that’s not changing anything except getting those accounts banned from social media.

This should be illegal. There is absolutely no good reason this should be available to anybody. It should also be considered unconstitutional; if one of those dots is a person, whether you directly know who the person is or not, it should violate the right to privacy and the right of illegal search and seizure — no questions asked.

Because right now’s political climate is about how abortion is being billed en masse as murder, and people are having to go to other states to get abortions (even for miscarriages), so the states that bill abortion as murder want to be able to prosecute the women. So there are a lot of fears that states will be tracking women through tools like this, and it turns out the fearful were correct.

Let’s bring back those animated gifs (mailbox and under construction) from the 90s. That’ll get everyone riled back up again.

That’s fair. How would you go about implementing the service? I always love seeing other people’s perspectives. 😊

I wouldn’t. Not from this example anyway. YAGNI is an important paradigm and introducing plenty of classes upfront to implement trivial checks is overengineering…

Classes, functions, methods… pick your poison. The point is to encapsulate your logic in a way that is easy to understand. Lumping all of the validation logic into one monolithic block of code (be it a single class, function, or methods) is not self-documenting. Whereas separating the concerns makes it easier to read and keep your focus without mixing purposes. I’m very-engineering (imo) would be something akin to creating micro services to send data in and get a response back.

Edit: Your naming convention isn’t the best either. I’d expect UserInputValidator to validate user input, maybe sanitize it for a database query, but not necessarily an existence check as in the example.

If you go back to my example, you’ll notice there is a UserUniqueValidator, which is meant to check for existence of a user.

And if you expect a validator to do sanitation, then your expectations are wrong. A validator validates, and a sanitizer sanitizes. Not both.

For the uninitiated, this is called Separation of Concerns. The idea is to do one thing and do it well, and then compose these things together to make your program — like an orchestra.

async function createUser(user) {
    validateUserInput(user) || throwError(err.userValidationFailed);
    isPasswordValid(user.password) || throwError(err.invalidPassword);
    !(await userService.getUserByEmail(user.email)) || throwError(err.userExists);

    user.password = await hashPassword(user.password);
    return userService.create(user);
}

Or

async function createUser(user) {
    return await (new UserService(user))
        .validate()
        .create();
}

// elsewhere…
const UserService = class {
    #user;

    constructor(user) {
        this.user = user;
    }

    async validate() {
        InputValidator.valid(this.user);

       PasswordValidator.valid(this.user.password);

        !(await UserUniqueValidator.valid(this.user.email);

        return this;
    }

    async create() {
        this.user.password = await hashPassword(this.user.password);

        return userService.create(this.user);
    }
}

I would argue that the validate routines be their own classes; ie UserInputValidator, UserPasswordValidator, etc. They should conform to a common interface with a valid() method that throws when invalid. (I’m on mobile and typed enough already).

“Self-documenting” does not mean “write less code”. In fact, it means the opposite; it means be more verbose. The trick is to find that happy balance where you write just enough code to make it clear what’s going on (that does not mean you write long identifier names (e.g., getUserByEmail(email) vs. getUser(email) or better fetchUser(email)).

Be consistent:

1. get* and set* should be reserved for working on an instance of an object
2. is* or has* for Boolean returns
3. Methods/functions are verbs because they are actionable; e.g., fetchUser(), validate(), create()
4. Do not repeat identifiers: e.g., UserService.createUser()
5. Properties/variables are not verbs; they are state: e.g., valid vs isValid
6. Especially for JavaScript, everything is const unless you absolutely have to reassign its direct value; I.e., objects and arrays should be const unless you use the assignment operator after initialization
7. All class methods should be private until it’s needed to be public. It’s easier to make an API public, but near impossible to make it private without compromising backward compatibility.
8. Don’t be afraid to use if {} statements. Short-circuiting is cutesy and all, but it makes code more complex to read.
9. Delineate unrelated code with new lines. What I mean is that jamming all your code together into one block makes it difficult to follow (like run-on sentences or massive walls of text). Use new lines and/or {} to create small groups of related code. You’re not penalized for the white space because it gets compiled away anyway.

There is so much more, but this should be a good primer.

Hm. I wonder if I could get those lenses in my prescription. That would be neat.