[{"data":1,"prerenderedAt":149},["ShallowReactive",2],{"all-articles":3},[4,24,49,69,89,105,118,135],{"slug":5,"title":6,"description":7,"body":8,"category":9,"sources":10,"date":14,"tags":15,"language":20,"draft":21,"project":22,"path":23},"building-small-tools-to-test-an-idea","Building small tools to test an idea","A carousel-maker experiment, and what a small working tool can teach before it becomes a larger project.","\nI posted an Instagram carousel maker and asked whether I should open-source it. That public update describes an experiment, not a released product or a measured result.\n\nThe useful idea behind it is broader: a small tool can make a product question concrete.\n\n## Build around one piece of work\n\nA carousel has a simple job. It turns a sequence of points into a set of readable slides.\n\nA focused prototype can ask whether the same spacing, type hierarchy and layout rules are useful across several slides. It can also reveal where a template stops helping: a long title, a code example or an image with an awkward crop.\n\nThose are clearer questions than whether a general-purpose design tool should have another feature.\n\n## Make the output easy to react to\n\nA description asks someone to imagine an interaction. A working output gives them something to inspect.\n\nFor a carousel maker, that output could be a short sequence of slides. Feedback can then become specific: the heading is too small, a slide needs fewer words, or the export does not fit the platform.\n\nThe prototype does not need to solve every case to reveal the next constraint.\n\n## Keep the experiment’s status visible\n\nShowing something in public creates expectations. A clear label helps distinguish a prototype, an open-source package and a product that someone can use today.\n\nThe question in my post was whether to open-source the experiment. It should not be read as a claim that the tool has already been released.\n\nThat distinction lets the work stay exploratory while still making it useful to discuss.\n\n## Let an idea earn its next step\n\nA useful next step might be a smaller scope, another iteration or simply a note about what did not work.\n\nThe larger projects in my workshop, such as [Nuxt Charts](\u002Fprojects\u002Fnuxt-charts), also started with a specific problem. A prototype provides a way to understand that problem before committing to a much larger system.\n\nSee [small experiments](\u002Fprojects\u002Fsmall-experiments) for the place these ideas occupy alongside the bigger projects.\n","Building products",[11],{"label":12,"url":13},"My carousel-maker experiment on X","https:\u002F\u002Fx.com\u002FDennisAdriaans\u002Fstatus\u002F2091175741769531766","2026-10-12",[16,17,18,19],"side projects","prototypes","carousels","product development","en",false,"small-experiments","\u002Fblog\u002Fbuilding-small-tools-to-test-an-idea",{"slug":25,"title":26,"description":27,"body":28,"category":29,"sources":30,"date":14,"tags":40,"language":20,"draft":21,"project":47,"path":48},"chart-design-across-vue-nuxt-and-angular","Chart design across Vue, Nuxt and Angular","What can stay consistent when chart components move between frontend frameworks, and what needs to fit each ecosystem.","\nI shared an update about bringing the charting work to Angular, powered by Unovis. Alongside Nuxt Charts and vue-chrts, that work raises a useful design question: which parts of a chart belong to the framework, and which belong to the data?\n\nThis article develops that question from the public update.\n\n## The reader’s task stays familiar\n\nWhether the application is written in Vue, Nuxt or Angular, a chart’s reader still needs to understand a trend, compare categories or inspect a proportion.\n\nThe same questions are worth asking in each implementation. Are the labels clear? Are the units visible? Is a comparison meaningful? Can the chart fit the space available?\n\nThe framework does not answer those design questions.\n\n## The component API should fit the framework\n\nThe way a developer passes data, reacts to changes and configures a component does depend on the framework.\n\nTrying to make every wrapper look identical can create an API that feels unfamiliar everywhere. A better boundary keeps the visualization concepts consistent while letting each integration use its ecosystem’s conventions.\n\nFor a bar chart, the common ideas might be a dataset, categories, labels and formatting. The component’s inputs and update behavior should still feel natural in its application.\n\n## Shared foundations reduce duplicated work\n\nUnovis is the visualization foundation used in the chart projects. A shared foundation gives the work a common place to build from.\n\nThat does not make each package interchangeable. Integrations still have their own setup, documentation and compatibility considerations.\n\nThe repository is the right place to verify what a particular package currently supports.\n\n## Choose the level of abstraction you need\n\nA finished chart component helps when a familiar chart type is enough. Lower-level primitives help when the visualization itself is unusual.\n\nThat is part of the distinction between the component work in vue-chrts and the exploration in visx-vue. Both can be useful, but they leave different amounts of work to the developer.\n\nYou can find the packages on [the open-source charts project page](\u002Fprojects\u002Fopen-source-charts). For the Nuxt-focused experience, start with [Nuxt Charts](\u002Fprojects\u002Fnuxt-charts).\n","Nuxt & Vue",[31,34,37],{"label":32,"url":33},"My Angular chart announcement on X","https:\u002F\u002Fx.com\u002FDennisAdriaans\u002Fstatus\u002F2018720917036114092",{"label":35,"url":36},"vue-chrts repository","https:\u002F\u002Fgithub.com\u002Fdennisadriaans\u002Fvue-chrts",{"label":38,"url":39},"angular-chrts repository","https:\u002F\u002Fgithub.com\u002Fdennisadriaans\u002Fangular-chrts",[41,42,43,44,45,46],"Vue","Nuxt","Angular","Unovis","charts","open source","open-source-charts","\u002Fblog\u002Fchart-design-across-vue-nuxt-and-angular",{"slug":50,"title":51,"description":52,"body":53,"category":54,"sources":55,"date":14,"tags":62,"language":20,"draft":21,"project":63,"path":68},"cloudconfig-a-backend-for-frontend-developers","cloudconfig: a backend for frontend developers","The idea behind Dennis Adriaansen’s cloudconfig project: keep models, validation, access rules and deployment connected.","\nIn a public post, I described a simple backend layer on Cloudflare, inspired by the ease of getting started with tools such as PocketBase and Supabase.\n\nThat is the direction behind cloudconfig. It is a beta project, currently built for Cloudflare. This article expands on the idea behind the post and the current project structure.\n\n## The repeated work is the problem\n\nA small application can need the same field described in several places: the database, validation, an API response, a form and a client type.\n\nSuppose a project record has a title and a published flag. When the title becomes required, the database and request validator need to agree. When only published records are public, the API needs an explicit rule.\n\nThe repetition makes even a modest backend harder to follow than it needs to be.\n\n## Let one model definition carry the shared contract\n\ncloudconfig uses a TypeScript backend definition to connect model declarations to migrations, validated routes, access rules and a typed client.\n\nThe goal is to keep those pieces aligned. It is still the developer’s job to decide what a model means and which operations the application should permit.\n\nA generated API is most useful when the rules behind it remain readable.\n\n## The frontend and an agent use the same boundary\n\nA dashboard might ask to update a record. A coding or application agent might propose the same update. Both requests should pass through the application’s server-side validation and permissions.\n\nA helpful interface can explain the proposed operation before execution. The backend must still reject an operation the caller is not allowed to perform.\n\nThat keeps the model’s business rules independent of the interface that happens to send the request.\n\n## Start with an actual deployment target\n\nCloudflare is cloudconfig’s current platform. Its services shape the present database and deployment integration.\n\nSupporting other clouds well means examining database behavior, storage, background work and runtime assumptions. I treat that as infrastructure work that needs explicit adapters and verification, rather than a setting that can make platforms equivalent by itself.\n\nFor current setup details, use [the cloudconfig docs](https:\u002F\u002Fcloudconfig.dev\u002Fdocs). The [project page](\u002Fprojects\u002Fcloudconfig) gives a concise overview of the work.\n","Backend & agents",[56,59],{"label":57,"url":58},"My public cloudconfig post on X","https:\u002F\u002Fx.com\u002FDennisAdriaans\u002Fstatus\u002F2106081787013193818",{"label":60,"url":61},"cloudconfig documentation","https:\u002F\u002Fcloudconfig.dev\u002Fdocs",[63,64,65,66,67],"cloudconfig","Cloudflare","TypeScript","backend","access rules","\u002Fblog\u002Fcloudconfig-a-backend-for-frontend-developers",{"slug":70,"title":71,"description":72,"body":73,"category":74,"sources":75,"date":14,"tags":82,"language":20,"draft":21,"project":87,"path":88},"from-nuxt-charts-to-a-complete-dashboard","From Nuxt Charts to a complete dashboard","Expanding a public Nuxt UI dashboard update into the design decisions around charts, context and useful interfaces.","\nI shared a work-in-progress dashboard using Nuxt UI and Nuxt Charts on X. A short update can show the interface; a longer article has room to explain the decisions around it.\n\nThis is an expansion of that dashboard theme, rather than a transcript of the post.\n\n## Start with the question a screen answers\n\nA dashboard should help someone understand a situation or choose a next step. Before deciding how many cards it needs, decide what its reader is trying to find out.\n\nFor example, a team looking at background jobs may want to know whether work is building up. Queue depth, processing time and failed jobs answer different parts of that question.\n\nThree attractive charts can still leave the question unanswered if each uses a different time window or leaves its units unclear.\n\n## A chart needs its neighbors\n\nA chart title should say what is being measured. The surrounding copy should provide the time window and comparison. A nearby action should relate to what the reader has learned.\n\nThe visual hierarchy can then stay quiet:\n\n1. State the main question or status.\n2. Show the evidence in a chart or table.\n3. Explain the relevant change.\n4. Offer a sensible next step.\n\nFor a job dashboard, that might mean a backlog trend, the oldest waiting job and a link to inspect the queue.\n\n## Reusable blocks carry the relationship\n\nA chart component is one reusable piece. A block can preserve the relationship between a heading, a value, a chart, a legend and a small explanation.\n\nTemplates take that one level further by arranging those pieces across a screen. The developer can then adapt the data and behavior rather than reworking the same layout decisions each time.\n\nThat is why [Nuxt Charts](\u002Fprojects\u002Fnuxt-charts) includes more than individual chart components.\n\n## A demo is a starting point\n\nA polished screenshot shows one state. A real product also needs loading, empty and error states, along with sensible behavior on smaller screens.\n\nThose states belong to the interface’s design. They determine whether someone can understand what is happening when the perfect sample data is gone.\n\nMy focus is to make a good starting point that developers can turn into the dashboard their application actually needs.\n","Design & dashboards",[76,79],{"label":77,"url":78},"My Nuxt UI \u002F Nuxt Charts dashboard update on X","https:\u002F\u002Fx.com\u002FDennisAdriaans\u002Fstatus\u002F2054139267899678987",{"label":80,"url":81},"Nuxt Charts — blocks and templates","https:\u002F\u002Fnuxtcharts.com",[83,84,85,86],"Nuxt UI","Nuxt Charts","dashboards","interface design","nuxt-charts","\u002Fblog\u002Ffrom-nuxt-charts-to-a-complete-dashboard",{"slug":90,"title":91,"description":92,"body":93,"category":94,"sources":95,"date":14,"updated":14,"tags":96,"language":102,"draft":21,"project":103,"path":104},"je-bedrijf-koppelen-aan-chatgpt","Je bedrijfsinformatie koppelen aan AI: context, zoeken en toegang","Hoe je bedrijfsinformatie bruikbaar maakt voor een AI-assistent, met aandacht voor bronnen, actualiteit en toegangsregels.","\nEen algemene AI-assistent kent de details van je bedrijf niet vanzelf. Denk aan productinformatie, interne werkinstructies of documentatie die regelmatig verandert.\n\nJe kunt zulke informatie tijdens een vraag als context aanbieden. Daarvoor hoef je niet automatisch een nieuw model te trainen. Het systeem haalt relevante informatie op en geeft die mee aan het model.\n\n## Begin bij een concrete vraag\n\nStel dat een medewerker vraagt welke stappen nodig zijn om een beschadigd product terug te nemen. De bruikbare bron is dan de actuele retourinstructie, niet een willekeurig oud gesprek over retouren.\n\nBepaal eerst waar die bron staat, wie hem mag lezen en hoe je herkent welke versie actueel is.\n\n## Zoeken op betekenis kan helpen\n\nEen embedding is een numerieke weergave van informatie. Daarmee kan een systeem zoeken naar inhoud die qua betekenis bij een vraag past.\n\nZo kan een vraag over “beschadigde levering” ook een document vinden dat “productschade na ontvangst” heet. Een vectorindex is één manier om die zoekstap uit te voeren. Gewoon zoeken, filters en gerichte databasevragen kunnen daarnaast nuttig blijven.\n\nDe toepassing die informatie zoekt en aan een model meegeeft, wordt vaak retrieval-augmented generation of RAG genoemd.\n\n## Een label is geen toegangscontrole\n\nEen bedrijfsnaam in de metadata helpt bij het filteren. Dat label maakt de data nog niet automatisch veilig gescheiden.\n\nDe backend moet vaststellen welk bedrijf en welke gebruiker de aanvraag doet, en de zoekopdracht beperken tot informatie waarvoor die gebruiker toestemming heeft. Dezelfde controle geldt voor documenten, databasegegevens en bijlagen.\n\nEen model mag die scheiding niet zelf hoeven raden.\n\n## Maak het antwoord controleerbaar\n\nEen bruikbaar antwoord verwijst naar de gebruikte bron. Wanneer de informatie ontbreekt of tegenstrijdig is, moet de assistent dat zichtbaar kunnen maken.\n\nVoor het retourvoorbeeld kan de medewerker de instructie openen en nagaan of die op deze bestelling van toepassing is. Zo wordt het antwoord een hulpmiddel bij het werk.\n\n## Test eerst een kleine verzameling\n\nBegin met een overzichtelijke set actuele documenten. Maak voorbeeldvragen, controleer welke bronnen worden gevonden en beoordeel de antwoorden met iemand die het proces kent.\n\nPas wanneer die basis werkt, heeft uitbreiding naar meer documenten of extra acties zin. Meer informatie beschikbaar maken is niet hetzelfde als betrouwbaarder antwoorden krijgen.\n\nVoor meer voorbeelden voor ondernemers en managers bouw ik [AI Inzetten](\u002Fprojects\u002Fai-inzetten). Voor de applicatieregels achter zulke tools werk ik aan [cloudconfig](\u002Fprojects\u002Fcloudconfig).\n","Practical AI",[],[97,98,99,100,101],"AI","bedrijfsdata","RAG","zoeken","context","nl","ai-inzetten","\u002Fblog\u002Fje-bedrijf-koppelen-aan-chatgpt",{"slug":106,"title":107,"description":108,"body":109,"category":54,"sources":110,"date":14,"updated":14,"tags":114,"language":102,"draft":21,"path":117},"how-ai-changes-frontend-2025","MCP in een Nuxt-app: van vraag naar gecontroleerde actie","Dennis Adriaansen over MCP, tools en de scheiding tussen een AI-voorstel en een toegestane actie in je applicatie.","\nEen AI-model kan een actie voorstellen. Een applicatie moet bepalen of die actie klopt en is toegestaan. Dat onderscheid is een belangrijk uitgangspunt in mijn werk aan [cloudconfig](\u002Fprojects\u002Fcloudconfig) en [Nuxt Agentic](\u002Fprojects\u002Fnuxt-agentic).\n\nIk ben Dennis Adriaansen, in de Nuxt-community ook bekend als Dennis Adriaans. In dit artikel kijk ik naar MCP vanuit de ontwikkelaar die een werkende applicatie moet bouwen.\n\n## Wat MCP verbindt\n\nHet Model Context Protocol beschrijft hoe een AI-applicatie context en mogelijkheden van een server kan ontdekken en gebruiken. Een host beheert clients die met MCP-servers communiceren.\n\nEen server kan onder meer tools, resources en prompts aanbieden. Een tool voert een functie uit; een resource levert context; een prompt biedt een herbruikbaar uitgangspunt voor een interactie.\n\nDie verbinding vertelt de applicatie welke mogelijkheden er zijn. De concrete regels van je product blijven jouw verantwoordelijkheid.\n\n## Een voorbeeld: een project aanpassen\n\nStel dat iemand vraagt: “Zet dit project op afgerond.” Een mogelijke tool kan een projectstatus wijzigen, maar daarvoor zijn nog steeds een project-ID, een geldige status en een ingelogde gebruiker nodig.\n\nDe server controleert of de gebruiker dat project mag aanpassen. Vervolgens valideert de applicatie de nieuwe status en voert ze de wijziging uit. Een gevoelige wijziging kan eerst een zichtbare bevestiging krijgen.\n\nHet model hoeft die controles niet te vervangen. Het helpt om de vraag aan een concrete bewerking te koppelen.\n\n## Maak de grens leesbaar\n\nEen kleine tool met een duidelijke invoer is makkelijker te beoordelen dan een algemene functie die overal toegang toe heeft.\n\nLaat de interface tonen wat er gaat gebeuren. Laat de backend controleren of het mag. Leg daarna het resultaat vast, zodat een gebruiker kan zien of de bedoelde wijziging is uitgevoerd.\n\nZo blijft dezelfde applicatieregel gelden voor een knop in het dashboard, een API-aanroep en een voorgestelde actie van een agent.\n\n## Begin met één bruikbare handeling\n\nKies een afgebakende functie die je al begrijpt. Beschrijf haar invoer, bepaal de toegangsregels en test het resultaat buiten de modelinteractie.\n\nPas daarna krijgt de AI-interface er een betekenisvolle rol bij. Een protocolverbinding is het begin van de integratie; het productgedrag zit in de applicatie die je eromheen bouwt.\n\nLees meer over de infrastructuur op de [cloudconfig-projectpagina](\u002Fprojects\u002Fcloudconfig).\n",[111],{"label":112,"url":113},"Officiële MCP-architectuur","https:\u002F\u002Fmodelcontextprotocol.io\u002Fdocs\u002Flearn\u002Farchitecture",[115,42,97,116],"MCP","tools","\u002Fblog\u002Fhow-ai-changes-frontend-2025",{"slug":119,"title":120,"description":121,"body":122,"category":54,"sources":123,"date":14,"tags":127,"language":20,"draft":21,"project":133,"path":134},"scheduling-coding-agents-with-open-run","Scheduling coding agents with Open Run","The project behind local coding-agent schedules, with a focus on explicit tasks, visible changes and reviewable results.","\nA coding agent can help with a repeatable task, but someone still needs to say what should happen, where it should happen and how to check the result.\n\nOpen Run is my project for scheduling that work on a local machine. It uses coding-agent CLIs and connects their runs to projects, triggers, conversations and Git changes.\n\n## A schedule needs a precise instruction\n\n“Improve the project” leaves too many decisions open for an unattended run. A smaller instruction gives the result a clearer shape.\n\nFor example:\n\n> Inspect the failing date-formatting test. Explain the cause, make the smallest correction and run the relevant test. Leave the change available for review.\n\nThis is an example task, not a guarantee that the agent will fix it. Its value is that the goal, scope and verification step are visible.\n\n## Keep execution separate from acceptance\n\nA run can produce a change without deciding that the change belongs in production.\n\nThe diff is the bridge between the agent’s work and a developer’s judgment. The developer should be able to see which files changed and whether the checks relate to the original problem.\n\nA successful process exit alone does not establish that the application behaves correctly.\n\n## A local schedule has real operating conditions\n\nThe machine must be awake and the worker must be running for a schedule to fire. The selected CLI also needs to be available and configured.\n\nOpen Run does not require model API keys itself, but its agent CLIs still use their own subscriptions or provider configuration. “Local” describes where the orchestration runs; it does not mean the selected agent performs every model operation offline.\n\n## Make the history useful\n\nThe history of a run should help answer a few practical questions: what was requested, which agent ran, what changed and what was checked?\n\nThat is the reason I care about connecting instructions, conversations and diffs. It makes repeatable work easier to follow when someone returns to it later.\n\nRead the [Open Run repository](https:\u002F\u002Fgithub.com\u002Fdennisadriaans\u002Fopenrun) for current commands and runtime details, or visit [the project overview](\u002Fprojects\u002Fopen-run).\n",[124],{"label":125,"url":126},"Open Run README, CLI and security details","https:\u002F\u002Fgithub.com\u002Fdennisadriaans\u002Fopenrun",[128,129,130,131,132],"Open Run","coding agents","automation","Git","scheduling","open-run","\u002Fblog\u002Fscheduling-coding-agents-with-open-run",{"slug":136,"title":137,"description":138,"body":139,"category":29,"sources":140,"date":14,"tags":146,"language":20,"draft":21,"project":87,"path":148},"why-i-built-nuxt-charts","Why I built Nuxt Charts","The practical problem behind Nuxt Charts, and how a chart library grew into reusable blocks and dashboard templates.","\nNuxt Charts began inside another project. I was building Nuxt Error, an error dashboard for Nuxt applications, and needed charts that were informative and looked right in the interface.\n\nI liked the polished visualization work I saw in the React ecosystem. Working in Vue and Nuxt, I wanted an equally straightforward way to get to a finished result.\n\nThat need became Nuxt Charts. I’m Dennis Adriaansen — also known as Dennis Adriaans in the Nuxt community — and this is one of the projects that best captures how I like to build.\n\n## The chart is only part of the work\n\nA dashboard needs more than a line on a screen. It needs a clear label, a sensible scale, useful formatting and a layout that makes the data’s context visible.\n\nConsider a chart of completed jobs. A line can show the trend, but a reader still needs to know the time window and whether the values are totals or rates. A tooltip cannot do all that work for the page.\n\nMy aim is to make the ordinary parts of that interface easier to assemble, so a developer can spend more time on what the application needs to communicate.\n\n## Defaults should get you started\n\nNuxt Charts connects Vue chart components, built around Unovis, to a Nuxt-focused experience. The work now also includes reusable blocks and dashboard templates.\n\nA useful default gives a developer something coherent to begin with. Customization lets it fit the product: color, spacing, number formatting and the relationship between a chart and the rest of a screen.\n\nThose two needs belong together. A component should be quick to use without forcing every application to look identical.\n\n## From one need to a reusable piece\n\nThe original problem was specific to one dashboard. The reusable part was the path from typed data to a readable chart.\n\nThat is the pattern I keep looking for in my projects: solve a real problem, identify the repeated work and make that piece easier to use again.\n\nFor the current examples and documentation, visit [Nuxt Charts](https:\u002F\u002Fnuxtcharts.com). For a longer view of the project, see [the Nuxt Charts project page](\u002Fprojects\u002Fnuxt-charts).\n",[141,144],{"label":142,"url":143},"My original article on DEV","https:\u002F\u002Fdev.to\u002Fdennisadriaans\u002Fwhy-im-building-nuxt-charts-4dlj",{"label":145,"url":81},"Nuxt Charts — current library and examples",[84,41,44,147],"developer experience","\u002Fblog\u002Fwhy-i-built-nuxt-charts",1794481660652]