Take

The minimal CMS and engine behind Take has gotten a few improvements along with minimal tweaks to the site look.

Particularly important to me, there is now a step which minimizes the HTML of all pages. The front page (which for me is slightly heavier since I'm logged in) now weighs in at 40 353 bytes for me, and contains 31 661 characters of text, for a 78.4% text-to-HTML density.

For comparison:

• Today's issue of the text-heavy (but also interactive-charts-heavy) Electoral-vote.com clocks in at ~9.8% (31 363 vs 320 055)

• Daring Fireball's latest full-text article page at ~47.6% (6 951 vs 14 602)

• CloudFlare's Medium-hosted How we made our page-load optimisations even faster at ~5.3% (13 196 vs 251 035)

(Play along home by running
[document.body.innerText.length, document.body.parentElement.outerHTML.length, (document.body.innerText.length / document.body.parentElement.outerHTML.length) * 100]
in the developer tools console of your browser.

Please be advised that this is in no way a useful representative measure of bloat since it completely disregards the potential freight train of externally included resources, and punishes links, tables and images. For me, now, it's a good measure of the whitespace-removing and HTML-simplifying minification process, and the rest is just in good fun.)

Ever since John Conway passed away, Eric Lippert has had a good series on the search for an efficient Game of Life algorithm. It's still ongoing and has already managed to touch on both SIMD and Michael Abrash.

I could do without the name, the dogma about precisely which effect is used and the desire to be "fresh", but as a step in the right direction away both from flatness and "Material Design", it is refreshing.

(via: Uninvited Redesign's link to Sangeeta Baishya's neumorphic Spotify redesign, which mostly looks pretty good but partly capsizes in Photoshop layer effects.)

You're about to spend the next 25 minutes watching a guy solve a Sudoku.

Not only that, but it's going to be the highlight of your day.

Ben Orlin is not wrong.

I don't have much aptitude for slowly unpicking crosswords or sudokus, but applying constraints and deductive reasoning and progressing towards an answer is a real high, and seeing how Simon solves this is riveting.

WSL was a strange beast in its first incarnation (the userspace bits from various distros interacting with a Linux translation layer in the NT kernel) and becomes stranger still in WSL2 where it becomes a Microsoft-blended Linux kernel shipped with Windows and maintained with Windows Update, atop which the userspace bits are run essentially in a container-like fashion.

Graphical applications are coming too, using a layer where RDP talks to Wayland (luckily, rather than X). And interestingly, DirectX 12 and lots of GPU-related machinery is being ported to run on Linux as part of this effort; largely to enable WSL features, but going further wouldn't be the strangest technical consequence of this project.

I still wouldn't want to rely on any Linux testing of neither command line nor desktop applications in this way, but there's an odd symmetry of incendiary grump that the same solution might provide both a decently modern command line on Windows and a decent desktop experience for Linux applications.

I used to write a bunch of software for what was then called Mac OS X. (It's a long story, but I'm personally responsible for the little controls you type a keyboard shortcut into sometimes being called "shortcut recorders".) Why did I stop?

I stopped because it was too much. I love the platform, I love the community, I love the sense that it's okay to care about details, I love the combination of a strong foundation that's not afraid to move forward and try new things. That gives you energy to do something, and it gives you ideas.

I've never been good at containing and managing that into a neat and healthy time allotment and a bounded investment of energy and emotion. Together with what my work asks of me, the things I do for my own personal use and the time I need to unwind from those other things, I had to drop it.

I've been reading about the pressures of open source maintainers for the past year or so, and I feel it. You want to put something out there to share, and some people – fine, good people with good intent – can turn it into a commitment that you only fulfill because you maintain an interest in it. If those pressures are reasonable, and if your life allows, you can do that, but it risks being turned from one of the highlights of your day into a downer, or even both simultaneously.

Making something for yourself, for friends, for people in the same situation you are, for kindred spirits that need to do something that's just too hard or inconvenient or troublesome – it can be an expression of who you are. It can be a balled-up gift of toil and thought and soul. It can make someone's day brighter and easier, and it can make you happier and filled with purpose. And it can also make you heart-achingly vulnerable, like a kid with a sandcastle, staring nervously at the waves, judging the strength of the winds against your skin.

I mentioned having an interest in gaming-related videos, and one of the biggest, strangest and diverse subcultures is certainly the one around Sonic.

A few years ago something interesting happened. Christian Whitehead, known in the community as The Taxman, came to an agreement with SEGA to revamp and re-release Sonic CD on iOS and Android. He did this using his own Retro Engine, with which he'd been making Sonic fan games for a number of years. This led into remasters of the original Sonic the Hedgehog as well as Sonic 2, and eventually also to him pitching a new game to them. That game became Sonic Mania.

Sonic Mania essentially continued the tangent of where Sonic was heading after the sibling installments of Sonic 3 and Sonic & Knuckles, and was better received than any Sonic title in recent memory – all the more impressive since SEGA's own attempts at following it up with the episodic Sonic 4 foundered, and recalling SEGA's walk in the wilderness with several cancelled projects after Sonic 3.

In both instances, SEGA tried to forget what had brought them there, or take something new and retrofit it. In the years after Sonic 3, they were caught up in a wave of consoles hastily making the transition to 3D spaces using still-early technology, and made the decision that continuing a 2D approach wouldn't work. And with Sonic 4, they tried to retro-fit the eventually occasionally successful 3D Sonic to the 2D formula, without paying attention to the dynamics that came to define not only the player's experience and memories but also how everything else had to be designed to interact well with Sonic's controls and the player.

I am about as nostalgic as you could be, but ever since Sonic Mania was released I've been waiting for the announcement of whatever comes next. Sonic Mania was announced as a one-off to honor fans and the series' own history (a task it performs admirably, the attention to detail and lore goes deep), but ended up demonstrating that the idea of the 2D Sonic games still worked (and with the DLC/physical release Sonic Mania Plus, that it was open to expanded mechanics).

In a world that works the way it should work, the minds behind Sonic Mania are now working not on Sonic Mania 2, but on the next step the original series would have taken, a game that isn't retro, but also not just re-painted with "assets" from more contemporary 3D-line Sonic titles. A game that tries to treat today's technology as something to be used in the way the original games approached then-current 16-bit technology, instead of as a crutch for reproducing the same old painting. A game that perfects the foundation and uses it to build a new and wondrous thing. A game that gets back in the driver's seat and gives the fans what they didn't yet know they wanted, instead of just paying homage to their obsession.

In order to make Sonic as great as it used to be, they need to be courageous enough to stop making Sonic the way it used to be.

Lots on the distinction between communication based in facts, numbers and statistics and in storytelling, how neither necessarily communicate truthfully or completely, and on how the brain is ill-equipped yet to gel the two.

Most of the controversy and opposing camps of the past few months has its source in one group being comfortable looking at things one way and not understanding another group's choice to look at it another way. My guess is that either group is made up mostly of people persuaded to that position, and that being able to communicate and connect on many planes is impactful.

Open Graph is a complete trainwreck, but is now a supported trainwreck.

An og:image is supposedly required for every page, but there's no defined or overwhelmingly common aspect ratio, and it's apparently not the end of the world if you leave it out for your front page, so I'm leaving it out for all pages since I wouldn't know what to put there. (I have ideas, but it would have to be customized to match the look of the site.)

Entry page loading should be just a little faster, since Markdown parsing and HTML conversion is done once when all entries are loaded instead of with every page load.

Incredibly impressive voice coding demo using Talon. Starts with the infamous "let's code Perl using the Vista speech recognition" video for even more contrast.

(via: Accidental Tech)

This is another good example to illustrate the previous entry's point. In this, he takes issue with the ungodly amount of "moon" collectibles and how it dilutes the worth and meaning and joy associated with it, which most fair-minded reviews would. Except that he also painstakingly catalogues every single moon and categorizes them. This is the opposite of rash and harsh commentary often left off the cuff – as recently explored by Mark Brown's Game Maker's Toolkit, another good watch.

I have a complicated relationship with them.

On the one hand, it's easy to look at them and say: wow, here are hundreds of videos retreading a game like Super Mario 64 most people who care about games have played and coming to largely the same conclusion.

On the other hand, it's not wrong to like something, nor is it necessary for large catalogues of human endeavor to be deduplicated. For each of these videos there has always been thousands of people thinking similar thoughts or holding fond memories in their head.

As an example, I have long appreciated how well-designed the Baby Mario bubble dynamic in Super Mario World 2: Yoshi's Island is. The sound of the baby is gut-wrenching and speaks to your instincts; after recovering from being stunned, Yoshi seems to lurch in the right direction; it's possible for the flying toadies that come to collect him to be delayed or prevented from approaching the bubble even though the countdown timer is at 0.

Thanks to videos like the ones I have been watching over the years, I have come to appreciate those details and think about game design in a way I surely wouldn't unless I designed games myself, even though I've been playing games all my life.

For similar reasons, the ongoing and surely accelerating death of magazine journalism is not the death of gaming journalism. "Democratization" is a common and worn-out term, but it's also imprecise – it's not so much that everyone can write a review but that we are able to be seeded with ideas and foundations of knowledge now like never before.

Many of the English language gaming magazines available to me when I grew up seemed more like rough-housing lad bibles that were most entertaining to the ten people on staff who understood all the in-jokes. Meanwhile, there are plenty of hour-long videos exploring the meaning, pacing, narrative, metaphysics, controls and so on of games; here's one about 2018's God of War. I don't mean to compare the message available in a 3 hour video vs a two-page spread, but I do mean to contrast that the desire for depth was often never really there in the old magazines, and I'd rather trust the guy who made the video than most classically designated game journalists.

In a way this is the positive side of the wonder of the Internet. For good and for bad, it connects people and lets them communicate. It can let misinformation, stereotypes and conspiracy theories flourish, with many consequences. But it can also be a positive force in deepening interest and knowledge and passion, which makes us stronger and happier and more fulfilled, and helps us on the way to fight the bad sides.

(And wouldn't you know that there are thoughtful deconstructions of those things too.)

I’m trying to figure out what bothers me. I think there are two things.

One is just that the App Store has always seemed rather arbitrary. The guidelines don’t even have to change for unseen policies to change, and it’s impossible to know in advance if a thing you’re doing will be okay and stay okay. (Recall that NetNewsWire has been doing the same thing with default feeds for 18 years.)

This gets really tiring, because every time we submit an app — even just a bug-fix release, like 5.0.1 is — I have to deal with the anxiety as I wonder what’s going to happen this time.

The other issue is a little harder to explain, but it goes like this:

If a site provides a public feed, it’s reasonable to assume that RSS readers might include that feed in some kind of discovery mechanism — they might even include it as a default. This is the public, open web, after all.

Now, if NetNewsWire were presenting itself as the official app version of Daring Fireball, for instance, then that would be dishonest. But it’s not, and that’s quite clear.

To nevertheless require documentation here is for Apple to use overly-fussy legal concerns in order to infantilize an app developer who can, and does, and rather would, take care of these things himself.

In other words: lay off, I want to say. I’m an adult with good judgment and I’ve already dealt with this issue, and it’s mine to deal with.

I have been complaining about the App Store since its inception, but it's worth repeating that it's not just dolts like me who don't like it. It's arbitrary in ways that defeat its purpose, demean its constituents and take for itself the crown of only responsible grown-up. Responsible grown-ups bring up and infuse their kids with values, yes, but would walk on burning embers to give them the freedom to do with their lives what they want. Extracting new rules from the same list of information and applying it suddenly and unevenly is capricious.

It would take an incredible balancing act to actually run an app store well. Apple has done the best job of it so far, but it's still a tire fire that inhibits applications legitimate developers want to write. These events are not representative of every app review process ever, but they are representative of what happens when you have an app review process and you live in the real world. It doesn't have to happen in most of the cases to be a disgrace and an impediment.

A slightly less complimentary, but no less true, take on today's theme.

(Also, that decision to allow Markdown in titles is coming out in force right out of the gates.)

The emerging norm for web development is to build a React single-page application, with server rendering. The two key elements of this architecture are something like:

1. The main UI is built & updated in JavaScript using React or something similar.
2. The backend is an API that that application makes requests against.

This idea has really swept the internet. It started with a few major popular websites and has crept into corners like marketing sites and blogs.

It's hard to quote just one bit but there's a lot in here. React (and many single-page application architectures) is a good fit for managing a certain level of complexity as long as you don't ask of it more than it can deliver.

For simple things, you can often get it done with simpler solutions. Take has no visible JavaScript if you're just visiting the site as it is. That's not a dogmatic decision – if I need to bring in JavaScript for compelling functionality I will, but there's no need for that at present. I'm writing this into a post editor right on the front page, with Markdown rendered live as I type, and the JavaScript and CSS to support it is being conditionally included when I'm visiting the site.

I love the basic idea behind React, which is to solve the inevitable problem anyone who tried to "just hook together" functionality using jQuery ran into, which is drift and divergence in UI logic. Doing iterative things to bodge something into just the right state from all over the place, and getting things done right up until the point where you start cursing your own love for expediency.

But React comes with the associated mess every JavaScript framework comes with. It's not the language as such (even though it has perhaps the worst standard library design sighted by reliable witnesses), it's that you have to use ten tonnes of slow-moving, complex infrastructure to build a pipeline for module loading and code splitting and minification and source maps, not to mention cross-compiling down to the revision of the language people can actually run. And it's the kind of thing that you don't do exactly the same on all projects, and the whole world moves enough that you can't really just crib a version from another project, because if there isn't a new language feature or technique you want to use, there's damn sure a new version of the bundler which promises to fix some inherent corner case you keep running into.

To their credit, the React team has made create-react-app which is a command line tool to generate, wrap and maintain a known good configuration of one such solution, but to configure it you have to "eject" from the ecosystem, and at that point you're in the same place you were. Angular also comes with a command line tool for related but not identical reasons, and it's emblematic of the problem and the culture. Pulling down a stack of paper that would reach your ceiling a few times over is not seen as an issue.

Even if snapping your finger and getting everything tooling-related working was possible, which I'm sure it is at Facebook where React is developed, the next round of problems arise, which is that having flipped the world on its head, you now have to find, develop, document and cohere a new set of solutions to all related problems, like, oh, fetching data and handling the evolution of state, which are inherent problems in all projects where React solves anything.

Dan Abramov of the React team and creator of Redux (which I also like) describes the issue from Tom's post as straddling the server-client divide and requiring a holistic solution, which may be true, but pretty much locks everyone into running JavaScript on the server (or the React team into providing server-side parts for all major server-side frameworks), and preferably committing yourself to ancillary technologies like GraphQL. One of my big problems with React is much bigger with GraphQL – that normal use cases like "authenticating", "mutating data" or "understanding how the hell you implement something that if unconstrained can basically cause you to need to generate arbitrary queries on your server" are tackled only incidentally and hand-wavily, and can never be thorough enough, seeing as how GraphQL is a specification instead of a library.

There are many things that can be done with JavaScript that make so-called single-page applications worth thinking about. And it's easy to see everyone who questions the state-of-the-art as either grumps or web haters. But Tom's post shines a light on the spectrum of solutions and serves as a good reminder that simple solutions can be the most appropriate and that React has a long way to go before all parts of using it are as attractively coined as the core, which was rooted in an actual problem, observation and mitigation that brings many of us in to begin with.

I believe in the web as a platform that is uniquely suited for many things, but also as a stack of technologies whose characteristics and limitations should be understood and respected to achieve the best result. Focusing on scaffolding and tooling and reworking revolutionary internals in order for brief code samples to become more powerful risks missing that the extra effort to support this process is a significant cognitive and operational load for everyone who uses the framework, and plants the expectation for newcomers that it's okay for 5000 things to go on behind your back, which is poisonous to learning and an impediment to problem solving.

Titles of entries are weird. In many places they're supposed to be "that entry from X named Y". You pick something good and that's it, nothing's ever supposed to have that name again – what programmers call "namespacing". I'm trying to let a title just become a headline here, and there may be dozens of entries with that title. Not in the same day, mind you. But maybe recurring.

(Except that this could be the definite answer here to why titles are then even weirder on Take than in many other places. I'm not saying I'll turn the car around if that ever happens, just that I'm trying not to let finding the perfect title hold stuff up.)

One of the things that rub me sideways about iPadOS or iOS or some of Apple's newer platforms is that there are always dozens of modes that you are supposed to support. Be it split view or scenes/windows or whatever, it shows up as some new abstraction that recontextualizes what's already there and sets some new parameter for how something works.

Maybe that's the only way it can happen, both in terms of introducing a new concept and allowing for the nitty-gritty details to work out in a sound way. But it still feels odd, most of the time. It feels like asking people to absorb additional layers of architecture all the time in some sort of endless layer cake, where perfection and "good citizenship" is only ever temporary, and you better have a lot of free time at your disposal. And if you're lucky, it gets announced ahead of time, and not just hotpatched into the GM seed when the latest device is announced.

YouTube is full of deep dives into many subjects, and this channel is particularly thorough and educational and goes into both precise detail and answering practical questions, like "how come the right edge of the screen looks glitchy in Super Mario Bros. 3?".

So far, this site is fried, not baked. I would love to bake it, but even more so, I would love to be able to type stuff into it and have it show up soon. Minimizing friction and all that. And my esoteric metadata and reticence towards implementing a standard posting API makes using a weblog posting app unlikely.

Right now, every time a post is added or edited or removed, a change is made to the database (SQLite), all the entries are read into memory and massaged into a form that will make pretty much any query fast (like maintaining ordered lists of post IDs and a dictionary of post IDs to everything about that post), and the previous instance of this form is atomically swapped out. This is slow-and-dumb, but it's not slow-and-dumb enough to make all this take measurable time, even on the Turing's bookend of a server this runs on, and it only happens when changes are actually made which is almost never. And showing a post never goes to the database/disk, it just consults this massaged form and does data structure things, which gains a lot of performance back, since that happens way more than changes.

Eventually my preference will be to have every popular thing that can be served baked up front, and when a change happens, to have the baked things that are affected re-baked. This gets tricky when next/prev links are involved, or when deleting a post shifts all subsequent pages, if you're doing this to post-list-pages too.

I changed the font from Faustina to PT Serif. PT Serif looks a bit too high brow, but Faustina looked a bit too cheap. I kept trucking because I thought it was because using a serif for body text is out of my comfort zone, but I realized I just wasn't happy with it.

I would have loved to have used Poly, but it has no bold weight, which could be a problem.

The logotype is set in the dynamic Pique. It looks swooping and dynamic (unlike me) and brashly swiftly bold (there we go).

I understand the point that not everyone want to have their own web sites. Everyone who thought the advent of the web meant people would own their own domains and set up their own weblogs were living in a bubble. It's not that people don't have them, of course. I just mean people people.

Last summer I listened to one of my dad's friends talk about keeping up with some of his acquaintances and some people in a club of sorts of shared interests. To him, for that purpose, Facebook is the best thing since sliced bread because it lets him do that. He can operate a computer and especially a phone well enough to do that, and he's really positive about it.

I'm guessing he's heard about what Facebook does and doesn't care, because he's not willing to put any effort into it. If it's there and it works, lovely. Making an effort to replace it with something else: son, are you kidding me? I don't know anything about that stuff, and I want to talk to a dozen people who don't either.

There's a lot more people like him than like the people who want to have their own web sites. Probably by a factor of hundreds.

Of course, the people who make Facebooks are way less than the people who make web sites too. It's not a completely hopeless calculus. Someone could still come along with something better and steal them away and ruin Facebook's day. But the Diaspora-like people who expect those people to give a damn about decentralization and federation and hooking things up are living on entirely separate planes of existence.

I'm being unfair – some of them are talking about privacy and agency and control instead of focusing on technology, and that can move people too, but only some people sometimes. Right now, people who care have brains that are on fire and in constant pain, and people who don't don't understand what the fuss is about.

They need to speak in the language of "how do we let you do something you couldn't do before" if they want people who spend most their day not thinking about this at all to have a reason to move. (Or in the words of jwz, "how will this software get him laid". There's a disclaimer there which is almost haunting, but I guess it underlines what out-Facebooking Facebook entails.)

Me, I'm just happy to be able to have something outside of Facebook and outside of Twitter, outside of the zoo of everyone else combined with whatever today's monetization strategy calls for. To me, not being an animal in their zoo is important. But not everyone thinks like that, or sees Facebook or Twitter like that.

We're probably far more likely to see Facebook out-Facebooked by something that's a bit more convenient but with a far more horrible backside than we are by seeing it replaced by something someone like me, or someone like the Diaspora people. If you think I don't like Facebook, I'm walking city blocks around TikTok. (You know, just to end on a positive note.)

The original goal was to have no tags or categories or such. Well. No. That's like saying the original goal for a meal was to have no éclairs in it. The original goal was to have as little as possible here, so there would be as little as possible to "fill in", and so it would be okay for what was there to be there. Each thing added is one more threshold, and the thing is to have as few thresholds as possible so that I would actually write.

Maybe some organization will become necessary in the future. No such plans right now though.

People are leaving cable and their 8000 channel packages behind. No one wants to see more than two or five or nine, of course, and the three most wanted are introduced in the third most expensive, second most expensive and most expensive tiers. Some people would say that this is what you do when you have something people want and that this is how a market is supposed to work – I'd say this is what people do when there are oligopolies.

But I don't really care about cable. What I care about is that what it's being replaced with – ISPs, streaming services and so on – end up replicating the worst bits. Now you have exclusives on different streaming services instead, and have to pay monthly tithes to them instead of to cable companies. It's still an improvement I guess, because there are plenty of things not locked down to them. But if you look at these constructions and see a broken model, it's like seeing an alcoholic making their way home after a lot of fuss, looking like they're on the home stretch, producing a flask from their jacket, taking a swig and promptly diving off the side of the road into a warm nettle embrace.

I guess technical freedom is one thing and "business realities" are another.

I'm now copying the entries I've written so far into the... spartan but custom-made CMS. I get live Markdown previews for the title and the text - the title because the title can include Markdown too, mostly because of links.

There's a plain text version of the title for various uses (like the title bar or feeds). There are both Atom and JSON feeds, and they include the formatted version of the title. They also just plain include every entry, despite what I said before.

There's no search yet. There's paging. There's no date-based index pages; if you cut off the URL components from the permalink it will go to the last known instant for what remains of the date and rewind until it finds a post, and if not, it'll throw you back to the front page. If you go to an entry in a URL that isn't the canonical URL, like 2020/5/10 instead of 2020/05/10, it throws you to the canonical version, because damn it.

I just want to get this up and running so I can have something stable to work with.

Here’s me: when I download an app with a first-run tutorial, I try to find a way to short-circuit it and get to the actual app. If I can’t, I just race through it, knowing I wouldn’t have remembered any of it anyway.

Either I can figure out the app later or I can’t.

One of the biggest issues is that it's all up-front. Show helpful arrows in context – have an intelligently put together blank slate and most problems just evaporate.