Welcome to Nasdanika

Table of Contents

· Overview
· Roadmap
∘ Beyond PicoCLI
∘ Beyond Diagrams
∘ Java Analysis
∘ Flow
∘ Function Flow
∘ Federated RAG
∘ Video courses from diagrams using Text-to-Speech
· Getting Involved

Overview

Nasdanika provides a suite of capabilities for (Java) Guerilla Innovators. All Nasdanika products are Java-based. So, if you know Java you may consume the capabilities at the API level. If you are not a Java person you may use Nasdanika CLI.

I use the term “Guerilla” in the sense of “achieving results in constrained environments with limited resources” as an antonym of a regular “army” with scrum masters, testers, DevOps, ...

For example, you work in a corporate environment and bringing in a new piece of software is a multi-month process which requires approval from the top-management. At the same time Maven Central is proxied by the organization’s binary repository and all you need to consume a module from Maven Central is adding a dependency to your pom.xml. So, find what you need on Maven Central! Another example is GitHub — you may not be able to download sources or binaries from the internet without an approval, but you might be able to use sources from GitHub.

And guess what, all Nasdanika products are on GitHub and many of them are published on Maven Central.

Nasdanika capabilities aim to reduce resource requirements for achieving a particular “mission”. In other words, to minimize the “loss function” of the “You-enterprise” by :

• Heightening the level of abstraction using modeling,
• Binding decisions at the optimal point in design/development process. E.g. not committing to a particular technology up-front.
• Leveraging visualizations such as diagrams as they have a shorter path from/to the brain than words,
• Automating and generating as much as possible,
• Providing “bite-size” components and models which are extensible and composable.

Take a look at the Enterprise Model for additional insights.

You may think of Nasdanika suite of capabilities as a grocery store — Core & HTML are isles with foundational components (salt, sugar, flour, …), models are more like frozen food, Nasdanika CLI is a deli/take-out — you don’t have to cook yourself, but you are limited in what you get. Practices and books are recipe books. All of them are “present tense”, although they may mention future possibilities. This Medium Nasdanika Publication is a place to share user experiences (recipes) and “future tense” — what might be.

Please note that as of the time of this writing most of Nasdanika components are “lightly documented” — I’m a guerilla innovator myself working on Nasdanika capabilities during my personal time — early mornings, late evenings, weekends and vacations — including writing of this story.

Roadmap

This section outlines what I plan to publish in the (near) future. Near being 2024, hopefully.

Beyond PicoCLI

Recently I’ve revived a CLI module based on PicoCLI. The module extends PicoCLI functionality by adding:

• Bottom-up composition of a command hierarchy a mix-ins — a child command defines its parent command (path) and a mix-in may define where to mix it it
• Command and mix-in polymorphism — a sub-command or mix-in may override (replace) a sub-command/mix-in with the same name in the parent command
• Generation of HTML documentation
• Generation of distributions which support modular Java applications

This future story will delve into the above capabilities and provide links to reference documentation.

Beyond Diagrams

I’m a huge fan of diagrams, so huge that I even wrote a book on the subject. However I’m not a fan of pixel-deep diagrams which are glorified images and need a human or accompanying write-up to make sense of them. I’m a fan of semantic diagrams.

In my opinion diagrams are the ultimate communication medium — they predate writing, human brain comprehends diagrams much faster than words. As a matter of fact, humans have to produce diagrams in their minds or on paper/whiteboard to comprehend complex concepts and communicate those concepts to others and self.

With AI advances in its ability to comprehend text and images, diagramming might be something where we, humans, can hold the fort for some time until there is a large body of (semantic) diagrams to train AI on.

AI is good at working with text and images. Diagrams, however, are neither text nor images (in the way AI works with images — convolutional neural networks).

With the introduction of Nasdanika CLI it should become much easier to generate documentation from mapped diagrams.

This story will be a companion to the book — it will provide a high-level explanation, simple use cases, and links to demos.

Java Analysis

There is already a Java model which can be loaded from source files. I’m planning to extend it with ability to load from bytecode using ASM — I have an almost decade-old code from my past experiments and I hope I will be able to modernize it and create a model loader/enricher.

Once it is done, I’m planning to adapt Ecore documentation generator, which generates model documentation (example), to generate Java documentation with dependency graphs (module, package, class, method, field), sequence diagrams and possibly other visualizations.

Some interesting opportunities:

• Use GenAI to create descriptions and recommendation by looking at source code and add it to the generated documentation.
• Generate text from Java models (e.g. “field firstName is read by getFirstName method and modified by setFirstName method”) and feed descriptions to GenAI as prompts or fine-tuning.

The two usages may be combined — generate a long description, feed it to GenAI along with source code and ask to summarize.

One of use cases for such analysis is helping to understand legacy codebases to assist in modernization efforts. Another is speed-up on-boarding of new team members or users.

Once all of it is done, I’m planning to publish a story outlining what is available and how it might be used.

Flow

I’ve been experimenting with documenting processes for many years — in my opinion ability to capture how you do something and be able to optimize, automate, and delegate individual activities can provide a great productivity boost for guerilla innovators as well as small business owners.

The Flow model is the latest installment. Currently it is too complex to my taste. I plan to simplify it by extending the Graph model, document how to map Drawio diagrams to the model, update the Beyond Diagrams book with detailed documentation and publish a story here with a high-level overview.

One promising aspect of flow/process engineering is flow polymorphism — ability to “override” and suppress activities (elements) of super-flows in sub-flows (not to be mistaken with nested/child flows). This is similar to inheritance in Object-Oriented languages like Java and to building container images — files from the base image can be modified or deleted and new files can be added. When applied to flows (processes) it would allow to define generic flows/processes and then adjust them to specific situations.

Function Flow

The Flow model mentioned above is not executable. Function Flow model is executable. Currently there is basic synchronous executability. I’m planning to solidify the generation, combine with generation of Java sources leveraging the Java model and possibly GenAI, and eventually add support of asynchronous execution using Reactive Streams. Nasdanika CLI will feature commands to execute flows defined in Drawio diagrams as well as generate documentation from the same diagrams. One form of execution would be “serving” — a diagram is loaded to memory and executed on HTTP requests.

As with the other ideas — once it is done, I’ll publish a story outlining the approach with links to reference documentation.

Federated RAG

Most of the above generates HTML documentation sites using the HTML Application Model. The generated HTML has a unified structure across sites which makes it easy to extract content text. Also, text can be extracted as part of generation process without having to parse generated HTML. Extracted text can be used to produce embeddings which would be stored as loose files along with HTML files. There would be, say, embeddings.json similar to sitemap.xml at the site root.

It would allow to create embedding indices from collections of sites of interest and build a RAG solutions on top of such site groups. The RAG may be location-aware — in addition to embedding similarity it may take “hop /graph distance” into account when selecting chunks for a GenAI prompt.

Nasdanika CLI would provide commands to build embedding indices and HTTP server commands to execute semantic search and summarization.

Combined with, say, Java analysis, it would allow to “chat” with specific codebases. For example, your project and its dependencies.

Combined with documentation generated from CLI (example) it would allow to chat with CLI tools. Imagine that you have a CLI tools which features dozens of commands. Wouldn’t it be nice to be able to ask “How do I …” and get an answer?

The concept might be extended to PDF’s leveraging the PDF model and online PDF viewer components — take a body of PDF’s, generate sites with viewers (e.g. using PDF.js), do the same as with the other sites, possibly with text highlighting.

There are also other models, say, Excel.

One interesting aspect of this RAG approach would be ability to chat with diagrams in two modalities:

• A site can be generated from a diagram
• For a diagram on a site page hidden text (aria) can be generated from diagram elements — this text will be “visible” to RAG, but not to humans. For example, the following description can be generated from the diagram of the Internet Banking System C4 model: “Personal Banking Customer (named entity) views account balances, and makes payments using the Internet Banking System (named entity). …”

I’m also thinking about creating a RAG solution on top of the Source Engineering Model. RAG deals with chunks of texts. Ranges are pieces of text which can be used as chunks or combined into chunks. A range is identified by resource URI and start/end fragments within the resource. This provides a unified approach for index stores — embedding -> 2 URI’s.

Currently the Java model extends the Source Engineering Model. It is very easy to add range support to the PDF model. I’m also thinking about introducing a YAML model on top of SnakeYAML and MarkedLinkedHashMap and MarkedArrayList.

Video courses from diagrams using Text-to-Speech

Videos are a great communication vehicle! However, narration is a skill which I don’t shine at. So, this is what I’ve been doing for quite some time:

• Create an outline of what you want to communicate as a mind-map
• Add scripts (what needs to be said)
• Use text-to-speech to generate voice. Recently I’ve been using Speechelo, but I also have a generator which uses Google Text-to-Speech somewhere in the depths of GitHub. Speechelo might be better for smaller projects and batch generation for large endeavors.
• Record video(s) (I use Camtasia)
• Cleanup videos, add generated voice, annotations, transitions, etc.
• Generate and publish videos and a site containing videos and scripts — if people prefer to read.

Once the flow model is ready and I have tons of time on my hands I might document the video creation process in a flow model and publish an overview story here.

Getting Involved

If you like Nasdanika capabilities and want to help to evolve them then this is what you might do:

• Share your experience in using them in this publication.
• Build demos.
• Build extensions — CLI commands, models, etc. and publish them on Maven Central or GitHub to help others. For example, implementations for Function Flow models.
• Contribute unit tests and bug fixes via fork/pull request. No promises that your pull request would be accepted, though, sorry!

At this point I don’t have capacity to accept contributions to the “core” codebase except unit tests and bug fixes.

However, there is a number of models and ideas craving for TLC. E.g. Decision Analysis. If you want to help, drop me a line and will figure out how to collaborate!