DEV Community: SANKET PATIL

Troubleshooting .NET MAUI on macOS: From Build Errors to Device Debugging

SANKET PATIL — Fri, 18 Sep 2026 11:12:58 +0000

Part 2 of 2 - Troubleshooting the development environment

In Part 1, I covered how I approached setting up a reliable .NET MAUI development environment on macOS.

This article focuses on what happened when things didn't work as expected.

The interesting part of setting up a development machine isn't always installing the tools. Sometimes the tools are installed, the expected commands exist, and everything looks correct - but the actual application still cannot build or run.

That's where troubleshooting becomes important.

During my setup, I encountered several situations where the first assumption wasn't the actual cause of the problem.

That led me to a simple principle:

Don't troubleshoot based only on what is installed. Troubleshoot based on what the application and build tools can actually see and use.

1. Start With the Error, Not the Installation
2. Xcode Is Installed - So Why Isn't It Working?
3. When Xcode and MAUI Versions Need to Align
4. When Android Setup Doesn't Complete Cleanly
5. The JDK Exists, But the Build Can't Find It
6. From ADB to a Real Physical Device
7. Build Success Isn't the Finish Line
8. A Systematic Troubleshooting Approach
My Troubleshooting Checklist
What I Learned
Conclusion

1. Start With the Error, Not the Installation

When a development environment isn't working, the natural reaction is often:

"Something isn't installed correctly."

Sometimes that's true.

But reinstalling everything isn't necessarily the best first step.

A better starting point is the actual error.

Think about the environment as a dependency chain:

Project
   ↓
.NET SDK
   ↓
.NET MAUI workload
   ↓
Platform tooling
   ↓
Build tools
   ↓
Simulator / Device
   ↓
Application

If the application fails somewhere in that chain, the error usually gives you a starting point.

For example:

iOS build failure
        ↓
   Check Xcode
        ↓
Check selected developer directory
        ↓
Check .NET / MAUI workload
        ↓
Check compatibility

Or:

Android build failure
        ↓
Check Android SDK
        ↓
    Check JDK
        ↓
Check JDK discovery
        ↓
Check build configuration

The goal is to narrow the problem down before changing anything.

A useful rule

Find the failing layer before trying to fix the environment.

This sounds obvious, but it can prevent a lot of unnecessary reinstallations.

2. Xcode Is Installed - So Why Isn't It Working?

One of the first issues I encountered was with Xcode.

The full Xcode application was installed, but the active developer directory wasn't pointing to it.

I checked:

xcode-select -p

and got:

/Library/Developer/CommandLineTools

This was an important clue.

Having Apple's Command Line Tools selected doesn't necessarily mean the full Xcode installation is the active developer environment.

I then checked the actual Xcode command-line tooling:

xcodebuild -version

and the simulator tooling:

xcrun simctl list

These checks helped distinguish between:

Xcode is installed

and:

The expected Xcode tooling is available to the development environment

If necessary, the active developer directory can be changed:

sudo xcode-select --switch /Applications/Xcode.app

Then verify again:

xcode-select -p
xcodebuild -version

The lesson

Don't stop at:

"Xcode is installed."

Ask:

"Is the correct Xcode installation active, and can the command-line tooling use it?"

This was one of the first examples that changed how I looked at the setup.

3. When Xcode and MAUI Versions Need to Align

Another important part of the setup was version compatibility.

A .NET MAUI application isn't dependent on a single version.

There are several layers:

.NET SDK
    ↓
.NET MAUI workload
    ↓
.NET iOS workload
    ↓
  Xcode
    ↓
Apple SDK

The project repository can also define specific versions.

For an existing application, files such as:

global.json
Directory.Build.props
*.csproj

can tell you what the project expects.

In my setup, the repository pinned the .NET SDK and MAUI versions. The project used .NET SDK 10.0.203 and MAUI 10.0.60, so simply installing the newest available versions wasn't the goal.

The goal was to reproduce the environment expected by the project.

This is particularly important when setting up an existing application rather than starting a brand-new project.

Capture the versions together

When troubleshooting an iOS build, I found it useful to capture:

dotnet --info
dotnet workload list
xcodebuild -version

Instead of looking at these as independent applications, treat them as one toolchain.

For example:

.NET SDK
   +
MAUI workload
   +
 Xcode
   +
Apple SDK
   =
iOS development toolchain

If one component changes, the others may become relevant.

The lesson

For an existing project, compatibility is more important than simply using the newest version.

4. When Android Setup Doesn't Complete Cleanly

Android setup presented a different challenge.

The initial machine didn't have all the Android development components available.

The setup process needed to establish:

Android SDK
JDK
Build Tools
Platform Tools
ADB

An automated setup process installed Microsoft OpenJDK 21 and bootstrapped the Android SDK, but the overall setup eventually timed out while installing packages.

At that point, it would have been easy to assume:

"The Android setup failed. Start again."

Instead, I checked what had actually been installed.

For example:

java -version

and:

adb version

Then I inspected the Android SDK and its installed components.

This matters because a timeout doesn't necessarily mean that every operation performed before the timeout was unsuccessful.

You may already have:

the JDK
Android SDK
platform tools
build tools
SDK platforms

installed and ready.

The better approach

Instead of:

Setup failed
    ↓
Reinstall everything

try:

Setup failed / timed out
        ↓
Inspect current state
        ↓
Identify what's missing
        ↓
Install only what's missing
        ↓
Continue verification

The lesson

When an automated setup fails, inspect the resulting environment before starting over.

5. The JDK Exists, But the Build Can't Find It

This was the most interesting Android issue I encountered.

The JDK was installed.

Java was available on the machine.

But the .NET MAUI Android build still failed.

The build reported an XA5300 error because it couldn't locate the Java SDK.

The important part of the investigation was that the problem wasn't simply:

"Java isn't installed."

The JDK existed.

The problem was JDK discovery.

The build process was using Java discovery through:

/usr/libexec/java_home

but it wasn't resolving the installed JDK in the way the build expected.

This highlighted an important distinction:

JDK installed
     ≠
JDK discoverable
     ≠
JDK usable by the build

Step 1: Verify Java

First:

java -version

Then:

/usr/libexec/java_home -V

These commands answer slightly different questions.

The first tells you whether Java is available.

The second helps determine what JDK installations macOS can discover through its Java tooling.

Step 2: Find the actual JDK

The next step was to determine where the JDK was actually installed.

In this setup, the JDK was installed under the Android developer directory.

At this point, the question changed from:

"Is Java installed?"

to:

"What JDK path should the MAUI Android build use?"

Step 3: Explicitly configure the JDK

Rather than continuing to rely on automatic discovery, I configured the build to use the explicit JDK location.

After that change, the Android build progressed successfully.

Why this matters

This pattern applies to many development tools.

A dependency can be:

installed
visible in the file system
available from your terminal

and still be unavailable to the process that actually needs it.

The same idea applies to SDKs, compilers, runtimes, command-line tools, and environment variables.

The lesson

When a build says a dependency is missing, verify whether it is actually missing or simply undiscoverable.

That distinction can save a lot of time.

6. From ADB to a Real Physical Device

Once the Android build environment was working, I wanted to verify the complete development workflow on a physical device.

A physical Android device introduces another layer:

Mac
 ↓
Android SDK
 ↓
ADB
 ↓
Physical device
 ↓
MAUI application
 ↓
Debugger

The first check was deliberately independent of MAUI:

adb devices

The device appeared as an authorized device.

That confirmed:

Mac
 ↓
ADB
 ↓
Device

But that still wasn't enough.

ADB seeing the device doesn't automatically prove that:

the MAUI project can build
the application can deploy
the application can launch
the debugger can attach

So I treated these as separate verification steps.

The complete sequence

1. Connect device
        ↓
2. Enable USB debugging
        ↓
3. Authorize the Mac
        ↓
4. Verify with adb devices
        ↓
5. Build the MAUI project
        ↓
6. Deploy the application
        ↓
7. Launch the application
        ↓
8. Attach the debugger

This is much more useful than simply checking whether the device appears in ADB.

The lesson

Verify each boundary separately.

When something fails, you immediately know which layer to investigate.

7. Build Success Isn't the Finish Line

Another lesson from the setup was that a successful build isn't the same as a ready development environment.

It's possible to reach:

Build succeeded

and still have problems with:

deployment
simulator/device detection
application startup
debugger attachment
runtime behavior

That's why I prefer validating the complete workflow:

Restore
   ↓
 Build
   ↓
 Deploy
   ↓
 Launch
   ↓
 Debug
   ↓
Breakpoint

For iOS, this means verifying that the Simulator can run the application.

For Android, it means going beyond a successful build and validating deployment on an emulator or physical device.

The final test isn't:

"Did the command finish successfully?"

It's:

"Can I actually use this machine for my normal development workflow?"

That is a much stronger definition of "ready."

8. A Systematic Troubleshooting Approach

After going through these issues, I found a simple process useful.

Step 1: Read the error carefully

Don't immediately jump to a fix.

Identify what the error is actually saying.

For example:

Can't find Java SDK

doesn't necessarily mean:

Java isn't installed

It could mean:

The build can't discover the installed Java SDK

Those require different actions.

Step 2: Identify the failing layer

Use the dependency chain:

Project
  ↓
.NET SDK
  ↓
MAUI workload
  ↓
iOS / Android tooling
  ↓
Build tools
  ↓
Simulator / Device
  ↓
Application

Find the smallest layer that explains the failure.

Step 3: Verify the dependency independently

Use simple commands to validate individual components.

For .NET:

dotnet --info
dotnet workload list

For Xcode:

xcode-select -p
xcodebuild -version

For Java:

java -version
/usr/libexec/java_home -V

For Android:

adb version
adb devices

The goal is to separate:

Project problem

from:

Environment problem

Step 4: Compare expected vs actual

This is especially important for existing projects.

Ask two questions:

What does the project expect?

and:

What is the machine actually using?

For example:

Expected SDK version
        vs
Active SDK version

or:

Expected JDK location
        vs
JDK location discovered by the build

Step 5: Change one thing at a time

If you simultaneously change:

.NET SDK
MAUI workload
Xcode
JDK
Android SDK

and the build starts working, you may never know which change fixed it.

Whenever possible:

Observe
  ↓
Change one thing
  ↓
Verify
  ↓
Continue

This makes troubleshooting much easier to reason about.

Step 6: Re-test the real workflow

After making a change, don't stop at the individual command that previously failed.

Run the actual workflow again:

Restore
   ↓
 Build
   ↓
 Deploy
   ↓
  Run
   ↓
 Debug

That's the final validation.

My Troubleshooting Checklist

.NET

[ ] dotnet --info shows the expected SDK
[ ] global.json requirements checked
[ ] MAUI workload installed
[ ] Workload version verified

iOS

[ ] Xcode installed
[ ] Correct Xcode selected
[ ] xcodebuild works
[ ] iOS runtimes available
[ ] Simulator launches
[ ] Project builds for iOS

Android

[ ] JDK installed
[ ] JDK discoverable by the build
[ ] Android SDK installed
[ ] Required platform installed
[ ] Build tools installed
[ ] Platform tools installed
[ ] adb available
[ ] Device authorized
[ ] Project builds for Android

Application

[ ] Dependencies restored
[ ] Application builds
[ ] Application deploys
[ ] Application launches
[ ] Debugger attaches
[ ] Breakpoints work

What I Learned

The biggest change in my approach was moving away from installation-based troubleshooting.

It is easy to think:

"The JDK is installed, so Java isn't the problem."

Or:

"Xcode is installed, so iOS development should work."

But the more useful questions are:

What does the project require?

What is actually installed?

What is currently selected?

Can the build process discover it?

Can the application actually use it?

That gives us a much more useful model:

                PROJECT
                   │
                   ▼
             What does it need?
                   │
                   ▼
             What is installed?
                   │
                   ▼
          What is actually selected?
                   │
                   ▼
        Can the build process find it?
                   │
                   ▼
             Does the build work?
                   │
                   ▼
       Can the application run?
                   │
                   ▼
          Can I actually debug it?

Every failed step reduces the area you need to investigate.

Conclusion

Setting up a development machine isn't really about installing a list of applications.

It's about creating a working chain of dependencies.

When something breaks, the fastest approach isn't always to reinstall everything.

Instead:

Inspect → Isolate → Verify → Fix → Re-test

Start with the actual failure.

Understand which layer is failing.

Verify the dependency independently.

Make the smallest necessary change.

Then test the complete application workflow again.

The most useful distinction I took away from this experience is:

Installed ≠ configured ≠ discoverable ≠ usable.

A tool is only useful when the application and build system can actually find and use it.

That's what turns a development machine from a collection of installed tools into a reliable development environment.

If you haven't read Part 1 yet, it covers the initial setup and verification process that led to these troubleshooting scenarios.

Part 1: Setting Up a Reliable .NET MAUI Development Environment on macOS

Setting Up a Reliable .NET MAUI Development Environment on macOS

SANKET PATIL — Fri, 18 Sep 2026 10:36:19 +0000

Setting up a new development machine for a .NET MAUI project sounds simple.

Install .NET.
Install Xcode.
Install Android Studio.
Clone the repository.
Run the application.

At least, that's how it looks on paper.

When you're setting up a Mac for an existing production .NET MAUI project, there are several more pieces involved. The .NET SDK, MAUI workload, Xcode, iOS tooling, Android SDK, JDK, device configuration, signing, and project-specific requirements all need to work together.

I recently went through this process while setting up a Mac for an existing .NET MAUI application. Along the way, I encountered several issues that were not obvious from the initial setup.

That experience led me to a simple conclusion:

A development environment isn't ready when the tools are installed. It's ready when the application can build, run, and be debugged.

This is Part 1 of a two-part series.

Part 1: Setting up a reliable .NET MAUI development environment on macOS
Part 2: Troubleshooting .NET MAUI setup issues on macOS

What We Are Trying to Achieve
1. Start With the Repository
2. Install and Verify the .NET SDK
3. Install the .NET MAUI Workload
4. Configure Xcode for iOS Development
5. Pay Attention to Xcode and MAUI Compatibility
6. Verify the iOS Simulator
7. Configure Android
8. Verify the JDK
9. Configure the Android SDK
10. Emulator or Physical Device?
11. Connect a Physical Android Device
12. Restore the Actual Project
13. Don't Ignore Warnings
14. Validate Debugging, Not Just Deployment
15. My Setup Checklist
What I Learned
Conclusion

What We Are Trying to Achieve

The goal isn't just to install the required tools.

We want to reach this state:

Project requirements
        ↓
    .NET SDK
        ↓
.NET MAUI workload
        ↓
Xcode + iOS tooling
        ↓
Android SDK + JDK
        ↓
Simulator / Emulator
        ↓
 Physical device
        ↓
 Project restore
        ↓
      Build
        ↓
       Run
        ↓
      Debug

If any layer is missing or incompatible, the setup may appear complete while the actual application still doesn't work.

1. Start With the Repository

Before installing anything, look at the project.

This is probably the most important step in the entire setup.

Don't start by installing the latest versions of every tool.

Instead, first determine what the application actually expects.

For a .NET MAUI repository, look for files such as:

global.json
Directory.Build.props
*.csproj
NuGet.config
README.md
docs/

Things worth checking include:

.NET SDK version
MAUI version
MAUI workload version
Target frameworks
Android API level
iOS minimum version
Required NuGet feeds
Development tooling
Signing requirements

For example, a repository may contain a global.json similar to:

{
  "sdk": {
    "version": "10.0.203",
    "rollForward": "disable"
  },
  "tools": {
    "dotnet-workload-version": "10.0.203"
  }
}

And a central MSBuild file may define the MAUI version:

<PropertyGroup>
    <MauiVersion>10.0.60</MauiVersion>
</PropertyGroup>

This immediately tells us something important:

The repository is part of the setup documentation.

The project itself often contains more accurate requirements than a generic installation guide.

2. Install and Verify the .NET SDK

Once the required version is known, install the corresponding .NET SDK.

After installation, don't assume it worked.

Verify it:

dotnet --version

Then inspect the complete environment:

dotnet --info

The second command is particularly useful because it shows:

SDK version
Runtime version
OS
Architecture
Workload information
SDK installation path
global.json information

For example:

.NET SDK:
 Version: 10.0.203

Runtime Environment:
 OS: Mac OS X
 Architecture: arm64

If the project has a global.json, make sure the SDK being used matches it.

Why not simply use the latest SDK?

Because an existing application may have been tested against a specific SDK and workload combination.

A newer SDK isn't automatically a better SDK for an existing project.

For project setup, compatibility is more important than recency.

3. Install the .NET MAUI Workload

Installing the .NET SDK doesn't automatically mean the MAUI development environment is ready.

Check the installed workloads:

dotnet workload list

If MAUI isn't installed, install it:

dotnet workload install maui

Then verify again:

dotnet workload list

For repositories that pin the workload version, follow the repository's configuration rather than manually selecting an unrelated workload version.

This distinction matters because the MAUI workload is closely tied to the .NET SDK and platform tooling.

4. Configure Xcode for iOS Development

For iOS development, Xcode is not optional.

After installing Xcode, verify which developer directory macOS is using:

xcode-select -p

Then check the Xcode version:

xcodebuild -version

A common setup issue is having Apple's Command Line Tools installed while Xcode itself is not the active developer directory.

For example:

/Library/Developer/CommandLineTools

may be returned by:

xcode-select -p

while commands such as xcodebuild or simctl still require the full Xcode installation.

If necessary, select Xcode explicitly:

sudo xcode-select --switch /Applications/Xcode.app

Then verify again:

xcodebuild -version

The important lesson is:

Installed doesn't necessarily mean configured.

5. Pay Attention to Xcode and MAUI Compatibility

This is an area where mobile development differs from many typical .NET applications.

Your application depends on multiple layers:

.NET SDK
   ↓
.NET MAUI workload
   ↓
.NET iOS workload
   ↓
 Xcode
   ↓
Apple SDK

Changing one of these can affect the others.

For example, upgrading Xcode may require using a compatible .NET workload version.

So when troubleshooting an iOS build, capture the versions together:

dotnet --info
dotnet workload list
xcodebuild -version

Don't troubleshoot them independently.

Think of them as a toolchain, not separate applications.

6. Verify the iOS Simulator

Once Xcode is configured, launch the Simulator.

You can open it with:

open -a Simulator

You can also inspect available runtimes:

xcrun simctl list runtimes

And devices:

xcrun simctl list devices

At this point, the objective is simple:

Can the Mac see an iOS simulator that the MAUI project can target?

If yes, move on to the actual application.

7. Configure Android

Android has another dependency chain:

.NET SDK
   ↓
.NET MAUI
   ↓
Android SDK
   ↓
  JDK
   ↓
Android Build Tools
   ↓
  ADB
   ↓
Emulator / Physical Device

The JDK is particularly important.

A .NET MAUI Android build isn't only dependent on .NET. The Android toolchain also needs a compatible Java Development Kit.

8. Verify the JDK

First check whether Java is available:

java -version

Also check:

/usr/libexec/java_home -V

The important thing isn't simply having Java installed.

The build system needs to be able to find the correct JDK.

This distinction becomes especially important when multiple Java installations exist on a development machine.

A JDK can exist on disk while the .NET Android build still reports that it cannot find a Java SDK.

We'll look at this scenario in detail in Part 2.

9. Configure the Android SDK

The Android SDK needs several components depending on the project's requirements.

Typical components include:

platform-tools
platforms;android-XX
build-tools;XX.X.X
cmdline-tools
emulator
system-images

Check the SDK location and installed components.

For example:

echo $ANDROID_HOME

And:

ls "$ANDROID_HOME"

ADB should also be available:

adb version

If adb isn't found but the Android SDK's platform-tools directory exists, the SDK may be installed correctly but not configured on your shell's PATH.

For example:

export ANDROID_HOME="$HOME/Library/Developer/Android/sdk"
export PATH="$ANDROID_HOME/platform-tools:$PATH"

Then:

adb devices

10. Emulator or Physical Device?

For Android development, there are two common deployment targets:

Android Emulator
Physical Android device

Both are useful.

The emulator is convenient for everyday development and testing different configurations.

A physical device is particularly useful for validating:

Real hardware behavior
Device-specific issues
OS-specific behavior
Performance
Lifecycle behavior
Native platform behavior

For production mobile applications, I prefer having access to both.

11. Connect a Physical Android Device

To debug on a physical Android device:

Enable Developer Options.
Enable USB debugging.
Connect the device to the Mac.
Authorize the computer on the device.
Verify the connection.

Run:

adb devices

A successfully connected device should appear as:

List of devices attached
<device-id>    device

Once ADB sees the device, the next question is whether the MAUI project can actually build and deploy to it.

That distinction is important.

ADB sees device
        ≠
MAUI can deploy application

Both need to be verified.

12. Restore the Actual Project

Now we get to the most important part.

Stop testing the environment with individual commands.

Test the actual application.

From the repository root:

dotnet restore

Or, if the repository provides a solution file:

dotnet restore ALPAMobile.sln

Then build the required platform.

iOS

dotnet build ALPAMobile/ALPAMobile.csproj \
    -f net10.0-ios \
    -c Debug

Android

dotnet build ALPAMobile/ALPAMobile.csproj \
    -f net10.0-android \
    -c Debug

The exact project and target framework will obviously vary by repository.

13. Don't Ignore Warnings

A successful build can still produce useful warnings.

For example, dependency security warnings may appear during restore or build.

These should not automatically be treated as setup failures.

Separate the output into categories:

Build errors
Warnings
Dependency warnings
Environment warnings
Runtime issues

This makes troubleshooting much easier.

The objective during initial setup is to determine:

Can the application successfully restore, compile, deploy, and run?

Not:

Does the terminal output contain zero warnings?

Those are different goals.

14. Validate Debugging, Not Just Deployment

The final step is to verify the actual development workflow.

For example:

Open project
     ↓
Start Debug
     ↓
Application builds
     ↓
Application deploys
     ↓
Application launches
     ↓
Debugger attaches
     ↓
Breakpoint hits

This is a much stronger validation than simply seeing an application icon appear on a simulator or device.

A developer environment should support the workflow you actually need every day.

15. My Setup Checklist

After going through the setup process, I found it useful to think of the environment as a checklist rather than a collection of installed applications.

Project

[ ] Repository cloned
[ ] global.json checked
[ ] MAUI version checked
[ ] Target frameworks checked
[ ] Project-specific documentation reviewed

.NET

[ ] Required SDK installed
[ ] Correct SDK selected
[ ] MAUI workload installed
[ ] Workload version verified

iOS

[ ] Xcode installed
[ ] Xcode selected with xcode-select
[ ] Xcode version verified
[ ] iOS runtime installed
[ ] Simulator launches
[ ] Application builds for iOS

Android

[ ] JDK installed
[ ] JDK discoverable by the build
[ ] Android SDK installed
[ ] Required platform installed
[ ] Build tools installed
[ ] Platform tools installed
[ ] ADB available
[ ] Emulator configured
[ ] Physical device detected

Application

[ ] Dependencies restored
[ ] iOS Debug build succeeds
[ ] Android Debug build succeeds
[ ] iOS Simulator launches application
[ ] Android Emulator launches application
[ ] Physical Android device launches application
[ ] Debugger attaches successfully

What I Learned

The biggest lesson from setting up a new Mac for an existing MAUI project was that environment setup is really dependency management.

The tools don't exist independently.

A simplified view looks like this:

             Project
                │
                ▼
          .NET SDK version
                │
                ▼
          MAUI workload
          /           \
         /             \
        ▼               ▼
     Xcode          Android SDK
        │               │
     iOS SDK            JDK
        │               │
   Simulator         ADB/device

If one layer is incompatible or incorrectly configured, the failure may appear somewhere else.

For example, an Android build error may look like a project problem when the actual issue is simply that the build process cannot locate the JDK.

Likewise, an iOS build problem may initially look like a MAUI problem when the underlying issue is the selected Xcode installation or an incompatible toolchain combination.

This is why I now approach a new development environment with three questions:

1. What does the project require?

Don't guess.

Read the repository configuration.

2. What is actually installed?

Use commands such as:

dotnet --info
dotnet workload list
xcodebuild -version
java -version
adb version

3. Does the actual application work?

Ultimately:

Restore → Build → Deploy → Run → Debug

is the real test.

Conclusion

Setting up .NET MAUI on macOS isn't difficult because any single component is particularly complicated.

It's challenging because several components have to work together.

The most reliable approach I've found is:

Inspect → Install → Configure → Verify → Build → Run → Debug

And most importantly:

Don't consider the machine ready just because the installation completed. Consider it ready when the actual application can be developed on it.

In Part 2, I'll go through the troubleshooting side of this setup - including what happens when Xcode is installed but isn't being used, Android SDK installation partially succeeds, the JDK exists but the build can't find it, and how to systematically diagnose these problems instead of repeatedly reinstalling tools.

Coming next: Part 2-Troubleshooting .NET MAUI on macOS: From Build Errors to Device Debugging

My Journey to Passing AZ-900: Microsoft Azure Fundamentals

SANKET PATIL — Mon, 22 Jun 2026 06:45:51 +0000

Recently, I achieved the Microsoft Azure Fundamentals (AZ-900) certification. While the certification is considered an entry-level Azure exam, the journey taught me several valuable lessons about cloud computing, exam preparation, and continuous learning.

Why I Decided to Pursue AZ-900

As a software engineer, I wanted to strengthen my understanding of cloud concepts and Azure services. Although I work primarily in application development, cloud technologies have become an essential part of modern software delivery. AZ-900 provided a structured way to build foundational knowledge across cloud concepts, architecture, security, governance, networking, storage, and cost management.

My Preparation Approach

I primarily relied on Microsoft Learn modules and practice assessments. Initially, I focused on understanding concepts rather than memorizing answers. Topics such as cloud service models (IaaS, PaaS, SaaS), Azure regions, availability zones, virtual networks, storage services, and governance tools formed the core of my preparation.

One of the biggest lessons I learned was that understanding the differences between similar services is critical. For example:

Azure Policy vs RBAC
Azure Monitor vs Application Insights
VPN Gateway vs ExpressRoute
Azure Advisor vs Azure Migrate
Availability Zones vs Region Pairs

Many exam questions are scenario-based and require understanding when to use a specific service rather than simply knowing its definition.

Challenges During Preparation

Practice assessments were not always consistent. My scores fluctuated across attempts, which was initially discouraging. Some assessments focused heavily on governance and monitoring, while others emphasized architecture and networking concepts.

Instead of focusing solely on scores, I reviewed every incorrect answer and created flashcards for recurring weak areas. This approach helped me improve my understanding and confidence over time.

Exam Experience

The exam tested both foundational concepts and practical scenarios. Reading questions carefully was important because Microsoft often includes keywords that point directly to the correct service or feature.

A few tips from my experience:

Understand concepts instead of memorizing answers.
Focus on service selection scenarios.
Review governance and monitoring topics thoroughly.
Use practice assessments to identify weak areas.
Stay calm during the exam and avoid overthinking questions.

Final Result

I successfully passed the AZ-900 certification exam and earned the Microsoft Azure Fundamentals certification.

More importantly, the journey improved my understanding of cloud computing fundamentals and provided a stronger foundation for future Azure learning paths.

Key Takeaway

Certification is not just about passing an exam. It is about building confidence, learning new concepts, and creating a foundation for future growth. Every practice test, mistake, and revision contributed to the final outcome.

For anyone considering AZ-900, my advice is simple: focus on understanding the concepts, practice consistently, and don't get discouraged by practice assessment scores. Progress matters more than perfection.

Fixing Bugs Is Easy. Preventing Their Return Is Hard

SANKET PATIL — Fri, 12 Jun 2026 08:20:17 +0000

Most developers celebrate when they identify the root cause of a bug.

The debugger finally reveals the problem. The fix is coded. Tests pass. A pull request is raised.

But in my experience, finding and fixing the bug is often the easiest part of the process.

The real challenge is proving that the fix is correct.

The Illusion of a Successful Fix

A common mistake is to focus only on making the reported issue disappear.

Imagine a mobile application crashes when a user performs a specific action. After investigating, we discover an exception being thrown from an asynchronous operation. We add exception handling, verify the crash no longer occurs, and consider the issue resolved.

The problem is that we only answered one question:

"Does the application still crash?"

We didn't answer the more important question:

"Did we actually fix the underlying problem without breaking anything else?"

Symptoms vs Root Causes

One lesson I've learned is that symptoms and root causes are rarely the same thing.

A crash report may point to a particular line of code, but that line is often just where the failure becomes visible.

Before implementing any fix, I try to understand:

Why did the system enter this state?
What assumptions were violated?
What conditions allowed the issue to occur?
Could the same root cause appear somewhere else?

Treating symptoms instead of causes often leads to recurring bugs that reappear weeks later under slightly different conditions.

The Regression Question

Every bug fix introduces risk.

When reviewing a fix, I always ask:

What behavior changed?
Which users are affected?
Which code paths are now different?
What existing functionality depends on this logic?

A fix that solves one issue but creates two new ones is not really a fix.

This is why regression validation is often more important than writing the code change itself.

Confidence Over Hope

Many teams validate fixes with a simple process:

Reproduce the bug.
Apply the fix.
Verify the bug no longer occurs.

While necessary, this is rarely sufficient.

I prefer adding additional validation:

Test edge cases.
Test failure scenarios.
Review related code paths.
Consider platform-specific behavior.
Verify assumptions made by the fix.

The goal is not to prove the fix works once.

The goal is to build confidence that it continues to work under real-world conditions.

The Best Fixes Prevent Future Bugs

The highest-quality fixes often do more than resolve the current issue.

They make similar issues harder to introduce in the future.

Examples include:

Adding defensive error handling.
Improving logging and observability.
Removing unsafe assumptions.
Strengthening automated tests.
Simplifying complex logic.

A bug fix should improve the system, not just patch a hole.

Final Thoughts

Over time, I've realized that debugging is only one part of software engineering.

Finding the bug demonstrates technical skill.

Designing a safe fix demonstrates engineering judgment.

The next time you solve a production issue, don't stop after the error disappears.

Ask yourself a harder question:

"How confident am I that this won't happen again?"

That's where the real work begins.

Production Systems Fail in Ways Tutorials Never Discuss

SANKET PATIL — Fri, 06 Mar 2026 11:52:01 +0000

Most engineers think of bugs as something technical.

A broken query.
A race condition.
A missing index.

You fix it, deploy a hotfix, and move on.

But sometimes a “bug” reveals something much deeper - not just about the system, but about how software businesses actually work.

Recently, I faced one such situation that changed how I think about production systems, ownership, and responsibility as a senior engineer.

The Performance Issue That Didn’t Make Sense

A customer reported that the application had become very slow.

Naturally, the first place we checked was the application infrastructure.

The application was running on an Azure App Service plan P1v3, which is a reasonably capable tier. When we looked at the metrics:

CPU utilization was below 60%
Memory looked stable
No major spikes in requests
No error rates

From the application side, everything looked normal.

So the question became:

If the application server is healthy, why is the app slow?

The First Clue: Local Environment Was Fast

When we tested the application locally using a restored database backup, the performance was significantly faster.

That was the moment we realized:

This might not be an application problem.

This might be a database problem.

The Real Culprit: A $5 Database Plan

After investigating the database metrics, we finally found the issue.

The production database was running on a $5 basic plan, and it was consistently hitting 100% utilization.

The application itself was fine.

But the database simply did not have enough resources to handle the workload.

Once the database became the bottleneck, every request slowed down - giving the impression that the entire system was performing poorly.

The Awkward Truth: We Had Recommended This Earlier

The uncomfortable part of this situation was that this wasn’t completely unexpected.

Earlier in the project we had recommended:

Start with the basic plan and upgrade the database as data grows.

This is a common and reasonable approach during early deployments.

But like many things in production systems, it was never revisited again.

The system kept growing.
The data increased.
Usage increased.

But the database plan stayed the same.

Eventually the performance issue surfaced - and the customer reported it as a bug.

The Engineering Instinct: Just Fix It

As engineers, our instinct is simple:

Fix the problem.

So the immediate solution was obvious:

Upgrade the database tier
Monitor performance
Verify application responsiveness

And technically, that would resolve the issue.

But this is where I learned something new - something that tutorials never teach.

The Business Reality of Fixed-Price Projects

This project had been delivered as a fixed-price engagement.

In such projects, development and delivery are scoped within an agreed cost.

But what happens months later when:

Infrastructure needs adjustment
External services change policies
Usage grows beyond initial assumptions
Performance tuning becomes necessary

Are these bugs?

Or are they support and maintenance work?

This is where things get complicated.

Startups and small teams often fall into a trap:

They keep fixing things for free because it feels like the “right thing to do.”

But over time, this creates a hidden cost for the company.

Engineering time becomes support time.

And support becomes unplanned work.

Another Case: When Third-Party Services Change

We encountered a similar situation with Auth0.

A change in policy meant that a callback configuration required updates, including adding localhost to the allowed callback URLs for certain flows.

This change caused issues in the application, and it was reported as a bug.

But the root cause wasn’t in our application code.

It was a policy change from a third-party service.

So the question becomes:

Should the development team fix this under the original project scope?

Or should it be treated as ongoing platform maintenance?

The Bigger Question: What Is Actually a Bug?

This experience made me rethink something important.

Not every issue reported in production is actually a software bug.

Some issues fall into other categories:

1. Infrastructure limitations
Example: Under-provisioned database resources.

2. Usage growth
Systems behaving differently as data and traffic scale.

3. Third-party service changes
Authentication providers, APIs, SDKs updating their policies.

4. Operational configuration issues
DNS, environment variables, callback URLs, quotas.

Yet many organizations treat all of these as bugs that must be fixed immediately.

And engineers often jump in and solve them without questioning the long-term impact.

What Larger Organizations Typically Do

More mature software organizations usually separate work into clear categories:

1. Development Scope
Features agreed in the project contract.

2. Warranty Period
A limited period where genuine defects are fixed.

3. Support / Maintenance Plan
Ongoing system maintenance, monitoring, infrastructure tuning, and external dependency updates.

This ensures that engineering teams are not constantly pulled into unplanned work months after delivery.

Lessons I Learned as an Engineer

This experience taught me several lessons that go beyond debugging.

1. Production Systems Are Living Systems

They evolve as data, users, and dependencies change.

Infrastructure decisions made early in a project may not hold months later.

2. Not Every Issue Is a Bug

Sometimes the system is behaving exactly as expected.

It’s the environment that changed.

3. Infrastructure Is Part of the Product

Developers often think only about application code.

But performance is frequently determined by:

database tiers
network limits
cache strategies
third-party APIs

Ignoring infrastructure can lead to misleading conclusions about “bugs”.

4. Fixed-Price Projects Need Clear Boundaries

Without clear support agreements, teams risk entering a cycle of continuous unpaid maintenance.

A sustainable approach usually includes:

post-launch support plans
infrastructure monitoring
defined response scopes
upgrade recommendations

5. Engineers Should Think Beyond Code

One of the biggest mindset shifts for me was realizing that senior engineering roles require understanding not only:

systems
debugging
architecture

but also product sustainability and operational ownership.

The health of a system is not just technical.

It’s also organizational.

Final Thought

The original problem looked like a simple performance bug.

But the deeper lesson had nothing to do with code.

It was about understanding how software systems, infrastructure, business agreements, and third-party dependencies intersect.

As engineers, we often focus on fixing the problem in front of us.

But sometimes the real challenge is asking a different question:

Is this actually a bug - or is this part of running a real production system?

And the answer to that question can shape how a product - and a company - operates long term.

What Working on Web Accessibility Taught Me (The Fun, the Frustration, and the Click)

SANKET PATIL — Thu, 05 Feb 2026 09:44:46 +0000

Web accessibility is one of those things most of us know is important - but don’t fully understand until we experience our own application from a completely different perspective.

Recently, I spent time working on an accessibility-focused proof of concept where I audited and improved a web module using WCAG 2.1 AA guidelines. What started as a technical exercise quickly became one of the most eye-opening development experiences I’ve had.

It was fun.

It was frustrating.

And eventually - it clicked.

In this post, I want to share what I learned while working through accessibility challenges and why it changed how I think about building web applications.

🎯 Why I Took an Accessibility-First Approach

Accessibility is often treated as a final checklist item — something you verify before release. I wanted to try a different approach: treat accessibility as a non-negotiable constraint from the start, similar to performance or security.

Instead of just scanning for issues, I tried to:

Audit UI components against WCAG guidelines
Fix problems at the component and system level
Verify fixes using real assistive technologies
Avoid “ARIA band-aids” and focus on proper semantics

That shift alone changed how I approached UI development.

⌨️ The First Reality Check: Keyboard-Only Navigation

The first thing I did was simple: I stopped using my mouse.

And immediately, I started noticing problems.

Things that felt completely fine visually became difficult to use:

Expandable rows that weren’t keyboard reachable
Buttons that had no visible focus state
Dialogs that opened but didn’t guide keyboard focus
UI flows that assumed users could see everything

Keyboard-only testing quickly exposes whether your UI is navigable, not just visually functional.

🔊 Screen Reader Testing: The Most Humbling Part

I then tested the application using a screen reader (NVDA).

That experience completely changed my perspective.

Some common issues I discovered:

Icon-only buttons announced as just “button”
Tables that lacked context or structure
Dynamic notifications that weren’t announced at all
Complex forms that were difficult to understand without visual grouping

Technically, nothing was broken.

But the experience was exhausting and confusing.

That’s when I realized:

👉 Accessibility problems don’t always block users — they often just make tasks unnecessarily difficult.

🧩 Accessibility Issues Are Usually Systemic

One of the biggest surprises during the audit was how many accessibility problems were repeated across components.

Examples included:

Icon buttons missing accessible names
Status messages not announced to assistive technologies
Missing focus management after dynamic UI changes
Animations ignoring reduced motion preferences

These weren’t page-specific bugs.

They were component-level patterns.

Fixing them once improved accessibility across multiple parts of the application.

Accessibility isn’t just about screens — it’s about shared UI primitives.

🤔 The Most Interesting Challenge: When a Table Isn’t Really a Table

One interface I worked on visually resembled a table but behaved more like a dynamic form where users could add and edit rows.

Initially, it used generic layout containers styled like a grid. Visually, it worked well. Semantically, it was confusing for assistive technologies.

I had to step back and ask:

Is this data display or data entry?
Should users navigate rows or form inputs?
What interaction model best matches user expectations?

Instead of forcing ARIA roles onto the layout, I switched to a more semantic structure using list and fieldset patterns. The visual design stayed the same, but the interaction became far clearer for screen readers and keyboard users.

That experience reinforced an important lesson:

👉 Accessibility is often solved through better structure, not more attributes.

🧠 How Accessibility Changes Your Development Mindset

After working through accessibility improvements, I started noticing things I previously ignored:

Where keyboard focus moves after actions
Whether UI updates are announced or silent
How clearly components communicate purpose
Whether interactions are predictable or surprising

Accessibility forces you to think beyond visuals and focus on user experience flow.

📚 Lessons I’m Taking Forward

Accessibility Is Experiential

Reading guidelines helps, but testing with real assistive tools reveals the actual user experience.

Most Accessibility Issues Aren’t Technically Complex

They’re often small structural or semantic improvements that simply require awareness.

Design Decisions Matter More Than ARIA Fixes

If the interaction model is wrong, ARIA rarely saves it. Starting with semantic HTML usually leads to better outcomes.

Accessibility Improves UX for Everyone

Clear focus states, predictable navigation, and meaningful feedback benefit all users, not just those using assistive technologies.

🏁 Closing Thoughts

Working on accessibility was genuinely fun — and occasionally frustrating in a productive way.

Fun because solving these problems feels impactful.

Frustrating because it reveals how easily users can be excluded without anyone noticing.

But once accessibility clicks, it becomes impossible to ignore.

If you’ve never tried using your application without a mouse or with a screen reader, I highly recommend it. You’ll likely learn more in 30 minutes than from reading documentation alone.

Here’s to building applications that work — for everyone 🚀

🚀 Building an AI-Powered Code Reviewer for Bitbucket Using Groq & Pipelines

SANKET PATIL — Tue, 09 Dec 2025 12:54:46 +0000

Modern development teams rely heavily on pull requests for code quality-but manual reviews are slow, inconsistent, and expensive. Recently, Bitbucket introduced Rovo Dev, and GitHub has Ask Copilot, both offering AI-assisted PR reviews.

But there was one major problem for me:

❌ I wasn’t ready to pay $20 per developer per month just to get AI reviews.

✅ I already had a Groq API key.

✅ I wanted a fully automated, pipeline-driven solution.

So I built my own AI-powered PR review system for Bitbucket using:

✅ Bitbucket Pipelines
✅ Groq LLM (llama-3.3-70b-versatile)
✅ Git-based diff extraction (no REST API auth headaches)

This system reviews every PR automatically and outputs a structured, checklist-driven AI review-with zero dependency on Bitbucket’s unreliable token ecosystem and zero per-developer licensing cost.

In this post, I’ll cover:

How this compares to Rovo Dev & GitHub Copilot
Why I avoided Bitbucket’s REST APIs
The final production architecture
How the AI review works
Key engineering lessons from building this

🤖 Rovo Dev vs Ask Copilot vs This Approach

Feature	Rovo Dev (Bitbucket)	Ask Copilot (GitHub)	This Groq-Based System
AI PR Reviews	✅	✅	✅
Fully Automated in CI	❌ (mostly UI based)	❌ (manual prompts)	✅
Per-Developer Cost	❌ $20/month/dev	❌ Bundled with Copilot	✅ $0 per dev
Works in Pipelines	❌	❌	✅
Custom Review Rules	❌ Limited	❌ Limited	✅ Full control
Vendor Lock-in	✅	✅	❌ None (Groq + Git)

I didn’t want:

Another per-seat SaaS subscription
A manual “Ask AI” workflow
Or a system that breaks when pricing changes

I wanted:
✅ Fully automated

✅ CI-level enforcement

✅ Custom review rules

✅ Lowest possible cost

That’s why I chose Groq + Pipelines.

❌ The Problem with Traditional Bitbucket PR Automation

Initially, I tried the standard approach:

Fetch PR diffs using the Bitbucket REST API
Post PR comments using:
- Atlassian API tokens
- Workspace tokens
- Repository access tokens

Despite correct scopes, PR comment posting repeatedly failed with 401 Unauthorized errors due to:

Inconsistent token behaviors
Bitbucket’s evolving security model
Poor documentation around 2025 token behavior

After continous debugging, I realized:

✅ The smartest move was to eliminate Bitbucket’s REST API entirely for diff collection.

✅ The Final Working Architecture

Here’s the production setup that actually works:

Pull Request Created
↓
Bitbucket Pipeline Triggered
↓
Git diff extracted using: git diff origin/main...HEAD
↓
Diff sent to Groq LLM
↓
AI generates structured checklist-based review
↓
Review shown in Pipeline logs + downloadable artifact

Why this works so well:

✅ No REST API calls for diffs
✅ No authentication failures
✅ No permission issues
✅ No flakiness
✅ Fully deterministic

🤖 The AI Review Rules (Enterprise-Grade)

The AI review is driven by a strict TypeScript + Angular + security checklist:

❌ No any types
✅ Strong typing with interfaces & generics
✅ Modern Angular syntax (@if, @for, standalone components)
✅ Authentication guards
✅ No hardcoded secrets
✅ Error handling
✅ Tests present
✅ Performance checks
✅ Accessibility (WCAG)
✅ Final verdict: MERGE READY / NEEDS WORK

This ensures:

Consistent reviews
Enforced standards
Zero reviewer bias

🧠 Git-Based Diff Instead of REST API

Instead of calling Bitbucket’s REST endpoints, the pipeline simply runs:

git fetch origin main
git diff origin/main...HEAD

This gives:

✅ The exact PR diff

✅ No API authentication

✅ Works in every CI environment

This single decision eliminated 90% of the system’s complexity.

⚡ Groq LLM Integration
The diff is sent to Groq using:
llama-3.3-70b-versatile

Why Groq?
⚡ Extremely fast inference

🧠 Excellent reasoning on large diffs

💸 Much cheaper than many alternatives

✅ OpenAI-compatible API

🌱 More eco-friendly due to lower compute time per request

The AI responds with:

🚨 Critical Issues

🔒 Security Analysis

⚡ Performance Review

🏗️ Architecture Feedback

📝 Maintainability

✅ Final Verdict: MERGE READY / NEEDS WORK

📄 Where the AI Review Appears Instead of battling PR comment permissions:

✅ The full AI review appears in the Pipelines logs

✅ Optionally saved as a downloadable ai-review.md artifact

✅ No PR write permissions required

✅ No security risks

This turned out to be far more enterprise-compliant than auto-commenting.

🧪 Production Impact After enabling this system:

✅ Every PR is reviewed automatically

✅ Developers get feedback in minutes

✅ Review standards are enforced consistently

✅ Human reviewers focus only on business logic

✅ No failed pipelines due to auth issues

✅ No wasted build minutes on retries

✅ Zero per-developer licensing cost

🔑 Key Engineering Lessons
Avoid brittle platform APIs when Git can do the job

AI reviewers should assist, not block developers

PR comments are optional-reviews must be reliable

Pipelines + Git + LLM = extremely powerful combination

Groq is ideal for CI/CD AI workloads

Not every AI solution needs a $20/month/dev license

📌 What’s Next?
Planned upgrades:

✅ Auto-block merge when verdict = NEEDS WORK

✅ Language-specific reviewers (.NET, SQL)

✅ Security-only review mode

✅ Architectural drift detection

✅ Final Thoughts
If you're using Bitbucket and want reliable AI-powered PR reviews without paying enterprise per-seat pricing, my recommendation is:

💡 Use Git for diff extraction + Groq for AI analysis + Pipelines for automation. Avoid REST API auth wherever possible.

It’s simpler. It’s faster. It’s cheaper. And it actually works in production.

Building an Auto-Logout System for Angular Applications: Securing User Sessions with Inactivity Detection

SANKET PATIL — Fri, 31 Oct 2025 11:20:33 +0000

🧠 Introduction

In modern web applications, security extends far beyond authentication - it’s also about protecting active user sessions from unauthorized access.

One often-overlooked feature in this area is automatic logout due to inactivity.

Imagine a user leaving a laptop unlocked with sensitive data on-screen. Without an inactivity timeout, that session remains vulnerable.

In this post, we’ll walk through how to implement a robust auto-logout mechanism in Angular that detects user inactivity, displays a warning dialog, and safely logs the user out after a configurable timeout period.

🚨 The Problem

Enterprise and data-sensitive applications often need to:

Automatically terminate sessions after inactivity
Display a warning before logout
Detect real user activity (not just page loads)
Prevent memory leaks via proper cleanup
Maintain a smooth, non-intrusive user experience

🧩 The Solution: InactivityService

We’ll build an InactivityService that can:

Detect inactivity using multiple event types
Display a configurable warning dialog
Auto-logout after a timeout
Clean up resources properly
Work seamlessly with Angular change detection

⚙️ Step 1: Service Setup

import { Injectable, NgZone } from '@angular/core';

@Injectable({
  providedIn: 'root'
})
export class InactivityService {
  private readonly INACTIVITY_TIMEOUT = 60 * 60 * 1000; // 1 hour
  private readonly WARNING_TIME = 5 * 60 * 1000; // 5 minutes

  private lastActivityTime = Date.now();
  private inactivityTimer: any = null;
  private warningTimer: any = null;
  private isWarningShown = false;
  private isTracking = false;

  private readonly activityEvents = [
    'mousedown', 'mousemove', 'keypress',
    'scroll', 'touchstart', 'click'
  ];

  constructor(private ngZone: NgZone) {}
}

Key Design Choices

Multiple event types: Tracks various forms of user input.
NgZone usage: Ensures Angular detects UI updates correctly.
State flags: Manage active state and prevent duplicate warnings.

🖱️ Step 2: Tracking User Activity

startTracking(): void {
  if (this.isTracking) return;

  this.isTracking = true;
  this.resetTimer();
  this.addActivityListeners();
}

private addActivityListeners(): void {
  this.activityEvents.forEach(event => {
    document.addEventListener(event, this.onActivity.bind(this), {
      passive: true,
      capture: true
    });
  });
}

private onActivity(): void {
  if (!this.isTracking) return;

  this.ngZone.run(() => {
    this.resetActivity();
  });
}

private resetActivity(): void {
  this.lastActivityTime = Date.now();
  this.isWarningShown = false;
  this.resetTimer();
}

Why This Matters

passive: true improves scroll performance.
Capturing phase ensures early event detection.
NgZone.run() allows Angular to refresh bindings if needed.

⏰ Step 3: Timer Management

private resetTimer(): void {
  this.clearTimers();

  // Warning before logout
  this.warningTimer = setTimeout(() => {
    this.showInactivityWarning();
  }, this.INACTIVITY_TIMEOUT - this.WARNING_TIME);

  // Auto-logout
  this.inactivityTimer = setTimeout(() => {
    this.performLogout();
  }, this.INACTIVITY_TIMEOUT);
}

private clearTimers(): void {
  if (this.inactivityTimer) clearTimeout(this.inactivityTimer);
  if (this.warningTimer) clearTimeout(this.warningTimer);
  this.inactivityTimer = this.warningTimer = null;
}

Timer Strategy

Separate timers for warning and logout.
Reset on any detected activity.
Clear all on logout to prevent memory leaks.

⚠️ Step 4: Displaying the Warning Dialog

We’ll create a minimal dialog using vanilla JavaScript to avoid external dependencies.

private showInactivityWarning(): void {
  if (this.isWarningShown || !this.isTracking) return;

  const existing = document.getElementById('inactivity-warning');
  if (existing) return;

  this.isWarningShown = true;

  const overlay = document.createElement('div');
  overlay.id = 'inactivity-warning';
  Object.assign(overlay.style, {
    position: 'fixed',
    top: '0', left: '0', right: '0', bottom: '0',
    background: 'rgba(0,0,0,0.4)',
    display: 'flex',
    alignItems: 'center',
    justifyContent: 'center',
    zIndex: '9999'
  });

  const dialog = document.createElement('div');
  Object.assign(dialog.style, {
    background: '#fff',
    padding: '24px',
    borderRadius: '8px',
    textAlign: 'center',
    boxShadow: '0 4px 10px rgba(0,0,0,0.3)',
    width: '300px'
  });

  const title = document.createElement('h3');
  title.textContent = 'Session Timeout Warning';

  const message = document.createElement('p');
  message.textContent = 'You will be logged out in 5 minutes due to inactivity.';

  const stayBtn = document.createElement('button');
  stayBtn.textContent = 'Stay Logged In';
  stayBtn.onclick = () => {
    this.dismissWarning();
    this.resetActivity();
  };

  const logoutBtn = document.createElement('button');
  logoutBtn.textContent = 'Logout Now';
  logoutBtn.onclick = () => {
    this.dismissWarning();
    this.performLogout();
  };

  dialog.append(title, message, stayBtn, logoutBtn);
  overlay.appendChild(dialog);
  document.body.appendChild(overlay);
}

private dismissWarning(): void {
  const warning = document.getElementById('inactivity-warning');
  if (warning) warning.remove();
  this.isWarningShown = false;
}

Advantages of This Approach

Zero external dependencies
Works even if Angular rendering pauses
Customizable look and feel

🚪 Step 5: Performing Logout

private performLogout(): void {
  if (!this.isTracking) return;

  this.stopTracking();
  this.dismissWarning();

  // Clear any cached data
  localStorage.clear();
  sessionStorage.clear();

  // Redirect to login or home page
  window.location.href = '/login';
}

stopTracking(): void {
  if (!this.isTracking) return;

  this.isTracking = false;
  this.clearTimers();

  this.activityEvents.forEach(event => {
    document.removeEventListener(event, this.onActivity.bind(this));
  });
}

🔗 Integration in Your Angular App

To enable inactivity tracking globally, start the service in your main AppComponent or after user login:

export class AppComponent implements OnInit {
  constructor(private inactivityService: InactivityService) {}

  ngOnInit(): void {
    this.inactivityService.startTracking();
    console.log('Inactivity tracking enabled');
  }
}

🧭 Best Practices

1. Configurable Timeouts

Use environment variables or role-based settings:

private readonly INACTIVITY_TIMEOUT = 15 * 60 * 1000; // 15 minutes for admins

2. Server-Side Session Expiry

Don’t rely solely on client logic-implement:

Short-lived JWTs
Refresh token rotation
Server-side session validation

3. UX & Accessibility

Provide clear messages
Allow time to respond
Add ARIA attributes for screen readers

4. Performance

Use passive: true listeners
Debounce high-frequency events if needed
Clean up listeners on component destroy

🧪 Testing Tips

Simulate user inactivity with fake timers
Verify that warning appears before logout
Ensure timers reset on user activity

Example test snippet:

it('should reset activity on user interaction', () => {
  service.startTracking();
  document.dispatchEvent(new MouseEvent('mousemove'));
  expect(service['lastActivityTime']).toBeGreaterThan(Date.now() - 1000);
});

💡 Real-World Benefits

Implementing inactivity logout helps you achieve:

🔒 Improved session security
✅ Compliance with standards like HIPAA / GDPR
💬 User trust through clear timeout warnings
🧹 Cleaner memory management via proper event cleanup

🏁 Conclusion

Building an auto-logout system may seem small, but it significantly boosts your application’s security posture.

This approach offers:

Comprehensive user activity detection
Configurable timeout and warning
Lightweight implementation with no dependencies
Full Angular compatibility

Secure, user-friendly, and easy to integrate - this solution protects both your users and your platform.

📚 Resources

💬 Discussion

What session timeout strategies do you use in your applications?

Let’s exchange ideas below 👇

Building a Production-Ready Logger Service in Angular 🚀

SANKET PATIL — Tue, 30 Sep 2025 08:24:12 +0000

When I started working on Angular app, I noticed one common thing: console.log everywhere. Debug messages scattered across components, warnings mixed with production logs, and the occasional sensitive info sneaking into the console.

With guidance from my peers, I learned about a much better approach-a centralized Logger Service. In this post, I’ll walk you through a production-ready Logger Service implementation for Angular that makes logging clean, powerful, and safe.

The Problem 🤔

We’ve all been there-debugging with console.log() sprinkled across the codebase.
The issues?

Cluttered production logs
Manual cleanup before deployment
Inconsistent formatting
No central control
Potential exposure of sensitive info

The Solution ✨

A Logger Service that provides:

✅ Environment-aware logging (disabled in production)
✅ Multiple log levels: DEBUG, INFO, WARN, ERROR
✅ Consistent formatting with timestamps
✅ Advanced features (grouping, timing, styled logs, tables)
✅ Type safety with full TypeScript support

Implementation 💻

Core Logger Service

export enum LogLevel {
  DEBUG = 0,
  INFO = 1,
  WARN = 2,
  ERROR = 3
}

@Injectable({ providedIn: 'root' })
export class LoggerService {
  private isEnabled: boolean = !environment.production;
  private logLevel: LogLevel = LogLevel.DEBUG;

  constructor() {
    if (environment.hasOwnProperty('enableLogging')) {
      this.isEnabled = (environment as any).enableLogging;
    }

    if (environment.hasOwnProperty('logLevel')) {
      this.logLevel = (environment as any).logLevel;
    }
  }

  debug(message: any, ...params: any[]): void {
    this.log(LogLevel.DEBUG, message, ...params);
  }

  info(message: any, ...params: any[]): void {
    this.log(LogLevel.INFO, message, ...params);
  }

  warn(message: any, ...params: any[]): void {
    this.log(LogLevel.WARN, message, ...params);
  }

  error(message: any, ...params: any[]): void {
    console.error(message, ...params);
  }

  private log(level: LogLevel, message: any, ...params: any[]): void {
    if (!this.isEnabled || level < this.logLevel) return;

    const timestamp = new Date().toISOString();
    const prefix = `[${timestamp}] [${LogLevel[level]}]`;

    switch (level) {
      case LogLevel.DEBUG: console.log(prefix, message, ...params); break;
      case LogLevel.INFO: console.info(prefix, message, ...params); break;
      case LogLevel.WARN: console.warn(prefix, message, ...params); break;
      case LogLevel.ERROR: console.error(prefix, message, ...params); break;
    }
  }
}

Key highlights:

Disabled automatically in production
Errors always logged regardless of environment
ISO timestamps for precise log tracking

Advanced Features 🎯

1. Grouping Related Logs

group(name: string, collapsed = false): void {
  if (this.isEnabled) {
    collapsed ? console.groupCollapsed(name) : console.group(name);
  }
}

groupEnd(): void {
  if (this.isEnabled) console.groupEnd();
}

2. Performance Timing

time(name: string): void {
  if (this.isEnabled && this.logLevel <= LogLevel.DEBUG) console.time(name);
}

timeEnd(name: string): void {
  if (this.isEnabled && this.logLevel <= LogLevel.DEBUG) console.timeEnd(name);
}

3. Table Display

table(data: any): void {
  if (this.isEnabled && this.logLevel <= LogLevel.DEBUG) console.table(data);
}

4. Styled Logs

styled(msg: string, styles = 'color: #2196F3; font-weight: bold;'): void {
  if (this.isEnabled && this.logLevel <= LogLevel.INFO) {
    console.log(`%c${msg}`, styles);
  }
}

Migration Guide 📝

Before:

console.log('Debug info');
console.warn('Warning message');
console.error('Error occurred');

After:

this.logger.debug('Debug info');
this.logger.warn('Warning message');
this.logger.error('Error occurred');

Dynamic Configuration ⚙️

Enable/disable logging at runtime:

constructor(private logger: LoggerService) {
  if (window.location.href.includes('debug=true')) {
    this.logger.setEnabled(true);
    this.logger.setLogLevel(LogLevel.DEBUG);
  }
}

Benefits 🎁

Cleaner production logs
Rich formatting and timestamps
Toggle logging with a single flag
Zero overhead when disabled
Type safety with TypeScript
Consistent across the app
No accidental leakage of sensitive info

Best Practices 📚

Use logger.error() for errors (always logged)
Use debug() for diagnostics, info() for general messages, warn() for potential issues
Group related logs for readability
Time performance-critical operations
Replace all console. with logger.

Conclusion 🎯

A Logger Service is one of those simple but powerful upgrades that every Angular app should have.
It makes logs consistent, keeps production clean, and gives developers richer debugging tools.

Since adding it to our project, debugging has become easier and our production logs are finally clean.
No more scattered console.logs 🚫

💬 What’s your logging strategy? Share your approach in the comments!

Angular Architecture That Clicks: Embracing Feature-Based Design

SANKET PATIL — Thu, 21 Aug 2025 05:03:05 +0000

Structuring an Angular app may seem straightforward at first-just put components in one folder, services in another, and models in their own. But as projects grow, that neat separation can quickly turn into a maze of files.

Reflecting on a recent project, I realized how much time I wasted bouncing between folders just to make a small change in one feature. That’s when I decided to shift from the type-based structure to a feature-based design-and it completely changed how I build and maintain Angular apps.

In this post, I’ll walk you through why this shift clicked for me, the challenges it solved, and how it makes apps more modular and scalable.

🛠️ Challenges with Type-Based Structure
At first, the default structure looked clean:

/components  
/services  
/models

But real-world development quickly exposed its flaws:

Scattered Logic: Updating a single feature meant editing files across multiple folders.
Onboarding Pain: New developers struggled to trace what belonged to which feature.
Scaling Issues: As features grew, so did the complexity of managing cross-folder dependencies.

🔄 The Shift to Feature-Based Design
Instead of grouping files by type, I started grouping them by feature:

/features  
   /dashboard  
      dashboard.component.ts  
      dashboard.service.ts  
      dashboard.module.ts  
   /user  
      user.component.ts  
      user.service.ts  
      user.model.ts

Everything related to “User” now lives in one place. Need to update user logic? It’s all inside /user. Want to add a new feature? Create a new folder and keep it self-contained.

🚀 Benefits I Experienced
The difference was immediate:

Modularity → Features became self-contained, easier to maintain, and simpler to test.
Scalability → Features could be lazy-loaded, reducing initial bundle size.
Collaboration → Teams could work on different features in parallel with minimal conflicts.
Clarity → The structure told a story. Even new developers instantly knew where to look.

📖 Lessons Learned
Making the switch taught me a few key lessons:

Align with Angular’s Strengths: Angular is inherently module-driven, so a feature-based structure plays to its strengths.
Think in Features, Not Files: Real-world applications evolve around features, not isolated file types.
Refactor Early: The earlier you move to feature-based design, the less painful the transition.

🏁 Conclusion
Shifting to feature-based design wasn’t just a structural change-it was a mindset shift. By organizing code around features instead of file types, I cut down development time, reduced confusion, and made the codebase far more modular.

If you’re still working with a type-based Angular structure, I encourage you to try the feature-based approach. Like me, you might find it just clicks.

Here’s to building modular, scalable, and developer-friendly Angular apps 🚀

From Basics to Battle-Tested: 10 Tech Foundations You Should Actually Master

SANKET PATIL — Tue, 27 May 2025 07:29:36 +0000

The tech industry moves fast, but solid foundations move with you.

Whether you're building cloud-native apps, running production-grade infrastructure, or automating deployments - there’s a huge difference between knowing the commands and understanding the systems.

Here’s a curated list of 10 core areas you should master, along with the why behind them.

1. 🐧 Linux + Networking

What to know:

Write robust Bash scripts with error handling and signal traps
Understand TCP/IP, subnets, MTU, and DNS resolution
Dive into iptables, not just cloud firewall rules
Use tools like tcpdump and wireshark to trace packets

💡 If your app is slow or unreachable, networking fundamentals usually have the answer.

2. 🐳 Docker

What to know:

Use multi-stage builds to keep images clean
Integrate Trivy for vulnerability scanning in CI
Prefer minimal base images like alpine or distroless

🔐 Smaller, more secure containers = faster and safer deploys.

3. 🧠 Git (Not Just the Commands)

What to know:

Use feature branch workflows with clean merges
Make atomic commits with meaningful messages
Understand Git's DAG structure (Directed Acyclic Graph)

🧬 Git history is your project's DNA. Learn to shape it cleanly.

4. ☁️ Cloud Platform (Pick One - Azure in this case)

What to know:

Design VNet architectures with private endpoints, service endpoints, and routing
Apply RBAC and Azure AD roles with least privilege
Enforce policy-based guardrails using Azure Policy and Blueprints
Optimize cost with resource tagging and Azure Cost Management

☁️ Cloud mastery = security, cost control, and scalability.

5. 🔧 Terraform

What to know:

Manage state responsibly (remote backend, locking, state drift detection)
Use modular design to scale Terraform across environments
Add validators with validation blocks and use tflint in CI

🧱 Infra as Code isn't just writing resources-it's about reusability and governance.

6. 🔁 CI/CD

What to know:

Design stateless, idempotent pipelines
Use multi-environment promotion (e.g., Dev → QA → Prod) with approvals
Manage secrets with Azure Key Vault or HashiCorp Vault

🚀 A broken pipeline breaks your ability to deliver. Build it right from the start.

7. 🐍 Python for Automation

What to know:

Write automation scripts with structured logging and exception handling
Use retry/backoff patterns when calling APIs
Build infrastructure tests with pytest, moto, or localstack

🤖 Python is your best friend for scripting and automation-write like it’s going to prod.

8. 🧭 Azure + GitOps

What to know:

Use Bicep or ARM templates to define infrastructure declaratively
Deploy infra using Azure DevOps Pipelines or GitHub Actions
Implement GitOps with Azure Arc or FluxCD on AKS
Use Policy as Code and custom Azure Policy Definitions for compliance

☁️ GitOps isn’t just for Kubernetes - it's a philosophy you can apply to ARM/Bicep and everything Azure-native.

9. 📊 Logging + Monitoring

What to know:

Centralize logs, metrics, and traces using Azure Monitor and Application Insights
Create SLO-based alerts, not just static thresholds
Enable distributed tracing for microservices via OpenTelemetry

👁️ Observability isn’t optional. It's how you see into your systems and respond fast.

10. 🔐 Security (Shift Left)

What to know:

Use Trivy, Checkov, and Defender for Cloud for early vulnerability scanning
Validate compliance using Azure Policy and Security Center
Build immutable infrastructure - no SSH, no patching in prod

🔐 Secure infrastructure is built, not bolted on later.

Final Thought 💬

This isn't about tools-it's about understanding how systems work and how to build for failure, scale, and security. Don’t just memorize flags. Learn the concepts.

📌 Pick one area. Go deep. Then level up the next.

🙏 If this was useful, drop a ❤️ or follow for future deep dives on DevOps, automation, and infrastructure engineering.

Mastering Data Integration with Azure Data Factory

SANKET PATIL — Mon, 24 Feb 2025 08:14:01 +0000

Data integration is at the heart of building scalable and efficient systems. Whether you're dealing with large datasets, ensuring referential integrity, or optimizing execution flows, having a structured approach is essential. In this blog, we'll walk through the key aspects of data integration using Azure Data Factory (ADF), covering pipeline execution, data flows, foreign key relationships, and optimization strategies.

Data Integration Pipelines

1. Data Ingestion and Transformation

Copy Data Activity

Source: A view containing structured data
Sink: Destination table for processed data
Write Behavior: Upsert for handling updates efficiently
Primary Key Handling: Ensuring uniqueness for seamless integration
Bulk Insert Optimization: Enabled for performance
Schema Mapping: Importing schema, removing unwanted columns, and aligning similar fields
Pre-Copy Script: Handling identity inserts dynamically

Stored Procedure for Cleanup

Stored Procedure Execution: Ensures obsolete records are flagged for deletion
Purpose: Soft deletes records not present in the source
Execution Context: Runs within a defined integration service

2. Managing Dependencies in Pipelines

For a successful data flow, foreign key relationships must be respected. Pipelines execute in a structured order:

Entity A (No dependencies)
Entity B (Reference to Entity A)
Entity C (Reference to Entity A & B)
Entity D (Multiple foreign key dependencies)

This execution order prevents constraint violations and maintains data integrity.

3. Series Execution Pipeline

A dedicated execution pipeline coordinates all pipelines sequentially:

Ensures execution in the correct order
Prevents independent triggers from causing conflicts
Uses failure handling to halt execution for debugging
Scheduled to run at predefined intervals for consistency

4. Handling Complex Scenarios

Some datasets require additional filtering to prevent duplication and ensure integrity. Consider an example where a hierarchical structure exists (e.g., parent-child relationships). The following SQL logic ensures parent records exist before inserting child records:

SELECT *
FROM SourceTable s
LEFT JOIN TargetTable t ON s.ID = t.ID
WHERE t.ID IS NULL 
AND (s.ParentID IS NULL OR EXISTS (SELECT 1 FROM TargetTable WHERE ID = s.ParentID));

This prevents foreign key constraint violations, ensuring smooth execution.

5. Monitoring & Troubleshooting

Failure Handling: The pipeline stops execution when errors occur, simplifying debugging.
Soft Deletes: Keeps track of obsolete records while preserving data integrity.
Centralized Monitoring: A single point of execution improves traceability and performance tracking.

Conclusion

Data integration isn't just about moving data—it's about maintaining consistency, ensuring referential integrity, and optimizing execution. A structured approach like the one outlined above enables seamless integration, reducing failures and improving maintainability. Whether you're building from scratch or refining an existing system, these best practices will help you navigate the complexities of data pipelines.

Have you encountered challenges while implementing data pipelines? Share your thoughts in the comments below!

DEV Community: SANKET PATIL

Troubleshooting .NET MAUI on macOS: From Build Errors to Device Debugging

Table of Contents

1. Start With the Error, Not the Installation

A useful rule

2. Xcode Is Installed - So Why Isn't It Working?

The lesson

3. When Xcode and MAUI Versions Need to Align

Capture the versions together

The lesson

4. When Android Setup Doesn't Complete Cleanly

The better approach

The lesson

5. The JDK Exists, But the Build Can't Find It

Step 1: Verify Java

Step 2: Find the actual JDK

Step 3: Explicitly configure the JDK

Why this matters

The lesson

6. From ADB to a Real Physical Device

The complete sequence

The lesson

7. Build Success Isn't the Finish Line

8. A Systematic Troubleshooting Approach

Step 1: Read the error carefully

Step 2: Identify the failing layer

Step 3: Verify the dependency independently

Step 4: Compare expected vs actual

Step 5: Change one thing at a time

Step 6: Re-test the real workflow

My Troubleshooting Checklist

.NET

iOS

Android

Application

What I Learned

Conclusion

Setting Up a Reliable .NET MAUI Development Environment on macOS

Table of Contents

What We Are Trying to Achieve

1. Start With the Repository

2. Install and Verify the .NET SDK

Why not simply use the latest SDK?

3. Install the .NET MAUI Workload

4. Configure Xcode for iOS Development

5. Pay Attention to Xcode and MAUI Compatibility

6. Verify the iOS Simulator

7. Configure Android

8. Verify the JDK

9. Configure the Android SDK

10. Emulator or Physical Device?

11. Connect a Physical Android Device

12. Restore the Actual Project

iOS

Android

13. Don't Ignore Warnings

14. Validate Debugging, Not Just Deployment

15. My Setup Checklist

Project

.NET

iOS

Android

Application

What I Learned

1. What does the project require?

2. What is actually installed?

3. Does the actual application work?

Conclusion

My Journey to Passing AZ-900: Microsoft Azure Fundamentals

Why I Decided to Pursue AZ-900

My Preparation Approach

Challenges During Preparation

Exam Experience

Final Result

Key Takeaway

Fixing Bugs Is Easy. Preventing Their Return Is Hard

The Illusion of a Successful Fix

Symptoms vs Root Causes

The Regression Question

Confidence Over Hope