Ben Crowder

Blog: #blogging

19 posts :: tag feed :: about the blog :: archive

Small milestone I almost forgot about: this website turned twenty this year.

January 23, 2001. It’s possible I started it before that day, but that’s the first reference to it I’ve found in my journals.

Tinkering on the site all these years has been a delight. Truly one of my favorite activities.


Reply via email or via office hours

A couple quick updates:

Today was my last day at Cedar (formerly OODA Health before the acquisition), and on Monday I start a new job at Hologram.

I’m finally getting around to writing Cast, the new backend engine for this site. The plan is to go full static and deploy via Render. Also planning to move my personal apps over. While I’m still probably a couple months away from having everything migrated, I’m so, so looking forward to not maintaining a personal server anymore. (It’s fun, sure, and I’ve learned a lot, but it’s stressful — yesterday’s Let’s Encrypt root certificate expiration bit me thanks to an old OpenSSL version, for example — and it’s no longer something I want to spend time on for personal projects.)


Reply via email or via office hours

For those subscribing via RSS or JSON Feed: I’ve added the post tags to the top of each post, mirroring what you see on my site.

(My reasoning for including the tags and putting them at the top, by the way, is to make it a little easier to see at a glance what a post is about and whether you want to skip it.)


Reply via email or via office hours

I seem to have forgotten how to blog. (Actual blogging, as opposed to merely linking to new art.) In an attempt to get back on the saddle again:

Outside of art, my project time lately has primarily been swallowed up by some internal tooling changes. I alluded to this back in June, though the plan changed along the way. Rather than merging all those apps into one behemoth conglomerate, I decided it would be better (along at least a few axes) to follow the Unix philosophy and stick with smaller tools that do one thing well. Which conveniently lines up with the set of tools I’ve already built. Fancy that.

Arc is (was) my notes app, written using FastAPI. I wanted an app that felt more a wiki, and I wanted to move it to Django (easier to maintain, considering most of my other tools are also in Django). And I didn’t really like the name anymore. Thus Codex was born. Heretically, I built it using hardly any JavaScript — just a bit for keyboard shortcuts and another bit for the autosuggest when linking to another page. Everything else uses plain old HTML forms.

In fact, it was so liberating and fun that I plowed onward and decided to ditch Vinci (my internal blog/notebook app) and build a new app, Leaf, using the same technique; the only JS it uses is for keyboard shortcuts. It’s simpler, easier to maintain (I think? it’s still early on), and in a way it feels more in line with the grain of the web.

One other thing I did differently with both apps was to wait to write any CSS until after the functionality was all in place. It was disconcerting and delightful, building something with bare browser styles, and it certainly helped me focus on functionality first rather than getting distracted by layout.

Conclusion: while I doubt I would ever build apps at work this way, this old-school mode was invigorating and absolutely worth it for these personal projects.


Reply via email or via office hours

Blog-driven productivity

New experiment: blog-driven productivity.

Ordinarily I work on projects and then, when they’re done, I post about them. Occasionally I post about work in progress (something I’m trying to do better at as part of working in public). In both cases, though, the project work comes first.

This idea flips that around: start writing the blog post first, from the perspective of your future self after you’ve already finished the project. Then do whatever backfill work is needed to turn the post from optimistic lie to settled truth. (And when the work is actually done, publish the post.)

My brain tends to think of it as an extremely loose analog to test-driven development in software engineering.

It’s not anything particularly novel, but it intrigues me and who knows, maybe there’s something there. (In some cases, for some people, your mileage may vary, etc.)


Reply via email or via office hours

Links #41

Rob Weychert’s Plus Equals, a new zine about algorithmic art. The first issue was good, looking forward to future installments.

Riccardo Scalco’s Textures.js, SVG patterns for d3.js. Yum. I don’t even use d3 (at least not right now), but I’m tempted to do something with it just so I can use these.

Jason Kottke on the invention of a new pasta shape. Max sauceability as a concept will stick with me for a long time, I think.

Rytis Bieliunas on some of the darker corners of Go (the programming language). I’m writing a lot of Go at work now and this was helpful.

Austin Kleon on blogging as a forgiving medium. The idea of continually editing and refining posts after publishing them intrigues me. I fix typos if I find them, but that’s about it at the moment.


Reply via email or via office hours

Release bundles reborn

Starting now, I’m going to batch releases of my art/writing/etc., posting things only at the beginning of each month. I did this back in 2014–2015 for four or five months, and I think it’s a good fit for me again.

Arbitrary reasons for doing it (acknowledging that it would be just as easy to argue convincingly in the other direction):

  • To focus more. By not thinking as often about posting work (speaking mainly of art here since that’s primarily what I’ve been doing lately), I’ll hopefully be able to focus more on the work itself and less on its reception.
  • To slow down. Being able to release finished work immediately is a magical and wonderful part of the Internet, but I think some detachment can be helpful, giving ample time to assess and reassess the work and to polish it further before finally posting it. (I have regrets. Not many, but I do have some.)
  • I don’t know that batching will actually make this happen, but: to work more on somewhat larger projects that take more time. My current working theory, however, is that immediate release cycles encourage me to optimize toward projects I can finish as quickly as possible. The experiment is to see if slowing the release cycle down makes an actual difference there or not. It may not. I may just be lazy and ill-suited for large projects.
  • To write more blog posts that aren’t just release posts. Or, failing that, to at least make the blog feel less like a neverending train of releases and navel-gazing meta posts. (I do believe I’m yearning for the old days, when I wrote “real” posts. We’ll see if the essayist in me still lives.)

Rules I’m arbitrarily giving myself in this experiment, and other tacked-on miscellaneous thoughts that I didn’t want to start a new list for:

  • I’ll post each bundle on the first day of each month, or the second day if the first is a Sunday. (I’m calling these batches “release bundles,” by the way.)
  • A project has to have been finished for at least a week before I can release it — so anything finished during the last week of the month will go out a month later.
  • There’s no set end date for now. If it works well, I’ll hopefully keep doing it for a long time. If it inhibits the old creativity, I’ll stop.
  • I’m not sure yet whether I’ll write about in-progress projects during the month. Lately I’ve found myself harboring some misgivings about working in public, or at least some parts of it, and I need to soul search and figure out what I’m comfortable with and what makes the most sense for me and my introvert self.

Here we go. Next releases will be on March 1.


Reply via email or via office hours

Links #27


Reply via email or via office hours

Links #16


Reply via email or via office hours

Just wanted to say thank you to all of you for reading this blog. I realize the time you spend here is a very small sliver of your lives overall (hopefully!), but it’s still time you could have spent elsewhere. Thank you.


Reply via email or via office hours