nikolasdimi

joined 3 weeks ago
 

hey there,

There is always a temptation to add "something AI" in new tools. Especially to tools that are somehow related to developer productivity.

At the same time I wanted to avoid this temptation with Voiden. So there is currently nothing screaming "AI" in it even though I can potentially see many many use cases.

This is also one of the main reasons I think that a plugin architecture is best. What was actually in my mind is that not adding AI is ok for now and the community will start coming up and building AI plugins. For example creating docs from specs and vice versa.

Any other use cases you can think that could be applicable to a tool like this? (Dev Tool with executable markdown files for API specs, tests and docs). The first plugins we shipped were more around methods (grpc, graph ql, web sockets etc etc).

repo: https://github.com/VoidenHQ/feedback

[–] nikolasdimi@lemmy.world 2 points 4 days ago

so there could be an option "select a texan taxi driver" irrespective of where you are in the world

[–] nikolasdimi@lemmy.world 1 points 4 days ago

yap...thats the thing...you never know...the interesting conversations can only happen only when we are open and ready to accept also the banal ones :)

[–] nikolasdimi@lemmy.world -3 points 4 days ago (3 children)

thats super sad....I dont have a problem with someone not wanting chit chat but isnt better to just say "hey, today I am not in much mood to talk" or to show it and to make it happen without explicitly selecting it in an app.....

its just very black mirror esque

[–] nikolasdimi@lemmy.world 1 points 5 days ago

you can keep an eyes on our github issues cause these languages will come soon!

[–] nikolasdimi@lemmy.world 1 points 5 days ago

thats true right? we are also coming from the same boat.

btw now we are adding shell script as well...different devs need different capabilities.

so did you try Voiden? anything interesting or any feedback to share ?

[–] nikolasdimi@lemmy.world 1 points 6 days ago

we are indeed looking at the docs again. To begin with we focused on the tool itself so some of the examples that you see can indeed be worth revisiting and re writing. :) But I hope you can focus and zoom in to the tool itself and see how this can help you with your API workflows.

[–] nikolasdimi@lemmy.world 2 points 6 days ago

thanks for sharing!

[–] nikolasdimi@lemmy.world 2 points 6 days ago (3 children)

cool - what would then be on the very top of what you would like to use? :)

 

Note - This post is intended to look for feedback in a tool that solves a problem we have been seeing (around API clients not supporting Python) - and hopefully help Python folks (like it helped us when building it).

So, a bit of a backstory - Something I noticed while we were building our internal tool for API testing: A lot of developer tools assume JavaScript scripting by default. API clients are a good example of this.

scripting = JavaScript

And yes it might not be always a huge problem, but it adds constant friction.

Eventually we realized the real issue was not just JavaScript. The issue was and is that many tools force a single language.

So when we started building our own API client (link below), we decided to approach scripting differently: Pre-request and post-request scripts support multiple languages and runs on real interpreters, not a limited sandbox like most Clients do.

So we built this to support Python and JS from day 1 and now releasing shell script + more coming (perhaps Go would be the next??)

The idea is simple: Your API tool should adapt to your stack, not the other way around.

Some developers think in JS, some in Python, some in Go or Rust.

The tool shouldn’t care.

Q: Would you actually use Python for request automation inside an API client, or do you prefer handling that logic outside the tool?

Repo: https://github.com/VoidenHQ/voiden

[–] nikolasdimi@lemmy.world 4 points 1 week ago

True. Background of the story of how I learnt is in my tai chi class where I asked the teacher if they also do king fu there. And they told me that well tai chi is also part of kung fu.

[–] nikolasdimi@lemmy.world 2 points 1 week ago

I have added the link! It's free to watch

[–] nikolasdimi@lemmy.world 1 points 1 week ago

wow wow thanks! please spread the word!

 

has anyone seen this masterpiece?

[–] nikolasdimi@lemmy.world 2 points 1 week ago

yes in Voiden everything is a block though.

 
7
Heavenly - Atta girl (www.youtube.com)
submitted 1 week ago* (last edited 1 week ago) by nikolasdimi@lemmy.world to c/90smusic@lemmy.world
 

fuck you, no way!

 

this my take on a matisse painting, that you can find here.

https://www.clickatlife.gr/fu/p/228858/1200/10000/00000000005fd2d3/1/matisse.jpg

I thought of an idea: take your pencil and make your version this :) will be funny to see how different people translate this.

 

One of the things I discovered (or better said, something I suspected but had the chance to verify) while working on open-sourcing a tool (and API client tool): there is a big (mostly justified) trust deficiency out there .

I could feel it immediately in every discussion: always that little question in the back of people’s minds:

"Will this project "stay true", or will it change the rules on me later?"

We have seen this pattern repeatedly: Terraform > OpenTofu, Redis > Valkey, Elastic > OpenSearch....

I understand this: it’s becoming hard not to become a little cynical. In some ways, SaaS starts to feel better only because its more honest and at least the incentives and motivations are explicit from day one.

But why does this happen?

One answer is simple: bad intentions, that yeah, they do exist some times. But then this might be an oversimplification.

One aspect that is not often talked about: Many of the most durable open-source tools and frameworks (VS Code, React, Kubernetes, and Backstage among others) were built by companies where the tool itself was NOT the primary revenue engine. Their core business lived elsewhere.

This means that these tools could function as ecosystem infrastructure rather than direct monetization vehicles. They could stay open because they weren’t carrying payroll, sales targets, and investor expectations on their own.

In contrast, when an open-source project becomes the business, the incentives start to shift. The tool now has to "fund" teams, meet SLAs, satisfy investors, and deliver predictable growth.

Over time, that pressure often leads to open-core models, licensing changes, community forks, and growing tension between "community" and "enterprise."

So yeah, the intentions might have not been alway bad....but the economics have spoken...

The "open source first, monetize later" strategy feels super risky.

Once adoption takes off and the tool becomes central to a company’s survival, teams are forced into trade-offs that often erode trust and fragment communities.

My opinion is that Open Source thrives most easily when it IS NOT carrying the full weight of corporate survival.

When it is, preserving its original spirit becomes much harder.

If we want healthier developer ecosystems, we need to be more honest from the start. This means to either build an open-source project as genuine long-term infrastructure and commit to keeping it open, or build a commercial product with a clear monetization model from day one.

Both paths are valid. Trying to blur the two is what repeatedly leads to broken trust (with developers), frustrated contributors, and fragmented communities.

The takeaway? I guess it is that we just need to be upfront:

If your project is commercial lets be upfront. If it’s truly open, lets commit to it.

Anything in between makes people hesitate to believe and that’s how communities start to fracture.

what do you think? what makes you trust an open-source project long term, and what are the red flags that make you cautious?

454
Modern API tools (lemmy.world)
submitted 2 weeks ago* (last edited 1 week ago) by nikolasdimi@lemmy.world to c/programmer_humor@programming.dev
 

this is the first meme I have ever made (yes I am that old) - so be gentle :)

what does being modern mean to you?

 

what does modern mean to you?

44
submitted 2 weeks ago* (last edited 2 weeks ago) by nikolasdimi@lemmy.world to c/bmoviebonanza@lemmy.world
 

has anyone seen a worse haircut than Ator's in this film?

Full movie: https://www.youtube.com/watch?v=6wRznqH9IbA&t=254s

view more: next ›