Pac-Man: The Untold Story of How We Really Played The Game

This is a repost promoting content originally published elsewhere. See more things Dan's reposted.

Unrestored Pac-Man machine with worn paint in a specific place on the left-hand side.

Human beings leave physical impressions upon the things they love and use just as much as their do upon the lives of people and the planet they live upon. For every action, there’s a reaction. For every pressure, there’s an affect on mass and volume. And in the impressions left by that combination, particularly if you’re lucky enough to see the sides of a rare, unrestored  vintage Pac-Man cabinet, lies the never before told story of how we really played the game.

Until now, I don’t believe anyone has ever written about it.

Interesting exploration of the history of the cabinets housing Pac-Man, observing the ergonomic impact of the controls on the way that people would hold the side of the machine and, in turn, how that would affect where and how the paint would wear off.

I love that folks care about this stuff.

The Ball and The Box

This is a repost promoting content originally published elsewhere. See more things Dan's reposted.

Thread by @LaurenHerschel: “After what has been a surprisingly okayish Christmas, I had a moment today in SuperStore. Saw a lady who reminded me of my 92yo grandma, who […]” (threadreaderapp.com)

Thread by @LaurenHerschel: “After what has been a surprisingly okayish Christmas, I had a moment today in SuperStore. Saw a lady who remindedndma, who even in the early stages of dementia, completely understood that my mom died. I thought I’d share t […]”

After what has been a surprisingly okayish Christmas, I had a moment today in SuperStore. Saw a lady who reminded me of my 92yo grandma, who even in the early stages of dementia, completely understood that my mom died.
I thought I’d share the Ball in the Box analogy my Dr told me
So grief is like this:
There’s a box with a ball in it. And a pain button.
And no, I am not known for my art skills.
In the beginning, the ball is huge. You can’t move the box without the ball hitting the pain button. It rattles around on its own in there and hits the button over and over. You can’t control it – it just keeps hurting. Sometimes it seems unrelenting.
Over time, the ball gets smaller. It hits the button less and less but when it does, it hurts just as much. It’s better because you can function day to day more easily. But the downside is that the ball randomly hits that button when you least expect it.
For most people, the ball never really goes away. It might hit less and less and you have more time to recover between hits, unlike when the ball was still giant.
I thought this was the best description of grief I’ve heard in a long time.
I told my step dad about the ball in the box (with even worse pictures). He now uses it to talk about how he’s feeling.
“The Ball was really big today. It wouldn’t lay off the button. I hope it gets smaller soon.”
Slowly it is.

Minimal Google Analytics Snippet

This is a repost promoting content originally published elsewhere. See more things Dan's reposted.

<script>
(function(a,b,c){var d=a.history,e=document,f=navigator||{},g=localStorage,
h=encodeURIComponent,i=d.pushState,k=function(){return Math.random().toString(36)},
l=function(){return g.cid||(g.cid=k()),g.cid},m=function(r){var s=[];for(var t in r)
r.hasOwnProperty(t)&&void 0!==r[t]&&s.push(h(t)+"="+h(r[t]));return s.join("&")},
n=function(r,s,t,u,v,w,x){var z="https://www.google-analytics.com/collect",
A=m({v:"1",ds:"web",aip:c.anonymizeIp?1:void 0,tid:b,cid:l(),t:r||"pageview",
sd:c.colorDepth&&screen.colorDepth?screen.colorDepth+"-bits":void 0,dr:e.referrer||
void 0,dt:e.title,dl:e.location.origin+e.location.pathname+e.location.search,ul:c.language?
(f.language||"").toLowerCase():void 0,de:c.characterSet?e.characterSet:void 0,
sr:c.screenSize?(a.screen||{}).width+"x"+(a.screen||{}).height:void 0,vp:c.screenSize&&
a.visualViewport?(a.visualViewport||{}).width+"x"+(a.visualViewport||{}).height:void 0,
ec:s||void 0,ea:t||void 0,el:u||void 0,ev:v||void 0,exd:w||void 0,exf:"undefined"!=typeof x&&
!1==!!x?0:void 0});if(f.sendBeacon)f.sendBeacon(z,A);else{var y=new XMLHttpRequest;
y.open("POST",z,!0),y.send(A)}};d.pushState=function(r){return"function"==typeof d.onpushstate&&
d.onpushstate({state:r}),setTimeout(n,c.delay||10),i.apply(d,arguments)},n(),
a.ma={trackEvent:function o(r,s,t,u){return n("event",r,s,t,u)},
trackException:function q(r,s){return n("exception",null,null,null,null,r,s)}}})
(window,"XX-XXXXXXXXX-X",{anonymizeIp:true,colorDepth:true,characterSet:true,screenSize:true,language:true});
</script>

This is cute: a Google Analytics code snippet that results in a payload about a fiftieth of the size of the one provided by Google but still provides most of the important features.

You probably don’t need a single-page application

This is a repost promoting content originally published elsewhere. See more things Dan's reposted.

The meteoric rise of front-end frameworks like React, Angular, Vue.js, Elm, etc. has made single-page applications ubiquitous on the web. For many developers, these have become part of their ‘default’ toolset. When they start a new project, they grab the tools they know already: a REST API on the backend, and a React/Angular/Vue/Elm frontend.

Is there something wrong with these tools? Absolutely not. In fact, I love working with them. However, I would only choose this architecture when an actual requirement is pushing me in that direction. If there are no specific reasons to build a single-page application, I will go with a traditional server-rendered architecture every day of the week. It is simpler and allows you to move faster.

There’s been an increasing trend towards delivering web applications as SPAs backed by an API. I can see the attraction: disposing of the browser’s navigation cycle lets you develop that coveted “app-like” interaction experience, pushing only data around lets you implement multiple clients backed by the same single middleware, and it results in a development workflow that fits tightly with many of the hippest frameworks (go jamstack, backendless, Node-backed, or whatever). I love REST and all, but I feel that it works best when it’s used to deliver multiformat results (whether by content negotiation or whatever): web pages for the humans, JSON or whatever for the computers.

For an increasing number of developers, SPAs are a golden hammer. Let’s fix that.

Post-it Note Affirmations and the Amazon Dash

This is a repost promoting content originally published elsewhere. See more things Dan's reposted.

The amazon dash is a pinnacle of modern web design. It’s one of the most intrusive, complex, and resource-dependent devices we’ve introduced into our homes, yet it appears as a simple oval with a single button for a single use. The use is absurdly narrow: the button will have a picture of Tide detergent, and when you press the button, Tide detergent is sent to your door.

Barely a week goes by between the times that I discover some horrifically over-engineered “solution” on the Internet. Amazon’s Dash buttons are terrible: disposable (plastic) single-purpose computers that could so easily have been made into something “more” – more-versatile, more-open, more-configurable, more-flexible. Indeed: people have been doing exactly that kind of thing! But the vanilla Dash button remains little more than selling you convenience (and not much convenience, if we’re honest) in exchange for more and more of your feeling of digital freedom. Yet another example of what replaced the Web we lost…

By hiding the technical processes, and simplifying the onboarding and engagement of their services, Amazon can continually reinforce your depression for a profit— and you can get name-brand laundry detergent faster.

Also, can I just take a moment to point out how awesome Zach’s website is. Not only is it the perfect example of how fun and weird the Internet can be and having a mixture of fascinating and curious content, it’s also available via dat:// for those of you who’ve got some love for the datbaseiverse.

Newtown bypass in Powys opens after 70-year wait

This is a repost promoting content originally published elsewhere. See more things Dan's reposted.

Town’s bypass opens after 70-year wait (BBC News)

It was 1949 when highways officials started to look at traffic issues affecting Newtown.

A multi-million pound bypass that has been 70 years in the planning officially opened in Powys on Thursday.

One haulier said Newtown bypass will make a “big difference” due to 45-minute hold-ups in the town, while the local AM said it was a “momentous” day.

The Welsh Government said the road will ease congestion by about 40% in the town centre.

A public notice printed in 1949 shows a bypass was being considered by the former Montgomeryshire County Council.

The four-mile (6.4km) road runs to the south of the town with two lanes in one direction and one in the opposite direction, to provide overtaking points.

Never thought I’d see the day. Back when she used to work in Newtown, Claire would routinely be delayed on her journey home by traffic passing through the town that could quite-justifiably have gone around it were it not for the lack of a decent trunk road, and she’d bemoan the continuing absence of the long-promised bypass. That was like 15 years ago… I can’t imagine what it’s been like for the people who’ve lived in Newtown, waiting for the bypass to be built, for their entire life.

In the time it’s taken to build this bypass, people who’ve been too young to drive have heard about it, grown up, had children of their own, and those people have had children who are now old enough to drive. The mind boggles.

Programming is just solving puzzles

This is a repost promoting content originally published elsewhere. See more things Dan's reposted.

‘Programming is just solving puzzles’ – Nominet (Nominet)

As a child, I wanted to be a botanical researcher. I loved being outdoors and used to visit the botanical gardens near my house all the time. My grandma inspired me to change my mind and helped me get interested in science. She lived in the country and we would look at the stars together,…

Ruth Trevor-Allen

As a child, I wanted to be a botanical researcher. I loved being outdoors and used to visit the botanical gardens near my house all the time. My grandma inspired me to change my mind and helped me get interested in science. She lived in the country and we would look at the stars together, which led to an early fascination in astronomy.

Unusually for the era, both my grandmothers had worked in science: one as a lab technician and one as a researcher in speech therapy. I have two brothers, but neither went into technology as a career. My mum was a vicar and my dad looked after us kids, although he had been a maths teacher.

My aptitude for science and maths led me to study physics at university, but I didn’t enjoy it, and switched to software engineering after the first year. As soon as I did my first bit of programming, I knew this was what I had been looking for. I like solving problems and building stuff that works, and programming gave me the opportunity to do both. It was my little eureka moment.

Wise words from my partner on her workplace’s blog as part of a series of pieces they’re doing on women in technology. Plus, a nice plug for Three Rings there (thanks, love!).

Shouldn’t We All Have Seamless Micropayments By Now?

This is a repost promoting content originally published elsewhere. See more things Dan's reposted.

Shouldn’t We All Have Seamless Micropayments By Now? (WIRED)

The web’s founders fully expected some form of digital payment to be integral to its functioning. But nearly three decades later, we’re still waiting.

Back in the 1990s, when Tim Berners-Lee and his team were creating the infrastructure of the World Wide Web, they made a list of the error codes that would pop up when something went wrong. You’ve surely encountered many of them: “404 Not Found,” which pops up if you click on a dead link; “401 Unauthorized” when you hit a page that needs a password; and so on.

Here’s one you probably haven’t seen—and its absence from your life speaks to why the promise of the early web seems increasingly out of reach: “402 Payment Required.”

That’s right: The web’s founders fully expected some form of digital payment to be integral to its functioning, just as integral as links, web pages, and passwords. After all, without a way to quickly and smoothly exchange money, how would a new economy be able to flourish online? Of course there ought to be a way to integrate digital cash into browsing and other activities. Of course.

Yet after almost three decades, that 402 error code is still “reserved for future use.” So I still have to ask: Where are my digital micropayments? Where are those frictionless, integrated ways of exchanging money online—cryptographically protected to allow commerce but not surveillance?

In response to this article being discussed on MetaFilter, I wrote:

The Web Payments Working Group published a specification for a standardised mechanism for the collection of card payment details online, a couple of years ago. It’s not quite the same thing because it’s done in the page application rather than at the HTTP(S) level, but it goes a long way towards solving a lot of the problems with our existing approach to payment processing online.

It’s already seeing adoption in browsers, but merchants and payment processors are unlikely to start rolling it out until adoption until later because (a) they want critical mass and (b) they’re wary of change. But within a few years, you’ll probably see it for the first time, and you might not even notice.

The idea is that instead of asking you to fill out an (arbitrary) form, a web page will ask your browser to get payment details from you in a standardised format. That might mean entering your card details if that’s how you prefer to work (but even if you choose to do this, the form you fill in will look the same every time) but it would instead allow you to use a payment tool built in to your browser, operating system, or password safe to do it for you. I know that browsers and password safes will offer to try to do this today, but standardising the format means that they’ll always be able to achieve it.

Once this technology’s in place, there’s nothing to stop HTTP 402’s implementation being completed: all the infrastructure will exist.

The thing about the future is that when it arrives, you don’t even notice. It’s never jetpacks and flying cars: it’s a series of iterative changes, each one predictable after the completion of the last but the entire ensemble seeming innovative and surprising when taken as a whole.

Let’s bring Fan Sites and webrings back!

This is a repost promoting content originally published elsewhere. See more things Dan's reposted.

Let’s bring Fan Sites and webrings back! – bryanlrobinson.com (bryanlrobinson.com)

In the days before the web was mainstream, it was a place of creation. First for education, then for every random idea that any creator had!

As the web transitioned from a network of educational institutions to the consumer force it is today, the early adopters were technologists… AKA geeks!

Promo image of various Fan Sites

A hallmark of geek culture is fandom – a deep knowledge of whatever topic interests them. This could be about a book, TV show, movie or band. With this passion comes a desire to share it with the world. Before the internet, there was no clear path. After the web started gaining traction, it was the biggest and easiest megaphone you could want.

It wasn’t always easy to be found, though. There was no search algorithm. Google was not ubiquitous with search. To be found, you needed to be listed on a site that aggregated other sites about your topic.

There was always a certain joy to a well-kept webring, back in the day. I’d love to see a return to this kind of “Indieweb dream”, but I don’t think that just wishing for it nor even telling people to go out and do it goes far enough, alone. Hopefully Bryan’s post will help nudge a few people in the right direction, though.

What If English Were Phonetically Consistent?

This is a repost promoting content originally published elsewhere. See more things Dan's reposted.

YouTube (youtube.com)

I’m reminded of an old joke (best read aloud), which I’ll repeat for your amusement:

The European Union commissioners have announced that agreement has been reached to adopt English as the preferred language for European communications, rather than German, which was the other possibility. As part of the negotiations, Her Majesty’s Government conceded that English spelling had some room for improvement and has accepted a five-year phased plan for what will be known as EuroEnglish (Euro for short).

In the first year, “s” will be used instead of the soft “c.” Sertainly, sivil servants will resieve this news with joy. Also, the hard “c” will be replaced with “k”. Not only will this klear up konfusion, but typewriters kan have one less letter.

There will be growing publik enthusiasm in the sekond year, when the troublesome “ph” will be replaced by “f”. This will make words like “fotograf” 20 persent shorter.

In the third year, publik akseptanse of the new spelling kan be expekted to reach the stage where more komplikated changes are possible. Governments will enkorage the removal of double letters, which have always ben a deterent to akurate speling. Also, al wil agre that the horible mes of silent “e”s in the languag is disgrasful, and they would go.

By the fourth year, peopl wil be reseptiv to steps such as replasing “th” by “z” and “w” by ” v”.

During ze fifz year, ze unesesary “o” kan be dropd from vords kontaining “ou”, and similar changes vud of kors be aplid to ozer kombinations of leters.

After zis fifz yer, ve vil hav a reli sensibl riten styl. Zer vil be no mor trubls or difikultis and evrivun vil find it ezi tu understand ech ozer.

Ze drem vil finali kum tru.