My 2021 Honda CR-V doesn’t get close to EPA MPG but the range calculator is still accurate to within maybe 15%. I’ve tested it a few times driving from Oakland to LA which is right around the full range of the car and it gets pretty close- even with a whole mountain range to drive over north of LA. It doesn’t appear to use EPA MPG for its estimates and it makes for a better experience.
How do you define difficulty? I’ve seen companies with vastly different opinions on difficulty based on how they’re set up. Can I edit the difficulty based on my own company’s needs?
Definitions we use when rating savings opportunities are below.
Right now users can’t edit the difficulty but that’s helpful feedback if you think it’s something you’d use!
Would you want the ability to change difficulty to one of our fixed difficulty categories or the ability to add a custom difficulty unique to your org (e.g. custom difficulty based on internal approvals/processes at your company)?
Easy: zero downtime, zero performance risk
Medium: zero downtime, potential performance tradeoffs
This seems like a fair way to split it up and would apply to a broad range of scenarios. I actually lean towards the tool being more opinionated about classifications like these- I’ve seen many tools that bog themselves down because people focus on making granular adjustments to the tool itself rather than using it to execute. A special purpose tool like this should be able to nudge me towards best practices without giving me too many opportunities for distraction!
Thanks for the input. Definitely tough to balance being opinionated and guiding with best practices vs being flexible for unique company use cases and right now we're trying to "nudge" :)
We particularly wanted the "Easy" savings opportunities to be things a cloud cost owner (Head of Infrastructure or Cloud FinOps) could execute centrally without creating tickets for eng sprints. Quick wins.
New Zealand is a long flight but IIRC it’s about a 21 hour time change to California (give or take DST) which only feels like about 3 hours. (Not defending the subject of the article, just an interesting time quirk).
I don't see CSS-in-JS as a rejection of separation of concerns. In fact, one of the big advantages of CSS-in-JS is that it lets you decide how best to separate your concerns.
Using hand-tuned CSS will undoubtedly be the most performant option, but it leaves you with very difficult problems at the boundary of your styling and content/structure concerns. If you have even a sliver of dynamic content in your website, it will quickly become near-impossible to verify that your content and styles work together as expected, or even to verify that your class names match between your CSS and HTML.
On the other hand, if you use CSS-in-JS, what you lose in performance you gain in compatibility guarantees between your concerns, regardless of how you prefer to separate. Are you putting your styles in the same files as your layout components to fully separate one feature from another? Great, you can unit test those components and be reassured that the elements are styled as expected. Are you isolating your styles to only a certain subset of components that deal directly with styling concerns? Also great—if you're using TypeScript, you can guarantee correct use of those styles at build time.
For a large enough team, those guarantees really pay off. If you have lots of customers using 2G/3G networks and want to hand-roll your CSS, I commend you! For most products, I think there's a better way to make that tradeoff and your users won't mind a slightly slower experience that has fewer bugs.
If you want to replace all the styling in your project, because you've had a rebrand; I would argue that CSS in JS makes your life more difficult.
If you want to share styling between your app and your website; I would also state that this process is made more difficult.
If you want to create, implement and maintain an atomic design system to build in consistency and reuse .. again, more complicated that it might have been.
To add to that, this article suggests that there's a performance deficit.
In the US almost everyone uses SMS. iMessage uses the same app as SMS, changing the message type based on whether the recipient can accept iMessages. So, most iPhone-to-iPhone communication ends up being SMS because we don’t have to change what we’re used to.
The motion reminds me of the “crab scratch,” [1] a DJing technique that uses finger tapping to move the cross fader rapidly in a similar way. I wonder if someone brought the technique over from DJing or if it’s a kind of convergent evolution.
Interesting. I’m currently working on an “IoT” device and this seems like it could theoretically work. One concern I have is that there’s an initial step where the device creates an access point so that you can enter wifi credentials that it will use to connect to your home network. In this case, the device connecting to the local server will not have internet access, and would not be able to resolve the plex.direct domain. Maybe I can rely on the browser dns cache, but that seems pretty sketchy...
I think it’s important context that this author recently had her book “Irreversible Damage: The Transgender Craze Seducing our Daughters” blocked from sale at some outlets. You can decide whether that helps or hurts her argument.
If you’d like to learn more about what the Black Lives Matter organization worked on last year, you can see their 2020 impact report, including some impressive voter turnout results [1]
If you’re interested specifically in organizations that make breakfast, there are organizations like People’s Breakfast Oakland, which does great work. Not sure if they do omelettes though. [2]
