summaryrefslogtreecommitdiffstats
path: root/2021/talks/mold.md
diff options
context:
space:
mode:
Diffstat (limited to '2021/talks/mold.md')
-rw-r--r--2021/talks/mold.md56
1 files changed, 56 insertions, 0 deletions
diff --git a/2021/talks/mold.md b/2021/talks/mold.md
index 95e55e03..d01e3a3f 100644
--- a/2021/talks/mold.md
+++ b/2021/talks/mold.md
@@ -39,12 +39,68 @@ You can learn more about this at: <https://github.com/ag91/moldable-emacs>
IRC nick: `andrea
+Pad:
+
+- Q1: How to find a balance between «generic» molds that do not
+ provide specific enough info vs writing a new mold for every new
+ query/question?
+ - A: You can write molds that are private for your special
+ problem. I created molds for my work that I don\'t share: like
+ find the stories I am working on and how long time I spent on
+ tasks lately. Also, moldable-emacs is to make these tools easy
+ to write, so you should free to throw away tools when you need
+ them once only. If I believe a tool is a good start for many
+ other tools, I put them among the core molds, else if I use them
+ often I store them as contrib. If it is a one off, I throw it
+ away.
+- Q2: How would you evaluate this workflow for package managemnt in
+ large independent codebases. Can one integrate it with code sematic
+ analyzers to make for a better work flow?
+ - A: moldable-emacs is about creating custom tools you can apply
+ to your situation. I started experimenting with molding NPM json
+ packages + security data from OWASP to view/display security
+ issues in my packages to my colleagues in the past.
+ moldable-emacs gives me the infrastructure to answer my question
+ about security, and I now started asking myself about
+ architecture coherence, so I have scaled up tree-sitter over
+ projects to check that modules don\'t use packages from other
+ modules. By that I mean that as long as your code semantic
+ analyzers output data, you can mold that (context) data to tell
+ your story (answer the question you have). Does this answer your
+ question?
+ - You answered it very well. I am also a security auditor for
+ multiple development teams. And I am incharge of code analysis
+ in an understaffed security team. So your usecase example got my
+ usecase spot on. 
+ - Cool! For now you can define insecure patterns using tree-sitter
+ expressions (for example, I find a variable called \"password\"
+ in the code set to a string. For the package.json I linked to
+ OWASP API and looped through the packages using tree-sitter
+ tokens. I didn\'t get there, but I wanted to see an Org Mode
+ buffer with the list of the most vulnerable deps highlighted by
+ color + how to solve them: so I could pass them to developers to
+ resolve them (I am a dev, but sometimes others don\'t know about
+ security risks).
+ - Often molds are to tell stories to others.
+ - This is probably the most important thing for my personal
+ usecase. Thank you very much. Now it\'s my turn to learn it and
+ use it well. 
+ - Please open issues or email me, and I will try to help if you
+ like how it works :)
+ - I\'ll do so.
+
+IRC:
+
- cool...so essentially you are developing a text based version of Glamorous Toolkit.
- `andrea: yup, but only because I don't have good imaging in Emacs yet (but with tui.el...)
- your talk helped a lot with that though. I'd been seeing posts from you for a little while, but now I "get it"
- `andrea: yeah sorry, I am still building my vision: it may look I have been all over the place (image recognition, editing css, parse English lately), but the common thread is the easing of creation of micro tools that help me tell the stories I need
- I love your approach of mining other 'nuggets' from other contexts and bringing them to Emacs. I really look forward to looking in to your work and see if I can implement some of it. Thank you so much for your talk.
+Links:
+
+- Telling a story about code using buffer views <https://moldabledevelopment.com/>
+
# Outline
- 5-10 minutes: quick demo of moldable-emacs