> 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.
When the USB audio device class was created [1], it had support for AVR-like audio controls (volume, balance, tone etc.), and, like would be reasonable, made all that work with decibels. But, as far as I know, that part of the standard got ignored by basically everyone, including some of whom wrote it (Microsoft), by presenting e.g. the on-device volume control as a 0-100 scale, like Windows and ALSA still do. Except... some hardware devices actually implemented the spec, including the PCM29xx family of audio codecs. These, and clones of them, have been used in quite a few USB audio cards and some very low-end audio interface over the decades. And for those, "100" in Windows means something like "+30 dBfs" [2] - so you'll get extreme distortion with basically any signal.
[1] 1.0 is actually impressively complex and basically models the entire stack of audio devices someone could have possibly had in their TV cabinet in the 1995, including stuff like dolby and surround decoders.
> 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.
I don't get this Firefox hate. I use Firefox and I'm pretty happy with it and the product's direction. I'm also fine igoring products and features that I'm not interested in.
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 being at the bottom has nothing to do with what mozilla does. Its because they are going against google that pesters you to download chrome. The network effects of everyone downloading chrome for 15 years. The idea that google is one of the largest companies on earth and mozilla is a rag tag team. Firefox is better. You objectively have a worse experience on chrome or edge or safari. Most users otoh just don’t care about vetting software. They stick to what they know. Go to a library or cafe and be disappointed how many people browse the web with zero ad blocking because they simply don’t know any better.
I think we can recognize at this late date that most 'hate' on the Internet is about a form of fun, one kind of social interaction and self-expression and not about the object of abuse. People express hate about everything under the sun (and on HN).
Most of it is a performative rant, sort of like a stand-up comedy routine. The target is just material for the routine; nobody takes the comedian too seriously. Every HN thread has it.
Firefox is perfectly customizable. You can make the tabs look however you want with a config. Want them out of the way and appear when you mouse over on the left edge? You can have it like that. You also don’t need to use any features you don’t want to use. You can even hide them entirely with a config file.
> 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].
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.
That's a fine (and arguably superior) philosophy for a simple personal site.
But it just isn't practical for a commercial product that needs manual testing. If you have a single breakpoint, you only have 2 versions to test. If you ultimately have 30 different breakpoint values, that's 31 versions to test. And that's a lot of opportunity for CSS rules designed in isolation to wind up colliding with undesired results.
Not to mention a nightmare for any designer to attempt to document expected behavior.
But your site can be broken at different sizes even without breakpoints. From a QA perspective with manual testing, there's no difference whether or not developers have used breakpoints, the question is whether the application is working for the users' screen sizes. And, as the article points out, they are myriad.
To test that the responsiveness works everywhere, the easiest thing is to probably go to the "responsive" tool in the browser's devtools, which opens the page in a little subwindow inside the main browser window, and then you can resize the subwindow freely to check a range of different sizes (rather than just an explicit set of them).
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.
Curious about this take, since I've done it successfully many times. Orchestrating a backend for frontend is usually a pretty trivial task. It's usually just mapping one json to another.
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.
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?
Incredibly dismissive of somebody's work, aren't ya? I regret breaking my own self-imposed rule of never answering follow-up questions on HN because there's always somebody willing to hand-wave away six months of my life and 40 years of real-world experience with a flippant comment of "oh, but that's easy if you don't have too..."
And you sir, are fucking toxic, just looking at your comment history I can tell that. So you calling me "fragile" carries about as much weight as the next idiot with an opinion.
Quick google yields very good examples in huge improvements on a single algorithm level: https://youtu.be/c33AZBnRHks
Easy to imagine how even smaller improvements across 10-100 steps of data processing, can become even better.
I find TDD antethetical to this... you really need to actually understand the problem space - that requires large scale experimentation, not the micro-structuring TDD preaches.
> Maybe we should invent a paradigm and write a manifesto about it. We can call it... test-driven development.
Isn't test-driven development the opposite, though?
If the program is layered as layers A (main program), B (business logic), C (data objects) and D (persistent storage), TDD would have you first do the interface (and tests) for D before you do anything for C.
You only realise if D is missing something (or worse, has superfluous features) once you start doing C. Same when you get to B.
When going API first, you go top-down. You first figure out what the interface to the main program (A) should be, then you figure out what the interface to B should look like, etc.
I always have to program from both sides, and hopefully meet in the middle. You need your low level stuff before your high level stuff works. but you don't know what low level things you will need until you do the high level things.
My understanding is that TDD would start with the main program (A), testing functionality that is exposed to the final user. The later layers would only be written if and when they are required for the end-user functionality.
I think that User-Centered Design (UCD) would be a better term here for what this concept is trying to say. In modern design, we tell user stories that help guide development of interfaces, including APIs.
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.
albums weren't sold in blank sleeves. Lot's of stuff around the album was there to make it more exiting. Album design, liner notes, and even record stores are all part of a past "exciting" music listening experience, that author argues Spotify do not want to bring to their users.
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.
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.