bottombottominate
FTFY
Web Developer by day, and aspiring Swift developer at night.
bottombottominate
FTFY
You can say the same things about sports betting.
It’s fucked up for sure. Investing is akin to gambling in Vegas. Any one otherwise inconsequential detail could completely bankrupt you, and we’re expected to pin our elder years on this system.
Burn in fucking Hell Raegan.
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.
👆 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. 😅
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:
get*
and set*
should be reserved for working on an instance of an objectis*
or has*
for Boolean returnsfetchUser()
, validate()
, create()
UserService.createUser()
valid
vs isValid
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 initializationif {}
statements. Short-circuiting is cutesy and all, but it makes code more complex to read.{}
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.
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.
Well for one, it encrypts all communications so that people can’t snoop on what you’re doing.
Ssh! 🫢 You’ll ruin the joke!
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)
😏 😁
🏃♂️💨
According to the PMBOK (7th edition) by the Project Management Institute (PMI), daily standup is a “brief, daily collaboration meeting in which the team review progress from the previous day, declares intentions for the current day, and highlights any obstacles encountered or anticipated.” Source
To be fair, daily standups are defined however your group collectively decide to define it.
For those who decide to report the work from previous day, it’s expected that you would have made your list before the meeting, not during. It’s a practice I too struggle with. 😊
Hm. Might not be standup that’s the problem. Might be a company culture thing. But only you know that for sure. Good luck op! Disassociation can be a life saver.
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.
…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.
This only could’ve been better if this was a picture frame a phone of the monitor with the screenshot open in whatever the default screenshot app is for the is.
Those commit messages though 🤣