We’re still in the habit of asking people “How was your week/weekend?” or “What have you been up to?” But since every day is the same and time has no meaning anymore, I have no answers. Especially since most of the people asking those questions are colleagues or casual acquaintances. I’m not telling them about how I watched Rick & Morty s5 in one sitting, or all my computer problems.

Publications

I’ve had several poems published recently! Sort of a coincidence that the publishing schedules all lined up in this three month period, because they were all accepted at different times—one a full year ago:

I’ve also got 2 poems forthcoming in print in Poetry Salzburg Review, which will now be a Spring 2022 pub, rather than the Winter 2021 release that was planned. The editor recently posted that the master copy is with the printer, so… however long it takes to print then ship. (From Austria.)

Submissions

I was on a streak, submitting poems most days November–January. There are probably 30 submissions still awaiting reply (plus a few chapbook contests). 30 submissions represents about 150 poems, and with my lifetime acceptance rate around 3% of the total poems I submit, I can probably expect another 4–5 poems published.

No submissions since the end of January, though. After doing a clean migration to a new computer whose OS no longer supports PHP, I’m still redesigning my submission architecture. Big surprise, it wasn’t as easy as I made it out to be. More on this below.

This site

A few small changes here. I removed the About page, and added its content to the homepage. It didn’t seem necessary to have a separate page for my short bio and contact info while I had a homepage with no content except a headshot. Considering getting rid of the Contact info panel, since all that info is in the footer of every page.

I hate my homepage, actually. It’s boring, and I don’t think the elements really work together; it looks, I dunno, blocky. I need to spend some time revising. I also need a new headshot in advance of releasing the book, and since the current one is 8 years old.

On the Links page, all my poetry publications are now visible. I can’t remember now why I decided to highlight only some of them; it’s not like I have an unwieldy number of credits. Several of the journals & their websites are now defunct, and others were published in print, so many of my published poems aren’t available at all. Which brings me to my final update on this site, the Read page.

Read page

It’s not quite ready yet. Because I solved my single-sourcing issue, I now have all my poems available in the repo for this website. The plan is to use the Read page to display all my published poems that are:

  • unavailable because the journal folded.
  • older than one year (preferring to direct traffic to the journal until then).

But I can’t figure out the code to disallow pubs less than a year old

Dates are tricky in Liquid. I can’t just say something like if date ≤ ('now' - 365). In Liquid, you can only use operators (==, !=, <, <=, >, >=, or, and) within control flow tags (if, unless, case/when). But you can’t use filters in any of those tags to limit output; and most of the useful filters (like where) only act on arrays. Basically, it takes too much effort to compare dates. And Liquid (sometimes?) treats them as strings instead of numbers or, ya know, dates.

One solution should be to convert all dates to Unix time (the number of seconds since ), subtract the published date from today’s date, and ensure that number is greater than 31,556,926 (the number of seconds in a non-leap year). It’s basically how I wrote the Links page to say “forthcoming” if the issue hasn’t been released yet. But it’s not working, and I haven’t figured it out yet.

Of course, that solution will only reflect dates at the second I build my site, before pushing to the GitHub repo. Javascript should be able to keep all my date-dependent code current, but I’m only just now learning that language.

Migrating

My old computer was experiencing increasingly regular kernel panics (like a crash, but more severe because it’s related to the core program within your operating system), so I bought a new computer before the old one could brick on me. Because of the kernel panics, I decided to do a clean migration to avoid accidentally bringing over whatever corrupt file was fucking up the old computer. I thought it would be a good learning experience, but it was just a massive pain in the ass.

Users

I decided to implement the common security practice of setting up a standard user for day-to-day use, separate from the admin user you create when you first power on a new computer. The rationale being that Admin has access to everything on the computer, so if you get phished or download the wrong file, the scammer has full access; Standard users have a more limited scope, so a scammer can do less damage.

All that sounds great, but for people like me who use a lot of open-source tools, it requires updating PATH variables for every tool or language. This is usually poorly documented, if at all. It’s also scary because you’re running command line commands to edit configuration files. Entering the wrong PATH probably won’t screw anything up that you can’t easily fix, but there are other elements in those files that will fuck up your computer should you mistype.

Jekyll

I won’t get into all the details, but getting my Jekyll projects up & running was… infuriating. In theory, you just clone the repo from GitHub, but the gem theme directory structure complicates it.

Jekyll allows you to choose a theme (or skin) for your site, and while the project directory can be anywhere (like your desktop), the files for the theme are buried in the directory for whatever tool you use to manage Ruby (RVM, in my case).

I ended up moving all the necessary theme files into the project folders, then transferring the files over Airdrop. I have two projects that use the same theme (this site & my submissions project); with the gem theme directory structure, all those files are shared. Which I think is very stupid. Unless you want both projects to have the exact same layouts, headers, footers, & stylesheets, it only makes things harder as a user.

Dotfiles

Finally (and this was my dumb fault), I used a tool called Mackup to transfer my dotfiles. That temporarily fucked everything up because I continued to use the old computer. I didn’t realize (but should have) that Mackup was syncing those files (it uses your Dropbox or similar account). So I ended up with important config files being shared with both computers (oops) as aliases (shit). Fortunately, once I uninstalled Mackup, everything went back to normal.

The big thing that migrating forced me to deal with was my bad practice of maintaining multiple copies of my poems. To recap, I have three projects that might need to use my poems:

  • this site
  • the booksite
  • a setup for creating submissions

Two of those three had their own copies of each poem (I’ve been holding off adding poems to this site so as not to create another copy):

  • The booksite is another Jekyll project, so those poems needed YAML frontmatter.
  • The submissions setup on the old computer used the built-in Apache server, with poems written in HTML and compiled with a PHP template.

Given two different formats, they couldn’t have been shared. In some macOS update after my old computer wasn’t able to upgrade anymore, Mac deprecated support for PHP. Rather than recreate that setup, I figured I could use Jekyll to create submission documents.

I decided not to change anything with the poems in the booksite. They have custom frontmatter elements for navigation & notes that would be meaningless in another project. Plus, I want the booksite to remain static after I release it; I don't want any future edits to those poems to get pushed to the booksite.

To have a single source of poems, I tested Git submodules. But because Git is trash, it wasn’t a solution. First of all, the files in the submodule weren’t available in the superprojects I added them to—Jekyll basically acted like they weren’t there. And even if it had worked, that setup would have required me to run all of the following commands each time I updated any poem:

in the submodule (poems) repo

  1. git add
  2. git commit
  3. git push

in each superproject (repos using the poems)

  1. git submodule update –remote
  2. git add
  3. git commit
  4. git push

Finally, I remembered that another Jekyll Talk user suggested I look into symlinks. And they work seamlessly! I just ran the following Zsh command (in Terminal) for each project where I want the poems to be available:

ln -s path/to/poems path/to/project

And that’s it! All my poems are now persistently available in this project & the submissions project.

As far as I can tell, the only real downside here is that every poem gets pulled into the build, even the ones that aren’t being used anywhere. For this site, that’s kind of a pain in the ass, since the GitHub repo has to be public in order for GH Pages to read & serve it, and a lot of journals have strict interpretations of what constitutes “previous publication”. So I have to manually remove those files.

The booksite

No real progress here because of all the time I spent dealing with the new computer. I have some time away from work coming up that I plan to devote to the book; specifically communicating with a friend who works in book promotion.

BJJ

I'm a beginner to BJJ, which is a very complicated discipline, full of nuance.

Please contextualize my observations & opinions as those of someone who understands very little.

This week, I used a Kimura to tap someone in a roll while I had him in full guard.

That was probably a weird sentence for anyone reading this blog, so let me break it down:

  • Kimura is an arm & shoulder lock, named after Masahiko Kimura (regarded as the judo GOAT).
  • tap means I submitted my opponent—I made him tap.
  • roll is a spar, or a practice fight.
  • guard is a position. When I’m on the ground and my opponent is above me, I’m “in guard”.
    Full guard means I’m on my back with my legs around my opponent’s torso and ankles locked; here, my opponent is “in my guard”. (Counterintuitively, if I have an opponent in full guard, I am in the advantageous position.)

I’d never managed it from that position, so I felt like a total boss. The Kimura (or the similar Americana) is my favorite submission; I go for it a lot, mostly failing. I’m trying to master them because (from my inexpert perspective) one of them is available from pretty much every position.

Mostly, I got my ass kicked again this week. I’m very sore because one roll was with a black belt, and he basically decided what my body would be doing for those three minutes.