Mastodon: https://toot.cafe/@pimterry
TypeScript has become my go-to general-purpose option. Between Node.js & the web you can build anything (and share code between all these different domains), the JS ecosystem is huge so there’s existing libraries & examples for everything, it gives you a good balance between productivity & performance (much faster to run than Python, much faster to write than Rust), and proper typing solves the rough edges of JavaScript without being so strict that you have to fight it.
I work with Kotlin, Rust, and Bash for various other specific things (e.g. Android apps, very low-level/high-performance code, and widely-compatible scripting) but 9 times out of 10 I’d reach for TypeScript if there isn’t a special reason.
I’m the maintainer of HTTP Toolkit - it’s not a Postman alternative (it’s an open source project focused on intercepting & debugging traffic, not sending it) but I’m actually working on building a UI for exactly this right now, so this thread is perfectly timed!
Is there anything that any of you really love or hate about any of the tools suggested here?
What core features beyond just “edit method+URL+headers+body, send, view the response status+headers+body” are essential to you?
Anything you wish these tools could do better?
I’m planning on taking the client functionality live within a few weeks max, so if you want to help your perfect Postman alternative come to life now’s the moment 😁
Honestly, I’d be surprised. Fighting the EU on technicalities when the intention here is so clear is going to be hard work! To even get close to a good case, they’d have to change all the marketing for the device to show it’s clearly being intended as a primarily water-use product. The words “primarily” and “regularly” in there aren’t just decorative, they’d really have to demonstrate that to make it stick! Seems to have more downside than just making the battery removable in the first place.
The full quote also has this bit:
This derogation should only apply when it is not possible, by way of redesign of the appliance, to ensure the safety of the end-user and the safe continued use of the appliance after the end-user has correctly followed the instructions to remove and replace the battery.
Since real phones do already exist that are both waterproof and have removable batteries, I think it’s very hard to plausibly say “it’s impossible to design this in a way the user can safely remove the battery”.
Of course, to know for sure we’ll both just have to wait and see 😄
Thanks! That’s interesting to see, looks like this is an amendment? I’m not totally sure how that bit of the legal process works here.
I’d be surprised if this is intended to apply to mobile phones though - very few phones are used primarily in an environment of water immersion. They’re designed for incidental protection, but the regular day-to-day use case is pretty dry! I’d read that as intended for things like watersports & diving equipment.
Do you have a reference for that? From all the documentation I’ve seen elsewhere, that’s not true. There’s no exclusion for waterproof devices, and everything has to be possible with tools a normal person can buy (you might need to go to a local hardware store, but no unique specialist expensive kit).
The full law is here: https://www.europarl.europa.eu/RegData/docs_autres_institutions/commission_europeenne/com/2020/0798/COM_COM(2020)0798_EN.pdf. It only mentions ‘water’ 3 times and none of them relate to waterproof phones (they’re talking about batteries of waterbourne transport & environmental impact of water use) so I don’t know where that’s coming from.
It’s totally possible to make waterproof phones with removable batteries - Samsung did it with the Galaxy S5 (IP67 - 1 meter under water for 30 minutes) way back in 2014 and there’s lots of other examples. It’s just not quite as cheap as glueing everything together.
Hahaha, that might be British-specific I guess? I always assumed it was universal. Just means “a long time”.
https://www.merriam-webster.com/dictionary/donkey's years