🚀 #100DaysOfCode – Day 12 | Backend Journey Continues 💻🔥 Consistency is starting to feel powerful now. Day 12 done ✅ 🧠 LeetCode Daily Challenge 📌 Problem: Maximum Walls Destroyed by Robots 💡 Approach & Learnings: Today’s problem was a mix of Sorting + Binary Search + Dynamic Programming, which made it super interesting. 🔹 Sorted robots and walls to process efficiently 🔹 Used Binary Search to quickly count walls in a given range 🔹 Applied Dynamic Programming to maximize total walls destroyed 👉 The key challenge was handling overlapping ranges between robots and deciding the optimal strategy to avoid double counting. This problem really tested how well I can combine multiple concepts into one optimized solution. Submission Link: https://lnkd.in/gp99D5sS 🌱 Spring Boot Learning Today I focused on some very important backend concepts: 🔹 PUT vs PATCH Mapping 👉 PUT Mapping Used when updating the entire object Missing fields → become NULL Best for full replacement 👉 PATCH Mapping Used for partial updates Only updates required fields Avoids unnecessary null values 🔹 ReflectionUtils in PATCH Learned how to use Reflection to dynamically update fields inside an entity. 💡 This helps in: Updating fields without writing multiple setters Making PATCH APIs more flexible Writing cleaner and scalable backend code 🔹 ResponseEntity Understood how to structure API responses properly: ✅ Control HTTP status codes ✅ Customize response body ✅ Improve API clarity and standards 📈 Key Takeaways ✔️ Combining multiple DSA concepts is key for optimization ✔️ PATCH is essential for real-world API design ✔️ Reflection adds flexibility to backend logic ✔️ Clean API responses improve overall system design NotesLink: https://lnkd.in/gNZWz96m 🔥 Day 12 done. Still consistent. Still improving. #BackendDevelopment #SpringBoot #Java #LeetCode #100DaysOfCode #CodingJourney

Will Backend Coding Become UI-Based 🤔 ? As technology grow rapidly, I’ve some doubts: Will frameworks like Spring Boot eventually become fully UI driven? Today, we already see tools that reduce boilerplate code: Lombok simplifies model classes ,Spring Data JPA reduces repository code,Auto configurations minimize manual setup And some AI agents already creating boiler plates for backend like JHipster As in future components like Controllers, and Repositories be generated or managed entirely through a visual interface in the future? Imagine a world where: Non-coders can build backend systems using UI tools Business logic is designed visually instead of written line by line Applications are assembled like building blocks We are already moving in this direction with low code and nocode platforms. But will they ever fully replace traditional coding? What do you think? is it good  to spend thousands of hours on learning traditional way of learning , or its time to change as minimal logics are already automated ? #SpringBoot #Java #BackendDevelopment #LowCode #NoCode #FutureOfTech #SoftwareEngineering

💡 Copilot feels faster… but Codex made me rethink AI coding in IntelliJ IDEA... I tested both on a real Spring Boot project with external JARs, Nexus dependencies, and internal SDKs. At first glance, they feel almost identical. Both speed up development. Both reduce boilerplate. But once you work with real complexity, especially external libraries, the difference becomes obvious. ⚡ Copilot = speed layer It works great for: boilerplate code quick methods inline suggestions But it mostly relies on visible context. With external dependencies, it doesn’t really “understand” what’s inside the libraries, you guide it more than it interprets them. 🧠 Codex = context layer On complex projects, it starts to: follow patterns across the codebase respect architecture and structure infer how external libraries are actually used reason across multiple files It doesn’t read JARs directl, but it reconstructs intent from how you use them. 💡 My takeaway: -Copilot helps you code faster. -Codex helps you think deeper. And the real insight is this: 👉 The cleaner your architecture and library usage, the more powerful both tools become. Curious how others see it: In real Spring Boot/enterprise projects, do you feel Copilot is enough, or does Codex add another layer of understanding? #AI #Java #SpringBoot #IntelliJIDEA #SoftwareEngineering #AI_Agent

🚀 Day 10: Classes & Objects – The Core of Object-Oriented Programming 💎🏗️ Today marks a significant step in my Java journey. I moved beyond writing simple logic and started understanding how to represent real-world entities in code using Classes and Objects. Here’s how I structured my learning: 🔹 1. Class – The Blueprint 📋 A class is a logical structure—a blueprint that defines what an object will look like. It contains: • Properties (State): Variables like name, age, etc. • Behaviors (Actions): Methods that define functionality 👉 Think of it as an architect’s design—you can’t live in it, but it guides construction. 🔹 2. Object – The Real Entity 🏠 An object is an instance of a class. It exists in memory and represents a real-world entity. Created using the new keyword: Car myCar = new Car(); 👉 If the class is the design, the object is the actual building. 🔹 3. Class–Object Relationship 🔗 • A class is defined once • Multiple objects can be created from it • Each object holds its own unique data 💡 Key Takeaway: Programming is not just about writing instructions—it’s about modeling the real world digitally using structured and reusable designs. I’m starting to see how powerful Object-Oriented Programming is in building scalable and maintainable applications. This feels like the foundation for becoming a strong backend developer. 💻 #JavaFullStack #OOP #ObjectOrientedProgramming #JavaDeveloper #CodingJourney #Day10 #BackendDev2026

A well-structured Spring Boot app follows a clear hierarchy: ✅ Controller → Handles Requests ✅ Service → Business Logic ✅ Repository → Database Access ✅ Entity → Data Structure Clean architecture = Happy developers. Save this cheat sheet for your next project! #JavaDeveloper #SpringBoot #CodingLife #CleanCode #Programming

🚀 Stop blindly using @Autowired on fields. It works… but it’s NOT the best way. Let’s understand why 👇 👉 There are 3 ways to inject dependencies in Spring: 1️⃣ Field Injection 2️⃣ Setter Injection 3️⃣ Constructor Injection ✅ (Recommended) --- 💡 Most beginners do this: @Service public class OrderService { @Autowired private PaymentService paymentService; } ❌ Problems: - Hard to test (no control over dependency) - Hidden dependencies - Breaks immutability --- ✅ Better approach → Constructor Injection: @Service public class OrderService { private final PaymentService paymentService; public OrderService(PaymentService paymentService) { this.paymentService = paymentService; } } ✔ Dependencies are explicit ✔ Easy to write unit tests ✔ Ensures immutability --- 🔥 Bonus (Spring Boot magic): If a class has ONLY ONE constructor → You don’t even need @Autowired 😮 Spring automatically injects it! --- ⚡ Real-world impact: In large projects: - Field injection → messy & hard to debug - Constructor injection → clean & maintainable --- ❌ Common mistake: Using @Autowired everywhere just because it’s easy --- 📌 Key Takeaway: “Convenience is not always best practice.” Always prefer Constructor Injection for clean and testable code. --- Follow for more real backend learnings 🚀 #SpringBoot #Java #CleanCode #BackendDevelopment #SoftwareEngineer

🚀 Day 4 — Executors (Better Thread Management, Still Messy Code) AsyncTask tried to simplify async — and failed. So the next step was: 👉 Improve how threads are managed --- 👉 Problem so far: • Creating threads manually is expensive • Too many threads → performance issues • No reuse → wasteful --- 👉 Solution: Executors Instead of creating new threads every time, Executors use a thread pool 👉 Threads are reused instead of recreated --- 👉 Example: ExecutorService executor = Executors.newSingleThreadExecutor(); executor.execute(() -> { String data = apiCall(); new Handler(Looper.getMainLooper()).post(() -> { textView.setText(data); }); }); --- 👉 Real Problem (Still not solved): When tasks depend on each other, you end up with nested callbacks Example: executor.execute(() -> { apiCall1(); handler.post(() -> { executor.execute(() -> { apiCall2(); handler.post(() -> { updateUI(); }); }); }); }); --- ⚠️ This leads to: • Deep nesting (hard to read) • Hard to debug • Hard to manage errors • Callback hell --- ✅ What improved: • Efficient thread management • Better performance (thread reuse) • Scales better than raw threads --- ⚠️ What’s still broken: • Still need Handler for UI updates • Manual thread switching everywhere • No lifecycle awareness • Code becomes messy with dependent tasks --- 📉 Core Limitation: Executors solved performance, but made code structure worse for complex flows --- ➡️ Why we moved forward: Developers needed: • Cleaner async flow • Less nesting • Better readability --- ➡️ Next: RxJava (Reactive way to handle async + chaining) --- #AndroidDevelopment #AsyncProgramming #Java #MobileDevelopment #SoftwareEngineering #AndroidDev #Programming

Everyone is building fast with Spring Boot… but silently killing their architecture with one keyword 👇 👉 `new` Looks harmless right? But this one line can destroy **scalability, testability, and flexibility**. --- ## ⚠️ Real Problem You write this: ```java @Service public class OrderService { private PaymentService paymentService = new PaymentService(); // ❌ } ``` Works fine. No errors. Ship it 🚀 But now ask yourself: * Can I mock this in testing? ❌ * Can I switch implementation easily? ❌ * Is Spring managing this object? ❌ You just bypassed **Dependency Injection** completely. --- ## 💥 What actually went wrong? You created **tight coupling**. Now your code is: * Hard to test * Hard to extend * Painful to maintain --- ## ✅ Correct Way (Production Mindset) ```java @Service public class OrderService { private final PaymentService paymentService; public OrderService(PaymentService paymentService) { this.paymentService = paymentService; } } ``` Now: ✔ Loose coupling ✔ Easy mocking ✔ Fully Spring-managed lifecycle --- ## 🚨 Sneaky Mistake (Most devs miss this) ```java public void process() { PaymentService ps = new PaymentService(); // ❌ hidden violation } ``` Even inside methods — it’s still breaking DI. --- ## 🧠 Where `new` is ACTUALLY OK ✔ DTO / POJO ✔ Utility classes ✔ Builders / Factory pattern --- ## ❌ Where it’s NOT OK ✖ Services ✖ Repositories ✖ External API clients ✖ Anything with business logic --- ## ⚡ Reality Check In the AI era, anyone can generate working code. But production-ready engineers ask: 👉 “Who is managing this object?” 👉 “Can I replace this tomorrow?” 👉 “Can I test this in isolation?” --- ## 🔥 One Line to Remember > If you are using `new` inside a Spring-managed class… > you are probably breaking Dependency Injection. --- Stop writing code that just works. Start writing code that survives. #Java #SpringBoot #CleanCode #SystemDesign #Backend #SoftwareEngineering

GitHub Copilot— AI pair programmer — and like any collaborator, the quality of output depends on how you communicate. High-Impact Prompt Patterns —— 1. Be explicit about architecture “Create a microservice with controller, service, and repository layers using Spring Boot” 2. Add constraints “Optimize this method for O(n) complexity and avoid nested loops” 3. Define role/context “Act as a senior Java developer and refactor this code for scalability” 4. Ask for improvements, not just code “Identify performance bottlenecks and suggest improvements” 5. Generate tests & documentation “Write JUnit test cases with Mockito for this service class” Because in the AI era, how you ask matters more than how fast you type. #GitHubCopilot #AIforDevelopers #Productivity #SoftwareEngineering

Just used cursor-agent with debug mode to fix Git source scanning issue in Cursor IDE. TL;DR had to downgrade Electron ## Scope - Symptom: Cursor Git integration failed with `No full commit provider registered`. - Environment: Arch Linux, `cursor-bin` 3.2.11-1, workspace `/srv/python/test-project`. - Impact: Source-control dependent UI/features in Cursor were broken or stuck. ## Root Cause Cursor `3.2.11` (built on VSCode `1.105.1`, Electron 37 line) was executed with **system Electron 41** due Arch `cursor-bin` wrapper/dependency behavior: - Wrapper (`/usr/share/cursor/cursor`) used `name=electron` (generic). - On this machine, `electron` resolved to `/usr/lib/electron41/electron`. This version skew caused startup/runtime incompatibilities in Cursor internal extension hosts (especially always-local/git worker), so the full commit provider was not registered before renderer calls needed it. ## Runtime Evidence 1. Wrong Electron runtime selected:   - Process exec path during failing runs: `/usr/lib/electron41/electron`.   - `cursor-bin` dependency included generic `electron` (not pinned major). 2. V8/launch mismatch signal:   - Captured stderr: `Error: unrecognized flag --nodecommit_pooled_pages`.   - Cursor app code includes Linux js-flag injection of `--nodecommit_pooled_pages`. 3. Extension host instability:   - Logs showed extension host unresponsive events in failing sessions.   - Git worker host existed, but provider registration path still failed in renderer startup. 4. Reproducible renderer failure in prior sessions:   - `~/.config/Cursor/logs/20260425T171954/window1/renderer.log` had multiple `No full commit provider registered` entries shortly after extension-host startup. ## Fix Applied 1. Installed Electron 37:   - `electron37 37.5.1-1` 2. Patched Cursor wrapper:   - `/usr/share/cursor/cursor`: `name=electron37` (was `name=electron`) 3. Restarted Cursor processes and launched fresh session. ## Post-Fix Verification Fresh session (`~/.config/Cursor/logs/20260426T063949/`) showed: - Cursor processes running on `/usr/lib/electron37/electron`. - No `No full commit provider registered` hits in new session logs. - No `Extension host ... unresponsive` / `UNRESPONSIVE` in new session logs. - `vscode.git/Git.log` present and active in the new run. ## Recommendations for App Author 1. **Detect unsupported Electron major at startup** and fail fast with actionable error text. 2. **Avoid generic Linux package assumptions**; document/ship strict Electron major compatibility. 3. **Guard provider-dependent renderer paths** so missing provider degrades gracefully instead of hard error loops. 4. **Emit explicit diagnostics** when commit provider registration does not occur within expected init window. 5. **Consider removing/feature-gating deprecated V8 flags** like `--nodecommit_pooled_pages` for newer Electron runtimes.