Tag Archives: CI

Radial Charts


I wanted to plot the data that is tightly connected to a time of a day as a circular chart, resembling the clock face – for no particular reason other than checking out how it looks.

Another thing I wanted to do was to play with some relatively modern JS framework.

And then I also got a bit a of a spare time on my hands.


So as a result, here’s a code that fetches CSV data from Graphite metrics (or any other CSV file) and displays it on a radial chart (aka Radar chart). It’s crude and unoptimised and inefficient, but it serves the goal of visual representation (see examples section below): https://github.com/hydralien/Radial-Charts

It’s mostly an amCharts showcase – amCharts are amazing, I love them dearly. Check them out if you’re not familiar, there’s seemingly nothing you can’t do with them: https://www.amcharts.com/demos/

Additionally, it also uses Github Actions (https://help.github.com/en/actions) as a CI mechanism – so on every push a build is pushed to a branch and then deployed as Github pages using https://github.com/marketplace/actions/github-pages-action#%EF%B8%8F-publish_branch (there’s many action plugins, this one was just the first one that worked).


Surprisingly, there’s npt that many public datasets with high-granularity daily data available on the Internet, but here’s at least one:
Bike rentals in NYC, January 1st 2020 vs July 1st 2019 (from https://s3.amazonaws.com/tripdata/index.html):

Bike rentals


  • it’s not a working tool or a developing project – it’s a fun thing built for no reason
  • it loads a ton of unnecessary libraries, becasue how amCharts library for Vue.js is structured, and also because it’s not optimised for anything
  • <many other things>

Project features switch trick (aka Feature Toggle)

OK, so you probably know about feature branches. And DVCS. And CI (see that feature branches article again, there’s also PI idea I wasn’t aware of before). So do I (more or less). What I wasn’t aware of (till recent visit to CEE SEC(R) conference – which was OK, even good at some points) is Feature Toggle idea (sometimes referred as “switches”, “flags” etc.), which is quite useful in stand-alone software model, or if your service is big and world-wide.

The description Martin Fowler provides is pretty complete and verbose (who could have doubted), but still to squeeze the idea: for each feature you can consider a separate chunk of changes – such as a new part in UI that connects to the rest of the interface through a single link, new API method, a switch in data processing algorithm, that kind of stuff – you can do a configuration-level flag that, when given a true value, would enable that feature – or disable otherwise.

I see it useful in many cases – when you can try out new functionality on a limited group of customers but don’t want to build them a separate version, when you want your brand new user profile disguise appear only when customer system is ready for that without blocking other system updates (I know Facebook is using that model to deploy their changes world-wide). This also works quite well with CI idea – you can easily do CI on your main branch, and disable failing features without a need to rollback or quick-fix.

However this Toggling technique (like, well, any other) doesn’t suit all cases. It won’t do for bugfixes; It doesn’t fit small changes, or a patch that alters all occurrences of some method; it’s an overkill for (relatively) small SaS model where releases are easy to fix or rollback. So… Be advised, use wisely. And if you do, don’t forget to remove togglers when the appropriate code reaches stable-prod-level state – otherwise you eventually get yourself another ugly mess of no-one-remembers-why rules.

FTR there’s also this “branch by abstraction” idea – but I think it’s somewhat overcomplicated. I mean , to build an abstraction layer (sort of facade/adapter fusion) and switch internal methods used is alright, but why not just doing those method changes in branches? Although the perspective I see it from is a SaS, and rather tiny one – so there might be valid cases for this one, too.