LaTeX (and TeX, for that matter), syntax is relatively consistent, and uses a lot of backslashes.

Bourne shell syntax is somewhat inconsistent, and also uses backslashes.

Regular expression syntax I seem almost perversely disinclined to remember, and definitely sometimes often uses maybe backslashes.

Therefore, when I need to use a regular expression to work on a LaTeX document, I do it interactively in the shell until it works then paste that into a shell script. Now I need never remember or even uncover how to write that unholy combination of regex, shell, and LaTeX ever again.

For example I have defined a LaTeX macro \todo{I need more examples here.}, that draws the text “TODO: I need more examples here.” with a box around it in the document. I review outstanding sections by searching for lines on which todo items appear, using this script:

#!/bin/sh

grep -n todo\{ "$1" | sed s/\\\\todo\{\\\(.\*\\\)\}/\\1/

Now I get to blank from my mind the unholy combination of syntaces that led to 15 backslashes on one line, but still use the results.

Here’s a song I wrote many years ago when I lived in Turkey. “Laleli” is actually a rather drab suburb of Istanbul, but I’m using it here as a woman’s name purely because it sounds nice and rolls off the tongue!

Bass and knob-twiddling are by Shez, as is customary. The image is of @naWa53, photographed by Farhad Eidi, combined with some tiles from Topkapı Palace, taken by Meriç Dağlı, used with thanks. The song contains a fragment of a poem by Turkish folk poet and Sufi mystic Yunus Emre, read by Kivanc Atmaca for LibriVox, and some Persian vocal samples from Rast sound. The rest of the vocals and instruments are by me.

I was moving through my strangest dream,

watching how you build your bridges.

I was underneath the lights that seem

to drain the colours from your pictures.

Laleli, my love for you

is wider than these continents.

If all that’s in your mind were read,

who am I to understand or blame you?

I was spinning on the carousel

that makes me end in my beginning.

I was opposite the screens that tell

who is losing, who is winning.

Laleli, my only love –

come watch the evening like a dream.

If all that’s in your mind were read,
who am I to nominate or name you?

I was moving through some stranger’s dream,

watching how you burn your bridges.

I was underneath and in-between

my expectations and your mysteries.

Laleli, my only love -

silver like the Bosphorous.
if all that’s in your mind were read,
who am I to comprehend or claim you?

Words and music © Bruce Lawson 2021, all rights reserved.

• Link o’ the week: The Future of CSS: Cascade Layers is a jolly useful guide by @bramus that’s helped me understand the syntax and subtleties
• Apple to face EU antitrust charge over NFC chip – Only Apple Pay can use it because (checks notes) “privacy and security, absolutely not monopolistic behaviour. Who, us? Ha ha! Never!”
• New study reveals iPhones aren’t as private as you think – “Android phones collect more data by volume, but iPhones collect more types of data, a study finds”
• Make your PWAs Look and Launch Beautifully a presentation a by Önder Ceylan at PWA summit on the new developments on cross-platform icons, splash screens etc.
• Making the whole web better, one canvas at a time – Uncle Brian on OffscreenCanvas
• In Quest of Search – “On why I think adding a new HTML sectioning element for search is a good idea” by Sara Soueidan
• Datasette Desktop – “Datasette was originally designed as a tool for data journalists, to help report on data-driven stories, crunch through large datasets and publish the results…Datasette can be used to power dynamic-static websites: sites that run on serverless hosting while providing dynamic data-backed functionality.”
• Google found guilty of restricting Android forks in South Korea, fined $177 million
• Me Me Me! corner: The F-Word Episode 13 – Does the iOS browser ban harm or help the web? Now with added Stuart Langridge!

I only have 17 years of experience, but every point on this list accords with my experience. I’ve made my own attempt to catalogue things software developers should know (that are not writing code), but this is a succinct and great summary.

A couple of weeks ago, my grandma died.

This was not wholly unexpected, and at the same time it was completely unexpected. I should probably explain that.

She was ninety, which is a fair age for anyone, but her mother (my great-grandmother) lived to be even older. What’s different is that nobody knew she was ninety, other than us. Most of her friends were in their mid-seventies. Now, you might be thinking, LOL, old, but this is like you in your mid-forties hanging out with someone who’s 30, or you in your late twenties hanging out with someone who’s 13, or you at eighteen hanging out with someone who’s still learning what letters are. Gaps get narrower as we get older, but the thing that most surprised me was that all her friends were themselves surprised at the age she was. She can’t have been that age, they said when we told them, and buried in there is a subtle compliment: she was like us, and we’re so much younger, and when we’re that much older we won’t be like her.

No. No, you won’t be like my grandma.

I don’t want to talk much about the last few weeks. We, my mum and me, we flew to Ireland in the middle of the night, we sorted out her house and her garden and her affairs and her funeral and her friends and her family, and we came home. All I want to say about it is that, and all I want to say about her is probably best said in the eulogy I wrote and spoke for her death, and I don’t want to say it again.

But (and this is where people in my family should tune out) I thought I’d talk about the website I made for her. Because of course I made a website. You know how some people throw themselves into work to dull the pain when something terrible happens to the people they love? I’m assuming that if you were a metalworker in 1950 and you wanted to handle your grief that a bunch of people got a bunch of metal stuff that you wouldn’t ordinarily have made. Well, I am no metalworker; I build the open web, and I perform, on conference stages or for public perception. So I made a website for my grandma; something that will maybe live on beyond her and maybe say what we thought about her.

Firstly I should say: it’s at kryogenix.org/nell because her name was Nell and I made it. But neither of those things are really true. Her name was Ellen, and what I did was write down what we all said and what we all did to say goodbye. I wanted to capture the words we said while they were still fresh in my memory, but more while how I felt was fresh in my memory. Because in time the cuts will become barely noticeable scars and I’ll be able to think of her not being here without stopping myself crying, and I don’t want to forget. I don’t want to lose it amongst memories of laughter and houses and lights. So I wrote down what we all said right now while I can still feel the hurt of it like fingernails, so maybe I won’t let it fade away.

I want to write some things about the web, but that’s not for this post. This post is to say: goodbye, Grandma.

Goodbye, Grandma. I tried to make a thing that would make people think of you when they looked at it. I wanted people to think of memories of you when they read it. So I made a thing of memories of you, and I spoke about memories of you, and maybe people who knew you will remember you and people who didn’t know you will learn about you from what we all said.

Goodbye, Grandma.

kryogenix.org/nell

The “return a command” trick

This is a nice trick, but we need a phrase for that thing where you implement extreme late binding of functions by invoking an active function that selects the function you want based on its name. I can imagine the pattern catching on.

As you may know, every browser on iOS is actually just a branded re-skin of WebKit, the engine that Safari uses, because Apple won’t allow other engines on iOS.

Supporters of the Apple Browser Ban tend to give one of three reasons (listed here from most ridiculous to most credible):

The web shouldn’t be “app-like”, it’s for documents only

Whatever. (See A Brief History of Web Apps for more on why this is nonsense.)

Privacy and security are protected by not allowing non-Apple code on devices

This doesn’t really make sense when non-Apple apps are allowed on iOS, which can leak data so valuable that Amazon and eBay will pay you to use their apps rather than web. Apple’s most recent zero-day vulnerability was exploited along with a flaw in WebKit, and so left all users exposed because users of other “browsers” are forced to use WebKit. Stuart Langridge has a great post going deeper into Browser choice on Apple’s iOS: privacy and security aspects.

Allowing other rendering engines leads to Chromium taking over the world

This one kind of makes sense. After all, Opera abandoned its Presto engine and Microsoft abandoned Trident, and both went to Chromium. Firefox risks sliding into irrelevance due to inept lack of leadership. If Apple were forced to allow Chrome onto iOS, then domination would be complete!

The interesting predicate of this argument is that Apple intend to keep Safari as the sad, buggy app that they’ve allowed it to wither to, because it has no competition. I emphatically do not want Chromium to win. Quite the opposite: I want Apple to allow the WebKit team to raise its game so there is an *excellent* competitor to Chromium.

WebKit is available on Windows, Linux and more. Safari was once available on Windows, but Apple silently withdrew it. SVP of software Eddy Cue, who reports directly to Tim Cook, wrote in 2013

The reason we lost Safari on Windows is the same reason we are losing Safari on Mac. We didn’t innovate or enhance Safari….We had an amazing start and then stopped innovating… Look at Chrome. They put out releases at least every month while we basically do it once a year.

There is browser choice on MacOS, and 63% of MacOS users remain with Safari (24% use Chrome, 5.6% use Firefox). As everyone who works on browsers knows, a capable browser made by the Operating System’s manufacturer and pre-installed greatly deters users from seeking and installing another. There is no reason to believe it would be different on iOS. (Internet Explorer on Windows isn’t a counter-example; there were much better alternatives, long before Edge came along.)

But let’s set out aspirations higher. Imagine a fantastic Safari on iOS, Mac, Windows and Linux, giving Chrome a run for its money. If anyone can take on Google, Apple can. It has talented WebKit engineers, excellent Standards experts, a colossal marketing budget, and great brand recognition.

If Apple allowed Safari to actually compete, it would be better for web developers, businesses, consumers, and for the health of the web. Come on, Apple, set Safari free!

(You could also read my Briefing to the UK Competition and Markets Authority on Apple’s iOS browser monopoly and Progressive Web Apps.)

The biggest missing feature in the manifesto for agile software development and the principles behind it is anyone other than the makers and their customer. We get autonomous, self-organising delivery teams but without the sense of responsibility to a broader society one would expect from autonomous professional agents.

Therefore it’s no surprise to find developers working to turn their colleagues into a below-minimum-wage precariat; to rig elections at scale; or to implement family separation policies or travel bans on religious minorities. A principled agile software developer only needs to ask “how can I deliver this, early and continuously, to the customer?” and “how can we adjust our behaviour to become more effective at this?”: they do not need to ask “is this a good idea?” or “should this be delivered at all?”

Principle Zero ought to read something like this.

We build software that transforms the workplace, leisure, interpersonal interaction, and society at large: we do so in consultation with as broad a representation of those interests as possible and ensure that our software is beneficial to those whose lives are being transformed. Within that context, we follow these principles:

I know that there are bigger problems to discuss about Apple’s approach to business and partnerships at the mo, but their handling of security researchers seems particularly cynical and hypocritical. See, for example, this post about four reported iPhone 0days that went ignored and the nine other cases linked in that article.

Apple advertise themselves as the privacy company. By this, they really mean that their products are designed to share as much of your data with Apple as they are comfortable with, and that beyond that you should probably assume that nobody else is involved. But their security development lifecycle tells another story.

“Wait, did you just pivot from talking about privacy to security?” No! You can have security without privacy: this blog has that, on a first glance. All of the posts and pages are public, anybody can read them, but I want to make sure that what you read is actually what I wrote (the integrity of the posts) and that nothing stops you from reading it when you want (the availability). On a closer examination, I also care that there are things you don’t have access to: any of the account passwords, configuration settings, draft posts, etc. So in fact the blog has privacy requirements too, and those are handled in security by considering and protecting the confidentiality of those private assets. You can have security without privacy, but not privacy without security.

Something, I’m not sure what from the outside, is wrong with the security development lifecycle at Apple. As a privacy-focused company they should also be a security-focused company, but they evidently never had the same “trustworthy computing” moment that Microsoft did. I’m not going to do any kind of deep dive into CVE counts here, just provide the following high-level support for the case that Apple is, at best, doing no better than anybody else in the industry at this.

• Gil Shwed on the threats on iOS and Android being roughly balanced
• Android vulnerabilities command a premium over iOS (2019)
• Xcode 13 Server fixes multiple vulnerabilities by updating nginx. I include this to show that Apple are not taking the lead on infosec: they are incorporating vulnerable third-party components and fixes from upstream sources.

Meanwhile, they fail to acknowledge external contributors to their product security, do not pay out agreed bounties, and sue security researchers or ban them from their store. Apple say that the bounty program has doubled in 2019-2020 and continues to grow. You could say that maybe they aren’t doing any better, but they certainly aren’t doing any worse. Every new product announcement, senior managers at Apple up to their CEO tell everyone how great they are at privacy. Their intent is that people believe they are doing the best at this, when they are around the middle of the pack. This is disingenuous.

A bug bounty program is a security process of last resort. You didn’t design, implement, or fix flaws out of your product before it got to customers and attackers: and that happens, that’s fine, but these escapee threats that are realised as vulnerabilities should be a small fraction of the total possible problems, and the lower severity ones at that. You also didn’t detect it yourself once the customers and attackers had access to the product: that also happens and is fine, but again the vulnerabilities that escape your detection should be the lowest down the stack. Once someone else is discovering your vulnerabilities, the correct thing to do is to say thank you for bringing this to our attention before exploiting it yourself, here is compensation for the time and work you put into making our product better.

Apple is not doing this. As seen from the various linked stories above, they are leaving security researchers with a bitter taste and a questioning feeling over whether they would want to work with Apple again, but not doing the heavy lifting to ensure their SDLC catches the highest-severity problems on campus, before or after release. I don’t know what is at fault here, but I expect it’s systemic rather than individual leader/department/activity. The product security folks at Apple are good at their jobs, the software engineers are good at their jobs…and yet here we are.

I suspect a certain amount of large-company effect is at play. “As Tim told you, our products are best in class for privacy,” says anonymous and fictional somewhat high up marketing person, “and if you had any specific complaint I couldn’t hear it over all the high-volume stock cash register sound effects we play in the board room to represent our success in the marketplace.”

I was having a think about this short history of Objective-C, and it occurred to me that perhaps I had been thinking about ObjC wrong. Now, I realise that by thinking about ObjC at all I mark myself out as a bit of an oddball, but I do it a lot. I co-host the [objc retain]; stream with Steven Baker, discussing cross-platform free software Objective-C every week. Hell of a time to realise I’ve been doing it wrong.

My current thinking is that the idea of ObjC is not to write “apps” in ObjC, or even in successor languages (sorry, fans of successor languages). Summed up in that history are Brad Cox’s views which you can read in more length in his books. I’ve at least tangentially covered each book here: Object-Oriented Programming: an Evolutionary Approach and Superdistribution: Objects as Property on the Electronic Frontier. In these he talks about Object-Oriented Programming as the “software industrial revolution”, in which the each-one-is-bespoke way of writing software from artisinally-selected ones and lightly-sparkling zeroes is replaced with a catalogue of re-usable parts, called Software ICs (integrated circuits). As an integrator, I might take the “window” IC, the “button” IC, the “text field” IC, and a “data store” IC and make a board for entering expenses.

So far, so npm. The key bit is the next bit. As a computer owner, you might take that board and integrate it into your computer so that you can do your home finances, or so that you can submit your business expense claims, or so that your characters in The Sims can claim for their CPU time, or all three of those things. The key is that this isn’t some app developer, this is the person whose computer it is.

From that perspective, Objective-C is an intermediary tool, and not a particularly important or long-lasting one. Its job is to turn legacy code into objects so that it can be accessed by people using their computers by sticking software together using objects (hello NSFileManager). To the extent it has an ongoing job, that is to turn algorithms into objects, for the same reason (but the algorithms have been made out of not-objects, because All Hail the Perform Ant).

You can make your software on your computer by glueing objects together, whether they’re made of ObjC (a common and important case), Eiffel (an uncommon and important case), Smalltalk (ditto) or whatever. Objective-C is the shiny surface we’re missing over the tar pit. It is the gear system on the bicycle for the mind; the tool that frees computer users from the tyranny of the app vendor and the app store.

I apologise for taking this long to work that out.

(Last Updated on 30 September 2021)

I watched this week’s Apple Event for a while, but there was nothing that interested me; I have a mobile phone which works fine for me, I don’t need a watch and I can’t afford a new computer.

But here’s one Apple event speech I genuinely found really energising. In 2007, Steve Jobs made a bold announcement at Apple’s developer conference, that I still find inspiring today:

On open Operating Systems, Progressive Web Apps live up to this promise; truly cross-platform code that can be responsive to any form factor, using a mature technology with great accessibility (assuming a competent developer), that is secure and sandboxed, that requires no gatekeepers, developer licenses or expensive IDEs. They’ll work on Android, Windows, ChromeOS and Mac.

But 14 years after Jobs had this bold vision for the open web, iOS hasn’t caught up. Apple has imposed a browser ban on iOS. Yes, there are “browsers” called Chrome, Edge, Firefox that can be downloaded from the App Store for iOS–but they only share branding and UI features with their fully-fledged counterparts on open Operating Systems. On iOS, they are all just differently-badged skins for the buggy, hamstrung version of WebKit that Apple ships and occasionally patches for security (often waiting long after WebKit has been fixed before pushing it to consumers).

Apple knows Safari is terrible. SVP of software Eddy Cue, who reports directly to Tim Cook, wrote in 2013

The reason we lost Safari on Windows is the same reason we are losing Safari on Mac. We didn’t innovate or enhance Safari….We had an amazing start and then stopped innovating… Look at Chrome. They put out releases at least every month while we basically do it once a year.

Forcing other iOS “browsers” to skin Safari’s engine rather than use their own more capable engines is a deliberate policy decision. Apple’s App Store guidelines state

Apps that browse the web must use the appropriate WebKit framework and WebKit Javascript.

Job’s 2007 speech felt like a turning point: a successful, future-facing company really betting on the open web. These days, Apple sells you hardware that they claim will “express your individuality” by choosing one of two brand new colours. But, for the web, choose any colour you want, as long as it’s webkit-black.

Some of us are trying to change this. Earlier this month I was part of a small group invited to brief the UK regulator, the Competition and Marketing Authority, as part of its investigation into

Apple’s conduct in relation to the distribution of apps on iOS and iPadOS devices in the UK, in particular, the terms and conditions governing app developers’ access to Apple’s App Store.

You can watch the video of my presentation, and see Stuart Langridge’s slides.

Words interest me. As I’ve been getting interested in green woodworking and the appropriate tools, I’ve become more aware of the US term “shop”. A few days ago, in a discussion of why America is lagging behind on lower level tech education, someone suggested schools needed to reintroduce ‘shop’, to get kids interested in designing and making things. I think young Brits would know this as ‘Design Technology, Resistive Materials’. I did ‘Woodwork’ and ‘Metalwork’.

America takes its cars ‘to the shop’ because their ‘garages’ are being used as ‘car parks’. Obviously, it means ‘workshop’.  A shop where you buy work, a service instead of a product, as you walk down main street. Not at all like a job-shop in Britain where we try to sell spare labour to employers, or shop for jobs, if you prefer.

I came across a meaning from the world of share trading. A stock may be ‘shopped’ – actively sold. I think we’re finally getting to the meaning. A shop is a place (real or virtual) where goods, services and labour are traded, in either direction. A market stall. I almost wrote “store” but stores are where you keep things before selling our when they haven’t sold.

I was slightly side-tracked by coppers, copping criminals and taking them to the cop shop, trading their liberty for their crimes. My government assures me that if I haven’t committed a crime I won’t cop it. I wish I believed them. That’s the cost of lying in a market that depends on trust and information. Their share price is down.

(Last Updated on 30 September 2021)

On 4 March this year, the UK Competition and Markets Authority announced that it is

investigating Apple’s conduct in relation to the distribution of apps on iOS and iPadOS devices in the UK, in particular, the terms and conditions governing app developers’ access to Apple’s App Store.

Submissions from the public were invited, so I replied and was invited, with “Clark Kent” (a UK iOS Web-Apps developer who wishes to be anonymous) and Stuart Langridge to brief the CMA in more detail. We were asked to attend for 2 hours, so spoke for one hour, and then took questions.

CMA are happy for our presentations to be published (they’re eager to be seen to be engaging with developers) but asked that the questions be kept private. Suffice it to say that the questioning went over the allocated time, and showed a level of technical understanding of the issues that surpasses many engineers. (The lawyers and economists knew, for example, that iOS browsers are all compelled to use WebKit under the hood, so Chrome/ Firefox/ Edge on iOS share only a name and a UI with their fully-fledged real versions on all other Operating Systems).

Clark’s presentation

Clark talked of how Steve Jobs’ 2007 announcement of apps for iPhone inspired him to use his webdev skills to make iOS web-apps.

you can write amazing Web 2.0 and Ajax apps that look exactly and behave exactly like apps on the iPhone. And these apps can integrate perfectly with iPhone services … And guess what? There’s no SDK that you need! You’ve got everything you need if you know how to write apps using the most modern web standards to write amazing apps for the iPhone today.

Unfortunately, Safari’s bugs made development much more expensive by breaking Indexed DB; breaking scrolling etc. Also, Apple refuses to support Web Bluetooth, so his customers had to purchase expensive iOS-compatible printers for printing receipts, at 11 times the cost of Bluetooth printers. iOS apps can integrate with Bluetooth, however.

He can’t ask his customers to jettison their iPads and buy Android tablets. Neither can he ask them to use an alternative browser, because there isn’t any meaningful choice on iOS. Clark simply wants to be able to make “amazing Web 2.0 and Ajax apps that look exactly and behave exactly like apps on the iPhone”, as Jobs promised. He summed up:

All these business costs inevitably get passed onto consumers. Or worse applications simply never get built, due to the increased cost.

From the perspective of software developers there is no browser competition on iOS.

Apple has banned all the other browser engines and Safari’s bugs and missing features means that web-apps struggle to compete with the AppStore. If third party browsers were allowed, with full access to all the APIs that Apple gives Safari, this would provide Apple the incentive to keep pace with the other browsers and give consumers a means of voting with their feet by moving to a competing browser if they fail to do so.

This would then lead to a universal open app development and distribution platform which would substantially reduce development and maintenance costs for a wide range of business and consumer applications. The open web offers an alternative future where the control from corporate intermediaries along with their fees are replaced with consumer choice and the freedom to easily shift from one platform to another. Instead of having to write multiple separate applications for every device, it allows developers to build their application once and have it work on all consumer devices be it desktop, laptop, tablet or phone.

Write once, deploy everywhere, no gatekeepers, no fees. just as Steve Jobs originally promised.

Stuart’s presentation

Stuart examined whether Apple’s assertion that lack of real browser diversity is actually better for consumers’ privacy and security.

My presentation

Here’s my captioned video. Below is the marked-up transcript with links. Note: this submission is my personal opinion and does not represent the opinion of any of my past or present clients or employers.

Last week I was part of a meeting with the UK’s Competition and Markets Authority, the regulator, to talk about Apple devices and the browser choice (or lack of it) on them. They’re doing a big study into Apple’s conduct in relation to the distribution of apps on iOS and iPadOS devices in the UK, in particular, the terms and conditions governing app developers’ access to Apple’s App Store, and part of that involves looking at browsers on iOS, and part of that involves talking to people who work on the web. So myself and Bruce Lawson and another UK developer of iOS and web apps put together some thoughts and had a useful long meeting with the CMA on the topic.

They asked that we keep confidential the exact details of what was discussed and asked, which I think is reasonable, but I did put together a slide deck to summarise my thoughts which I presented to them, and you can certainly see that. It’s at kryogenix.org/code/cma-apple and shows everything that I presented to the CMA along with my detailed notes on what it all means.

Bruce had a similar slide deck, and you can read his slides on iOS’s browser monopoly and progressive web apps. Bruce has also summarised our other colleague’s presentation, which is what we led off with. The discussion that we then went into was really interesting; they asked some very sensible questions, and showed every sign of properly understanding the problem already and wanting to understand it better. This was good: honestly, I was a bit worried that we might be trying to explain the difference between a browser and a rendering engine to a bunch of retired colonel types who find technology to be baffling and perhaps a little unmanly, and this was emphatically not the case; I found the committee engaging and knowledgeable, and this is encouraging.

In the last few weeks we’ve seen quite a few different governments and regulatory authorities begin to take a stand against tech companies generally and Apple’s control over your devices more specifically. These are baby steps — video and music apps are now permitted to add a link to their own website, saints preserve us, after the Japan Fair Trade Commission’s investigation; developers are now allowed to send emails to their own users which mention payments, which is being hailed as “flexibility” although it doesn’t allow app devs to tell their users about other payment options in the app itself, and there are still court cases and regulatory investigations going on all around the world. Still, the tide may be changing here.

What I would like is that I can give users the best experience on the web, on the best mobile hardware. That best mobile hardware is Apple’s, but at the moment if I want to choose Apple hardware I have to choose a sub-par web experience. Nobody can fix this other than Apple, and there are a bunch of approaches that they could take — they could make Safari be a best-in-class experience for the web, or they could allow other people to collaborate on making the browser best-in-class, or they could stop blocking other browsers from their hardware. People have lots of opinions about which of these, or what else, could and should be done about this; I think pretty much everyone thinks that something should be done about it, though. Even if your goal is to slow the web down and to think that it shouldn’t compete with native apps, there’s no real reason why flexbox and grid and transforms should be worse in Safari, right? Anyway, go and read the talk for more detail on all that. And I’m interested in what you think. Do please hit me up on Twitter about this, or anything else; what do you think should be done, and how?

Last week I sat down with the UK Competition and Markets Authority to talk about browser choice on Apple devices, and whether the claims that limiting choice is good for security and privacy actually hold up. Here's the presentation I gave.https://t.co/7i35fwdnrM

— Stuart Langridge (@sil) September 6, 2021

• Link o’ the Week: iOS Engine Choice In Depth – Big Al doing his forensics on Apple’s disingenuousness.
• Australian watchdog considers regulating Apple and Google to boost app store competition = ” both companies faced very little competition in app distributions on their respective mobile platforms. The competition watchdog suggested the companies were stifling competition with their control over what apps could do on their platforms.”
• Russia slaps Apple with warning over abusing dominant market position – “it was cheaper to buy goods on a seller’s website… Apple gets a commission from 15% to 30% for each payment in the App Store, yet users are blocked from being informed about the possibility of purchases outside of it”
• After Apple rejections, FlickType gives up on popular iPhone keyboard for the blind – “Apple has thrown us obstacle after obstacle for years while we try to provide an app to improve people’s lives, and we can no longer endure their abuse.”
• Postcodes.io – Postcode & Geolocation API for the UK. Free, Open Source and based solely on Open Data
• A guide to designing accessible, WCAG-compliant focus indicators by Sara Soueidan
• Good stablecoins, a protocol for money, and digital wallets: the formula to fix our broken payment system. Hurrah! Facebook’s ZuckCoin is about to launch. And apparently, anyone who doesn’t love the idea of Facebook knowing all about your “money in the MetaVerse” (really!) is “profoundly unAmerican”.
• End of the line for Uber – Cory Doctorow on Uber’s probable demise. The saddest thing about Uber (and Airbnb) is they *could* have been good ideas if they actually were about real people’s spare capacity meeting some genuine excess demand. But (perhaps inevitably) they turned into hideous Silicon Valley monsters.
• Goodbye, Michael Jones, the man who gave the power of maps in our hands – Obituary of Michael Jones, the man behind Google Earth, and his mission to democratize maps.

There’s been a bit of a thing about software user experience going off the rails lately. Some people don’t like cross-platform software, and think that it isn’t as consistent, as well-integrated, or as empathetic as native software. Some people don’t like native software, thinking that changes in the design of the browser (Apple), the start menu (Microsoft), or everything (GNOME) herald the end of days.

So what’s going on? Why did those people make that thing that you didn’t like? Here are some possibilities.

My cheese was moved

Plenty of people have spent plenty of time using plenty of computers. Some short-sighted individual promised “a computer on every desktop”, made it happen, and this made a lot of people rather angry.

All of these people have learned a way of using these computers that works for them. Not necessarily the one that you or anybody else expects, but one that’s basically good enough. This is called satisficing: finding a good enough way to achieve your goal.

Now removing this satisficing path, or moving it a few pixels over to the left, might make something that’s supposedly better than what was there before, but is actually worse because the learned behaviour of the people trying to use the thing no longer achieves what they want.
It may even be that the original thing is really bad. But because we know how to use it, we don’t want it to change.

Consider the File menu. In About Face 3: The Essentials of Interaction Design, written in 2007, Alan Cooper described all of the problems with the File menu and its operations: New, Open, Save, Save As…. Those operations are implementation focused. They tell you what the computer will do, which is something the computer should take care of.

He described a different model, based on what people think about how their documents work. Anything you type in gets saved (that’s true of the computer I’m typing this in to, which works a lot like a Canon Cat). You can rename it if you want to give it a different name, and you can duplicate it if you want to give it a different name while keeping the version at the original name.

This should be better, because it makes the computer expose operations that people want to do, not operations that the computer needs to do. It’s like having a helicopter with an “up” control instead of a cyclic and collective controls.

Only, replacing the Open/Save/Save As… stuff with the “better” stuff is like removing the cyclic and collective controls and giving a trained helicopter pilot with years of experience the “up” button. It doesn’t work the way they expect, they have to think about it which they didn’t have to do with the cyclic/collective controls (any more), therefore it’s worse (for them).

Users are more experienced and adaptable now

But let’s look at this a different way. More people have used more computers now than at any earlier point in history, because that’s literally how history works. And while they might not like having their cheese moved, they’re probably OK with learning how a different piece of cheese works because they’ve been doing that over and over each time they visit a new website, play a new game, or use a new app.

Maybe “platform consistency” and “conform with the human interface/platform style guidelines” was a thing that made sense in 1984, when nobody who bought a computer with a GUI had ever used one before and would have to learn how literally everything worked. But now people are more sophisticated in their use of computers, regularly flit between desktop applications, mobile apps, and websites, across different platforms, and so are more flexible and adaptable in using different software with different interactions than they were in the 1980s when you first read the Amiga User Interface Style Guide.

We asked users; they don’t care

At first glance, this explanation seems related to the previous one. We’re doing the agile thing, and talking to our customers, and they’ve never mentioned that the UI framework or the slightly inconsistent controls are an issue.

But it’s actually quite different. The reason users don’t mention that there’s extra cognitive load is that these kinds of mental operations are tacit knowledge. If you’re asked about “how can we improve your experience filing taxes”, you’ll start thinking tax-related questions, before you think “I couldn’t press Ctrl-A to get to the beginning of that text field”. I mean, unless you’re a developer who goes out of their way to look for that sort of inconsistency in software.

The trick here is to stop asking, and start watching. Users may well care, even if they don’t vocalise that caring. They may well suffer, even if they don’t realise it hard enough to care.

We didn’t ask users

Yes, that happens. I’ve probably gone into enough depth on why it happens in various places, but here’s the summary: the company has a customer proxy who doesn’t proxy customers.

Respectable persons of this parish of Internet have been, shall we say, critical of Scrum and its ability to help makers (particularly software developers) to make things (particularly software). Ron Jeffries and GeePaw Hill have both deployed the bullshit word.

My own view, which I have described before, is that Scrum is a baseline product delivery process and a process improvement framework. Unfortunately, not many of us are trained or experienced in process improvement, not many of us know what we should be measuring to get a better process, so the process never improves.

At best, then, many Scrum organisations stick with the baseline process. That is still scadloads better than what many software organisations were trying before they had heard of Agile and Scrum, or after they had heard of it and before their CIO’s in-flight magazine made it acceptable. As a quick recap for those who were recruited into the post-Agile software industry, we used to spend two months working out all the tasks that would go into our six month project. Then we’d spend 15 months trying to implement them, then we’d all point at everybody else to explain why it hadn’t worked. Then, if there was any money left, we’d finally remember to ship some software to the customer.

Scrum has improved on that, by distributing both the shipping and the blaming over the whole life span of the project. This was sort of a necessary condition for software development to survive the dot-com crash, when “I have an idea” no longer instantly led to office space in SF, a foosball table, and thirty Herman Miller chairs. You have to deliver something of value early because you haven’t got enough money any more to put it off.

So when these respectable Internet parishioners say that Scrum is bad, this is how bad it has to be to reach that mark. Both of the authors I cite have been drinking from this trough way longer than I have, so have much more experience of the before times.

In this article I wanted to look at some of the things I, and software engineering peers around me, have done to make Scrum this bad. Because, as Ron says, Scrum is systemically bad, and we are part of the system.

Focus on Velocity

One thing it’s possible to measure is how much stuff gets shovelled in per iteration. This can be used to guide a couple of process-improvement ideas. First up is whether our ability to foresee problems arising in implementation is improving: this is “do estimates match actuals” but acknowledging that they never do, and the reason they never do is that we’re too optimistic all the time.

Second is whether the amount of stuff you’re shovelling is sustainable. This has to come second, because you have to have a stable idea of how much stuff there is in “some stuff” before you can determine whether it’s the same stuff you shovelled last time. If you occasionally shovel tons of stuff, then everybody goes off sick and you shovel no stuff, that’s not sustainable pace. If you occasionally shovel tons of stuff, then have to fix a load of production bugs and outages, and do a load of refactoring before you can shovel any more stuff, that’s not a sustainable pace, even if the amount of work in the shovelling phase and the fixing phase is equivalent.

This all makes working out what you can do, and what you can tell other people about what you can do, much easier. If you’re good at working out where the problems lie, and you’re good at knowing how many problems you can encounter and resolve per time, then it’s easier to make plans. Yes, we value responding to change over following a plan, but we also value planning our response to change, and we value communicating the impact of that response.

Even all of that relies on believing that a lot of things that could change, won’t change. Prediction and forecasting aren’t so chaotic that nobody should ever attempt them, but they certainly are sensitive enough to “all things being equal” that it’s important to bear in mind what all the things are and whether they have indeed remained equal.

And so it’s a terrible mistake to assume that this sprint’s velocity should be the same as, or (worse) greater than, the last one. You’re taking a descriptive statistic that should be handled with lots of caveats and using it as a goal. You end up doing the wrong thing.

Let’s say you decide you want 100 bushels of software over the next two weeks, because you shovelled 95 bushels of software last week. The easiest way to achieve that is to take things that you think add up to 100 bushels of software, and do less work so that they contain only, say, 78 bushels, and try to get those 78 bushels done in the time.

Which bits do you cut off? The buttons that the customer presses? No, they’ll notice that. The actions that happen when the customer presses the buttons? They’ll probably notice that, too. How about all the refinement and improvement that will make it possible to add another 100 bushels next time round? Nobody needs that to shovel this 100 bushels in!

But now, next time, shovelling software is harder, and you need to get 110 bushels in to “build on the momentum”. So more corners get cut, and more evenings get worked. And now it’s even harder to get the 120 bushels in that are needed the next time. Actual rate of software is going down, claimed rate of software is going up: soon everything will explode.

Separating “technical” and “non-technical”

Sometimes also “engineering” and “the business”. Particularly in a software company, this is weird, because “the business” is software engineering, but it’s a problem in other lines of business enabled by software too.

Often, domain experts in companies have quite a lot of technical knowledge and experience. In one fintech where I used to work, the “non-technical” people had a wealth (pun intended) of technical know-how when it came to financial planning and advice. That knowledge is as important to the purpose of making financial technology software as is software knowledge. Well, at least as important.

So why do so many teams delineate “engineering” and “the business”, or “techies” and “non-technical” people? In other words, why do software teams decide that only the software typists get a say in what software gets made using what practices? Why do people divide the world into pigs and chickens (though, in fairness to the Scrum folks, they abandoned that metaphor)?

I think the answer may be defensiveness. We’ve taken our ability to shovel 50 bushels of software and our commitment (it used to be an estimate, but now it’s a commitment) to shovel 120 bushels, and it’s evident that we can’t realistically do that. Why not? Oh it must be those pesky product owners, keep bringing their demands from the VP of marketing when all they’re going to do is say “build more”, “shovel more software”, and they aren’t actually doing any of it. If the customer rep didn’t keep repping the customer, we’d have time to actually do the software properly, and that would fix everything.

Note that while the Scrum guide no longer mentions chickens and pigs, it “still makes a distinction between members of the Scrum team and those individuals who are part of the process, but not responsible for delivering products”. This is an important distinction in places, but irrelevant and harmful in others. But it’s at its most harmful when it’s too narrowly drawn. When people who are part of the process are excluded from the delivering-products cabal. You still need to hear from them and use their expertise, even if you pretend that you don’t.

The related problem I have seen, and been part of, is the software-expertise people not even gaining passing knowledge of the problem domain. I’ve even seen it working on a developer tools team where the engineers building the tools didn’t have cause to use, or particularly even understand, the tool during our day-to-day work. All of those good technical practices, like automated acceptance tests, ubiquitous language, domain-driven design; they only mean shit if they’re helping to make the software compatible with the things people want the software for.

And that means a little bit of give and take on the old job boundaries. Let the rest of the company in on some info about how the software development is going, and learn a little about what the other folks you work with do. Be ready to adopt a more nuanced position on a new feature request than “Jen from sales with another crazy demand”.

Undriven process optimisation

As I said up top, the biggest problem Scrum often encounters in the wild is that it’s a process improvement framework run by people who don’t have any expertise at process improvement, but have read a book on Scrum (if that). This is where the agile consultant / retrospective facilitators usually come in: they do know something about process improvement, and even if they know nothing about your process it’s probably failing in similar enough ways to similar processes on similar teams that they can quickly identify the patterns and dysfunctions that apply in your context.

Without that guidance, or without that expertise on the team, retrospectives are the regular talking shop in which everybody knows that something is wrong, nobody knows what, and anybody who has a pet thing to try can propose that thing because there are no cogent arguments against giving it a go (nor are there any for it, except that we’ve got to try something!).

Thus we get resume-driven development: I bet that last sprint was bad because we aren’t functionally reactive enough, so we should spend the next sprint rewriting to this library I read about on medium. Or arbitrary process changes: this sprint we should add a column to the board, because we removed a column last time and look what happened. Or process gaming: I know we didn’t actually finish anything this month, but that’s because we didn’t deploy so if we call something “done” when it’s been typed into the IDE, we’ll achieve more next month. Or more pigs and chickens: the problem we had was that sales kept coming up with things customers needed, so we should stop the sales people talking either to the customers, to us, or to both.

Work out what it is you’re trying to do (not shovelling bushels of software, but the thing you’re trying to do for which software is potentially a solution) and measure that. Do you need to do more of that? Or less of it? Or the same amount for different people? Or for less money? What, about the way you’re shovelling software, could you change that would make that happen?

We’re back at connecting the technical and non-technical parts of the work, of course. To understand how the software work affects the non-software goals we need to understand both, and their interactions. Always have, always will.

In my experience, the best way to get a high-quality software product is to take your time, not crunch to some deadline. On one project I led, after a couple of months we realised that the feature goals (ALL of them) and the performance goals (also ALL of them, in this case ALL of the iPads back to the first-gen, single core 2010 one) were incompatible.

We talked to the customer, worked out achievable goals with a new timeline, and set to work with a new idea based on what we had found was possible. We went from infrequently running Instruments (the Apple performance analysis tool) to daily, then every merge, then every proposed change. If a change led to a regression, find another change. Customers were disappointed that the thing came out later than they originally thought, but it was still well-received and well-reviewed.

At the last release candidate, we had two known problems. Very infrequently sound would stop playing back, which with Apple’s DTS we isolated to an OS bug. After around 12 hours of uptime (in an iPad app, remember!) there was a chance of a crash, which with DTS we found to be due to calling an animation API in a way consistent with the documentation but inconsistent with the API’s actual expectations. We managed to fix that one before going live on the App Store.

On the other hand, projects I’ve worked on that had crunch times, weekend/evening working, and increased pressure to deliver from management ended up in a worse state. They were still late, but they tended to be even later and lower quality as developers who were under pressure to fix their bugs introduced other bugs by cutting corners. And everybody got upset and angry with everybody else, desperate to find a reason why the late project wasn’t my fault alone.

In one death march project, my first software project which was planned as a three month waterfall and took two years to deliver, we spent a lot of time shovelling bugs in at a faster rate than we were fixing them. On another, an angry product manager demanded that I fix bugs live in a handover meeting to another developer, without access to any test devices, then gave the resulting build to a customer…who of course discovered another, worse bug that had been introduced.

If you want good software, you have to sleep on it, and let everybody else sleep on it.

• Link ‘o the week: Safari isn’t protecting the web, it’s killing it – also featuring “Safari is killing the web through show-stopping bugs” eg, IndexedDB, localStorage, 100vh, Fetch requests skipping the service worker, and all your other favourites. Sort it out, NotSteve.
• Do App Store Rules Matter? – “half of the revenue comes from just 0.5% of the users … last year, Apple made $7-8bn in commission revenue from perhaps 5m people spending over $450 a quarter on in-app purchases in games. Apple has started talking a lot about helping you use your iPhone in more healthy ways, but that doesn’t seem to extend to the app store.”
• URL protocol handler registration for PWAs – Chromium 92 will let installed PWAs handle links that use a specific protocol for a more integrated experience.
• Xiaomi knocks Apple off #2 spot – but will it become the next Huawei? – “Chinese manufacturer Xiaomi is now the second largest smartphone maker in the world. In last quarter’s results it had a 17% share of global smartphone shipments, ahead of Apple’s 14% and behind Samsung’s 19%
• One-offs and low-expectations with Safari – “Jen Simmons solicited some open feedback about WebKit, asking what they might “need to add / change / fix / invent to help you?” … If I could ask for anything, it’d be that Apple loosen the purse strings and let Webkit be that warehouse for web innovation that it was a decade ago.” by Dave Rupert
• Concern trolls and power grabs: Inside Big Tech’s angry, geeky, often petty war for your privacy – “Inside the World Wide Web Consortium, where the world’s top engineers battle over the future of your data.
• Intent to Ship: CSS Overflow scrollbar-gutter – Tab Atkins explains “the space that a scrollbar *would* take up is always reserved regardless, so it doesn’t matter whether the scrollbar pops in or not. You can also get the same space reserved on the other side for visual symmetry if you want.”
• Homepage UX – 8 Common Pitfalls starring 75% with carousels implement them badly (TL;DR: don’t bother); 22% hide the Search field; 35% don’t implement country and language selection correctly; 43% don’t style clickable interface elements effectively
• WVG – Web Vector Graphics – a proof of concept spec from yer man @Hixie on a vector graphics format for Flutter (whatever that is). Interesting discussions on design decisions and trade offs.

$ docker container list -a

I noticed I had a large number of docker containers that weren’t being used. Fortunately docker makes it easy to single out a container from this list and remove all containers that were created before it.

docker ps -aq -f "before=widgets_web_run_32cb6f5d2d71" | xargs docker container rm

There are a bunch of handy filters that can be applied to docker ps. Nice for a bit of spring cleaning.

• Using CSS to Enforce Accessibility – remember: always listen to Uncle Adrian, kids.
• Another Big Win in the Domino’s Pizza Accessibility Saga – The judge issued an injunction ordering Domino’s to bring its website into compliance with WCAG 2.0, also ruled that Domino’s mobile app was covered by the ADA.
• Tota11y instructions – I’ve finally written (and lavishly illustrated!!) instructions for the Tota11y accessibility visualisation toolkit thingie I released on Global Accessibility Awareness Day
• prefers-reduced-motion and browser defaults by moi
• react-native-network-logger – An HTTP network request monitor for React Native with in-app interface for iOS and Android with no native code
• What’s NOT new in React 18
• CMA to scrutinise Apple and Google mobile ecosystems – If you develop apps for iOS/ Android, UK Competition & Markets Authority wants your input into its investigation on the monopoly (or not) of app stores & experience of web vs native. You can be anonymous (they know many are scared of retaliation).
• Amazon is blocking Google’s FLoC — and that could seriously weaken the fledgling tracking system
• Google delays Chrome’s cookie-blocking privacy plan by nearly 2 years -“Google is working on revisions to FLOC, too.”
• Apple argues against sideloading iPhone apps as regulatory pressure mounts
• EU’s Vestager warns Apple against using privacy, security to limit competition – Europe’s tech chief Margrethe Vestager on Friday warned iPhone maker Apple against using privacy and security concerns to fend off competition on its App Store, reasons CEO Tim Cook gave for not allowing users to install software from outside the Store.
• The Open-Source Software bubble that is and the blogging bubble that was – I’m wary of orgs that base all their tech on OSS but never seem to commit anything back or offer any financial support to the projects they rely on.
• OpenStreetMap looks to relocate to EU due to Brexit limitations – another win for ‘Global Britain’
• Crony Connect allows you to identify politically-connected individuals, using data from Companies House, the Electoral Commission and the MP’s Register of Financial Interests.
• LinkedIn breach reportedly exposes data of 92% of users, including inferred salaries

I’ve had a number of conversations about what “we” in the “free software community” “need” to do to combat the growth in proprietary, user-hostile and customer-hostile business models like cloud user-generated content hosts, social media platforms, hosted payment platforms, videoconferencing services etc. Questions can often be summarised as “what can we do to get everyone off of Facebook groups”, “how do we get businesses to adopt Jitsi Meet instead of Teams” or “how do we convince everyone that Mattermost is better for community chat than Slack”.

My answer is “we don’t”, which is very different from “we do nothing about those things”. Scaled software platforms introduce all sorts of problems that are only caused by trying to operate the software at scale, and the reason the big Silicon Valley companies are that big is that they have to spend a load of resources just to tread water because they’ve made everything so complex for themselves.

This scale problem has two related effects: firstly the companies are hyper-concerned about “growth” because when you’ve got a billion users, your shareholders want to know where the next hundred million are coming from, not the next twenty. Secondly the companies are overly-focused on lowest common denominator solutions, because Jennifer Miggins from South Shields is a rounding error and anything that’s good enough for Scott Zablowski from Los Angeles will have to be good enough for her too, and the millions of people on the flight path between them.

Growth hacking and lowest common denominator experiences are their problems, so we should avoid making them our problems, too. We already have various tools for enabling growth: the freedom to use the software for any purpose being one of the most powerful. We can go the other way and provide deeply-specific experiences that solve a small collection of problems incredibly well for a small number of people. Then those people become super-committed fans because no other thing works as well for them as our thing, and they tell their small number of friends, who can not only use this great thing but have the freedom to study how the program works, and change it so it does their computing as they wish—or to get someone to change it for them. Thus the snowball turns into an avalanche.

Each of these massive corporations with their non-free platforms that we’re trying to displace started as a small corporation solving a small problem for a small number of people. Facebook was internal to one university. Apple sold 500 computers to a single reseller. Google was a research project for one supervisor. This is a view of the world that’s been heavily skewed by the seemingly ready access to millions of dollars in venture capital for disruptive platforms, but many endeavours don’t have access to that capital and many that do don’t succeed. It is ludicrous to try and compete on the same terms without the same resources, so throw Marc Andreessen’s rulebook away and write a different one.

We get freedom to a billion people a handful at a time. That reddit-killing distributed self-hosted tool you’re building probably won’t kill reddit, sorry. Design for that one farmer’s cooperative in Skåne, and other farmers and other cooperatives will notice. Design for that one town government in Nordrhein-Westfalen, and other towns and other governments will notice. Design for that one biochemistry research group in Brasilia, and other biochemists and other researchers will notice. Make something personal for a dozen people, because that’s the one thing those massive vendors will never do and never even understand that they could do.

(Last Updated on 15 July 2021)

All the omens were there: a comet in the sky; birds fell silent; dogs howled; unquiet spirits walked the forests and the dark, empty places. Yes, it was a meeting request from Marketing to discuss a new product page with animations that are triggered on scroll.

Much as a priest grasps his crucifix when facing a vampire, I immediately reached for Intersection Observer to avoid the browser grinding to a halt when watching to see if something is scrolled into view. And, like an exoricst sprinkling holy water on a demon, I also cleansed the code with a prefers-reduced-motion media query.

prefers-reduced-motion looks at the user’s operating system settings to see if they wish to suppress animations (for performance reasons, or because animations make them nauseous–perhaps because they have a vestibular disorder). A responsible developer will check to see if the user has indicated that they prefer reduced motion and use or avoid animations accordingly.

Content images can be made to switch between animated or static using the &LTpicture> element (so brilliantly brought to you by a team of gorgeous hunks). Bradbury Frosticle gives this example:

<picture>
  <source srcset="no-motion.jpg" media="(prefers-reduced-motion: reduce)">
  <img srcset="animated.gif alt="brick wall"/>
</picture>

Now, obviously you are a responsible developer. You use alt text (and don’t call it “alt tags”). But unfortunately, not everyone is like you. There are also 639 squillion websites out there that were made before prefers-reduced-motion was a thing, and only 3 of them are actively maintained.

It seems to me that browsers could do more to protect their users. Browsers are, after all, user agents that protect the visitor from pop-ups, malicious sites, autoplaying videos and other denizens of the underworld. They should also protect users against nausea and migraines, regardless of whether the developer thought to (or had the tools available to).

So, I propose that browsers should never respect scroll-behavior: smooth; if a user prefers reduced motion, regardless of whether a developer has set the media query.

Animated GIFs (and their animated counterparts in more modern image formats) are somewhat more complex. Since 2018, the Chromium-based Vivaldi browser has allowed users to deactivate animated GIFs right from the Status Bar, but this isn’t useful in all circumstances.

My initial thought was that the browser should only show the first five seconds because WCAG Success Criterion 2.2.2 says

For any moving, blinking or scrolling information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it

But this wouldn’t allow a user to choose to see more than 5 seconds. The essential aspect of this success criterion is, I think, control. Melanie Richards, who does accessibility on Microsoft Edge browser, noted

IE had a neat keyboard shortcut that would pause any GIFs on command. I’d be curious to get your take on the relative usefulness of a browser setting such as you described, and/or a more contextual command.

I’m doubtful about discoverability of keyboard commands, but Travis Leithead (also Microsoft) suggested

We can use ML + your mic (with permission of course) to detect your frustration at forever looping Gifs and stop just the right one in real time. Or maybe just a play/pause control would help… +1 customer request!

And yes, a play/pause mechanism gives maximum control to the user. This would also solve the problem of looping GIFs in marketing emails, which are commonly displayed in browsers. There is an added complexity of what to do if the animated image is a link, but I’m not paid a massive salary to make web browsers, so I leave that to mightier brains than I possess.

In the meantime, until all browser vendors do my bidding (it only took 5 years for the <picture> element), please consider adding this to your CSS (by Thomas Steiner)

@media (prefers-reduced-motion: reduce) {
  *, ::before, ::after {
    animation-delay: -1ms !important;
    animation-duration: 1ms !important;
    animation-iteration-count: 1 !important;
    background-attachment: initial !important;
    scroll-behavior: auto !important;
    transition-duration: 0s !important;
    transition-delay: 0s !important;
  }
}

I am not an MBA, but it seems to me that making your users puke isn’t the best beginning to a successful business relationship.

• The hidden world of aria-hidden – Steveo Faulko reports “The effects of aria-hidden are not consistent across browsers and screen readers”. Seems like a Chrome bug to me.
• Bad Apple Safari update breaks IndexedDB JavaScript API, upsets web apps – Given Apple is currently pretending that it likes PWAs because of legal stuff, this would seem to be an accident rather than deliberate. And testing is hard, and Apple long gave up being a software company.
• Meet :has, A Native CSS Parent Selector (And More) (and Can I :has() – Uncle Brian explains this new exciting CSS thingy)
• Optical size, the hidden superpower of variable fonts – with mushroom examples.
• CMA to have key oversight role over Google’s planned removal of third-party cookies, also Privacy Sandbox – CMA oversight role and how to engage – video.
• Free, open source health icons
• Creating Accessible React Native Apps – some useful actionable advice here
• What my decade at Google taught me about Africa’s tech future
• My Life in the Apple Ecosystem – “But change is coming, whether or not Apple wants it. And boy, Apple deserves having those changes forced onto it, given how badly they’ve treated their developer community for so many years.”
• Huawei officially launches Android alternative HarmonyOS for smartphones – Yay, another not-Android (and not-Windows and not-Tizen and not-Ubuntu)

The latest in a series of posts on getting Unity Test Framework tests running in jenkins in the cloud, because this seems entirely undocumented.

To recap, we had got as far as running our playmode tests on the cloud machine, but we had to use the -batchmode -nographics command line parameters. If we don’t, we get tons of errors about non-interactive window sessions. But if we do, we can no longer rely on animation, physics, or some coroutines during our tests! This limits us to basic lifecycle and validation tests, which isn’t great.

We need our cloud machine to pretend there’s a monitor attached, so unity can run its renderer and physics.

First, we’re going to need to make sure we have enough grunt in our cloud machine to run the game at a solid frametate. We use ec2, with the g4dn.xlarge machine (which has a decent GPU) and the https://aws.amazon.com/marketplace/pp/prodview-xrrke4dwueqv6?ref=cns_srchrow#pdp-overview ami, which pre-installs the right GPU drivers.

To do this, we’re going to set up a non-admin windows account on our cloud machine (because that’s just good practice), get it to auto-login on boot and ask it to connect to jenkins under this account. Read on for more details.

First, set up your new windows account by remoting into the admin account of the cloud machine:

• type “add user” in the windows start menu to get started adding your user. I call mine simply “jenkins”. Remember to save the password somewhere safe!
• We need to be able to remote into the new user, so go to System Properties, and on the Remote tab click Select Users, and add your jenkins user

• if jenkins has already run on this machine, you’ll want to give the new jenkins user rights to modify the c:\Workspace folder
• You’ll also want to go into the Services app, find the jenkins service, and disable it.
• Next, download autologon https://docs.microsoft.com/en-us/sysinternals/downloads/autologon, uncompress it somewhere sensible, then run it.
  • enter your new jenkins account details
  • click Enable
  • close the dialog

Now, log out of the admin account, and you should be able to remote desktop into the new account using the credentials you saved.

Now we need to make this new account register the computer with your jenkins server once it comes online. More details here https://wiki.jenkins.io/display/JENKINS/Distributed+builds#Distributedbuilds-Agenttomasterconnections, and it may be a bit different for you depending on setup, but here’s what we do:

• From the remote desktop of the jenkins user account, open a browser and log into your jenkins server
• Go to the node page for your new machine, and configure the Launch Type to be Launch Agent By Connecting It To The Master
• Switch to the node’s status tab and you should have an orange button to download the agent jnlp file
• Put this file in the %userprofile%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup folder
• Change the Launch Type back to whatever you need (we use the Slave Setup plugin, despite the icky name https://plugins.jenkins.io/slave-setup/) — it doesn’t need to stay as Launch Agent By Connecting It To The Master.

We’re done. log out of remote desktop and reboot the machine. You should see it come alive in the jenkins server after a few minutes. If you remove the -batchmode and -nographics options from your unity commands, you should see the tests start to run with full physics and animation!

I’ve talked before about the non-team team dynamic that is “one person per task”. Where the management and engineers collude to push the organisation beyond a sustainable pace by making sure that at all times, each individual is kept busy and collaboration is minimised.

I talked about the deleterious effect on collaboration, particularly that code review becomes a burden resolved with a quick “LGTM”. People quickly develop specialisations and fiefdoms: oh there’s a CUDA story, better give it to Yevgeny as he worked on the last CUDA story.

The organisation quickly adapts to this balkanisation and optimises for it. Is there a CUDA story in the next sprint? We need something for Yevgeny to do. This is Conway’s Corrolary: the most efficient way to develop software is when the structure matches the org chart.

Basically all forms of collaboration become a slog when there’s no “us” in team. Unfortunately, the contradiction at the heart of this 19th century approach to division of labour is that, when applied to knowledge work, the value to each participant of being in meetings is minimised, while the necessity for each participant to be in a meeting is maximised.

The value is minimised because each person has their personal task within their personal fiefdom to work on. Attending a meeting takes away from the individual productivity that the process is optimising for. Additionally, it increases the likelihood that the meeting content will be mostly irrelevant: why should I want to discuss backend work when Sophie takes all the backend tasks?

The meetings are necessary, though, because nobody owns the whole widget. No-one can see the impact of any workflow change, or dependency adoption, or clean up task, because nobody understands more than a 1/N part of the whole system. Every little thing needs to be run by Sophie and Yevgeny and all the others because no-one is in a position to make a decision without their input.

This might sound radically democratic, and not the sort of thing you’d expect from a business: nobody can make a decision without consulting all the workers! Power to the people! In fact it’s just entirely progress-destroying: nobody can make a decision at all until they’ve got every single person on board, and that’s so much work that a lot of decisions will be defaulted. Nothing changes.

And there’s no way within this paradigm to avoid that. Have fewer meetings, and each individual is happier because they get to maximise progress time spent on their individual tasks. But the work will eventually grind to a halt, as the architecture reflects N different opinions, and the N! different interfaces (which have each fallen into the unowned gaps between the individual contributors) become harder to work with.

Have more meetings, and people will grumble that there are too many meetings. And that Piotr is trying to land-grab from other fiefdoms by pushing for decisions that cross into Sophie’s domain.

The answer is to reconstitute the team – preferably along self-organising principles – into a cybernetic organism that makes use of its constituent individuals as they can best be applied, but in pursuit of the team’s goals, not N individual goals. This means radical democracy for some issues, (agreed) tyranny for others, and collective ignorance of yet others.

It means in some cases giving anyone the autonomy to make some choices, but giving someone with more expertise the autonomy to override those choices. In some cases, all decisions get made locally, in others, they must be run past an agreed arbiter. In some cases, having one task per team, or even no tasks per team if the team needs to do something more important before it can take on another task.

I’m doing some accessibility testing on a React Native codebase that uses Expo during development. If you’ve done something seriously wrong in a previous life and karma has condemned you to using React Native rather than making a Progressive Web App, Expo is jolly useful. It gives you a QR code that you can scan with Android or iOS to ‘install’ the app on your device and you get live reload of any changes. It’s like sinking in a quagmire of shit but someone nice is bringing you beer and playing Abba while it happens. (Beats me why that isn’t their corporate strapline.)

Anyway, I struggled a bit to set it up so here are some random tips that I learned the hard way:

• If your terminal yells “Error: EMFILE: too many open files, watch at FSEvent.FSWatcher._handle.onchange (internal/fs/watchers.js:178:28) error Command failed with exit code 1” when you start Expo, stop it, do brew install watchman and re-start Expo. Why? No idea. Someone from StackOverflow told me. Most npm stuff is voodoo magic–just install all the things, hope none of them were made by in Moscow by Vladimir Evilovich of KGB Enterprises, ignore all the deprecation warnings and cross your fingers.
• If you want to open your app in an iOS simulator, you need xcode and you need to install xcode command line tools or it’ll just hang.
• Scrolling in iOS simulator is weird. Press the trackpad with one hand and scroll with other hand. Or enable three finger drag and have one hand free for coffee, smoking or whatever other filthy habits you’ve developed while working from home.
• If you don’t want it, you can turn off the debugging menu overlay.
• If you like CSS, under no circumstances view source of the app running in the browser. It is, however, full of lots of ARIA nourishment thanks to React Native for Web.

Who knows? One day, Apple may decide not to hamstring PWAs on iOS and we can all use the web to run on any device and any browser, just as Sir Uncle Timbo intended.

It was requested on twitter that I start answering community questions on the podcast. I’ve got a few to get the ball rolling, but what would you like to ask? Comment here, or reach me wherever you know I hang out.