I don't agree with a ban, but burning crude oil (are you sure about that, it's usually refined at least a little?) can have centralised carbon capture and filtration, whereas cars pretty much just pump it straight out. Luckily they made the smoke invisible so it's ok, almost like it's not even there!
I don't think banning combustion engines is fighting the right battle, but incentivizing the alternatives (e..g lowering or removing sales tax) is a good idea.
We don't actually want to scrap working cars unless they have reached the end of their life or passed an air quality threshold (UK tests every car over 3 years old, every year, called an MOT). Reduce, reuse, recycle etc.
Mine did more than 25,000, just get better tyres. The basic premise is that EVs are heavier and have more torque than average cars, but it's a 20% difference in real life, so your tyres may last 20% less.
I know road damage is far higher (fourth power of weight) so maybe wear on tires is also worse than linear?
heavier vehicles are also worse in many other ways (e.g. less safe for pedestrians, require more space for parking,...) and we really should be encouraging smaller vehicles.
Close but no cigar, if you're trying to achieve VB like hunt and peck productivity then XML doesn't cut it any more now than it has in the last 30 years or so.
Blazor is pretty productive if you're looking for a mature component based XML (Razor) syntax but again, there is no Visual design element to throw thing together.
This is nice, my main criticism would be that it uses the language "easy" and "simple" regularly which is a classic mistake in any instructive text (including docs etc).
If the reader was feeling a bit dumb and/or embarrassed that they didn't yet get the concept being explained then this will only make them feel worse and give up.
Language like that is often used to make things feel approachable and worry-free, but can have the opposite effect.
And never ever, ever write "obvious" in a doc explaining something, because if obviousness was at play they wouldn't be reading your doc.
I think about wording like that, like the extraneously explicit meta-content that dumbs down so many story plots. A character explicitly says "That makes me angry". When a better written story would make the anger implicitly obvious.
Stories should show not tell.
Make a point, make it clear make it concise, and it will be simple for most readers. Don't talk about making a point, or say a point is clear.
That is projecting attributes or experiences onto readers. But even a very well written point may not appear simple for some readers. Assume (optimistically!) that there will always be some unusually under-prepared but motivated reader. Hooray if you get them! They can handle a challenge every so often.
"Simple" communication is a high priority target, but rarely completely achievable for the total self-selected, beyond intended, audience.
Oh man. The variant I see so infuriatingly often at the moment is “It is clear that these form a Lie algebra/finite abelian group/Hilbert space/bijective map/<whatever other thing that is long-winded or complex to prove> and I encourage the reader to satisfy themselves that this is the case”.
Always encouraging to see that ideas can work out. I'm not quite managing the "let's build a team" aspect just yet but otherwise similar journey and outcome over a (slightly) longer period.
I just wanted to not deal with certificates, now I deal with certificates all day every day lol: https://certifytheweb.com
Probably a couple of hours on support per day on average, some days less, some days more. The vast majority of users don't ask for support, they prefer to read the docs, read the community forum, goggle stuff or hunt-and-peck options in the app. Roughly 90% use the free version. If everyone used the paid version I could have a very large team, but the reality is the product competes with many free tools.
If you update the app or refine docs in response to previous support questions it does streamline the experience but there are always folks who just don't read docs and there are many who will purchase the app just for access to support so they can figure something out.
I'm sure some apps are more support heavy than others, but ours is aimed at system administrators and with that comes an assumed level of competence (in reality, many people are only in the role because nobody else could/would do it but even they are quite independently resourceful).
The disadvantage of users helping themselves is that you don't get feedback from them or learn about their use cases. Knowing how/why people are using your stuff is really valuable for development, so if I had the team for it then dedicated support engineers would follow up with customers early on even if they don't have issues.
Did you consider adding an optional survey (or just an input or two) somewhere in setup or the onboarding flow? I bet some % of people would willingly tell you how/why they are using the software.
reply