My usual workflow with archive files (that I've just downloaded) is clicking the file in my browser's download list to open it and then extracting it. In WinRAR, the extraction path is pre-filled to be "<archive directory>/<archive name>", and there is an option to automatically open this folder after extraction. 7-Zip doesn't have this, so I'd need to manually add the archive name to the extraction path and then separately browse to it. Granted, if you browse to the archive and right click it, 7-Zip does have an option to extract to an "<archive name>" folder (though this still doesn't automatically open it afterwards), but that's an unnecessary extra step.
There might be an oversaturation of Mac native apps on the HN front page relative to Linux/Windows native apps. I, too, feel a bit disappointed when they are posted for the same reason as SomeCallMeTim (especially if it's not clear from the post's title that it's Mac exclusive and it only becomes apparent deep into the linked page), but I also know there are tons of native tools for Windows and Linux — they're just not discussed here as often. Though this could also be confirmation bias on my part.
Would you be able to give a ballpark figure for the extended licenses? I'd rather not get into a sales funnel before knowing what kind of numbers I should expect. In particular, I'm interested in being able to use the full set of icons rather than being limited to 100/project (and having to track that).
As pointed out in the linked article, the stats conflate unwelcome/unrequested notification prompts (e.g. Reddit, which pops up the prompt the first time you open the website (or used to anyway)) and cases where the user explicitly requests/opts in to notifications. I feel like the latter is something that proper web apps that don't utilize dark patterns could make very good use of. Consider the 85% acceptance rate for the camera/microphone prompt; few websites request camera/microphone permissions in the same intrusive way as they request notification permissions, hence it's not declined as often.
I personally moved to Apple Music with my music library. Allows uploading and then streaming your own songs, has a streaming subscription option and a store to purchase music, and works on the devices I use. And while iTunes on Windows may be clunkier than Spotify, it's a hell of a lot more usable - for my use cases anyway.
I have lots of music that is not available on streaming services, so being able to upload and stream songs is a must for me. Spotify only offers syncing between devices which is definitely not the same.
In my experience, 99% of the relationships I fetch fit the basic one-to-one, one-to-many, many-to-many definitions that pretty much all ORMs support. For these cases, the queries are generally more than efficient enough and there's little reason to reinvent the wheel and implement the code for fetching those relationships yourself.
For anything more complex, I agree. But for the common case of fetching simple and often (depending on your project) nested relations, I definitely enjoy the abstraction provided by ORMs.
It seems you cannot load relationships for a collection of entities easily without N+1 queries, unless I'm missing something. Based on the many-to-many section of the docs (https://github.com/Seb-C/kiss-orm#many-to-many), I would have to load relationships for each entity separately, and then if they have further nested relationships, run a query for each again. The subsequent section also mentions eager loading is not supported.
For me, being able to load relationships (and especially nested relationships) with little boilerplate and few queries is probably the most useful feature in an ORM (usually explicitly eager-loaded), so I'm sad to see it's not supported.
Do you want the manufacturer of your computer or its operating system - and only them - to be able to specify exactly who can and can't develop software for it, and whose software you can and can't run? I don't, and I don't see any situation where I'd want a single entity to have that power, even if it comes with security benefits (which are not mutually exclusive to this setup either).
They didn't say anything about whether it merits 10k people, they were curious what all those 10k people are doing. I'm curious about that as well - clearly LinkedIn is doing much more than I was aware of.
In everyday business, I would generally start with the day and then follow with the month if it's relevant (often it's not, if talking about a date in the near future), and finally by year if needed. I can't imagine when I'd start with the month, really, but that might be because in Finnish you'd almost always say and write dates with the day first.
As far as date formats go, apart from the ISO format, "21 Jul 2020" is definitely my favorite and always unambiguous. The only downside is that it's language dependent.
I don't know about this one. For example, I'm not going to invite every one of our clients to our Slack as a single-channel guest, nor am I going to be joining their Slack workspaces (if any of them even have one - most of them are in the Microsoft ecosystem). I'm also not going to do that with every vendor I'm in contact with, and so on — email is much more convenient. That being said, most of our internal communication within the company is on Slack, but that's a small slice of what emails are used for.
ES6 is plain old JavaScript. I think the parent commenter's point was that even when you're writing plain JS, if you target browsers (and old browsers specifically) or e.g. a large range of Node.js versions, you often still need to transpile it. This naturally doesn't apply if you target a specific runtime version (e.g. a specific Node.js version).
That being said, the commenter above them could've also been referring to old old JavaScript where no transpilation is needed to reach practically every target environment.
When the margin works, the logic makes sense. 50vw sets the padding of the side in question (e.g. left) to the middle of the screen, 50% subtracts half of the containing element's width (<body>) from it. Doing this for both left and right and then negating it with equal negative margins results in the content area in the header being centered and having the same width as body, but the padding stretching out to the edges of the window.
> I would still prefer to have to trust just one authority for my platform than a multitude of random developers.
These are not the only two options. What about multiple authorities, but not random individual developers? That's basically how it works with e.g. game stores on PC (though Steam is certainly the largest), or package repositories on Linux.
Like you, I like being able to trust an authority to vet the software I install rather than having to judge the trustworthiness of each individual developer, but I'm not a fan of there only being one authority by design (as it is on e.g. iOS). It introduces a single point of failure and gives that authority full control over all software on that platform - for better or worse. Many package managers specifically deal with the issue of consolidating updates to a single system while not relying on a single authority.
I switched back to Firefox (after using Chrome for a long time) back when Quantum launched and have stuck with it since. Initially I fell back to Chrome every now and then for the devtools, but I haven't felt the need to do that for a good while now. Works really well for my use cases at least.
Subpixel AA is absolutely not unnecessary these days. I've seen a few programs switch off from it recently (in favor of grayscale AA) and every time it's been noticably more blurry. For example, Discord had a bug that disabled it just a few weeks ago (which has been fixed since), and Twitch's redesign also disabled it in their desktop app (which is why I now use Twitch almost exclusively on Firefox). Both of these apps are based on electron/chromium though, so text rendering, even with grayscale AA, could be better in some other programs.
Unless we completely abandon small font sizes or switch exclusively to high-dpi screens (will likely happen eventually, but we're not there yet), subpixel AA can look much sharper than grayscale AA if properly configured and you're not sensitive to the color fringes (personally, sitting at about an arm's length from my monitor, I don't notice them at all). And I'd rather not have text rendering quality suddenly downgraded on my existing peripherals before that happens.
just a scrollable div of a couple dozen large images is enough to make it stutter seconds at time while they load and render
I might be wrong, but with WebRender, isn't scrolling now done asynchronously so it doesn't stutter while things are loading? I certainly haven't experienced any scroll stutter since I turned it on.
;){kind=link}
[1] https://github.com/js-temporal/proposal-temporal-v2/issues/5