Programming Leftovers
-
Document your secrets
We touch those secrets so rarely that unless we bring in new developers into team every month, we’re bound to start forgetting: what does this key actually mean, where do you get it, is it personally generated or shared by the team and what permission levels it should have in a system that supports permission management.
Even my simple one-person static site webpage project has six different environment variables and if I wouldn’t document them, I most certainly wouldn’t remember in 6 to 12 months where I can get new ones.
-
An overview of what's out there for reproducibility with R
In this short blog post I’ll be summarizing what I learnt these past years about reproducibility with R. I’ll give some high-level explanations about different tools and then link to different blog posts of mine.
-
An overview of what’s out there for reproducibility with R
I think that these aspects are really very important nice-to-haves, but depending on the project you might not have to use all these tools or techniques (but I would really recommend that you think very hard about these requirements and make sure that you actually, really, don’t need them).
What’s also important is how you organize the work if you’re in a team. Making sure that everyone is on the same page and uses the same tools and approaches is very important.
Now that we have the commonalities out of the way, let’s discuss the “two approaches”. Let’s start by the most popular one.
-
I’ve vastly misunderstood the Single Responsibility Principle
I came to question that understanding today when I read Parnas’s article On the Criteria to be Used in Decomposing Systems into Modules. His top criterion is decision hiding: everywhere you make a choice about the system implementation, put that choice into a module with an interface that doesn’t expose the choice made.
If you combine that principle with my incorrect SRP (“one reason to change per module”), you get the absurd situation that each module may contain only one change point. In other words, each bit of software architecture information must exist in a separate module.
-
Programming, language
Thus we get approaches to programming language design that ask people what they want to say, and how they want to say it. At one extreme, almost nihilist in its basis, is the Perl-style postmodernist philosophy: it’s not up to the language designer to constrain expression so the language gives you all the tools to say anything, however you want.
-
Python 3.12.0 from a supply chain security perspective
Since the entire process has happened in order to deliver 3.12.0, I wanted to discuss how it can be tweaked to provide better assurances of the integrity of the built artifacts. I'll be discussing these improvements with release managers after the dust has settled around the 3.12.0 release on how to potentially implement these improvements.