Programming Leftovers
-
Rlang ☛ Command Line Interface (CLI) for techtonique.net’s API
Command Line Interface (CLI) for techtonique.net's API
-
Uwe Friedrichsen ☛ The long way towards resilience - Part 9
In the previous post, we broadened our view and learned about the sameness of business and IT. We also used the four response types of resilience to change our static approach regarding threats towards a more dynamic one, including continuous evaluation of threats, learning and repositioning in an ever-changing threat landscape. This adds the last missing shard to resilience: Anti-fragility.
-
Python Package Index ☛ PyPI Now Supports Project Archival
Project archival is not deletion: archiving a project does not remove it from the index, and does not prevent users from installing it. Archival is purely a user-controlled marker that gives project owners the ability to signal a project’s status; PyPI has no plans to delete or prune archived distributions.
-
Bert Hubert ☛ On Long Term Software Development
Much software is now provided as a service, and is typically deployed continuously (CD, continuous deployment), surrounded by enough automated testing (CI, continuous integration) that we can be reasonably sure that a new revision is likely to at least work to some extent.
In contrast, there is also still a huge world where people don’t appreciate such continuous changes combined with only a pretty good likelihood of things working. Software that controls (nuclear) power plants, elections, pacemakers, airplanes, bridges, heavy machinery. In general, stuff that can kill you if it does the wrong thing, or perhaps simply by not working.
These fields appreciate your software sticking around for decades, with well described and pre-announced changes. Release notes that go beyond “various bug fixes and improvements”. Software that might not see any changes for a few years, after which a new major release gets planned, and stuff still needs to build from source.
Crazy talk of course, but some of us like it this way!
-
University of Toronto ☛ Modern languages and bad packaging outcomes at scale
Recently I read Steinar H. Gunderson's Migrating away from bcachefs (via), where one of the mentioned issues was a strong disagreement between the author of bcachefs and the Debian Linux distribution about how to package and distribute some Rust-based tools that are necessary to work with bcachefs. In the technology circles that I follow, there's a certain amount of disdain for the Debian approach, so today I want to write up how I see the general problem from a system administrator's point of view.
-
Dirk Eddelbuettel ☛ Thinking inside the box
Thrilled to announce a new package: zigg. It arrived on CRAN today after a few days of review in the ‘newbies’ queue. zigg provides the Ziggurat pseudo-random number generator for Normal, Exponential and Uniform draws proposed by Marsaglia and Tsang (JSS, 2000), and extended by Leong et al. (JSS, 2005).
I had picked up their work in package RcppZiggurat and updated its code for the 64-buit world we now live in. That package alredy provided the Normal generator along with several competing implementations which it compared rigorously and timed them. As one of the generators was based on the GNU GSL via the implementation of Voss, we always ended up with a run-time dependency on the GSL too. No more: this new package is zero-depedency, zero-suggsts and hence very easy to deploy. Moreover, we also include a demonstration of four distinct ways of accessing the compiled code from another R package: pure and straight-up C, similarly pure C++, inclusion of the header in C++ as well as via Rcpp.
-
Alisa Sireneva ☛ Falsehoods programmers believe about null pointers
Null pointers look simple on the surface, and that’s why they’re so dangerous. As compiler optimizations, intuitive but incorrect simplifications, and platform-specific quirks have piled on, the odds of making a wrong assumption have increased, leading to the proliferation of bugs and vulnerabilities.
This article explores common misconceptions about null pointers held by many programmers, starting with simple fallacies and working our way up to the weirdest cases. Some of them will be news only to beginners, while others may lead experts down the path of meticulous fact-checking. Without further ado, let’s dive in.
-
[Old] Erik Aker ☛ Are Second Systems Inevitable
These two ideas are related. In his seminal 1975 work, Brooks argued that “second systems” are almost always bloated and overwrought because engineers seek to solve all problems existing in the first system and this results in their “second system” taking on an unworkably large and overly ambitious set of features and traits. This is why Brooks was impelled to add engineers to the superceding system he was working on at IBM, the failure of which later became the inspiration for his book, where he observed the paradoxical effect that adding people to the late project made it later. Overall, though, second systems like this where engineers try to pack in features they left out of the first system are doomed to failure, Brooks argues, which is the phenomenon we now call “Second System Syndrome.”
I’m interested in second systems, in general, but not necessarily the “syndrome” Brooks identified. Obviously, technical organizations manage to throw away old systems and build new ones without committing the errors Brooks has identified. Nevertheless, second systems are hard, so it’s worth asking why engineering organizations are compelled to do it?
-
Perl / Raku
-
Arne Sommer ☛ Elementary Odd with Raku
You are given an array of positive integers, @ints.
Write a script to return the sum of all possible odd-length subarrays of the given array. A subarray is a contiguous subsequence of the array.
-