Paul Ford explains version control in a way that is clear and straightforward, while also being wistful and poetic.
I had idle fantasies about what the world of technology would look like if, instead of files, we were all sharing repositories and managing our lives in git: book projects, code projects, side projects, article drafts, everything. It’s just so damned … safe. I come home, work on something, push the changes back to the master repository, and download it when I get to work. If I needed to collaborate with other people, nothing would need to change. I’d just give them access to my repositories (repos, for short). I imagined myself handing git repos to my kids. “These are yours now. Iteratively add features to them, as I taught you.”
This looks like a terrific use of a Raspberry Pi—blocking adtech surveillance at the network level.
Wouldn’t it be great if the clichéd going-home-for-Christmas/Thanksgiving to fix the printer/wifi included setting up one of these?
There’s an article about Pi-hole in Business Week where the creators offer some advice for those who equate any kind of online advertising with ubiquitous surveillance:
For publishers struggling to survive even with maximum ad surveillance, the Pi-hole team recommends a renewed focus on subscriptions, affiliate links, and curated endorsements for products and services that might truly interest users, similar to the way podcast hosts may talk about how much they personally enjoy a sponsor’s products. There’s nothing wrong with pitching people stuff they might enjoy, the team says. It’s just the constant, ever-intensifying surveillance that needs to stop.
An interesting piece by Jessica Kerr that draws lessons from the histories of art and science and applies them to software development.
This was an interesting point about the cognitive load of getting your head around an existing system compared to creating your own:
And just because I’ve spent most of last year thinking about how to effectively communicate—in book form—relatively complex ideas clearly and simply, this part really stood out for me:
When you do have a decent mental model of a system, sharing that with others is hard. You don’t know how much you know.
The transcript of a terrific talk by Paul, calling for a more thoughtful, questioning approach to digital design. It covers the issues I’ve raised about Booking.com’s dark patterns and a post I linked to a while back about the shifting priorities of designers working at scale.
Drawing inspiration from architectural practice, its successes and failures, I question the role of design in a world being eaten by software. When the prevailing technocratic culture permits the creation of products that undermine and exploit users, who will protect citizens within the digital spaces they now inhabit?
Peter looks into his crystal ball for 2018 and sees computers with eyes, computers with ears, and computers with brains.
I like Richard’s five reminders:
- Just because the technology feels magic, it doesn’t mean making it understandable requires magic.
- Designers are going to need to get familiar with new materials to make things make sense to people.
- We need to make sure people have an option to object when something isn’t right.
- We should not fall into the trap of assuming the way to make machine learning understandable should be purely individualistic.
- We also need to think about how we design regulators too.
James talks about automation and understanding.
Just because a technology – whether it’s autonomous vehicles, satellite communications, or the internet – has been captured by capital and turned against the populace, doesn’t mean it does not retain a seed of utopian possibility.
Alan Kay’s initial description of a “Dynabook” written at Xerox PARC in 1972.
Are you the creator, programmer, or quality-tester of a podcasting application? This page provides a range of podcasts that exemplify a range of atypical use case from merely uncommon to exceedingly fringe. If your app can handle all these, you’re doing well.
The title is pure clickbait, and the moral panic early in this article repeats the Toyota myth, but then it settles down into a fascinating examination of abstractions in programming. On the one hand, there’s the problem of the not enough abstraction: having to write in code is such a computer-centric way of building things. On the other hand, our world is filled with dangerously abstracted systems:
When your tires are flat, you look at your tires, they are flat. When your software is broken, you look at your software, you see nothing.
So that’s a big problem.
Bret Victor, John Resig and Margaret Hamilton are featured. Doug Engelbart and J.C.R. Licklider aren’t mentioned but their spirits loom large.
Anecdotes about the development of Apple’s original Macintosh, and the people who made it.
Like a real-life Halt And Catch Fire.
A great bit of web history spelunking in search of the first websites that allowed users to interact with data on a server. Applications, if you will. It’s well written, but I take issue with this:
The world wide web wasn’t supposed to be this fun. Berners-Lee imagined the internet as a place to collaborate around text, somewhere to share research data and thesis papers.
This often gets trotted out (“the web was intended for scientists sharing documents”), but it’s simply not true that Tim Berners-Lee was only thinking of his immediate use-case; he deliberately made the WWW project broad enough to allow all sorts of thitherto unforeseen uses. If he hadn’t …well, the web wouldn’t have been able to accommodate all those later developments. It’s not an accident that the web was later used for all sorts of unexpected things—that was the whole idea.
Anyway, apart from that misstep, the rest of the article is a fun piece, well worth reading.
Tuukka Ojala is a programmer working on the web. He’s also blind. Here are the tools of his trade.
How the IETF redefined the process of creating standards.
To some visionary pioneers, such as Ted Nelson, who had been developing a purist hypertext paradigm called Xanadu for decades, the browser represented an undesirably messy direction for the evolution of the Internet. To pragmatists, the browser represented important software evolving as it should: in a pluralistic way, embodying many contending ideas, through what the Internet Engineering Task Force (IETF) calls “rough consensus and running code.”
The Internet Archive is now hosting early Macintosh software emulated right in your browser. That means you can play Adventure: the source of subsequent text adventures, natural language parsing, and chatbots.
Colossal Cave Adventure (also known as ADVENT, Colossal Cave, or Adventure) is a text adventure game, developed originally in 1976, by Will Crowther for the PDP-10 mainframe. The game was expanded upon in 1977, with help from Don Woods, and other programmers created variations on the game and ports to other systems in the following years.
In the game, the player controls a character through simple text commands to explore a cave rumored to be filled with wealth.
As part of an ongoing series where we ask industry professionals what they use to get the job done, we speak to Jeremy, technical director at Clearleft.
I couldn’t resist the smartarse answer about my “dream setup.”
A Mac app for converting PNGs and JPEGs to WebP.
A fascinating bit of technological archeology tracing some of the oldest still-running software, from a COBOL program at the Pentagon to the firmware on the Voyager probes.
Under the hood it’s the same Blink engine that power’s the regular Opera browser (and Chrome) but I really like the interface on this experiment. It’s described as being a “concept browser”, much like a “concept car”, which is a nice way of framing experiments like this. More concept browsers please!