DEV Community: milkias17

Programming Saved Me Days of Tedious Work

milkias17 — Tue, 13 Jun 2023 18:25:31 +0000

Banging your head against the wall, trying to understand this horribly written and incomprehensible code of the legacy system? Well we've all been there and most of us are probably there right now. These days, due to the tedious tasks we often do as programmers, we often forget how beautiful and just joyful programming is. Well today, I'm going to share how a very simple ~30 line script saved me so much time with basically no effort.

The Problem

So I recently acquired a large library of spiritual songs from a friend of mine(close to 20GB), and it was amazing. I had basically any song I would want to listen offline right there in my laptop, so whenever I'm coding or doing pretty much anything on my computer, I'd open up the music in my favorite media player. However, there was one huge annoyance I accumulated over using the library over the past couple of months, the problem was the metadata of the media files was non-existent. Meaning I couldn't use my media player, say to play only songs of a particular artist(which was my main gripe), or sort based on the artist and so on.

The Solution

It's possible to edit the metadata of media files using software but of course editing each file in a 20GB directory is just not worth any amount of annoyance. Of course, if you're a programmer you already know where I'm going with this, I just wrote a small script that goes through each media file, and edits the artist metadata(which it gets from the directory name) and vuala, in just under a minute, the script updated the metadata of all files in 20GB worth of media files. Here's the code if you'd like to take a peek:

Ending Thoughts

Now, was this a groundbreaking and incredible piece of code, of course No. This was a very trivial piece of code anyone could write, but the utility I got from such a simple script is the point of this article. Programming is beautiful, yes sometimes it can be a big pain in your life, especially when working with something that doesn't excite you, but always remember those things that made you fall in love with programming. It is such an amazing tool, and is probably the closest thing that we have to a superpower, so let's all take a moment to appreciate how lucky we are to be doing it!

My recent side project

milkias17 — Tue, 06 Dec 2022 14:11:53 +0000

Introduction

Hello, hope you are doing well. Today I'll be telling you about my recent side project, mchess. The idea was to create a simplified chess website in the veins of lichess.org or chess.com for example. So the website should allow you to play chess offline locally and online against someone over the internet. I wanted to expand my knowledge on all fronts so I decided to create the whole thing myself, from the designs, to the frontend and the backend.

Inspiration

I have been a huge chess fan for a couple of years now and it has been by biggest hobby. I have spent countless hours playing the game and watching the best players play so its fair to say I had fallen in love with the game. Through that I thought hey wouldn't it be cool to create my own chess website, how hard could it be right?

The Project

Okay I know you didn't come here to read sappy stories about a side project no one uses, so lets get to the fun part, the tech behind the project. For the frontend, I chose to use ReactJS and just base CSS. I was thinking about maybe using a component library like MUI or Ant design but I decided against it I thought the time investment of learning that library wasn't worth it because css modules do the job as fine. A huge decision in the frontend was whether to use a chess library or not. Although using a chess library was a much more enticing option, I knew from the inception of the project that I would be doing all the chess logic myself because I wanted to see how hard it could be. Turns out chess is a very complicated game to code due to the huge amount of rules that exist. In the end I was quite proud that I was able to code the entire app logic without an incredible amount of hassle and in a specified time frame.
While I would say that the majority of the work of the app was done in the frontend due to the nature of the project, there was quite a bit of work to do in the backend as well. For the backend I chose to use FastAPI. I love python, it is my favorite programming language after all, and I kept hearing about how great FastAPI is so I decided hey what better way to learn it than use it in the project. Looking at it now, FastAPI was a fantastic choice, it is by far the best developer experience I have had creating API's. Automatic data validation, automatic api documentation, dependency injection, all these things were things I had never used before and once you've seen the light there's no coming back. For the most part, the backend code was fairly standard, user authentication, database models and the whole shebang. The part that I struggled with, and spent quite a bit of time on was the websocket handling. I've used websockets before, but I used socketio and it just abstracted a lot away, so I never really had to think about how I would manage connections. Handling players leaving their game, spectators, sending moves and other actions I needed for the chess game was harder than I thought it would be. I still don't think that the class I wrote is the most elegant piece of code you'll ever see and I can definitely see how you can improve it, but it works and it isn't the worst out there.

Lessons

I always would like to think that every side project gives you a lesson or two, and this side project was no different.
One of the most important things I've learned is to consciously reduce code coupling from the start of the project. In this project, in the start there was so much code coupling between displaying the board(React part) with the chess logic. It made it extremely hard as I progressed with the app to add new features and add things due to the extreme coupling of the two elements. Its definitely not something I understand how to do well even now after the project, but I'll definitely read up on this issue so I can better architect my projects in the future.
Another thing I found out in this project is how great FastAPI is. I've decided from now on, if I'm creating a web app I'm definitely going to FastAPI for the backend, the experience is unmatched. And bonus is that it's much faster than both django and flask.

Conclusion

Hey if you stuck through this whole read, thank you. Sorry about my long rants in the middle. If you'd like to see the code for the project, you can find it here.

What happens when you type google.com and press Enter?

milkias17 — Sun, 09 Oct 2022 16:39:53 +0000

As developers we all work with the web at different layers of the stack, but we rarely ever think about what actually happens when a user types in a URL in their browser and presses enter. There is so much that is abstracted away during web development, which is great, but I was interested in what goes on behind the scenes. So today, I'll be sharing with you a very simplified process of how a request cycle may works.

The first thing that happens after a user types in a URL and presses enter, is the browser tries to translate the URL into an IP address. The thing is, web servers communicate using IP addresses instead of strings, so instead of "google.com", the browser and server communicate with an IP address like "192.168.8.108".

But how does the browser translate URLS to IP addresses

It first asks the OS if it knows the current host, this is what happens when you type in localhost:3000 for your react project for example. The browser asks the OS if it knows the host "localhost" which the OS replies with the URL, 127.0.0.1. You can add more hosts on your machine by editing /etc/hosts file. But if the OS and the browser cache don't contain the the IP address for that URL, the browser asks the resolver(usually your ISP) for that DNS entry and then translates the URL into an IP address.

What happens after you found the IP address for the server?

Well, now the browser sends an HTTP GET request to the previously found IP address. Then since google has enormous amount of traffic, they obviously don't just have a single server, they have a huge amount servers all around the world. So when we send a GET request to the IP address we get, the load balancer finds a server with the least amount of load through its algorithm to send the request to a server.

Well the server received the request, now what?

Well once the server receives a request, the web server(the application that runs on a physical server and accepts the request) is normally configured to do a specific action when a request is sent to a route. In our scenario, the web server might just return an index html page where we normally type our search query. But in another case, the web server might query the database and send us that data or a million other things you might think of as a developer.

Conclusion

Well, that was my very simplified explanation of how a web request works. Hopefully you didn't find my explanation to be incredibly stupid:) Have a good one!