Git – making smart people feel stupid since 2005.
I think in some sense that the categories front and back end obscure the fact that it’s (or should be) modules all the way down.
Every part (module!) of the system should have boundaries as strong as those between front and back end. (For a moment ignoring that front and back ends don’t have strong enough boundaries.)
Every module should have integrity. Every module should keep some things to itself, thereby freeing other modules from having to concern themselves with those things.
It should be very clear which the responsibilities of a modules are, and which aren’t.
Are there really categories of responsibilities are wholly belong to either the front or back end?
A module can either accept or reject an input.
If it accepts it, that means accepting responsibility for it.
By rejecting it, that signals to the sending party that it is their responsibility to prepare the input in some other way, before sending it.
If the module accepts it, it is then responsible for transforming the input such that it can be processed.
The API should make clear what things will be accepted or rejected.
Anything that is not clear from inspecting the API will be left to exploration. And then there’s the risk that some variations aren’t found before release into the world. Then things will turn out to be rejected when they were expected to be accepted.
A module can choose to be very strict, which reduces the likelihood that such unexpected rejections happen in the wild.
Making software is an exploration. Like hiking in the mountains, sometimes you are in an open landscape: you can see where you are going and you can see where you have been and how long it took to get to where you are now.
At other times, you can see a steep climb, and then you can’t know how long it will take to complete the next stage of your trip, and how much effort – or even if you’ll have to turn back and take another route.
At yet other times, your vision will be obscured, so you know nothing about what lies ahead.
Also, in making software there are no maps.
When I’m a member of a software team, I want to help establish an environment where anyone at any level of experience dares to contribute ideas and be open about what they don’t know or understand.
In our profession as software makers, knowledge and experience are central to one’s status. In this field we are still struggling with what it takes to succeed with projects, to deliver things of quality at a competitive pace.
So being seen as someone who is experienced and knows a lot makes you attractive and in the end determines your value.
Sometimes there’s a lot of pressure on a team. The organisation might not be happy about what the team delivers or how long it takes.
If you as a member of the team are struggling to meet the estimates, often this makes you less likely to ask for help, so having a culture on the team where it’s safe to do so is important, for the individuals as well as for the team.
For a member of a team to ask for help, to say that they are confused about something, or worried that they might not be able to do fulfil a task, they must see other team mates do so. So one factor that discourages this is that it seldom happens.
Another factor is that organisations often have a poor understanding of what it means to make software.
We desperately want things to be predictable, that it will be possible to find a way to have an idea and carry it out exactly as envisioned, with as much effort we thought it would be.
Making software means being in a state of constant exploration. We can’t be certain about anything. And when we don’t recognise this openly, we also contribute to a culture where there’s great risk in being open about being uncertain.
In the early days of Agile, before the term was coined, the term ‘light-weight processes’ wasn’t deemed ideal, that it wouldn’t gain traction among those who felt a heavy-weight process was called for. Perhaps it would do better today, when Agile has become bogged down.
Making software, you can’t be sure of anything until it’s in the hands of your users, and you can tell that they understand what it enables them to do, and that it has the desired effects on your business.
Talking to users and drawing the UI in Figma doesn’t make this not true.
We do many things in a software project to gain certainty: do research, draw designs, write specs, discuss things, estimate the effort to implement – and how all this don’t make things as certain as we feel they are. I think it would be a good thing to recognise this uncertainty.
From ’How Frank Gehry delivers on time and on budget’:
When projects are launched without detailed and rigorous plans, issues are left unresolved that will resurface during delivery, causing delays, cost overruns, and breakdowns. […]
Gehry and his team had spent two years up front thinking through and simulating every detail, in effect building the museum on computers before they built it in reality. […]
Relatively speaking, planning is cheap, delivery is expensive.
There was a time when we thought this was the case for software projects. We, on the other hand, want to move to delivery as soon as possible, and capture the details in code, not plans.
Civil dusk. When you can still read. Nautical dusk. When at sea you can still make out the horizon. Astronomical dusk. When you can begin to observe faint stars.
One major factor in the emergence of agile methods in the 90s was the idea that we needed to manage software projects in harmony with the nature of making software. We fixed some of that, with shorter releases, iterating on plans; the emergence of the web as platform also helped.
But wasn’t agile rather about handling uncertainty and embracing change? Wasn’t it about any type of project facing uncertainty? Well, earlier efforts to get control over software projects were rather about removing uncertainty, deciding early on what shouldn’t change.
The belief was that late change was the very cause that projects failed – either exceeding budgets and deadlines, if finishing at all. We looked to other engineering disciplines in these efforts. Which was a mistake as it meant rejecting the nature of making software.
Also, having frequent, as in at least daily, discussions with those responsible for the behaviour and appearance of product as received by the users. You can’t successfully make software without this.
In some projects, UX becomes a barrier to such discussions. Those discussions have already taken place, and some artifact is handed over. Invariably there are aspects that haven’t been considered, usually leading to compromises in the resulting system design.
If you create an interface, be it a function or an API endpoint, you have two options for the inputs it takes. You can be strict, and then it’s the callers’ responsibility to prepare the inputs in an exact way. Or you can be loose, and then it is your responsibility to normalise.
Being strict means it’s your responsibility to reject every incorrect input. You can still reject things if you are loose, but for that which you don’t reject you have to be strict about shaping the input in the way the caller would have done if you had been strict.
So what are you?
There are directors who think they have to provoke people to get the best work out of them. […] I try to create a very loose set, filled with jokes and concentration. It sounds surprising, but the two things go together nicely.
Jag har länge sysslat med Git från command line förutom för att diffa & merga (med Kaleidoscope). Nu har jag börjat att staga ändringar med Fork, vilket har varit ett enormt lyft. Annars håller jag fast vid min uppfattning att Git inte kan abstraheras bort av ett GUI.
En produkt som aldrig skulle flyga om den uppfanns idag: ringklockan – en knapp utanför din bostad som spelar upp ett högt ljud inne i bostaden. Vem skulle vilja ha något sådant?
Igår råkade jag på en optional bool som representerade sex olika state.
Såg första avsnittet av Squid game. Serier har i alla fall i 10–15 år byggt huvudsakligen på mysterier och cliffhangers och att portionera ut svar och nya mysterier i effektiva doser så att vi blir hooked. Var Lost först med att skruva upp den manipulativa dramaturgin?
Above all, Hitchcock inspires comparison with Shakespeare, a conjunction that some may find hard to justify but which, having studied and written on each, I am more and more inclined to support. Both had a prescribed structure, adapted material taken from elsewhere to their own lexicon and vision, and used humour to season their drama. Both were enormously confident in their imaginations, prolific in their output, and astute in the ways of business and promotion. Both were moralists who took issue with the morality of their day while managing not to show their loyalties too clearly or ever lose popular support. “You have to design your film just as Shakespeare did his plays – for an audience”, Hitchcock told Truffaut.
Shakespeare’s greatness is wedded to language and Hitchcock’s to cinematic expression, in keeping with the ages in which they worked. Hitchcock’s apprenticeship during the silent era meant that he would always think, first, in images, and his greatest sequences are without dialogue (though often brilliantly scored). Some of my favourites: the camera closing in on the blinking drummer in Young and Innocent (1937); the train’s arrival with a cloud of black smoke bringing the suave killer to his sister’s family in Shadow of a Doubt; the extraordinary stalking and strangling scene in the fairground in Strangers on a Train; the reverse crane shot that shows us the key in Ingrid Bergman’s hand in Notorious (1946); the panning shot that opens Rear Window and tells us everything we need to know about the laid-up protagonist; the stabbing in the shower in Psycho; and the movement through the cemetery in Family Plot (1976). Even a disappointingly incoherent film like Topaz (1969) is made unforgettable by the image of a woman falling to the floor after being shot, her purple dress cascading around her like a pool of blood, but also like a flower, finding its fullest expression in the moment of death.
Sån är jag: ska ta fram nya skyltar till tvättstugan, bläddrar snart på experimentaljetset.nl, plockar fram typografiböcker, funderar på om jag ska friska upp mig på vilka Ellinor Ostroms 8 regler för fungerande allmänningar är.
Så git rebase är inget annat än en anonym branch skapad på toppen av det du vill rebasa din branch ovanpå, och därefter bara ett antal cherrypicks från nämnda branch – där din branch sedan resettas till den anonyma?
Insåg det när jag i en rebase av en lång branch klantade mig i mitten när jag löste konflikter: bara att göra git rebase --edit-todo och lägga tillbaka den tillklantade som en pick överst och resetta till HEAD^ och göra git rebase --continue.
Behöver uppdatera alla mina avatarer, för idag ömsade jag pandemisvallet.
En fråga att ställa sig själv. Vad har jag under pandemin lärt mig om mig själv och är någon lärdom så påtaglig att jag inte önskar att jag hade sluppit det hela?
Min genomsnittliga vilopuls har gått ned från 57 till 53 under pandemin.
Det var överraskande. Pandemin har varit krävande och inneburit stress. Men jag har sovit mer och också vilat mer. Jag ska fundera på vad det kan bero på.
I mitt nuvarande uppdrag har jag lagt en pull request var 1,9:e dag och reviewat 2,2 för varje jag har lagt.
Funderade nyligen över den märkliga betydelseglidningen i programmeringstermen ”mock”, med tanke på att just utvecklare tenderar om att vara måna om tydlighet och semantik. Att låta ett ord ta över alla närbesläktade ord, när det från början var väldigt specifikt – märkligt.
Ett annat fall är ordet ”model”. Från början ”business” eller ”domain model”. Vanligen singular, omfattande samtliga entiteter i en verksamhet eller domän. Nu syftande på enskilda entiteter – dessutom i huvudsak som databehållare, från att främst ha gällt logik och relationer.
Alltså ”en modell” av en domän, dess entiteter och deras roller och ansvar i förhållande till varandra, logik, regler. Jag kan gå med på att se varje entitet som en modell i sig av en företeelse, men det jag främst tycker är synd är att logik och funktion ses som något separat.
Litauiska alfabetet har 32 bokstäver! Vi är stolta över åäö men de har ąčęėįšųūž! Förvisso har de inte x eller q. Dessutom överraskar de med att lägga y efter i och į; notera att det sista inte är ett j (det kommer efter y).
I Monterey har jag varit. Inte Big Sur, eftersom vi när vi bilade från San Francisco efter WWDC 2001 hade blivit less på scenic routes vid det laget då vi passerade avtagsvägen. Sierra (Nevada) och El Capitan ligger båda i Yosemite där jag var något av de tidigare åren.
Har prickat in rätt många macOS-versioner. Har vagt för mig att jag något år dessutom var i Half Moon Bay där Mavericks Beach ligger.
Kategorin random tvivelaktiga fakta jag har memorerat: att det i genomsnitt är en halv grad lägre temperatur i parker, vilket gör att det uppstår luftcirkulation i städer.
Det är vanligt att kalla alla slags test doubles för mocks. Jag upplever att man nästan uteslutande menar stubs. En mock är en stub som dessutom har förväntningar om hur andra entiteter ska interagera med den, som alltså kan faila testet om dessa inte uppfylls.
Mock, stub och fake har förvisso som ord inga nyanser som hjälper en att avgöra vad som är vad. Spy och eventuellt även dummy har lite mer ”metaforisk höjd”. ”Att mocka” kanske ligger bättre i munnen.
Men det är synd att inte ha alla orden till hands i diskussion. Att säga mock om en dummy förlorar aspekten att det är något som inte har betydelse för testet, utan bara för att alls kunna sätta upp testet.
Att säga mock om stub är väl egentligen inte så farligt i ett sammanhang där man aldrig använder mock-tekniken, vilket ofta är fallet.
Någon som kommer ned i tvättstugan tänker en av två tankar: Grisigt, ingen städar efter sig! (Städar följaktligen inte heller.) Fint, här var det nystädat! (Dito.)