And like cars, replacement ebike batteries are absurdly expensive. $500-600 for a few 18650 and a BMS.
Part of it is that a battery pack is legitimately dangerous at that scale (so lots of testing/safety certifications etc). But those are one-time design costs that should be amortized.
I would really like to see some standardization around battery packs for both cars and bikes, so that it could become a commodity market for packs.
I really dislike it when a turing-complete language is used for configuration. It almost always breaks every possibility to programmatically process or analyze the config. You can't just JSON.parse the file and check it.
Also I've been in projects where I had to debug the config multiple levels deep, tracking side-effects someone made in some constructor trying to DRY out the code. We already have these issues in the application itself. Lets not also do that in configurations.
> It almost always breaks every possibility to programmatically process or analyze the config. You can't just JSON.parse the file and check it.
Counterpoint: 95% of config-readers are or could be checked in with all the config they ever read.
I have yet to come across a programming language where it is easier to read + parse + type/structure validate a json/whatever file than it is to import a thing. Imports are also /much/ less fragile to e.g. the current working directory. And you get autocomplete! As for checks, you can use unit tests. And types, if you've got them.
I try to frame these guys as "data values" rather than configuration though. People tend to have less funny ideas about making their data 'clean'.
The only time where JSON.parse is actually easier is when you can't use a normal import. This boils down to when users write the data and have practical barriers to checking in to your source code. IME such cases are rare, and most are bad UX.
> Side effects in constructors
Putting such things in configuration files will not save you from people DRYing out the config files indirectly with effectful config processing logic. I recently spent the better part of a month ripping out one such chimera because changing the data model was intractable.
This is what's nice about Pkl, you define a schema as a Pkl file, you define a value of that schema as a Pkl file that imports the schema, `pkl eval my file.pkl` will do the type check and output yaml for visual inspection or programmatic processing, but keeping it to one file per module means that I almost never obsessively D-R-Y my Pkl configs.
Actually that's not the biggest benefit (which is tests for schemas) but it's nice to have the “.ts” file actually log the actual config as JSON and then the app consumes it as JSON, rather than importing the .ts file and all its dependencies and having weird things like “this configuration property expects a lambda.”
I still have to see a JS project where the config for each tool could not be something simple like `.toolrc`. We could have some markers to delineate plugins config.
Instead, there’s a another software in the configuration of sample projects, instead of just using good code organization and sensible conventions.
It's been a bit since I've done this (I'm not watching live TV anymore), but something like HDHomeRun worked fine.
It basically pairs an antenna with a small computer to convert to network traffic, then gives you an app on your streaming device to play it back.
You do need to be able to run the vendor's app, and you'll get stuck with that UI for live tv (So yeah - totally agree that you're compromising the UX). But still no reliance on the "smarts" built into the tv.
I have an HDHomeRun box and use it through Plex. I've never installed the HDHomeRun software. Plex immediately recognized it as soon as I plugged it in. There is a noticeable amount of latency between selecting a channel and starting the stream, so channel surfing is pretty cumbersome, but I almost never do that. With the paid version of Plex (Plex Pass), you also get DVR support which automatically removes commercials from the recording, so that's pretty much the only way I use it.
Good to know - At the time I wasn't self-hosting as much so I hadn't explored that.
You're right, though - both Plex and Jellyfin seem to have pretty good support these days, so if you're already running one of those it's a nicer integration.
You generally don't want a smart tv you can hack. You want a decent computer you own sending signal through the external inputs.
The SBC in the TV is, hands down across basically every "smart" TV I've interacted with, a cheap piece of crap (even well into the "expensive" brands and models).
Manufacturers stick the absolute cheapest garbage in there that can output the advertised resolution during playback without stuttering.
So you can spend hours/days/week wrestling this cheap, underpowered board back from the manufacturer... or you can just side-step it entirely and spend much less time and effort sticking a decent computer you own behind the tv.
Personally - what you're asking for is type definitions.
And it's a blurry line, since type definitions are a good form of documentation. It's just that type-system tooling has mostly replaced the need to go read through the docs for that. I expect to get it easily and obviously in whatever editor or IDE I've configured.
I think the prevalence of example based documentation is because of this trend - don't waste time manually writing the same thing type tooling is going to give your users anyway.
When I hit docs - I'm much less interested in the specific arguments, and I'm very interested in "Capabilities": Problems this tool can solve.
Examples are a great showcase for that. Especially if I have a specific problem in mind and I just want to know if a "tool" can solve that problem, and how to use it to do so.
---
If I have a type system: I want examples first.
If I don't have a type system: 1) I'm not happy. 2) I want examples first, followed by the detailed arguments/return/data structure docs you're referring to.
It's the API specification. It's not just the functions and their parameters, it's also an explanation of what they do.
> I'm much less interested in the specific arguments, and I'm very interested in "Capabilities"
And that's exactly what an API specification provides you, and that examples do not. Examples only tell you how to use the API on the same way that the author is using it.
I really want both. I can follow examples and read specifications, but i likely want the simplest example first if I'm using a tool, and then the specifications after i've used it a few times.
it's much harder to imagine everything a tool can do with only the specs, and I'm not clear what things I'm missing. Examples make it concrete
The most annoying problem I run into with strongly typed languages or even typed python for that matter, is what on earth do I expect this to return?
With python, it could be a mysterious class that isn't explicitly mentioned.
For Rust, you often need to know 4 layers deep of nested types for various error and flow control, and once generics are introduced with the expectation of implemented traits, it all goes out the window.
If I need to declare the type of a value ahead of time, or know it's shape to serialize, check, etc, I want a very clear "this is what it returns, this is how it's expected to be used".
It's not like this is going unnoticed either, though.
The International Ski Federation (FIS) now bans fluorinated wax in all their competitions, and this wax is explicitly called out alongside cookware in much of the legislation that's going around in places like CA/CO for PFAS bans.
I'd argue that the "structural" bottleneck is actually just the same "pay" bottleneck.
This was the whole issue with allowing guilds in the first place... If you only allow a guild to do a job (legally) and the guild also controls how many members they train and accept... The end result is a labor shortage.
Because it's better for the existing members of the guild.
If they train a large number of new members... they spend time and money on training, and they've increased their competition during bidding which drives down rates.
So instead you train the bare minimum for replacements. This keeps your members' rates high and competition low.
---
Any time the "pay is great" but the "process to get it sucks!"... you're seeing this in action. It's not that the process really needs to suck, it's that the process roadblocks are there to maintain high pay for the existing trained members.
If there's one thing monopolies don't like... it's competition. And legally enforced certifications are wonderful monopoly creators if you don't manage them carefully.
That's one of the reasons US-trained doctors are in such short supply. The government controls the number of slots in medical schools, and from what I can tell the government does pretty much whatever the AMA wants.
I'd argue that without competition, it isn't capitalism, and before someone "no true Scotsman"'s me, Adam Smith wrote about the dangers of monopolies in The Weath of Nations. Where Scotsman isn't a well defined term, and neither is capitalism, coloquially anyway, maybe, but a free market would have rival trade unions with different certification processes and employers would decide which certification was preferable.
"Neoliberalism" became a dirty word for lots of reasons (mainly because it caused a ton of people in developed nations to lose their jobs, as manufacturing capacity shifted to developing nations and developed nations leaned into the information economy), but there was a time when the word wasn't tainted and the pro-market Democrats of the Clinton era absolutely self-identified as Neoliberals.
They liked competition and markets, delivered strong economic growth, and brought the deficit down, but they fucked up by not funneling some of those efficiency gains into education and training, and toward building a robust social safety net to help the economically displaced.
pro-communists want a system without competition. Pro-capitalists do want competition or at least no restrictions. People who are practicing capitalists would love to not have competition.
Think of a prize race. The people organizing the race and the audience want a highly competitive race. But the racers, if they are in it for the prize, would love to have little to no competition.
Artificial restrictions on who can do a thing is not good and it is violence behind, whether it is government or not.
Anarcho-capitalists are the true expression of the ideology of free markets.
You could just eliminate the regulations on who can and cannot be an accredited investor. It's a bit paternalistic to tell people what they can and cannot spend their money on in the first place tbh
True. Average people are sophisticated enough to understand complex financial instruments designed to scam them by an army of lawyers and MBAs trained at the finest financial institutions and law schools.
How does having a net worth of $1M or an annual income of over $200K inure you to being scammed by complex financial instruments?
Also, we already let people engage in sports gambling (which is guaranteed to result in a net loss) and cryptocurrency speculation, (which is a zero sum game). I'd rather give people more options to invest in financial instruments that at least in theory have the potential to be positive sum, since we're not going to ban either of the other two any time soon.
Your examples of cryptocurrency and sports gambling are a perfect example of my criticism. There are virtually no people that are sophisticated enough to succeed in either of those activities as they are all based on pure speculation and luck. There is no actual asset in either of these cases. While some modern crypto coins might be back with actual assets, many crypto coins are backed by only speculation and no actual assets. Basically they’re scams.
Yes, that was my point. Both are scams, but both are very legal. It seems dumb to bar people from investing in real, productive assets (even complex ones that might have a poor rate of return relative to index funds) when we let them "invest" in things that are guaranteed losses on average.
Ex - we already have plenty of cases where the government outsources payment processing to 3rd parties. What happens when that private 3rd party declares it's not accepting payments through anything except a mobile app?
