TL;DR I wanted to do more with plugin development because I’m interested in implementing plugin architectures. Here’s the repo for the notes plugin, and here’s the page for Kanboard’s plugin registry.

Why would you make yet another note taking app?

  • I wanted to learn the ins and outs of Kanboard, my task tracking app of choice that I self host in my homelab.
  • I wanted to get into writing plugins for things so I could show how useful and awesome plugins are.
  • I wanted to see how others had implemented plugin architectures and see what I liked and didn’t like.
  • I wanted to use this myself as a replacement for Notes ‘N Todos app I had previously installed.
  • I wanted to release more software this year.

There’s a good reason that there are so many note taking applications out there. It’s because it’s a relatively simple product to deliver when learning new or unfamiliar technology. That’s why I choose to make a note taking app as my first foray into Kanboard plugin development. I learned a lot from creating this plugin and I wanted to share a few thoughts about my experience, what went well, and what I would like to see improve.

What was it like to write a plugin for Kanboard?

I think my biggest takeway from making this plugin was that the PSR-11 IoC container is a fantastic interface that makes plugin systems like Kanboard’s easy to develop. By allowing developers to have a globally injected object, you get the benefit of availability that comes from global state with none of the drawbacks. Furthermore, by allowing this container to be accessed by plugins you create a system in which all functionality could be written as a plugin. That’s the kind of system that I want to build at some point this year, but until then I’ll be content having worked with Kanboard’s plugin system. At the very least, starting my plugin focused project will allow me to work with IoC containers in a language other than PHP.

What was it like to work with PHP in 2023 and 2024?

Not too bad, but there are some pain points that come directly from PHP. First, the dollar sign prefix is silly. I understand it’s necessary to carry forward because a design choice was made early on, and any change to it would cause all previous codebases to break. It’s still not fun to debug and chase down a weird syntax error ultimately caused by a missing dollar sign. That being said, modern IDEs (PHPStorm) make this point pretty much irrelevant. Debugging was also an issue, and I didn’t really find a good way to inspect state without using echo var_dump(some_var). It worked well enough and it was much less painful to debug this way than it would have been to get XDebug working and exposed outside of the docker host I was developing on. It’s on my radar for a second go-round to fix this particular issue, but for now I think it’s good enough to just var_dump.

What will happen to your Notes ‘N Todos instance?

That’s a good question, I have already retired it after moving my notes from the markdown files to my Kanboard database. I initially set up my Kanboard instance with SQLite and that worked well for a long time, but I wanted to consolidate and use a more scalable database at some point so I migrated to MariaDB before migrating my notes. Once I had migrated my notes, I just shut down my notes instance. Unfortunately, my redirecting middleware service isn’t set up yet so going to the notes instance url just pulls up a bad gateway page. In the future, I want to create a custom 404 page that will redirect to another service if it’s defined. I have an idea of wanting to animate a gopher digging in a chest to see if it can find “the right host”, and then returing it visually if it exists or shrugging otherwise. I realize that’s a big stretch goal, but I think it could be super cool.