EngiNerd.io

Full Stack Engineer who speaks JS/TS, Python, Go, and a bit of C. I build web apps, automate the boring stuff, and occasionally make bots just for fun

My Favorite Dev Environment After a Decade with VSCode

My Favorite Dev Environment After a Decade with VSCode

For a long time, I considered my development environment on VSCode to be quite convenient and productive. I configured LSP servers, mastered many shortcuts, and tried to use a minimal number of plugins — instead relying heavily on native tasks. It seemed like it couldn’t get any better — my productivity was at its peak.

But earlier this year, I became more interested in how other developers set up their development environments, for example, ThePrimeagen. After that, doubts started to creep in: maybe I was far from true productivity...

I had been using VSCode for 10 years, but at the end of January this year, I decided to try switching to NeoVim — to change my habits and fully tie my development environment to the terminal. This radically changed my perspective and understanding of how a development environment should be set up and how flexible it can be.

Zig Devevelopment Environment Setup on macOS/Linux

Zig is a relatively new programming language that's often described as a better version of C. It's fast, simple, and focuses on performance and safety, which made me curious to try it out. If you're interested in Zig and thinking about setting it up in VSCode on macOS/Linux, here’s what I went through while setting up my development environment.

Fast and Ineffective Hugo

I've been using Jekyll for quite a while now, probably around 7-8 years. I'm not exactly a very active blogger, and I don't have any complaints about Jekyll in terms of generating documentation - usually there is no more than 100 pages. Yes, sometimes it can be quite slow, especially with complex Liquid constructions or if there are a lot of images, or if you're using the Kramdown parser instead of CommonMark. However, Jekyll's slowness is typically not critical, as sites are not built frequently, and one or two minutes don't really make a difference.

Recently, out of curiosity, I explored the range of popular static site generators (SSGs) - who knows, maybe there's something out there that's as stable and mature as Jekyll but with better performance. Hugo, Astro, and 11ty caught my attention. Since I'm not a fan of products that go down the path of excessive universality, like a Swiss Army knife with everything you need but with lots of drawbacks, Astro and 11ty were ruled out. That left "incredibly fast" Hugo, which I decided to try out and see if it lives up to its reputation as described in various articles. Hugo does indeed boast impressive performance thanks to its implementation in Go, and according to some, it has an "insanely awesome" templating engine based on the Go html/template package.

Amazing Node-RED

Oh, if only I had touched Node-RED earlier. With this awesome programming tool, you can automate everything... well, almost everything. Yes, it is not for everyone, an ordinary user who does not understand the basics of networks and does not know JavaScript will probably prefer IFTTT or Zapier.

How much I have been messing with IFTTT over the past few years, with their constant introduction of new limits, offering a subscription, and other crap. As soon as I raised a docker container with Node-RED on my raspberry pi 4 and I've got so many possibilities and had so much flexibility that I can never see on IFTTT or Zapier. Especially with a dedicated IP address, the possibilities in terms of IoT automation in conjunction with various APIs and online services are almost limitless.

Goodbye, Gromozeka Bot

The Gromozeka bot was implemented to assist Telegram users in deleting all of their messages from a chat, channel, or conversation, even without admin privileges. Official Telegram clients lack a straightforward solution for a mass message deletion, requiring users to manually select and delete messages, with a limit of 100 at a time. Gromozeka bot was aimed to solve this inconvenience.

The bot's implementation involves creating and storing a user session on the bot's side, posing a security concern regarding potential misuse by the bot owner. While it's reasonable for Telegram to prevent unauthorized user session manipulation by a bot, my implementation addresses this issue. Although not flawless, my solution ensures that only the user can utilize the created session.