I've used vim and variants since 2001. In 2019, a friend introduced me to coc.nvim, which turned out to be my initial gateway to nvim, which I adopted a year or two later.

Yesterday, I discussed vim-surround. Today I'm going to discuss another plugin I've used a ton: tabular.

I've blogged about vim a number of times. I've been using vim or its descendents for 22 years now; I switched to neovim a few years back, but it's compatible with the existing vim ecosystem. (The primary differences, to my mind, are that it has a more optimized engine which is more performant, and that you can now configure and extend it using Lua if you want. Otherwise... it's just vim.)

I used to "collect" plugins, but at this point, particularly since switching over to neovim, I've reduced my plugins quite a bit, to only those I use on a regular basis.

So, I figured today, I'd start a mini-series as part of my Advent 2023 blogging, on some of my most used plugins.

Today's plugin: vim-surround.

I've mentioned a few times over the course of this 2023 Advent series that the longer I'm in the tech field, the more I appreciate and favor simple solutions. I was reminded of this yesterday when I read this article on return types in Laravel controllers by Joel Clermont.

A couple days ago, I wrote about Makefile. Today, I'm going to show a quick tip for writing "guard" targets.

Halfway through advent; half to go!

This will be a short post, to detail an invaluable tool I've been using for around 5 years now: Nextcloud.

I like to automate common workflows when I can, particularly for web projects. As an example, I may have different Docker Compose setups for development versus production, and having to remember to add the -f {compose file name} argument can be tedious and error prone.

Being a long-time Linux user, I've used make a lot, and am fairly comfortable with Makefile, so I often turn to it for these tasks.

I've mostly taken database abstraction for granted since I started at Zend. We had a decent abstraction layer in ZF1, and improved it for ZF2. There were a lot quirks to it — you really had to dive in and look at the various SQL abstraction classes to understand how to do more complex stuff — but it worked, and was always right there and available in the projects I worked on.

In the last couple of years, though, we came to the realization in the Laminas Project that we didn't really have anybody with the expertise or time to maintain it. We've marked it security-only twice now, and while we've managed to keep it updated to each new PHP version, it's becoming harder and harder, and whenever there's a CI issue, it's anybody's guess as to whether or not we'll be able to get it resolved.

My alternatives have been straight PDO, or Doctrine DBAL, with the latter being my preference.

The first thing I was tasked with after I moved full time to the Zend Framework team (17 years ago! Yikes!) was to create a forms library. Like all the work I did for ZF in the early days, I first created a working group, gathered requirements, and prioritized features. There were a lot of requests:

• Ability to normalize values
• Ability to validate values
• Ability to get validation error messages
• Ability to render HTML forms, and have customizable markup
• Ability to do nested values
• Ability to handle optional values
• Ability to report missing values

and quite a lot more. But those are some of the things that stuck out that I can remember off the top of my head.

Zend_Form was considered a big enough new feature that we actually bumped the version from 1.0 to 1.5 to call it out.

And, honestly, in hindsight, it was a mistake.