Software I used for Programming in 2020

vim

I last wrote about the software I’m using while programming back in March.  I think at the time I was thinking of writing quarterly updates, but my preferences didn’t change with that much regularity. I decided to make it one of my annual posts instead. So here is the software I used in 2020 to program.

Python Projects

PyCharm

For my Python projects I transitioned fully to PyCharm Community Edition. I documented my reasons for moving towards Pycharm in this post with a followup here. As I was writing this, I learned of a Real Python guide to Pycharm that taught me a few things I didn’t know about how to make better use of PyCharm. PyCharm has made Python programming a real joy. For any libraries I have imported (or standard libraries), it provides excellent code completion as well as context for function or method arguments that saves me time vs looking it up in documentation. The git integration is also great and I’ve recently started exploring usage of the lower git window which may make GitQlient obsolete for my Python projects. I haven’t made the best use of the debugger yet, but I’m slowly learning how to take advantage of it in my larger projects. If you’re a Python programmer I can’t imagine a better IDE. I did have access to Pycharm Professional for a while in 2020, but I wasn’t doing any Flask or Django work, so I didn’t really notice anything useful over the community edition.

Mu

I use Mu when I’m working with Circuit Python for my Adafruit boards. Mu would probably be really awesome if I hadn’t started using Pycharm. It’s about equivalent to Kate as I’m using it in Fedora 32 (more on that in another section below). It will provide word completion for words that I’ve already typed, but has no understanding of the libraries installed on the board. Also, (and I have no idea if there’s a reason it’s implemented this way) I’d love it if the programming was a little more Arduino-like. That is so say, programming on my computer and then transferring it to the device whenever I asked it to. Instead, the default is to edit the code on the device and reload the device when I hit save. This means to save my files and put them under git control, I have to keep remembering to copy the file off the circuit board and onto my system. 

This may seem that I’m really hating on Mu. Don’t view it that way. I’m merely wishing there was something with the power of Pycharm that could do what Mu does. Because Mu does provide some valuable services when programming in Circuit Python. It provides easy access to the board’s REPL without having to do any work to figure out how to connect to the REPL in the Linux console. It also provides the ability to graph outputs from within Mu. I used it quite a bit this year on my Circuit Python projects and expect to use it quite a bit in the coming year.

Unity/C#

Rider

If you’ve read through this blog post in order, you know that I really love using PyCharm. So when I got back into C# programming with Unity this year, I figured I’d give Rider a shot. I blogged about my experience setting up Rider and Unity on Fedora (using flatpak). I didn’t end up getting much use out of it because Unity decided not to open my project once I added in the inputs plugin. In the end it doesn’t matter because, from what I can tell, Rider does not have a community edition. That is fine. I’m sure *most* folks programming on Unity are either real studios like Ghost Town Games (makers of Overcooked) or bedroom coders, since that’s a thing again thanks to the indie scene. JetBrains deserves to get money for their product. Since I’m not developing for money – just for fun – it doesn’t make sense to spend professional IDE money, especially when there are free IDEs that work just fine with Unity. IDEs like Microsoft Visual Studio.

MS Visual Studio

I continued to use MS Visual Studio on Windows when doing Unity C# programming. In the latest class I’m taking the professor is using Visual Studio Code, but the shortcuts seem to be the same, so I didn’t see a need to install VSC when plain old Visual Studio was working just fine. I’m just barely taking advantage of any of the Visual Studio features – definitely not using any of their git features. But it works perfectly fine. If I were doing my Unity programming on Linux, I’d probably use VSC since it’s cross-platform.

Arduino

Arduino “classic”

I didn’t do too much Arduino programming in 2020, but when I did – the classic Arduino code editor was just fine.

Arduino Pro

I really, really want to use Arduino Pro. It has a much nicer looking interface and is version control aware. That said, it’s still in alpha or beta and never quite worked for me in 2020. I always ended up going back to the classic editor.

Language-Independent IDEs

Kate

In 2020 I mostly used Kate for learning Ruby. It’s also a lot faster and less complicated for my short Python programs than Pycharm. In fact, for short scripts, Pycharm’s project-focused workflow actually gets in the way. So I have used it a bit for short Python scripts as well as for the practice problems in various Python books. It’s always great for a shell script, too. However, I usually end up writing those in a vi clone. They almost never seem complicated enough to spin up a GUI program for.

Last March I mentioned that the Kate developers were working on making Kate more of a Visual Studio Code competitor. They were working on implementing a good LSP Client (if I understand correctly, this is what allows Pycharm to make suggestions based on the packages I’ve imported) as well as better git integration. As I write this, I still haven’t upgraded my main desktop to Fedora 33 and the LSP software needed to make this work with Kate and Python hasn’t been ported to Fedora 32. So I can’t speak to how well this works. I suspect it could only make things even nicer when working with these shorter Python scripts. As for other languages I’m thinking of learning, like Go and Rust, as far as I know they aren’t supported especially well in KDevelop. So if Kate ends up with better LSP tech, I may end up using it for those languages.

Vim

In 2020 I went all in on my conversion to becoming a vim native. I haven’t used Emacs in ages and vi or vim was always conveniently there on any server I sshed into. I started reading the O’Reilly Vi/Vim book that I got in a Humble Bundle so that I could get a little more proficient at the command line. I also set up powerline so that it could be a little more immediately clear to me which mode I was in.

Neovim

When I was doing a lot of research into Vim, I discovered Neovim, which was developing at a faster pace (and more openly) than Vim. So I installed it to check it out. I should probably alias vim to nvim because I keep forgetting to use Neovim. I should also probably install a syntax highlighter like Semshi and maybe an LSP plugin. Right now, for *my* use case, I don’t really get any benefits over vanilla vim.

Chrome for MS Make Code

I’m including this only for completionist reasons. When MS Make Code is done in the browser and works best with Chrome (or a Chromium-based browser). So I used it when working on MS Make Code projects with the kids.

Git

gh CLI 

I touched this once or twice in 2020. I’m sorry to say I haven’t quite figured out what I’d want to do with github in the CLI that I wouldn’t want to go to the website for. If anyone comments with some use cases, things may change in 2021.

GitQlient

GitQlient continued to be useful to me for visualizing what’s going on with my most complex projects. Those have many branches, tags, etc. That said, at the moment, my most complex projects on Linux are Python projects. So I may start using Pycharm’s git features a lot more and GitQlient may fall to the wayside for a while.

Git Kraken

On Windows I have fully moved over to Git Kraken for my git needs. There is really only one thing that’s a pain compared to SourceTree – starting up my repo. Unity doesn’t want to go into a folder that already has files. Git Kraken seems to have similar issues when I try to create a repo into a Unity folder. Outside of that, everything works great. 

Gitea

I continued to use Gitea to host code locally when I wanted to be able have a Github-like interface, but didn’t want the code to be public. For now, I continue not to see a need or reason to self-host a public Gitea instance instead of just using Github. Any contributors will already have a Github account and it’s just simpler this way. That said, Gitea continues to improve and add great features.

Continuous Integration/Continuous Deployment

Drone

As I did last year, I am still using Drone for CI/CD of my private code. It allows me to do automated checks with a clean environment upon check-in of my code. And for one bit of code, allows me to publish to PyPi. 

Github Actions

I make heavy use of Github Actions on my big, public projects. It allows me to not only run unit tests, lint, and code coverage, but also to create binaries for Windows and push my code to PyPi. I don’t have any compiled code projects on Github yet, except for Unity. Apparently this exists. I think that would be interesting for cross-compiling for various build targets. I think it’d be interesting to see how well Github actions would work with Rust or Go.