A Markdown preview has a narrow job: turn the active text file into readable HTML. I wanted that job to stay local and avoid analytics or remote rendering services.
I built Lightweight Markdown Preview as a small VS Code extension that renders Markdown in a webview. It includes Mermaid diagrams and MathJax equations. This post explains the data flow and the deliberate limits behind the small package.
Time logs can contain client names, project details, and working patterns. A cloud-based tracker stores some of that information on someone else's infrastructure and may require an account or network connection.
I built TimeTrackly as a local-first alternative for developers, freelancers, and makers. It stores time entries as JSON files on the user's machine and works without a cloud service. This post explains that storage model, its privacy benefits, and the backup responsibility that comes with it.
Charts can show what changed without explaining why the change matters or what to investigate next. I have seen that gap slow conversations between data teams and business teams.
I built Data Story AI to test one workflow: turn a plain-language question into a DuckDB query, a chart, and a written summary. This post explains the architecture and its safeguards. The generated story is a starting point for analysis, not an automatic business decision.
Mermaid stores a diagram as text inside Markdown. That works well for versioned documentation, but a diagram embedded in a long page can be too small for a meeting. Exporting screenshots adds another file that can drift from the source.
I created Mermaid-Slides.com to turn Mermaid blocks from a Markdown file into a browser-based slide deck. This post explains the local rendering pipeline, navigation controls, and privacy boundary without requiring a separate slide configuration.
Large language models (LLMs) generate text; they should not be trusted to calculate an exact file digest from memory. A digest is the fixed-length value produced by a hash function for a specific input.
I built the Hashing MCP Server so an AI assistant can delegate that calculation to Python code through Model Context Protocol (MCP). This post shows how the tool exposes MD5 and SHA-256 operations, how a client calls them, and why MD5 is useful for compatibility checks but not for security-sensitive integrity guarantees.
A large language model (LLM) can only respond to information available in its current input or learned during training. Giving it controlled access to files, databases, or software tools usually requires integration code for each host and service.
Model Context Protocol (MCP) defines a common way for an AI application to discover and call those resources. This post explains the client-server roles, the messages they exchange, and where MCP fits into a tool-using application. MCP standardizes the connection; it does not make a tool safe or an answer correct by itself.
A data model defines what information a system stores, how records relate, and which rules the data must follow. Those choices affect queries, validation, and the cost of adding a new use case later.
This guide compares four approaches: relational, graph, semantic, and document-oriented modeling. It explains the structure each approach favors, the questions it answers well, and the trade-offs to consider before choosing one.
An AI agent combines a language model with software that can choose tools, act on their results, and continue through several steps. Products such as OpenAI's Operator and Claude's Computer Use illustrate parts of this pattern.
I built an interactive chatbot to make the control loop visible. It can retrieve document context, call web APIs, and create GitHub issues. This post explains tool calling, how the loop decides what to do next, and why permissions and stopping conditions matter.
An AI governance program has to connect legal duties with the data and model controls that teams can actually operate. At a Data Leaders meetup in Munich, I presented research on the General Data Protection Regulation (GDPR) and the European Union Artificial Intelligence Act (EU AI Act).
This post turns that research into a practical lifecycle: trace data sources, classify risk, test data quality and bias, document validation, and monitor the deployed system. It is an engineering overview, not legal advice.
The European Union Artificial Intelligence Act (EU AI Act) regulates an AI system according to its use and risk, rather than applying one rule to every model. It entered into force on 1 August 2024, and its obligations apply in phases.
This post explains the main risk groups, the roles of providers and deployers, and the engineering controls required for high-risk systems. It also reflects the timeline in force on 7 August 2026, including the extended high-risk deadlines introduced by the AI Omnibus.