DEV Community: Ritik Pal

How I Built a Production-Grade E2E Test Automation Framework for an AI Testing Product

Ritik Pal — Thu, 19 Mar 2026 13:36:58 +0000

Meta description: How one engineer built two complete E2E test automation frameworks — 61 UI specs + 192 API endpoints — for a GenAI-native test agent. Real architecture, real code, real problems solved.

Target keywords: end-to-end test automation framework, Playwright TypeScript framework, API test automation, SDET framework architecture India

Cover image suggestion: A dark-themed split-screen showing Playwright test output on the left and a CI/CD pipeline dashboard on the right. Search Unsplash: "software testing code dark theme"

When your product lets users write tests in plain English and an AI agent executes them across browsers, mobile devices, and cloud environments — how do you test that?

This is the exact problem I had to solve.

I'm Ritik Pal, Member of Technical Staff at an AI testing company — and over the past year I built two complete end-to-end test automation frameworks from scratch. One for the frontend (61 test specs, 18 feature areas). One for the backend (192 API endpoints, 32 typed clients).

Together, they form the quality backbone of the AI testing product I work on.

No hand-waving. No theory. In this article I'll walk you through the real architecture decisions, the actual code, and the hard problems that took weeks to solve.

The Problem: Who Tests the Testing Tool?

The AI testing product I work on is a GenAI-native testing agent. Teams write test cases in natural language like:

"Login with valid credentials and verify the dashboard loads correctly"

...and the agent converts that into actual automation that runs across browsers and environments. It's genuinely impressive technology.

But here's the uncomfortable question nobody asks until it's too late: who tests the testing tool?

We needed a quality layer that could:

Validate 18 different UI feature areas — projects, test cases, test runs, reports, AI agent integration, Jira integration, and more
Hit every single API endpoint (192 of them) with proper auth, retry logic, and schema validation
Run across 4 environments in parallel: US Staging, EU Staging, US Production, EU Production
Gate every PR with a smoke suite and run full regression nightly
Scale to 15 parallel workers on a cloud execution grid

Two repos. One mission. Zero existing framework to build on.

The High-Level Architecture

Before getting into the details, here's the full picture:

Frontend: E2E-Frontend-Automation

Tech Stack:  Playwright 1.49 + TypeScript 5.7 + Node 20
Pattern:     Page Object Model with custom Playwright fixtures
Tests:       61 specs across 18 feature areas
Execution:   Local → Remote (CDP Grid) → Cloud (HyperExecute)

Backend: E2E-Backend-Automation

Tech Stack:  Playwright Test + Axios + TypeScript 5.7 + AJV + Faker.js
Pattern:     Typed API clients with interceptor chain architecture
Tests:       192 endpoints, 41 test files, ~180 test cases
Tiers:       Smoke (30s) · Regression (full) · Flows (E2E) · Benchmark (latency)

Both frameworks are built on five shared principles:

Type safety everywhere — TypeScript catches breaking changes at compile time, before a single test runs
Zero boilerplate per test — fixtures handle setup and teardown automatically
Test data isolation — every test creates its own data and cleans up after itself
Multi-environment support — one environment variable switches everything
Smart retry logic — distinguishes transient failures from real bugs

Deep Dive: Frontend Framework

The 6-Layer Architecture

┌─────────────────────────────────────────────┐
│  Test Layer (61 specs, @smoke/@regression)  │
├─────────────────────────────────────────────┤
│  Fixture Layer (20 page objects + API setup)│
├─────────────────────────────────────────────┤
│  Page Object Layer (20 modules, 40 files)   │
├─────────────────────────────────────────────┤
│  API Layer (REST API + Jira clients)        │
├─────────────────────────────────────────────┤
│  Config & Utils (env, waits, retry, random) │
├─────────────────────────────────────────────┤
│  Reporting & CI/CD (4 reporters, 3 pipelines│
└─────────────────────────────────────────────┘

Each layer has one job. The test layer just tests. The fixture layer manages lifecycle. The page objects handle interactions. This separation is what keeps the framework maintainable as it grows.

BasePage: Minimal by Design

Most Page Object frameworks I've seen make the same mistake: they try to abstract away the underlying test library entirely. They wrap every Playwright method in a custom method, add unnecessary complexity, and end up with a framework that fights against the tool it's built on.

My BasePage has exactly 3 core methods:

export class BasePage {
  constructor(readonly page: Page) {}

  /**
   * Auto-detects XPath, testid, or CSS selectors.
   * Removes the "which locator type?" decision from test authors.
   */
  loc(selector: string): Locator {
    if (selector.startsWith('testid:')) {
      return this.page.getByTestId(selector.slice(7));
    }
    return selector.startsWith('/') || selector.startsWith('(')
      ? this.page.locator(`xpath=${selector}`)
      : this.page.locator(selector);
  }

  /**
   * Replace {{placeholders}} in selector strings.
   * Enables dynamic selectors without string concatenation.
   */
  tpl(selector: string, replacements: Record<string, string>): string {
    let result = selector;
    for (const [key, value] of Object.entries(replacements)) {
      result = result.replaceAll(`{{${key}}}`, value);
    }
    return result;
  }

  /**
   * Retry any action with configurable attempts and delay.
   * Used for operations that are legitimately flaky by nature.
   */
  async retry(
    action: () => Promise<void>,
    options?: { retries?: number; delayMs?: number; label?: string },
  ): Promise<void> {
    const { retries = 3, delayMs = 2_000, label = 'action' } = options ?? {};
    for (let attempt = 1; attempt <= retries; attempt++) {
      try {
        await action();
        return;
      } catch (error) {
        if (attempt === retries) throw error;
        await this.page.waitForTimeout(delayMs);
      }
    }
  }
}

The design rationale: Page objects use Playwright's native API directly. The base class adds just enough — auto-detecting locator types, template interpolation, and retry logic. Everything else stays in Playwright's hands.

The tpl method deserves a special mention. Instead of building selectors with string concatenation like '.project-' + name + '-button' (which breaks on special characters), you define a selector template once and interpolate:

// In page object selectors file
const PROJECT_BUTTON = '.project-{{name}}-action';

// In page object method
async clickProject(name: string) {
  await this.loc(this.tpl(PROJECT_BUTTON, { name })).click();
}

Clean, readable, and debuggable.

The Fixture System

This is where the real power lives. One fixture file exports everything a test needs — auth, browser context, page objects, and environment routing:

export const test = base.extend<AppFixtures>({
  page: async ({ page }, use, testInfo) => {

    // LOCAL MODE: just navigate and hand over the page
    if (process.env.TEST_MODE !== 'remote') {
      await page.goto(EnvConfig.baseUrl, { waitUntil: 'domcontentloaded' });
      await use(page);
      return;
    }

    // REMOTE MODE: per-test CDP session on remote browser grid
    const testName = testInfo.titlePath.slice(1).join(' > ');
    const wsEndpoint = getCdpEndpoint(profile, runProfile, testName);

    let browser, context, remotePage;
    for (let attempt = 1; attempt <= 2; attempt++) {
      try {
        browser = await chromium.connect(wsEndpoint);
        context = await browser.newContext({
          storageState: testInfo.project.use.storageState,
        });
        remotePage = await context.newPage();
        await remotePage.goto(EnvConfig.baseUrl);
        break;
      } catch (error) {
        if (attempt === 2) throw error;
        // Grid congestion on attempt 1 — retry once before giving up
      }
    }

    await use(remotePage);

    // Update CI dashboard with pass/fail status
    await remotePage.evaluate(
      () => {},
      `remote_action: ${JSON.stringify({
        action: 'setTestStatus',
        arguments: { status: testInfo.status }
      })}`
    );
  },

  // 20 page objects — each lazily initialized per test
  projectPage:  async ({ page }, use) => { await use(new ProjectPage(page)); },
  testCasePage: async ({ page }, use) => { await use(new TestCasePage(page)); },
  // ... 18 more page objects
});

The clever part: In local mode, tests use the default Playwright page. In remote mode, the same fixture creates a per-test CDP session on the remote browser grid, retries once on connection failure, and reports the final test status back to the CI dashboard. The test code itself never knows which mode it's running in.

Composite Fixtures for Zero-Setup Tests

The most powerful pattern in the entire framework: composite fixtures that create entire entity hierarchies before the test even starts.

// Three fixture levels — each builds on the previous:

// Level 1: Just a project
projectOnly: creates project → opens it → USE → deletes it

// Level 2: Project with a test case
projectWithTestCase: creates project → creates TC → USE → deletes both

// Level 3: Full hierarchy
projectWithTestCaseInFolder: creates project → folder → TC → USE → deletes all

A test that needs a full hierarchy? Just destructure it:

test('verify test case appears in folder', async ({
  projectWithTestCaseInFolder
}) => {
  // Everything is already created and opened.
  // Just test the thing you care about.
  await expect(testCasePage.folderItem).toBeVisible();
  // Cleanup happens automatically after this line.
});

Zero setup lines. Zero teardown lines. Zero cognitive overhead about state management.

This pattern transformed how the team writes tests. New test authors don't need to understand fixture wiring — they just pick the fixture level they need.

Smart Waits — The Hardest Problem

Flaky tests are almost always a wait problem. Here's what I found in practice and how I solved each case:

Problem 1: Search field debounce

Typing into a search field and immediately pressing Enter fires before the debounce completes:

async fillAndSubmit(locator: Locator, value: string): Promise<void> {
  await locator.fill(value);
  await this.page.waitForTimeout(800); // explicit debounce wait
  await this.page.keyboard.press('Enter');
}

Problem 2: Network settle after navigation

networkidle is the ideal wait — but it's strict. On CI runners or apps with persistent WebSocket connections, it times out:

async clickAndWaitForNetwork(locator: Locator): Promise<void> {
  await locator.click();
  try {
    await this.page.waitForLoadState('networkidle');
  } catch {
    // Fallback: DOM is ready even if network isn't fully settled
    await this.page.waitForLoadState('domcontentloaded');
  }
}

The principle: Never use fixed waitForTimeout as a crutch for unknown timing. Use it only when you know exactly what you're waiting for (like a debounce) and pair explicit waits with network/DOM state checks.

Deep Dive: Backend Framework

The Interceptor Chain Architecture

This is the core architectural innovation in the backend framework. Every API client is built on Axios with a 4-layer interceptor chain:

Request  →  [HTTP Logger]  →  [Auth Injector]  →  Server
Response ←  [Error Handler] ←  [Retry Logic]  ←  Server

export const createClient = (options: ClientOptions = {}): AxiosInstance => {
  const client = axios.create({
    baseURL: serviceConfig.baseURL,
    timeout: 30_000,
  });

  // Layer 1: HTTP logger — captures timing from the moment request fires
  attachHttpLogger(client);

  // Layer 2: Auth — inject Bearer token or Basic auth depending on service
  client.interceptors.request.use(async (config) => {
    await applyAuth({ headers: config.headers }, authStrategy);
    return config;
  });

  // Layer 3: Error handler — context-aware error classification
  client.interceptors.response.use(
    (res) => res,
    (err) => {
      // 401, 404, 422 in negative tests → EXPECTED (don't alarm)
      // 500 "record not found" → EXPECTED (deterministic)
      // Everything else → ACTUAL ERROR (needs attention)
      return Promise.reject(err);
    },
  );

  // Layer 4: Retry — exponential backoff for transient infrastructure failures
  attachRetryInterceptor(client);

  return client;
};

Why this specific ordering matters:

Logger runs first — captures timing from request inception, not after auth delay
Auth runs before Error handler — auth failures are classified correctly as errors
Error handler runs before Retry — only actually retryable errors get retried
Retry runs last — replays the complete chain including auth refresh on retry

Get the order wrong and you get incorrect timing data, silent auth failures, or infinite retry loops on permanent errors.

Exponential Backoff Retry

Not all 5xx errors deserve a retry. A "record not found" from the database is permanent — retrying it wastes time. A 502 gateway timeout is transient — retrying it often succeeds:

const RETRYABLE_STATUS_CODES = new Set([500, 502, 503, 504]);
const RETRYABLE_NETWORK_CODES = new Set(['ECONNRESET', 'ETIMEDOUT', 'ECONNABORTED']);

const isRetryable = (error: AxiosError): boolean => {
  if (error.response?.status === 500) {
    const body = JSON.stringify(error.response.data);
    // Deterministic application error — not retryable
    if (body.includes('record not found')) return false;
  }
  return (
    RETRYABLE_STATUS_CODES.has(error.response?.status) ||
    RETRYABLE_NETWORK_CODES.has(error.code)
  );
};

// Exponential backoff: 1s → 2s → 4s (max 3 retries)
const delay = Math.pow(2, retryCount) * 1000;

This nuance — distinguishing application errors from infrastructure errors — is the difference between a retry system that helps and one that masks real bugs.

Worker-Scoped Fixtures with LIFO Cleanup

Running 10 parallel workers means 10 simultaneous test suites. Each worker needs its own project context to avoid data collisions:

export const test = base.extend<{}, WorkerFixtures>({

  // CleanupRegistry tracks everything created — cleans up in reverse order
  cleanup: [async ({}, use) => {
    const registry = new CleanupRegistry();
    await use(registry);
    await registry.run(); // LIFO: last created = first deleted
  }, { scope: 'worker' }],

  // One project per worker — shared across all tests in that worker
  projectId: [async ({ cleanup }, use) => {
    const res = await ProjectsClient.create(fakeProject());
    cleanup.add(async () => {
      await ProjectsClient.delete(res.data.id);
    });
    await use(res.data.id);
  }, { scope: 'worker' }],

});

Why LIFO (Last In, First Out) cleanup is essential:

Create order:   Project → Folder → TestCase → TestStep
Cleanup order:  TestStep → TestCase → Folder → Project  ✓

If you delete the Project first, the Folder, TestCase, and TestStep deletions return 404. With LIFO, every entity is deleted in the correct dependency order, automatically.

4-Tier Test Strategy

One test suite that runs everywhere is an anti-pattern. Different contexts need different test configurations:

Tier	Timeout	Workers	Retries	When
Smoke	30s	10	1	Every PR — must be fast
Regression	60s	5	2	Nightly — full coverage
Flows	120s	1 (serial)	0	On demand — E2E business flows
Benchmark	180s	10	0	Weekly — latency profiling

The Flows tier runs serially by design. These tests validate complete multi-step business processes:

Create Project → Create Folder → Add Test Case → Create Test Run → Verify Results

Running these in parallel would mean multiple tests modifying the same entities simultaneously — a recipe for race conditions and false failures.

The Benchmark tier has zero retries by design. If you retry a latency measurement, the p95 and p99 numbers become meaningless. One attempt. Record the truth.

Test Data Factories

15 parallel workers creating test data simultaneously needs one thing above all else: guaranteed uniqueness.

const uniqueName = (entity: string): string =>
  `AutoTest_${entity}_${faker.string.nanoid(6)}`;

export const fakeProject = (overrides?: Partial<ProjectPayload>) => ({
  name: uniqueName('Proj'),          // → AutoTest_Proj_x9m3p7
  description: faker.lorem.sentence(),
  tags: [faker.lorem.word()],
  ...overrides,
});

export const fakeTestCase = (projectId: string, overrides?) => ({
  project_id: projectId,
  test_cases: [{
    title: uniqueName('TC'),         // → AutoTest_TC_a8k2n1
    priority: 'Medium',
    type: 'Functional',
    ...overrides,
  }],
});

The overrides pattern is the most underrated part of this design. Default data is auto-generated for the 80% of tests that don't care about specific field values. But any test can override exactly what it needs:

// Test doesn't care about priority — use default
const tc = fakeTestCase(projectId);

// Test specifically validates Critical priority behaviour
const tc = fakeTestCase(projectId, { priority: 'Critical' });

// Test validates multiple field combinations
const tc = fakeTestCase(projectId, {
  priority: 'High',
  type: 'Integration',
  status: 'Draft',
});

No factory method explosion. No duplicate data builders. One factory, infinite flexibility.

The Hard Problems (And How I Solved Them)

1. Multi-Environment Region Routing

Four environments. Two regions each. Eight different URL sets. One wrong URL and tests silently hit the wrong region — passing when they should be testing something else entirely.

stage    → stage.app.internal  (US)
eu-stage → eu-stage.app.internal  (EU — different subdomain!)
prod     → app.example.com                (US)
eu-prod  → eu-app.example.com             (EU)

Solution: a single TEST_ENV variable that resolves the complete configuration:

const ENV_MAP = {
  'stage':    { project: 'us-chromium', region: 'us' },
  'eu-stage': { project: 'eu-chromium', region: 'eu' },
  'prod':     { project: 'us-chromium', region: 'us' },
  'eu-prod':  { project: 'eu-chromium', region: 'eu' },
};

One source of truth. No URL mixing across config files. Switching from staging to production is one variable change.

2. Remote Grid Stability Under Parallel Load

Running 15 tests simultaneously on a remote browser grid is inherently unstable. Connections drop. Sessions time out. Grid gets congested during peak hours.

My solution was three-pronged:

Inflated timeouts for remote execution:

Local:  test=120s, expect=15s, action=30s, navigation=60s
Remote: test=300s, expect=25s, action=45s, navigation=90s

Per-test connection retry:

for (let attempt = 1; attempt <= 2; attempt++) {
  try {
    browser = await chromium.connect(wsEndpoint);
    break;
  } catch {
    if (attempt === 2) throw error;
    // Grid congestion — wait briefly and retry
  }
}

Named sessions: Every remote test gets its own CDP session with the test name embedded. The CI dashboard shows individual test results, not a blob of unnamed sessions — which makes debugging failures in CI actually possible.

3. Auth Token Sharing Across Workers

Logging in once per test would trigger rate limiting. Logging in once per worker still means 15 login calls at startup. The solution: global setup with file-based token caching.

Frontend (cookie-based):

// global-setup.ts — runs ONCE before any worker starts
const authFilePath = '.auth/user.json';
const ONE_HOUR = 60 * 60 * 1000;

if (
  fs.existsSync(authFilePath) &&
  Date.now() - fs.statSync(authFilePath).mtimeMs < ONE_HOUR
) {
  return; // Reuse cached cookies — no login needed
}

// Otherwise: API login → save cookies → all workers read the file

Backend (JWT-based):

// Fetch JWT once at startup → save to .auth-token file
// Every worker reads from the same file on each request
const token = await getAuthToken(); // reads from file, not network
config.headers['Authorization'] = `Bearer ${token}`;

15 workers. 1 login. No rate limiting.

4. Flaky Test Detection

A test that fails on attempt 0 but passes on attempt 1 is not "passing" — it's flaky. Retries hide the problem. You need to track it:

class FlakyReporter implements Reporter {
  private flakyTests: FlakyTest[] = [];

  onTestEnd(test: TestCase, result: TestResult) {
    if (test.outcome() === 'flaky') {
      this.flakyTests.push({
        title:          test.title,
        file:           test.location.file,
        failureMessage: result.errors[0]?.message,
        attempts:       result.retry + 1,
      });
    }
  }

  onEnd() {
    if (this.flakyTests.length > 0) {
      // Still exits with code 1 — flaky tests are not OK
      console.error(`⚠️  ${this.flakyTests.length} flaky test(s) detected`);
      this.flakyTests.forEach(t => console.error(`  • ${t.title}`));
      process.exit(1);
    }
  }
}

Flaky tests don't silently pass in this framework. They're visible, logged, and they break the build — because a flaky test is a real problem waiting to become a consistent failure.

5. API Schema Validation at Scale

192 endpoints. Manually writing JSON schemas for each one is weeks of work and immediately goes stale when the backend team changes a response shape.

Solution: auto-discovery and drift detection.

First run:   Real API response → auto-generate JSON schema → save to schemas/discovered/
All future:  Real API response → validate against saved schema → FAIL if shape changed

// On first encounter of an endpoint
const schema = generateSchema(response.data);
fs.writeFileSync(`schemas/discovered/${endpointKey}.json`, JSON.stringify(schema));

// On subsequent runs
const savedSchema = JSON.parse(fs.readFileSync(`schemas/discovered/${endpointKey}.json`));
const valid = ajv.validate(savedSchema, response.data);
if (!valid) {
  throw new Error(`Schema drift detected on ${endpointKey}: ${ajv.errorsText()}`);
}

100+ schemas, auto-generated. When the backend team silently changes a response shape (it happens more than you'd think), the CI pipeline catches it before it reaches production.

CI/CD Pipelines

Frontend Pipeline

# ci.yml — Triggered on every PR
steps:
  - TypeScript compile check (tsc --noEmit)
  # Catches type errors before running a single browser

# test.yml — Manual trigger with environment selection
steps:
  - Select: environment (stage | eu-stage | prod | eu-prod)
  - Select: tag (@smoke | @regression)
  - Run: 2 workers, 2 retries
  - Upload: playwright-report, allure-results, test-results artifacts

# hyperexecute.yml — Cloud-scale execution
steps:
  - 15 workers with autosplit (distributes test files automatically)
  - Stable build ID (all workers grouped in CI dashboard)
  - 90-minute global timeout
  - HyperExecute YAML with concurrency: 15

Backend Pipeline

# api-tests.yml — Manual trigger with suite selection
steps:
  - Step 1: TypeScript compile check (tsc --noEmit)
  - Step 2: Run by suite (smoke | regression | flows | all)
  - Upload: HTML report, JSON results, API timing summary

# The compile check in Step 1 is not optional.
# It catches more API contract bugs than the tests themselves.

The Numbers

Metric	Frontend	Backend
Test specs	61	41
API endpoints covered	—	192 (100% of v1)
Feature areas	18	32 API clients
Custom reporters	4	2
Environments supported	4 × 2 regions	6 configs
Max parallel workers	15	10
Smoke run time	~2 minutes	~30 seconds
Full regression	~15 minutes	~8 minutes
Framework code (lines)	~4,000	~6,000
Schema drift detectors	—	100+ auto-generated

Key Takeaways

These aren't principles I copied from a blog post. They're conclusions from building this specific system and watching what broke and what held:

1. Your base class should be thin. My BasePage has 3 methods. Everything else uses Playwright directly. Every additional abstraction layer is a maintenance burden you're betting will pay off. Most don't.

2. Fixtures beat beforeEach/afterEach every time. Playwright fixtures handle dependency injection, scoping, and automatic cleanup. They compose. They're reusable across files. beforeEach is a local solution to a global problem.

3. Separate test data from test logic. Faker factories with override patterns give you unique data with zero maintenance. Never hardcode test data. Never share test data between tests.

4. Design for parallel execution from day one. Worker-scoped fixtures, unique test data, LIFO cleanup — these aren't optimizations you add later. They're requirements. Retrofitting parallelism into a serial framework is painful.

5. Retry logic needs nuance. Not all errors are retryable. Not all retries should be silent. Build flaky test detection, not just retry counts.

6. One environment variable should switch everything. If changing environments requires modifying more than one config value, your setup is too fragile for real CI/CD usage.

7. TypeScript catches bugs before tests run.tsc --noEmit in CI caught more API contract issues than the actual tests. Type safety is not a nice-to-have in test automation — it's a first-class quality gate.

What's Next

These two frameworks now run hundreds of tests every day across 4 environments, catching regressions before they reach our users.

But a framework is never finished. The next priorities are:

Visual regression testing for the product's AI-generated UI components
Contract testing between frontend and backend using Pact
Performance benchmarking with automated regression alerts at p99 latency thresholds

If you're building test automation infrastructure for a complex product and want to talk through architecture decisions — I'm always open to connecting.

Found This Useful?

If this breakdown helped you think differently about test automation architecture, share it with your team or QA community. Every framework starts with someone asking "how should I structure this?" — maybe this article gives you a starting point.

Follow me on LinkedIn for weekly posts on software engineering, open source, and developer tools: 👉 linkedin.com/in/ritikpal

Check out webguardx — my open-source web audit tool built with Playwright: 👉 npmjs.com/package/webguardx

Subscribe to this blog to get notified when I publish the next post: "How I set up web accessibility testing in your CI/CD pipeline"

Have questions about any of the patterns in this article? Drop them in the comments — I read every one.

TestAutomation #Playwright #TypeScript #SDET #QAEngineering #OpenSource #SoftwareEngineering

How I Went from Fresher to Engineer at an AI Startup — My Honest 2-Year Journey

Ritik Pal — Thu, 19 Mar 2026 13:30:42 +0000

Meta description: A software engineer's honest career journey in India — from college at AKTU to working at an AI startup. Real lessons, mistakes, and practical tips for freshers starting out.

Two years ago, I was a final-year IT student at Dr. A.P.J. Abdul Kalam Technical University with zero industry experience, a GitHub with three half-finished projects, and a browser history full of "how to get a software engineering job in India" searches.

Today, I'm a Member of Technical Staff at TestMu AI — an AI-powered testing startup in Noida — and I recently shipped my first open-source npm package, webguardx, which crossed 50 stars in its first week.

This isn't a motivational post. It's the unfiltered version of what my software engineer career journey in India actually looked like — the internships, the rejections, the skills I had to teach myself, and the things nobody told me in college.

If you're a fresher trying to figure out your path, keep reading. I wish someone had written this for me.

Where I Started — and What College Actually Prepared Me For

I did my Bachelor's in Information Technology from AKTU. If you've been through a tier-2 engineering college in India, you know the drill — heavy on theory, light on industry-relevant skills, and a curriculum that moves at a pace that feels disconnected from what companies actually want.

What college did give me: a foundation in data structures, some exposure to web development through side projects, and — honestly — the pressure of placement season which forced me to actually start coding seriously.

What it didn't give me: version control habits, how real team workflows operate, what production code actually looks like, or how to communicate technical decisions to non-technical people.

That gap? I had to fill it myself. And that's exactly what these two years have been about.

My First Internship: FlexEHR and What Working Remotely Taught Me

In December 2023, I joined FlexEHR Healthcare Solutions as an SDE intern. It was remote, based out of Bengaluru, and it was my first real exposure to a professional codebase.

The first week was humbling. Real code doesn't look like the tutorial projects you build in college. There are files everywhere, naming conventions you haven't seen before, legacy decisions baked into the architecture, and a pace that doesn't slow down for you to catch up.

A few things that hit me immediately:

GitLab was not GitHub. I had used GitHub casually for personal projects but hadn't worked with proper branching strategies, pull requests, or merge request reviews. My first week was partly just learning how the team moved code around.

Nobody has time to explain everything. In college, someone is always available to answer your question. In a startup, people are heads-down on deliverables. I learned to read documentation carefully, trace code myself before asking, and ask specific questions rather than broad ones.

The healthcare domain had real constraints. Building UI components for a healthcare platform isn't the same as building a generic web app. Accessibility wasn't a nice-to-have — it was a requirement. Compliance mattered. That context shaped how I thought about writing clean, careful code.

I stayed for six months. By the time I left, I had gone from barely understanding the codebase to confidently shipping frontend features independently.

GeeksforGeeks Internship: The DSA Grind That Changed Everything

Before FlexEHR, I had a six-month stint at GeeksforGeeks as a Problem Solver intern. This is where my relationship with Data Structures and Algorithms went from "I barely pass this in exams" to "I actually enjoy this."

I spent most of 2022 grinding problems. Not for placement prep — well, partly for placement prep — but because I started genuinely understanding why certain approaches were more efficient than others. That shift from memorising solutions to understanding patterns was one of the most important things that happened to my engineering brain.

If you're a fresher struggling with DSA, here's what actually helped me:

Stop solving random problems. Pick one topic (arrays, trees, graphs) and exhaust it before moving on.
Understand the "why" before the "how." Before coding a solution, explain to yourself why this approach makes sense.
Revisit problems you got wrong. Not to copy the solution — to understand what your thinking missed.
Write it out. Typing code in an IDE is different from writing logic on paper. Both are useful muscles.

DSA didn't just help me in interviews. It changed how I reason through problems in production code, which I didn't expect but am genuinely grateful for.

Getting My First Full-Time Job at Typof

In July 2024, I joined Typof as a Frontend Developer. Typof is a commerce platform and my role was building and maintaining frontend interfaces using React.js, Node.js, and Material UI.

Getting this job wasn't magic. It was the result of two internships on my resume, a portfolio with real projects, and being able to talk confidently in the interview about problems I had actually solved — not hypothetical ones.

What I learned at Typof was a different kind of lesson: scale matters. At FlexEHR I was working on a small team. At Typof, the frontend served thousands of merchants. The decisions I made about component architecture, performance, and reusability had real downstream effects.

I also learned what burnout looks like. The pace was fast, the expectations were high, and there were weeks where I was shipping features faster than I was fully understanding them. I got better at speaking up, slowing down when something needed to be done properly, and communicating timelines honestly.

Eight months later, the next opportunity arrived.

The Skills Gap Nobody Talks About

Here's something I think the Indian tech education system consistently underestimates: the gap between writing code and being an engineer.

Writing code is the smallest part of the job. The bigger parts are:

Reading and understanding other people's code, which is often messy and underdocumented
Communicating decisions — why you built something a certain way, what trade-offs you made
Estimating work honestly — not optimistically, which is the natural instinct
Writing documentation and tests, which nobody teaches you to love but everyone needs you to do
Debugging production issues under pressure, which is a completely different skill from solving algorithm problems

I had to learn all of this on the job. Some of it through mistakes, some through watching senior engineers work, and some through actively building habits like writing comments for future-me and always asking "what breaks if this fails?"

If you're still in college: start building these habits now. They will differentiate you more than knowing the latest framework.

How I Landed at an AI Startup (and What That Actually Means Day-to-Day)

In February 2025, I joined TestMu AI as Member of Technical Staff.

TestMu AI is focused on AI-powered testing — which meant the intersection of my frontend/backend experience and the AI exposure I had gained earlier through Outlier, where I spent time training large language models in coding best practices.

People romanticize working at an AI startup. The reality is more grounded — and more interesting for it. We're building real infrastructure, solving real engineering problems, and the "AI" part means we're constantly thinking about how to make testing smarter, faster, and more reliable.

What's different about working here compared to my earlier roles:

Ownership is higher. At a startup, you're not just a contributor to a large system. Your decisions have visible impact quickly.
The learning curve is steeper. You're expected to move across the stack — TypeScript, Python, Node.js — and pick up new domains fast.
The pace tests your fundamentals. When things move fast, shortcuts hurt you. The engineers who thrive here are the ones who built strong fundamentals early and don't cut corners when it matters.

Building webguardx — My First Open Source Project

Alongside my work at TestMu AI, I built and launched webguardx — an open-source npm package for full-page web auditing using Playwright.

The idea came from a problem I kept seeing across every project I worked on: web apps break in ways that users notice before developers do. Broken links, accessibility failures, silent JavaScript errors, poor performance — these things accumulate and nobody catches them systematically.

So I built webguardx to do exactly that. Accessibility checks, HTTP status codes, broken links, console errors, performance and SEO via Lighthouse, SQL injection tests, session invalidation checks — all from a single config file with three commands.

Building in public taught me things working in private never could:

People will use your code in ways you didn't design for. This is humbling and motivating at the same time.
Documentation is a first-class feature. A tool nobody can set up is a tool nobody uses.
Community feedback is the fastest way to improve. The security audit checks in the latest version came directly from user requests.

The webguardx launch post on LinkedIn got more traction than anything I had posted before. Building something real and sharing it openly is the single best portfolio move I have made in my career.

5 Honest Lessons from 2 Years in the Industry

After two years of internships, full-time roles, a startup, and an open-source project, here's what I genuinely believe:

1. Your first job matters less than what you do in it.
Prestige of the company fades quickly. What stays is the quality of the work you do, the habits you build, and the problems you own. I've learned more from a mid-size startup than I would have coasting at a large company.

2. Communication is a technical skill.
The engineers who grow fastest aren't always the best coders — they're the ones who can clearly explain what they built, why it works, and what can go wrong. Practice this like you practice DSA.

3. Side projects are the best interview prep.
Not because of resume points, but because they force you to own the full problem. No one tells you what to build, how to architect it, or when to stop. That autonomy builds a kind of engineering judgment that tutorial projects never develop.

4. Learn the problem domain, not just the tech stack.
At FlexEHR I learned about healthcare compliance. At Typof I learned about e-commerce infrastructure. At TestMu AI I'm learning about software quality at scale. The engineers who understand the domain they're building for write better software.

5. Your career is not a straight line.
Two internships, a full-time role, a startup, an open-source project, and now content creation. None of it was planned. Every step opened a door I didn't know existed. Stay curious and stay willing to bet on yourself.

What I'd Tell My Fresher Self

If I could send one message back to myself in final year:

Start building things people can use. Not tutorial clones — real things that solve real problems, even small ones. Put them on GitHub. Write about how you built them. The compounding effect of this habit over two years is greater than any certification or course.

Everything else follows from that.

Key Takeaways

College gives you a foundation, but the industry gap is real — plan to fill it yourself
Internships are worth more than their stipend — treat every one as a learning sprint
DSA matters, but communication, documentation, and ownership matter just as much
Open source is the most underrated career accelerator for developers in India
Your software engineer career journey in India is not a template — it's yours to build

What's Next for Me

I'm currently focused on three things: shipping more features for TestMu AI, growing webguardx into a widely-used tool in the developer community, and sharing everything I'm learning through writing and video content about tech, AI, and travel.

If you're a fresher or early-career engineer finding your footing — I hope this was useful. The path is messier than anyone's LinkedIn makes it look, and that's exactly what makes it worth it.

Follow me on LinkedIn for weekly posts on software engineering, open-source, and the developer life: linkedin.com/in/ritikpal

Check out webguardx on npm and GitHub — contributions and feedback are always welcome.

Subscribe to this blog to get notified when I publish the next post — coming soon: "How I learned TypeScript from scratch while working full-time."

If this post helped you, share it with a fellow developer who's just starting out. It means more than you know.

Why --legacy-peer-deps is Better than --force in npm

Ritik Pal — Sat, 01 Feb 2025 07:57:20 +0000

When managing dependencies in a Node.js project, you might encounter scenarios where installing packages results in conflicts or warnings due to peer dependency issues. Two common ways developers address this are using the --legacy-peer-deps flag or the --force flag with npm. While both methods can resolve dependency issues temporarily, --legacy-peer-deps is generally the safer and more reliable choice. Let’s dive into the details of these options, their use cases, and why you should prefer --legacy-peer-deps over --force.

Understanding Peer Dependencies

Peer dependencies in npm are a way for a package to specify that it works alongside a specific version of another package. Instead of installing the dependency itself, it ensures that the consuming project already has the appropriate version installed. This is common in ecosystems like React, where libraries often rely on a specific version of React to avoid compatibility issues.

For example:

{
  "peerDependencies": {
    "react": "^17.0.0"
  }
}

When you try to install a package with conflicting peer dependencies, npm may throw errors or warnings to alert you.

The `--legacy-peer-deps` Flag

The --legacy-peer-deps flag tells npm to ignore peer dependency conflicts and install the dependencies as they were handled in older npm versions (prior to npm 7). This approach doesn’t strictly enforce peer dependency resolutions, which can help avoid installation failures while preserving the overall integrity of the dependency tree.

Benefits of Using `--legacy-peer-deps`

Compatibility:
- Retains compatibility with older package versions that may not have updated their peer dependency requirements for npm 7+.
Controlled Flexibility:
- While ignoring peer dependency errors, it still respects the hierarchy and structure of your dependency tree.
Reduced Risk:
- Avoids the potential for breaking changes or instability in your project by not overriding dependencies aggressively.
Better for Collaboration:
- Ensures a more predictable environment for your team, as dependency resolutions are closer to the original behavior of npm.

The `--force` Flag

The --force flag in npm does exactly what it sounds like: it forces npm to install the package, overriding any conflicts, including peer dependency and version mismatches. While this might seem like a quick fix, it comes with significant risks.

Risks of Using `--force`

Breaking Changes:
- Forcefully overriding dependencies can result in incompatible versions being installed, leading to runtime errors or unexpected behavior.
Unpredictable Behavior:
- Dependencies that rely on specific versions of their peer dependencies may not function correctly, creating instability in your application.
Difficult Debugging:
- Force-installed packages can cause subtle bugs that are hard to trace, as the dependency tree may not align with what the packages expect.
Potential Conflicts in Teams:
- Using --force can make it harder to replicate environments, especially when working in teams or deploying to different environments.
Technical Debt:
- By ignoring warnings and conflicts, you may introduce long-term technical debt into your project, making future upgrades or maintenance more challenging.

When to Use Each Flag

Use `--legacy-peer-deps` When:

You are working with older packages that have not updated their peer dependency requirements.
You want to avoid breaking changes while maintaining some level of dependency integrity.
You’re installing a specific package, and peer dependency warnings are blocking the installation.

Avoid Using `--force` Unless:

You have no other option, and you understand the risks.
You’re working in a temporary environment, such as debugging or testing.
You plan to immediately address the root cause of the dependency conflict.

Example: Resolving Conflicts

Imagine you’re trying to install a library that depends on React 17, but your project uses React 18. Here’s how the two flags behave:

Using `--legacy-peer-deps`:

npm install some-library --legacy-peer-deps

Installs the library while ignoring the React version mismatch.
Keeps your existing React 18 version and avoids forcefully downgrading or upgrading dependencies.

Using `--force`:

npm install some-library --force

Ignores all dependency conflicts and installs the library, potentially overwriting your React version or breaking other packages.

Why `--legacy-peer-deps` is the Better Choice

Safer Resolutions: It avoids the brute-force approach of overriding dependencies, minimizing the risk of breaking your application.
Preserves Peer Dependency Logic: By ignoring conflicts without overwriting, it respects the intent behind peer dependencies.
Team-Friendly: Provides a more predictable and stable environment for collaboration and deployment.
Future-Proofing: Reduces the likelihood of introducing technical debt, making it easier to maintain and upgrade your project in the future.

Best Practices

Understand Your Dependencies:
- Review the peer dependency requirements and try to resolve conflicts manually where possible.
Upgrade Packages Regularly:
- Keep your dependencies up-to-date to avoid compatibility issues with newer npm versions.
Use Tools:
- Leverage tools like npm ls to inspect your dependency tree and identify potential conflicts.
Document Decisions:
- If you use --legacy-peer-deps or --force, document the reasoning in your project’s README or a relevant file for future reference.

Conclusion

While both --legacy-peer-deps and --force can help resolve dependency conflicts, --legacy-peer-deps is the better option in most cases. It strikes a balance between resolving issues and maintaining the integrity of your dependency tree, ensuring a stable and predictable environment for development. Reserve --force for exceptional circumstances where no other solution is viable, and always proceed with caution. By understanding and carefully managing your dependencies, you can avoid the pitfalls of conflicts and build a more maintainable project.

Mastering React Quill: A Step-by-Step Guide to Implement a Rich Text Editor in Your React App

Ritik Pal — Tue, 07 Jan 2025 11:13:36 +0000

In the modern digital landscape, rich text editors have become a cornerstone for building user-friendly interfaces. From blog platforms to content management systems (CMS), they empower users to craft beautifully formatted content with ease. One of the most robust and widely-used tools for this purpose in React is React Quill.

This guide will take you on a journey to integrate and customize React Quill in your React application, making your interface dynamic and feature-rich.

Why React Quill?
React Quill is a wrapper for the powerful Quill.js editor. It offers a lightweight and modular solution for rich text editing in React applications, featuring:

Rich Text Formatting: Support for bold, italic, underline, and more.
Customizable Toolbar: Tailor the editor to include only the features you need.
Lightweight and Flexible: Highly customizable with minimal setup.
React-Friendly Architecture: Seamless integration into React’s component model.
Whether you’re building a blog editor, a messaging app, or a CMS, React Quill is your go-to solution.

Step 1: Installing React Quill
To get started, install React Quill and its peer dependency, Quill, using npm or yarn.

npm install react-quill quill

Step 2: Importing React Quill and Its Styles
React Quill relies on Quill’s styles for its appearance. Import the editor and its default theme (snow) into your component.

Import quill and css for that

import React, { useState } from 'react';
import ReactQuill from 'react-quill';
import 'react-quill/dist/quill.snow.css'

Step 3: Creating a Basic Editor Component
Here’s how to set up a simple rich text editor:

const RichTextEditor = () => {
  const [content, setContent] = useState('');

  const handleContentChange = (value) => {
    setContent(value);
  };

  return (
    <div>
      <h2>Rich Text Editor</h2>
      <ReactQuill
        theme="snow"
        value={content}
        onChange={handleContentChange}
      />
      <h3>Preview:</h3>
      <div dangerouslySetInnerHTML={{ __html: content }} />
    </div>
  );
};

export default RichTextEditor;

Step 4: Customizing the Toolbar
Out of the box, React Quill provides a comprehensive toolbar. However, you can customize it to include only the features you need, enhancing usability and focusing on specific functionalities.

Custom Toolbar Configuration:

const modules = {
  toolbar: [
    [{ header: [1, 2, false] }], 
    ['bold', 'italic', 'underline'], 
    [{ list: 'ordered' }, { list: 'bullet' }], 
    ['link', 'image'], 
  ],
};

const formats = [
  'header',
  'bold',
  'italic',
  'underline',
  'list',
  'bullet',
  'link',
  'image',
];
Applying the Custom Toolbar:
javascript
Copy code
<ReactQuill
  theme="snow"
  value={content}
  onChange={handleContentChange}
  modules={modules}
  formats={formats}
/>

Step 5: Adding the Editor to a Form
If you want to use the editor as part of a form, ensure the content is submitted correctly:


const handleSubmit = (e) => {
  e.preventDefault();
  console.log('Submitted Content:', content);
};

return (
  <form onSubmit={handleSubmit}>
    <ReactQuill
      theme="snow"
      value={content}
      onChange={handleContentChange}
      modules={modules}
      formats={formats}
    />
    <button type="submit">Submit</button>
  </form>
);

Step 6: Adding Validation
To ensure quality input, validate the editor’s content before submission. For example, you can prevent submission if the content is empty:


const handleSubmit = (e) => {
  e.preventDefault();
  if (!content || content.trim() === '<p><br></p>') {
    alert('Content cannot be empty!');
    return;
  }
  console.log('Valid Content:', content);
};

Step 7: Advanced Customization
1. Custom Styling
Customize the editor’s appearance by overriding the default styles.

.ql-container {
  font-family: 'Grotesk', sans-serif;
  min-height: 300px;
}

.ql-toolbar {
  background-color: #f8f9fa;
  border: 1px solid #ced4da;
}

2. Image Upload Handling
React Quill supports images, but to upload images to a server, you’ll need to extend its functionality. You can add a custom handler for the image button in the toolbar.

Step 8: Server-Side Rendering (SSR)
React Quill depends on the window object, which can cause issues with SSR frameworks like Next.js. To address this, dynamically import React Quill on the client side:

import dynamic from 'next/dynamic';

const ReactQuill = dynamic(() => import('react-quill'), { ssr: false });

Use Cases of React Quill

Blog Platforms: Enable users to create and format posts easily.
Messaging Apps: Allow rich text formatting in messages.
Content Management Systems: Help content creators manage dynamic content.
Email Builders: Provide drag-and-drop interfaces for creating styled emails.

Conclusion

React Quill is a powerful and flexible tool for integrating rich text editing into React applications. With its extensive customization options and easy-to-use API, you can build tailored editing experiences for your users.

By following this guide, you’ve learned how to:

Install and set up React Quill.
Customize the toolbar.
Integrate the editor with forms.
Handle content validation.
Overcome SSR challenges.
Now, it’s time to put this knowledge into practice. Whether you’re building a blog, a CMS, or any app requiring rich text input, React Quill is a reliable choice that will elevate your application’s user experience.

Happy Coding! 🚀

How To Write Best Git Commit

Ritik Pal — Thu, 29 Aug 2024 15:06:17 +0000

Here's how you can write a better Git commit.
That will Mostly Help You To Increase Your Productivity

JavaScript Event Loop: A Deep Dive

Ritik Pal — Wed, 17 Jul 2024 11:25:15 +0000

JavaScript, being a single-threaded language, executes one task at a time. However, it handles asynchronous operations with ease, thanks to the event loop. The event loop is a fundamental concept that powers JavaScript's concurrency model, allowing it to manage multiple operations efficiently without blocking the main thread. In this article, we'll explore the intricacies of the JavaScript event loop, understanding how it works and why it's crucial for developing responsive web applications.

What is the JavaScript Event Loop?

The event loop is a mechanism that JavaScript uses to handle asynchronous operations. It continuously checks the call stack and the task queue, ensuring that tasks are executed in the correct order. The primary goal of the event loop is to keep the application responsive by managing the execution of synchronous and asynchronous code.

Key Components of the Event Loop

1. Call Stack:

The call stack is a data structure that tracks function calls in a Last In, First Out (LIFO) order. When a function is called, it's added to the stack. When the function execution completes, it's removed from the stack.

2. Web APIs:

Web APIs are provided by the browser (or Node.js environment) to handle asynchronous operations like setTimeout, HTTP requests (XMLHttpRequest, Fetch API), and DOM events. These APIs operate outside the JavaScript engine.

3. Callback Queue (Task Queue):
The callback queue is a data structure that holds the callbacks of asynchronous operations. These callbacks are executed when the call stack is empty.

4. Event Loop:
The event loop continuously monitors the call stack and the callback queue. If the call stack is empty, it takes the first callback from the queue and pushes it onto the stack, allowing it to be executed.

How the Event Loop Works
To understand the event loop, let's walk through an example:

console.log('Start');

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

console.log('End');

Step-by-Step Execution:

1. Initialization:
The console.log('Start') function is pushed onto the call stack and executed, printing Start to the console. The function is then removed from the stack.

2. Asynchronous Operation:
The setTimeout function is called with a callback and a delay of 0 milliseconds. The setTimeout function is pushed onto the call stack and then immediately removed after setting the timer. The callback is passed to the Web API.

3. Continuation:
The console.log('End') function is pushed onto the call stack and executed, printing End to the console. The function is then removed from the stack.

4. Callback Execution:
After the call stack is empty, the event loop checks the callback queue. The callback from the setTimeout is moved to the callback queue and then pushed onto the call stack, printing Timeout to the console.

Microtasks and Macrotasks

In JavaScript, tasks are categorized into two types: microtasks and macrotasks. Understanding the difference between them is crucial for writing efficient asynchronous code.

1. Microtasks:
Microtasks include promises and MutationObserver callbacks. They have higher priority and are executed before macrotasks. After every macrotask, the event loop checks the microtask queue and executes all available microtasks.

2.Macrotasks:
Macrotasks include setTimeout, setInterval, and I/O operations. They are executed in the order they are added to the callback queue.

Example with Promises

Consider the following example with promises:

console.log('Start');

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

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

console.log('End');

Step-by-Step Execution:

1. Initialization:
console.log('Start') prints Start.setTimeout schedules a macrotask with a delay of 0ms.
Promise.resolve().then() schedules a microtask.
console.log('End') prints End.

2. Microtask Execution:
The microtask queue is checked, and the promise callback is executed, printing Promise.

3. Macrotask Execution:
The macrotask queue is checked, and the setTimeout callback is executed, printing Timeout.

Best Practices for Using the Event Loop

1. Avoid Blocking the Main Thread:
Perform heavy computations in web workers or use asynchronous patterns to keep the main thread responsive.

2. Use Promises and Async/Await:
Promises and async/await make it easier to handle asynchronous operations and improve code readability.

3. Understand Task Priorities:
Be aware of the differences between microtasks and macrotasks to write more predictable and efficient code.

Conclusion

The JavaScript event loop is a powerful mechanism that enables asynchronous programming in a single-threaded environment. By understanding how the event loop works, you can write more efficient and responsive web applications. Remember to leverage promises, async/await, and web workers to manage asynchronous tasks effectively, ensuring a smooth and seamless user experience.

50 basic Linux commands

Ritik Pal — Tue, 09 Jul 2024 10:50:33 +0000

𝐄𝐬𝐬𝐞𝐧𝐭𝐢𝐚𝐥 𝟓𝟎 𝐁𝐚𝐬𝐢𝐜 𝐋𝐢𝐧𝐮𝐱 𝐂𝐨𝐦𝐦𝐚𝐧𝐝𝐬: 𝐌𝐚𝐬𝐭𝐞𝐫 𝐘𝐨𝐮𝐫 𝐂𝐨𝐦𝐦𝐚𝐧𝐝 𝐋𝐢𝐧𝐞 𝐒𝐤𝐢𝐥𝐥𝐬 🐧

𝐩𝐰𝐝 - Print working directory. 📂
𝐥𝐬 - List directory contents. 📋
𝐜𝐝 - Change directory. 📁
𝐭𝐨𝐮𝐜𝐡 - To create a file without any content. 📄
𝐜𝐚𝐭 - Concatenate and display file content. 🐱
𝐜𝐩 - Copy files or directories. 📁📂
𝐦𝐯 - Move or rename files or directories. 🔄
𝐫𝐦 - Remove files or directories. 🗑️
𝐦𝐤𝐝𝐢𝐫 - Create a new directory. 📁
𝐫𝐦𝐝𝐢𝐫 - Remove an empty directory. 📁🗑️
𝐞𝐜𝐡𝐨 - Display a line of text or a variable value. 📢
𝐧𝐚𝐧𝐨 - A simple text editor. ✏️
𝐯𝐢 - A powerful text editor. ✒️
𝐜𝐡𝐦𝐨𝐝 - Change file or directory permissions. 🔐
𝐜𝐡𝐨𝐰𝐧 - Change file or directory owner and group. 👤
𝐟𝐢𝐧𝐝 - Search for files in a directory hierarchy. 🔍
𝐠𝐫𝐞𝐩 - Search text using patterns. 🔎
𝐦𝐚𝐧 - Display the manual for a command. 📖
𝐩𝐬 - Display information about running processes. 🔄
𝐤𝐢𝐥𝐥 - Terminate processes by PID. ⚰️
𝐭𝐨𝐩 - Display and update sorted information about processes. 📊
𝐝𝐟 - Report file system disk space usage. 💾
𝐝𝐮 - Estimate file space usage. 📏
𝐟𝐫𝐞𝐞 - Display memory usage. 🧠
𝐮𝐧𝐚𝐦𝐞 - Print system information. ℹ️
𝐮𝐩𝐭𝐢𝐦𝐞 - Tell how long the system has been running. ⏳
𝐰𝐡𝐨𝐚𝐦𝐢 - Display the current user. 👤
𝐬𝐮𝐝𝐨 - Execute a command as another user, typically the superuser. 🛡️
𝐚𝐩𝐭-𝐠𝐞𝐭 - Package handling utility for Debian-based distributions. 📦
𝐲𝐮𝐦 - Package manager for RPM-based distributions. 🍲
𝐭𝐚𝐫 - Archive files. 🗃️
𝐳𝐢𝐩 - Package and compress (archive) files. 📦
𝐮𝐧𝐳𝐢𝐩 - Extract compressed files. 📂
𝐰𝐠𝐞𝐭 - Retrieve files from the web. 🌐
𝐜𝐮𝐫𝐥 - Transfer data from or to a server. 🔄
𝐬𝐬𝐡 - OpenSSH client (remote login program). 🚪
𝐬𝐜𝐩 - Secure copy (remote file copy program). 🔒
𝐫𝐬𝐲𝐧𝐜 - Remote file and directory synchronization. 🔄
𝐡𝐨𝐬𝐭𝐧𝐚𝐦𝐞 - Show or set the system's host name. 🏠
𝐩𝐢𝐧𝐠 - Send ICMP ECHO_REQUEST to network hosts. 📶
𝐧𝐞𝐭𝐬𝐭𝐚𝐭 - Print network connections, routing tables, interface statistics, masquerade connections, and multicast memberships. 🌐
𝐢𝐟𝐜𝐨𝐧𝐟𝐢𝐠 - Configure a network interface. 🌐
𝐢𝐩 - Show/manipulate routing, devices, policy routing, and tunnels. 🌐
𝐢𝐩𝐭𝐚𝐛𝐥𝐞𝐬 - Administration tool for IPv4 packet filtering and NAT. 🛡️
𝐬𝐲𝐬𝐭𝐞𝐦𝐜𝐭𝐥 - Control the systemd system and service manager. 🔄
𝐣𝐨𝐮𝐫𝐧𝐚𝐥𝐜𝐭𝐥 - Query and display messages from the journal. 📜
𝐜𝐫𝐨𝐧𝐭𝐚𝐛 - Schedule periodic background jobs. ⏰
𝐬𝐮𝐝𝐨 𝐬𝐮 - Allows us to switch to a different user and execute one or more commands in the shell without logging out from our current session. 🛡️
𝐦𝐨𝐮𝐧𝐭 - Mount a file system. 📂
𝐮𝐦𝐨𝐮𝐧𝐭 - Unmount a file system. 📂

🐧 Use these commands to interact with your Linux system and perform various administrative tasks! 🚀

LinuxCommands #SysAdmin #DeveloperTips #LinuxTips #DevOps #CodingLife #CommandLine #LinuxTutorial #aws #linux #bash #devops

Why a .gitignore File is Essential for Your Projects

Ritik Pal — Sun, 23 Jun 2024 12:20:10 +0000

When working on a project using Git for version control, you’ll often encounter files and directories that you don’t want to track. This is where the .gitignore file becomes essential. In this post, we'll explore what a .gitignore file is, why it’s necessary, and how to use it effectively in your projects.

What is a .gitignore File?
A .gitignore file is a simple text file where you list the files and directories that you want Git to ignore. Git will then exclude these files from being tracked and versioned. This helps keep your repository clean and free from unnecessary files.

Why is a .gitignore File Necessary?

Improving Performance
By ignoring unnecessary files, you can improve the performance of Git operations. This is especially important for large projects where tracking every file can slow down version control operations.
Reducing Repository Size
Keeping your repository clean by ignoring files that are not required in version control helps reduce the overall size of the repository. This makes cloning and pulling from the repository faster and more efficient.

Preventing Sensitive Data from Being Tracked
Including sensitive information like API keys, passwords, and configuration files in your repository can be risky. A .gitignore file ensures that these sensitive files are not accidentally committed to the repository.

Example .gitignore entry for sensitive data
.env config/secrets.yml

Example .gitignore entries for temporary files

.log
tmp/
build/
dist/

Improving Performance

Reducing Repository Size
Keeping your repository clean by ignoring files that are not required in version control helps reduce the overall size of the repository. This makes cloning and pulling from the repository faster and more efficient.

Maintaining Clean and Professional Repositories
Using a .gitignore file helps maintain a clean and professional repository. It ensures that only the relevant files are tracked, making the project easier to understand and manage for other developers.

How to Use a .gitignore File
Creating and using a .gitignore file is straightforward. Here are some steps and examples to get you started:

Step 1: Create a .gitignore File
In the root directory of your project, create a file named .gitignore.

Step 2: Add Files and Directories to Ignore
Open the .gitignore file in a text editor and add the files and directories you want Git to ignore. Each entry should be on a new line.

# Ignore all .log files
*.log

# Ignore node_modules directory
node_modules/

# Ignore build directory
build/

# Ignore .env file
.env

Step 3: Commit the .gitignore File
After creating and updating your .gitignore file, commit it to your repository.

git add .gitignore
git commit -m "Add .gitignore file"

# Logs
logs
*.log
npm-debug.log*

# Dependency directories
node_modules/

# Build output
dist/
build/

# Environment variables
.env

# IDE files
.vscode/
.idea/

Conclusion
A .gitignore file is an essential part of any project using Git. It helps keep your repository clean, secure, and efficient by ignoring unnecessary files and directories. By understanding and using .gitignore files effectively, you can ensure that your version control remains manageable and professional.

Happy coding!
Follow For More

Understanding JavaScript Promises

Ritik Pal — Fri, 21 Jun 2024 19:26:37 +0000

Introduction

JavaScript Promises are a powerful way to handle asynchronous operations, allowing you to write cleaner and more manageable code. In this post, we'll dive deep into Promises and explore how they can improve your code.

Understanding Promises
A Promise in JavaScript represents the eventual completion (or failure) of an asynchronous operation and its resulting value.

How you can create Promises
You can create a new Promise using the Promise constructor, which takes a function with two parameters: resolve and reject.

Promise Methods
Promises have several methods to handle the result of the asynchronous operation.

.then()
The .then() method is used to handle the resolved value.

.catch()
The .catch() method is used to handle errors or rejected promises.

.finally()
The .finally() method is executed regardless of the promise's outcome.

Promises Chaining
Promises can be chained to perform multiple asynchronous operations in sequence.

Handle Error
Proper error handling in Promises is crucial for robust code.

Conclusion
JavaScript Promises provide a powerful way to handle asynchronous operations. By understanding and utilizing Promises, you can write cleaner, more efficient, and more readable code.

Happy Coding (:
Follow for more "_"

DEV Community: Ritik Pal

How I Built a Production-Grade E2E Test Automation Framework for an AI Testing Product

The Problem: Who Tests the Testing Tool?

The High-Level Architecture

Frontend: E2E-Frontend-Automation

Backend: E2E-Backend-Automation

Deep Dive: Frontend Framework

The 6-Layer Architecture

BasePage: Minimal by Design

The Fixture System

Composite Fixtures for Zero-Setup Tests

Smart Waits — The Hardest Problem

Deep Dive: Backend Framework

The Interceptor Chain Architecture

Exponential Backoff Retry

Worker-Scoped Fixtures with LIFO Cleanup

4-Tier Test Strategy

Test Data Factories

The Hard Problems (And How I Solved Them)

1. Multi-Environment Region Routing

2. Remote Grid Stability Under Parallel Load

3. Auth Token Sharing Across Workers

4. Flaky Test Detection

5. API Schema Validation at Scale

CI/CD Pipelines

Frontend Pipeline

Backend Pipeline

The Numbers

Key Takeaways

What's Next

Found This Useful?

TestAutomation #Playwright #TypeScript #SDET #QAEngineering #OpenSource #SoftwareEngineering

How I Went from Fresher to Engineer at an AI Startup — My Honest 2-Year Journey

Where I Started — and What College Actually Prepared Me For

My First Internship: FlexEHR and What Working Remotely Taught Me

GeeksforGeeks Internship: The DSA Grind That Changed Everything

Getting My First Full-Time Job at Typof

The Skills Gap Nobody Talks About

How I Landed at an AI Startup (and What That Actually Means Day-to-Day)

Building webguardx — My First Open Source Project

5 Honest Lessons from 2 Years in the Industry

What I'd Tell My Fresher Self

Key Takeaways

What's Next for Me

Why --legacy-peer-deps is Better than --force in npm

Understanding Peer Dependencies

The --legacy-peer-deps Flag

Benefits of Using --legacy-peer-deps

The --force Flag

Risks of Using --force

When to Use Each Flag

Use --legacy-peer-deps When:

Avoid Using --force Unless:

Example: Resolving Conflicts

Using --legacy-peer-deps:

Using --force:

Why --legacy-peer-deps is the Better Choice

Best Practices

Conclusion

Mastering React Quill: A Step-by-Step Guide to Implement a Rich Text Editor in Your React App

Conclusion

Happy Coding! 🚀

How To Write Best Git Commit

JavaScript Event Loop: A Deep Dive

What is the JavaScript Event Loop?

Key Components of the Event Loop

Step-by-Step Execution:

Microtasks and Macrotasks

Example with Promises

Step-by-Step Execution:

Best Practices for Using the Event Loop

Conclusion

50 basic Linux commands

LinuxCommands #SysAdmin #DeveloperTips #LinuxTips #DevOps #CodingLife #CommandLine #LinuxTutorial #aws #linux #bash #devops

Why a .gitignore File is Essential for Your Projects

Understanding JavaScript Promises

The `--legacy-peer-deps` Flag

Benefits of Using `--legacy-peer-deps`

The `--force` Flag

Risks of Using `--force`

Use `--legacy-peer-deps` When:

Avoid Using `--force` Unless:

Using `--legacy-peer-deps`:

Using `--force`:

Why `--legacy-peer-deps` is the Better Choice