Years ago I built my own CI-CD 🔗 solution for a moderately complex static website. ...

Have you ever spent hours on something, made it work, and then discovered a feature in the language that could have saved you a ton of effort? That’s what happened when I tried to figure out how to draw an arrowhead to a curved line at some distance from the center of a target (see banner). TL;DR When working with custom visualizations, you might need to do some math. But make use of (and give credit to) the community around these tools. It’s there for a reason. ...

I’ve recently found myself with a little more free time, and so this new site is finally coming together. Topics I will be discussing include the typical meta-topic of hosting and updating affordable static sites on the internet, but I’ll also be touching on the challenge of maintaining control of a site while enabling external contributions … clearly not a thing just yet on this site. Tools of the trade may include (in alphabetical order) AWS 🔗 , Cloudflare 🔗 , GitHub 🔗 , Slack 🔗 and Zapier 🔗 . Digging into the weeds on the use of those tools means I won’t be able to avoid things like build automation, cloud hosting (including security issues), possibly some microservice architecture, seasoned with some light coding. ...

Introduction This post builds on a discussion started last week on managing visualization state. For some more context please see last week’s post . Example - D3 meets React and Angular We start by revisiting (and revising) a simple brushing visualization from Mike Bostock introduced as an example of user interaction with data-driven visualizations. JavaScript-enabled users get an interactive version of this static image. The code for our starting point is fairly typical of D3 sample code. It is a stripped down version of the original on bl.ocks.org 🔗 , modified to focus on the basics and to provide blog readers lacking JavaScript with a substitute image. An associated stylesheet is required, shown immediately after the JavaScript code. ...

Problem How best to manage the state of interactive browser-based visualizations. Context Interactive web applications composed of data-driven visualizations typically take advantage of open source JavaScript libraries. Choosing the right visualization library is one of the developer’s first decisions, and an important but sometimes hidden element of this decision is how the library maintains interaction state. In the early days of the web it might be said that the DOM was the state, and many excellent visualization libraries start with this assumption. But with the rich forms of interaction and collaboration afforded by modern browsers, this assumption can lead to great complexity. ...

Prelude and Caveat This post builds on another post that introduces RESTful APIs using Node-RED. If you haven’t read it already, please see that post . It should be repeated that there are other – perhaps better – ways besides a RESTful API for connecting a MIDI device to a web application. In a future post I will extend this MIDI example using web sockets, but please note that the central purpose of this discussion is not to demonstrate an ideal solution but rather to demonstrate the value of API prototyping using visual tools. ...

Problem When building new web application prototypes there is value in rapid redesign on both clients and servers. Can we make it easy for client programmers to tinker with server prototypes? Context While in many situations it is possible to create a mock server API for clients to consume, in some cases there is value in more realistic data sources. Examples include real-time collaboration and Internet-of-Things (IoT) scenarios. The situation can arise in small agile teams whose focus is primarily on web client applications, but who depend on evolving or establishing server-based resources and APIs. This may be early in proof-of-concept phases, after paper prototyping and perhaps in place of Wizard-of-Oz 🔗 testing, and hopefully long before a production implementation. ...