Blog

Every day I went on LinkedIn and applied to as many jobs as possible. Most of them never even looked at my resume. Those who did, rejected me because they were megacorporations that wanted experience. I was just a teenager in high school and had nothing to show except my coding projects. I mostly applied to Web Developer jobs and some Blockchain Intern jobs. I was excited to work on Blockchain, but I didn't think they would hire someone without experience; I still applied. After getting rejected from tens of internship positions, a newly founded freelancing company was hiring en masse and called me for an interview for the position of Blockchain Intern.

I immediately got anxious; I set up my camera, cleaned up my room, and added the blur effect on all video-chat apps. But I didn't need to do all that; it was only a voice call. The interview was more of a quiz about general blockchain knowledge. Because I had spent months mining, trading, and investing in cryptocurrencies, I nailed it. I got most of the questions right and felt confident about myself. The next day, I got a call that I was accepted. The salary was low, only 2000 rupees (~25 dollars) per month for 20 hours per week. The only reason to accept the offer was to acquire experience and learn about blockchain tech. Being desperate, I said yes.

There was no onboarding; they just sent me a link to a Slack group and told me to join, which I did. They welcomed me in the general chat, assigned me a project, and told me to download and sign in to some other apps. One was ScreenshotMonitor, which I installed but didn't use because of privacy concerns; it monitored the employee by taking random screenshots when it was on. The other app was ClickUp, a productivity app in which they assigned tasks on a board. After doing all this, I realized they hadn't sent me an official offer letter, so I asked HR for that. They said they'd send it in a few days. I thought that was fine, but my sister said, "Don't work unless they send you the offer letter, because then you'd work for free when you were supposed to get paid." When I told them I needed the letter to start working, they sent it the next day.

The experience so far was underwhelming, to say the least: lack of communication, no meetings, ambiguous messages, and everything felt a bit off. But I shrugged it off and just continued; it turned out fine in the end.

Testing software is a must; often, I've made changes and broken something unknowingly, making it super annoying to trace down what went wrong. Testing helps avoid all that and is also very pleasing; those green checkmarks appearing one by one feel oddly comforting. There are several ways of testing software: integration testing, component testing, end-to-end testing, unit testing, etc. All of them have their use cases, for example, component testing is a great idea for testing a component library or your custom components, and end-to-end testing is good at checking how a user uses an application. I prefer to use a mix of e2e and component testing.

I used to stay away from testing, but now I always test my code. Sometimes I write tests before starting to code! (known as Test Driven Development, TDD). It has helped me a lot by catching bugs in time and knowing what caused them. A few months ago, I used to rely on the Cypress framework to test my app, but now SvelteKit recommends Playwright during project creation. I hadn't heard of Playwright before, so I thought to try it out; it was surprisingly good.

It was simple, lightweight, and fast, lightning fast! It performed tests in parallel, utilizing all cores of the CPU. Since I had a Ryzen 5 3600, 6-core CPU, it completed tests incredibly faster than Cypress. I could also use node modules right inside my test files; without having to create separate tasks. Although it was a bit challenging to move from a GUI-based testing framework to a CLI one, it was well worth the effort. It also had native tooling with VS-Code; I could run tests directly from my IDE. The tooling nailed it for me; I wasn't going to look back.

Cypress made testing fun and enjoyed its time as a solo competitor. But as Playwright from Microsoft steps into the arena with insanely attractive features and advantages, Cypress will have to step up its game.

As a web developer, you come across many ways to achieve the same goal: frameworks, technologies, languages, etc. There isn't just one way to make your dream web app; you can do whatever seems natural to you. You can use React, or you can use Angular, TypeScript, or vanilla JavaScript, bundle using Webpack, or Vite. There are so many ways to do the same thing, which seems nice because we can choose the tech stack that we like, but it comes with a cost.

As someone who has tinkered with many technologies, I didn't like the web development ecosystem because nothing is explicit. There are tens of frameworks to choose from, and even then, there are different ways of doing things (why does React still use class-based components in their docs?). When I used to make websites around 2015, I just used HTML, CSS, and JS; life was simple. But when I came back after a few years, everything had changed so drastically; there were so many different ways to do the same thing that deciding on the stack became more stressful than trying to make the app itself. In competitive programming, I started using Python, but just because I could, it didn't mean I should; I quickly realized the cons of using Python in CP and switched to C++. There was a way of doing things in this space; I didn't mind switching. There may be different paths to achieve the same thing, but they should be relatively straightforward.

I started with Svelte, the perfect framework for me: easy to use and straightforward, and I rarely had to use npm install. But because Svelte was not popular among jobs and internships, I had to switch to React. It was tough, but the vast ecosystem was new and felt nice. I didn't have to implement complex components from scratch; they were just one npm install away. I found that the tutorial series on their websites used class-based components to teach; fortunately, I had heard Fireship.io say that "class-based components are literally - the devil.", so I quickly switched to a different tutorial and found Next.js' website. Their tutorial used function-based components; they were way better than class-based. To my surprise, it was better than the official React tutorial: easier to understand, small questions in every section, and beginner-friendly.

React is so different from Svelte that it felt like switching from Python to C++. Now that I have used React and Next for some time, I can confidently say that: Svelte is better; I would've never switched if there was even a slightly larger ecosystem and was in demand by jobs and internships. As SvelteKit approaches a stable release, companies may slowly adopt Svelte, but it will take a while. For now though, because I am looking for internships, I will be using React and Next.

After almost a year of waiting, I'm proud to announce that MyFit V3 is now officially released 🎉🎉🎉! Here's a glimpse of the new features:

• Brand new, clean UI with dark and light modes
• Detailed statistics for all kinds of metrics
• Adjust mesocycle split during its active phase
• Drag and drop exercises to change their order
• Volume progression customizations per muscle group
• Better handling of bodyweight exercises

You can also migrate all your data from V2 to V3! To migrate, just go to your profile page in V3 from the top navbar and hit “Start migration.” There are some limitations due to schema mismatches:

• You should NOT have an active mesocycle in V2. If you do, you can finish it at your own pace and migrate later, no rush.
• You'll need a single average bodyweight to back-fill all workouts.
• You'll need a single average workout duration to back-fill all workouts.

Although I've thoroughly tested the app and have been using it for quite some time, there might still be small bugs. Feel free to open an issue if you encounter any. Thank you all for your patience!

To avoid keeping everyone in complete darkness, I've created a GitHub discussion which I'll try to update regularly.

"Sub-optimal" — you might've heard this word many times on social media: influencers telling you that this exercise is "sub-optimal" for this head of this muscle group and that you SHOULD NOT do it AT ALL. Sometimes it is true and well-intended, but many times it's just unnecessary and a lot more nuanced. Fitness should be considered with context, and so should exercises. Some exercises might not be "optimal," but they might feel better on your joints, or you might simply enjoy them more. Keeping a black-and-white view of exercises as simply optimal vs. not optimal is not good for long-term goals.

I've learned this same lesson when making this app on the technical side as well. Sometimes you can't get the optimal structure or pristine code with perfect readability, and you should be fine with it. I've re-made this same workout app about four times now, each time learning new things and getting better at it. Instead of aiming for perfect code, I've now started to aim for "good enough" code. Otherwise, I'll never be able to release v3 and will be stuck in my OCD forever.

Tech updates:

• Moved to CockroachDB from Neon for the lower latency and higher storage (10GiB free!)
• A good CI/CD pipeline that will work for PRs as well

Again, I'm just a college student who's barely an adult. This blog is a place where I plan to share my journey of building this application. None of this is scientific advice, just my opinion on things I've built by watching tons of Dr. Mike on YouTube 😅

The app now gets 4000+ views every week 🥳. Thanks, all!

Now that my exams are over and I have almost an entire month of holidays, I'm dedicating nearly the entire day to v3. I'm learning new things and implementing features every day, which feels great! I'm almost done with the foundational work on exercises and mesocycles and will begin working on workouts very soon. Most of the tech stack is now fixed, and I doubt I'll have to rewrite anything for at least the next few months.

v3 sneak peek

Some of the new and requested features that I've implemented are:

• Drag and drop for exercises
• Exercise search list where you can add an exercise with one click
• Ability to change the exercise split of an ongoing mesocycle without losing progress
• Actual and meaningful analytics

For the tech people who are interested (these decisions don't really affect the actual end user experience directly, mostly just UI stuff and some speed improvements), here are some of the major changes:

• tRPC instead of REST API for type-safe database queries
• shadcn-svelte with Svelte 5 for UI components
• Prisma with Neon PostgreSQL for efficient joins and type safety

Now that the basics are in place, I can soon start work on the progression algorithms. I just need to write some tests to make sure things don't break later on when I add more features. That's about it for this blog post. I'll try to post once every month to give updates on v3 and cool upcoming stuff. Happy lifting!

TLDR: Life happened. and I wasn't happy with the current tech stack, so I'm sorry but it's gonna take quite some more time

Yeah... that didn't pan out well. It's been almost half an year since I made the v3 notice. I was naive to believe that I'd actually be able to complete the thing in 2 months. I didn't expect so much stuff to happen in this last semester of my diploma, basketball, hackathons, college events, and even exams! I still tried to put in as much work in v3 as I could, but the code quality was deteriorating over time as I was starting to do the same thing I did in v2, rush things.

I wasn't happy with how the spaghetti code looked, I just knew this was something that would become a disaster to manage later on, so instead of trying to deliver a rushed app again, I've decided to let v3 take as much time as it needs.

I also need to change the tech stack entirely.

• I'm moving away from MongoDB with API endpoints, to server-side streamed Prisma ORM with PostgreSQL hosted on Neon, this should offer much better type safety without code duplication and better performance.
• I'm also going to use shadcn-svelte for this project instead of DaisyUI, it looks very cool and is quite low-effort tbh.
• I also want to use Svelte 5, but I need to wait a bit as the shadcn-svelte library isn't yet fully ready for runes support.

"So how long will v3 take?", you may ask, and to answer that honestly, I don't know at this point, I really don't want to rush this. Sorry for making false promises, I didn't know any better.

I have my last sem exams now, after which I have a lot of free time to build, till then hopefully svelte 5 would be better supported in the ecosystem and the DX would be great too.

On a side note: v2 is still doing extremely well, there are 10000+ views every month, which is insane to me. So many people have opened helpful issues to suggest stuff and also told me to add a donations option, which is very cool, thanks a lot guys. As soon as exams are over, I'll start working on v3, I don't feel comfortable yet giving a specific timeline but I promise you this, I'll try my best to finish it as soon as possible.

Happy lifting!

I have received quite the traffic in v2, I am super happy about that

Unfortunately, even though I wanted to, I couldn't fully implement all the features of v2 before launch, I hurried a lot

I have began work on v3 now, this time it will be a full fledged app with all the features from start, and not break any important features after launch

Developing v3 will take a long time (~2 months), but if there are some important features that you guys wish to have in v2, feel free to open an issue on the GitHub repository

The reason I am working on v3 and not implementing the new features directly in v2 is cause of potential migration problems, v3's schema will be different from v2's. Don't worry though, I will definitely make a migration script after v3 has finished development for an easy upgrade to v3

Some new features that I'm working on in v3 are:

• Offline support
• Automatic recovery suggestions
• Automatic deload creator
• Better and working analytics
• Open to suggestions, open an issue!

I said I'd try to write a blog post every month, but I got busy with college admissions and stuff. And honestly, I got a Deadlock invite (the game), and it was way too enticing to miss out on. Met up with friends as we hadn't seen each other for quite some time. So basically, I procrastinated working on the app for the better part of August.

After finishing up the admissions process, I had a bit of breathing room before the start of the academic year. I got the motivation to start working on the app again and learned a lot about GitHub guidelines and issue tracking from a friend.

A beta version of V3 was released for testing and feedback, and people started opening issues like bug reports and feature requests. After seeing positive comments when I resolved the GitHub issues and discussed the app with others, I WANTED to work on the app. Closing issues one by one while interacting with the community has a different kind of satisfaction to it.

Unfortunately, there were a LOT more things remaining to finish off before I could release the V3-stable version. And I couldn't finish them before college, and now I'm buried under assignments, practicals, and lectures.

So I will be slowing down work on the app for now, and when a new holiday season arrives, giving me some free time, I'll catch up on the issues.

Here's the V3-beta link for anyone who missed it on GitHub: https://my-fit-v3.vercel.app (this version is in beta and user data might be deleted without notice, use at your own discretion)