True, you could insert something in the middle, that generates a page depending on the user-agent.
But then it requires extra SSR logic.
But on the other hand, you can have a iOS or Android based app that depends on the same data. So the browser is not the only client in general, especially nowadays, I think?
That's the crux of the question. The BFF approach says that you remove logic from the client and put it in a server-side component. Not that you add extra logic. Then you might find that you need to copy that server-side component sideways for a new client, if the view layer in that client is sufficiently different to what you already have. The browser can be the only client of its BFF API; the mobile apps can either speak to the same API or have their own.
Dramatically more important than any theoretical, abstract consideration in deciding whether this can work is what your teams look like. The client team should almost certainly own the BFF API, which has implications for skillsets and maturity.
The intellectual exploration is understanding that we have a better understanding of medicine, and ADHD is just like other conditions we can now treat.
but sure, lets ignore over a century of research and progress because someone wants to ask "what if" and treat all that as an emotional response.
Meh, medical research in terms of psychology (disorders) is largely based on how well a person functions in modern society, which is sick. Since the OP asked the question in terms of sociology/evolution, it makes sense that the medical literature would not say much about it.
"All of your colleagues have done something dumb. Don't be afraid to tell us when you make a mistake. We all remember our first screw up and will be happy to help."
Never have truer words been spoken.
As I tell all the new juniors at work doing sysadmin type tasks, everyone has deleted the production database at least once. Mistakes will always happen, it's how you deal with them that defines how good you are at the end of the day.
It’s also a measure of how well management does in response. We were transferring a software production repository from one machine to another, Lord knows why, when a junior admin I was supposed to supervise had arrived a half hour early and started the operation without me. He got the source and destination arguments reversed in the file transfer; we were using DD for this one part of it.
Management reacted pretty well. They assured both of us that while we made the mistake, it was not our fault that data was lost: the problem was that backups were not being checked, which caused us to lose the resulting three days (120 developer days) of work. The manager in charge of the folks doing the backup got taken to task - but nobody else did.
I did something like this once my senior year of high school. I was using XCOPY to copy a copy of Counter Strike: Source that someone had placed on the U:/ drive, but reversed the order of arguments so that instead of copying it to my desktop, I copied everything on my desktop to the directory.
For whatever reason, we had write access to that directory, but not deletion. I had to get the teacher to delete it for me.
> Don't be afraid to tell us when you make a mistake. We all remember our first screw up and will be happy to help.
This is very much dependent on the circumstances - sometimes people won't be supportive or encouraging, but cold at best and toxic (rude, making fun of mistakes, letting their egos run wild) at worst. This is more likely to happen in some work cultures/companies than others, and there can also be individuals that are allowed to persist with their problematic conduct in otherwise okay environments.
If you are ever in such environments, acknowledge the fact, possibly push back against stuff like that and definitely be on the lookout for alternatives, where you'd be able to prosper.
Thankfully, my personal experiences have mostly been okay, but I've definitely seen both attitudes and choices that can make everyone's lives worse, to the point where I wrote the satirical article "The Unethical Developer's Guide to Personal Success": https://blog.kronis.dev/articles/the-unethical-developers-gu...
There are limitations to that, as you well know, since you hedged with “much of.” And this is, again, a nitpick around the edges and not really a comment that addresses my main point.
unfortunately this also needs to be done server side, unless your trusting the client to send you information that is what your expecting?
client side validation makes for a good user experience, but it does not replace the requirement to validate things server side, and many times you will end up doing the same validations for different reasons.
If it's merely a hint for the user (did you make a typo?) there's no need to ensure "this is a valid email address". in fact: foo@gamil.com is perfect valid email-address, but quite likely (though not certain!) not what the user meant.
I've seen hundreds of email-adres-format-validations in my career, server-side. The most horrible regexps, the most naïve assumptions[1]. But to what end?
What -this is a question that a domain expert or business should answer - does it matter if an email is valid? trump@whitehouse.gov is probably valid. As is i@i.pm[2]. What your business- expert quite likely will answer is something in line of "we need to be sure we can send stuff so that the recipient will can/read it", which is a good business constraint, but one that cannot be solved by validating the format of an email. One possible correct "validation" is to send some token to the email, and when that token is then entered, you -the business- can be sure that at least at this point in time, the user can read mail at that address.
[1] A recent gig was a Saas where a naïve implementor, years ago, decided that email-addresses always had a TLD of two or three letters: .com or .us and such. Many of their customers now have .shop or somesuch.
[2] Many devs don't realize that `foo` is a valid email-adress. That's foo without any @ or whatever. It's a local one, so rather niche and hardly used in practice; but if you decide "I'll just validate using the RFC, you'll be letting through such addresses too!". Another reason not to validate the format of email: it's arbitrary and you'll end up with lots of emails that are formatted correct, but cannot be used anyway.
It doesn't matter if an email has a valid format: that says almost nothing about it's validity. The only way you can be sure an address can receive mail(today) is by sending mail to it. All the rest is theatre.
And all this only matters if the business cares about deliverability in the first place.
No, I understood your point and I agree sending the email and getting some type of read receipt is necessary.
You seem to think that because of this client validation should be skipped. On that point I disagree. If you can tell that it's not a valid email address (bigtunacan@goog obviously invalid since missing a TLD) then no email should be sent. Good UX is to let the customer/user know there is a mistake in the email address.
It's a shame your number one reason is customer support, when at least in my experience it has been woefully lacking.
Despite having a reasonably large contract with them at work, we had multiple support tickets go without response for months, with at least one that I am aware of being left open for almost 2 years before being closed as "won't fix"
Noting that its only my personal experience I am sure plenty of others have had the opposite experience, however I have found canonical support to be vastly superior as as such I would never chose RH if support was the primary thing I was after.
That sounds like an account management issue. You need to know how to manage and work with vendors more often than not it’s not the size of the account that matters but how you engage with them.
to be clear when I say no response, I am talking they got consistent updates that essentially said "we have no update on this issue", not them simply never putting anything on them.
also like it or not, by paying for support people have a right to expect that the company being paid will be engaging with you and the request you are putting into there system, not that you will have to find a person to chase down because your tickets are being ignored.
The GDPR only applies to businesses, not individuals. So, clearly in this case it does not apply at all since the person behind @ElonJet is acting in an individual capacity.
The GDPR applies to everyone, except "by a natural person in the course of a purely personal or household activity", member states and some authorities.
sounds like you need to go talk to the FAA since they are the ones originally publishing this info rather then a twitter account that is just consuming the info.
Companies that use the data published by the FAA are required to not display information about planes that are part of the LADD program (which Elon's Jet is).
This data is not from the FAA, but from ADSBExchange, which crowdsources the data.
It’s funny how even despite the fact I didn’t address this situation here to try to speak generally people inevitably found there way back to Musk - but the entire point of doxxing is you take public information and repackage it and focus it in a way to help target an individual. Just because the FAA publishes flight information doesn’t imply they are doxxing someone, if someone built a custom app to track everything a specific famous person was doing including this FAA data, that would be closer to what doxxing actually is.
There is no value in reinventing the wheel, and not doing so gives you time to do other things that will give you value so someone should always be asking the question of if something should be done.
The vast majority of the time, the browswer is infact going to be the only client.
once you reach the point where its not, then build the api to suit the new client rather then trying to build one that does both.