Python

This year I really worked a lot on Python web technologies so I came to appreciate all the work that the JetBrains team does to make all the little things (like running Django test server commands) incredibly easy. I essentially did all my Python development in Pycharm.  I’ve had access to the paid JetBrains suite because of the work I’ve done for my open source project: Extra Life Donation Tracker. Since development has slowed a bit on there, I may not be able to renew the subscription. If that’s the case, there’s a big chance that I’ll start saving up some money for a Pycharm Professional license. The only real exception to using Pycharm for programming was when I was editing code on a server. There I would use vim or nvim (more on that later).

I wrote about GitQlient a while ago. A few days ago I got a GitHub notification that GitQlient had finally reached 1.0. Consequently, the author created an Appimage version of the client so I was finally able to try it without having to compile on my own. As I started taking screenshots for blog post, I realized that the points I wanted to make would be more easily made if I could show them via a video, so I made a video comparing the two.

This used to look pretty regular. Just two parallel lines with the devel branch connecting into the master branch here and there. But then I merged master into devel because I added issue templates on the github website directly into master. Things got….interesting….

Here’s the before (but a few weeks ago):

git before merging master to devel

Here’s what it looks like now:

git after merging master into devel

When I wrote about checking out KDevelop, I mentioned that it was due to a blog post by the Kate developers about how to evolve Kate going forward. Last night I came across a new article in the same vein in which they looked at potential git GUIs to use from within Kate. In my KDevelop post, I mentioned that I use QGit, but it can look a bit small in the screenshot of my 3 monitor desktop. So this is my typical QGit setup:

When MakeMKV added a new requirement for ccextractor, allowing it to grab subtitles that are encoded on the DVD or Blueray as Closed Captioning instead of subtitles, there wasn’t a package available for Fedora. (There is now, but at the time where wasn’t) So I wanted to make an RPM that I could host on Fedora’s COPR for others who needed the package. There was a problem with their shell script for building RPMs. At the time I just kept hacking away at it until I was able to build RPMs. But I didn’t think about how the manual process wouldn’t be sustainable as changes were made to CC Extractor. They weren’t having releases too often, so I didn’t worry about it. But then they made a new release and I knew that this time, having leveled up on my git-fu, I would try and figure out how to fix that problem and submit a pull request.