jonrosner

Feel free to ask questions / give feedback right here in the comments.

I am thinking of distributing skills that I build to my clients. As my clients are mostly non-technical users I need this process of distribution to be as easy as possible. Even adding a .env file would probably be too much for most of them. With skills I can now finally distribute my logic easily, just send the raw files and tell them to put it into a folder - done. But there is no easy way for them to "setup" the credentials in those skills yet. The best UX in my opinion would be for Codex (or Claude, doesn't matter) to ask for those setup-parameters once when first using the skill and process the inputs in a secure manner, i.e. some internal secret storage

you could for example create a skill to access your database for testing purposes and pass in your tables specifications so that the agent can easily retrieve data for you on the fly.

one thing that I am missing from the specification is a way to inject specific variables into the skills. If I create let's say a postgres-skill, then I can either (1) provide the password on every skill execution or (2) hardcode the password into my script. To make this really useful there needs to be some kind of secret storage that the agent can read/write. This would also allow me as a programmer to sell the skills that I create more easily to customers.

after testing it for a little I am pretty disappointed. While I do get 90 token per second out of it from my M4 Pro which is more than enough for a real world use case, the quality is just not there. I gave it a codebase that it should analyze and answer me some questions and it started hallucinating right away. No replacement for a "real" coding agent - maybe for other agentic work like sorting emails though.

running it on my M4 @ 90tps, takes 18GB of RAM.

Self host Yaade. If you dont have a server run it locally in a Docker container.

Thats why I self host Yaade https://docs.yaade.io (shameless plug lol)

I can't reproduce this, even when forcing it not to reason:

"how many b's are in blueberry? don't think, answer fast."

blueberry • b → 1 (at position 1) • l → no • u → no • e → no • b → 2 (at position 5) • e → no • r → no • r → no • y → no

Total: 2 b’s.

Nice tool, congrats. Looks reasonable for the target audience. Is there a chord library for common songs? Or even sharing my chords with others?

No, I am from germany. Also good job on programming a game that plays flawlessly on pretty much all systems after so much time. Also, online play via IP address was super easy.

Wow thanks a lot! We played DD Poker during the Pandemic. It really saved us from going insane:)

E: just checked and they did update their pricing to be 3,50 now for the unlimited push. It's better, but still per-user-based. Which is still bad IMO. It says "Support Zulip's open-source development". I'd happily do that with a fixed price or an honest per-push price.

Great update. Unfortunately, the limitation of push notifications to 10 members puts it into the B- category of self-hosted OSS for me. I understand that costs do exist by providing a push service, but forcing Orgs into the same plan as everyone else kind of feels like it's an intentionally set boundary to lurk people in and then force them to go all-in. I'd much rather see another tier that only includes the cost for push notifications.

It's the same urge to abandon the current side-project and start a new one. It's normal, all Devs have it. Your brain always wants to do new fun stuff. You see a new shiny framework you want to use it. For me what took me out of this habit was to get rid of all the online-dev-community noise. Don't listen to any of the new trends, new frameworks, new architectures. They are just noise. And at the same time focus on why you started your side project in the first place: to solve real problems of real people. None of these people care what fancy tools you use or what architecture your backend is built with. What they care about is if you solve their problem. So focus on that. And if at some point your bad architecture from 5 years ago stops you from solving real problems, then change it. But from my experience the probability that no one will use your app in 5 years is way way higher than the probability that you have so many users that your architecture will actually matter.

Don't split your codebase. Just add some flags if it is self-hosted or not. Devs here will cry and tell you you can't do that and people can bypass it. Really don't listen to them. 99% of the people who purchase your SaaS instead of self-hosting do it because they don't want the hassle. The rest won't buy from you anyway. The biggest problem is getting SOMETHING out there. If you have success (which let's be honest most likely you won't), you'll have enough time building a better solution later. So keep it simple.

I've been using both codemirror and lezer in Yaade (https://github.com/EsperoTech/yaade). Thanks to lezer I was able to write a JSON extension language that supports Yaade environment variables. Pretty cool project and very nicely documented! I love building OSS on top of OSS.

Shameless plug: This is why I created Yaade. A self-hosted alternative to Postman and Insomnia. Unfortunately, being OSS is not enough anymore. The rug-pulls will keep happening. Remember: If you don't host it, you don't own it!

Check out Yaade on GitHub. Will be interested to hear what you guys think.

thanks for your comment. Environment for collections is definitely on the roadmap. Probably one of the first things I will implement next. How would you want a feature like this to look? Is having multiple collections with the same content but different environments OK or would you rather have one collection with multiple environments and you can switch them at the click of a button?

Haha thanks for your comment. May I ask where you are from? I am from germany and I thought you could just pronounce it like the gem Jade.

Thanks. I feel the same way. I hate not knowing which features will be behind a paywall.

Thanks for your reply! Looking forward to hearing your feedback. Yes things like this will be handled by the tool in the future. For now I want to gather as much feedback as possible to know which are the most wanted features / improvements. I have a roadmap in mind already and want to confirm if that is what other users want too!

Using Postman has become an essential part of my development workflow. Unfortunately I found that I was very limited by the local nature of Postman. I built Yaade to easily and securely share my API collections with my teammates. Alternatives like Hoppscotch may provide an awesome user interface but their self-hosting capabilities just lack far behind of what I need for actual production use.

Feel free to try it out and comment. Running Yaade just takes two docker commands! Your opinion is very welcome.