Programming Leftovers
-
The C free() API means memory allocation must save some metadata
Here's something that I hadn't really thought about until I was thinking about the effects of malloc() and free() on C APIs: the API of free() in specific more or less requires a conventional C memory allocator to save some metadata about each allocation. This is because free() isn't passed an explicit size of what to free, which implies that it must get this information from elsewhere. The traditional way the C memory allocator does this is to put information about the size of the allocation in a hidden area either before or after the memory it returns (often before, because it's less likely to get accidentally overwritten there).
(That C memory allocators store the size of allocations they've handed out is clear to anyone who's read through the small malloc() implementation in K&R.)
-
My adventure with URLs in a Grafana that's behind a reverse proxy
I was oblique in yesterday's entry, but today I'm going to talk about the concrete issue I'm seeing because it makes a good illustration of how modern web environments can be rather complicated. We run Grafana behind a reverse proxy as part of a website, with all of Grafana under the /grafana/ path. One of the things you can add to a Grafana dashboard is links, either to other dashboards or to URLs. I want all of our dashboards to have a link to the front page of our overall metrics site. The obvious way to configure this is to tell Grafana that you want a link to '/', which as a raw link in HTML is an absolute path to the root of the current web server in the current scheme.
When I actually do this, the link is actually rendered (in the resulting HTML) as a link to '/grafana/', which is the root of the Grafana portion of the website. Grafana is partially configured so that it knows what this is, in that on the one hand it knows what the web server's root URL for it is, but on the other hand its own post-proxy root is '/' (in Apache terminology, we do a ProxyPass of '/grafana/' to 'localhost:3000/'). This happens in both Firefox and Chrome, and I've used Firefox's developer tools to verify that the 'href' of the link in the HTML is '/grafana/' (as opposed to, eg, the link getting rewritten by Javascript on the fly when you hover or click on it).
-
How to Fight Climate Change as a Software Engineer
We need to reduce and eliminate greenhouse gas emissions in order to stop climate change. There is no way around this. But what is the role that software plays here? And what can we - as software engineers - do about this? Let’s take a look under the hood to uncover the relationship between greenhouse gas emissions and software, learn about the impact that we can have, and identify concrete ways to reduce those emissions on a day-to-day basis when creating and running software.
-
4 Ways Software Developers Can Fight Climate Change
Thus, they say, software engineers can contribute to the fight against climate change in seemingly small ways that add up to a larger impact.
-
raku & rust: Option-Some-None
Regular visitors to my blog will know that I think raku and rust are both awesome in their chosen niches and are natural companions for the modern programming era just as perl and C were back in the day.
Coming off an excellent 2nd raku conference over the weekend, I got to thinking about how both languages handle the concept of “nothing” (the absence of a value) and wanted to have some -Ofun.
-
Postboxes & Postal Codes
The postal code data was acquired from gov.uk as a collection of CSV files. The data were read and consolidated into a single data frame. The coordinates were transformed from CRS 27700 (British National Grid) to CRS 4326 (World Geodetic System).
The postbox locations were retrieved from https://postboxes.dracos.co.uk/, an awesome interactive map created by Matthew Somerville using data from the Royal Mail. The data were lightly cleaned (there’s still some work to be done though).