smarkov

I think Docker has a fairly well designed CLI and I don't find myself having to Google commands for it often. It follows a few pretty consistent patterns that I wish git had tried to stick with rather than the concoction of words and flags for common actions it ended up with.

And that is exactly why they can be changed - because they're valuable details that can be used to track someone down. Your DNA is easily obtainable and is not used in any meaningful way that would affect your life if it was exposed.

I simply don't want to deal with spam or scams. If I'm exposing my contact details it would be a separate set that is dedicated to dealing with communication coming from the public.

Exactly my thoughts.

I'd be more upset if a combination of my name and email/phone number got leaked than if my DNA was made available public.

This makes it out to be so much worse than it actually is.

It's good at what it does - serving media to all your devices. No online accounts, no phoning home, no advertisement, no BS. I've had no trouble with either the web UI or any of the apps available on android/TV. Admittedly I've never used Plex but I can't imagine it doing any of that much better.

Safari is at a disadvantage - it's behind a walled garden and people outside of that garden don't develop or test for it. Sure, that's a trivial issue for a company but not for small team or single person projects.

Not to mention that it feels like Safari is only fast because it does its own thing and doesn't strictly follow the spec. I've often run into CSS specific issues with it when making slightly more complicated animations.

People with technical skills can't accept that, but the ones without them that make up the majority couldn't care less. The vast majority of people don't know how to read or utilize anything past the domain name, hence why you constantly see people copy paste 300 characters long URLs of images from Google. Hell, a good amount of people don't even look at the domain name which is why phishing is so common.

I'd gladly pay not to see ads on a site that has content worth seeing. Facebook and Instagram are not one of those.

> and without a firewall, people on the train will be attacking your containerized apps.

I was surprised when I learned this but Docker by default bypasses UFW and potentially other firewalls relying on iptables.

https://blog.viktorpetersson.com/2014/11/03/the-dangers-of-u...

> Don't change random registry settings or code pages on the user's computer, that's mad.

A million times this.

Multiple Valve games set the microphone volume in Windows to 100% whenever you launch the game, which, for my setup, makes me sound unbearably loud. Unless your app has a valid reason to change my settings, like if I've set it up to do that on a schedule or with some condition, sure, otherwise don't mess with my settings.

> I don't get this Firefox hate.

Just because I'm criticizing something doesn't mean I hate it. I want it to be better, and that's something Firefox needs if it wants to get out of the bottom in terms of usage.

> Firefox remains a stable option to come back to everytime

Don't get me wrong, I've been using Firefox for the last decade and I don't intend on using anything else for the foreseeable future, but Mozilla has no idea what they're doing with Firefox nowadays. Firefox View is the most useless thing I've ever seen, that expiring "independent voices" theme picker was some weird hippie stunt[1], the latest UI redesign which split the tab from the window looks hideous, and it's not like Firefox doesn't have things you can tweak for a more private experience[2]. I miss Firefox Test Pilot where they tried out different new features, I found a lot of them to be very useful but sadly lots of them didn't make it. I don't know what's going on at Mozilla but they seem to lack any vision, they're just existing as an option without trying to be the best option.

[1] https://blog.mozilla.org/en/products/firefox/firefox-news/in...

[2] https://github.com/arkenfox/user.js/

> Even a small number of apps trying to get their own certificates at the same time can exhaust the Let's Encrypt quota for your domain

I got curious about this and decided to look it up, they actually have more restrictions than I expected[1]. Looks like to play it on the safe side you might be better off having a single server issuing certificates and distributing them where needed as well as using wildcards as much as possible. Interestingly, it looks like Google is doing just that since their certificate covers a very wide range of domains[2].

[1] https://letsencrypt.org/docs/rate-limits/

[2] https://www.sslchecker.com/sslchecker?su=b39e88e1c4d3efcdb79...

> I don't know how useful this is.

I think very. I've never designed anything based on arbitrary breakpoints (md, lg, xl and whatever numbers they might translate to) because that forces me to make design choices around those constraints.

The only way to sanely add breakpoints in my opinion is to gradually reduce the width of your page and search for things that start looking off. Are your paragraphs starting to look a little cramped? Add a breakpoint at that width, maybe remove the sidebar, maybe lower paddings and margins to allow it to stay a little longer, maybe manually reduce font size or switch your column layout to rows if applicable. Keep doing that until you get to ~350px width and everything looks fine. You decide what needs to change when it makes sense rather than being told that something needs to change at some specific breakpoint.

Here's just some of the things that become non-trivial in such a scenario:

* Validation - you either replicate the same rules on the generalized API/BFF/FE and risk inconsistencies or figure out a way to extract that validation to a shared package

* Making API calls inside the BFF - usually generalized APIs have a lot of features in individual endpoints, some of which aren't always documented so you'd need a really good documentation that gets constantly updated or some kind of a connector package that makes it easy to discover those features

* Testing - most of your endpoints are just calls to another API, all you can do is mock those calls in your tests based on what you expect the API to return but this gets hairy if you're just copy pasting the same 200 line JSON body across multiple tests so you'll need some helpers/a package for that too. It also requires that you always have a person on your team who's very familiar with how the API you're making calls to works so you don't make false assumptions

You either need someone who's aware of every little detail that goes on in both the generalized API and the BFF or you need all of these constant abstractions to be able to scale properly in any shape or form without introducing bugs with every new feature.

Based on my personal experience general purpose APIs lead to backends for frontends, which is a colossal footgun unless orchestrated by a mastermind. Even if you did have that kind of mastermind, if that person decides to leave you're left with a very expensive puzzle for everyone else to solve.

Here's my take: don't build general purpose APIs, build general purpose domain actions. A user making an account is a domain action. Sending a notification to the user is a domain action. Make doing each separately easy. Make doing both at the same time easy. Do this with all of your domain actions and now you have an easy way of building exactly the kind of endpoints all your front ends need.

Very curious to learn more about what the monolith was doing so incredibly poorly that you managed to squeeze that much performance out of it. Poorly written queries? Too many queries? Lack of any caching? Doing things synchronously when they could've been done concurrently?

I'd go a step further and say this is how you should write all of your code because realistically every single function/class is its own little API.

You can put SSH on a different port but it can still be found through port scanning and poked at. Figuring out whether Wireguard is running at all or which port it's on is, from my understanding, very much not a trivial task if possible at all from the outside. This extra layer prevents attackers from even getting a chance at poking around with SSH.

Sure, Spotify's interface can be bad. It's unintuitive at places, wildly inconsistent in its features between platforms and it feels like it takes forever for any new meaningful things to be added to it. However...

> It starts with creating an exciting music interface that celebrates artistry and creativity.

It's a music player. You play/pause and scrub or go next, how are you supposed to make that more exciting? I don't want unnecessary visuals or music lore on my screen, I want a music player. And so do most other people who put music on, minimize the app and do something else.

This is cool though it contributes to the saturated "let's ship our own browser" space. I need a separate browser to play music, to play games, to communicate with people, to browse the web, and now to run a wallpaper. If only we had a way to use a single browser instance that is utilized by all of these. That's kind of been the selling point of the web all this time - write once and run almost everywhere. You shouldn't need to ship your own browser, though I understand we don't have that kind of capability standardized yet.

So instead of making good games that attract more people they choose to make grindy, annoying games that force players to spend more time in them and likely spend money to reduce those annoyances. Almost like... paying to play less. Counterintuitive to focus on that metric in that case, no?

> The overhead involved in building a react app is nearly nil with all the tooling we have.

All the tooling we have is exactly why React has an overhead which is far from nil. Every package goes through a period of changing its best practices, some go through multiple. Entire packages go in and out of season, seemingly depending on the phase of the moon. There's a new bundler every year, each with its own quirks. For some things there's 4 "go to" packages that achieve the same thing but take a different path to get there. You have all these packages and tooling you have to learn, stay in touch with, maintain and fight against. All of that so you could ship megabytes of JS that ultimately just changes some text on a page. You can do all of that with vanilla JS and spare yourself the headache.

> use public DNS and Let's Encrypt garbageware and leak details of your internal network

Wildcard letsencrypt + internal DNS means you don't leak anything and you don't have to deal with the awkwardness of installing certificates.

> Hosting something like this seems like it would cost more time/money/frustration than its worth.

If you've never self hosted anything there is indeed a large initial time and money investment. However, going through it once it pays itself off in the long run and adding additional services or maintaining existing ones becomes trivial.

Actually owning your data and having full control over it without worrying who it might be shared with or how it might be used is absolutely worth the hassle for some people.

> Being able to quickly scan a large list of emails without scrolling is practical and useful.

Conversely, why is scrolling considered evil? We can agree that emails are documents. In real life, on your desk, do spread out all your documents so you could see them all at once? Or do you have a stack of them and view them one by one? You can still cross reference by putting documents side by side, just like you can with multiple emails open in separate windows or monitors.

Admittedly depending on the amount of emails and the speed at which you work through them you might benefit from seeing many at once, though there's other ways of dealing with that issue.

> All whitespace achieves is aesthetics, which are meaningless beyond initial adoption.

I don't think whitespace is all about aesthetics. Personally, it makes it easier for me to read and focus on things. It gives individual things more value, rather than them being "just another thing in a gigantic list", easily blending in and showing no significance.

I really don't understand this. It already looks a little too clumped to me, what's the benefit to further putting things closer to one another? It's not like you're doing some kind of additive transformation and you need to quickly jump between lines, each email is its own thing and you can only read one at a time. If you need to find specific ones you can always categorize them or use the search functionality. I'm just confused by statements like this.

Please make this the industry standard for testing APIs.

I'm tired of having to look at Postman screenshots sent from QA. I'm tired of having to wait for them to press Send once I've implemented a fix. I know they're tired of waiting for me to do that, too. Hurl is something both the devs and QA can speak and write. It can be automated and a part of CI. It makes communicating expectations straightforward. It can be chucked along with PRs as a starting point for QA. I don't see a reason not to use it wherever possible.

> I wonder if there's a possibility that this will shake Youtube from it's dominance.

Sadly, very unlikely. I recommend AdBlockers and YouTube app alternatives without ads to basically everyone and the vast majority of people would rather watch ads than deal with installing something even if it'll take a few seconds.

There's enough of us (adblock users) for Google to want to take profit from but not enough to make a dent in YouTube's monopoly even if we all moved to something else.

What's the intended way it's supposed to be used? Are the managers and directors supposed to subscribe to it or the developers? If it's the developers, when they need to explain a concept do they just copy-paste the explanations? Forward an email? Send some kind of a link? It seems like an awkward interaction to me.

As a developer, it's always been my job to explain things to non-technical people in as few words as possible during conversations. I'm not sure how a newsletter would fit in that use case.