I meant to write about this last month, but as it is I’ve just barely managed to get to it this month; Excuse poorly written blog post; Perhaps I should have titled this “The hardest thing about blogging is finding the time” instead?
This maybe blurs the lines a bit between work and personal, but it’s open-source so I can’t see there is anything wrong in me talking about it.
I recently managed to close a seven year old issue on the Compose Transporter repository asking for a MySQL adaptor. Putting aside the natural decline in Compose since acquisition, and thus there will have also been less of an external interest in Transporter, that’s still seven years for anyone else in the world to have had found time to do this - including people inside Compose and IBM; And there are some damn clever people on that issue.
As much as I probably should be selling myself and saying “I’m a great programmer” and “It needed me to make it happen”, neither of those statements are true (sigh) and there isn’t actually anything special about me - I only first started with Go in 2018 and I do not necessarily use it day in and day out. I.e. anyone else could have done this. All that had to happen is for a brief few months a manager decided we should focus on Transporter again and specifically Postgresql and MySQL; Despite the dearth in activity on the repository over recent years we had still been making good use of this internally for migrating MongoDBs between platforms.
And that was it. Since I was literally being paid to work on it I managed to go from nothing to a good first adaptor - it’s as least as good as the existing Postgresql adaptor; Maybe a bit better as handles geospatial data. I even had time to work on changes to the mysql driver we were using.
Unfortunately, as is typical in organisations, priorities and focus soon shifted and no one is working on Transporter again and who knows if or when I’ll be able to add bulk write support to the MySQL adaptor.
What I like most about this “story” though is that you can follow the commit history from that PR/branch along and see how I did it: Lots of little baby steps. I basically copied the Postgresql adaptor file by file and it was very much test-driven-development - adapting each Postgresql test to MySQL and then using to test to help develop the code. That and reading Postgresql and MySQL documentation. Like I said, anyone else could have done this if they had the time.
This reminds me of my ncurses learning project where you can also follow the commit history along and see how it developed from something else.
Abrupt ending to poor post because I just need to get something out this month.