Allowing multiple versions of a library to run simultaneously is a design decision - there are definitely shortfalls to allowing this (increased code size, a relative nightmare to audit, increased tendency towards downstream dependencies opening vulnerability potential). Culturally with bundler it tends not to be an issue since the inability to run multiple versions of packages tends to reduce the number of secondary dependencies to only pretty core libraries, and encourages permissive version requirements for gems.
Do you mind sharing some details? This doesn't match my experiences at all really - while I think running into messes with NPM is sometimes a little overstated, the number of times I've needed to do something drastic like `rm -rf node_modules` is not insignificant and I've never had to do anything at all like that with Bundler.
The only problem I can really think of is working through issues when two gems require different irreconcilable versions of a library, and that's more of a fundamental ruby issue / design choice than a problem with bundler itself.
I have had to use older versions of npm on unsupported nodejs. There was no pinning, or guard rails with upgrading. I have borked the entire npm install doing that because the later npm wanted to use newer syntax that was not backwards compatible.
What you and I describe is not a bundler or npm problem so much that the software we are working on requires an outdated version of ruby and nodejs.
I agree with the the other comment though — npm has more problems even when with the latest version. Like Nodejs, it is flawed by design.
I wouldn't say "very" for me but it's definitely not as smooth as your average webpage. This is pretty edge casey use of HTML / CSS though, it's not surprising that browsers wouldn't optimize for it since this is more of a stunt than the best way to achieve this output.
This is cool! I really wish the authour formatted their HTML more nicely though - it's fine through the inspector but this is the sort of thing where I instinctively reached for "View Source" and with the whitespace stripped it's basically unreadable.
The HTML is just a div per "artwork" the css is the only interesting part. Much better to just: Right click, inspect element. To see the magic behind each piece.
Google did this early on with android - originally the Google devices (Nexus) were lower end, and high end devices were left to other manufacturers. They've flipped around recently, but I think the Nexus line was a decent enough idea at the time.
The Nexus devices were initially badly designed high end devices, starting with the Nexus One, which was among the first smartphones with an OLED screen but had too little internal storage to be useful. There was no intentional strategy there to build a bad product, just bad product designers making bad design choices.
Nexus was supposed to be reference platform with a harmless quirk or two, not necessarily low or high end. The idea was everyone builds for Nexus and apps run everywhere.
I mean, Apple does have a procurement process. If you're selling at the large team / department level or up (i.e. not individuals within Apple), you're dealing with "Apple" at least for the sale through security and contract reviews, etc.
> cameras and mp3 players (and phones!!) are basically a thing of the past thanks to the iPhone
This was all true with the first iPhone though. That's the point. I'm sure that the Vision pro will be refined, but what will be necessary to make this a mass market device seems more fundamental than just a lot of refinements.
When the iPhone came out, I remember thinking it was too expensive and not for me, but I definitely wanted one and was jealous of the few people I knew who had one. I just don't have that feeling with the Vision Pro - to the point where I feel if I was given one for free I still couldn't see myself using it much.
That's sort of rare for Apple devices - even if I think some things are ridiculously overpriced I would always be happy with a free one and make good use of it.
It’s because you probably had a phone before the iPhone.
If you’re not already a vr user then it’s hard to imagine how this will fit in your life.
For me, if I happen to get an opportunity to strap a vr device to my face be interested to play around, but not motivated enough to go out of my way for it.
As a developer, I already spend a fortune on devices and simply can’t see any of our products benefiting from vr…this was true with oculus, and is still true with vision pro.
My kid has a VR headset, along with a few of his friends. He certainly uses it but it's a huge exagerration to say that he spends more of his free time in VR than real life. Minecraft / Roblox / Fortnite you could make an argument for maybe (depending on age).
All of his friends with VR headsets as well. It's an occasional toy sort of device for pretty much everyone I know. I realize that the plural of anecdotes isn't data, so if you have actual data I'm happy to see it!
You're almost always going to have to leak some sort of ID in an API, otherwise your API is going to be exceptionally hard to work with. You could choose to have a separate external ID, but provided that knowledge of an internal ID doesn't convey any information or additional privilege, it's not that big a deal.
Utilizing pasta water is something that Italians have been doing for ages but until recently wasn't a common feature of American pasta recipes. I'm sure restaurants were doing it, but your average mass market cookbook only started mentioning it in the last 5-10 years or so.
reply