My tech timeline

So this is embarrassing, but I accidentally broke production, and not in a way I expected.

I was working on v4, I knew I should use a different database, which I was doing, on a different platform too. But at one point, I needed to use the OpenFoodFacts database, which was quite huge, so I thought the other services only offer upto 0.5 GB of storage, so instead I can just use the same platform as v3, which was CockroachDB cloud. It used to have a really generous free tier (I got really lucky, they stopped offering it) so I thought it would be fine.

In hindsight, I didn't even need to use CockroachDB, at the end of the day, I just needed about 40 MB of storage, which is nothing. I could have used Vercel Postgres, Neon, or anything else, but I didn't. I just thought it would be fine. I can be lazy, right?

So I created a SEPARATE database for v4, and started working on it. "That should be fine", I said to myself. I pushed the new schema, tested it out with some models and the new simplified 40 MB data, and it was fine. I just needed to drop some columns to prevent redundancy...

So apparently, when you drop columns in CockroachDB from the prisma CLI, using prisma db push, it takes a while, like a few minutes, I thought that's just some latency, so I just waited. I queued up a game of a MOBA, and chilled. I saw a small notification on my Desktop about a mail, saying 50% Request Units used, and I thought "Oh, that's fine, just 50% is chill, it's the end of the month anyways".

I got back into the game, it was a tough one, I was playing with friends too, so I was focused on that. After I was done, I saw my Desktop, dismissed the older notification, and saw a new one: "100% Request Units used, your database cannot be connected to". I was like "What? How? I just dropped a few columns, it shouldn't be that much!". I opened the database dashboard, and saw that it was unavailable. I was like "Oh no, this is bad, I need to fix this". I panicked.

I immediately put up a notice and a redirect on the app, trying to cope with the situation, that "Yeah, I messed up, should be fine in 3 days, when a new month starts". I was so embarrassed, I had to tell my friends who were using the app, that I broke it. I was so ashamed, I didn't even want to look at the codebase. Then I thought maybe I can just download the backups, restore it on a different platform, and then just use that. I tried to do that, but the backups were not that easy to download, I tried setting up cloud buckets, adding connections, but nothing worked. I was so frustrated, I just wanted to cry.

I was about to give up, but then I just, gave my debit card details to CockroachDB, yeah, I really wanted to avoid that, but I had no choice. MyFit was gaining some traction again, got over 97+ stars on GitHub, and I didn't want to let my users down. I just added it, and saw that I didn't really need to pay anything unless it crosses 15$ of credits, which was fine, I only used up about 10$, I got about 5$ of headroom for just a few days. I was relieved, but still embarrassed. I had to tell my users that I messed up, and I did. I apologized, but luckily I fixed it in a few hours, and everything was back to normal.

I learned a lot from this experience, and I hope you do too. Here are some of the key takeaways:

1. Don't be lazy: I should have used a different platform, or better yet, go local. I was just being lazy, and it cost me a lot of time and effort.
2. Don't ignore mails: I should have paid attention to the notification, it was a warning that I ignored. I thought it was just some latency, but it was actually a warning that I was about to hit the limit.
3. Don't panic: I panicked when I saw the read-only message, but I should have just taken a deep breath and thought about the solution. I could have avoided a lot of stress if I had just calmed down.

During my internship at Yardstick, I had the opportunity to work on an AI-driven workflow automation platform that was designed to scale efficiently and handle a large user base. The focus was on building a modern, performant web application using the latest technologies.

Key Responsibilities

Platform Development

Developed an AI-driven workflow automation platform using Next.js, optimizing for scalability, performance, and low latency to support a large user base. The platform leveraged cutting-edge technologies to deliver a seamless user experience.

Modern Web Technologies

Implemented modern web technologies, including React Server Components (RSCs), Suspense-based data fetching, and lazy loading. These optimizations improved SEO significantly and achieved high Lighthouse scores across all metrics.

Backend Integration

Integrated Stripe for secure payment processing and Prisma for efficient database management. I was responsible for designing a RESTful API that was scalable, secure, and high-performance, ensuring smooth data flow between the frontend and backend.

Skills Developed

This internship allowed me to deepen my understanding of full-stack development, particularly in building scalable applications with modern frameworks. I gained hands-on experience with payment integrations, database optimization, and performance tuning for web applications.

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)

My internship at Anand Chemiceutics was focused on data engineering and automation. I worked on building efficient data transformation pipelines that significantly improved the company's data processing workflows.

Key Achievements

Data Automation

Automated data transformation with Python scripts, utilizing Pandas for file conversions and optimizing numerical operations with NumPy. This automation reduced processing time by 75%, drastically improving the efficiency of data workflows.

Pipeline Optimization

Boosted pipeline efficiency by 10x through the elimination of manual data conversion and integration of automated processes. This not only saved time but also significantly reduced human error in data handling.

Quality Assurance

Implemented robust testing methodologies to reduce OCR error rate for scanned documents to below 1%. This improvement in accuracy and reliability was crucial for maintaining data integrity across the organization's systems.

Learning Experience

This internship was my first real exposure to data engineering and automation at scale. I learned the importance of writing efficient, maintainable code and the impact that automation can have on business processes. Working with real-world data challenges taught me valuable lessons about error handling, testing, and optimization.

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.

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.

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.

This was my first professional internship, and it was an exciting dive into blockchain technology and smart contract development. Working remotely at Juppiter AI Labs, I was exposed to cutting-edge technologies and challenging problems.

Key Achievements

Rapid Learning

Quickly adapted to PyTEAL (Python smart contract library) to meet tight project deadlines. Despite having no prior experience with the library, I was able to become proficient quickly and deliver high-quality work.

Recognition

Recognized as Employee of the Month for being the only intern to successfully deliver smart contracts and test them in Docker containers. I greatly contributed to project milestones by emulating a local Algorand node, which was critical for development and testing.

Testing Automation

Automated smart contract testing using Bash scripts, achieving 90% code coverage and ensuring high reliability. This automation framework became a valuable tool for the team and improved our development workflow significantly.

Growth and Learning

This internship was transformative for my career. It taught me the importance of self-learning, persistence, and the value of thorough testing. Working with blockchain technology and smart contracts opened up a new world of possibilities and sparked my interest in decentralized systems. Being recognized as Employee of the Month as an intern was a huge confidence boost and motivated me to continue pushing my boundaries.