Forem: Aarav Sibbal

Squash Elo Rating System

Aarav Sibbal — Mon, 18 Nov 2024 19:10:41 +0000

I am ecstatic to announce my new project, the Squash Elo Rating System. This project is created for the Carleton Squash Club.

Why?

When attending the club myself and talking to other players I realized there was a need for a system that could help players see their ranking and/or their progress within the game, while having a conversation with a member we concluded that Chess.com Elo rating system would kind of work for our purposes.

So I made this project to solve that very need based on these principles:

The thing made should be readily accessible to players
Players should be able to see their ratings, stats, and any other data easily
The system should be simple and intuitive

What

So what exactly did I make here is the question you might be asking after reading this long.

Discord Bot (Writing)

Responsibilities/features:

Authentication: The Carleton Squash club is private, is very well maintained and on top of that, is on Discord, which by itself provides so much fine-tuning for the admins that the authentication and thus bad data is handled by the Discord itself.
Adding players to the system: Players can only be added through Discord.
Adding match to the system: The match can only be added through Discord. Also, all the data is also sanitized by the bot.
Stats: Players can see their stats.

The bot is made entirely in Golang, this is first because I love using it and also it had a very easy-to-use package, with great documentation which helped me get started in no time.
https://github.com/bwmarrin/discordgo

The original vision for this system was for it to be only a Discord bot where players can view their rankings through Discord. This vision was then disrupted by the conversation I had with the members of my club about how they would use the bot. From the conversation, I could see that there would be a hindrance in players wanting to see their stats/rankings/matchups, because every time they do, it would be public. This led me to the decision to add a website to the system.

Adding a website was essential because I want my club's players to see all data at all times without having to think about server etiquette.

Website (Reading)

Responsibilities:

Getting the rankings
Getting the player's current stats
Having all player's matchups
Having a graphic to view players' recent progression

Like I said I wanted the website to be simple, and I don't like writing auth logic so the website is made to be read not write.

The website is also written in Golang because it is the Best language to write servers in.

In conclusion

I would like to thank the president of my club, Noah, for letting me give this project to the community and for helping me improve it with his input.

I would also like to thank Adam an exec in our club who helped me realize that I should not base my DB on Discord Usernames as people can change them, he helped me change it to Discord IDs that are usually only seen at the API level.

I learned a lot with this project, and I put a lot into it, as of now I am in the process of getting this hosted while waiting on the bureaucracy of it all. In the meantime, I wanted to share this project with you. You can find it on my GitHub.

https://github.com/AaravSibbal/SquashWebsite

Why backend engineers should make CLI's

Aarav Sibbal — Mon, 25 Mar 2024 21:12:15 +0000

In this article, I am going to focus on why I think people are missing out by not making CLIs. Almost everyone I know starts with web development because it is one of the things that gives results fast, which makes us go "me best, me genius," and that's exactly why I am still learning about web development. But there comes a point where you just want to be a developer rather than a web developer.

It takes too much time

I wanted to be able to zip my files without using 7zip because I didn't want to learn about their CLI, which is complicated for no reason, and because of this, I always had to open the GUI.

Now if I made a website, that would just be too excessive because I am making a server with Go, having my UI with HTMX, containerizing my application in a docker, using nginx, and let's encrypt to have https, and finally using docker-compose to have them in one container to run on my Linux server on the digital ocean.

Or I can think about the functionality that I wanted, the kind of input I wanted to support, learning about how to read a file, and later how to walk a whole directory with Go recursively, and figure out that there is a small thing about using backslashes with the zip.Writer() function.

In the latter case, I was focused on the thing I wanted to learn rather than all the other junk that stopped me from actually getting into the thing that I wanted to learn.

Making an entire website with all the bells and whistles for a little feature that you want to develop and figure out is too much. Just make a CLI.

Reusable code

Another benefit of making a CLI is that you can reuse your code, i.e., if you decide to make a CLI that takes a video and converts it into different formats, something that YouTube does to deal with the varying internet bandwidth of its users.

After making the CLI, that part of the puzzle is now demystified, which means you can use it in a project that has videos; it almost acts as a microservice.

The Bliss of Finishing

Everyone has a lot of unfinished projects, which is completely fine, but sometimes your resume needs to have some complete projects that have the appropriate readme, which people can either install or see because that gives you credibility.

Remember, sometimes you have to finish the thing that you start. CLIs, in my perspective, make the probability of finishing higher because the problem you are going to tackle is by nature going to be small in scale. This also has the byproduct of giving you confidence, which is rather helpful, especially when you are starting.

It is cool

My favorite thing about making a CLI is that any time you use the thing that you made and it just works, it makes everything you work for seem worth it.

My advice is that when you feel overwhelmed by the things that you feel like you have to do or just feel like programming is losing its spark, just make something. It doesn't have to be grand; it only needs to be something that you want. It is by far the quickest way to feel the fire again, and CLIs are just a nice little middle-ground thing that you will use and will need.

Final Thoughts

If you haven't made a CLI yet, I would like to say just try it, or maybe start by customizing your command line to look the way you want to. You spend a lot of time there, so having ownership over the things you use is important. Having fun is also important.

Note: I got this idea from the freecodecamp.org video about Getting a job It is a great video, and you should check it out if you are trying to get a job.

If anyone wants to have a conversation about tech in general or talk about some of the cool CLI they've made for themselves, I'd love to talk about it. My information is on my profile.

Things I like about Go

Aarav Sibbal — Sat, 10 Feb 2024 01:03:22 +0000

Intro

I recently learned Go with the help of a book called "Let's Go" by Alex Edward. The book was nice, especially for beginners in Go/Web Dev like me, and there were a lot of things that I liked about the language. Before using Go the only real experience I had was with the JS eco-system so because of that most of my comparisons will be between Go and JS.

Error Handling

JS Error handling

Most of the time in JS/TS error handling is done like so:

try{
    await sql.open("db")
}catch(err){
    // do something else
}

I feel that there are a lot of problems with this approach:

If you are writing JS you just don't even know if a function that you are running is going to err
If you are writing TS unless the people who have written the library have chosen to write the return types of the functions, you don't know that the function is going to err, and that just seems to be a recipe for a disaster.
It is not even necessary to have errors as values

Go Error handling

Error Handling in Go is done like so:

db, err := sql.Open("db")
if err != nil {
    log.Fatal(err)
}

Things I like about this approach:

Along with the fact that errors are treated as values and that you are explicitly required to write your return types allows for an experience where as a developer you know every function that is going to err in your codebase from which you can handle the errors accordingly.

defer

I love this functionality in every language that I see it in, because of its convenience. It allows me to not think about how and when the connection/db should be closed, it is just a nice quality-of-life feature.

db, err := sql.Open()
if err != nil {
    log.falal("internal server error")
}

defer db.Close()

Standard Library

In JS the libraries you choose completely change the way that you experience/learn the language to the point that there is a difference between a JS developer, a TS developer, and a React Developer not to mention all the n number of libraries that are needed that make your programs that can also change your experience drastically.

Comparing this to Go where most of the things that you might need are already included in the standard library, moreover, the things that are included are useable this allows for more or less a singular experience with the language and I feel like this would work better with teams. A great example of this would be having the "net/http" package ready to go, which as of release 1.22 also has improved the routing allowing for request methods as well as wild card at the end of the URL example: "POST tweet/{id}".

Having a good standard library also makes it so that you are focused on making the project rather than focusing on the third-party libraries that you must choose in JS.

Conclusion

I liked my experience with Go it was easy to learn, fast to be productive in, fast as a language, compiled, statically typed, with good error handling, a complete feeling standard library, and doesn't even have colored functions, which just feels like a win to me overall. I'll be making a lot more of my projects using Go from now on and I am excited about it.

Author: Aarav Sibbal
Github
Email: aaravsibbal.15@gmail.com