Typically, when working in React, it’s best to split UI elements into separate, reusable parts. This allows for more modular code and finer control over each element.
However, this goes against the way D3 operates, which is to subsequently call dot operators, building up elements and groups of elements.
So how can we utilize D3 in a meaningful way while simultaneously breaking up our elements into individual components? I’m going to show you by working through an example implementing a force graph.
Read more on Using D3 with React and TypeScript…
The world and its many, many systems are infinitely complicated and unquantifiable. Yet we hold out hope that if we can collect enough information, we can find the answers to big questions about science, medicine, life, and everything we can imagine.
Read more on Visualizations: Making Your Data Make Sense [w/Video]…
When recently integrating Rickshaw into a project, I ran into a few hurdles that weren’t terribly well documented or explained online. In this post I’ll provide an overview of Rickshaw and go into some detail on how several of the Rickshaw add-ons work, so you can tweak your graph to look just the way you want. Code for all of the below examples can be found in this Github repository.
Read more on Creating Charts with Rickshaw.js…
We discuss scale, risk, and different options with our customers and team members continually throughout the lifetime of a project. Having a visual representation of the conversation points can be very useful.
A well-designed visual makes it easy to identify the highs and lows, draws conversation to the most important points, and helps everyone navigate the problem landscape. It’s hard to replace the way a good visual can connect with visual learners. And, as an added benefit for me, it removes the temptation to just read a slide during a presentation.
A few quick tips before we dig in:
- Double-check your numbers. It sucks to realize your visual is wrong in the middle of a presentation.
- It’s nice if the visual is easy to update to reflect new information. Simple shapes and a straight-forward scale help that a lot.
Below are a few examples we’ve used recently. Read more on Visualizing Project Scale, Risk, and Options…
Most developers take automatic garbage collection for granted. It’s just another amazing feature provided by our language run-times to make our jobs easier.
But if you try to peek inside a modern garbage collector, it’s very difficult to see how they actually work. There are thousands of implementation details that will confuse you unless you already have a good understanding of what it’s trying to do and how they can go fantastically wrong.
I’ve built a toy with five different garbage collection algorithms. Small animations were created from the run-time behavior. You can find larger animations and the code to create them at github.com/kenfox/gc-viz. It surprised me how much a simple animation reveals about these important algorithms.
Cleanup At The End: aka No GC
The simplest possible way of cleaning up garbage is to just wait until a task is done and dispose of everything at once. This is a surprisingly useful technique, especially if you have a way of breaking up a task into pieces. The Apache web server, for example, creates a small pool of memory per request and throws the entire pool away when the request completes.
The small animation to the right represents a running program. The entire image represents the program’s memory. Memory starts out colored black, which means it isn’t used. Areas that flash bright green or yellow are memory reads or writes. The color decays over time so you can see how memory was used, but also see current activity. If you watch carefully, you can see patterns emerge where the program begins to ignore some memory. Those areas have become garbage — they are not used and not reachable by the program. Everything else that isn’t garbage is “live”. Read more on Visualizing Garbage Collection Algorithms…
Some of the most interesting and challenging projects involve data visualization. It can be very difficult to express data in a clear way and also make the product aesthetically pleasing. There are many different ways of presenting data to users, and choosing the “correct” visualization is not always a simple decision. Having numerous tools at your disposal, or at least greater awareness of what is out there, can help you make a better decision.
I was recently experimenting with a library called jqPlot, jqPlot is a jQuery plugin that supports drawing line, bar and pie charts with many customizable features. The project I was working on involved a device that monitors the temperature of the contents of a kettle during the process of brewing beer. My goal was to show the temperature as it changes over time and also to indicate a prediction of when the temperature would reach a desired target value. Here is what I ended up with:
To produce the chart above, very little html code was required. Read more on Charting Data with jqPlot…
I’ve spent a lot of time with D3 over the past several months, and while I’ve enjoyed it immensely, one thing had eluded me: saving visualizations as images. When I needed to turn a browser-drawn SVG (scalable vector graphic) into an image, I used FileSaver.js to save the content of the webpage’s SVG node as a file, then opened the file in Inkscape and rasterized to an image format. Unfortunately, this process often created discrepancies between how the visualization looked in the browser and how it looked in the final image.
While making a calendar as a gift over the holidays, I finally figured out how to save SVG content as an image directly from the browser. Not only is the workflow a lot smoother, but the results are much more consistent than processing the SVG through Inkscape. The core code for the process is laid out below, and the complete script is on GitHub. Read more on Saving Browser-based SVGs as Images…
graphviz is a great tool for creating quick diagrams. While it does not have a particularly polished WYSIWYG editor such as omnigraffle, it can automatically create diagrams from its simple markup language, DOT. After reading in the DOT markup, it uses various layout algorithms to automatically arrange the diagram. The DOT language is pretty flexible in its formatting and quite easy to generate from other programs.
The main installation includes a couple of standalone programs, such as
neato. I’ve mostly used
dot, which creates directed graphs. (
neato renders undirected graphs.) While installing it is beyond the scope of this post, installation is straightforward on OSX, Windows, and most Linux and BSD distributions. Read more on Making Diagrams with graphviz…
Justin Kulesza and I have been using Puppet to manage the configuration of some virtualized servers. Recently, we added some modules that introduced unexpected dependency cycles. As we worked to untangle the complex series of dependencies, it became difficult to keep track of just how everything was connected.
In order to make sense of the complex web of chaining relationships, I decided to take advantage of Puppet’s ability to generate DOT graph files of resource relationships. Although it’s still sparsely documented , this option can be specified either on the command line or in puppet.conf.
Read more on Puppet + Gephi: Visualizing Infrastructure as Code…