DEV Community: Gouranga Das Samrat

The PACELC Theorem — in a few words

Gouranga Das Samrat — Sun, 17 May 2026 13:00:00 +0000

The PACELC theorem (often pronounced as pack-else) was proposed by Daniel Abadi in 2010 as an extension to the CAP theorem. While the CAP theorem focuses only on the behavior of a distributed system during a network partition, the PACELC theorem also pays lots of attention to a different state of a system - a state without any network partitions.

Similarly as we did with the CAP theorem, we won’t just quote it and call it a day, instead, we will try to devise it ourselves from the ground up.

But first, we should agree on the terminology! Two terms will be important for us today:

Latency — the PACELC theorem operates with the Latency as a (client-observed) duration of a write operation. The longer a client would have to wait until a write operation he has initiated completed — the higher the latency would be. This is not only the duration of the write operation on a single node, but the overall duration of the write operation as observed by the client. For clarity, the network round-trip time between the client and the system is not included in the latency.
Consistency — while the CAP theorem operates only with the strong consistency (linearizability), for the PACELC theorem the consistency is a spectrum: it might vary from the strong consistency to the eventual consistency. For today’s discussion, we will consider the consistency as the degree to which all nodes in the system have the same data after a write operation completes, ranging from 1 (only entry node has written the new data) to N (all nodes have written the new data).

Setting up the stage

We are going to use a simple key-value store as a model for our thought experiment. This distributed system would:

be able to execute only one operation — write;
consist of N nodes (obviously, at least two nodes — otherwise it won’t be a distributed system);
accept and execute write operation requests on each node;
store the whole data set on each node (i.e., replicate all writes to all nodes).

The overall design of this toy key-value store would look like this:

For illustration, here’s a simple API definition for such a system:

We won’t focus on data read operations today, but we will assume that the system is able to read data as well.

Maximizing consistency

At first, we will try to ensure the strong consistency for our system. This means that a write operation should be considered completed only when all nodes have acknowledged it. Therefore, the write operation could only complete when the data change has been replicated to all nodes.

This design would ensure that data consistency is maximized — once a write operation is completed, all nodes would have the same data. However, this comes at a cost of increased latency — the write operation would have to wait for the slowest node to acknowledge it. In a real-world scenario, this could be further exacerbated by network delays, node failures, or other issues that could slow down the replication process.

Still, this design would provide the strongest consistency guarantees possible.

Minimizing latency

Next, we will try to minimize the latency of our system. To achieve this, we could modify our write operation to complete as soon as the data is written to the first (entry) node, without waiting for the replication to other nodes to complete. The replication process would occur asynchronously in the background.

This design would significantly reduce the latency of write operations, as they would complete as soon as the entry node acknowledges them. However, this comes at the cost of reduced consistency — there is a window of time during which not all nodes have the same data. If a read operation is performed during this window, it may return stale data from nodes that have not yet received the latest write.

Even worse, a failure of the entry node before replication completes could lead to data loss, despite the write operation being acknowledged to the client!

The trade-off

As we can see, there is a clear trade-off between maximizing consistency and minimizing latency in our distributed system:

Maximizing consistency leads to higher latency, as write operations must wait for all nodes to acknowledge them.
Minimizing latency leads to reduced consistency, as write operations can complete before all nodes have the latest data.

Remembering the CAP theorem, we might think that this is a binary choice — either we have consistency or low latency. Let’s prove that this is not the case.

We will alter the design of our system to allow for a configurable trade-off between consistency and latency. We can introduce a parameter W (write quorum) that specifies the number of nodes that must acknowledge a write operation before it is considered complete. In this way, the value of W would affect both the consistency and latency of the system:

With W=N we would have the strongest consistency - as we have seen before in the "Maximizing consistency" chapter.
With W=0 we would have the lowest latency - as we have seen before in the "Minimizing latency" chapter.
With 0 < W < N we would have a balance between consistency and latency - the higher the value of W, the stronger the consistency and the higher the latency, and vice versa.

Let’s illustrate one example — with W=N/2 + 1 (majority quorum):

This design would provide a middle ground between consistency and latency. While the strong consistency is lost, the system would still provide a reasonable level of consistency:

The majority of nodes would have the latest data after a write operation completes.
The latency would be defined by the latency of the slowest node in the majority, which is typically lower than waiting for all nodes. That said, the latency would still be higher than waiting for just one node, but it would be affected in a lesser degree by the latency spikes on a single node.

A good example of such a system is MongoDB, which allows clients to configure the write concern for write operations, including options for majority quorum — via so called write concern option.

Finally, the PACELC theorem

While we can clearly see the connection between our thought experiment and the CAP theorem, there are some important differences to note:

The CAP theorem focuses on the trade-offs during network partitions. We put our focus on the other case — when there is no network partition.
The CAP theorem presents a binary choice between consistency and availability during partitions. We demonstrated a spectrum of trade-offs between consistency and latency in the absence of partitions.

All of this leads us to the PACELC theorem:

In the presence of a network partition, a distributed system must choose between strong consistency and availability.

Else, when there is no network partition, a distributed system must choose between latency and the degree of consistency.

It’s easy to remember and decode the name of the theorem:

PAC means: "if Partition happens, choose between Availability and Consistency" - the CAP theorem.
ELC means: "Else, choose between Latency and Consistency".

Now, it’s a great theorem — its whole meaning is encoded in its name!

I would like to note one point, important for completeness.

In the CAP theorem, we speak about strong consistency (linearizability) only. However, in the PACELC theorem, the consistency is a spectrum — from strong consistency to eventual consistency. And eventual consistency is non-binary — there are different degrees of eventual consistency:

Ensuring that N-1 nodes might serve the stale data for some time is a weaker form of eventual consistency.
Ensuring that only the minority of nodes might serve the stale data for some time is a stronger form of eventual consistency.
Ensuring that not a single node might serve the stale data for some time is a strong consistency, not an eventual one.

It’s a caveat worth mentioning!

VS Code on Your Phone — Yes, It Actually Works 🔥

Gouranga Das Samrat — Mon, 11 May 2026 04:00:00 +0000

Extensions, IntelliSense, debuggers — the full experience, running natively on Android.

You've got VS Code running in Termux. You open it, install a Rust or Lua extension, and... the language server does nothing. No autocomplete. No error highlighting. Just silence.

This happens to almost everyone. And the fix is simpler than you think.

New here? This guide assumes you already have Code-OSS (code-oss) installed in Termux. If you haven't set that up yet, check out the previous post first — Turn Your Android Into a Full Desktop — No Root Needed — which covers installing a full XFCE4 desktop with Code-OSS on Termux, no root, no hacks, no proot required. Come back here once you're set up. 👋

This guide — based on the GourangaDasSamrat/dotfiles repo — walks you through two things:

Making Code-OSS look and behave like the real Visual Studio Code (including access to the official VS Marketplace)
Fixing language servers for Rust, Lua, and the CodeLLDB debugger so they actually work on Termux

🤔 Why Doesn't It Just Work Out of the Box?

Termux ships code-oss — the open-source build of VS Code. The problem is that VS Code extensions bundle their own pre-compiled binaries (language servers, debuggers), and those binaries are compiled for x86 Linux. They don't run on ARM Android.

The fix? Install the correct ARM binaries via Termux's package manager, then symlink them into the extension folders. Simple once you know it — confusing until you do.

Part 1 — Make Code-OSS Feel Like the Real VS Code

Unlock the Official VS Marketplace

By default, Code-OSS points to the Open VSX registry, not Microsoft's official Marketplace. A small config change fixes this and also renames the app to "Visual Studio Code" so everything feels native.

Edit the product config file:

nano /data/data/com.termux/files/usr/lib/code-oss/resources/app/product.json

Add or update these properties:

{
  "nameShort": "Visual Studio Code",
  "nameLong": "Visual Studio Code",
  "applicationName": "code",
  "dataFolderName": ".vscode",
  "linuxIconName": "code",
  "urlProtocol": "vscode",
  "extensionsGallery": {
    "serviceUrl": "https://marketplace.visualstudio.com/_apis/public/gallery",
    "cacheUrl": "https://vscode.vo.msecnd.net/gallery",
    "itemUrl": "https://marketplace.visualstudio.com/items"
  },
  "linkProtectionTrustedDomains": [
    "https://open-vsx.org",
    "https://marketplace.visualstudio.com",
    "https://vscode.vo.msecnd.net"
  ]
}

Save and restart Code-OSS. You now have the official Marketplace, the official name, and the code command in your terminal. It's VS Code. On your phone.

Part 2 — Fix Language Servers That Don't Work

The pattern for every broken language server is the same three steps:

Install the correct binary via apt
Remove the broken bundled binary that came with the extension
Symlink the working system binary in its place

Let's go through each one.

🦀 Rust — rust-analyzer

Step 1 — Install the system binary:

apt install rust-analyzer

Step 2 — Remove the broken bundled binary:

rm ~/.vscode/extensions/rust-lang.rust-analyzer-*/server/rust-analyzer

Step 3 — Symlink the working one:

ln -s $(which rust-analyzer) ~/.vscode/extensions/rust-lang.rust-analyzer-*/server/rust-analyzer

If the * wildcard doesn't work, run ls ~/.vscode/extensions/ to find the exact folder name and replace * with the version number.

Reload VS Code and open a .rs file — autocomplete, type hints, and error checking should all be live. 🦀

🌙 Lua — lua-language-server

Step 1 — Install the system binary:

apt install lua-language-server

Step 2 — Remove the broken bundled binary:

rm ~/.vscode/extensions/sumneko.lua-*/server/bin/lua-language-server

Step 3 — Symlink the working one:

ln -s $(which lua-language-server) ~/.vscode/extensions/sumneko.lua-*/server/bin/lua-language-server

Open a .lua file and watch IntelliSense spring to life. 🌙

🐛 CodeLLDB — Native Debugger for Rust & C++

This one has more moving parts because CodeLLDB bundles several binaries. Same approach, just more symlinks.

Step 1 — Install the system binaries:

apt install codelldb

Step 2 — Remove all the broken bundled binaries at once:

rm -rf \
  ~/.vscode/extensions/vadimcn.vscode-lldb-*/adapter/codelldb \
  ~/.vscode/extensions/vadimcn.vscode-lldb-*/lldb/bin/lldb \
  ~/.vscode/extensions/vadimcn.vscode-lldb-*/lldb/bin/lldb-server \
  ~/.vscode/extensions/vadimcn.vscode-lldb-*/lldb/bin/lldb-argdumper

Step 3 — Symlink all four system binaries:

ln -s $(which codelldb)       ~/.vscode/extensions/vadimcn.vscode-lldb-*/adapter/codelldb
ln -s $(which lldb)           ~/.vscode/extensions/vadimcn.vscode-lldb-*/lldb/bin/lldb
ln -s $(which lldb-server)    ~/.vscode/extensions/vadimcn.vscode-lldb-*/lldb/bin/lldb-server
ln -s $(which lldb-argdumper) ~/.vscode/extensions/vadimcn.vscode-lldb-*/lldb/bin/lldb-argdumper

Set a breakpoint, hit F5, and you've got a working debugger. On Android. 🤯

🔍 Troubleshooting — When Things Still Don't Work

If a language server or debugger is still misbehaving after following the steps above, run through this checklist:

Check that the symlinks actually exist:

ls -l ~/.vscode/extensions/[extension-folder]/server/
ls -l ~/.vscode/extensions/[extension-folder]/adapter/

Verify the symlink targets are executable:

file $(which codelldb)
file $(which lldb)

Reload the language server without restarting VS Code:

Press Ctrl+Shift+P → type Restart Language Server → hit Enter.

Check for error details:

Open the Output panel (Ctrl+Shift+U) and select the language server from the dropdown. The error messages there are usually very specific and point right to the problem.

💡 Quick Recap

Language / Tool	Package to Install	What You Symlink
Rust	`rust-analyzer`	`server/rust-analyzer`
Lua	`lua-language-server`	`server/bin/lua-language-server`
CodeLLDB	`codelldb`	`adapter/codelldb` + 3 lldb binaries

The pattern never changes: apt install → rm broken binary → ln -s system binary. Once you understand this, you can apply it to any other language server that breaks in the future.

📁 All Configs Live in the Dotfiles Repo

The full setup, including a curated list of recommended VS Code extensions for Termux, lives here:

👉 github.com/GourangaDasSamrat/dotfiles

Check docs/vscode/ for both this setup guide and the full extensions list.

🏁 You Now Have a Real Dev Environment on Android

A working VS Code with IntelliSense, language servers, and a native debugger — all running on your phone without any root, emulation, or cloud tricks.

Whether you're coding Rust on your commute or debugging Lua on your lunch break, your Android is now a legitimate development machine.

Go ship something. 🚀

If this helped, star the dotfiles repo on GitHub! ⭐

📖 Read the previous post in this series:
Turn Your Android Into a Full Desktop — No Root Needed — Install XFCE4 + Code-OSS on Termux from scratch, no root, no proot, no hacks.

Test coverage and what it can tell us

Gouranga Das Samrat — Sun, 10 May 2026 13:00:00 +0000

When we write production-grade code, we want confidence that it behaves as expected. One of the main ways to achieve that is through unit tests — small automated checks verifying that specific parts of the code work correctly.

Naturally, this raises a few questions: How many tests do we need? And how effective are they? A common answer is test coverage — a metric showing how much of the codebase is executed during testing.

Many teams use test coverage as a quality gate: if the number drops below a threshold, new code can’t be merged. But these thresholds are often arbitrary — high enough to feel safe, yet low enough to be achievable. 75%, 80%, 85% — familiar numbers that might look meaningful but rarely are.

Before relying on coverage as a quality signal, we should ask:

What does test coverage actually tell us?
How useful is it as a metric?
Does a certain percentage guarantee well-tested code?

This post explores those questions and shows why high coverage can still be misleading.

Deceiving coverage

For a start, let’s write a simple function that calculates a discount multiplier based on user age and activity status:

For users under 18 years old, we give a 10% discount (multiplier 0.9).
For inactive users, we apply a 20% discount (multiplier 0.8).
For users who are both under 18 and inactive, we apply both discounts (multiplier 0.72).
For all other users, no discount is applied (multiplier 1.0).

Here is the code for these requirements (I’ve chosen Go, but the language itself is not important here):

package main
func CalcDiscount(userAge int, isUserActive bool) float64 {
    discountMul := 1.0
    if userAge < 18 {
        discountMul *= 0.9 // 10% discount for minors
    }
    if !isUserActive {
        discountMul *= 0.8 // 20% discount for inactive users
    }
    return discountMul
}

It’s worth noting: this function is really simple, but that’s intentional. I want to have something very simple to make my points clear. Later, I will analyze the code to devise better test cases.

Now, let’s write some tests for this function. And since we are going to talk about test coverage, let’s measure it as well — and use the test coverage as a metric:

package main
import (
    "fmt"
    "math"
    "testing"
)
func TestCalcDiscount(t *testing.T) {
    type TestCase struct {
        UserAge      int
        IsUserActive bool
        Expected     float64
    }
    testCases := []TestCase{
        // Test Case 1 - user age < 18 and user is inactive
        {UserAge: 17, IsUserActive: false, Expected: 0.72},
        // Test Case 2 - user age ≥ 18 and user is active
        {UserAge: 30, IsUserActive: true, Expected: 1.0},
        // Test Case 3 - user age < 18 and user is active
        {UserAge: 17, IsUserActive: true, Expected: 0.9},
        // Test Case 4 - user age ≥ 18 and user is inactive
        {UserAge: 25, IsUserActive: false, Expected: 0.8},
    }
    for _, testCase := range testCases {
        testCase := testCase
        testCaseName := fmt.Sprintf(
            "%d-%t",
            testCase.UserAge,
            testCase.IsUserActive,
        )
        t.Run(testCaseName, func(t *testing.T) {
            actual := CalcDiscount(testCase.UserAge, testCase.IsUserActive)
            delta := math.Abs(actual - testCase.Expected)
            const epsilon = 0.00001
            if delta > epsilon {
                t.Errorf("Expected %v, got %v", testCase.Expected, actual)
            }
        })
    }
}

I’m going to run these tests with different sets of test cases and measure coverage:-examples/code-1 0.211s

$ go test -covermode=count -coverprofile=/dev/null
PASS
coverage: 100.0% of statements
ok      github.com/kapitanov/personal-blog/posts/code-examples/code-1   0.211s

My end goal for now is to reach 100% coverage, and I’m not going to look into the function code itself while writing the tests. Yes, it’s really simple, but let’s pretend it’s more complex — too complex to properly analyze manually. Thus, we’d have to rely on code coverage.

I’m going to add test cases one by one and measure coverage after each addition:

Without any tests, we have zero coverage, which makes sense.
With only one test (Test Case 1), we already have 100% test coverage! This might look correct at first glance — as we cover bothtrue and false branches of each if statement. But requirements-wise, we still don't have test cases for the remaining scenarios.
Adding more test cases does not change coverage — it remains at 100%.

Therefore, if I relied on test coverage as a metric and had a 100% coverage threshold (and the code were too complex to analyze manually), I would end up with a false sense of security — thinking that my function is properly tested while it’s not even remotely so.

Digging deeper

To unveil the mystery, let’s put the statements onto a call graph and analyze which branches are covered by which test cases:

As an example, I’ve highlighted Test Case 1 in the graph — and we can clearly see that it only covers 25% of the entire call graph! Now it’s clear: to properly test the function, we need to cover all branches of the call graph, so we need exactly four test cases to cover all branches.

As you might have guessed, there are different types of code coverage:

Statement coverage — measures whether each statement in the code was executed. This is what we measured in the previous examples. Even a single test case was enough to achieve 100% statement coverage.
Branch coverage — measures whether each branch ( true/ false) of control structures (if, switch, for) was executed. For our example, Test Case 1 would cover two branches - the true branch of the first if and the false branch of the second if - out of a total of four branches, giving us 50% branch coverage. Out of curiosity — we could get 100% branch coverage with just two test cases: Test Case 1 — user age < 18 and user is inactive, and Test Case 2 — user age ≥ 18 and user is active.
Path coverage — measures whether all possible paths through the code were executed. In our example, we have four possible paths through the function, which means that Test Case 1 only covers one out of four paths, resulting in 25% path coverage. We would need all four test cases to achieve 100% path coverage.

Most testing tools provide statement coverage; some might provide branch coverage — but as we have seen, neither of these types of coverage guarantees a proper level of verification.

Only path coverage may guarantee that all possible scenarios were tested. But is it feasible to achieve path coverage in real life? Let’s take a look at another code example:

package main
import "slices"
// MinOf returns the minimum value from a slice of integers.
// It doesn't allow empty slices as input.
func MinOf(xs []int) int {
    if len(xs) == 0 {
        panic("empty slice")
    }
    slices.Sort(xs)
    return xs[0]
}

This function has two branches — one for empty slices and one for non-empty slices. So, would it be enough to have two test cases — one with an empty slice and one with a non-empty slice?

The answer is no — because the slices.Sort function itself has branches and paths that we don't control. Moreover, it's a library function - we don't know its implementation details, and they might change even between minor releases of the toolchain.

And finally, let’s take a look at a slightly trickier example:

package main
func ComplexCondition(a, b, c bool) bool {
    if a || (b && c) {
        return true
    }
    return false
}

It seems that there are only two possible execution paths here — one where the condition is true and one where it’s false. But in reality, there are four possible combinations of input values (a, b, c)! Let’s rewrite the condition to make it more explicit:

package main
func ComplexConditionExplicit(a, b, c bool) bool {
    if a {
        return true
    }
    if b {
        if c {
            return true
        }
        return false
    }
    return false
}

Now we see — we need four test cases to cover all possible paths through the function. This unfortunately means that even with 100% path coverage, we might need to write more tests than we initially thought.

Conclusion and a few thoughts

Generally, test coverage is a useful metric to have — it can help us identify untested parts of the code.

But we should be aware of its limitations: even 100% statement or branch coverage does not guarantee that our code is properly tested. In fact, it does not even come close to guaranteeing that.

At the same time, achieving 100% path coverage is often infeasible. Even if we manage to achieve it — our tests won’t survive any code changes.

Thus, I recommend following a simple rule:

Until you have 100% coverage of the testable parts of your codebase, you do have untested code. Once you have 100% coverage of the testable parts of your codebase, you still might have untested code.

Here are a few steps to help you follow this rule:

**Not every bit of code needs to be tested. **Identify critical parts of your codebase that require proper testing. It’s likely you won’t even need tests for infrastructure code, glue code, and similar. Do you really need to unit-test your logger setup or HTTP server initialization? Probably not — these parts of your codebase should be tested implicitly during integration testing stages. Do you need to unit-test your business logic? Most likely, yes — these parts are critical and should be properly tested. Write test scripts that calculate test coverage for these critical parts only. Even if some other units are indirectly covered by these tests — their coverage should not affect the resulting number.
**Aim for 100% (full) coverage of the testable parts of your code. **Having less than 100% (as we observed above) guarantees you don’t have well-tested code! 100% test coverage, on the other hand, means nothing — you still have to carefully design your tests and test cases. Thus, you should aim for 100% coverage, but not rely on it.
**Be pragmatic. **You won’t be able to achieve 100% all the time — often you’ll have lines of code that are not testable. In Go, it would be really painful (and usually unnecessary) to properly test all the error-handling if err { return err } lines. Leave these lines untested - otherwise, you might end up wasting time writing fragile tests for code that has no business value. Still, aim for 100% — if you have 95% coverage, it means that you have untested code. If you do — make sure you know which code is untested and why. Review code coverage regularly — for each pull request, for example. You should pay extra attention to source code lines that belong to the critical parts of the codebase and are not covered by tests.
**Don’t rely on code coverage thresholds. **Don’t set arbitrary thresholds like 75%, 80%, or 85% — they are meaningless. Don’t set a 100% threshold either — it’s often infeasible to achieve. Don’t set different thresholds for different parts of the codebase — that’s meaningless as well. Don’t set a “coverage should never decrease” rule — it doesn’t make sense.
**Unit tests are never enough. **Imagine that you have managed to achieve 100% path coverage of your entire codebase (somehow). Would it guarantee that your code works as expected? The answer is no — even totally correct code might fail in production due to misconfiguration, network issues, hardware failures, etc. Thus, you should also have integration tests, end-to-end tests, and other types of tests. Unit tests (and their coverage) are merely a tool — one of the tools you should keep on your belt.

These recommendations are obviously opinionated; however, I personally follow them in my projects and find them useful.

Hope you find them useful as well!

Turn Your Android Into a Full Desktop — No Root Needed 🚀

Gouranga Das Samrat — Sat, 09 May 2026 05:06:30 +0000

Your pocket is hiding a surprisingly powerful computer. Let's unlock it.

Most people use Termux to run a few scripts or compile some code. But what if you could run a full XFCE4 desktop environment — with a taskbar, app launcher, file manager, browser, and VS Code — right on your Android phone? No root. No hacks. Just pure Linux power in your palm.

This is exactly what the GourangaDasSamrat/dotfiles repo makes effortlessly possible. Let's set it up step by step.

🧠 What You'll End Up With

A real, working Linux desktop on Android featuring:

XFCE4 — a fast, lightweight desktop environment
Firefox — full desktop browser
VS Code (code-oss) — your favourite editor, on your phone
Rofi app launcher — blazing-fast app search with Ctrl+Space
PulseAudio — actual working audio
A Debian container (via proot) for running any Linux software

🛠️ What You Need Before Starting

An Android phone (Android 7+)
Termux — install from F-Droid (NOT the Play Store version)
Termux:X11 — the display server app
A stable internet connection for the initial setup
~3–4 GB of free storage

Pro tip: Install both Termux and Termux:X11 from F-Droid or GitHub releases. The Play Store versions are outdated and will cause problems.

📦 Step 1 — Grant Storage & Update Termux

Open Termux and run:

termux-setup-storage

Tap Allow when Android asks for storage permission. Then update your packages:

pkg update && pkg upgrade -y

Grab a coffee — this takes a few minutes the first time. ☕

🔧 Step 2 — Install the Desktop Stack

Now install everything you need in one go. This installs git first, then X11 support, XFCE4, PulseAudio, and a bunch of useful apps:

# Add required repos and core packages (git is installed here first!)
pkg install git curl wget x11-repo tur-repo termux-x11-nightly pulseaudio -y

# Apps: browser, editor, image viewer, calculator
apt install firefox code-oss mousepad eog galculator pinentry-gnome3 -y

# XFCE4 and all the good plugins
apt install xfce4 xfce4-whiskermenu-plugin xfce4-clipman-plugin \
  xfce4-screenshooter xfce4-docklike-plugin xfce4-panel-profiles \
  xfce4-taskmanager -y

This installs quite a lot, so be patient and keep Termux open. If anything fails, re-run the same command — it picks up where it left off.

📥 Step 3 — Clone the Dotfiles Repo

Now that git is installed, grab the dotfiles:

git clone https://github.com/GourangaDasSamrat/dotfiles ~/dotfiles

This repo contains everything pre-configured — startup scripts, XFCE4 settings, tmux config, and desktop launch logic. You don't have to figure out any of it from scratch.

🚀 Step 4 — Set Up the Startup Script

The dotfiles repo includes a ready-made startup script that handles everything: killing old X11 processes, starting PulseAudio, launching Termux:X11, and booting XFCE4.

cp ~/dotfiles/docs/termux/native-desktop-start.sh ~/start.sh
chmod +x ~/start.sh

🖥️ Step 5 — Launch Your Desktop!

This is the moment. Run:

./start.sh

The script will:

Start PulseAudio for audio support
Fire up the Termux:X11 display server
Open the Termux:X11 app automatically
Launch a full XFCE4 desktop session

Switch to the Termux:X11 app — and there's your desktop. 🎉

⌨️ Keyboard Shortcuts Worth Memorising

Once you're in the desktop, these shortcuts will make your life much easier:

Action	Shortcut
Open App Launcher (Rofi)	`Ctrl + Space`
Open Whisker Menu	`Super`
Open Clipboard History	`Super + Alt + V`

🐧 Bonus: Add a Full Debian Container (Optional but Awesome)

Want to apt install literally anything from the Debian repos? Add a proot Debian container:

pkg install proot-distro -y
proot-distro install debian

Then log in with:

proot-distro login debian

Inside, you can install packages, set up users, configure your timezone, and run server software — all from within your Android:

# Inside Debian container
apt update && apt upgrade -y
apt install sudo git curl wget -y

# Set timezone (example: Asia/Dhaka)
ln -sf /usr/share/zoneinfo/Asia/Dhaka /etc/localtime

You can even symlink your Debian home folder to Termux's filesystem for easy file sharing:

ln -s /data/data/com.termux/files/usr/var/lib/proot-distro/installed-rootfs/debian/home/YOUR_USER ~/Developer

🎨 Personalise Your Setup

Change the Termux Welcome Message

nano $PREFIX/etc/motd

Write anything you want — a quote, ASCII art, a dashboard. It shows every time you open Termux.

Configure GPG for Git Signing

nano ~/.gnupg/gpg-agent.conf

Add:

pinentry-program /data/data/com.termux/files/usr/bin/pinentry-gnome3

🔁 Every Time You Want to Start the Desktop

Just open Termux and run:

./start.sh

That's it. Your full desktop spins up in seconds.

🤔 Why XFCE4?

XFCE4 is the perfect choice for mobile hardware. It's:

Lightweight — won't make your phone lag or overheat
Stable — rock solid, no random crashes
Highly customisable — themes, panels, plugins, everything
Familiar — feels like a real desktop OS immediately

Compared to heavier alternatives like GNOME or KDE, XFCE4 runs smoothly even on mid-range phones.

💡 Pro Tips

Keep Termux awake: Go to Android settings → Battery → Termux → set to "Unrestricted" to prevent the OS from killing your session.
Use a Bluetooth keyboard & mouse for the full desktop experience — it genuinely feels like a real computer.
External display? Some phones support video output via USB-C. Connect to a monitor and you've got a proper Linux workstation.
Tmux inside the terminal: The dotfiles also include a full tmux config (~/.tmux.conf) with mouse support, sensible shortcuts, and a clean status bar — great for running multiple terminal sessions inside the desktop.

📁 Everything Is in the Dotfiles Repo

All the configs, scripts, and docs used in this guide live in one clean, well-organised repository:

👉 github.com/GourangaDasSamrat/dotfiles

It includes:

The native desktop startup script
Tmux configuration
VS Code extension list for Termux
PRoot Debian setup guide
GPG & Git configuration templates

Star it, fork it, and make it your own. 🌟

🏁 Final Thoughts

A full Linux desktop on Android sounds like a geek fantasy — but with Termux, Termux:X11, and a solid dotfiles setup, it's completely real and surprisingly usable. Whether you're coding on the go, running a local server, or just geeking out, this setup delivers.

Your phone is now also a computer. Go build something cool. 💻📱

Found this useful? Give the dotfiles repo a ⭐ on GitHub!

How to Use Micro Frontends Without Regretting It

Gouranga Das Samrat — Sun, 03 May 2026 13:00:00 +0000

From Monolith Mess to MFE Freedom

Your Angular app has ballooned into a beast — builds drag on forever, deployments become team-wide nightmares, and everyone’s stuck waiting on each other. It’s like cooking a feast for 20 in a cramped kitchen: one slow chopper holds up the line. We’ve all been there.

Micro Frontends Flip the Script

Micro frontends flip that script, especially in Angular. They carve your giant app into smaller, independent chunks that teams can build, test, and deploy solo — like Netflix doling out UI pieces without the mess. Angular’s Native Federation makes it seamless: ditch webpack woes for ES modules that share dependencies and lazy-load on demand.

The Real Hook (and Headache)

Here’s the real hook (and challenge): it’s less about code splits and more about dodging UI glitches or bundle bloat while gaining true autonomy. Whether you’re a dev testing the waters or a lead scoping enterprise scale, this article breaks down setups, best practices, and pitfalls — equipping you to scale like the pros, drama-free.

When Micro Frontends Actually Make Sense (And When They Don’t)

A massive ship with dozens of crew members tweaking their own decks without halting the whole vessel — that’s your frontend at scale. Chaotic? Absolutely. Monoliths suit small teams fine, but as complexity grows, micro frontends emerge as modular lifeboats, enabling independent team progress.

Here’s the rub: most apps don’t need this firepower yet. I’ve seen teams jump into micro frontends too early, turning a simple project into a Frankenstein’s monster of mismatched UIs and bloated bundles. The real question? Does your business need this level of decoupling, or are you just chasing a buzzword?

Spot the Chaos: Team Size Signals

Start with the basics: team size and deployment drama. If you’ve got more than 30 developers split across features — like one squad on search, another on payments — micro frontends shine. They enable independent deploys, so the cart team ships weekly without rebuilding the entire app. No more “waiting on Bob’s login fix” nightmares.

Nx Lifesaver: Skip MFEs Early

But for smaller crews? Skip it. Angular’s monorepo magic with Nx handles growth beautifully first. Picture Nx as your smart toolbox: it enforces shared styles, lazy-loads modules, and deploys apps separately — all without the full MFE split. Many startups scale to 15 devs seamlessly with Nx. Escalate only for absolute autonomy, like blending React with Angular or isolated pipelines.

Velocity Gold vs. Hidden Traps

Sure, velocity skyrockets — teams own their turf, shipping faster. But risks lurk: UI drift (think buttons that look alien across pages), bundle bloat from duplicate libs, and that nagging coordination tax. It’s like inviting roommates who each decorate their room wild-west style; the house feels cohesive only with strict house rules.

Enforce shared design systems and tools like Module Federation to share dependencies dynamically. Gains often crush cons in big orgs, but measure twice: velocity up, consistency down?

E-Commerce Escape: Real Deploy Magic

Take Ksolves’ fashion platform revamp: a U.S. e-commerce monolith choking on slow releases. They carved it into MFEs — catalog, cart, checkout — using Angular and Module Federation. Lazy loads, shared NgRx state, boom: 50% faster features, 35% quicker pages. Separate teams deployed freely, like clockwork. No more monolith roadblocks.

Bottom line? Micro frontends aren’t a silver bullet — they’re for when monoliths crack under team scale. Assess needs honestly, lean on Angular’s strengths, and weigh those trades. Your app (and sanity) will thank you. Next time you’re eyeing that refactor, ask: autonomy or overkill?

Micro-Frontends Made Easy: Angular’s Native Federation Revolution

Think of a massive enterprise app as a bustling shopping mall — each store runs independently, yet customers flow seamlessly between them. That’s micro-frontends (MFEs) in action. With Angular 17+, Native Federation makes this setup straightforward, ditching old headaches for speed and simplicity built right into Angular’s core.

Why Ditch the Old Ways?

Let’s back up. Traditional monoliths? They’re that one giant codebase where every team steps on toes, deployments halt everything, and scaling feels like herding cats. Enter MFEs: break your app into bite-sized, team-owned chunks (a “shell” app plus “remote” modules like a products catalog). The catch? Older tools like webpack Module Federation added bloat and complexity. Native Federation, powered by esbuild, flips the script — native SSR support, CLI magic, and zero extra plugins. It’s Angular’s way of saying, “We’ve got this.”

Setup That Feels Like Magic

Here’s where it gets fun. Setup is a breeze with @angular-architects/native-federation. Devs everywhere spin up demos quickly: ng add @angular-architects/native-federation --project shell --type host for the host, then the same for remotes like "products." Instantly, federation.config.js maps modules like a smart GPS. Nx workspaces take it further: npx create-nx-workspace mfes, generate shell and remotes, serve—and proxies kill CORS woes effortlessly.

The Singleton Superpower Unleashed

The real hero? Dependency sharing. Duplicates are the silent killer — multiple Angular cores bloating your bundle like double-dipping on fries. Native Federation shares them as singletons by default: shareAll({ singleton: true }) in your config. Explicitly lock RxJS or Router too: { singleton: true, strictVersion: true }. It's like everyone at the party sharing one killer playlist instead of blasting their own. Multi-version libs? Tread carefully—eager load if clashes arise, or risk runtime drama.

Lazy-Load Like a Pro

Hands-on time. Lazy-load that products MFE in your shell routes:

{
  path: 'products',
  loadChildren: () => import('products/Module').then(m => m.ProductsModule)
}

Or dynamically: loadRemoteModule({ remoteEntry: 'http://localhost:4201/remoteEntry.js', exposedModule: './Module' }). Hit serve, navigate to /products—watch it load on-demand, sharing singletons flawlessly. No full rebuilds. Pure joy.

Your App, Future-Proofed

Why does this matter? In a world of distributed teams, Native Federation scales your app and your sanity. Deployment independence means UI teams ship UI without backend waits. SSR keeps SEO happy. And as Angular evolves, you’re future-proofed — no webpack lock-in.

Think of it like modular Lego: build grand castles, swap bricks anytime. Whether you’re a manager eyeing team velocity or a dev craving clean code, Native Federation delivers. Dive in — your mall just got a glow-up.

Avoiding Pitfalls and Regrets in Angular Micro Frontends

You’re finally cruising down the highway in your shiny new Micro Frontends (MFE) setup with Angular’s Module Federation. Everything’s smooth — until suddenly, your app feels like it’s dragging a trailer full of bricks. Performance tanks, buttons look different across pages, and state glitches make users scratch their heads. Sound familiar? I’ve been there, refactoring a bloated monolith into MFEs only to realize I’d traded one headache for three. The good news? These pitfalls are avoidable with a few smart moves. Let’s unpack them like we’re grabbing coffee and swapping war stories.

Dodge the Performance Brick Wall

First off, performance hits can sneak up fast. Without lazy loading, you’re dumping every MFE into the initial bundle — like inviting the whole party to brunch when you just need coffee. Instead, load remotes dynamically: only pull in what users need, when they need it. Pair that with strict dependency sharing. Module Federation’s share() config lets you expose Angular core, RxJS, or even your UI library once, slashing duplicates. Skip the fluff with shareAll({ singleton: true, strictVersion: true, requiredVersion: 'auto' }). And don't sleep on CORS woes—those cross-origin asset blocks? Whip up a reverse proxy in proxy.conf.json to route everything through your dev server. Pro tip: Monitor bundle sizes religiously with tools like BundleMon hooked into your CI pipeline. One spike, and you'll get an alert before launch day drama.

Banish UI Frankenstein Nightmares

UI consistency is another gremlin. Picture your app as a mismatched wardrobe: one MFE rocks neon buttons, another sticks to grayscale. Fix it with a federated design system — Angular Material works beautifully when shared as a remote entry. Everyone pulls from the same stylish pot, no NPM version wars. Draw domain-driven boundaries too, using Nx workspace tags or Angular’s providedIn: 'root' to keep features isolated yet harmonious. It's like giving each team their own kitchen but one shared spice rack.

Tame the State and Routing Beasts

State and routing? Tricky beasts. Cross-MFE sync screams for NgRx: slice your store by domain, use facades for clean APIs, and dispatch custom events for navigation handoffs. Say a remote MFE needs to trigger a shell route — boom, childRouteChanged event handles it without tight coupling. For versioning, dynamic manifests (mf.manifest.json) let you hot-swap remotes at runtime, dodging build-time lock-ins.

Slash 50% Off Feature Delivery Time

Take this real-world win: A team migrated their monolith to MFEs and slashed feature delivery time by 50%. Independent deploys? Check. Lazy loads trimmed initial times by 35%. But early CORS snarls and state leaks nearly derailed it — until proxies and shared libs saved the day.

The takeaway? MFEs aren’t set-it-and-forget-it. Treat them like a high-performance engine: tune for speed, align the parts, and test relentlessly. Skip these steps, and regrets pile up. Nail them, and you’re not just building apps — you’re future-proofing your frontend revolution. Your users (and stakeholders) will thank you.

Best Practices for Micro-Frontend Success

Micro-frontends (MFEs) let you scale Angular apps like snapping together specialized Lego pieces instead of wrestling one giant brick. They’re powerful, but success demands smart moves. Jumping in without a plan risks chaos — frustrating, error-prone, and ready to topple. Let’s break down the practices that make it smooth.

Start Small, Win Big

The golden rule? Start small with pilots. Don’t overhaul your entire monorepo overnight. Pick 2–3 MFEs — say, a user dashboard, product catalog, and checkout flow — and test them in a controlled monorepo setup using tools like Nx. This keeps code sharing easy (think shared UI libraries) while letting each team own their domain. Automate CI/CD pipelines per remote MFE with Module Federation magic: independent builds and deploys mean one team’s hiccup doesn’t halt the show. It’s like fixing a car while it’s still running, but with seatbelts — safe and iterative.

Ditch Props, Master Events

Communication is where most MFE dreams crumble, so lean on event buses and contracts, not direct props. Direct props create tight coupling and version hell. Instead, define lightweight contracts: stable events with a unique ID and minimal data, published via a shared message bus. MFEs listen anonymously, staying blissfully unaware of each other’s guts. Version independently, evolve contracts slowly with schema validation, and watch breaking changes vanish. No more “my update broke your UI” drama.

Test Smart, Deploy Fearless

Testing and deployment demand discipline too. Run independent pipelines for units and integrations, but E2E across the shell. Each MFE gets its own fast tests, while a parent pipeline catches shell-level glitches — triggering rollbacks if needed. Crave speed? Lazy-load remotes and embrace SSR with smart hydration to dodge mismatches and slash load times. Progressive hydration ensures the server-rendered shell hydrates client-side MFEs without jank, keeping users happy.

Ksolves: 35% Faster Loads

Real-world proof? Ksolves nailed it with an e-commerce giant. They splintered a monolithic Angular app into lazy-loaded MFEs for catalog, cart, and checkout. Result: 35% faster initial loads, 50% quicker feature rolls, and true team autonomy — all without UX fractures. Independent pipelines minimized risks, and a shared design system glued it together seamlessly.

These practices aren’t checkboxes; they’re your roadmap to MFE mastery. Start small, communicate loosely, test rigorously, and scale confidently. Your Angular app will thank you — faster, more resilient, and ready for whatever growth throws your way. Who’s piloting their first MFE this week?

Ready to Scale Smart?

Wrapping up our deep dive into Micro Frontends (MFEs) with Angular and Nx, you’ve got the tools to build scalable, team-friendly apps without the headaches.

The Power Trio: Key Takeaways

Implement MFEs only when your project hits real scale — like multi-team setups demanding independent deploys and tech stacks. Otherwise, stick to monorepo libraries for Angular’s compile-time magic. Prioritize Native Federation for slick sharing of deps like Angular core and RxJS via shareAll({}), cutting bundle bloat. Always enforce strict boundaries with clear exposes in federation.config.js and lazy loads via loadRemoteModule to sidestep regrets like sluggish perf (federation artifacts can drag dev builds) or UI drift across remotes.

Hands-On: Build Your Pilot

Fire up an Nx workspace today: npx create-nx-workspace@latest my-mfe --preset=apps, add Angular with nx add @nx/angular, then generate a host and remote like nx g @nx/angular:host apps/shell and nx g @nx/angular:remote apps/mfe1 --host=shell. Serve with nx serve shell --devRemotes=mfe1 and tweak routes to lazy-load your MFE. Share your pilot wins (or epic fails) in the comments—perf metrics or boundary gotchas welcome!

I Spent Months Perfecting My Dotfiles So You Don't Have To — Here's Everything Inside

Gouranga Das Samrat — Wed, 29 Apr 2026 10:45:06 +0000

"Your terminal is where you live. Make it beautiful."

Every developer has a dotfiles repo. Most of them are a pile of Gists half-remembered from 2019, a .bashrc that's been copy-pasted between machines for years, and a VS Code settings file that's one merge conflict away from catastrophe.

This one is different. I want to walk you through every real, working piece of gourangadassamrat/dotfiles — not just the highlights reel, but the actual code, the design decisions, and the parts that took the most iteration to get right.

⚡ The Bootstrap: One Command, Full Environment

git clone https://github.com/GourangaDasSamrat/dotfiles.git ~/dotfiles
cd ~/dotfiles/scripts && ./install.sh

install.sh calls every module in lib/ in order. If you want to pick and choose:

./setup.sh

This drops you into a numbered menu of every .sh file found recursively in scripts/ (excluding itself and utils/). You pick by number — or type all. No YAML, no external tooling, just bash.

The brains behind cross-platform compatibility live in utils/detect.sh, which determines your OS, available package manager (apt, brew, pacman), and sudo access. Every script in lib/ sources this. The result: the same lib/packages.sh that runs apt install on Ubuntu runs brew install on macOS, transparently.

Everything is symlinked into place using GNU Stow — one call to stow <module> and the directory structure inside that module folder maps directly onto $HOME. Zero manual path management.

🐚 The Shell: Nothing Is Left Unquestioned

The zsh config lives under zsh/.config/zsh/ and is split into core/, functions/, plugins/, and user/. Here's what's actually in each.

core/

colors.zsh — Defines COLOR_HEADER, COLOR_SUCCESS, COLOR_ERROR, COLOR_WARNING, COLOR_TEXT, COLOR_CURSOR, COLOR_BORDER, COLOR_NORMAL, COLOR_RESET as ANSI escape sequences. Every function and alias in the repo uses these — the whole terminal has a consistent color palette, not just a theme.

env.zsh — DOTFILES path, GOPATH, editor set to nvim, XDG_* base dirs.

history.zsh — HISTSIZE, SAVEHIST, setopt SHARE_HISTORY. Done correctly.

user/aliases.zsh

A few highlights that deserve explanation:

eza aliases are conditional. They only activate if eza is actually in $PATH:

if (($+commands[eza])); then
  alias ls='eza --color=always --long --git --no-filesize --icons=always --no-time --no-user --no-permissions'
  alias lt='eza --tree -a -I "node_modules|.git"'
fi

VS Code profile switching is handled gracefully across code, code-oss, and code-insiders. It detects which binary exists and aliases it correctly, then layers profile shortcuts on top — only if code resolves at all:

alias code-b='code --profile "Backend Dev"'
alias code-f='code --profile "Frontend Dev"'
alias code-g='code --profile "Go Dev"'
alias code-c='code --profile "C/C++ Dev"'
alias code-d='code --profile "Database Dev"'
alias code-r='code --profile "Rust Dev"'
alias code-l='code --profile "Lua Dev"'
alias code-p='code --profile "Python Dev"'
alias code-w='code --profile "Wiki Dev"'

Nine profiles. One alias each. Termux support is included too — for those of us who develop on Android:

if [[ -d /data/data/com.termux ]]; then
  alias debian="TERM='xterm-256color' proot-distro login debian --user gouranga"
fi

🔧 user/overrides.zsh: `mkdir` and `rm` Reimagined

These two rewrites are among my favorite parts of the whole repo.

`mkdir` — Git-aware directory creation

When you create a single directory, an interactive prompt appears — no fzf, just pure terminal keyboard input with read -k1 and ANSI escape sequences for arrow key detection:

  ◆  Initialize git repository in 'myproject'?
     Yes  › No

Use left/right arrows to toggle, Enter to confirm. If you say Yes:

cd "$1"
git init -q
echo "# $1" > README.md
git add .
git commit -m "chore: initialize repository with README" -q

It quietly creates the repo, writes a README, and makes the first conventional commit — all in one mkdir call. Creating multiple directories skips the prompt entirely.

`rm` — Confirm before you destroy

Overrides rm to first show you exactly what you're deleting (with 📁/📄 icons for directories vs files), then presents the same arrow-key Yes/No interface. Flags like -rf still pass through after confirmation. Both overrides use tput civis to hide the cursor during interaction and trap 'tput cnorm' EXIT to restore it on exit or Ctrl+C.

🔌 plugins/fzf.zsh: fzf Done Properly

The fzf config ships two themes — Dracula and Catppuccin — as named functions that can be swapped by calling them:

_fzf_theme_dracula()    # active by default
_fzf_theme_catppuccin() # call to switch

Each sets the full 8-color FZF_DEFAULT_OPTS palette: fg, bg, hl, info, prompt, pointer, marker, spinner, header, border.

Search uses fd instead of find:

export FZF_DEFAULT_COMMAND="fd --hidden --strip-cwd-prefix --exclude .git"

Tab completion previews use eza for directories and bat for files. Context-aware completion via _fzf_comprun routes different commands to appropriate previews — cd gets a directory tree, ssh gets dig {}, export/unset evaluates the variable value.

📡 functions/ — Custom Commands Written From Scratch

`apireq` — A Full API Client in Your Terminal

apireq is the most complex function in the repo. It's a complete interactive HTTP client powered by fzf, written entirely in zsh. No dependencies beyond curl, fzf, bat, jq, and optionally python3 for JSON validation.

Flow:

Choose: Create new request or Load saved .http file
Pick HTTP method via fzf
Enter URL
Multi-select with Space: Auth · Custom Headers · Query Params · Request Body
Auth: Bearer Token or Basic Auth (password via read -rs, no echo to terminal)
Body: JSON (validated via python3 -m json.tool), Raw Text, Form Data (urlencoded), or Multipart (supports file upload via key=@/path/to/file)
Output: auto (bat for headers + jq for JSON body), bat, jq, or raw
Save as .http file with an fzf folder picker that browses $HOME

The .http format is real — saved requests can be loaded, inspected in a preview pane, and optionally modified field-by-field (method, URL, headers, body) before re-sending.

`archive.zsh` — Universal Pack/Unpack

extract() handles tar.*, tgz, tbz2, txz, and zip via a clean case statement with colorized output using the colors.zsh palette.

compress() presents an fzf menu of 7 formats with human descriptions:

tar.gz   → Good balance, common
tar.bz2  → Better compression, slower
tar.xz   → Best compression, slowest
zip      → Cross-platform
7z       → High compression
gz       → Single file only
bz2      → Single file only

.gz and .bz2 correctly bail out with an error if you try to compress a directory.

`network.zsh` — Three Genuinely Useful Web Commands

All three are conditionally defined — they only load if their dependencies exist at shell startup.

isup [url] — Uses httpie with -F (follow redirects) and -p=h (headers only) to check site status. Displays ✔ ONLINE [200 OK], ⚠ ISSUE [301], or ✘ OFFLINE. Extracts and shows the Server: header value.

myip — Fetches ipinfo.io via httpie, parses the JSON with grep -Po, and prints IP address, city + region, and ISP — all styled with the color palette.

inspect [url] — Fetches response headers filtered to security-relevant ones (Server, Content-Type, X-Powered-By, Cache-Control, Strict-Transport-Security), then runs openssl s_client to show SSL cert validity dates. Only defined when both http and openssl are available.

`utils.zsh` — The Everyday Toolkit

serve [port] — Python HTTP server with a full validation loop: ensures the port is numeric, 1–65535, and not already bound (lsof -Pi :$port -sTCP:LISTEN). Prompts for another port if occupied.

timer <duration> — Accepts raw seconds, 1h30m, 45m20s, or any combination. Renders a full-screen countdown: color-coded time display (green → yellow → red as it runs out), a 40-char block progress bar (█░), a braille spinner, and elapsed time. On completion: terminal bell (\a), notify-send desktop notification, and system audio via paplay or aplay if available.

backup <path> — One command creates folder_backup_20260429_142301.tar.gz with a precise timestamp.

weather [city] — Fetches wttr.in/<city>?0mFq&format=v2 — the v2 format gives a full readable weather card. Defaults to Khulna.

t <command> — Prefixes every output line from any command with [YYYY-MM-DD HH:MM:SS] via moreutils' ts. Uses stdbuf -oL -eL for real-time line-buffered output and FORCE_COLOR=3 to preserve colors in piped output. Defined only if ts is installed.

expose [port] [ttl] — Wraps slim share with the same port validation as serve. Exposes localhost to the internet. Optional ttl argument passed through. Defined only if slim is installed.

`security.zsh` — Auto-Locking GPG

Spawns a background daemon named gpg-auto-lock-loop via exec -a (so it's grep-able by name) that fires gpg-connect-agent reloadagent /bye every 900 seconds — locking your GPG key cache. Checks for an existing instance before spawning so sourcing your config multiple times never creates duplicates.

`whois.zsh` — Filtered WHOIS Lookup

Defines a server map with keys dp (whois.digitalplat.org), iana (whois.iana.org), and com (whois.verisign-grs.com):

dzw example.com           # default server
dzw dp example.com        # via digitalplat.org
dzw iana example.com      # via IANA

Output is filtered with grep -E to useful fields only — Domain Name, Registrar, dates, Name Servers, Status — stripping all legal boilerplate.

`chpwd.zsh` — Smart Directory Change Hooks

Three functions registered via add-zsh-hook chpwd:

_manage_python_venv — Checks for .venv, venv, or .env directories. Auto-activates on cd in, auto-deactivates on cd out.

_list_project_tools — On every cd, detects and lists available automation targets. justfile → just --list. Makefile → awk-parsed targets. package.json → jq -r '.scripts | keys[]'. docker-compose.yml → docker compose ps --services.

_auto_nvm_use — Reads .nvmrc and calls nvm use automatically.

`plugins/pass.zsh` — Encrypted Secret Management

env-save <file> <pass-path> — Reads a .env file and pipes it into pass insert -m at any path in the password store. Multi-line safe.

env-load <pass-path> [filename] — Pulls secrets out of pass into a local file (defaults to .env). Verifies the path exists before writing. Prints line count on success.

🪟 tmux: Live Weather in the Status Bar

The tmux config uses Catppuccin macchiato with rounded window separators and status bar at the top, updating every second.

The live weather widget:

set -ag status-right "#[fg=#b7bdf8,bg=#24273a] #[fg=#24273a,bg=#b7bdf8,bold]#(curl -s 'wttr.in/Khulna?format=%%c%%t' | tr -d '+')#[fg=#b7bdf8,bg=#24273a] "

This fetches the current condition icon and temperature from wttr.in every second. tr -d '+' strips the leading + from positive temperatures.

Key bindings:

Prefix:         Ctrl+A
Splits:         | horizontal · - vertical (opens at current path)
Pane nav:       h·j·k·l (Vim) or Alt+Arrow (no prefix)
Window nav:     Alt+1–5 (no prefix needed)
Window reorder: < and > to swap left/right
Resize:         Prefix + H/J/K/L (repeatable with -r)
Zoom pane:      Prefix + m

Persistence: tmux-resurrect + tmux-continuum auto-save every 5 minutes (@continuum-save-interval '5'), restore on server start (@continuum-restore 'on'), and capture pane contents (@resurrect-capture-pane-contents 'on').

🖥️ VS Code: Nine Profiles, Every Extension Documented

The docs/vscode/vscode-extensions.md documents every extension per profile:

Profile	Formatter	Key Extensions
Default	—	Dracula, Error Lens, GitLens, Code Spell Checker, Commit Sage, Todo Tree
Frontend	Prettier + ESLint	Live Server, Pretty TS Errors, Tailwind IntelliSense
Backend	Prettier + ESLint	Thunder Client, Prisma, SQLTools
C/C++	clangd	clangd, Code Runner
Go	gopls + goimports	Go (official), Code Runner
Database	prettier-sql	Prettier SQL VSCode, SQLTools
Rust	rust-analyzer	rust-analyzer, Code Runner
Lua	sumneko	Lua, Code Runner
Wiki	Prettier	Prettier

Font stack: Operator Mono (italic keywords + ligatures) → Cartograph CF → JetBrains Mono.

Custom snippets shipped: cpp.json (competitive programming main, LeetCode template), go.json (main, package, iferr, interface), react-components.code-snippets, clang-format.code-snippets.

✏️ Neovim: lazy.nvim + Custom Dashboard

Managed by lazy.nvim. Plugins:

Mofiqul/dracula.nvim — Dracula with italic_comment = true
nvim-lualine/lualine.nvim — statusline with dracula-nvim theme
windwp/nvim-autopairs — auto-close brackets on InsertEnter
folke/todo-comments.nvim — highlights TODO:, FIXME:, NOTE: etc.
rhysd/committia.vim — splits the commit window into diff + message panes
lewis6991/gitsigns.nvim — git diff signs in the gutter
goolord/alpha-nvim — ASCII NEOVIM banner dashboard with New File, File Browser, and Quit shortcuts

Options set in one compact idiomatic block: line numbers, cursorline, 2-space tabs, smart case search, clipboard = "unnamedplus", persistent undo, no swapfile, trailing space and tab indicators.

A gitcommit FileType autocmd enables spell and sets textwidth=72 — matching the 72-char limit the git hook warns about.

🔧 Git: GPG Signing + Hooks That Apply Everywhere

.gitconfig

All commits are GPG-signed by default. core.hooksPath = ~/.git-hooks redirects hooks globally — every repository on the machine gets these hooks automatically without any per-repo setup.

Useful aliases:

git lg         # color graph log with relative time
git today      # commits since midnight with [HH:MM AM/PM] timestamps
git yesterday  # yesterday's commits
git mine       # your commits only across all branches
git last       # full detail: hash, author, date, full message
git undo       # soft reset HEAD~1
git unstage    # reset HEAD --
git el         # dump log to git_history.txt

commit-msg hook

Validates the Conventional Commits spec: type(scope): subject. Skips merge commits (^Merge) and revert commits (^Revert). Valid types: feat, fix, docs, style, refactor, test, chore, perf, ci, build, revert. Warns (non-blocking) if the subject line exceeds 72 characters.

pre-push hook

Sources ~/.zsh_secrets and checks for GIT_PUSH_PASS. If set, prompts for a passphrase via /dev/tty with stty -echo (no terminal echo). Push proceeds only on match. A lightweight push authorization layer without external tooling.

📊 GitHub CLI: Contribution Analytics in the Terminal

gh/.config/gh/config.yml ships a full suite of GraphQL-powered gh aliases with ANSI color formatting baked into the --jq expressions:

Current activity:

gh today              # every commit with [HH:MM] timestamps, all repos
gh today-summary      # repo-by-repo breakdown + total count
gh today-stats        # commits, PRs, issues, private contributions
gh this-month-summary # monthly breakdown via GraphQL (handles 1000+ commits)
gh this-year-summary  # year breakdown sorted by repo
gh this-year-languages # top 5 languages by bytes committed this year
gh streak             # current and longest commit streak

Historical lookups:

gh yesterday           # prior day commits with timestamps
gh last-month-summary  # prior month breakdown
gh last-year-languages # top 5 languages in previous year

Utilities:

gh prs   # your PRs in the current repo (all states)
gh open  # open current repo in browser
gh co    # interactive PR checkout

All cross-platform — macOS date flags handled separately from Linux via [[ "$OSTYPE" == "darwin"* ]] checks in the shell snippets.

🎨 Starship: A Two-Line Prompt Showing Everything

The starship.toml config uses a two-line layout with $fill for right-alignment. Line 1 (left): hostname (SSH only), directory, language version modules. Line 1 (right): git branch, git status, command duration, time, OS. Line 2: ❯ (green on success, red on error).

Notable details:

Directory truncated to 1 level (truncation_length = 1)
Git status shows ahead/behind counts (⇡/⇣), untracked (?), modified (!), staged (+), renamed (»), deleted ( )
Command duration shown after just 1ms
Custom VS Code version — [custom.vscode] runs a shell script that finds the installed binary, reads its package.json, and shows the version inline in the prompt whenever VS Code is available. Works across code, code-oss, and code-insiders.
Language icons for Node, Go, Python, Rust, Java, Kotlin, Lua, Dart, Swift, Zig, Deno, Bun, and more — all Nerd Font.

🖱️ Rofi: Dracula App Launcher (Linux)

rofi/config.rasi uses the Dracula palette as CSS variables: MonoLisa 13 font, rounded 8px corners, 95% opaque background (#282a36ee), bd93f9 purple border and selection highlight, MacTahoe-dark icon theme. 7 items visible, 1 column, no scrollbar.

🎵 ytm-player: YouTube Music in the Terminal

High-quality audio, 80% default volume, prefetch_next enabled, block-style progress bar, album art in UI. MPRIS enabled for Linux media key integration. LastFM and Discord Rich Presence configured but disabled by default — just uncomment to enable.

🏗️ Full Architecture

scripts/
├── install.sh               # runs lib/* in order
├── setup.sh                 # interactive numbered menu
├── config/wallpapers.url    # remote wallpapers repo URL
├── utils/detect.sh          # OS, pkg manager, sudo detection
└── lib/
    ├── packages.sh          # all tools via apt/brew/pacman
    ├── plugins.sh           # oh-my-zsh, zsh plugins, tpm
    ├── wallpapers.sh        # clones wallpapers repo
    ├── dotfiles.sh          # stow + chmod git hooks
    ├── go_tools.sh          # gopls, goimports, golangci-lint, air,
    │                        # gotests, govulncheck, shfmt, usql, slim
    │                        # (--update flag supported)
    └── python_tools.sh      # httpie, ytm-player via uv
                             # (--update flag supported)

usql is installed with custom build tags (mysql postgres sqlite3 moderncsqlite) — one universal SQL client for four databases. Both go_tools.sh and python_tools.sh call go clean -modcache or equivalent cleanup after installation.

✅ CI/CD: Dotfiles That Are Actually Tested

shell-validation.yml — Runs shellcheck on every .sh file in scripts/ to catch undefined variables, unsafe patterns, and portability issues.

scripts-functionality.yml — Integration tests that run the core install scripts end-to-end in a CI environment.

Full GitHub issue template system: bug reports, feature requests, and config update requests — each with structured fields. PR template with a checklist.

🔒 Secret Templates

docs/templates/.zsh_secrets.template — Documents exactly which variables to set (including GIT_PUSH_PASS) in ~/.zsh_secrets, sourced by the pre-push hook.

docs/templates/.connections.usql.template — Ready-to-fill database connection string template for usql.

Getting Started

# Full auto-bootstrap
git clone https://github.com/GourangaDasSamrat/dotfiles.git ~/dotfiles
cd ~/dotfiles/scripts && ./install.sh

# Interactive — pick exactly what you want
cd ~/dotfiles/scripts && ./setup.sh

# Just Go tools
bash ~/dotfiles/scripts/lib/go_tools.sh

# Update all Go tools
bash ~/dotfiles/scripts/lib/go_tools.sh --update

# Just Python tools
bash ~/dotfiles/scripts/lib/python_tools.sh

Why This Is Different From Most Dotfiles Repos

Conditional loading everywhere. Nothing breaks if a dependency isn't installed. Every alias, function, and plugin checks for its binary before defining itself. Works on a minimal server and a fully loaded workstation.

The functions are genuinely useful replacements. apireq isn't a thin curl wrapper — it's a workflow with saved state. timer isn't a sleep alias — it's a full TUI. chpwd hooks aren't novelties — they save real keystrokes every day.

Git hygiene enforced at the machine level. core.hooksPath in .gitconfig points to a global location. Every repository you clone or create automatically gets conventional commit validation and push authorization — not just repos where you remembered to install hooks.

Modular by design. You can take exactly one piece — the fzf config, the git aliases, the apireq function, the starship prompt — and drop it into your own setup without the rest.

The repo is at github.com/GourangaDasSamrat/dotfiles. Everything described here is real, working code — read the source.

If it made your terminal feel like home — drop a ⭐

Built by Gouranga Das Samrat · MIT License · Issues and PRs welcome

🚀 Handling Multiple Form Submissions Gracefully on Frontend

Gouranga Das Samrat — Sun, 26 Apr 2026 14:00:00 +0000

How to Build a User-Proof, Scalable, and Clean Form Submission Flow

Handling multiple form submissions is one of those subtle — but critical — frontend challenges every engineer encounters. Users double-click buttons, spam taps, refresh pages, or simply get impatient. And if your backend isn’t fully idempotent, this can quickly turn into:

Duplicate entries
Failed or partial saves
Data corruption
Frustrated users

A small UX issue suddenly becomes a large engineering headache.

In this article, let’s break down a reliable, scalable strategy to gracefully handle multiple submissions on the frontend.

🔹 1. Disable the Submit Button After the First Click

The simplest and most effective safeguard.

Once the user clicks Submit, immediately:

Disable the button
Show a loader or progress indicator

This prevents accidental double-clicks and gives the user a visual cue that the action is in progress.

🔹 2. Use Debouncing or Throttling

Some submissions get triggered by event-based actions, like _onChange_, _onEnter_, or UI interactions.

To prevent rapid re-triggers:

Debouncing delays execution until the user stops triggering the event.
Throttling ensures the event fires only once in a fixed interval.

This protects your API from spammy or repeated calls.

🔹 3. Implement a Client-Side Request Queue

When multiple submissions are possible due to network delays or user impatience, a frontend queue ensures requests are processed sequentially, not all at once.

Get Richa Gautam 🌷’s stories in your inbox

Join Medium for free to get updates from this writer.

This guarantees:

Predictable behavior
Controlled request flow
Preventing race conditions or overwrites

🔹 4. Use Idempotency Keys (Best Practice)

This is the gold standard — especially in payments, forms, and transactional flows.

Generate a unique key (UUID) for every submission request.
Send it to the backend with the payload.

If the user accidentally sends the same request 10 times:

➡️ The backend will treat all duplicates as a single operation.

This ensures data integrity, even if the user hammers the button.

🔹 5. Implement Optimistic UI Updates

Users hate waiting.

To improve perceived performance:

Update the UI instantly
Assume the operation will succeed
Roll back changes only if the request fails

This creates a smooth, responsive experience while maintaining correctness.

🎯 Final Thoughts: Small UX Patterns Have Big Impact

When your app scales, even tiny interactions — like form submission behavior — start to matter.

A robust submission strategy:

Improves data integrity
Reduces accidental duplicates
Makes your UI feel polished and responsive
Builds user confidence and trust

Even if a user clicks 10 times, your system stays stable and your data stays clean.

🙏 Stay Connected!

🔔 Follow for more guides on JavaScript, React.js & interview prep.

**_Thankyou! for reading my article.

7 Secrets Your Framework Docs Don’t Tell You About Standalone Components

Gouranga Das Samrat — Sun, 19 Apr 2026 14:00:00 +0000

You’ve probably heard about Angular’s standalone components — they’re a fresh way to build apps without relying on NgModules. But there’s more to them than just skipping modules. Standalone components let you create self-contained building blocks that you import exactly where you need them, which makes your app cleaner and easier to manage. They simplify how you organize your code and open up new possibilities for building faster, more modular apps.

This article isn’t about the basics you’ve heard before. Instead, it dives into seven hidden tips and real-world advantages that most people overlook. Whether you’re new to Angular or a seasoned developer, these insights will help you get more from standalone components. Even if you’re a manager or stakeholder curious about how Angular’s latest features can impact your projects, this guide will give you useful, practical knowledge to make development smoother and more efficient.

Secret 1: Standalone Components Simplify Dependency Management

Standalone components in Angular simplify dependency management by letting each component handle its own imports right inside its decorator. This eliminates the need for bulky NgModule declarations and cuts out a lot of repetitive boilerplate code. Basically, your component says, “Here’s exactly what I need,” making dependencies clearer and more local.

This approach also makes teamwork smoother. When dependencies are tied to the component itself, it’s easier for developers to understand and manage their parts without digging through large module files. It reduces conflicts, speeds up onboarding, and encourages building reusable, self-contained components.

For example, instead of declaring a component and its imports in an NgModule like this:

@NgModule({
  declarations: [OldComponent],
  imports: [CommonModule, FormsModule, SharedModule],
})
export class AppModule { }

You convert it to a standalone component that imports what it needs directly:

@Component({
  selector: 'app-new',
  standalone: true,
  imports: [CommonModule, FormsModule, SharedModule],
  templateUrl: './new.component.html',
})
export class NewComponent { }

No more module clutter, just a clear, self-sufficient component. This not only makes your code easier to manage but also sets you up for better lazy loading and performance optimization. Overall, standalone components cut down complexity, boost collaboration, and keep your Angular apps clean and scalable.

Secret 2: Lazy Loading Made Easy with Standalone Components

Why It Matters

Lazy loading helps your app start faster by loading only what’s needed when it’s needed. Angular’s standalone components make lazy loading even simpler — no more wrapping components inside modules just to load them on demand. With the loadComponent API, you load standalone components directly, which trims down your code and speeds up your app.

Old vs. New Lazy Loading

Before, you had to create entire NgModules to lazy load parts of your app, which added extra setup and larger bundles. Now, you can lazy load standalone components directly, skipping that module overhead entirely. It’s like ordering a single item instead of the whole combo — more precise and less bulky.

Performance Boosts

Loading only the components you need means smaller initial downloads and faster startup times. Angular can also optimize your app better since there’s no extra module wrapping. The result? A nimbler app that feels faster and more responsive.

Tips for Organizing

Use loadComponent in your routes to lazy load standalone components.
Group related components but avoid forcing modules just for lazy loading.
Don’t import lazy components eagerly elsewhere; keep them truly lazy.
Provide services inside standalone components for localized scope.

Quick Code Example

const routes = [  {
    path: 'dashboard',
    loadComponent: () => import('./dashboard.component').then(m => m.DashboardComponent)
  },
  {
    path: 'profile',
    loadComponent: () => import('./profile.component').then(m => m.ProfileComponent)
  }
];

With this setup, Angular loads each standalone component only when its route is visited. Simple, clean, and fast!

In short, standalone components make lazy loading straightforward and more efficient, helping you build faster Angular apps with less hassle. Give it a try — you’ll love the boost in speed and simplicity!

Secret 3: Standalone Components Make Your Angular Apps Smaller and Faster

One of the best things about Angular’s standalone components is how they help your app load quicker and run smoother by making the bundles smaller. This happens thanks to better build optimization and tree shaking — which just means cutting out unused code automatically.

Smaller Bundle Sizes Thanks to Modular Dependencies

With standalone components, each piece knows exactly what it needs, instead of hiding behind big NgModules that pack everything together. This modular setup means only the parts you actually use get included, making your final app bundle much lighter and faster to download.

Better Tree Shaking Compared to NgModules

Tree shaking is like cleaning out your closet — it removes the stuff you don’t wear (or use). Traditional NgModules can be a bit messy because they bring in whole modules even if you only need part of them. Standalone components are neat and precise, so tools can trim your code more effectively, resulting in less unnecessary code in your app.

How to Use This for Speedier Apps

To get the most out of standalone components:

Switch your key components to standalone gradually.
Only import what each component really needs.
Use lazy loading with standalone components to load parts only when needed.

Following these steps helps your app start faster and feel more responsive, especially for users with slower devices or connections.

Quick Example: Smaller and Faster Bundles

As you can see, adopting standalone components can shrink your bundle by over 35% and speed up load times significantly.

Standalone components give you control and freedom to keep your Angular apps lean and fast, making everyone’s life easier — from developers to end users.

Secret 4: Easier Migration Path — The Hybrid Approach

Migrating a big Angular app doesn’t have to mean a risky, all‑at‑once rewrite. Angular’s hybrid approach lets you mix standalone components and NgModules, so you can modernize piece by piece without breaking anything.

Why Hybrid Works for Big Apps

Large apps need stability and flexibility. With hybrid migration, you keep NgModules running while gradually introducing standalone components. This means you can keep shipping new features, avoid long freezes, and reduce risk. If something goes wrong, you can roll back without taking the whole app offline.

How to Migrate Step by Step

Start by picking a small, self‑contained area — like a feature or a route — and convert it to standalone components. Use Angular’s migration tools to help automate the process. Move your routing one route at a time, test after each change, and deploy small updates. Once a section is fully migrated, clean up the old module wiring before moving on.

Common Pitfalls to Avoid

Don’t try to migrate everything at once — it’s tempting, but it usually leads to delays and bugs. Avoid leaving temporary fixes in place, as they can turn into technical debt. Watch out for tangled dependencies and shared state, which can make migration messy. Untangle things as you go.

A Quick Example

Imagine a banking dashboard. Start by migrating the notifications section to standalone components while leaving the main dashboard as is. Move the reports section route by route, validating with tests and real traffic. Keep stakeholders updated with simple metrics like “40% of routes now standalone.” Once everything is migrated, remove the old modules and glue code, leaving behind a cleaner, faster Angular app.

The hybrid approach lets you modernize with control — no big bang, no drama, just steady progress.

Secret 5: Standalone Components Improve Testing Isolation

Standalone components in Angular make unit testing simpler and more focused. They help you write cleaner, better isolated tests that are easier to maintain and quicker to run.

How Standalone Components Change Test Setup

With traditional components, tests require setting up a testing module where you declare the component and import all necessary modules. This can get bulky and hard to manage.

Get Karol Modelski’s stories in your inbox

Join Medium for free to get updates from this writer.

Standalone components handle their own dependencies inside their definition, so in tests you just import the component directly. This makes the setup shorter and much less cluttered, letting you focus on testing instead of configuration.

Why This Makes Tests Easier to Maintain

Since each standalone component controls its own dependencies, test setups update automatically when the component changes. Your tests stay stable even if the rest of the app’s module structure changes.

This means less risk of broken tests from module tweaks and easier refactoring overall. Simpler test setups also makes tests clearer and less intimidating for the whole team.

How It Speeds Up Test Execution

Skipping heavy module setups means tests compile and run faster. The isolation standalone components bring also helps test runners parallelize and cache tests better, giving you faster feedback when coding or in CI.

Example: A Clean Unit Test for a Standalone Component

import { ComponentFixture, TestBed } from '@angular/core/testing';
import { MyStandaloneComponent } from './my-standalone.component';
describe('MyStandaloneComponent', () => {
  let fixture: ComponentFixture<MyStandaloneComponent>;
  let component: MyStandaloneComponent;
  beforeEach(async () => {
    await TestBed.configureTestingModule({
      imports: [MyStandaloneComponent]  // Just import directly
    }).compileComponents();
    fixture = TestBed.createComponent(MyStandaloneComponent);
    component = fixture.componentInstance;
    fixture.detectChanges();
  });
  it('should create the component', () => {
    expect(component).toBeTruthy();
  });
  it('should have the correct default title', () => {
    expect(component.title).toBe('Hello Standalone');
  });
});

No declarations or extra module imports needed — just the component. This makes tests clean and isolated.

Standalone components help you build faster, more maintainable test suites by simplifying setup, improving isolation, and speeding up execution. They make testing in Angular a smoother and more enjoyable experience.

Secret 6: Standalone Components Make Reuse a Breeze

Standalone components in Angular let you build pieces of your app like LEGO bricks — snap them together without the module fuss. Now, components just import each other directly, so building and updating your UI is smoother and less confusing.

Mix and Match, No Headaches

Want one reusable component to use another? Just import it. There’s no more juggling NgModules — these components stand on their own. It’s all about working smarter and keeping things simple.

Perfect for Design Systems

Design systems thrive on reusable, consistent parts. Standalone components keep logic and styles self-contained, so sharing a slick button or form input across different projects is painless. This keeps every app on-brand and makes updates quick.

Large Teams: Speed and Consistency

When teams are big, code duplication can be a nightmare. With standalone components, anyone can grab shared widgets and use them, which means less confusion and more teamwork. Updates get rolled out fast and everyone stays in sync.

Real-World Example: The Trusty Button

Picture one button component that looks and works great. Build it once as a standalone. Need it elsewhere? Just pull it in — no extra config, no module drama. That’s a win for everyone.

Standalone components keep your code neat, easy to reuse, and a joy for both small teams and big enterprises. Once you try them, you’ll wonder how you ever lived without them.

Secret 7: Advanced Providers and Dependency Injection Tricks

Angular’s dependency injection (DI) system gets even more powerful with standalone components. Here’s how to manage your services smartly without the usual complexity.

Local vs Global Providers

You can provide services globally (available everywhere) or locally (only inside a specific standalone component and its children). Global services act like shared singletons for the whole app. Local services are new instances each time the component loads, keeping state or behavior isolated.

Use local providers when you need independent service instances that won’t interfere with other parts of your app.

Service Scopes in Standalone Components

Standalone components let you control exactly where services live:

Adding services directly in a standalone component’s providers means those services are scoped to that component and its subtree.
This allows you to run multiple instances of the same service in different component trees.
You can also override global providers locally when needed, for example, to swap a real service with a mock during testing.

Hierarchical Injectors and Standalone Components

Angular’s DI is hierarchical. The root injector is global, but standalone components can add their own injectors by declaring providers locally. Child components inherit from these injectors unless they declare their own providers.

This makes it easy to share some services globally while having specialized versions in particular sections of your app.

Example: Different Service Scopes in Action

@Injectable({ providedIn: 'root' })
export class GlobalService { 
  getValue(): string {
    return 'Global service value';
  } 
}
@Injectable()
export class LocalService { 
  getValue(): string {
    return 'Local service value';
  } 
}
@Component({
  selector: 'app-standalone',
  standalone: true,
  template: `
    <p>{{globalValue}}</p>
    <p>{{localValue}}</p>
    <app-child></app-child>
  `,
  providers: [LocalService],
})
export class StandaloneComponent {
  private globalService = inject(GlobalService);
  private localService = inject(LocalService);
  protected globalValue = this.globalService.getValue();
  protected localValue = this.localService.getValue();
}
@Component({
  selector: 'app-child',
  standalone: true,
  template: `<p>Child uses local: {{ localValue }}</p>`,
})
export class ChildComponent {
  private localService = inject(LocalService);
  protected localValue = this.localService.getValue();
}

Here, the GlobalService is shared app-wide. The LocalService is created fresh for StandaloneComponent and passed down to its child, giving you neat control over service lifetimes and visibility.

This approach keeps your Angular app modular and lean, with services existing only where they’re needed. It’s a simple but powerful way to master dependency injection in standalone components.

To sum it all up

You’ve learned 7 key secrets that make Angular apps simpler, faster, and easier to work with. Using standalone components as the default helps keep features self-contained and avoids the old tangled NgModule mess. Smarter routing and feature boundaries make your app easier to understand and faster to load. Lean state management and change detection patterns keep your UI smooth and responsive. All these add up to a happier, more productive team and better apps.

What to do next

Don’t try to change everything at once. Pick one secret and test it out in a small part of your app. Maybe create a standalone component, lazy-load a route, or optimize change detection on a slow screen. Measure the impact, then decide if it’s worth applying more broadly. If you lead a team, make it a small sprint goal, so everyone can learn and improve together.

Want to dive deeper?

Start with the official Angular docs — they have great guides on standalone components, performance, and architecture. When you’re ready, check out expert blogs, tutorials, and community resources to see how others solve real-world problems. Join Angular meetups, workshops, or conferences to stay up to date and learn from the best.

Keep experimenting, and watch your Angular apps and teams thrive.

Your support helps me create more practical guides and tools tailored for the frontend and startup community.

Let’s keep building together 🚀

How To Migrate to Signal Inputs and Queries Without Rewriting Your Templates

Gouranga Das Samrat — Sun, 12 Apr 2026 14:00:00 +0000

Hey, let’s talk about why reactive programming — and especially Angular’s signals — are blowing up right now. You’ve probably noticed how apps need to feel snappier and more responsive these days, right? Signals make that happen by letting your Angular code react to data changes automatically, cutting out a ton of the old-school hassle with change detection.

So, quick rundown: Signal inputs are like smart inputs that feed reactive data straight into your components, and signal queries let you pull and react to derived stuff from those inputs. They’re a big deal because they make your apps predictably fast and way easier to manage — no more wrestling with endless subscriptions or zone.js quirks.

If you’re an Angular dev or tech lead itching to modernize without ripping apart your templates, you’re in the right spot. We’ll dive into migration tricks that keep your existing views intact, so you can upgrade efficiently and get those wins without the headache.

Understanding Signal Inputs and Queries in Angular

You ever get tired of Angular’s old-school data passing feeling like a chore? Yeah, me too. That’s where signal inputs and queries come in — they’re the new, smooth way to handle inputs and grab child elements, all with built-in reactivity that keeps things zippy. No matter if you’re coding all day or just overseeing the team, this stuff makes apps faster and way less buggy. Let’s dive in and see why everyone’s switching over.

What Are Signal Inputs and Queries?

Hey, let’s talk about signal inputs and queries in Angular — they’re game-changers for passing data around and grabbing references to stuff in your components. Signal inputs use the input() function instead of the old @Input() decorator, giving you a reactive value that updates automatically when the parent changes it. And queries? Think viewChild() or contentChild()—they replace @ViewChild and @ContentChild, handing you back a signal that stays fresh without all the lifecycle hook hassle.

You know how traditional inputs meant hooking into ngOnChanges and dealing with Zone.js firing off change detection everywhere? Signals fix that mess. They make state super reactive, so only the parts that need updating actually do—pair them with computed() or effect(), and your app feels snappier, especially as it grows. No more guessing when things update; it's all predictable and fine-grained.

Why They’re a Big Upgrade

Picture this: old-school inputs could trigger full tree scans for changes, slowing things down. Signals? They mark OnPush components dirty only when needed, ditch ngOnChanges, and work zoneless for even better speed. Queries give you live signals instead of static lists, so you access kids reactively—no subscriptions or manual checks required. The perks hit hard: less code, easier debugging, and performance that scales, which managers love for real-world apps.

Plus, you’ve got handy options like required, alias, or transform right in the API. It cuts boilerplate and makes your components cleaner. Stakeholders get why this matters—fewer bugs, faster UIs, and dev teams move quicker.

Seeing Them in Action

Want to see it? Here’s a quick child component grabbing a count from its parent:

import { Component, input, computed } from '@angular/core';
@Component({
  selector: 'app-counter',
  template: `<p>Count: {{ doubledCount() }}</p>`
})
export class CounterComponent {
  count = input.required<number>();
  doubledCount = computed(() => this.count() * 2);
}

Just bind it like <app-counter [count]="parentCount"></app-counter>. Boom—changes flow instantly.

Get Karol Modelski’s stories in your inbox

Join Medium for free to get updates from this writer.

For queries, say you need an input field:

import { Component, viewChild, ElementRef } from '@angular/core';
@Component({
  selector: 'app-search',
  template: `<input #searchInput />`
})
export class SearchComponent {
  searchInput = viewChild.required<ElementRef<HTMLInputElement>>('searchInput');
  focusSearch() {
    this.searchInput().nativeElement.focus();
  }
}

Content queries work the same for projected kids. Simple, right? Less fuss, more power — you’ll wonder how you lived without ‘em.

Migration Strategies Without Template Rewrites

Look, migrating your old Angular templates to signals doesn’t have to mean ripping everything apart and starting over. Signals make your app snappier, easier to manage, and way more reactive — perfect for keeping things modern without the chaos. In this chapter, we’ll dive into straightforward strategies that let you wrap, adapt, and mix signals into your legacy code with barely a template tweak. Stick around for practical steps and a real dialog example that shows it all in action.

Why Migrating Legacy Templates to Signals is Tricky

Hey, let’s talk about the real headaches when you’re trying to shift old Angular templates over to signals. The big issue? Signals need that () to read them—like count()—but your legacy templates just use plain properties without it. Messing with templates directly can break everything in a huge app, spark a testing nightmare, and even tank production if your inputs get mutated weirdly or tie into ngOnChanges. That's why smart folks focus on tweaking the TypeScript side first, leaving your HTML alone.

Approach 1: Wrap Inputs and Queries in Signals

Start simple: wrap your old @Inputs and @Outputs, plus those ViewChild queries, right into signals—without touching the templates at all. Fire up Angular's schematics with ng generate @angular/core:signal-input-migration, and it'll swap safe inputs to input() signals automatically. It flags risky mutable ones with TODOs if you add --insert-todos. For queries, grab ng generate @angular/core:signal-queries-migration --best-effort-mode to link @ViewChild to viewChild(), and boom—your templates keep binding like nothing changed.

Approach 2: Adapters and Helpers to the Rescue

Don’t want to invoke signals everywhere? Whip up quick adapters or getters to make them act like regular properties. Something like get openState() { return this.openSignal(); } lets your template use [open]="openState" no sweat. Or lean on @angular/core/rxjs-interop with toSignal for observables—legacyData = toSignal(this.observableData$)—ditching the async pipe. Helpers like linkedSignal can even compute derived stuff reactively on the fly.

Approach 3: Go Incremental and Hybrid

Nobody migrates a whole app overnight, right? Mix signals with your legacy code piece by piece — maybe one module via ng generate @angular/core:signal-input-migration --path=src/app/feature. New kid components get signals, parents stay legacy, and Angular's fine-grained tracking keeps things zippy without zoneless drama. Slice it up, test as you go, and use VS Code refactors for @Input to input() swaps plus effect() for side effects. Stability first!

Real-World Example: A Simple Dialog Toggle

Picture this: you’ve got a legacy dialog with @Input() open: boolean; and a parent template like <app-dialog [open]="isOpen">, toggling via this.isOpen = !this.isOpen. Migrate by adding isOpen = signal(false); and that getter get isOpenState() { return this.isOpen(); }, then toggle with this.isOpen.update(v => !v). Template? Untouched. Add effect(() => console.log('Dialog:', this.isOpen())) for fun, and schematics handle most of it—your app's now signal-powered with zero HTML fuss.

Best Practices and Tooling Support

Hey, migrating to Angular Signals doesn’t have to be a headache. You can lean on Angular’s built-in schematics to handle the basics — like swapping inputs and queries — then tweak the tricky bits yourself. This way, you snag those sweet performance boosts from smarter change detection without wrecking your legacy code.

Smart Patterns to Follow

Look, start small: tackle simple inputs and queries first with the automated tools. For anything fancier, like RxJS streams or nested data, go manual and keep things immutable — tools like Immer make that a breeze by letting you “mutate” safely.
Don’t write directly to signal inputs (it’ll bite you), and use toObservable() to bridge signals back to RxJS when needed. Oh, and always chase down those schematic TODOs right away—they're your roadmap to pitfalls avoided.

Tools That Make It Easy

Angular’s CLI has your back with schematics that do the grunt work. Fire up ng generate @angular/core:signal-input-migration --best-effort-mode to flip @Input() to input(), and it'll flag anything sketchy with TODOs.
Same for outputs (signal-output-migration) and queries (signal-queries-migration—use --path to target folders).
Stuff like ngxtension helps keep your input names intact too. No more copy-paste nightmares.

Testing It Right

You gotta test like your app depends on it — which it does. Mock signals in unit tests with toSignal() for observables, then fire up Angular DevTools to eyeball those change detection wins (fewer cycles, happier users).
Run your full e2e suite after, hunt schematic reports for weirdness, and manually poke the TODO cases. Right? Performance graphs don't lie.

Step-by-Step Workflow

Bump to Angular 19+: ng update @angular/cli @angular/core. Easy start.
Hit the schematics in order: inputs, outputs, queries. Safety flags on.
Hunt TODOs, swap RxJS where it fits.
Test hard — units, perf, e2e.
Roll out bit by bit, watch prod for zoneless vibes if you’re going there.

Conclusion

Using Signal inputs and queries in your Angular apps is a smart move. They make your app faster and easier to maintain by letting you react smoothly to changes in data. This approach helps your app feel more responsive, which improves the user experience.

You don’t have to switch everything all at once. Try adding Signals little by little in parts of your app that need the most attention. This way, you avoid big rewrites and can see benefits as you go, keeping your project stable and moving forward.

If you want to learn more, check out Angular’s official docs and tutorials on Signals and reactive programming. There are plenty of guides and articles that break down the concepts and show practical examples to help you get comfortable with this modern Angular style.

Your support helps me create more practical guides and tools tailored for the frontend and startup community.

Let’s keep building together 🚀

Here’s Exactly How I Implemented @defer for Granular Code Splitting in Days — Step-by-Step

Gouranga Das Samrat — Sun, 05 Apr 2026 14:00:00 +0000

Picture this: you slash your Angular app’s initial bundle by 40% in days, loading those heavy charts only when users scroll down — no routing headaches required. Angular’s @defer (dropped in v17) is your new best friend for smart, template-level lazy loading of standalone components, directives, and pipes—perfectly teaming up with router lazy loading to crush Core Web Vitals like LCP.

Whether you’re a beginner dipping into @defer magic, an expert tweaking performance, or a stakeholder chasing that ROI from snappier apps, this guide's got you. We'll roll through hands-on steps, code snippets, killer triggers (viewport scrolls, button clicks), placeholder tricks to kill layout jank, and error-handling smarts—skipping compiler deep dives.

Ready to prefetch on idle, render on hover, and watch your app fly? Let’s dive in and supercharge your Angular game!

@defer Fundamentals and Setup

Angular’s @defer block is a game-changer for performance, letting you split heavy template sections—like charts or dashboards—into separate JavaScript bundles that load only when triggered by events such as viewport entry, user interaction, or browser idle time. This slashes your initial payload, speeding up Largest Contentful Paint (LCP) and overall app startup, especially in large single-page apps where not every user needs every feature right away.

Requirements for Success

You’ll need Angular 17 or later, as @defer leverages the new control flow syntax and stable deferrable views from Angular 18 onward. Components, directives, and pipes inside the @defer block must be standalone and not referenced elsewhere in the same file—think no sneaky ViewChild queries or imports outside the block, or they'll eagerly load anyway. Transitive dependencies can mix standalone or NgModule-based, but keep placeholders lightweight since their deps load upfront.

Basic Syntax in Action

Kick off with something simple: @defer (on viewport) { <heavy-chart /> } @placeholder { <skeleton-loader /> }. Here, the chart bundle loads when the placeholder hits the viewport, swapping the skeleton for the real deal—triggers like idle (default), interaction, hover, timer(2s), or custom when showLargeChart give you precise control. Add @loading (minimum 1s) for spinners during fetch, or @error { Retry? } for fails, all while prefetching separately via prefetch on idle.

Verify Your Build Wins

Run ng build and scan the CLI output for new chunks like defer-heavy-chart.js—that's your proof the split happened. Fire up the dev server, hit the Network tab in Chrome DevTools, and watch lazy loads kick in on triggers; no extra bundle until viewport or click, confirming a leaner main payload. Pro tip: Test with TestBed.deferBlockBehavior = DeferBlockBehavior.Manual for unit tests simulating states.

Real-World Starter: Dashboard Magic

Wrap a data-heavy dashboard widget in @defer (on viewport; prefetch on idle) { <analytics-widget /> } @placeholder (minimum 500ms) { <chart-skeleton /> } and watch your bundle shrink by 30% or more on complex pages—perfect for below-the-fold metrics that users scroll to. This combo preloads smartly without bloating initial load, delivering buttery-smooth experiences for managers eyeing KPIs without waiting forever.

Core Triggers and Sub-Blocks

Angular’s @defer blocks shine with built-in triggers like idle (default, fires on browser idle via requestIdleCallback), viewport (loads on scroll into view using Intersection Observer), interaction (triggers on click or keydown), hover (on mouseover or focusin), immediate (right after non-deferred content renders), and timer (after specified ms or s). These use the on keyword and support multiple via semicolons as OR conditions, decoupling prefetch from display for smarter loading.

Prefetching adds punch — load code early with prefetch on idle (default) or others, separated by semicolon from main trigger, so resources wait ready without instant render. Picture an e-commerce dashboard: prefetch heavy charts on viewport entry, but show only on "View Analytics" button click—users get instant charts without upfront bloat.

Sub-Blocks for Seamless UX

@placeholder shows initial eagerly-loaded content (keep it lightweight—no heavy deps), with minimum 500ms to dodge flicker on fast networks; it's required for some triggers like viewport needing a single root. @loading kicks in post-trigger (replacing placeholder), eagerly loaded too, with after 100ms; minimum 1s params to time it right—wait before show, ensure min display.

@error handles fetch fails gracefully, also eagerly loaded for quick fallback display. Wrap in aria-live="polite" for screen reader announcements during swaps.

Custom Triggers with `when`

For bespoke logic, when takes signals or expressions like @defer (when isVisible())—one-time truthy check, no revert. Combine with prefetch: @defer (when userClicked(); prefetch when dataReady) for total control. In dashboards, signal on data fetch complete triggers charts post-interaction.

Advanced Patterns and Optimization

Mastering @defer goes beyond basics—it's about smart strategies that squeeze every millisecond from your app's performance. Think of it like a traffic controller for your JavaScript bundles: directing heavy loads only when needed, avoiding pile-ups that slow everything down. Let's dive into pro techniques that deliver real-world wins.

Nested @defer and Cascading Avoidance

Nested @defer blocks let you layer lazy loading for complex UIs, but stack them wrong and you trigger cascading requests—multiple bundles firing simultaneously, tanking load times. The fix? Stagger triggers: use viewport for outer blocks and interaction for inners. Combine with @if for post-load toggling, like hiding loaded content until a condition flips true. This keeps your LCP snappy while giving granular control.

@defer (on viewport) {
  @defer (on interaction) {
    <heavy-chart />
  } @placeholder {
    <div>Click to expand</div>
  }
} @placeholder {
  <section>Scroll to see more</section>
}
@if (isExpanded) {
  <summary-panel />
}

SSR/SSG and Hydration Magic

In SSR or SSG, servers render @placeholder content (or nothing), skipping triggers since there's no viewport or idle state. Client-side, hydration kicks in, firing your configured triggers to make it interactive. Enable Incremental Hydration with hydrate on triggers for server-rendered main content—perfect for SEO without bloating client bundles. Pro tip: pair prefetch on idle to preload before hydration.

Bundle Analysis and HMR Pitfalls

Quantify @defer wins with source-map-explorer: install via npm i -D source-map-explorer, build with ng build --source-map, then run npx source-map-explorer dist/**/main.js for interactive treemaps showing chunk breakdowns. You'll see main bundles shrink as heavy standalone components split off—more accurate for Angular than alternatives. Watch for HMR gotchas—development servers eager-load all @defer chunks, ignoring triggers; disable with ng serve --no-hmr for accurate testing. Pitfall avoided, gains measured.

Accessibility with ARIA Live Regions

Screen readers miss @defer swaps—users hear placeholders but not loaded content. Wrap blocks in aria-live="polite" aria-atomic="true" divs to announce transitions automatically. This keeps deferred UIs inclusive without extra JS, ensuring managers love the perf and the ethics.

<div aria-live="polite" aria-atomic="true">
  @defer (on hover) { <user-profile /> }
  @placeholder { Loading profile... }
</div>

Real-World Case Study

One team slashed a 2MB Angular app into granular @defer splits: charts on viewport, analytics on interaction. Result? Production LCP under 2s, CWV scores soaring. They measured with bundle analyzer, staggered nests, and added ARIA—proving @defer scales from dashboards to enterprise dashboards.

Key Takeaways

@defer blocks deliver template-level code splitting through smart triggers like viewport, interaction, and idle, automatically creating separate JS chunks for standalone components, directives, and pipes — slashing initial bundle sizes and boosting Core Web Vitals such as LCP by up to 20–50% in real-world apps when paired with standalones.

This isn’t just theory: developers report main bundles dropping significantly (e.g., heavy chart components or third-party libs deferred until needed), leading to faster TTI and smoother user experiences without complex routing setups.

Unlike simple @if hiding — which still downloads everything — @defer truly lazy-loads, prefetching on demand while handling placeholders, loading spinners, and errors gracefully.

Your support helps me create more practical guides and tools tailored for the frontend and startup community.

Let’s keep building together 🚀

Building a Modern Web Infrastructure with DigitalPlat and Cloudflare

Gouranga Das Samrat — Sat, 04 Apr 2026 12:18:45 +0000

As a developer, having a personal domain and a solid infrastructure is essential for showcasing projects and building a professional brand. In this post, I will share how I managed to set up my web ecosystem using DigitalPlat FreeDomains and Cloudflare.

🌟 Project Credit & Reference

This project uses DigitalPlat FreeDomain, an open domain infrastructure maintained by Edward Hsing. Built on DigitalPlat FreeDomain for domain provisioning, with credit to the platform and its maintainer for supporting global developers.

Why DigitalPlat?

DigitalPlat provides a robust, open-domain infrastructure that is perfect for builders and creators. I am currently using several subdomains like gouranga.qzz.io and samrat.qzz.io to host my portfolio and development environments. The platform's commitment to providing free infrastructure for public-interest projects is truly commendable.

My Tech Stack

To keep my projects fast, secure, and professional, I use the following tools:

Domain Provider: DigitalPlat FreeDomains (Maintained by Edward Hsing).

DNS & Security: Cloudflare (For SSL, DDoS protection, and CDN).

Hosting: GitHub Pages / Vercel (Integrated with my custom subdomains).

Email: Cloudflare Email Routing (To receive professional emails like contact@samrat.qzz.io). ## Step-by-Step Setup ### 1. Registering the Domain I chose a name that reflects my identity, Gouranga Das Samrat. DigitalPlat makes the registration process seamless. I simply picked a suffix (like .qzz.io) and pointed it to my nameservers. ### 2. Connecting to Cloudflare Cloudflare is the backbone of my site's performance. By changing the nameservers in the DigitalPlat dashboard to Cloudflare's servers (e.g., ezra.ns.cloudflare.com and frida.ns.cloudflare.com), I gained full control over my DNS records, including A, CNAME, and MX records. ### 3. Implementing Email Routing One of the coolest features I use is Cloudflare Email Routing. It allows me to create custom email addresses for each of my domains without needing a dedicated mail server, redirecting everything to my personal Gmail. ## Current Progress & Future Plans Currently, my main domain gouranga.qzz.io has reached over 2,000 unique visitors, which is an incredible milestone! Moving forward, I plan to:

Launch a dedicated tech blog at gdsamrat.qzz.io.

Set up a staging environment for my JavaScript projects at dev.gouranga.org.

Document more about the DigitalPlat infrastructure to help fellow developers in Bangladesh. ## Conclusion DigitalPlat is more than just a free domain provider; it's a gateway for developers in regions like Bangladesh to access world-class infrastructure for free. Special thanks to Edward Hsing and the DigitalPlat team for their continuous support of the creator community! Published by **Gouranga Das Samrat** Visit my site: gouranga.qzz.io

🔥 Top Mistakes Developers Make While Applying for Jobs (And How to Fix Them)

Gouranga Das Samrat — Sun, 29 Mar 2026 14:00:00 +0000

A Practical Guide to Standing Out in the Ultra-Competitive Tech Job Market in 2025

The tech job market in 2025 is more competitive than ever. With thousands of developers applying for the same roles, many rejections happen before a recruiter even reads your resume. Not because you lack skills — but because small, avoidable mistakes weaken your application.

Here are the most common job-application mistakes developers make — and exactly how to fix them.

❌ 1. Using the Same Resume for Every Job

Many developers create a single resume and use it everywhere — startups, MNCs, product companies, remote roles.
But every company is looking for something different.

✅ How to Fix It

Tailor your resume to the job description:

Add relevant keywords from the JD
Highlight matching skills and tools
Move the most relevant projects to the top
Remove irrelevant experience

Customizing your resume increases your chances of clearing ATS and impressing recruiters.

❌ 2. Writing Weak or Vague Project Descriptions

A line like:
_**“Built a food delivery app using MERN.”**
…does nothing to help you stand out._

Recruiters want clarity — what exactly did you do? What problem did you solve? What impact did it create?

✅ How to Fix It

Use the Action + Impact formula.
Example:

_“Developed a MERN-based food delivery platform with real-time order tracking, reducing average delivery time by 20%.”
_This immediately shows your contribution, skill, and measurable value.

❌ 3. Ignoring Achievements and Metrics

Most resumes read like job descriptions:
“Worked on frontend UI. Integrated APIs. Wrote backend services.”

Get Richa Gautam 🌷’s stories in your inbox

Join Medium for free to get updates from this writer.

But companies hire people who deliver results, not tasks.

✅ How to Fix It

Add numbers and measurable outcomes:

Increased user sign-ups by 25%
Improved website performance by 40%
Automated testing saved 6+ hours per week
Reduced customer complaints by 15%

Metrics instantly make your resume more credible and memorable.

❌ 4. Having an Inactive GitHub or LinkedIn

Recruiters almost always check your online presence.
An empty GitHub or outdated LinkedIn creates the impression that you’ve stopped learning.

✅ How to Fix It

Keep your digital presence alive:

Update your pinned repositories
Add a short, clear “About” section
Post weekly insights, project updates, or coding learnings on LinkedIn

Consistency shows curiosity — one of the most valued traits in tech teams.

❌ 5. Never Following Up After Applying

Many developers apply once and wait.
Your email may simply get buried — not rejected.

✅ How to Fix It

Send a polite follow-up after 3–5 days:

“Hi [Name], just following up on my application for [Role].
I’m genuinely excited about the opportunity at [Company] and would love to discuss how my experience aligns with your needs.”

This small gesture dramatically increases your chances of getting noticed.

⚙️ Bonus: Underestimating the Power of Personal Branding

In 2025, your resume is just one piece of your professional identity.
Recruiters also look at:

Your portfolio
Your GitHub
Your LinkedIn posts
Your side projects
Your problem-solving approach

✅ How to Fix It

Show your learning journey:

Share mini-projects
Write about debugging problems
Post your coding insights
Document your growth

Personal branding builds trust even before the interview begins.

🚀 Final Thoughts

Your technical skills matter — but how you present them matters even more.
A few intentional changes to your resume, project descriptions, and online presence can drastically improve your job search results.

Start today.
You’ll see the difference within a week.

🙏 Stay Connected!

🔔 Follow for more guides on JavaScript, React.js & interview prep.

**_Thankyou! for reading my article.

DEV Community: Gouranga Das Samrat

The PACELC Theorem — in a few words

Setting up the stage

Maximizing consistency

Minimizing latency

The trade-off

Finally, the PACELC theorem

VS Code on Your Phone — Yes, It Actually Works 🔥

🤔 Why Doesn't It Just Work Out of the Box?

Part 1 — Make Code-OSS Feel Like the Real VS Code

Unlock the Official VS Marketplace

Part 2 — Fix Language Servers That Don't Work

🦀 Rust — rust-analyzer

🌙 Lua — lua-language-server

🐛 CodeLLDB — Native Debugger for Rust & C++

🔍 Troubleshooting — When Things Still Don't Work

💡 Quick Recap

📁 All Configs Live in the Dotfiles Repo

🏁 You Now Have a Real Dev Environment on Android

Test coverage and what it can tell us

Deceiving coverage

Digging deeper

Conclusion and a few thoughts

Turn Your Android Into a Full Desktop — No Root Needed 🚀

🧠 What You'll End Up With

🛠️ What You Need Before Starting

📦 Step 1 — Grant Storage & Update Termux

🔧 Step 2 — Install the Desktop Stack

📥 Step 3 — Clone the Dotfiles Repo

🚀 Step 4 — Set Up the Startup Script

🖥️ Step 5 — Launch Your Desktop!

⌨️ Keyboard Shortcuts Worth Memorising

🐧 Bonus: Add a Full Debian Container (Optional but Awesome)

🎨 Personalise Your Setup

Change the Termux Welcome Message

Configure GPG for Git Signing

🔁 Every Time You Want to Start the Desktop

🤔 Why XFCE4?

💡 Pro Tips

📁 Everything Is in the Dotfiles Repo

🏁 Final Thoughts

How to Use Micro Frontends Without Regretting It

From Monolith Mess to MFE Freedom

Micro Frontends Flip the Script

The Real Hook (and Headache)

When Micro Frontends Actually Make Sense (And When They Don’t)

Spot the Chaos: Team Size Signals

Nx Lifesaver: Skip MFEs Early

Velocity Gold vs. Hidden Traps

E-Commerce Escape: Real Deploy Magic

Micro-Frontends Made Easy: Angular’s Native Federation Revolution

Why Ditch the Old Ways?

Setup That Feels Like Magic

The Singleton Superpower Unleashed

Lazy-Load Like a Pro

Your App, Future-Proofed

Avoiding Pitfalls and Regrets in Angular Micro Frontends

Dodge the Performance Brick Wall

Banish UI Frankenstein Nightmares

Tame the State and Routing Beasts

Slash 50% Off Feature Delivery Time

Best Practices for Micro-Frontend Success

Start Small, Win Big

Ditch Props, Master Events

Test Smart, Deploy Fearless

Ksolves: 35% Faster Loads

Ready to Scale Smart?

The Power Trio: Key Takeaways

Hands-On: Build Your Pilot

I Spent Months Perfecting My Dotfiles So You Don't Have To — Here's Everything Inside

⚡ The Bootstrap: One Command, Full Environment

🐚 The Shell: Nothing Is Left Unquestioned

core/

user/aliases.zsh

🔧 user/overrides.zsh: mkdir and rm Reimagined

mkdir — Git-aware directory creation

rm — Confirm before you destroy

🔌 plugins/fzf.zsh: fzf Done Properly

📡 functions/ — Custom Commands Written From Scratch

apireq — A Full API Client in Your Terminal

🔧 user/overrides.zsh: `mkdir` and `rm` Reimagined

`mkdir` — Git-aware directory creation

`rm` — Confirm before you destroy

`apireq` — A Full API Client in Your Terminal

`archive.zsh` — Universal Pack/Unpack

`network.zsh` — Three Genuinely Useful Web Commands

`utils.zsh` — The Everyday Toolkit

`security.zsh` — Auto-Locking GPG

`whois.zsh` — Filtered WHOIS Lookup

`chpwd.zsh` — Smart Directory Change Hooks

`plugins/pass.zsh` — Encrypted Secret Management