dancablam

Runme is great. One thing I required was mobile support which I didn't see in Runme. I also thought the VS Code dependency was a bit heavy for me since I otherwise don't use VS Code.

- env vars parametrization: this is an issue I've hit myself and am looking to add a solution for it. Created an issue for it: https://github.com/ledgesh/ledge/issues/9

- CLI: Ledge does have a CLI. One gap is it can't run a code block from the CLI - another good item to add. Created as an issue: https://github.com/ledgesh/ledge/issues/10

- flags: you can add flags in the codeblock in Ledge (like confirm, norun, etc)

Thanks for the great input!

You described my exact use case :) Great idea about hooks. Something I'll look into for sure.

And, dang - sorry it's laggy for you! I've created a GH issue that includes some things for you to try and I'll work through them myself too: https://github.com/ledgesh/ledge/issues/8

Glad you like it! You're welcome :)

Yes you can use profiles to store credentials outside of the notes themselves :)

I think it's mainly an issue of preference. Markdown is common these days and already exists in READMEs etc. I know it so I tend to prefer it. I also require the ability to access my notes from my phone and that's more of a challenge with org-babel.

Awesome feedback! For code in the markdown it's just simple blocks like ```sh, ```python, etc. So your README example should mostly work. Regarding flows / conditionals - Right now it's up to the user to look at the response and determine what's next. But I do hit this problem myself - based on a response my workflow may branch off into an entirely different direction. Like you said, I'll have to decide the philosophy about how to approach something like this but it is a real challenge.

Ledge doesn't remove the need to write scripts / automations. But for things like complex deploy pipelines there are still many manual / human steps in between. So I use Ledge to run my automation scripts, do some manual checks, based on those run more automations, etc.

Thanks! I'm looking for ways to extend Ledge further. Math / Science capabilities could be cool (although I'll probably need a contributor that knows those needs to help out)

For what it's worth, Ledge has no AI built in. It's BYOAI for those that want it.

ha. Fair point. I'll work to soften it a bit. Not meaning to imply "first and only"

Hey really appreciate that context! My thoughts:

1. Ledge's bet is it shouldn't feel like authoring at all. I've always had markdown docs chock full of commands and docs so making them runnable was the next logical step for me.

2. True. Keeping any kind of documentation up to date is difficult

3. Also true. I'm hoping Ledge's built-in agent support will bridge that gap and allow agents to help keep the docs up-to-date

And yes, a "Team" notebook is a challenge. Technically anyone with SSH access can all share a Ledge notebook. But that probably doesn't get us all the way there.

Thanks again for providing your thoughts. This by no means is a solved problem but I'm interested to see where it goes!

Woah. I have no affiliation with Atuin so a coincidence I'm sure but really weird.

Great to hear! Hope it works well for you. Let me know if you hit any snags!

Ctrl-R, fzf and tab completion work in the terminal drawer. But completion in the editor doesn't exist currently. Really good idea, however so let me look into it!

Awesome! Let me know how it goes.

Hey thanks! This gives me the motivation to keep on evolving this project :)

Good feedback. Perhaps "Runnable markdown notes" instead of "The notebook that runs code".

Good question. Main differences of Ledge: You don't need Emacs for those of us that don't use it already. Markdown instead of Org syntax. Shells are interactive by default. Mobile apps can run the shell/code.

Nice! I'll take a look.

Jupyter is great. From what I recall it's bash kernel isn't a real terminal session so sudo prompts, top, etc can tend to get a bit wonky. I also have a preference towards Markdown over .ipynb.

We do in fact support SMTP - we'll work to make that more prominent. And I understand your take on the subscription model - we're chewing on some pay-for-use models.

In my experience everyone appreciates lower prices - and good senders should be rewarded with lower prices.

If you allow spammers on your network things get a lot more expensive. So you can't offer low prices and allow low-quality senders. That's why we have a strict AUP and aggressive measures to detect spammers, phishers, and non-permission (aka cold-outreach) messages.

Hey thanks!

Most do have email industry expertise. But for whatever reason email infrastructure expertise seems to be a dying breed with most providers pushing their infrastructure into major cloud providers. It has its benefits, but its costs too - and those get passed on to you. Our background has been in email infrastructure (managing it ourselves instead of paying a 3rd party to do it and sticking you with the bill).

Glad you got it! I'll send you a personal email from me so you can reach out if you have any more issues.

We saw your sign up! Looks like your domain has greylisting enabled. Nothing we can do but obey that limit. You should get it if you try again or wait for our retry: Message was greylisted, try again in 1 minute 50 seconds

Fair question. Here are a few reasons:

- Pricing wins against pretty much any provider (and is an order of magnitude lower than many incumbents). - Especially when compared to SES, we're a dev-friendly, fully modern sending platform and we don't require you to glue a bunch of services together. - We're self funded from previous acquisitions in the space. We're focused on good customer outcomes instead of investor outcomes. - We have a pretty cool templating platform that allows you to write simple markdown instead of convoluted email-compatible HTML.

Agreed. Our team's background is in deliverability. Our last startup was a deliverability company founded in 2014, grew to ~20,000 paying customers, and sold in 2020 so we know the space very well and have built Anypost around those best practices. Also happy to provide guidance to anyone who needs help with it. I can go into any specifics if interested.

It uses MJML under the hood to ensure email-safe HTML is generated. That should prevent many edge cases where failures can happen - but I'm sure there are some skeletons we'll have to find / fix.

Added support for cloudflare workers in 0.1.2. Thanks for the tip!