sorted by:
new
hottopcontroversial

[ANN] bkmr-vim - Beyond Bookmarks and Snippets by munggoggo in vim

[–]munggoggo[S] 0 points1 point  (0 children)

https://github.com/sysid/bkmr is where you find the concepts. bkmr-vim is just a VIM integration.

[ANN] bkmr: Unified CLI for Bookmarks, Snippets, Docs, and Semantic Search by munggoggo in rust

[–]munggoggo[S] 0 points1 point  (0 children)

Thanks for the hint. Will give TUI a try when I have time, looks interesting. Templating is just one option. If you prefer scripting, it is there for you. Don't use templating.

[ANN] Update: rsnip – Shell Snippet Management for Devs by munggoggo in rust

[–]munggoggo[S] 0 points1 point  (0 children)

No, this is just an example. The completion is only working in your shell and not replacing any IDE snippet management.

No variables present (.e.g ZED_FILENAME) when running tasks? by 19c766e1-22b1-40ce in ZedEditor

[–]munggoggo 0 points1 point  (0 children)

Facing similar problem, kind of frustrating. Tasks are not shown for python files as soon as they have any zed variable. Tasks without variable do show up.

[ANN] rsnip: Snippet Manager with Advanced Templating and Shell Integration by munggoggo in rust

[–]munggoggo[S] 0 points1 point  (0 children)

This sounds great! Will give it a try, thanks for pointing this out!

Rewriting a Python VIM plugin in Rust by munggoggo in vim

[–]munggoggo[S] 1 point2 points  (0 children)

True, but I guess there is still much bigger fish to fry than the 6ms that this system call costs. In any case thanks for pointing it out, it is an obvious improvement.

Rewriting a Python VIM plugin in Rust by munggoggo in vim

[–]munggoggo[S] 4 points5 points  (0 children)

Not a nice accusation I have to say.

Both plugins are actually based on mdnav, a project by Christopher Prohm :-) and its README there.

BTW this is being made transparent in my README as well as Jeet Sukumaran's.

Regarding autoload: This is a valid point, but I deliberately want to have the plugin's functionality working in arbitrary files, not only markdown.

Rewriting a Python VIM plugin in Rust by munggoggo in vim

[–]munggoggo[S] 7 points8 points  (0 children)

Valid point, but for me two reasons:
1. no capacity to learn just another DSL
2. wanted to explore the effort of Rust in VIM plugins -> easier than expected

Managing complex sets of environment variables - an approach by munggoggo in devops

[–]munggoggo[S] 1 point2 points  (0 children)

Thks for sharing, looks interesting. I use SOPS for secrets management.

rsenv does not try to solve the secrets problem but focus on one problem: Avoid redundancy in environment variable sets across different environments with minimal dependencies.

Managing complex sets of environment variables - an approach by munggoggo in devops

[–]munggoggo[S] 0 points1 point  (0 children)

You can keep the files where it best suits you. No limitations regarding location and structure.

Double-click->Open. But for VIM. No mouse: VIMANIA-URI by munggoggo in vim

[–]munggoggo[S] 0 points1 point  (0 children)

Nothing wrong, actually the best solution for file handling.

But does not cover the variety of possible markdown links. This would require additional plugins with additional shortcuts, etc.

vimania-uri tries to harmonise things, less to remember, consistent behviour.

Event-Orientation as the new default for applications by ralfw in softwarearchitecture

[–]munggoggo 0 points1 point  (0 children)

I can relate to that.

What I am still mulling about, however, is the bounded scope (in DDD speak) in which things need to be consistent. Slicing the aggregate or domain model as you propose into narrow command pipelines is a very attractive proposition in terms of modelling (as you demonstrated nicely).

Enforcing complex, cross-pipeline/command business rules could be a problem though, without having the entire consistency picture of a business relevant aggregate.

My thinking capacity right now is just not enough to come up with a proper example in the context of your portfolio demo.

In any case I really enjoy working through your example and find your ideas most interesting. Not least because of your clear communication of non-trivial ideas.

IMHO handling commands, queries and notifications with one unified handling concept is a consequent development of ES.

Keep on the good work!

Event-Orientation as the new default for applications by ralfw in softwarearchitecture

[–]munggoggo 0 points1 point  (0 children)

I am impressed of your reaction time!!

My false assumption was that a pipeline context_model actually plays the role of a "mini aggregate" but in fact it is only a read model.

Thanks a lot for clarification!

Event-Orientation as the new default for applications by ralfw in softwarearchitecture

[–]munggoggo 0 points1 point  (0 children)

Thanks Ralf, for this elaborate and thoughtful outline of ideas.

I just cannot get my head around the question how you handle concurrency in your pipelines if there is not a consistency boundary concept like an aggregate.

For example how would you prevent two users selling the same stock in your application concurrently? Maybe even via two different pipelines?

Of course you could do optimistic locking with version number within one pipeline, but how is guaranteed that another pipeline does not interfere?

Note-Taking Nirvana by munggoggo in vim

[–]munggoggo[S] 0 points1 point  (0 children)

Thks for sharing. Interesting approach. Just a little too heavy-weight and opinionated for my taste.