built with ☕

Any Given Saturday Afternoon

I watched the "Any Given Saturday Afternoon" episode (S3:E7) of Documentary Now! on Netflix this weekend. Documentary Now! is a great show to begin with but this one really killed me because I bowled in a league for many years, and it's a nearly one-to-one spoof of A League of Ordinary Gentleman which every bowling nerd watched when it came out. Spoof might not even be the right word, the source material is as ridiculous as the Documentary Now! version, with the exception of way more Alf references. I think. Honestly if the Alf stuff was in the original and I just forgot I wouldn't be supris

If you watched "Any Given Saturday Afternoon" and weren't familiar with who Tim Robinson and Michael C. Hall were portraying you'd miss out on most of the humor. A League of Ordinary Gentleman is worth watching, but if you're short on time Tim Robinson's character, Rick Kenmore, is an almost unaltered portrayl of Pete Weber, and you can understand Pete Weber from this amazing, 26 second long YouTube video entitled "PETE WEBER GOD DAMMIT I DID IT WHO DO YOU THINK YOU ARE".

Arts Fest Beverly, 2019

Our haul from Arts Fest Beverly this year. We definitely have a style we like, specifically down to how many legs a fox should have in the air.

1. Fox with grapes by Maura OConnor.
2. Bear by Hastings Studio.
3. Fox with butterflies by Kim Ferreira.
4. Little Mermaid by Brian Gubicza

2019 - the Year of Publishing Your Own Content

There's a running – joke? commentary? zen koan? – in the Linux community about the "Year of the Linux Desktop", meaning the year where people finally start using Linux instead of Windows. You can find an endless number of hot takes on the web about whether it has happened, is happening, will happen, will never happen, has happened but by way of the Android operating system... you get the idea.

Recently I've seen a similar theme on how now is finally the time for people to take control of their content on the web – the "Year of Publishing Your Own Content". There's strong takes like "Can we all please stop using Medium now?" and more nuanced takes on "Own Your Content". There's always Manton Reece's slightly opinionated thoughts on the subject or Eugen Rochko's Mastodon feed. We're even into the part of the cycle where people start to show demos of how they moved off of Medium to another platform and how to do it in gif form, analogous to the "how to delete Windows and install Linux" articles from the last turn of the millennium.

The points raised are all valid. The main hosting platforms are each their own brand of awful – Twitter (full of character-limited hate crimes), Tumblr (censorship), Medium (adwalled), and Facebook/Instagram (still run by Mark "I don't know why they trust me" Zuckerberg). What these treatises ignore is that publishing your own content isn't easy, and monetizing what you own is ten times harder than that. There might be more and more articles popping up now about how to move away from Medium, but go back two years and you'd many of the same people arguing for moving to Medium – it was the hot new platform and had all of the eyeballs. Everything that gets popular on the web will eventually get hit with the "nobody goes there anymore, it’s too crowded" line, but if you want to be seen, you need to be where it's crowded, and it you want to make money you need to be where it's incredibly, unbearably crowded.

posting on Medium seemed like a great idea before all of the content got stuck behind this pop-up.

I have some bias in the "should you self publish" argument as you're reading this on a domain I own, but I also realize I have the technical and financial means to do so. Also, I'm not trying to sell you anything, and I don't particularly care if you even show up. This quote from Khoi Vinh on "Own Your Content" resonated with me:

...I’m not suggesting that what I do has any superior worth at all, but what I will say is that the difference between content that lives on a centralized blogging platform and what I do on a site that I own and operate myself—where I don’t answer to anyone else but me—is that what my writing on Subtraction.com has a high tolerance for ambiguity. It’s generally about design and technology, but sometimes it’s about some random subject matter, some non sequitur, some personal passion. It’s a place for writing and thinking, and ambiguity is okay there, even an essential part of it. That’s actually increasingly rare in our digital world now, and I personally value that a lot.

My advice? Post whatever you want wherever you want, but keep everything backed up as plain text. Be skeptical of any system that makes that difficult, and avoid entirely any one that encourages people to be awful. If all else fails, consider selling chapbooks at the closest highway rest area, that's real self publishing.

Don't worry, bee happy

alt: don't worry, bee happy.

I'm super jealous of that scooter. Best thing I had at that age was a tricycle that weighed 80 pounds with pedals that would crack your shins in half if you went downhill.

HTML, code, and databases

Found on a Hacker News thread about PHP in 2019.

I don't write any PHP these days, but the sentiment of a single file that combines HTML, JavaScript, and database queries to quickly knock out simple projects resonates - that's the exact setup I have for the Gatsby powered files that generate this site. There's no <?s any more though, it's GraphQL queries and JSX that covers both the JS and the HTML.

I can't see ever going back to PHP - I'd prefer Python and I know more C# than it at this point - but I'll never complain about it being a quick and (sometimes) dirty language.

Digital Minimalism by Cal Newport

I finished "Digital Minimalism" by Cal Newport last weekend. I assumed, from the title, the book would just be this:

repeated for 300 or so pages. It wasn't! The 2016 election and Twitter comes up at least a few times, but the book is more about forming good habits to replace digital distractions. My favorite quote from the book:

You cannot expect an app dreamed up in a dorm room, or among the Ping-Pong tables of a Silicon Valley incubator, to successfully replace the types or rich interactions to which we’ve painstakingly adapted over millennia.

The book resonates with my belief that the value of the internet is fundamentally found in two things:

• As a repository of nearly infinite amounts of information.
• As a channel for nearly infinite pathways of human to human communication.

As an example: I play guitar, I'm interested in building my own guitar. There are many thousands of videos on YouTube on how to do this, reviews of every single piece I might be considering, and more forums than I can even find with detailed instructions and helpful tips from other people on how to build almost any combination of guitar. This was nonexistent when I was a kid - if you wanted this level of information you were lucky if a book existed, otherwise you had to find someone who knew how to build guitars, maybe at the local music store, if you happened to have one and someone working there knew something about guitars.

The Internet supports these activities, but most of the attention economy (Twitter, Facebook, YouTube, etc) is driven by users being distracted by other things. Facebook might help you organize real-life events, but wouldn't it be great if you also paid attention to these people you never see in real-life? Twitter might be a great place to follow your favorite author, but wouldn't it be great if you also saw some retweets about a political argument from a friend of a friend? YouTube might be a great place to watch instructional videos, but hey also have you considered that 9/11 might have been perpetrated by the US government and here's a 3-hour long video about that from OffTheGridLifeAmerica you might be interested in. Accepting these platforms as they would like you to accept them (i.e., in a way that makes them money) can only be done in a way that is inherently detrimental to your free time and quality of life.

My main takeaways from the book:

1. Delete / block anything digital that doesn't improve your real-life experience. Going back to the guitar example above, if a digital experience makes you want to play guitar more, great! If you spend all your time on Instagram looking at guitars, stop it. The rule of thumb here seems to be if you want to spend less time on the digital activity and more time on the IRL activity it fosters, it's probably ok.

2. Assume every addition to your life is a net negative unless proven otherwise. This isn't a "digital minimalism" philosophy, it's just a minimalism philosophy. It's seemingly a trend, or else Netflix wouldn't have produced that Marie Kondo show, right?

3. Build or create something every week. I liked this idea. I started blocking out my time better in 2019, and keeping track of things like "exercise 3 days a week", but the things I keep track of don't completely fill up my free time. Doing something with your hands is usually completely analog - unless of course it's building a guitar while watching videos on how to do it. But at the very least it's not passively digital, which is the point.

4. Own your shit. Or, phrased more politely, own your turf. I dream of a day I can go online once or twice a week, hit an RSS aggregator and catch up on the activities of all of the people I care about. That was nearly a reality in the early days of the web, but the social media giants would prefer to own your content and make it hard to access unless the reader is also inside their bubble. To that end, I deleted the links on this site to other places (LinkedIn, Mastodon... not Github, that's actually useful, and not really social media) - if you found me here, what more of me would you wish to find.

In conclusion I give the book ⭐⭐⭐⭐⭐ (out of 5), not on Goodreads or any other platform, just here. Also, true to form, I read the print version, and we got it from the library so we could work on real world minimalism too.

Twenty years and I still can't add a script tag right

2019 marks twenty years since I first pushed a website to the internet, yet today I was trying to set up a project and I got caught on something very... silly. I was testing a webpack configuration for a React library so it would run in Internet Explorer 11, but I couldn't get the application code to execute when running the development server. I dug through the code and searched for anything I could think of to narrow down if it was the fault of webpack, the dev server, my application code, or the polyfills I had added for IE11 support. After a (too long) search, it came down to this:

<script src="main.js" />

This is not the first time I've made this mistake, and in case it's not immediately clear to you, dear reader, script tags cannot be self-closing. Every time this has tripped me up it's been a particularly baffling error because a self-closing script tag will appear to load - the script will show up in the network tab of the dev tools, and all the code will be there, it just won't execute anything.

Since first learning web development, I've done the very basic task of adding a script tag a lot of different ways:

• In some PHP function that tied into a CMS's loading hooks.
• In .NET MVC ScriptBundles.
• document.createElement("script"); then assigning the script source.
• Not at all, letting the magic of something like Gatsby or webpack add the script tag for me.

On top of that, my mental context for when or when not to close tags comes from a mix of knowing HTML, XHTML, and currently working with React - there's some conflicting ideas of what must, should, and should not be self-closing going on in my head.

The project works now - and supports IE11! - and however many years from now, when I forget that a script tag can't be self-closing, I'll at least have this blog post to look back on. Or, all of the browsers will have started supporting a self-closing script tag, or I'll have moved on to yet another abstraction around loading the script tag that removes the brackets and I'll have forgotten how HTML works entirely.

Don't Let Ad Blockers Break Your Website

If you're a web developer working on a website running tracking or analytics scripts of any type, you absolutely need to make sure it works for users blocking third-party scripts. This is just the latest example, from fabric.com, but I've seen this happen many times: a completely blank screen when Ghostery is blocking scripts.

In this particular case the site threw the error:

Uncaught TypeError: window.cmRecRequest is not a function

I personally run Chrome with Ghostery in "shut it all down mode", or set to block everything. The issue is always the same: a piece of code that fires a call to a tracking script (usually set as a global variable), that doesn't check that the variable exists before making the call. It's not often you find it on page load, but turn Ghostery blocking on and watch how many call-to-action buttons on marketing sites stop working.

Even less extreme ad-blocking can cause some unwanted behavior. This is from css-tricks on Firefox running uBlock Origin.

I don't need any help managing my projects, but it still took me a bit to parse what exactly was going on with this sentence, until I viewed it in another browser and found out it was uBlock hiding text that was a doubleclick link.

The ad blocking wars are only going to get worse going forward, especially now that Apple is blocking ads at an operating system level, while Google and Microsoft are trying to prevent ad blocking at that same level, and the browsers and lining up on opposite sides of the same battle, with Safari and Firefox helping users block ads and trackers out of the box, and Edge and Chrome have a business interest in delivering ads and tracking their users.

Stenciling

I spent a little time over the holidays playing around with Stencil, a JS compiler for web components. I wanted to look at it because we've been comparing component libraries at work, and we were finding a surprising number of them that were going all-in on web components, usually generated by Stencil. Some quick notes about it in general, and comparing it against React, our current JavaScript library of choice:

• Stencil reminds me a lot of the joys of jQuery plugins, where deciding between creating an element and passing in children or creating an element and passing in attributes is just a flip of the coin kinda choice. That's not to say React is better - see the arguments for or against higher-order components - but at least in React everything is in React, unlike web components where your children / attributes are in HTML and the handling is in JavaScript.
• I hate carousels. I wanted to try to recreate a carousel that's on our current public site - it kind of magically appears when the viewport gets small enough and is just a glorified overflow slider. I feel like I've built variations of carousels a thousand times now, so there's a certain appeal in building a web component and never ever doing it again.
• HTML doesn't understand TypeScript. I use TypeScript on all my React projects, and having attribute completion is 💯so going back to "just" HTML made me a little sad. It also made me realize how long it's been since I've written anything in an .html file that wasn't just <div id="app"></div>.
• ... but it is just HTML + JS so it works anywhere.
• ... but Stencil is a compiler that requires a build step, so you haven't quite gotten away from build steps in your front-end development process, but you're closer for every project that uses the Stencil-generated components.
• I would have killed for this setup 3 or 4 years ago. TypeScript? Sane JavaScript templating? Not having to transport the same stupid widget between HTML, Angular, and React projects? It would have been amazing. Now that I do everything in React it's less exciting.

Overall I was impressed by Stencil. The documentation could be better, but they make it pretty easy to fire up a project and figure it out, and TypeScript + JSX is by far my favorite combination for JavaScript templating. Some of the decisions are close to React but not quite the same, like having props and state but not state update batching, or at least not that I could find. Digging through the shadow DOM in the Chrome inspector is painful compared to using React dev tools, especially if you're using child elements, which exist in some sort of alternate reality that allows you to interact with them like normal DOM elements. I built the carousel as a web component that accepts any children because that's how I would do it in React, but dealing with children beyond using the web component <slot> tag required some Stack Overflow searches and some solutions that I'm still not sure I grok.

If there was ever a chance we were moving away from doing everything in React I'd jump to web components in a second, but when we are building everything in React, adding in another compiler feels like it's overcomplicating our development tooling. But maybe I'll regret saying that when we switch to Vue and have to build another carousel.

I put the demo up on GitHub, it's probably broken in IE. I hate carousels.

Defending the presents

I think our cats might be half chicken. They've never tried taking the tree down - they're content to just roost under it.

Merry Christmas, everyone.