Skip to footer navigation.


A digital pillow fort

week notes

Last year I set out to rekindle my reading habit. That went well. This year’s reading has been enjoyable, but I’m not cozy with the ratio of non-fiction to fiction I’ve read this year…non-fiction (especially of the computing persuasion) far out balances the fiction I’ve read. I think this is mostly because I’ve been mired amidst a fiction book that I’ve found to be a slog…but enjoyable, too. I’d have abandoned it and moved on, elsewise. Onward!

Spring is quickly making way to summer here in Maine. The school year is fully geared up to end at any moment, and summer adventures are aching to start.

We don’t have anything huge planned this year — but we have more than we’ve had on deck for the past 5 years or so. I’m honestly a little anxious.

In an attempt to be more social, and not fake social-ness by occasionally posting these missives here, this weekend I was slated to attend an in-person game jam. Fate conspired against me, though, in the guise of an ill kid, and I was unable to attend. I was hoping to cobble together a game of some sort to help me think through what a simple game engine might be like implemented in apl, or another array language.

Here is a fun article on early computer art from Amy Goodchild.

Like so many other folks of late, my family has been deep into Zelda — but not the new Tears of the Kingdom game. We haven’t cracked that one, yet! We’ve been enjoying Links Awakening and Breath of the Wild.

…I joked about the Zelda games and pastoral art in another post a while back, I think, but can’t stop thinking about it in earnest now, especially Breath of the Wild, which literally features a flavor of pastoral art in cut scenes, all while relishing in an in-game art style that inches oh so close to romantic landscapes. Lots of juicy visuals to love.

Something left out of the original draft of this post:

I’ve started a fork of ngn-apl! My plan is to leave the core functionality in place, but to layer on some accessibility and mobile-friendly improvements to the web interface.

A dithered image shows a young child with long hair standing on the rocky coast, looking out at the sea.

First afternoon at the beach this year!

of array programming, lightsabers and some thoughts on permacomputing

A bit of this and that, some kind of mishmosh.

Over the last few weeks I’ve been reading a lot about array programming systems like J, K, Q, APL, and BQN. I’ve been intending to add a page to the wiki about them, but haven’t gotten to that yet. Consider this a little promise that I’ll do that sometime soon. I’m interested in array programming less because I think it’s particularly useful for me (it’s not) and more because I am captivated by the poetics it invites.

If I had a personal theory of programming (I don’t) it would be something like

programming is writing poetry that acts on input and data to cause a known effect.

Array programming systems invite a different sort of metre and verse to that poetry. They force ya towards something like haiku whereas most other languages want you to stick to a yawn inducing iambic pentameter.

Beyond that reading, I re-watched the original Star Wars movies — IV, V, VI — this past week with my older kid. Their reaction to them was skepticism, and being convinced that the Ewoks ate the dead Imperials after the Battle of Endor…which could be true?

A blog post I wrote a few months back at work got published. It is my attempt at sneaking in some thoughts on permacomputing into a more normal” setting. The timing of the post was oddly synchronous with a few things, one of which is my thinking a lot more about permacomputing:

A lot of the dialogue around permacomputing that I’ve seen seems intertwined with a certain aesthetic sensibility that is entangled with the demo scene and retro computing communities. While I think both these spaces are kinda rad, I think they’re specifically prone to a certain flavor of navel gazing…a flavor focused on specific tech stacks, and tooling, and apparent minimalism. It’s a flavor that leaves a gap in the conversation around what I’d call the why” of permacomputing.

Most of the conversations I see are hyper focused on the how” and what” of permacomputing. How” and what” cover the skeleton, we use X system running on Y reclaimed hardware.” The discussions that gesture at why” that I see tend to be like because it’s the more harmonious way to do computation given that we’re living amidst climate collapse.” And, while that is a great reason for choosing lower impact tools, I think the community generally misses what I see as the most important bit of permacomputing:

Let permacomputing be an invitation to question why and how much computation ought to be involved with a thing, and, if that computation is being used to increase or decrease the anomie between folks…and with what impact to the world?

My take on permacomputing is that it’s a way of approaching computation that’s further distanced from the goals of capitalism. It is an effort to re-imagine our tech landscape, and in so doing enchant it with values that support, for lack of a better word, balance.”

week notes

Some things of note, links mostly:

First and foremost, I found a suitable pinboard replacement in link hut! Shout outs to my buddy Bruno for the tip.

Here’s a bookmarklet I wrote to make it a bit more ergonomic for how I like to roll,

javascript:(function () {
  const tags = prompt('A space separated list of tags.');

That will snag any selected text and pop it into the bookmark’s description after it prompts you to enter some tags.

Next, a confession: those who know me know that I’m cynical about all tech. So, it should come as no surprise that I’m deeply cynical about the current bloom of AI, a la ChatGPT.

…well, curiosity got the best of me and I tried ChatGPT out.

And, honestly, I’m still pretty cynical about the whole vibe — I started to write some discombobulated thoughts about all that on my wiki but haven’t gotten anywhere with that line of thought yet — BUT, the thing I have found ChatGPT incredible for is that it has totally replaced my least favorite weekly chore! Menu planning.

I loathe menu planning. It is weirdly stressful and we have a handful of interconnected constraints on our menus and it was exhausting for me for some reason. I always dreaded menu planning. Well, ChatGPT has solved menu planning for me, and I guess that is cool?

I said unto it: please suggest 4 week’s worth of dinners for a gluten free, vegetarian family of 4 including recipes and shopping lists.”

…and it worked.

Insane with power, I submitted the same request with some minor tweaks 6 more times. I used the responses to build an archive of recipes paired with shopping lists. I’ve added a few items, and I’ve made myself a little tool to randomize a menu and shopping list.

Now ya’ll know my shame.

My birthday happened this month, for it I got 2 lovely gifts:

Among the games are two standouts:

Eastward is specifically amazing because it hits every button right for me — I’m a sucker for the type of story telling it engages, as well as for Vermeer-level pixel-art. The graphical story telling, and world building are all kinds of good.

Speaking of pixel-art, I continue to work on a little Game Boy game. To empower my doodling around with that while on work meetings I pulled together a little pixel-art editor.

Spring has been teasing us here in Maine. Hints of its arrival abound, yet it remains sloppy and gray outside…sock weather purists.

week notes

I’ve been experimenting. I’ve been concocting a recipe for vegan kugel, and rediscovering little features and edges of my website I’d forgotten I baked in. Like chocolate chips hidden in an oatmeal raisin cookie.

One chip most recently re-discovered: support for per-page custom styles?! All I gotta do is include an optional bit of meta data, bespoke-css, that points to a style sheet. I may play with this feature more. I do love myself some css. I can tell exactly when in my life I added this feature because these days I’d never call such a thing bespoke-css” — it would get a much more boring, terse label, like css” or styles.”

The kids have been home on school break this week. We’ve been having a lot of fun reading The Wind in the Willows aloud, and playing a bit of No Man’s Sky on creative mode. You wouldn’t think it, but each carry a really similar vibe. Cosmic-pastoral-localism?

In the last week notes I made mention of potty training; at first that was harrowing and seemed like it would never happen. Then, all at once, it did!

I continue to expand the newly formed wiki. My plan isn’t to catalogue everything and anything — outboard brain style — but to really only document stuff I find useful and that I want to keep track of for myself…that maybe will be useful for other folks, too? The acme page is probably most inline with what I’m going for.

For good times, check out ratfactors rad presentation on forth!

I’ve also been playing with babashka, reading it’s excellent companion book, babooka. Babashka is a wicked fast way to use clojure when you’d normally reach for bash.

Ideas for making accessibility and equity a core part of the software development lifecycle

In accessibility and the product person I said

we need to make accessibility a core part of our processes

Here, I want to talk about that in more detail. I want to briefly explore what making accessibility a part of core processes looks like, and how that is different from centering accessibility as a priority.

RICE is a scoring model many organizations use to prioritize what to focus on. If you aren’t familiar with it, RICE is an acronym that stands for reach, impact, confidence, and effort. The idea is that you assign a point value to each facet, and use the sum of those points to help determine priority between a few competing ideas.

If accessibility isn’t part of your core processes and baked into the culture of your work it will show up as one of many competing ideas all placed against each other in the RICE model. When pitted against other ideas, and when using tools like RICE, accessibility, and equity concerns writ-large, are gonna loose. They’ll be considered, discussed, added to the backlog, but, almost never prioritized. They won’t be prioritized because, across the software development landscape, accessibility isn’t a profit center, it is a cost driver.

But this is a solvable problem.

Stop using RICE and tools like it that don’t include accessibility and equity as facets of their model.

Add it if it isn’t there.

By adding them as a facet, RICE+Equity, you make accessibility a key part of all your decisions. You can still put the accessibility projects up against other ideas, but no matter what, by baking accessibility (and equity, generally) into the frameworks used to determine priority we can begin to ensure accessibility is a core consideration helping to guide all product decisions, and not left as a project on the backlog.

Moon maker

I recently re-read Peter Naur’s Programming as theory building”. Afterwards I set out to write my own text editor. The paper posits that it’s really hard, if not impossible, to fully communicate about a program and sort of gestures at the futility of documentation…what spun around inside my head as I read was that our primary programming medium — text files — is silly. Like, some folks would totally 100% scoff at my writing forth but, at the end of the day, forth and javascript both produce executable text files despite being lightyears apart. What if a text editor let us have something more than just text files as artifact?

So, like many before me, I started to write my own text editor. And it sucked. What I made sucked, and the process itself sucked…or, at least, it didn’t lead to anything particularly different from the vast array of existing text editors. I wanted to be able to support a different paradigm of writing code, I didn’t wanna just produce vim with worse ergonomics. I didn’t make much progress, even leveraging web technologies that gave me a lot for free,” because before I could begin to reinvent any particular wheel I had to crawl out of the primordial ooze…

Then I realized I didn’t actually want to implement my own text editor! I’m not a fanatic about what editor I use; I’m pretty evenly split between sublime text, emacs, text edit, vim, acme, and mg. I bounce between them depending on what I’m doing, and for how long I’ll be doing it. What I wanted was to be able to support a slightly different mental model of what a file” is using any existing editor!

That was an easier technical nut to crack. It took about 2 hours after the kids went to bed with a little bit of help from the inimitable llimllib on mastodon…and all I did was write a shell script!?

So, my personal solution to the cutting edge of programming being just text files is to add even more text files!…at the end of the day, they’re a really really hard thing to leave behind, especially if you’d like to preserve compatibility with any existing programming system.

That iconic image of the earth rising over the lip of the moon.

I wrote a shell script called Moon Maker. Moon maker, or mm, lets you attach orbiting moon files to central planet files. A planet file is the one you really actually care about — its probably a file in a project. A project can have any number of planet files, and a planet file can have any number of moons in orbit of it. Moons are files that orbit a planet, they’re places to take notes, a scratch space, somewhere to try things out, or add layers of information about the planet. A moon file can have any file extension, and references the planet by it’s name. Moon files live in a directory of their own, .moons, and each can be referenced by a unique id, or, collectively by the name of the planet they orbit.

    Moon Maker

    ⋆。°✩ ☾

    mm is a small program that lets you add orbiting moons to existing planets.

    A planet file is the one you care about -- probably a file in an actual project.
    Moon files orbit planets, they are disposable scratch spaces connected to planets.

    usage: ./mm
                    -i(nit)....initialize a directory to store moon files
                    -o(pen) a planet file and all of its moon files
                    -l(ist)....list all moons for a given planet file
                    -a(dd).....create a new moon file for a given planet file
                    -d(elete)..remove a moon file by its id
                    -c(lear)...remove all moon files for a given planet file
                    -u(pdate)..rename a planet file and all of its moon files

The idea is you use mm sort of like you’d use git — you initialize it at the project level, and then add moons to planets as needed within the context of a project.

By default, moons open in your EDITOR of choice, but I’m thinking of adding support for editor overrides so you can easily open planets in one tool, and moons in another.

I don’t honestly expect many or any folks to use this thing, but I’m excited too. It matches my mental model, and, my process: usually, when I’m working on a project, I end up creating a bunch of temporary or scratch files to document little corners of something, and experiment. This enables that in a consistent way across my projects while maintaining compatibility with all of my existing tools. If this works out, and doesn’t have any toothy gotchyas I’d like to support adding moons, satellites maybe, to specific lines, or regions of a planet file, too. My first attempt at this thing was more elaborate — rather than bash and saving to the file system, I tried to do something with sqlite, and having a database backing each file of a project.

The idea was to support using any convergence of row and column number of a text file as an id, and then generate a connected moon from that. This was a cool idea, but so fragile as to be untenable. Plaintext doesn’t offer a great way to reference specific points in a file if that file is changing.

Accessibility and the product person

This post is a slightly modified version of a talk I presented to the product practice at my work. It presents a few ways that product designers and managers can help to move accessibility forward. It is a little bit different than what I normally share, here, but, I thought it may be interesting to some folks.

Picture of a slide with the title “Why though?” It also includes a quote from Kat Holmes’ book Mismatch. The quote reads: “There are many challenges that stand in the way of inclusion, the sneakiest of which are sympathy and pity. Treating inclusion as a benevolent mission increases the separation between people. Believing that it should prevail simply because it’s the right thing to do is the fastest way to undermine its progress. To its own detriment, inclusion is often categorized as a feel-good activity.”

I’m not gonna make a case for why accessibility is important; my hope is that we’re pretty well aligned around why.

Today I’m going to focus on what product folks can do to push accessibility forward.

The tl;dr of it is that we need to make accessibility a core part of our processes:

This slide shows a meme in three parts. The first part shows a small, pixelated image of Mario. The middle part shows the fire flower. The last part shows a larger version of Mario throwing a fireball. Beneath each section is some text. The text, in aggregate, is set out like an equation, and reads: “Person who’s a potential customer + your product = awesome person who can do rad shit!” An arrow points to the fire flower and is labeled “this isn’t what your business make.” Another arrow points to Mario throwing a fireball and is labeled “this is what your business makes.”

Many product folks have shared this meme. It is beloved in the community because it offers a concise vision of product, and tugs at some nostalgic heartstrings while doing so.

I also think that this meme offers a vainglorious view of product.

Image includes a quote that reads: “A person seeking help in a time of crisis does not care about TypeScript, tree shaking, hot module replacement, A/B tests, burndown charts, NPS, OKRs, KPIs, or other startup jargon. Developer experience does not count for shit if the person using the thing they built can’t actually get what they need.” from Modern Health, frameworks, performance, and harm, by Eric W. Bailey

How annoying would an awesome burial form be? Or a tax form? These shouldn’t be noticed. No one should remember these forms for good or ill because these services are doing their jobs if they work and are totally frictionless.

Most of the products we work on are infrastructure that folks are obligated to interact with.

A real life example of a frustrated experience that we can see today is Namely’s PTO request form. That form takes a sighted person who can use a mouse a few seconds to complete. I urge you to try and complete that form using either a screen reader or only a keyboard. No mouse.

It is a gnarly-cumbersome experience because one of the form fields isn’t directly reachable from the keyboard.

The same meme as earlier, again in 3 parts, but with some changes. Now it has been edited. A large letter X, labeled “Not Accessible” totally covers the fire flower. And, the previously fire-ball-throwing Mario now faces outwards, looking at the viewer. Above Mario’s head float 3 question marks, indicating that Mario is very confused.

When products aren’t accessible folks don’t have a clear way forward. So, how can we avoid confused, and frustrated Mario here?

The PTO request form on Namely isn’t empowering rad shit, as the meme says, it is frustrating and makes what ought to be a simple task a difficult one.

It makes what should be an unmemorable obligation an annoying experience.

Slide with the text “How though?” and a small picture of Mario looking at the floating text.

But how do we avoid this? How can product folks help to prevent this situation?

Accessibility is often seen as a concern for UX and engineering — today I’d like to say that product folks are also key to creating accessible stuff.

Slide with the text “Identify points of exclusion.”

My suggestion is to stop thinking about inclusion and start thinking in terms of exclusion.

By identifying points of exclusion, those moments where folks are either wholly forced out of your product, or, more likely, have to come up with homegrown workarounds to complete some task, we can start to take actionable steps towards more inclusive products!

Sometimes you may have to make the hard choice of who’s in and who’s out; I think this is the type of choice that product should make, not growth, not sales, not engineering or design. Product should make this call because product often has the longest memory — product folks can back the choice up with data and continually work towards products with fewer points of exclusion.

If someone has to be excluded at least have data about who, and immediately work on a plan for how to bring them in.

Thinking in terms of inclusion tends to lean aspirational, while by framing things in terms of those points of exclusion we can more easily come up with actionable steps to help create more inclusive products.

Slide with the text “How though?” and a small picture of Mario appearing to walk with his arms’ outstretched.

Again, how though? How can we identify points of exclusion…especially when we’re talking about something that hasn’t been built yet?

Slide with the text “Interrogate your assumptions.”

We start by examining the assumptions we’ve made and making sure that they are informed by research, and also informing new research.

The popularization of hashtags on twitter is an example of this, or a child climbing a counter to reach a cabinet in a kitchen.

What assumptions informed these choices?

Of course, the best way to interrogate your assumptions is to include disabled folks in the discussion. Folks excluded from your product and the system that produces it — that isn’t always in our power and is a bit out of bounds for this presentation, but, include and prioritize these voices whenever possible.

Slide with the text “Have metrics to track your practice.” and a small picture of Mario appearing to recoil in fear.’ outstretched.

Next we make sure we have metrics about accessibility.

This, in my experience is the trickiest of my suggestions. A lot of things look and smell like metrics about accessibility, but end up being metrics about delivery.

To help ensure that our metrics are actually about accessibility, which is less an end-state and more a practice, or way of working, I’d suggest that we start by having metrics that focus on our teams’ processes and tracking how we approach accessibility in our day-to-day work.

Rather than track that we delivered some number of accessible components, I suggest that we track that our team has a plan for improving accessibility — like a tiny maturity model — so we can track this improvement in our processes.

For example, a metric tracking the number of components you shipped to production that include accessibility guidance.

Slide with the text “Always be banging that drum.”

Last but not least, don’t hold a meeting where you don’t mention accessibility, and, maybe most importantly, celebrate as you continually achieve accessibility beyond compliance.

We hear a lot about gaps in accessibility, and rarely about victories.

Because of this I think there’s an idea that accessibility is all about compliance and gloom; whereas we have an opportunity to make it about playgrounds and connection and innovation. It can be the next chapter in how we do this thing we do.

That is probably my most important point:

Just like when mobile-first” was the catchy rallying cry, we can celebrate and spread accessible-first” methodologies and help to popularize it as a core principle for any new projects.

Accessibility isn’t the sole responsibility of specialists, it is a facet of the work everyone does.

Achieving accessibility beyond compliance isn’t possible through technical means alone; it also involves a certain amount of cultural change. I think cultural change is a responsibility that a product practice carries.

When folks started to embrace mobile, some businesses did quick fixes to update existing solutions so that they’d work on smaller devices. This is akin to accessibility remediation work.

Other businesses adopted mobile-first design methodologies, making mobile a key principle from which they worked. This is like doing accessibility beyond compliance.

An accessible-first approach, an approach that goes beyond compliance, invites the creation of more adaptable systems that are ready for situations we haven’t imagined yet.

With mobile, folks who had an adaptive, mobile-first methodology were able to take the introduction of tablets in stride, while those folks who’d been focused on only supporting the known form-factors had to do more work to keep up.

Product folks have an opportunity to bring accessible-first” thinking to their work, and help cultivate a culture that strives for accessibility beyond compliance, and in so doing, ensure that we are all better prepared for anything that might come along.

Slide with the text “Thanks!” and a small picture of Mario. Mario has the ears and tail of a racoon, and is holding a bejeweled wand over their head.

A huge thanks to Josh and DK for sharing feedback with me while I came up with this presentation.

Slide with the text “Discussion.” and a picture of Mario curled into a small ball, hiding beneath their hat. The slide also lists the questions listed in the next section of this document.

Some questions to consider:

Accessibility updates

I’m feeling pretty chuffed! Last week I wrote about my intention to make this website more accessible. My motivations were many-fold, but, primarily, mostly shame. I’ve worked as an accessibility specialist in the past, and now spend a bunch of my days at work looking for ways to make public infrastructure online more accessible. It seemed fitting to at least make sure the little bit I contribute to the web here is also accessible.

I thought it was going to be more of a project than it ended up being. Oatmeal is passing with mostly flying colors according to a couple different browsers’ in-built accessibility auditing tools, VoiceOver, axe, WAVE and IBMs accessibility scanner.

I focused on improving a few key areas:

To achieve better color contrast ratios I know I could have employed math, but, instead, I didn’t do anything scientific — I used trial and error to land at a slightly updated color scheme. Along the same lines I also increased the default text-size and made sure that link text was visually unique along an axis other than only color. Underlines, baby!

The markup was the issue that had me thinking I was gonna have to do a soup to nuts rewrite. I ended up finding a handful of big wins, though, so was able to make a lot of progress pretty quickly. The biggest win was tearing out a lot of indieweb-specific markup. I think it isn’t that hCard’s and what not aren’t accessible, they just lead to a really chatty” page if poorly structured, and mine were poorly structured.

The markup updates flowed into improving the navigation. I’ve always leaned heavily on this being a blog, with everything structured around a gigantic chronological list of posts. That’s boring, though, and not all that conducive to actually finding stuff that isn’t chronologically recent.

The site’s navigation still lives mostly in the footer. Now there’s a skip link to get there more easily (try it! Use the tab key to trigger the skip link). I’ve also added a handful of new pages that invite folks in through some different entries — doors and windows and whatnot.

With these changes made, I’m feeling better about the state of this thing. There is 100% certainly more that can be improved, though, so, I’m gonna consider this the start of an ongoing project.

In reply to: Oatmeal - week notes

The worst kind of blogging is blogging about blogging, so, I’ll keep this blogging about blogging short!

I’ve made some minor updates to the design of the website that have improved it’s usability a wee bit, and are a step in the right direction toward upping my accessibility game. The major remaining accessibility issues are around color contrast and some structural stuff.

I’ve started to introduce an updated color pallet to resolve the contrast issues. The structural stuff is going to be a wee bit harder to address, but I’ve started to make inroads there, too, mostly by removing a lot of indieweb specific microformat markup. The entire site should be more or less totally navigable by keyboard now.

I’ve also added a page to help situate folks and invite ya in to different ways of finding stuff here.

Dithered image of a large cat with tufted ears sitting inside of and partially on top of a wooden play house. The cat is looking directing at the viewer and appears to be angry, angry at you, the universe, and all things in between. The cat is not happy. Behind the cat is a wall covered in Charlie Harper bird decals.

I am Batman.”

week notes

It got a wee bit cold here in Maine this weekend. It was thankfully uneventful for us. We hung around inside and watched it get real cold outside. Our home faired pretty well, too. Honestly pleasantly surprised about that!

We picked this weekend to go all in on potty training — pantsless days, treats, rousing bouts of encouragement sung, and a lot of spot cleaning. Fueled by hubris, I thought we had this potty training thing down pat. In reality, it was that our first go round with it was supremely uneventful. We will perceiver.

I’ve been thinking many thoughts about how to fix this website. While I love its design and general vibe, I know it’s not all that accessible, and has some usability issues (so many tags!?). I don’t have a real idea what to do, yet, but maybe take this as warning? Changes are afoot…albeit a pair of slow, uncertain feet. Things I hope to figure out include

I recently asked a question on fedi:

Once upon a time I was an art history person. I thought for a long while I was gonna be a professor of it or something adjacent to it.

There’s a certain sort of art history writing that spends a lot of time establishing an ontology around what’s beautiful, and what moves make something beautiful.

These days, a lot of the nonfiction I read is about programming or computer science. It’s not unusual for a programming book to talk about beauty in code, or data, but the rules” for what makes something beautiful seem a lot more ephemeral, but usually related to elegance.”

For the code inclined among ye, when do you see code as beautiful? Do you?

This had a number of really interesting responses that I’ve been noodling on. If I was so bold as to condense them down, I’d say a connecting line between all the responses is utility.” In hindsight this makes total and complete sense — code ought to work. When I asked the question, though, I was in a really aesthetic frame of mind, so, was sorta surprised with how focused folks were on the code actually functioning over some aesthetic quality of the rendering of the code itself.

…but this may also be sign that my code is mostly garbage?

In my mind, regardless of what or how it works, C is less beautiful” than a lisp. There is an aesthetic to lisps that I find beautiful.

One respondent said,

I find code beautiful when it has an internal grain, a style of its own, whatever that style may be.

That struck me. I’ve read about the idea of code having grain” before, and find that an interesting way to describe the tactile nature of programming systems when compared to one another…C to lisp, forth to pascal.

Since the new year I’ve finished a few books. I’m trying to read more fiction than nonfiction this year. I re-read The Hobbit with the family, and an unremarkable, but enjoyable book, the second in a series, Eyes of the Void, by Adrian Tchaikovsky. I liked the first in the series better than this second one, but it was fun, and I’ll most likely end up reading the third installment soon enough.

715 Creeks by Cristin Milioti is a song that has been in heavy rotation while I work lately. It is a cover from Bon Iver’s 22, A Million.

Dithered image of a large cat with tufted ears sitting in a laundry basket. The basket has colorful play silks woven into it. The cat has a vacant, empty expression on its face. It’s 11 neurons are all firing, desperately trying to keep up with the pace of life.

I’m on a boat.”

A dithered image of a cat sleeping on a window seat. The window is surrounded by fairy lights, and a felt, dinosaur mobile hangs next to the window. It’s snowing outside. The cat appears peaceful, but in reality is an asshole whom I love dearly.

Snorlax leaning into the whole vibe of her namesake.

« Future Page 1 of 208 Past »