harish

Deployed all the services (5 micro services) in Railway and frontend in vercel. Scheduler server is working but as a combination it throws error and i could not find a fix for this.

Discovery Server (Eureka):
1.set up eureka server for service registry
2.added @EnableEurekaServer in main class
3.configured application.properties with:
i)register-with-eureka=false
ii)fetch-registry=false
4.tested by running server and checking dashboard (/eureka)
5.at first services were not showing because wrong port config
6.fixed by correcting defaultZone in client services
7.learned how service discovery actually works (before I was just copying configs)

User Service: created basic spring boot service for handling users
1.create user
2.get user details
3.connected with eureka client
4.had issue with service not registering → fixed dependency mismatch
5.used simple in memory storage (no DB for now)
6.tested using Postman
7.learned how multiple services communicate through gateway

Scheduler Engine: implemented scheduler using @Scheduled annotation
1.purpose was to trigger periodic checks (like reminders or updates)
2.initially scheduler was not running → forgot to enable scheduling
3.fixed by adding @EnableScheduling
4.tested logs to confirm execution
learned how background jobs work in spring

UI (Vite Frontend):
1.created frontend using Vite
2.designed simple UI for study planner
3.added basic pages (tasks, planner view)
4.connected frontend to backend APIs
5.had CORS issue at first → fixed using spring config
6.replaced localhost with deployed backend URL later
UI is simple but functional

backend is not fully working because other microservices (like discovery server and services) are not deployed
due to this, some API calls are failing. So deployment is partially successful but not fully functional yet

I’m building a brain for my study schedule. I didn’t want a messy project where everything is shoved into one folder, so I split it up. This week was all about the API Gateway (the gatekeeper) and the Task Service ( the actual homework tracker).
the Gateway is like the “front door” of the whole app. Instead of the frontend trying to find 5 different ports (which is a total nightmare), it just hits port 8080 and the Gateway points it to the right place.

Dynamic Routing is GOATED: I used lb://. This means the Gateway literally asks Eureka where the services are. No hardcoded URLs. It’s super clean.
CORS was beefing with me: My React frontend was getting blocked because it’s on a different port. Spent way too long on this, but I fixed it with a CorsConfig so the browser stops trippping.
Checking the “Map”: I can check actuator/gateway/routes to see exactly where my traffic is going. It’s like a GPS for my data.
The Task Service:
Making it “Smart”:
I didn’t want this to be a boring to-do list, so I added some “autopilot” features:

Auto-Complete: If I set a task to 100% progress, it automatically flips to DONE. If I just start it, it moves to IN_PROGRESS. I don’t have to manually click a bunch of buttons.

Lazy Mode (Defaults): If I’m in a rush and just type “History Project,” the app fills in the rest—gives me a week to do it and sets a “medium” difficulty.

No Blank Screens: I added a “seed” function. The first time I open the app, it gives me 3 fake tasks (Math, History, Physics) so it doesn’t look like a ghost town.

I worked on fixing the deployment issue in my project. The backend is hosted on Render free tier, so it was going into sleep mode after some time. Because of that, whenever I opened the app after some time, it was taking around 30-60 seconds to load the data.
At first I thought something is wrong with my API, but later I understood it is due to cold start in Render.
So I searched for solutions and found that we can use a cron job to keep the server alive. I used cron-job.org and created a job that sends a request to my backend API every 5 minutes.
After setting this up, the backend is not going idle anymore and response is much faster now.

• Fixed Air vs Vacuum logic vacuum now applies identical acceleration to all objects
• Added selectable gravity presets for Earth, Moon, Mars, and Jupiter
  -Replaced hardcoded feather/stone setup with reusable object data using drag coefficients
• Updated fall simulation to use kinematic equations based on elapsed time for accurate vacuum motion
• Implemented simple air model: a_eff = g * (1 - Cd) so higher-drag objects fall slower
• Added live telemetry (velocity, height, acceleration, landing state, elapsed time)
• Updated end-of-drop explanation to reflect selected planet, environment, and objects
  -Made the simulation responsive so it works properly on mobile devices

index.html
-Changed the old feather vs stone demo into a full physics lab-style layout
-Added a planet selection dropdown (Earth, Moon, Mars, Jupiter) to test different gravity values
-Added object selection for both chambers (Lead Ball, Basketball, Paper Plane, Bowling Ball)
-Created a live data panel to show velocity, height, acceleration, time, and status
Reorganized the page into 3 sections:
1.Control Panel
2.Chamber Panel
3.Telemetry Panel
#airVvaccum.css
-Updated the design from a basic look to a dark digital lab theme
-Added grid-style backgrounds, panels, and telemetry card designs
-Used monospace font for number-heavy UI parts to improve readability
-Added responsive design changes so it works better on tablets and mobile
-Made the Drop button bigger for easier use on phones
-Fixed dropdown colors so options are clearly visible when opened
Next will be focus on the JS functionality to make it work

Deployed my Odd One Out project on Vercel. Fixed minor issues during deployment

I built the basic UI and added logic to check if the selected option is correct. i faced some issues with the selection logic but fixed them after debugging. I also made small UI improvements to make it cleaner.

During deployment, the updated UI was not showing because the main file was named “airVvacuum.html” instead of “index.html”. After renaming it and redeploying, the issue was fixed.

I created a simulation to show how objects fall in air and in vaccum. First, I designed the basic layout using HTML and CSS, then used JavaScript to add the falling animation. I applied the concept of gravity in both cases, and added air resistance only in the air part, so it falls slower compared to vaccum.

Worked on deploying my full-stack GameVault project. The backend is built using Spring Boot with PostgreSQL (Neon DB) and I deployed it on Render using Docker. Initially, I faced multiple issues like wrong runtime selection (Node instead of Java), Maven not found errors, and Dockerfile path problems. I also had to fix the Dockerfile naming issue (case sensitive) and understand how Render handles root directories and build context, for the frontend, I used plain HTML, CSS, and JavaScript and deployed it on Vercel. I ran into issues where Vercel was picking the wrong branch and root directory, so it wasn’t showing my frontend files. After correcting the root directory to the frontend folder and updating the API base URL to the deployed backend, everything started working properly. Finally i connected both frontend and backend, tested API endpoints, and verified that features like viewing games, cart, and admin operations are working correctly on the live deployment

Almost completed the backend part, still there are few bugs which I need to fix. Started working on the UI side, currently building login and register pages. Trying to connect frontend with backend APIs and testing the flow step by step.

Started working on the Game Store project. Set up the backend using Spring Boot and connected it with the database. Implemented basic authentication and role-based access control. Also created APIs for adding and managing games. Faced some issues with database configuration but fixed it after some debugging.

Added demo recording video link at Readme file and fixed the existing bugs

bug fixed and deployed in vercel

Implemented fixture class and started understanding how Playwright fixtures works. Also explored codegen and trace viewer, it was really helpful to see step by step execution. Trace viewer is very useful for debugging issues and understanding what exactly happening during test run.

Started this project to practice Playwright automation and understand how UI testing works. First I created basic login test cases and tried interacting with elements on the Practice Test Automation site. Later I added few more scenarios like exception handling and table validations. Also learned how to generate HTML reports and push the project to GitHub using git.

I’m working on my first project! This is so exciting.