Peter Naur's classic 1985 essay "Programming as Theory Building" argues that a program is not its source code. A program is a shared mental construct (he uses the word theory) that lives in the minds of the people who work on it. If you lose the people, you lose the program. The code is merely a written representation of the program, and it's lossy, so you can't reconstruct
sleepyfox
/ programming-as-theory-building.md
Created
April 27, 2021 18:02
— forked from onlurking/programming-as-theory-building.md
Programming as Theory Building - Peter Naur
sleepyfox
/ 2021-02-22-heavy-lifting.md
Last active
September 13, 2021 10:52
Undifferentiated heavy lifting
author: @sleepyfox
title: Undifferentiated heavy lifting
date: 22 February 2021
preamble: Why managed services are the last thing you should be thinking of
It is the popular wisdom nowadays that the secret to success is to use AWS (or ANO Cloud provider) to the fullest extent, using 'managed services' for all the components of your company's solution that it is possible to do so, to remove the 'undifferentiated heavy lifting' from your business. This is using the analogy of porters on the docks carrying cargo around from ship to warehouse, it's menial commodity work that requires no special skills.
sleepyfox
/ 2012-10-30-coffeescript-and-classes-privacy-and-encapsulation.md
Last active
February 2, 2021 13:53
CoffeeScript and classes, privacy and encapsulation
author: @sleepyfox
title: CoffeeScript and classes, privacy and encapsulation
date: 30-Oct-2012
preamble: There is an uneasy alliance between the concept of a 'class' in CoffeeScript and the class-less prototypal inheritance model of JavaScript, itself influenced by Self and Scheme. Many people coming to JavaScript, including the creators of CoffeeScript and Prototype.js have added mechanisms to their languages/libraries in order to enable a more 'intuitive' mechanism for handling Object-Oriented (OO) concepts.
Whilst I'm not declaring the use of OO in JavaScript to be good or bad per se, what I would like to do is point out where the limitations of JavaScript (and hence CoffeeScript) lie, and how to avoid inadvertently tying your own shoelaces together.
A simple example.
One way of hiding attributes or methods in JavaScript is to put them inside a closure. In our example implementation mug.js we have a functional-style make_mug function that creates Mug objects, each of which have a fill and a drink method, and a private liquid_oz attribute (the same method can be used for methods, no pun intended).
Only the mug object's methods have access to the private attribute. Reading from it from outside the object returns undefined and trying to set it from outside merely creates a new attribute that is public, but that is ignored by the object's methods.
This happens because at the time that we call make_mug(), when the mug object is created it closes over the lexical environment that it was created in, which includes the liquid_oz attribute. This closure is private ('closed' to the outside, hence the term 'closure') and cannot be accessed by calling code. When this object is returned from the make_mug funct
sleepyfox
/ 2020-07-29-hacking.md
Created
July 29, 2020 14:28
On Hacking and forgetting - a critique
Recently I reread 'Programming is Forgetting: Toward a New Hacker Ethic' by A. Parrish as it had come up in conversation with peers. Reading it now there are some fairly large problems with the article which I feel need addressing.
Firstly I want to frame the discussion by saying that the second half of the article, which deals with linguistics, systems thinking and general semantics is good stuff. There are valuable points there which we as an industry could well pay more attention to. The content of the first half of the article however is a condemnation of Steven Levy's 1984 book, 'Hackers : heroes of the computer revolution'.
The author in using Levy's book as a definition of Hacking and hacker culture sets up a straw man and falls victim to their own arguments of not succumbing to cognitive bias and cultural stereotyping. Levy's treatise, written in the era of Margaret Thatcher and Ronald Reagan is full of personal bias, and the bias of the time. Taking a quick look at this review of Lev
sleepyfox
/ post-commit-review.md
Last active
August 22, 2022 02:17
Post-commit reviews, the good, the bad and the ugly
Recently I read a tweet from @GergelyOrosz:
There are few engineering practices that I've not tried but I really want to. Post-commit reviews are one of them and @copyconstruct has a beyond excellent writeup. I'm thinking now is how to get to the stage that it's safe enough to fly with this:
He links to Cindy Sridharan's post on Medium about post-commit reviews which in it's opening paragraphs references a paper by Amazon on how they automate safe, hands-off deployments.
Then, after some preamble there's a section on what post-commit reviews are, and why you should prefer them over the more prevalent pre-commit reviews.
sleepyfox
/ 2020-07-14-exponential-horn.md
Last active
July 14, 2020 12:44
The exponential horn of testing
My favourite type of horn, a Viking drinking horn from Horns of Odin.
Inspired by Seb Rose's tweet about 'Eviscerating the Testing Pyramid', which, although containing some reasonable thoughts, I cannot take seriously due to his bizarre choice of language.
"Hey, Rogue boy! You call that an Eviscerate?"
"But Kungen, I crit for over 10,000!"
Although we're used to being told that you need to be good at maths in order to learn to code, studies by educators and psychologists prove that this isn't true. Although some people would like to have us believe that e.g. an aptitude for learning languages makes it easier to learn to code, studies show that this isn't really the case either. The truth of the matter is that anyone can learn to code. All it takes is time, effort and persistence. If you're not sure whether you believe it - read this story: https://www.wired.com/2015/11/can-you-teach-a-coal-miner-to-code/
- Because you want to make a thing, and that thing is an app, program, or requires some programming in order to work?
- Because you want to change the world and you need to code in order to do it?
sleepyfox
/ fruit_ninja.md
Created
October 30, 2019 11:37
Fruit Ninja pattern - Monlith to Microservices
In the once popular mobile game 'Fruit Ninja', the player must use their finger like a katana to slice pieces of fruit that fly across the screen to gain points. Sometimes a bomb will replace a piece of fruit, and if the player accidently slices the bomb then they will lose one of their three lives. If you've never played Fruit Ninja before then this video shows the gameplay.
When on the journey from monolith to microservices, it is often the case that we need to slice off a piece of the application into its own service, and the choice and drawing of a seam to cut along is the key to making this approach successful.
Some things to consider:
- Is the thing a domain entity? (DDD)
- Does it have a bounded context?
I did not invent this, I have extensively searched for the original article but failed to find it, so I'll do my best to reproduce it here.
Imagine a large Enterprise software development company. A bright young programmer joins this company, and in their first few weeks sets about the non-trivial task of understanding the gigantic bloated code base for the company's flagship product.
Finally, the young programmer ascends the dizzy spire of the company's office building and storms into the CTO's gloomy office with a stack of fanfold computer printout, pausing as they become aware of the music playing: a cacophany of crazed flutes and pan-pipes emerging from an audiophile system with a turntable that looks like a medieval orrery and a speaker that bears more than a passing resemblance to the monstrous shell of some long-extinct cephalopod. The music stops, the silence replacing it redolent of some awful finality.
Still full of righteous indignation the programmer angrily declares: