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.
Almost every tool in my current weekly use is cross-platform, with the one exception being Visual Studio (and that only when I'm working on a C# app and I don't really have a choice in the matter).
And I use a ton of proprietary tools: SmartGit, Beyond Compare, DataGrip, Postman, Word/Excel, Sublime, Docker Desktop, Blender, Slack, Discord...
The only thing I can find that's Windows-only are the two tools that make up for the shortcomings of Windows shells: MSYS2 and ConEmu.
Seriously; cross-platform (or at least multi-platform) is the future. The frequent posting of Mac-exclusive apps seems to be more about Mac-snobs trying to brag about (and justify) their decision to rely on Macs.
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.
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.
Implementing eager-loading with the current philosophy of kiss-orm would be tricky and difficult to use/read. It did not seem a high-priority, so I chose to not implement it for now.
Depending on the ORMs, the definition of eager-loading also varies.
I have seem ORMs doing everything in a single query, returning everything in a single result-set and then de-duplicating everything client-side. This is very messy (and impossible to hack/fix most of the time).
Currently, the way to go would be something like this:
const articles = await articlesRepository.search(sql`
"authorId" IN (${sqlJoin(
users.map(user => user.id),
sql`, `,
)})
`);
// Dispatch and assign the articles in the collection of users
I could consider having a helper method to make this easier, but I am afraid this would be quite difficult to use.
Agreed on the N+1 query problem, but I'm a bit mystified why people still choose ORMs for any projects with even a moderate level of database complexity. When using a straight SQL layer (JDBC or the basic features of KISS-orm) the query is in SQL form and the performance characteristics of the query are obvious from the query or can be analyzed easily by taking the query and running it through the database's query analysis tools. Using an ORM just adds extra steps: instead of optimizing a query in SQL, the query needs to be optimized using directives or methods or annotations that the ORM provides in the hope that the SQL that is ultimately generated is efficient; that is, we're programming the ORM which programs the database instead of just programming the database. Why bother with the extra step? With modern programming languages there really isn't that much extra boilerplate to implement the DTOs for straight SQL and it usually results in code that is a lot easier to maintain and extend in the examples I've seen.
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.
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.
