One of the whatsapp groups I am in stopped receiving my messages. In the end, I was kicked and invited back in, and my messages went through again. The weirdest thing was probably that they could see me type and some web clients would still receive my messages. For a while I thought I was shadow banned by whatsapp. 🙄

This should be the final nail in my Whatsapp coffin.

Today I removed all code related to bookmarks from Mirage and concluded the migration from all the bookmarks into the notes table. I got the feeling that I was duplicating a lot of code while thinking how I want to approach saving syndicated versions of posts on my site.

I wanted to create a table note_syndications and an schema to go with it. But I would need to do the same thing for bookmarks as well and when comparing the notes and bookmarks schema, there was not much of a difference between the both.

So I decided to completely remove the bookmarks code. Before that, I copied the missing fields from bookmarks, bookmark_of, like_of and repost_of over into the notes schema and added a database migration for them.

I then thought of creating a migration to automatically convert all my bookmarks on the production site into notes, but there were only about 15 bookmarks to convert, so I just did it by hand. Afterwards I wrote a migration to drop all bookmark-related indexes and tables and then deleted all the code.

I hope I made the right decision and don’t create a huge big ball of complexity in the notes schema, but de-duplicating a lot of code sure felt the right thing to do.

35 changed files with 21 additions and 1212 deletions

Today I reworked the hook system in Mirage. I knew from previous attempts that after creating a posts I needed to do certain things, like sending webmentions or syndicating the note to other platforms. That’s what I created the hooks module for. It will be called when a note is created or updated and will execute a list of actions.

At some point, I had lost track of what how it was supposed to work. I started executing the hook actions when publishing a note 1. I also added a hook action which published the note.

So the flow would be like this

  1. Create a new note, add some text (Hooks get executed)
  2. Update the note, add some tags (Hooks get executed)
  3. Publish the note (Hooks get executed)
  • Publish hook action gets executed, publishes the note again?
  • Goto 3.?

It’s still not really clear to me how this worked and did not blow up in my face 2, but I decided to have two separate hooks with different actions:

  1. Create/Update Hook
  • Update note tags
  • Create Syndication objects
  1. Publish Hook
  • Send webmentions
  • Syndicate note

This way, I can cleanly separate the actions which need to happen only at publishing from the actions that are only an extension of creating or updating a note.

There is still a few tests that need to be written, but this new hook module makes the whole process at least more easy to understand.

  1. ↩

    Which is a fancy way of saying “Set to published_at date to now”, so technically it’s an update of the note.

  2. ↩

    And I didn’t bother going down that rabbit hole.

I feel like I never too the time to look at my CSS and think, “How could this be organized?” Styles always felt.. different when it came to organizing them, as if it was not that important to organize them.

Today I looked around and quickly found a thing called 7-1 pattern. It is a way of structuring your css in a folder-based way.

Seven folders are recommended plus a main.css that’s only importing the other files. The 1-part is about putting exactly one logical piece in one file. So, in layout, you might have header.css, footer.css, wrapper.css in layouts and in components button.css and post-list.css.

I won’t go into more detail but what struck me is that this is the kind of structured and opinionated structure that I enjoy so much about Phoenix. Most of the time, you don’t need to think where something will go, because there is a place for it already and all its friends are there, too.