Web Developer by day, and aspiring Swift developer at night.

  • 2 Posts
  • 171 Comments
Joined 1 year ago
cake
Cake day: July 1st, 2023

help-circle


  • Don’t live your life to please other people. It’ll make you miserable because there will always be those you can’t please. Instead, define for yourself what a “good vegan” is, and do your best to meet that standard. Everybody is different, and only you know what works for you.

    Also, be forgiving of yourself. Everybody makes mistakes; no one is born an expert at anything. The fact that we still bite our tongues while eating is proof of that. So give yourself grace when you make a mistake; learn from it, and become better.


  • dohpaz42@lemmy.worldtoProgramming@programming.devBaby unit tests
    link
    fedilink
    English
    arrow-up
    27
    arrow-down
    8
    ·
    edit-2
    1 month ago

    Instead of just doing what I want to do, I’m stuck either doing plumbing work to hold my values and pass them around, or I’m casting things back and forth where I know things are correct but the compiler doesn’t.

    I hate this attitude.

    Instead of doing what you want to do? Dude, unless you’re a hobbyist, you’re being paid to do what your company wants you to do; i.e., it’s not about what you want.

    Stuck doing plumbing work? Yeah, nobody likes plumbing, but we all know it’s necessary. When you’ve got your proverbial shit backing up onto your floor because you cheaped out on plumbing, cry to me then.

    If you’re casting things back and forth, you’re doing it wrong. Spend a day or two and build yourself a solid, consistent foundation, plan ahead, and you won’t be casting things back and forth.

    And no, you obviously don’t know better than your compiler, you arrogant sack of sh…

    Anyway, get over yourself already and just do your damn job better.





  • dohpaz42@lemmy.worldtoProgramming@programming.devSelf-documenting Code
    link
    fedilink
    English
    arrow-up
    6
    arrow-down
    1
    ·
    2 months ago

    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.


  • 👆 This. In my experience, I’ve seen a lot of developers get upset about “their code” not being used, time wasted, or someone else changing the code after the fact. Who cares? Once you commit that code, it’s no longer your code. It’s the company’s code. Your paycheck will reflect the same amount of money regardless — and if it doesn’t, you may want to find a better employer. 😅


  • dohpaz42@lemmy.worldtoProgramming@programming.devSelf-documenting Code
    link
    fedilink
    English
    arrow-up
    13
    arrow-down
    6
    ·
    2 months ago
    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’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.