I installed Python 3.12 for a project and pointed /usr/bin/python3 to it, instead of using a virtual environment. Everything worked fine at first. A few days later, add-apt-repository failed with:

ModuleNotFoundError: No module named 'apt_pkg'

Why it happened

/usr/bin/python3 is not just a developer shortcut. Ubuntu uses it to run several of its own tools, including add-apt-repository, unattended-upgrades, and apport. These are Python scripts, and some of them depend on compiled Python modules built specifically for the Python version Ubuntu ships with, which was 3.10, not 3.12.

Once /usr/bin/python3 pointed at 3.12, these tools were running on an interpreter their compiled modules were never built for. Python looked for a module built for 3.12 and found nothing, because no such module existed.

The culprit

Installing Python 3.12 alongside the system Python was never the problem. That part is completely normal, plenty of machines run several Python versions side by side without any issue.

The real culprit was /usr/bin/python3 itself, a single, shared path. Every tool on the system that calls python3 without asking for a specific version follows that same path, including Ubuntu's own package management scripts. Those scripts don't need "some" Python 3, they need the exact one their compiled modules were built against. There's no version check before they run, so the moment /usr/bin/python3 changed, every one of those tools was quietly pointed at an interpreter it was never built for, and it stayed that way until one of them happened to run.

The fix

Keep the system Python untouched, and give the project its own environment instead:

sudo update-alternatives --set python3 /usr/bin/python3.10
python3.12 -m venv .venv
source .venv/bin/activate

This restores apt's original interpreter and gives the project Python 3.12 inside its own virtual environment. The OS manages its own dependencies, the project manages its own, and neither one has to interfere with the other.

Here's how that works.

It's Not Reading. It's Translating.

AI doesn't "understand" English the way you do. It can't. Instead, it converts words into vectors — lists of numbers that encode meaning mathematically. Words that mean similar things end up with similar numbers. Words that have nothing in common don't.

💡 Core idea: Every word you send to an AI becomes a point in a giant mathematical space. Meaning = position.

What Are Embeddings?

An embedding is that numerical representation — the set of numbers a word gets mapped to.

"King" and "Queen" end up numerically close to each other. "King" and "Laptop" don't. Nobody told the AI this. It figured it out on its own, by reading vast amounts of text and noticing which words kept showing up in similar situations.

The 3-Step Journey

Step 1 — Tokenization

Before any math happens, the text gets broken into tokens — small, digestible pieces the model can work with.

It's a small step, but an important one. By splitting unfamiliar words into known pieces, the model makes sure nothing is ever truly unreadable.

Step 2 — Vectorization

Once tokenized, each piece gets a unique address in meaning-space:

King  → [0.25,  0.51, -0.12, 0.88, ...]
Queen → [0.24,  0.49, -0.15, 0.82, ...]
Apple → [0.91, -0.33,  0.55, 0.01, ...]

Look at King and Queen — nearly identical values. Apple is somewhere completely different. Nobody hardcoded this. The model learned it purely from patterns in billions of sentences. That's also how it works out that "car" and "automobile" mean the same thing, or that "happy" sits on the opposite end of the spectrum from "sad." No one had to spell it out.

Step 3 — Contextualization

Here's where it gets interesting. The same word can mean completely different things — and the model has to figure out which one you meant.

Older AI gave every word one fixed meaning, no matter what. Modern models like BERT and GPT do something smarter — they generate a different vector each time, shaped by the words around it. The word "bank" in a fishing story is not the same "bank" as in a finance article. Context changes everything.

Why Embeddings Are AI's Superpower

The Takeaway

Every time AI processes text, three things happen:

1. Tokenize — break text into manageable units

2. Vectorize — map each unit to a position in meaning-space

3. Contextualize — shift that position based on surrounding words

What you get is a mathematical map of language. Meaning has coordinates. Relationships have distances. And "understanding" turns out to be a geometry problem.

It's a very different kind of reading. But it works.

This post breaks it all down — clearly, practically, and without the hype.

The Problem With Simple Search

Most of us started with keyword search. Type a word, scan for matches. It works fine until it doesn't.

Keyword search (like BM25 or TF-IDF) is purely lexical — it matches exact words or tokens, nothing more. Ask it for "automobile" when your docs say "car" and it comes back empty-handed. Ask it "dog bites man" and it'll happily treat that as identical to "man bites dog." It has no concept of meaning.

That's where semantic search comes in.

Semantic Search: Meaning Over Words

Semantic search converts text into embeddings — high-dimensional vectors that represent meaning. Instead of comparing words, you're comparing concepts.

Ask "Who wrote Dubious Parenting Tips?" and it can match "Lisa Melton wrote Dubious Parenting Tips" even though your query said "author," not "wrote." It understands they mean the same thing.

Under the hood, similarity is measured with:

• Cosine similarity — measures the angle between two vectors. Small angle = high similarity. This is the most common choice.

• Dot product — similar to cosine but sensitive to vector magnitude.

• Euclidean / Manhattan distance — measures raw distance in vector space.

Cosine similarity is particularly powerful because meaning is about direction, not magnitude. Two sentences can be phrased very differently but point in the same conceptual direction.

BM25 vs. Cosine Similarity — When to Use Which

This is where most tutorials gloss over the important stuff. Let's be direct:

BM25 answers: "How important is this word across all documents?" It balances three things:

1. How rare the word is across the whole corpus (IDF)

2. How often it appears in a specific document (TF)

3. Document length normalization (so shorter docs aren't unfairly penalized)

Cosine similarity doesn't care about exact words at all. "I want Italian food" and "pizza, pasta, risotto" can be very close in vector space even with zero word overlap.

The practical takeaway: neither is universally better. They're tools for different jobs.

Hybrid Search: The Real-World Architecture

Here's something most tutorials don't tell you — you can't pick a fixed 50/50 weight between keyword and vector search and expect it to work well across all query types.

Consider a product catalog with an item titled "Apple MacBook Pro 16-inch M3 Max" with SKU MBP-M3MAX-32-1TB.

A well-designed hybrid system looks like this:

User Query  
↓  
Query Parser  
↓  
BM25 (Keyword Search) + Vector Search (Semantic Search)  
↓  
Merge & Re-rank  
↓  
Top-K Retrieved Documents  
↓  
LLM (RAG)  
↓  
Final Answer

The smart part is the query classifier — detecting whether a query is a product code, a natural language question, or something in between, and adjusting weights accordingly.

When NOT to Use Vector Search

This is the section nobody writes, but it's arguably the most useful one.

Vector search is powerful, but it's genuinely the wrong tool in several common situations:

1. Exact IDs, codes, and SKUs Queries like Order A9F-3321 or Error code E042 need exact matching. Embeddings blur meaning — A9F-3321 and A9F-3322 may look nearly identical in vector space. Use BM25 or a database query instead.

2. Structured / filtered queries price < 100 AND color = red AND size = M is a database problem, not a search problem. Vectors don't reliably understand logical operators. Use SQL or faceted filters.

3. Short, ambiguous queries python, apple, jaguar — what does the embedding even represent here? A programming language? A fruit? A car brand? Vector search will guess, and it may guess wrong. Add query expansion, hybrid search, or clarifying prompts.

4. Real-time or frequently changing data Vector search retrieves what was indexed at embedding time. "Current Tesla stock price" or "today's weather" need live APIs, not a vector DB.

5. When ranking must be explainable In legal or compliance contexts, you need to answer "why did this document rank first?" Vector similarity doesn't give you a clean answer beyond "the distance was smaller." Use keyword scoring or rule-based systems where auditing matters.

6. Exact phrasing or legal clauses When you need FIND documents containing this exact sentence, embeddings intentionally lose exact phrasing. Use regex or exact text search.

7. Very small datasets 20–100 documents? Similarity scores get noisy and unreliable at tiny scale. A simple keyword search or even a manual review is often better.

8. Domain-specific jargon with no embedding coverage Internal acronyms, niche medical terms, company-specific concepts — generic embedding models don't "know" your private language. You'll need domain-specific embeddings, fine-tuning, or hybrid search with reranking.

The Takeaway

Search in the age of AI isn't one thing. It's a spectrum:

• Keyword search for precision — codes, names, exact terms

• Vector search for meaning — concepts, questions, natural language

• Hybrid search for the real world — because queries don't fit neatly into one box

Understanding when to reach for each tool is what separates developers who can use AI APIs from those who can architect AI systems.

That's a distinction worth making.

Indexes are one of those magical database features that can make your app feel lightning-fast—until they don't. Let's break down what's really happening under the hood.

What Exactly Is an Index?

Think of a database index like the index at the back of a textbook. Instead of flipping through every page to find "Binary Search Trees," you check the index, which tells you exactly where to look.

A database index contains three key pieces:

1. Copies of the indexed column values (sorted for quick searching)

2. Pointers to the actual row locations in the main table

3. Metadata for maintaining the index structure (B-tree nodes, etc.)

Here's what happens under the hood:

The index stores a sorted copy of the email column along with pointers back to the full records. Indexes typically use B-tree structures (balanced tree structures that keep data sorted and allow searches, inserts, and deletes in logarithmic time) to maintain this sorted order efficiently.

The Write Performance Hit (And Why It Happens)

Here's the painful truth: every index you create slows down writes.

Why? Because of Redundancy.

When you insert, update, or delete data, the database doesn't just modify the main table—it has to update every single index that references the affected columns.

Real-World Impact: The Numbers Don't Lie

Let's say you're building an e-commerce platform and need to bulk-import 1 million products:

• Without indexes: ~10-15 seconds

• With 3-4 indexes: ~120 seconds (8x slower!)

Indexes can make bulk writes dramatically slower.

When Indexes Shine: The Read Performance Boost

Now for the good news: indexes make reads incredibly fast.

Real-World Scenario: Social Media Feed

Imagine you're building a Twitter-like app with a posts table:

CREATE TABLE posts (
    id INT PRIMARY KEY,
    user_id INT,
    content TEXT,
    created_at TIMESTAMP,
    likes_count INT
);

-- Create composite index
CREATE INDEX idx_user_created ON posts (user_id, created_at);

Without the index, finding a user's recent posts means:

• Scanning every single row in the table (1 billion posts?)

• Checking if user_id matches

• Sorting by created_at

• Performance: O(n) — gets slower as your table grows

With the index, the database:

• Jumps directly to the user's posts using the sorted index

• Already sorted by created_at (thanks to index ordering!)

• Returns results in milliseconds

• Performance: O(log n) — barely affected by table size

The Catch: Column Order Matters

Here's where it gets tricky. The order of columns in a composite index determines which queries can use it efficiently.

Consider these two indexes:

-- Index 1
CREATE INDEX idx_price_category ON products (price, category);

-- Index 2
CREATE INDEX idx_category_price ON products (category, price);

Now run this query:

SELECT * FROM products 
WHERE category = 'Electronics' 
AND price BETWEEN 100 AND 500;

Index 1 (price, category): The database can't efficiently use this because the query doesn't filter by price first (the leading column). It might skip the index entirely.

Index 2 (category, price): Perfect! The database jumps to 'Electronics' in the index, then scans the price range. Fast and efficient.

Rule of thumb: Queries benefit from an index only when they use the leading columns (left to right) in the index definition.

Building Better Indexes: Practical Guidelines

Column Ordering Strategy

When creating a multi-column index, prioritize columns in this order:

1. Equality filters first (WHERE status = 'active')

2. Range filters second (WHERE price BETWEEN 100 AND 500)

3. Sort columns last (ORDER BY created_at)

E-commerce example:

-- Optimize for: WHERE category='Electronics' AND price < 1000 ORDER BY rating DESC
CREATE INDEX idx_products ON products (
    category,    -- Equality filter (most selective)
    price,       -- Range filter
    rating       -- Sort order
);

The Partial Index Update Rule

Here's a performance win many developers miss: only indexes containing modified columns need updating.

CREATE TABLE users (
    id INT PRIMARY KEY,
    email VARCHAR(255),
    last_login TIMESTAMP,
    settings JSON
);

CREATE INDEX idx_email ON users (email);

When you run:

UPDATE users SET last_login = NOW() WHERE id = 123;

The idx_email index doesn't get updated because email wasn't modified. This is why strategic column selection in indexes matters—you're not just optimizing reads, you're minimizing write overhead.

The Decision Framework: Your Takeaway Checklist

Create an Index When:

• You have a read-heavy workload (80%+ reads)

• Queries on specific columns are consistently slow

• The table has \>10,000 rows and growing

• Columns have high cardinality (many unique values)

• You're filtering/joining on the same columns repeatedly

Think Twice When:

• Table size is < 1,000 rows (table scans are faster)

• Write operations dominate your workload (>70% writes)

• You already have 5+ indexes on the table (diminishing returns)

• Indexing low-cardinality columns (few unique values)

• Storage constraints are tight

Red Flags (Don't Index):

• Columns that are rarely queried

• Columns with frequent updates but rare reads

• Boolean/status flags without additional composite columns

• Already covered by existing composite indexes

Action Items:

1. Audit your slowest queries (use EXPLAIN or query logs)

2. Check existing indexes: Are they actually being used?

3. Remove unused indexes: They cost you on every write

4. Test before deploying: Benchmark write performance with new indexes

5. Monitor index sizes: Set up alerts for storage growth

The Bottom Line

Indexes are a deliberate trade-off: you sacrifice write speed for dramatically faster reads. Start with your slowest queries, add indexes strategically, and always measure the impact on both reads and writes.

Understanding Windows Environment Variables

Before diving into the installer creation process, it's important to understand how Windows handles environment variables:

1. Environment variables in Windows can be set for the current user (HKCU) or local machine (HKLM).

2. These variables are stored in the Windows Registry Editor.

3. The paths for environment variables are:

   • For local machine: Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment

   • For current user: Computer\HKEY_CURRENT_USER\Environment

When working with 32-bit and 64-bit systems, it's crucial to use the correct registry keys. For example, HKLM64 maps to the 64-bit view of the registry, while HKLM32 maps to the 32-bit view.

Steps to Create a Windows Installer

1. Prepare Your Node.js Application

Ensure your Node.js application is ready for deployment. This includes:

• Having a package.json file with all necessary dependencies.

• Creating a main entry point for your application (e.g., app.js or index.js).

• Testing your application thoroughly on Windows.

2. Install Inno Setup

Download and install Inno Setup from the official website: Inno Setup

3. Create an Inno Setup Script

Create a new file with a .iss extension (e.g., myapp-installer.iss). This script will define how your installer behaves. Here's a basic template:

[Setup]
AppName=My Node.js App
AppVersion=1.0
DefaultDirName={pf}\MyNodeApp
DefaultGroupName=My Node.js App
OutputDir=installer
OutputBaseFilename=myapp-setup

[Files]
Source: "path\to\your\app\*"; DestDir: "{app}"; Flags: recursesubdirs

[Run]
Filename: "{app}\node.exe"; Parameters: "{app}\app.js"; Flags: runhidden

[Registry]
Root: HKLM; Subkey: "SYSTEM\CurrentControlSet\Control\Session Manager\Environment"; ValueType: expandsz; ValueName: "MY_APP_HOME"; ValueData: "{app}"; Flags: preservestringtype

4. Customize the Installer

Depending on your application's needs, you may want to:

• Create a Windows service using NSSM (Non-Sucking Service Manager).

• Set up environment variables.

• Include additional files like Node.js runtime, npm packages, or other dependencies.

5. Handle 32-bit and 64-bit Architectures

To support both 32-bit and 64-bit Windows systems, you'll need to:

• Include both 32-bit and 64-bit versions of Node.js and any native dependencies.

• Use conditional statements in your Inno Setup script to choose the correct files based on the system architecture.

6. Implement Logging

For easier troubleshooting, implement logging in both your Node.js application and the installer:

• Use a logging library like Winston for your Node.js app.

• Utilize Inno Setup's built-in logging capabilities for the installation process.

By following these steps and best practices, you can create a Windows installer for your Node.js application. This will make it easier for users to install and use your software, ultimately leading to better adoption and user satisfaction.

In this blog, we will explore the popular log parsing commands - grep, awk, and sed, and discuss how to choose the right tool based on your specific requirements.

Types of Commands

Grep

grep (Global Regular Expression Print) is a powerful search utility used for finding patterns within text files.

Awk

awk is a versatile programming language designed for text processing and data extraction.

Sed

sed (Stream Editor) is used for parsing and transforming text streams.

Key Considerations for Choosing the Right Log Parsing Tool:

• Size of the Dataset: Large datasets require efficient tools to minimize processing time and resource usage.

• Complexity of Parsing: Choose a tool that matches the complexity of the parsing and extraction tasks.

• Infrastructure Available: Ensure the tool can run efficiently on your available infrastructure and within any resource constraints.

• Performance Metrics: Evaluate execution time, CPU usage, memory usage, I/O performance, and scalability.

When to Use Grep, Awk, and Sed

Grep

• Best For: Simple text searches and filtering lines based on patterns.

• Performance: Fastest for simple searches with low CPU and memory usage.

Awk

• Best For: Complex pattern matching, data extraction, and text manipulation and calculation.

• Performance: Efficient for advanced text processing but slightly slower than grep for basic tasks.

Sed

• Best For: Stream editing and simple text transformations.

• Performance: Similar to grep for simple tasks, but less intuitive for complex parsing compared to awk.

Usage of Grep, Awk, and Sed Commands

Grep

# Find all lines containing "ERROR"
grep "ERROR" application.log

Awk

# Extract and print the second field from lines containing "ERROR"
awk '/ERROR/ {print $2}' application.log

Sed

# Replace all occurrences of "ERROR" with "WARNING"
sed 's/ERROR/WARNING/g' application.log

Practical Example: Using Awk vs Grep

Scenario: Extracting Fields from a Log File

Log File Example:

192.168.1.1 - - [12/Mar/2023:14:21:14 -0700] "GET /index.html HTTP/1.1" 200 2326
192.168.1.2 - - [12/Mar/2023:14:22:01 -0700] "POST /login HTTP/1.1" 403 534
192.168.1.3 - - [12/Mar/2023:14:23:08 -0700] "GET /images/logo.png HTTP/1.1" 200 456

Objective: Extract the IP address and the status code from each log entry.

Using Grep

# Grep cannot directly extract fields; we need to use additional tools like cut or awk.
grep "ERROR" access.log | awk '{print $1, $9}'

Using Awk

# Extract and print the first (IP address) and ninth (status code) fields
awk '{print $1, $9}' access.log

Conclusion

Choosing the right log parsing tool depends on your specific needs and the complexity of the tasks at hand. grep is ideal for simple searches, awk excels in complex data extraction and manipulation, and sed is powerful for stream editing and transformations.

Additionally, tools like Logstash, Splunk, and Elasticsearch offer high scalability and performance for handling large datasets(tens of gigabytes to terabytes), organizations need to consider the associated infrastructure and resource requirements as part of their deployment strategy.

Happy log parsing!

Credits: Bytebytego

Importance of package-lock.json

In Node when your code references library A, that library references library B and that in turn references Library C. Running npm install will install the latest version available of those dependencies (as long as no particular version is specified).

Upon installation, a new file is created called package-lock.json with the exact versions.

A new machine pulls the repo and runs npm install, if we didn’t have the package-lock.json the machine may pull the newer version of libraries and as a result possibly that your code no longer works are very high.

If package-lock.json exists in the repo, the npm install command will install the dependencies of same version as present in original repo, and as a result making the code consistent.

Always commit package.json and package-lock.json file along side of it.
In build,prod environment use npm ci for continuos integration and deployment workflows.

Managing dependencies

To manage npm dependency issues on repositories, it's advisable to use Renovate, Dependabot, Snyk

Dependabot provides automated dependency upgrades for software repositories. Users can receive automated reports of new security vulnerabilities in their repo's dependencies.

Renovate is an open-source tool that automatically creates pull requests for all types of dependency updates. It offers real-time scanning, annotated updates, and verification against existing tests to avoid regression errors.

Snyk is a developer-first cloud-native security tool that covers multiple areas of application security, including open source, application code, container, and infrastructure as code security. Snyk CLI can be authorized in the CI/CD programatically to use Snyk for npm dependency security vulnerabilities

References

• ten npm security best practices (snyk.io)

• https://ghumare64.medium.com/managing-dependencies-are-the-issue-c0ab844c05e0

• https://twitter.com/hnasr/status/1728755651659079980

What is Clustering?

Clustering allows Node.js applications to spawn multiple child processes (workers) to handle incoming requests. This allows the workload to be distributed across multiple CPU cores, improving performance and concurrency.

How Clustering Works

Here's a quick overview of how clustering works:

1. Create a Cluster

Use the built-incluster module and check if the current process is a master or worker. The master process manages the workers.

const cluster = require('cluster');

if(cluster.isMaster) {
  // fork workers
} else {
  // worker processes
}

2. Fork Worker Processes

The master process can fork multiple worker processes using cluster.fork() to utilize multiple CPU cores.

for(let i = 0; i < numCPUs; i++) {
  cluster.fork(); 
}

3. Distribute Requests

The master process listens for connections and distributes incoming requests among the workers in a round-robin fashion.

4. Handle the worker lifecycle

If a worker dies, the cluster module allows the master process to fork a new worker to replace it for high availability.

Key Benefits

• Improved performance through better utilization of CPU cores

• Increased capacity to handle more concurrent requests

• High availability through graceful handling of worker failures

By implementing clustering, Node.js apps can scale a lot better across multi-core systems. Give it a try!

In Node.js, there are several methods for scheduling callbacks:

• Timers (setTimeout(), setInterval())

• Promises

• setImmediate()

• process.nextTick()

• I/O events (actions involving reading from or writing to external resources such as files, network sockets, or other I/O operations)

Let's understand using an example:

console.log('Start');

process.nextTick(() => {
  console.log('process.nextTick callback');
});

Promise.resolve().then(() => {
  console.log('Promise microtask');
});

setTimeout(() => {
  console.log('setTimeout1 callback');
}, 0);

setTimeout(() => {
  console.log('setTimeout2 callback');
}, 100);

setImmediate(() => {
  console.log('setImmediate callback');
});

console.log('End');

The output will be:

Start
End
process.nextTick callback
Promise microtask
setTimeout1 callback
setImmediate callback
setTimeout2 callback

• Start and End are printed first because they are non-blocking (synchronous) operations

• Both process.nextTick() and Promises are executed at the end of the current event loop cycle, but process.nextTick() has a higher priority than promises. Therefore, theprocess.nextTick() callback is executed first, followed by the Promise microtask.

• ThesetTimeout1 callback is scheduled in the timer phase of the event loop. Even though the specified delay is 0 milliseconds, it still goes through the timer phase

• The setImmediatecallback is executed after the I/O phase of the event loop. It runs after I/O events but before the timers.

• At last, the setTimeout callback is called at last because it has a delay of 100 milliseconds

Conclusion: The priority order can be considered as follows:

1. Non-blocking operations

2. process.nextTick()

3. Promises

After this, the priority is: In a non-I/O loop, the execution order is setTimeout() > setImmediate(). In an I/O loop, the execution order is setImmediate() > setTimeout()

Here is an example of an I/O loop:

const fs = require('fs');

fs.readFile(__filename, () => {
  console.log('start');

  setTimeout(() => {
    console.log('setTimeout');
  }, 0);

  setImmediate(() => {
    console.log('setImmediate');
  });

  process.nextTick(() => {
    console.log('process.nextTick');
  });
});

Output of the above would be:

start
process.nextTick
setImmediate
setTimeout

For further reading in-depth, read Node.js docs here

It was created by Linus Torvalds.

Git, SVN, and Mercurial are other VCSs used out there.

In this blog post, we will be discussing the most commonly used commands.

• git config: Configure git globally using these commands:

  • git config --global user.name [username]

  • git config --global user.email [email ID]

  • git config --global core.editor nano

    • above command sets up the default editor for git to nano; other available editors are vim, vi, etc.

• git clone: git clone https://github.com/repo_name.git clones a remote repo. onto the local machine.

• git init: Initialize a git repository inside the current directory.

• git remote: Here, the "origin" works as an alias for the repo URL in further commands.

  • git remote add origin https://github.com/repo_name.git creates a connection from the local repository to the remote repository.

  • git remote -v displays remote for push and pull

  • git remote remove origin removes remote from the current local repo.

• git status: Displays the modified, staged, and unstaged files

• git add: This command is used to move untracked files into staging area. It can be done in 2 ways:

  • git add <file1.txt> <file2.txt> This command only adds file1 and file2 and keeps other untracked files as it is, to staging area.

  • git add . the command adds all untracked files to the staging area.

• git commit: The modified files in the staging area are committed with a message.

  • Assume you made additional changes after the last commit and want to include them in the last commit. Use these commands in the following order:

    git add additional_file.txt ; git commit --amend

  • Assume you need to change the commit message
    git commit --amend -m "New commit message"

• git push: git push origin main This command pushes changes from the local 'main' branch to the 'main' branch on the 'origin' remote.

• git pull: git pull origin master This command fetches changes from the default remote repository and merges them into the current branch. It's combination of git fetch and git pull commands.

• git log: displays the log of commits in the git repository, including information such as commit hashes, authors, dates, and commit messages.When you run git log without any additional options, it uses the default pager. The pager allows you to navigate through the commit history one page at a time. The following commands help navigate commit history:

  f: next page, b: prev page, / : search, n: next match, p: prev match,q: quit

  • git log -n 5 [displays latest 5 commits]

  • git log -- <file-path> [displays commit history specifically for the given file]

  • git log --author=<user.name> [displays commits by particular developer]

  • git log --since=<date> [displays commit since, specified date: YYYY-MM-DD}]

  • git log --after=<date> [displays commit after*, specified date: YYYY-MM-DD}]*

  • git log --oneline [displays condensed output, commit hash, and message]

  • git log --grep='login' [displays only those commits whose commit messages contain the string login]

  • git log -p Command is used to display the commit history along with the corresponding patch (changes) introduced in each commit. This is useful for reviewing the detailed changes made in each commit.

The above commands can also be applied in combination as attributes.

• git cherry-pick: git cherry-pick <commit_id> merges the commit with commit-id the current local repository. This command can be used to merge a specific commit from one branch to another.

• git fetch: git fetch origin This command fetches the changes from the 'origin' remote repository, but it does not modify your working directory or merge the changes into your local branch.

• git branch: Displays all the branches (the current branch is shown with a star)

  • git branch -a [shows all remote and local branches]

  • git branch dev-prakhar [creates branch dev-prakhar]

  • git branch -d branch1 [deletes branch1]

• git checkout: Command has various purposes as branching.

  • git checkout feature1 the command used to switch to an existing branch.

  • git chekout -b feature2 this command creates a new branch and switches to it also.

  • git checkout -- myfile.txt this command discards changes in a specific file

• git stash: Saves unstaged changes to a stash, which can be later used so that you can switch branches or perform other operations without committing your changes

  • git stash save -u "[WIP] Login feature"

  • git stash list [View list of stashes]

  • git stash apply [apply the last stash]

    • git stash apply <stash-ref>[Applies a particular stash from the list]

  • git stash pop [Apply the latest stash and remove it from the stash list]

Use Gitlens vs code extension to find the difference between two branches for the same file.

The concept (AFAIK) simply means to NOT rewrite the same piece of code again and again.

Let's say, for example, you are designing schema for your database using Mongoose, and you have used key timestamps, which by default insert createdAt and updatedAt fields in every document created. (here createdAt and updatedAt fields denote the time, new data was created or updated in the database)

But a backend developer unknown of the functionality of the timestamps key might add keys - created_at and updated_at in that schema and implement a method to update the updated_at field in the database in all API routes that have update queries.

He/she won't stop there and goes on implementing the same thing in other schemas and routes, and queries related to those schemas.

Now, there are two problems which could've been avoided:

1. The developer could've reduced the lines of code if had knowledge of the timestamp field or seen its implementation in the codebase already there

2. If he/she had followed the first step, there wouldn't have been a repetition of the code to implement created_at and updated_at

The above solutions might not work all the time, the permanent solution is to read the documentation of libraries that you are using in your code. This will not only deepen your understanding but also increase your knowledge about methods that can be leveraged to reduce your code complexity and achieve a DRY approach.