Here's a comment from the creator with a host of things that are mostly not available in Chrome:
There's a huge list of things Polypane emulates beyond the screen size.
For devices:
- user agent
- reported platform
- device pixel ratio
- rendering mode (mobile rendering and desktop rendering respond differently depending on your viewport meta tag)
- default input device
- orientation APIs
Beyond that it can also emulate reading direction, page language, browser locale, user-configured default font-size, different network settings and a whole range of different media queries like color-scheme, reduced-motion reduced-data, reduced-transparency, prefers-contrast, forced-colors (windows high contrast mode) and color gamut. I'll be adding even more device browser-specific emulations later this year.
I don’t know chrome devtools enough to say whether or not it already has all of these features. I will say that you can place a nail with a hammer, but if you’re building houses for a living, it might be best to invest in a nail gun.
You have a (very common) mistaken view of what the W3C is and how it works. It is NOT an independent standards body that tells browser makers what to do! In fact, it's the exact opposite: the browser makers (and Google is a big one) tell the W3C what to do.
This makes perfect sense if you think about it, because the browser makers ultimately decide what goes into the browser. If the W3C was "in charge" and tried to make Google (or another browser maker) do anything, Google could simply ignore them. That system wouldn't last.
It has to work this way ... and Google (along with Apple, Microsoft, etc.) have decided this syntax is best for them (and possibly their users).
Kent Beck is just as bad as Uncle Bob! He drank his own proverbial Kool-Aid and went all in on the crazy XP programming fad he started (... which contains brilliance like requiring pair programming for every line of code written).
Look, both authors are very smart people who have great insights into development that we can all learn from ... but both also have the failing of being way too in love with their own ideas.
It blinds them to the flaws in those ideas, and makes it so when you read their work you have to be skeptical and evaluate each individual idea on their own.
to come up with and advocate for paired programming before the concept existed _is_ pretty brilliant. And you also don't understand how much those practices improved software engineering, presumably because when you started programming they were already entrenched ideas, and so all you see are their shortcomings.
Those ideas do have flaws, and most of us are looking to improve how we right code. So if you aren't blind to those flaws, please, write a book or a blog or whatever on the best ways to write software so that we can all learn.
Force it on people, you'll see how much it works. Getting another pair of eyes on the code that you wrote is useful, but it's not free (effort, tolerance) and it's not for everyone. Just do proper code reviews. Middle ground.
IME code reviews are a bullshit half-measure that ends up as the worst of all worlds. It's tragic that so many companies settle on them as a compromise position.
> Getting another pair of eyes on the code that you wrote is useful, but it's not free (effort, tolerance) and it's not for everyone.
Yeah, but to be fair I would argue that in the limit, real code reviews end up looking a lot like pair programming, and you can avoid a bunch of back and forth by both people being present during development.
Obviously you still need code review (for regulatory reasons in a lot of cases), but the amount of times I've ended up on a Zoom talking through mine and others PRs makes me believe that pair programming would help here.
> and you can avoid a bunch of back and forth by both people being present during development.
I don't like pair programming for personal and cultural reasons (eg: I am uncomfortable with the _process_, but not the results), but the people in the pro-pair-programming camp will say the quoted bit above is one of its strengths. You back/forth and fix or change things early in the process.
Doing a code review is "too late", since these early decisions that could have been made differently/better effect all the code that follows it into a further less-optimal space.
So, this is anecdotal, and it's not true at the moment (because the end of the Santa Cruz wharf just fell into the ocean, and now the clam chowder restaurants are closed), but ...
... I had an ex who was a huge clam chowder fan, so she did her own "experiment" and tried every chowder-serving restaurant on the Santa Cruz wharf (I think there were seven).
Her completely unscientific finding was that the very best chowder was at the end of the wharf, and generally speaking the chowder got worse as you got closer to the start of the pier (ie. the closest place to The Boardwalk ... where all the tourists come).
It makes perfect sense to me: if people come to your restaurant because of its location, you don't put much effort into quality. If you're far from the walk-in traffic, you need to do something (like make really delicious chowder) to get people to walk out to you.
"We also looked at different types of psychedelics and didn’t see any systematic differences there."
This was the most fascinating finding to me. I really wouldn't have expected Salvia, Acid, Shrooms, etc. to all produce the same hallucinations ... but I guess ultimately they're all operating on the same core neurochemicals, so I guess it makes sense.
This. There’s obvious differences in salvinorin and psilocybin effects and both are well represented in the data. But keep in mind the current paper only looks at existing categories of visual effect. The second study might include a finer taxonomy.
They don't, they are drastically different in character. There are close similarities within classes between some of the lysergamides, substituted phenethylamines or tryptamines. But even closely structurally related analogues can be extremely different (ex. 2C-E vs DOET vs 2C-C).
LSD is almost nothing like psilocybin or mescaline or DMT. And nothing is like salvinorin...
At low doses they're pretty similar. Moving patterns in wood grain, breathing objects, faintly fractalesque structures. When you take more they get fairly different.
I know it's dumb, but when a library requires me to install Yarn to install it, I think so much less of it.
I just hate the idea that I have to install an entire package manager simply to use some Node.js code, when NPM almost certainly could have done the job.
It's not a library, it's an application. You're quoting a section called "Installing from Source". Obviously that'll require you to use the build tools the developers happened to have chosen.
There's also a Docker option if you don't want to do that.
Seems like it’s because they’re using the resolutions feature to override a dependency resolution. The alternative would be forking at least 1 package, all the way down to the dependency, to fix the version.
There’s a reason there’s 3 popular package managers for Node that aren’t NPM. Yes, part of that is the culture/ecosystem, but not entirely.
True. Either way, Umami's been using `yarn` since 2020, before that release of NPM (although for what reason at that time, I don't know).
Being bad thereby creating desirable competition has lasting effects. We could get into when/why/what each thing supports all day, but it's not worth it.
Speaking of what's supported nowadays, installing other package managers is a corepack call away -- literally a whole other feature built into Node.js because NPM is/was/etc subpar. It's experimental, but this is all to say: it doesn't surprise me in the slightest that a project might use something that isn't NPM, and I actively expect it when picking up other's projects.
It may not be dead, but it does seem a bit stagnant. Based on Google Trends at least (https://trends.google.com/trends/explore?date=today%205-y&ge...), Elm has the same general interest level as it did five years ago (despite going up a bit in-between).
Apple did NOT create the smartphone. When the iPhone released in 2007 it was a feature phone- no app store and famously missing featured like copy and paste. Besides Palm who you have mentioned there was Symbian and Windows Mobile which each had third party after market apps available.
Indeed Apple did not invent the concept of the smartphone. But by all accounts the first iPhone was absolutely considered a smartphone, based on its superior hardware, advanced operating system, and fully-functional web browser.
You seem to be equating "smartphone" with "has third party apps", but that isn't the defining characteristic of "smartphone" based on any common usage.
Besides, when the iOS App Store was launched ~1 year later, the original iPhone was able to use it.
I had a Nokia n95 at the time. It also had superior hardware and a fully functional web browser. Yes the iPhone was attractive at the time but not initially a smartphone and certainly not the first
I did not say iPhone was the first, I said the opposite. And again, your definition which equates "smartphone" with "has an app store" simply differs from widespread usage of the term.
Both the n95 and original iPhone were widely considered to be smartphones at the time! Examples:
Apple & Android took the smartphone from something that belonged in a businessman’s belt holster to something that lives in the pocket of every person on the planet who can afford it, from niche to ubiquity. For sure they did not invent “phone with store”, but they did create or strongly participate in a complete change of the market that left the earlier players - Windows Mobile, BlackBerry, Nokia, etc buried six feet under.
The fact that the very foundation of our legal system is fundamentally undemocratic (in the sense that no regular citizen can be reasonably expected to understand it) is starting to bubble up into societal awareness.
With everything Trump is doing to destroy the rule of law, and all the potential for technology to help us simplify it, I can only hope that when Trump burns it all down, the people who rebuild will be wise enough to do better.
I think this might be a missed analogy, rule of law isn't like a house that you can burn down and rebuild stronger.
The default state without rule of law is rule of the strongest. The law is like pillars that support a tunnel. Once these are weakened, the tunnel goes crashing down, and it has to be dug again.
The society backslides to authoritarianism. And the price for digging a new tunnel is often a lot of blood.
I have little faith that, should it all be burned down, recreating it all from the ground up that it would be better.
People need to accept that what Trump is doing is only possible because of what his predecessors put down as law. That means democratic presidents too.
I didn't see Trump's detractors call all of this out when the winds were blowing their way. So no, I have no faith that rebuilding it from the ground up would make it one iota better. Not without deep societal changes.
'v2';
At the top of every file could let us eliminate all this 20-year old cruft (like document.all hacks to support Internet Explorer).
Yet, despite the already established `use strict`; (which is basically 'v1.5'), the community seems completely against modernizing the language.