the operating system does not interpret it in anyway.

*in any_way. ;)

doesn’t fill me with excitement.

I’m skeptical too, but I choose to retain some optimism in a world with so much terrible stuff. This project seems to have more than zero potential, without introducing obvious great harm.

We all look forward to the success of your superior alternative.

it’s not clear in the article what they’re doing with the waste they recover. Simply moving it around doesn’t eliminate the garbage. And the project does not appear to include a budget for recycling or otherwise repurposing what they recover.

I found this with three clicks on project’s web site:

“Once our containers are full of plastic onboard, we bring them back to shore for recycling. For each system batch, we are making durable and sustainable products. Supporters getting the products will help fund the continued ocean cleanup. Catch, rinse, recycle and repeat - until the oceans are clean. The sunglasses are a proof of concept for this.”

It might not seem like much yet, but it’s better than nothing, and we have to start somewhere.

What about Googling stuff offline?

The fearful side of Chesterton’s Fence.

I don’t validate emails, I test them.

Hooray! You get a gold star.

OK, maybe I do some light validation first,

I hope your “validation” does nothing more than show a warning that the user is allowed to ignore.

I have seen too many systems built by people who think they know what’s valid or not before and after the @ sign*, and they are almost always dead wrong. In the worst cases, such systems accept an unusual-looking address and claim to send the expected verification message, but never actually send it. Of course, these systems won’t work for some people, and since none of their online docs or support staff know why, those people will be locked out of using the system and funneled into bottomless pit of misery if they try. Please don’t build broken garbage like this.

*Fun fact: Not so terribly long ago, even the @ sign didn’t have to be present. Some email addresses were bang paths. I’m not sure if any of these are still in use, but it wouldn’t shock me to learn that they are.

Use a library

Please, no. If someone wrote email address “validation” complex enough to warrant a library, then their code is almost certainly wrong.

or check for only the @ and then send an email confirmation.

Yes. Do that.

If your boss demands a more detailed check at input time, then make it display warnings, not errors, and continue to the confirmation sending step if the user chooses to ignore the warning.

That change is about True and False, not true and false. If OP was thinking of the former pair, it would seem my “different identifiers” guess was correct.

Python doesn’t have true or false keywords, nor any other primitives by those names.

So either you’re thinking of a different language, or different identifiers, or someone assigned equal values to variables with those names and then blogged about it.

It’s refreshing to see someone on social media who doesn’t dismiss code as “outdated” just because of its age.

I didn’t think I would have to spell this out, but when I wrote “as much as possible”, I was acknowledging that some libraries are either too complex or too security-sensitive to be reasonably homebrewed by the unqualified. (Perhaps “as much as reasonably possible” would have been better phrasing.) Where the line lies will depend on the person/team, of course, but the vast majority of libraries do not fall into that category. I was generalizing.

And yes, some third-party libs might get so much public scrutiny as to be considered safer than what someone would create in-house, depending on their skills. But safety in numbers sometimes turns out to be a false assumption, and at the end of the day, choosing this approach still pushes external risks (attack surface) onto users. Good luck. It hardly matters to the general point, though, because most libs do not have this level of scrutiny.

Let’s also remember that pinning dependencies is not a silver bullet. If I didn’t trust someone to follow “best practices”, I don’t think I would trust their certification of a third-party library hash any more than I would trust their own code.

With all that said, let me re-state my approach for clarity:

• I minimize dependencies first. Standard libraries are great for this.
• When something more cannot reasonably be avoided, I choose very carefully, prioritizing the safety of my users over my own convenience.
• Sometimes that means changing my original design, or spending my time learning or building things that I hadn’t planned to. I find the results to be worth it.

https://csszengarden.com/

This applies to developers, too.

External dependencies put end users at risk, so I avoid them as much as possible. If that means I have to rethink my design or write some boring modules myself, then so be it.

Thank you for including the text as text.

SimonSays make me a sandwich

One thing that would be helpful about not using drop-down boxes for static options: Fewer clicks required to set up a search. Each of the drop-down boxes in use now requires the user to:

• Read the text on the drop-down box to decide whether it’s relevant
• Move the mouse to the drop-down box
• Click to open it
• Read the options within
• Move the mouse to the best fitting option
• Click to choose the option

The first drop-down box (search type) contains only five options, which could be replaced by buttons like the existing Subscribed/Local/All buttons. It would make discovering the available options easier because they would no longer be hidden behind a drop-down, and it would reduce the number of actions required of the user.

The second drop-down box (sort type / time frame) might be a good candidate for this change, too.

As for whether tabs would be a better choice than the button-style approach currently used by Subscribed/Local/All: I’m not sure right now, as I haven’t had much time to consider it. But I think things would get messy and possibly confusing if more than one of these input elements were converted to tabs, because it would mean nesting tabs within tabs. On the other hand, using a row of buttons for each category would allow them to coexist neatly, fit the existing visual style, and avoid adding the complexity of another widget type for users to navigate.

I hear we are a rich nation.

By “we”, do you mean the US? (I’m guessing based on the dad here living in a US state.)

My impression is that US billionaires and large corporations are rich, but most US residents and social benefit programs are not.

It’s refreshing to see actually uplifting news here for a change. Thank you. ;)

human brains are weirdos.

Truer words were never said. :)