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.

I found this site which might help you in your search.

https://selfh.st/apps/

Food for thought (no pun intended), but unless you’re willing to build an app (could be a great app; I doubt you’re the only person who could use this), you might be over engineering this quite a bit. A spreadsheet could be made to do what you’re looking for, with much less effort.

Thank you. That’s the part I was missing.

I’m confused. The article makes note that, “Mullenweg has demanded a royalty fee of eight percent of WP Engine’s monthly revenue for continued access to Automattic’s WordPress servers and resources.” But then goes on to note that David Hansson, “believes Mullenweg’s actions do not honor the principles set by the GNU General Public License (GPL).”

It sounds to me that Mullenweg wants compensation for their server resources, not use of their Wordpress software — otherwise wouldn’t everybody who uses WordPress outside of wordpress.com be on the hook too?

If that is the case, how is it any different than RedHat charging for support services for their distribution of the Linux kernel and corresponding GNU software?

I feel like I’m missing something here.

Linus Torvalds: creator of Linux and Git, and hero to all English teachers everywhere!

<?php
declare(strict_types=1)

😏 😁

🏃‍♂️💨

You found an important bug in your short code plugin. Removing the line from .gitkeep is not actually the solution; it was a symptom of a much bigger and more dangerous problem: you are inadvertently including and parsing a file that is not intended to be a short code.

You, or a crafty hacker, might one day create a file with code in it that should not be parsed as a short code, and not realize that it’s being done. You’re lucky that you’re the one who discovered this and not somebody else.

The solution is the only parse the files that you need to parse. This means ignoring hidden files that begin with a dot. You might also think about creating a default ignore list for any other non-shortcode file that could exist.

This post is still not Linux related.

…the Logitech AI mouse.

That should be false advertising; both to consumers and investors. There is nothing AI about a dedicated button preprogrammed to launch an application that does the AI for you.

But I guess that further demonstrates your point about companies cramming shit in consumer’s faces to appease investors. It’s still a huge WTF in my book though.

Where’s the flex in that statement? How is suggesting you’d have rolled over and let another country bully you better than the “underdog” country fighting back and giving the bully a hard time? I must’ve missed a memo somewhere along the way.

The way I look at it is this: I want credit for the work I do, I should also be able to fork a repo that I work on, and I sure as hell don’t like giving up my rights if I can help it.

But others may feel different.

They are nuts. Their license means that you give up all of your authorship rights to the code you contribute, and on top of that you’re not allowed to distribute modified source, nor can you fork the source for any purpose.

Edit: lol

That’s ok. It’s a process and takes time. You got this!

“Not bad, I had fun.”

If it’s someone who didn’t go, “Hey, sorry you missed it. Maybe next time? It was a blast.”

Try to stay positive. It’s too easy to give in the negativity. Negativity is like a basket of crabs; you try to pull yourself up, but it will grab you and drag you back down. If you’re okay with that kind of life, stop here and keep on keeping on. If you want to be happier, ignore being alone and sad and do something about it (fake it until you make it).

When you feel sad, feel sad. But don’t “be” sad. You’re not a sad person; you simply have sad feelings. And it’s okay to feel things. Allow yourself to process those feelings.

As I’ve gotten older, I’ve found that quality trumps quantity. Don’t look at it as right or wrong; good or bad. Think about it as what met your expectations, and what didn’t. Take what didn’t meet your expectations, and learn from it. Don’t burn your bridges with those who couldn’t make it; they may have forgotten, or something came up. They deserve the benefit of the doubt. Finally, focus on the positives: you had five people show up for you! That’s awesome!

I’ll admit I’m no c/c++ aficionado, but after a little research I see what you mean. Originally, C++ was a superset of C, but C has since diverged to include things that are not in C++. So we are both correct.

In before the pedants: clang is a c compiler, in that it compiles c code—but it also compiles other languages too. The distinction is that c, c++, rust, etc are compiled directly into byte code , whereas typescript is transpiled into another language (JavaScript) before it is executed. I’ll probably catch heat for this, but you can liken TypeScript to C++ because they both are supersets of another language.

I feel you’ve missed my entire point. My comment was not based on any technical merits of a language. It’s about a persons personal (religious) view of a tool they use to do their job.

I proudly use PHP, JavaScript, Java, Bash, and SQL. They have given me the means to make a long and fruitful 18+ year career. If my boss walked up to me tomorrow and said I needed to learn Python, or Rust, or even brainfuck, I’d learn it and be better for it.

Would it be as easy as my tried and true toolset? Not at first. I still remember the struggles I had when I was first learning my current toolset. It was frustrating. I remember cursing how stupid this or that was (especially PHP and JavaScript). But I learned, and now they’re not as frustrating — because I work with it, and not against it.

Look at JavaScript. Yeah it’s weird sometimes; if you don’t understand how it works. So people slap these transpiled languages or frameworks (like CoffeeScript or TypeScript or whatever) on top, trying to fix the things they think are wrong with JavaScript, and end up making a chaotic mess of the entire community. (And yes we could spend months arguing pros and cons of any merits of transpires and frameworks and why and what not, but then you’re still missing the point).

Anyway, the point is: if it works, then it’s good. Rust does not make Linux worse. If anything, it makes it better because it makes it more accessible to programmers who know Rust but not C. And that’s a good thing. It ensures the Linux kernel will be around longer than whomever ends up being the last C developer.

Those C developers bitching about how they don’t like the idea of rust in their kernel are akin to those old fogies yelling about those damned kids and their loud music or fashion sense.