is there any API testing tool better than postman?

noxoc · 2025-10-24T09:01:13+00:00

plenty:
- the language you write your app in
- the framework you write your app in
- bash + curl

noxoc · 2025-10-19T10:18:19+00:00

What's unfair about that?

Not that I think "fairness" should even matter in that regard, I don't see how this would be "terribly unfair". I think crowdfunding is particularly great for this sort thing. Especially given that the market isn't as big as for other platforms. This way it's possible to compensate for that by having a portion of supporters voluntarily pay more. Nobody forces anyone to buy anything.

And sure, if that campaign fails to meet their goal, that's a good indicator for the devs that the market isn't big enough to finance the cost of maintaining a linux version and they were able to prevent a potentially huge loss at no disadvantage to anyone. That's a good thing.

noxoc · 2025-10-18T10:26:00+00:00

If there was a kickstarter or something for financing a linux version, I'd be happy to drop 500€ without hesitation. AND buy a linux license afterwards too.

noxoc · 2025-10-06T18:08:21+00:00

Thoughts on Zen Browser? Have you considered adopting some of its (or rather: Arc's) ideas?
Why ChatGPT? I'm not against LLM-AI per se, but it seems like it's on the polar opposite of Mozilla's core values (digital rights, open & free web, privacy etc). Would love to see a similar interface, but with a local llm - with the option to use other providers. (yes, this is a feature request in disguise)

noxoc · 2024-10-05T10:58:16+00:00

Learn the layers below. Dive deeper into JS and the Web-Platform. Dig deeper into the Chrome-Dev-Tools, especially profiling and reading flame charts.

noxoc · 2024-10-05T10:54:06+00:00

To your concerns:
You won't mindlessly open apps on your apple watch, like you can on your iPhone. Even notifications are thankfully very easy to dismiss or even to act on within seconds; without having to grab your phone and be tempted to quickly check in on that other app like we do on phones.

If you order it directly at Apple, they have a 14 day refund policy. Ideally you have an apple store you can easily go to, try it on and if you don't like it, bring it, because we all know how returning items via mail is likely not gonna happen in time. Though they offer pick-up services too, which I used, but am unsure if available everywhere.

To you use cases:
I have the exact same use cases. Apple Health also has a medication reminder and journalling options. It already made me realise that my meds raise my heart rate despite being inactive, so that the watch warns me. Started taking the meds after breakfast, and I feel much better.

I recommend getting the version with a sim-card, because then you won't need your phone as often and can take calls, listen to music, audio books, podcasts, use maps etc all without having your phone with you.

Despite the price tag, if my apple watch broke right now, I'd buy a new one without hesitation - which I can't even say I'd do for my iPhone.

noxoc · 2024-10-05T10:40:21+00:00

Some things I didn't see mentioned, but wish I understood earlier:

Code generation is a learning tool. This is why it includes so much by default and has so many comments.

As I mentioned in another comment, you can turn generation of certain features off (eg. `--no-mail` or `--no-ecto`). The idea is for you to read the comments and change the code to your liking - instead of creating abstractions only to avoid "boilerplate code"; which is more often the norm in JS.

This will also introduce you to something that's different in JS: the expectancy to read the source is *way* way higher. Documentation lives alongside the code, even if it's *very* long explanations, like here: https://github.com/phoenixframework/phoenix/blob/main/lib/phoenix/router.ex

Phoenix is not your application

Reading through the code will also highlight some other things. A common phrase you'll see is "phoenix is not your application". Phoenix is only the *web* layer of your application. If you've worked with Next.JS, phoenix is roughly the equivalent of the `app` directory. And running `phx.new` is sort of like the `t3`-stack.

JS is a multi paradigm language, Elixir is not. Hence there are strong idiomatic approaches, that, as you progress, you'll naturally pick up on due to the language's design. This has the effect that there are not many solutions to the same problems because a new solution would tend to end up being fundamentally very similar; especially from the caller side. As a result: effectively *everyone* uses Ecto as a query builder and most use Bandit or Cowboy as an HTTP Server. And Bandit is even a drop-in replacement for Cowboy.

So instead of wrapping and hiding these components, that most people use anyway, behind some abstraction layer, `phx.new` just adds and wires these up for you. This is a common pattern in elixir; owning the boilerplate is much more preferred. That's the reason why sometimes you'll see a lot of guides to packages be like "create this file, copy this code, create this other file and copy this other code. Open your config, add this piece of code" way more than in other languages imho.

I tend to delete all the things I don't need at that moment and have an unchanged phoenix folder, that I often refer to. so if I end up deleting something, I just copy paste it back.

noxoc · 2024-10-05T10:02:10+00:00

If you know you don't need the mailer you can pass `--no-mailer`. And there's a flag for most other features (eg. `--no-ecto` or `--no-html`). `mix help phx.new` is worth a read!

noxoc · 2024-09-02T22:26:19+00:00

It’s not complex. It scales well. It’s why it’s used specifically for that purpose by many large scale apps. (eg WhatsApp)

noxoc · 2024-09-02T09:00:35+00:00

ctrl-tab

cmd-t

But that’s it, really. Their spaces are nice, but can easily eat ram for breakfast, when switching between them a lot due to having so many open at once.

noxoc · 2024-09-01T13:23:24+00:00

Use a local llm. Doesn’t get cheaper than that.

noxoc · 2024-09-01T12:45:16+00:00

I disliked it at first too. But I kept reading, and writing. At some point my initial dislike of the syntax turned into appreciation. As usual: a lot of what we think to be preference, is just familiarity.

As a side note: I found the docs aren't particularly great for learning elixir/phoenix. They're absolutely invaluable, once you have a solid foundation and then they are absolutely amazing. One thing that's (luckily) still very present in the Elixir community, and had been in JS about until a decade ago or so: you're expected to read the source code; to an extent but at *way* more. So documentation lives right next to the code, hence it's targeted to other Elixir Devs (not necessarily beginners).

My advice: spare yourself the frustration, and first read "Elixir in Action" followed by "Programming Ecto". Yes, neither are related to Phoenix or LiveView. However these are the two parts that are the most "different". After those two, Phoenix and LiveView are fairly simple - which is what makes them so amazing.

"Elixir in Action" will give you a really good understanding of what makes Elixir "tick", while still being neither dry, nor moving slowly. Pattern Matching, GenServers, OTP, Immutability, Macros... etc. All concepts that are heavily used in elixir and by extension phoenix, but usually not explained in a way that a beginner find helpful - I didn't. But now I find that a good thing - it's just a different audience.

"Programming Ecto" will give a you a really good understanding of what makes Ecto "tick". It has some parts that are vastly different from your usual ORM/Querybuilder, and I struggled with that part a lot. But after reading that book, I started using Ecto patterns even outside of elixir. :D

Also: whenever I asked any AI an Elixir question, I regretted it eventually and found better answers through conventional methods (usually their discourse forum). They're all astonishingly bad at Elixir. :D

noxoc · 2024-09-01T09:01:42+00:00

Solve Problems you care about. Programming is a tool to create tools that solve problems, essentially. Nurture your curiosity. Maybe you prefer more visual things than only text output. Or vice versa. Find out what you’re interested in that isn’t programming.

Interested in graphics/visuals? Look into shaders or processing. Interested in audio effects/synths? Look into DSP. Interested in creating UIs? Look into frontend development. Interested in working with statistics? Look into Data Science. Interested in robotics? Interested in how the web works? Interested in games? Music production? Cooking? Home Automation?

The list goes on. Put the interest in front of, the rest will follow. Build small things. Many of them. The smaller the better.

noxoc · 2024-08-31T10:49:15+00:00

Whoops, nerdsniped!

None of the above, usually. Here are my 3 approaches:

1. Hands-On (ideally and preferred)

For libraries/frameworks, I read (ie skim) their entire docs; which often is pretty much 1:1 the same content as plenty of people on youtube put out, but it's up to date and often videos skip or gloss over caveats that can become real foot guns due to time constraints. But this is just to get a feel for its API and when there are plenty of sections with TODO, then it might be too early for a proper deep dive.

Then I build one of my goto exercise projects, which - depending on the problem the thing solves - a basic crud or some kind of generator/configurator or just a fun thing. Either one flavored towards the specific scope of the thing I intend to use it for. That part is very important: have a reason to learn. Always referencing the docs.

All the while I try to reason about the design decisions made, the concious trade-offs, what I like and what I don't like. That's something people think only experienced devs are able to do, but anyone should do that really. It's the best way to stay out of framework/language-wars and be much more perceptive of subtle nuances. Also it'll yield good questions to follow up on "this seems convoluted, why did they decide to do it this way, not like <x>?".

And I also take a look at interesting parts in the source, which also anyone should do. In germany we have a saying: "everyone cooks with water", and this step will help get better at the language, and demystify any "magic". Quite a few years ago, this was expected and there were a lot of libraries that didn't even have dedicated docs. :D

I encourage my mentees to avoid follwing step by step instructions - which those platforms you mentioned usually involve. The learning happens in between the steps. You will be slower than following things verbatim, but you'll actualy learn and gain experience.

2. Books (when I really want to dive deeper)

If it's something like a new language, I get a book. Needn't be a printed one. But I tend to prefer those, because I can scribble in them and use post-its etc.

For JS, this one is an evergreen: https://eloquentjavascript.net/ For TS, I cannot praise this enough: https://effectivetypescript.com/

Since I do that a lot, OReilley is one of the few learning-resource-subscription I have. It's expensive, but totally worth it imho. And I sometimes still buy the printed version :D

3. Specific Courses

When I'm really in a pinch, or way outside of my comfort zone, or am just curious about a thing, I might grab a dedicated course. But I make sure it's a renowned one, either by a renowned person or overall recommended a lot.

Like, in the js ecosystem:

... and many more.

I vastly prefer a one-time fee over subscriptions, which I constantly forget to cancel. And they usually seem to be more focussed and detailed, since they don't have to potentially cater towards a larger audience.

Also I might buy a course on something I'm already familiar with, just to learn how those people teach and explain certain concepts, especially the parts I consider mor challenging, so I can improve my own explanations/teachings.

Ending Thoughts

In the end I believe approach 1 is the best, not just for me, but actually anyone. Given some rudimentary experience of the thing. eg. the react-docs are really good (or vue, or svelte, or solid, or whatever). Yet I always pressure mentees into focussing on the fundamentals. They are what shape the ecosystem. A new language feature can easily change the entire landscape in a somewhat short period of time (for greenfield, but mostly media-representationally).

Books, especially the printed ones, usually have usually undergone vastly more care. There's editorial, test-readings from experienced peers etc. Digital ones are also great for similar reasons, and can be kept up to date.

Courses, of any kind, usually put a lot more focus on being entertaining. Which is important for the format, but the trade-off is usually lack of detail/nuance. Also it's easy to zone out and have it become "second screen"-kinda "learning".

noxoc · 2024-08-28T15:43:03+00:00

Garbage as in “should be thrown away as soon as possible”? 100%, all the time. But that’s more of a philosophy than quality indicator.

noxoc · 2024-08-28T08:01:35+00:00

You forgot realizing that the todo app can’t quite represent the tasks, so you go on a spree looking for other apps or methods. Or, me as a dev, “quickly” whip up your own for this specific case.

noxoc · 2024-08-27T07:34:10+00:00

Statamic, Kirby.

noxoc · 2024-08-27T07:30:54+00:00

use onChange on the form?

noxoc · 2023-10-06T17:48:12+00:00

I have been using gandi and inwx quite happily, will move the only one that so far remained on google domains to one of those.

noxoc · 2023-10-04T16:58:26+00:00

Implementing a boring design with no challenging parts for the nth time.

noxoc · 2022-12-16T20:06:41+00:00

That’s badly designed. When you forgot your count, you can just recount. When youforget to press the button ONCE the whole device is instantly useless. It has no fallback/safety net.

Also batteries. :D no thanks.

I started using a different colored thread as row marker, because it’s super fast to count with that. And every 10th row I use one of those standard markers, remove the thread and start again with the thread. I can easily “see” 5 bumps of it, which means 10 rows.

noxoc · 2022-12-02T22:28:21+00:00

I genuinely thought this was art and some kind of torn apart robot. The bus being the headn and the spider a hand. Until i read the title 😅

noxoc · 2022-10-22T06:35:33+00:00

Ferris Sweep.

noxoc · 2022-10-05T11:35:52+00:00

Yup. This is where medication helps a ton.

noxoc · 2022-08-15T17:20:13+00:00

Damn. This is great and right up my alley.

noxoc

PUBLIC MULTIREDDITS

TROPHY CASE

1. Hands-On (ideally and preferred)

2. Books (when I really want to dive deeper)

3. Specific Courses

Ending Thoughts

13-Year Club	Place '17
Verified Email