Paranoya or common sense?

It’s only recently that I started paying close attention to digital hygiene. In fact, I clearly remember the feeling of lingering sticky anxiety learning about IT security at the uni. We were given multiple assignments to ‘hack’ things. Reverge-engineer a binary to crack the password by utilizing a side-channel attack or decipher a message encrypted with AES-256 (widely used today) in the CBC mode. The hacking part was extremely fun. The realization how easy it can be given enough time and resources was not. Before the uni course was over, I had changed all my passwords to randomly generated and set up 2FA wherever possible. The paranoya was real.

https://github.com/Kristina-Pianykh/go-shell

Why?

There are certain things that every programmer must build. Opinions differ with regard to what such these things are supposed to be but my “bucket list” includes a CPU emulator, a compiler/interpreter, a small operating system, and a shell. I’ve done an emulator of a RISC-V processor and a very shallow and patchy version of an interpreter at the univirsity (both in C) but the shell part escaped me. Back then it was a pretty ambitious task for the time we were given to implement it and it was surely way over my head. Guess the implementation language for the true UNIX experience with all the classical concepts like process forking and file descriptor duplication for pipes (spoiler: it was also C). I was quite overwhelmed and had to eventually abandon the task. Now, a few years later, I could finally get back to it, only this time I chose to do it in Go. Although arguably a less conventional choice of a language for this purpose, I’d set the goal of extending my Go knowledge for professional purposes but I also consider it rather efficient to DO THE THING FAST while not getting entangled in language design features.

Advent of Code is famous in the developer community around the world for providing a perfect setting for learning a new langugage. After all, we all know that no amount of books and documentation reading can do you a better service than the good ol’ coding practice (altough RTFM still holds). As a control freak, I like prepping before a challenge. And by that I mean, I LOVE prepping. And I go hard on it. I’m aware that it’s my academic past speaking in the foolish attempt to control uncontrollable but I often can’t help and keeping myself on track to solve a problem without side-tracking to investigate all potential rabbit holes along the way can be a challenge in itself. That’s why before embarking on a journey with learning Golang by solving AoC 2024 this year, I decided to have a look at the puzzles for last year to know what’s coming. And I did it in Java (yes yes don’t hate) to build on the flow following from my thesis project¹.

I’m a big fan of CLI tools. There’s something about a terminal (emulator) that feels so damn special. I still remember the excitement I felt when I edited ~/.bashrc for the first time to create a command alias or modify the PATH. The simple commands I entered had an immediate effect and it felt like magic.

With time, I learnt how to manage my bash dotfiles, how to update system packages, where to configure newly installed open-source tools. It made me learn about my environment and where to look if I get an error. I learnt the importance of automatization in the development process (aka building your own development workflow!) and the importance of maintanance. After I nuked my root with the cursed rm -rf / command on WSL2 by failing to perform auto-complete and entering it way too late to remedy the situation but well in time to realize I’m in a pickle, I had to go through restoring my entire environment. And this is when I decided to take a more organized approach to managing my dotfiles. Today I use the home-manager to declaratively define my environment, Oh My Zsh instead of bash, kitty as a terminal emulator and of course neovim (my love, always) as a code editor.

On Java LSP support and editor¹

A note on IDE. I use neovim btw but that was until God blessed me with Java. Is what you probably expect me to say. And indeed setting up a Java LSP for neovim turned out as difficult as they say. I abondoned my beloved code editor and asked daddy aka my employer for a premium license for IntelliJ. I spent a bit of time rewriting some of the most basic functionality from neovim config in Lua to Vim script to still benefit from Vim motions in the IntelliJ IDE. I have to admit the IDE made many things easier but after a while I still turned back to neovim. Buckled up and divided into the LSP setup once again. I ended up with java-language-server (as opposed to the more popular jdtls but it gave me the most basic things I needed: code diagnostics and quick remedy strategies (hashtag lsp_code_actions), signature help, autocomplete suggestions, etc. Although granted, there’re still many things I’m unhappy about (e.g. symbol signature and third-party code, more stable cross-project referencing) but this is most likely due to a skill issue.