DEV Community: Ashish Vaghela

Using Google Sheets as a CMS: A Simple, Powerful Approach to Content Management

Ashish Vaghela — Thu, 05 Feb 2026 11:31:23 +0000

Content Management Systems (CMS) are essential for modern websites, but they often come with complexity, cost, and maintenance overhead. What if you could use a tool that everyone already knows Google Sheets as your CMS? In this tutorial, I'll show you how to build a lightweight, efficient content management system using Google Sheets and JavaScript.

Why Google Sheets as a CMS?

Before diving into the technical implementation, let's understand why this approach makes sense:

Zero Cost: Google Sheets is free, with no hosting or licensing fees
User-Friendly: Non-technical team members can update content without learning a new interface
Real-Time Collaboration: Multiple people can edit content simultaneously
Version History: Built-in revision tracking
No Database Required: Eliminates database setup and maintenance
Familiar Interface: Everyone knows how to use spreadsheets

How It Works

The workflow is straightforward:

Create a Google Sheet with your content
Publish the sheet as CSV
Fetch the CSV data in your website using JavaScript
Parse and display the data dynamically

Setup Guide

Step 1: Create Your Google Sheet

First, create a Google Sheet with your content. Here's an example structure for a blog or events website:

id	title	description	date	image_url	category
1	First Post	This is my first post	2024-01-15	https://example.com/img1.jpg	Tech
2	Second Post	Another great post	2024-01-20	https://example.com/img2.jpg	Design

Important: The first row should contain your column headers (field names).

Step 2: Publish Your Sheet as CSV

In Google Sheets, click on File → Share → Publish to web
Select the specific sheet you want to publish
Choose Comma-separated values (.csv) as the format
Click Publish
Copy the generated URL (it will look like: https://docs.google.com/spreadsheets/d/e/{SHEET_ID}/pub?output=csv)

Step 3: Implement the JavaScript Fetcher

Now, let's create the JavaScript code to fetch and parse this CSV data.

Basic CSV Fetcher

/**
 * Fetches and parses CSV data from Google Sheets
 * @param {string} csvUrl - The published CSV URL from Google Sheets
 * @returns {Promise<Array>} Array of objects representing rows
 */
async function fetchGoogleSheetData(csvUrl) {
  try {
    const response = await fetch(csvUrl);

    if (!response.ok) {
      throw new Error(`HTTP error! status: ${response.status}`);
    }

    const csvText = await response.text();
    return parseCSV(csvText);
  } catch (error) {
    console.error('Error fetching Google Sheet data:', error);
    return [];
  }
}

/**
 * Parses CSV text into an array of objects
 * @param {string} csvText - Raw CSV text
 * @returns {Array} Array of objects
 */
function parseCSV(csvText) {
  const lines = csvText.split('\n');
  const headers = lines[0].split(',').map(header => header.trim());
  const data = [];

  for (let i = 1; i < lines.length; i++) {
    if (lines[i].trim() === '') continue; // Skip empty lines

    const values = parseCSVLine(lines[i]);
    const row = {};

    headers.forEach((header, index) => {
      row[header] = values[index] ? values[index].trim() : '';
    });

    data.push(row);
  }

  return data;
}

/**
 * Parses a single CSV line, handling quoted values
 * @param {string} line - Single CSV line
 * @returns {Array} Array of values
 */
function parseCSVLine(line) {
  const values = [];
  let currentValue = '';
  let insideQuotes = false;

  for (let i = 0; i < line.length; i++) {
    const char = line[i];

    if (char === '"') {
      insideQuotes = !insideQuotes;
    } else if (char === ',' && !insideQuotes) {
      values.push(currentValue);
      currentValue = '';
    } else {
      currentValue += char;
    }
  }

  values.push(currentValue); // Push the last value
  return values;
}

Step 4: Display the Data

Now let's create functions to display the fetched data on your webpage.

/**
 * Renders data to the DOM
 * @param {Array} data - Array of data objects
 * @param {string} containerId - ID of the container element
 */
function renderData(data, containerId) {
  const container = document.getElementById(containerId);

  if (!container) {
    console.error(`Container with id "${containerId}" not found`);
    return;
  }

  container.innerHTML = ''; // Clear existing content

  data.forEach(item => {
    const card = createCard(item);
    container.appendChild(card);
  });
}

/**
 * Creates a card element for a single data item
 * @param {Object} item - Data object
 * @returns {HTMLElement} Card element
 */
function createCard(item) {
  const card = document.createElement('div');
  card.className = 'card';

  card.innerHTML = `
    <div class="card-image">
      <img src="${item.image_url || 'placeholder.jpg'}" alt="${item.title}">
    </div>
    <div class="card-content">
      <h3>${item.title}</h3>
      <p class="card-meta">
        <span class="category">${item.category}</span>
        <span class="date">${formatDate(item.date)}</span>
      </p>
      <p class="card-description">${item.description}</p>
    </div>
  `;

  return card;
}

/**
 * Formats date string
 * @param {string} dateString - Date in YYYY-MM-DD format
 * @returns {string} Formatted date
 */
function formatDate(dateString) {
  const options = { year: 'numeric', month: 'long', day: 'numeric' };
  const date = new Date(dateString);
  return date.toLocaleDateString('en-US', options);
}

Step 5: Initialize Your Application

Create the main initialization function:

/**
 * Main initialization function
 */
async function initializeApp() {
  // Replace this with your actual published CSV URL
  const SHEET_URL = 'https://docs.google.com/spreadsheets/d/e/YOUR_SHEET_ID/pub?output=csv';

  // Show loading state
  showLoader();

  try {
    const data = await fetchGoogleSheetData(SHEET_URL);

    if (data.length === 0) {
      showEmptyState();
      return;
    }

    renderData(data, 'content-container');
  } catch (error) {
    showErrorState(error.message);
  } finally {
    hideLoader();
  }
}

function showLoader() {
  const container = document.getElementById('content-container');
  container.innerHTML = '<div class="loader">Loading content...</div>';
}

function hideLoader() {
  const loader = document.querySelector('.loader');
  if (loader) loader.remove();
}

function showEmptyState() {
  const container = document.getElementById('content-container');
  container.innerHTML = '<div class="empty-state">No content available</div>';
}

function showErrorState(message) {
  const container = document.getElementById('content-container');
  container.innerHTML = `<div class="error-state">Error loading content: ${message}</div>`;
}

// Initialize when DOM is ready
document.addEventListener('DOMContentLoaded', initializeApp);

Step 6: HTML Structure

Here's the HTML structure for your page:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Google Sheets CMS Example</title>
  <link rel="stylesheet" href="styles.css">
</head>
<body>
  <header>
    <h1>My Google Sheets Powered Website</h1>
    <p>Content managed through Google Sheets</p>
  </header>

  <main>
    <div id="content-container" class="grid"></div>
  </main>

  <script src="app.js"></script>
</body>
</html>

Step 7: Styling (CSS)

Add some basic styling to make your content look good:

* {
  margin: 0;
  padding: 0;
  box-sizing: border-box;
}

body {
  font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, Oxygen, Ubuntu, Cantarell, sans-serif;
  line-height: 1.6;
  color: #333;
  background-color: #f5f5f5;
}

header {
  background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);
  color: white;
  padding: 3rem 2rem;
  text-align: center;
}

header h1 {
  font-size: 2.5rem;
  margin-bottom: 0.5rem;
}

header p {
  font-size: 1.1rem;
  opacity: 0.9;
}

main {
  max-width: 1200px;
  margin: 0 auto;
  padding: 2rem;
}

.grid {
  display: grid;
  grid-template-columns: repeat(auto-fill, minmax(300px, 1fr));
  gap: 2rem;
}

.card {
  background: white;
  border-radius: 8px;
  overflow: hidden;
  box-shadow: 0 2px 8px rgba(0, 0, 0, 0.1);
  transition: transform 0.3s ease, box-shadow 0.3s ease;
}

.card:hover {
  transform: translateY(-5px);
  box-shadow: 0 4px 16px rgba(0, 0, 0, 0.15);
}

.card-image {
  width: 100%;
  height: 200px;
  overflow: hidden;
}

.card-image img {
  width: 100%;
  height: 100%;
  object-fit: cover;
}

.card-content {
  padding: 1.5rem;
}

.card-content h3 {
  font-size: 1.5rem;
  margin-bottom: 0.5rem;
  color: #2d3748;
}

.card-meta {
  display: flex;
  justify-content: space-between;
  margin-bottom: 1rem;
  font-size: 0.9rem;
  color: #718096;
}

.category {
  background: #667eea;
  color: white;
  padding: 0.25rem 0.75rem;
  border-radius: 12px;
  font-size: 0.85rem;
}

.card-description {
  color: #4a5568;
  line-height: 1.6;
}

.loader {
  text-align: center;
  padding: 3rem;
  font-size: 1.2rem;
  color: #718096;
}

.empty-state,
.error-state {
  text-align: center;
  padding: 3rem;
  font-size: 1.1rem;
  color: #718096;
}

.error-state {
  color: #e53e3e;
}

/* Responsive Design */
@media (max-width: 768px) {
  .grid {
    grid-template-columns: 1fr;
  }

  header h1 {
    font-size: 2rem;
  }
}

Advanced Features

Filtering and Sorting

Add filtering and sorting capabilities to your CMS:

/**
 * Filters data by category
 * @param {Array} data - Original data array
 * @param {string} category - Category to filter by
 * @returns {Array} Filtered data
 */
function filterByCategory(data, category) {
  if (!category || category === 'all') return data;
  return data.filter(item => item.category === category);
}

/**
 * Sorts data by date
 * @param {Array} data - Data array to sort
 * @param {string} order - 'asc' or 'desc'
 * @returns {Array} Sorted data
 */
function sortByDate(data, order = 'desc') {
  return data.sort((a, b) => {
    const dateA = new Date(a.date);
    const dateB = new Date(b.date);
    return order === 'desc' ? dateB - dateA : dateA - dateB;
  });
}

/**
 * Searches data by title or description
 * @param {Array} data - Data array to search
 * @param {string} query - Search query
 * @returns {Array} Filtered data
 */
function searchData(data, query) {
  if (!query) return data;

  const lowerQuery = query.toLowerCase();
  return data.filter(item => 
    item.title.toLowerCase().includes(lowerQuery) ||
    item.description.toLowerCase().includes(lowerQuery)
  );
}

Caching for Better Performance

Implement caching to reduce API calls:

/**
 * Cache manager for Google Sheets data
 */
class SheetCacheManager {
  constructor(cacheKey = 'sheet_data', cacheDuration = 5 * 60 * 1000) {
    this.cacheKey = cacheKey;
    this.cacheDuration = cacheDuration; // 5 minutes default
  }

  /**
   * Gets cached data if still valid
   * @returns {Array|null} Cached data or null
   */
  get() {
    const cached = localStorage.getItem(this.cacheKey);
    if (!cached) return null;

    try {
      const { data, timestamp } = JSON.parse(cached);
      const now = Date.now();

      if (now - timestamp < this.cacheDuration) {
        console.log('Using cached data');
        return data;
      }

      // Cache expired
      this.clear();
      return null;
    } catch (error) {
      console.error('Error reading cache:', error);
      this.clear();
      return null;
    }
  }

  /**
   * Saves data to cache
   * @param {Array} data - Data to cache
   */
  set(data) {
    const cacheObject = {
      data,
      timestamp: Date.now()
    };
    localStorage.setItem(this.cacheKey, JSON.stringify(cacheObject));
  }

  /**
   * Clears the cache
   */
  clear() {
    localStorage.removeItem(this.cacheKey);
  }
}

/**
 * Enhanced fetch with caching
 */
async function fetchWithCache(csvUrl) {
  const cache = new SheetCacheManager();

  // Try to get from cache first
  const cachedData = cache.get();
  if (cachedData) {
    return cachedData;
  }

  // Fetch fresh data
  const data = await fetchGoogleSheetData(csvUrl);

  // Save to cache
  if (data.length > 0) {
    cache.set(data);
  }

  return data;
}

Multiple Sheets Support

Handle multiple sheets for different content types:

/**
 * Configuration for multiple sheets
 */
const SHEETS_CONFIG = {
  blog: 'https://docs.google.com/spreadsheets/d/e/SHEET_ID_1/pub?output=csv',
  events: 'https://docs.google.com/spreadsheets/d/e/SHEET_ID_2/pub?output=csv',
  team: 'https://docs.google.com/spreadsheets/d/e/SHEET_ID_3/pub?output=csv'
};

/**
 * Fetches data from multiple sheets
 * @param {Object} config - Configuration object with sheet URLs
 * @returns {Promise<Object>} Object with data from all sheets
 */
async function fetchAllSheets(config) {
  const results = {};

  const promises = Object.entries(config).map(async ([key, url]) => {
    try {
      const data = await fetchGoogleSheetData(url);
      results[key] = data;
    } catch (error) {
      console.error(`Error fetching ${key}:`, error);
      results[key] = [];
    }
  });

  await Promise.all(promises);
  return results;
}

/**
 * Example usage
 */
async function initMultipleSheets() {
  const allData = await fetchAllSheets(SHEETS_CONFIG);

  renderData(allData.blog, 'blog-container');
  renderData(allData.events, 'events-container');
  renderData(allData.team, 'team-container');
}

Complete Example: Events Website

Here's a complete working example for an events website:

// config.js
const CONFIG = {
  SHEET_URL: 'YOUR_PUBLISHED_CSV_URL_HERE',
  CACHE_DURATION: 5 * 60 * 1000, // 5 minutes
  CONTAINER_ID: 'events-container'
};

// main.js
class EventsManager {
  constructor(config) {
    this.config = config;
    this.cache = new SheetCacheManager('events_data', config.CACHE_DURATION);
    this.data = [];
    this.filteredData = [];
  }

  async init() {
    await this.loadData();
    this.setupEventListeners();
    this.render();
  }

  async loadData() {
    try {
      const cachedData = this.cache.get();

      if (cachedData) {
        this.data = cachedData;
      } else {
        const response = await fetch(this.config.SHEET_URL);
        const csvText = await response.text();
        this.data = parseCSV(csvText);
        this.cache.set(this.data);
      }

      this.filteredData = [...this.data];
    } catch (error) {
      console.error('Error loading data:', error);
      this.showError('Failed to load events. Please try again later.');
    }
  }

  setupEventListeners() {
    const searchInput = document.getElementById('search');
    const categoryFilter = document.getElementById('category-filter');
    const sortSelect = document.getElementById('sort');

    if (searchInput) {
      searchInput.addEventListener('input', (e) => this.handleSearch(e.target.value));
    }

    if (categoryFilter) {
      categoryFilter.addEventListener('change', (e) => this.handleFilter(e.target.value));
    }

    if (sortSelect) {
      sortSelect.addEventListener('change', (e) => this.handleSort(e.target.value));
    }
  }

  handleSearch(query) {
    this.filteredData = searchData(this.data, query);
    this.render();
  }

  handleFilter(category) {
    this.filteredData = filterByCategory(this.data, category);
    this.render();
  }

  handleSort(order) {
    this.filteredData = sortByDate(this.filteredData, order);
    this.render();
  }

  render() {
    const container = document.getElementById(this.config.CONTAINER_ID);

    if (!container) return;

    if (this.filteredData.length === 0) {
      container.innerHTML = '<div class="empty-state">No events found</div>';
      return;
    }

    container.innerHTML = '';
    this.filteredData.forEach(event => {
      const card = this.createEventCard(event);
      container.appendChild(card);
    });
  }

  createEventCard(event) {
    const card = document.createElement('div');
    card.className = 'event-card';

    const eventDate = new Date(event.date);
    const isPast = eventDate < new Date();

    card.innerHTML = `
      <div class="event-image">
        <img src="${event.image_url}" alt="${event.title}">
        ${isPast ? '<span class="badge past">Past Event</span>' : '<span class="badge upcoming">Upcoming</span>'}
      </div>
      <div class="event-content">
        <h3>${event.title}</h3>
        <p class="event-date">${formatDate(event.date)}</p>
        <p class="event-description">${event.description}</p>
        <div class="event-footer">
          <span class="category">${event.category}</span>
          ${!isPast ? '<button class="register-btn">Register</button>' : ''}
        </div>
      </div>
    `;

    return card;
  }

  showError(message) {
    const container = document.getElementById(this.config.CONTAINER_ID);
    container.innerHTML = `<div class="error-state">${message}</div>`;
  }
}

// Initialize the app
document.addEventListener('DOMContentLoaded', () => {
  const eventsManager = new EventsManager(CONFIG);
  eventsManager.init();
});

Best Practices

1. Data Structure

Keep your Google Sheet organized:

Use clear, descriptive column headers
Maintain consistent data types in each column
Avoid special characters in headers (use underscores instead of spaces)
Keep one type of content per sheet

2. Performance Optimization

Implement caching: Reduce API calls by caching data locally
Lazy loading: Load images only when they're in viewport
Pagination: For large datasets, implement pagination
Debouncing: Debounce search inputs to reduce processing

function debounce(func, wait) {
  let timeout;
  return function executedFunction(...args) {
    const later = () => {
      clearTimeout(timeout);
      func(...args);
    };
    clearTimeout(timeout);
    timeout = setTimeout(later, wait);
  };
}

// Usage
const debouncedSearch = debounce((query) => {
  handleSearch(query);
}, 300);

3. Error Handling

Always handle potential errors gracefully:

async function robustFetch(url, retries = 3) {
  for (let i = 0; i < retries; i++) {
    try {
      const response = await fetch(url);
      if (!response.ok) throw new Error(`HTTP ${response.status}`);
      return await response.text();
    } catch (error) {
      if (i === retries - 1) throw error;
      await new Promise(resolve => setTimeout(resolve, 1000 * (i + 1)));
    }
  }
}

4. Security Considerations

Never store sensitive information in public Google Sheets
Validate and sanitize all data before rendering
Use Content Security Policy (CSP) headers
Implement rate limiting if needed

5. SEO Optimization

For better SEO with dynamic content:

// Add meta tags dynamically
function updateMetaTags(data) {
  const firstItem = data[0];
  if (!firstItem) return;

  document.title = `${firstItem.title} | Your Site Name`;

  const metaDescription = document.querySelector('meta[name="description"]');
  if (metaDescription) {
    metaDescription.setAttribute('content', firstItem.description);
  }
}

Limitations and Considerations

While Google Sheets as a CMS is powerful, be aware of these limitations:

Rate Limits: Google has rate limits on published sheets. For high-traffic sites, consider caching aggressively.
Real-Time Updates: Changes in the sheet aren't instantly reflected. Use cache invalidation strategies.
Data Size: Large datasets (1000+ rows) may slow down parsing. Consider pagination or splitting data.
No Authentication: Published sheets are public. Don't store sensitive data.
Limited Querying: Unlike databases, you can't query specific data server-side. All filtering happens client-side.

Conclusion

Using Google Sheets as a CMS provides a simple, cost-effective solution for content management, especially for small to medium-sized projects. It empowers non-technical team members to manage content while giving developers a straightforward API to work with.

The approach works best for:

Small business websites
Event listings
Team directories
Product catalogs
Blog posts
Portfolio sites

For projects requiring complex relationships, user authentication, or real-time collaboration features, a traditional CMS or database solution might be more appropriate. However, for straightforward content needs, Google Sheets offers an unbeatable combination of simplicity, familiarity, and zero cost.

Additional Resources

---]

Thanks @abhishek_singh_116d0ab505 for the Concept and Idea.

Happy coding! If you found this tutorial helpful, feel free to share it with others who might benefit from this approach.

The AI Testing Paradox: How Automated Test Generation Might Kill Unit Testing

Ashish Vaghela — Mon, 24 Nov 2025 06:29:00 +0000

There's a troubling trend I've been observing in software development, and it keeps me up at night. AI-powered code generation has become incredibly popular, and one of its most promoted use cases is generating unit tests. On the surface, this seems like a clear win. who wouldn't want to automate the tedious work of writing tests? But I'm increasingly convinced that AI-generated tests, particularly in the hands of inexperienced developers, might actually destroy the practice of unit testing rather than enhance it.

The Death Spiral

Let me walk you through how this plays out. An inexperienced developer writes some production code. They've heard that tests are important, so they ask their AI assistant to generate a test suite. Within seconds, they have hundreds of lines of testing code, complete with mocks, assertions, and edge cases. The developer glances at it, sees green checkmarks in CI, and merges it. Mission accomplished, right?

Not quite. Here's the problem: that developer never learned the fundamentals of good unit testing. They can't distinguish between a test that verifies behavior and one that's merely reverse-engineered from the implementation. They don't recognize over-mocking, tight coupling to implementation details, or tests that will break with every minor refactor. They certainly aren't in the mood to carefully review hundreds of lines of auto-generated code to assess its quality.

The False Confidence Problem

These low-quality tests create a dangerous illusion. The codebase has impressive test coverage numbers. CI is green. Everything looks professional. But beneath the surface, the tests are fragile, verbose, and fundamentally flawed. They're over-mocked to the point of meaninglessness, testing implementation rather than behavior, lacking hermetic isolation, and coupling tightly to code structure rather than requirements.

When bugs inevitably slip through to production despite all those tests, what conclusion do developers draw? When refactoring becomes a nightmare because dozens of tests break from the smallest structural change, what lesson do they learn? They don't think "our tests are poorly designed." They think "unit testing doesn't work." They conclude that the practice itself is flawed, that tests are just bureaucratic overhead, that coverage metrics are vanity metrics.

The Tragic Irony

And here's the irony that haunts me: AI was supposed to make unit testing easier and more accessible. It promised to remove the friction of writing tests so developers could focus on building features. Instead, by short-circuiting the learning process, it risks creating a generation of developers who never experience what truly good tests feel like. They never know the confidence of refactoring with a solid test suite. They never feel the clarity that comes from test-driven development forcing you to think about your API design. They never experience tests as living documentation that actually helps you understand the codebase.

The practice of unit testing—one of the most valuable disciplines in software engineering—gets abandoned not because it failed, but because it was never actually practiced properly in the first place.

The Path Forward

I'm not saying AI has no place in testing. Far from it. But we need to be thoughtful about how we use it. AI should be a tool that accelerates developers who already understand testing fundamentals, not a crutch that allows them to avoid learning those fundamentals entirely.

Here's what I think we need:

Education first, automation second. Before developers use AI to generate tests, they should learn what makes a good test. They should practice writing tests by hand, make mistakes, feel the pain of brittle tests, and learn to recognize quality.

AI as a pair programmer, not a replacement. Use AI to handle boilerplate and suggest patterns, but critically evaluate every test it generates. Treat its output as a starting point for discussion, not gospel.

Focus on test design principles. Whether written by humans or AI, good tests share common characteristics: they test behavior not implementation, they're resilient to refactoring, they fail for the right reasons, and they're readable enough to serve as documentation.

Code review that matters. Test code deserves the same scrutiny as production code. Perhaps more, since poor tests can actively harm a codebase while providing a false sense of security.

Conclusion

Unit testing remains one of the most powerful practices in software development. When done well, it enables confident refactoring, catches regressions, documents behavior, and improves design. But "done well" is the critical phrase. AI can help us write tests faster, but it can't teach us what makes tests valuable. That wisdom still requires human learning, human judgment, and human experience.

Don't let AI-generated slop kill your appreciation for well-crafted tests. Learn the fundamentals. Build intuition. Then, and only then, use AI to accelerate your work. The future of software quality depends on it.

From Overwhelmed to Empowered: My Hacktoberfest 2025 Journey

Ashish Vaghela — Thu, 30 Oct 2025 18:18:47 +0000

The Starting Line

October 1st, 2025. Hacktoberfest had just begun, and I was staring at GitHub feeling completely lost. Everyone seemed to know exactly which projects to contribute to and how to craft the perfect pull request. I had been coding for a while, but open source felt like an exclusive club I couldn't access.

Then I asked myself: What problems do I actually care about solving?

That question changed everything.

Finding My Path: Open Source Weekend

Instead of chasing popular repositories, I looked for projects aligned with my interests. I've always been passionate about community building and making tech more accessible. That's when I found Open Source Weekend.

The Registration Flow Challenge

The Problem: New users were abandoning event registration halfway through. The maintainers knew it was a UX issue but weren't sure where the friction was.

What I Did: I went through the registration process myself, taking notes on every confusing moment. Then I submitted a PR that added a progress bar, consolidated redundant forms, improved error messages, and added helpful tooltips.

The Learning: This was my first time working with their tech stack. I spent an entire Saturday reading contribution guidelines and understanding their architecture. The maintainers were incredibly helpful, pointing me to similar implementations I could reference.

Key Insight: Good contributions aren't about showing off skills. They're about solving real user problems. Every line of code I wrote, I kept thinking: Would someone understand this? Would it make their experience better?

Documentation That Actually Helps

After my first PR merged, I tackled their documentation. It was comprehensive for experienced developers but intimidating for newcomers. I created a "Quick Start" guide with screenshots, common errors and fixes, and explanations of why each step mattered.

Within a week, three new contributors submitted their first PRs, specifically mentioning the guide helped them get started. That felt better than any code contribution.

Scaling Up: Open Source Day

With experience from Open Source Weekend, I discovered their sister project: Open Source Day. This platform scales the weekend concept into day-long, theme-focused events.

Building for the Organizers

The project needed help with their event organizer dashboard, specifically real-time analytics showing which projects were getting the most activity during events.

This was the most complex contribution I'd tackled. My first PR attempt worked but wasn't scalable. A senior maintainer left detailed feedback explaining why my approach would cause problems as events grew larger.

Initially, I felt defensive. Then I realized this was free mentorship from someone with years more experience. I rewrote the feature using their suggestions, learning about proper state management and efficient data fetching in the process.

The Breakthrough: After three rounds of revisions, my PR was merged. But the real victory was understanding I had leveled up as a developer. I could now architect features for scale, not just make things work locally.

The Meta Moment: While building tools for Open Source Day, something clicked. I was contributing to a platform that helps people organize events where others contribute to open source. Every feature I built would enable organizers to run better events, which would help more people make their first contributions.

That's when I truly understood the ecosystem nature of open source.

The Wild Card: Akash Network

Halfway through October, I made a deliberate decision to leave my comfort zone. I wanted to challenge myself with something completely outside my experience: Akash Network.

Learning a New World

Akash is a decentralized cloud computing marketplace. Anyone with spare computing resources can rent them out, and anyone needing infrastructure can deploy applications without relying on AWS or Google Cloud.

My First Week: I didn't contribute any code. I couldn't. I needed to learn. I read documentation, deployed test applications, joined their Discord, and watched tutorials about blockchain basics and container orchestration.

Multiple times I thought about giving up. Everyone seemed to speak a language I didn't understand. But I kept showing up, kept asking questions, and slowly it started making sense.

Documentation for the Confused

I noticed Akash's documentation was technically accurate but assumed you already understood blockchain and distributed systems. There was a gap between "what is Akash" and "here's how to deploy your first app."

I could fill that gap. I had just crossed that bridge myself.

I created "Deploying Your First App on Akash: A Guide for Web Developers New to Decentralized Infrastructure." It explained blockchain concepts through web development analogies, walked through deployment step-by-step, covered common mistakes I'd made, and provided resources for learning more.

The Response: This guide became my most impactful contribution. Several developers commented that it was exactly what they needed. A maintainer suggested incorporating parts into the official documentation.

What I Learned: Sometimes the best person to write beginner documentation is someone who just finished being a beginner. You remember what was confusing in ways that experts have forgotten.

Going Technical

With confidence built, I tackled more technical contributions:

Expanded test coverage for their deployment CLI tool, adding tests for error conditions like invalid configs, network timeouts, and insufficient funds
Created deployment helper scripts that simplified common patterns, letting new users start with templates and modify them as they learned

These weren't glamorous contributions, but they made the tool more reliable for everyone.

What I Learned

The Patterns That Emerged

1. Documentation Is Everyone's Responsibility

If something confused me, it would confuse others. Don't just fix your confusion and move on. Document the solution so the next person doesn't hit the same wall.

2. Small Contributions Multiply

Fixing a confusing error message, adding a missing example, improving variable names. These small changes remove friction for potentially hundreds of future contributors.

3. Community Makes the Difference

The projects where I contributed most had welcoming, responsive maintainers who gave constructive feedback, celebrated contributions, and made me feel valued.

4. Learning Happens in Public

Before Hacktoberfest, I would have been embarrassed to submit imperfect code. Now I understand that's the point. My "not great" first attempt at the analytics dashboard taught me more than a dozen perfect solo projects.

How Hacktoberfest Changed Me

Before October: Open source felt like something other people did. Talented developers with computer science degrees. Not me.

After October: I see open source as a spectrum of contributions. You don't need to be the best developer. You need to care about solving problems, be willing to learn, communicate clearly, take feedback gracefully, and show up consistently.

I can do all of those things. So can most developers.

What I Gained

Technical Skills: I entered comfortable with frontend development. I'm leaving with experience in backend architecture, blockchain technology, cross-platform development, advanced Git workflows, and performance optimization.

Network: I connected with maintainers and contributors worldwide. Some became mentors, others collaborators, a few became friends.

Perspective: Contributing to Akash changed how I think about infrastructure. Open Source Weekend and Day taught me technology serves people, not the other way around.

Confidence: I trust my ability to figure things out. That confidence extends beyond open source into my day job and life.

The Challenges

Let me be honest about what was hard:

Imposter Syndrome: Every new project, a voice said "you're not good enough." But every merged contribution quieted that voice a little more.

Time Management: Balancing contributions with work and life required discipline. I learned to set boundaries. Not every issue needed solving immediately.

Technical Gaps: Each concept I needed to learn felt like a mountain to climb. But I climbed them one tutorial at a time, one question in Discord at a time.

Feedback That Stung: Being told my code "worked but wasn't maintainable" hurt my pride. But it made me better. I learned to separate my ego from my code.

Advice for Your First Hacktoberfest

1. Start With Problems You Care About

Find projects that solve problems you actually face. Genuine interest sustains motivation when contributions get difficult.

2. Read More Than You Think You Need To

Spend time understanding the project's goals, contribution guidelines, and codebase structure before submitting PRs.

3. Start Small, Then Scale

My first contribution was fixing a typo. It taught me the PR process and gave me confidence for bigger issues.

4. Ask Questions Early and Often

Every time I hesitated to ask (because it felt too basic), I wasted time going the wrong direction. Maintainers want you to ask questions.

5. Embrace the Messy Middle

Your first PR will probably need revisions. You might make mistakes. That's not failure, that's learning.

6. Focus on Impact, Not Numbers

One meaningful contribution beats ten trivial ones. Quality over quantity.

7. Plan to Continue After October

The best outcome isn't winning prizes. It's finding projects you care enough about to keep contributing.

Looking Forward

I'm still active in all three projects. Open Source Weekend is planning a major Q4 release I'm part of. I'm helping coordinate a local Open Source Day event. Akash's roadmap includes developer experience improvements I want to contribute to.

The Most Exciting Next Step: I'm organizing a local Open Source Weekend event in my city for December. I'm literally using infrastructure I helped build to build more infrastructure for open source contribution. That recursive impact is beautiful.

What Open Source Means to Me Now

Before Hacktoberfest, open source was free software I used.

Now, open source is:

A Learning Platform where I study code from experienced developers and get feedback that makes me better.

A Community where people from different backgrounds collaborate toward shared goals.

A Way to Give Back to the collective knowledge that made my success possible.

A Force for Accessibility that democratizes technology for everyone.

A Practice of Humility that reminds me how much I can learn from others.

An Act of Optimism betting on a future where we build better things together than alone.

The Real Prize

Whether this post wins or not, I've already won.

I won when my documentation helped someone make their first contribution.

I won when maintainers trusted me with complex issues.

I won when I stopped seeing myself as an outsider and started seeing myself as a contributor.

I won when I realized open source isn't about being the best developer in the room. It's about making the room better for everyone who enters.

That's what I brought to Open Source Weekend, Open Source Day, and Akash Network this October. That's what I'll bring to every contribution that follows.

Your Turn

What about you?

If you participated in Hacktoberfest 2025, what projects did you contribute to? What surprised you? What will you keep contributing to after October?

If you're thinking about contributing but haven't started, what's holding you back? What would make taking that first step easier?

Let's talk in the comments. Share your stories, ask your questions, offer your advice. That's how communities grow.

Contributing to open source? Share your journey in the comments. Let's celebrate the community that makes all of this possible.

Crafting Code with Intent: A Journey to Clarity and Collaboration

Ashish Vaghela — Tue, 19 Aug 2025 06:56:32 +0000

As a software craftsman, I see coding as an art form – a blend of creativity, logic, and storytelling. Writing code isn’t just about making things work; it’s about weaving a narrative that others can follow with ease. Beautiful code is like a heartfelt song: it resonates, it’s clear, and it invites others to make it better.

Today, let’s explore how to craft such code by communicating intent through thoughtful comments, fostering collaboration, and leaving a legacy of clarity. I’ll share practical tips, Kotlin examples, and insights to elevate your coding journey.

The Joy of Beautiful Code

Some code feels like a masterpiece. Its variable names are poetic, its logic flows like a river, and its purpose shines through every line. Reading it is like having a cheerful chat with a friend who explains everything clearly. You don’t need to guess what’s happening – the code tells you.

This kind of code is rare, often born from years of refinement and collaboration. Its abstractions feel natural, its design decisions seem inevitable, and it’s a joy to work with. It’s like savoring a perfectly spiced biryani – every bite feels just right.

But let’s be real: not all code starts this way. Software is a living entity, constantly evolving through iterations. Even the most elegant codebases begin as rough sketches, full of promise but needing polish.

The Reality of Everyday Code

Most code we write or inherit is like a half-finished painting. It does its job, but it doesn’t always reveal why it’s doing it. The what – the mechanics of the code – is usually clear enough. But the why – the reasoning behind a design choice, the purpose of a condition, or the meaning of a return value – often remains hidden.

This gap can make maintenance a challenge. Without insight into the author’s intent, future developers (including you, six months from now!) may struggle to improve or debug the code. This is where comments become our superpower, acting as signposts that guide others through our thought process.

Why Intent-Driven Comments Are Essential

Imagine diving into complex code that’s hard to decipher. Now picture finding a comment that says, “Here’s why I chose this approach.” Suddenly, the clouds part! You understand the author’s goal, and refactoring becomes a breeze.

Comments that communicate intent – the why behind the code – are like a warm handshake between developers across time.

Here’s why intent-driven comments matter:

Clarity: They explain the purpose behind design decisions, making code easier to understand.
Collaboration: They foster teamwork by sharing context, helping new developers contribute faster.
Maintainability: They simplify refactoring by revealing the author’s goals, reducing guesswork.
Kindness: They show respect for future developers, making their lives easier.

Even if your code isn’t perfect (and nobody’s is), a comment sharing your intent is a gift to the next person. It doesn’t fix messy code, but it lights the path to improvement.

Crafting Intent-Driven Comments

So, how do we write comments that communicate intent effectively?

Practical Tips:

Focus on the Why, Not the What: Avoid stating the obvious. Instead of describing what the code does, explain why it’s done that way.
Place Comments at Key Points: Add intent comments where critical logic or design decisions live – think core functions, central modules, or complex algorithms.
Keep It Concise: Be clear and to the point. A single sentence can often convey the intent.
Use Comments as a Last Resort: First, try to make the code self-explanatory with clear names and structure. Use comments for insights that code alone can’t convey.
Pair with Refactoring: Write intent comments, then refactor to make the code clearer. Delete redundant comments as the code improves.

Example: Bad vs Good Comment

Poor comment:

// Setting up the module
fun setup() { ... }

Improved version with intent:

// Prepares the device for TCP connections, handling its unreliable behavior with retries
fun prepareDeviceForTcp() {
    setup()
    doStuff()
    doOtherStuff()
}

fun main() {
    prepareDeviceForTcp()
    val socket = openSocket()
    if (socket == null) {
        throw IllegalStateException("Device is not ready for reading")
    }
}

The comment explains why the function exists – the device is unreliable and needs special care. This insight can’t be fully expressed through code alone, making the comment invaluable.

Where Do You Stand as a Coder?

We all dream of writing flawless code that earns standing ovations. But let’s be honest: even the best developers have off days. Sometimes we craft elegant solutions, and other times we’re just trying to meet a deadline. And that’s okay! Coding is a journey, not a destination.

Wherever you are – beginner, average Joe, or seasoned craftsman – intent-driven comments help you leave a positive mark. They ensure that even if your code isn’t perfect, its purpose is clear, making it easier for others to build on your work.

Ask yourself: Do I always write code that’s crystal clear? Probably not.
By adding comments that share your intent, you’re helping future developers (and future you) navigate your code with confidence.

Balancing Comments and Code

Here’s a workflow to integrate intent-driven comments into your coding practice:

Write the Code: Get your logic working, even if it’s rough.
Add Intent Comments: Note why you made key decisions, especially in complex or critical areas.
Refactor: Improve variable names, simplify logic, and break down complex functions.
Prune Comments: Remove any comments that become redundant as the code becomes self-explanatory.
Preserve Intent: Keep comments that explain why the code exists or why a specific approach was chosen.

Example:

// Ensures the device is ready for TCP connections, retrying setup to handle frequent hardware glitches
fun ensureDeviceReadyForTcp() {
    repeat(3) { // Retry up to 3 times
        setup()
        if (isDeviceReady()) return
        Thread.sleep(100) // Brief pause before retry
    }
    throw IllegalStateException("Device failed to initialize after retries")
}

fun startServer() {
    ensureDeviceReadyForTcp()
    val socket = openSocket()
    if (socket == null) {
        throw IllegalStateException("Socket could not be opened")
    }
    // Proceed with server logic
}

The function name and structure are clear, but the comment adds context that code alone can’t provide.

Fostering Collaboration Through Intent

Intent-driven comments do more than clarify code – they build bridges between developers. They create a culture of trust and collaboration, where everyone feels supported.

When you share your thought process, you’re inviting others to join the journey, making it easier for them to contribute ideas or fixes.

Example:

// Uses a custom sorting algorithm because the default one was too slow for our large dataset
fun sortLargeDataset(data: List<Item>): List<Item> {
    // Custom sorting logic
    return data // Placeholder
}

This comment tells the next developer why you deviated from the standard approach. They can now decide whether to optimize further or stick with your solution, armed with your reasoning.

Final Thoughts

Writing code is a craft, and like any craft, it’s about growth, care, and connection. We’re not infallible coding wizards – we’re human, learning every day. By weaving intent-driven comments into our code, we’re not just solving problems; we’re telling stories, guiding others, and building a legacy of clarity.

So, embrace your inner craftsman. Write code with purpose, sprinkle in thoughtful comments, and refactor with love. Let’s create software that doesn’t just work but inspires – like a beautifully told tale that others can’t wait to continue.

What’s your approach to communicating intent in code?
Share your thoughts in the comments below – I’d love to hear your story!

Happy coding, and let’s keep crafting with intent!

Mastering JUnit: Techniques from Victor Rentea's Toolbox 🧰

Ashish Vaghela — Fri, 08 Nov 2024 05:59:40 +0000

Are you ready to test like a pro, or just tired of flaky tests? At Victor Rentea's recent meetup, we delved into the world of JUnit, where testing isn’t just a chore—it’s an art. From intercepting test execution to ditching assertEquals for something better, here’s the breakdown with a dash of humor and visuals to keep you awake.

1. Avoid the Waste: Feature Files Nobody Reads 🗑️

(I don't believe in this)

If there’s one thing Victor warned us about, it’s WASTE. Imagine toiling over .feature files that no businessperson ever approves. That's like building a ship for people who never plan to sail! Don’t maintain something that doesn’t have value; your tests should be assets, not liabilities. ⚖️

Pro Tip: Before you dive into feature files, ask yourself: "Will the business actually care?" If not, simplify or refocus those test cases.

Personal Thoughts 💭: I believe feature files should be written by developers, not even QAs or business people. Even if a businessperson isn't interested, these files are still valuable for maintaining quality and ensuring the code is readable by humans.

2. Say Goodbye to `assertEquals` 👋

assertEquals? We don’t know her. In Victor’s world, assertEquals is yesterday’s news. Why? Because AssertJ and Hamcrest give us way more readable, fluent assertions. Here’s a taste:

// Using AssertJ for clarity
assertThat(myList).contains("Apple").doesNotContain("Orange");

See the difference? AssertJ makes it more obvious what’s expected, giving you readable and maintainable tests. 📜

3. Parameterized Tests: Go Orthogonal or Go Home 🏠

When it comes to parameterized tests, low multicollinearity is key. What does that mean? Think of it like the spice mix in your favorite dish—too many overlapping flavors, and you end up with a mess. So, keep your test parameters orthogonal (fancy word for "non-overlapping") to avoid redundancy and ensure you’re truly testing unique combinations. 🍲

Best Practice: Avoid overlapping parameters that can muddy up your results and make test failures harder to diagnose.

4. From Flaky to Rock-Solid: @RepeatedTest 🛠️

We’ve all been there—tests that pass locally but fail in CI, or as we lovingly call them, "flaky tests." Enter @RepeatedTest, the annotation for the ultimate stress test. This lets you repeat a test several times to catch those pesky edge cases that only show up on the third or fourth run.

@RepeatedTest(10)
void shouldPassAllTheTime() {
    // Flaky code fixed with multiple runs
}

This isn’t just a “try until you pass” game; it’s about consistency and rooting out hidden bugs. 🐞

5. Profiling Tests and OutputCapture 🔍

Imagine running your tests with no clue what’s going on behind the scenes. OutputCapture to the rescue! Use this to capture and analyze your output, giving you insights into what your tests are actually doing. Profiling tests is like a health check-up for your code—you get to see what’s slowing you down and optimize as needed. 🩺

Essential Tools You’ll Need 🧰

Victor recommended a range of tools to supercharge your JUnit testing:

WireMock 🕹️: A tool for mocking out external services and dependencies. With WireMock, you can simulate HTTP responses, allowing you to test your application’s behavior without needing access to the real service. This is especially useful in microservices architecture, where services may depend on external APIs that are difficult to control in test environments.
@SpringBootTest & @ActiveProfiles 🏗️: These annotations in Spring Boot make it easier to control test environments. @SpringBootTest sets up a Spring application context for integration testing, while @ActiveProfiles allows you to specify which profiles should be active during the test. This way, you can isolate configurations and environments for testing, development, and production.
@cucumber & @ContextConfiguration 🥒: For behavior-driven development (BDD) with Cucumber, @cucumber helps integrate your tests with a Cucumber framework. @ContextConfiguration is used to specify application contexts in Spring Boot, allowing for smooth integration with Cucumber for writing and executing feature files that reflect real-world scenarios.

These tools streamline your testing process, making it possible to test complex scenarios with a consistent setup, saving you from manual setup and tear-down for every test run.

Books & Resources for Further Mastery 📚

If you’re hungry for more, here’s Victor’s recommended reading and watching list:

Books:
- Art of Unit Testing by Roy Osherove
- TDD by Example by Kent Beck
- Growing Object-Oriented Software, Guided by Tests by Steve Freeman and Nat Pryce
YouTube Talks:
- Devoxx UK: Testing Like a Pro by Victor Rentea
- Testing Microservices by Victor Rentea

Wrapping Up 🎉

JUnit isn’t just a testing framework; it’s a philosophy. Use custom annotations wisely, master parameterized tests, and remember, if no one’s reading those .feature files, maybe it’s time to hit delete. As Victor would say, testing is an art—one that requires mastery, dedication, and a good sense of humor. 😄

bibliography

The Hidden Dangers of Programming: A Lesson From Childhood 🛠️💻

Ashish Vaghela — Fri, 09 Aug 2024 18:13:59 +0000

In the world of software development, it's easy to fall into the trap of focusing on performance. With tools like StackOverflow, ChatGPT, and the ease of copying and pasting code, there's often more concern with the results than understanding the underlying idea. But is this approach really beneficial in the long run? 🤔 Let's explore this through childhood memories and understand the importance of clean coding.

Child Study 🧒🌳

Imagine you're a child who wants to build a tree house. You gather some nails, wood, and a hammer. When you start tinkering, you don't pay attention to the instructions or understand why certain parts go a certain way. In the end, you might have something that looks like a tree house, and you'll be happy that it's standing. 😊

But when the first strong wind comes, the tree house collapses. 🌬️🏚️ You didn't consider the integrity of the structure, didn't understand the importance of the support beams, and didn't follow the instructions to make the tree house safe and secure.

Likewise, in programming, if we just focus on making our code work without understanding the underlying logic, we're building a tree house that will always fail. 🚧

The Fallacy of Functional Software 🚨

When you write code without verifying or understanding it, you might achieve your immediate goal: getting the software to run. But this is a common misconception. Without a thorough understanding of your code, you're more likely to introduce bugs, security vulnerabilities, and performance issues. 🐞🔓⚡ This software may work today, but will it still work in different situations? Will it last over time? ⏳

The Importance of Clean Code 🧹💻

Clean code isn't about making your code look pretty. It's about writing clear, maintainable, and reliable code. So why is it important?

Readability 📖: Clean code is like a well-written book. Others (including yourself) will understand what the code does without needing explanations. This is crucial for collaboration and long-term maintenance.
Debugging 🔍: When problems arise, clean code makes it easier to identify and fix bugs. If your code is messy, finding the cause of a problem can be like finding a needle in a haystack. 🪡
Extensibility 🔧: Clean code is easier to extend and modify. If your code is well-organized and follows best practices, it's simpler to add new features or make changes with fewer errors.
Practice 🛠️: Understanding your code enables you to write better solutions. Blindly copying and pasting might work temporarily, but it often results in poor performance.

Simple Coding Best Practices 📝

Programming languages aren't the same as English, but we can still make our code more readable by following best practices:

Meaningful Names 🏷️: Use variable names and functions that describe their purpose. For example, "calculateTotalPrice" is clearer than "calcPrice."
Comments and Documentation 🗒️: While your code should be self-explanatory, comments can explain why certain decisions were made. This is especially useful for complex logic.
Consistent Formatting ✍️: Follow standard style guidelines for indentations, spaces, and brackets. This will make your code more efficient and easier to read.
Modularization 🧩: Break your code into smaller, reusable parts or modules. This not only makes your code more readable but also easier to test and maintain.
Error Handling 🚦: Implement proper error handling to make your code robust. Don't assume everything will work perfectly; plan for the unexpected.
Version Control 📊: Commit small changes frequently with clear messages. This helps track changes better and makes it easier to roll back if something goes wrong.
Comprehensive Documentation 📚: Maintain all documentation, including a README file that explains the purpose, setup, and usage of your program. This helps others quickly understand your project and makes onboarding new team members easier.

So...... 🎯

While it may be tempting to take shortcuts and focus only on getting your code to work, this approach is problematic. Just like building a sturdy tree house requires understanding the basics of construction, writing robust software requires understanding the underlying logic and following good coding practices. 🛠️ By doing this, you can ensure that your software will not only work today but will be reliable, maintainable, and extendable in the future.

Remember, clean coding isn't just about tidying up your code and formatting it. It's about writing code that others can read, understand, and build upon. In the long run, this approach will save you time, effort, and headaches, making your software more efficient and developers happier. 😊

Why Beginners Fail Coding Tests: The Art of Breaking Code

Ashish Vaghela — Fri, 02 Aug 2024 06:51:11 +0000

In the world of software development, passing coding tests in interviews is a crucial step. Despite having a good understanding of programming concepts and technologies, many beginners still struggle to pass these assessments. One of the main reasons for this is the inability to break code into smaller, more manageable pieces. This article explores this challenge, specifically through the lens of React.js, and highlights the importance of organizing code into reusable components.

The Problem: Understanding vs. Implementation 🤔

Beginners often have a good understanding of how the technology works in theory. For example, they can understand React.js concepts, such as components, state, and props. However, when faced with a practical problem, such as building a Todo app, they hesitate. This is not due to lack of knowledge but rather due to the inability to analyze the problem and structure their code effectively.

Let's consider a common scenario: a beginner tasked with creating a Todo app. They might end up putting everything into a single “App” component. This approach works well for very small projects but quickly becomes unmanageable as the application grows.

The Importance of Breaking Down Code 🔍

Breaking code into smaller, reusable pieces is a fundamental skill for any software developer. This means:

Better Organization: The code becomes more structured and easier to understand. 🗂️
Reusability: Smaller components can be reused in different parts of the application. ♻️
Maintainability: Separate components are easier to debug and test. 🔧
Scalability: As the application grows, new features can be added without breaking the existing code. 📈

Case Study: Building a Todo App in React 💡

Let's take a real-world example to illustrate this concept. Imagine you are asked to create a simple Todo app in React. Here is a detailed description of how you might organize the app:

App Component: The main component that holds the state and renders other components.
Header Component: A reusable header for the application.
TodoList Component: A component that displays the list of todos.
TodoItem Component: A component for each individual todo item.
AddTodo Component: A component for adding new todos.

By breaking down the application into these smaller components, each part has a specific responsibility, making the code more organized and easier to manage.

Example Code 💻

Here is a simple example of how this might look in code:

// App.js
import React, { useState } from 'react';
import Header from './Header';
import TodoList from './TodoList';
import AddTodo from './AddTodo';

const App = () => {
  const [todos, setTodos] = useState([]);

  const addTodo = (todo) => {
    setTodos([...todos, todo]);
  };

  return (
    <div>
      <Header />
      <AddTodo addTodo={addTodo} />
      <TodoList todos={todos} />
    </div>
  );
};

export default App;

// Header.js
import React from 'react';

const Header = () => <h1>Todo List</h1>;

export default Header;

// TodoList.js
import React from 'react';
import TodoItem from './TodoItem';

const TodoList = ({ todos }) => (
  <ul>
    {todos.map((todo, index) => (
      <TodoItem key={index} todo={todo} />
    ))}
  </ul>
);

export default TodoList;

// TodoItem.js
import React from 'react';

const TodoItem = ({ todo }) => <li>{todo}</li>;

export default TodoItem;

// AddTodo.js
import React, { useState } from 'react';

const AddTodo = ({ addTodo }) => {
  const [input, setInput] = useState('');

  const handleSubmit = (e) => {
    e.preventDefault();
    addTodo(input);
    setInput('');
  };

  return (
    <form onSubmit={handleSubmit}>
      <input
        type="text"
        value={input}
        onChange={(e) => setInput(e.target.value)}
      />
      <button type="submit">Add Todo</button>
    </form>
  );
};

export default AddTodo;

Conclusion 🏁

Understanding how to break down code into smaller, reusable chunks is essential for any software developer. It's not just about knowing the concepts, but also about applying them effectively in real-world situations. By organizing your code into well-structured, reusable components, you make your application more maintainable, scalable, and easier to understand.

So the next time you're faced with a coding challenge, take a step back and think about how you can decompose the problem. This skill will not only help you get through the coding rounds, but it will also make you a better developer in the long run. 🌟

Functional Programming Meets TDD: A Match Made in Code Heaven 🚀

Ashish Vaghela — Tue, 16 Jul 2024 14:12:30 +0000

This is the story of how these two paradigms can be combined for the ultimate coding experience. ?

Fundamentals of functional programming

Functional programming simply means writing sensible code. Here are the most important principles:

Immutability ?

Once a variable is set, it does not change. Instead of modifying data, you create new data structures.

Example:

// Immutable function
const add = (x, y) => x + y;

// Test case
test('add function should return the sum of two numbers', () => {
  expect(add(2, 3)).toBe(5);
});

Pure Functions ?

A pure function always returns the same result with the same inputs and causes no side effects.

Example:

// Pure function
const multiplication = (x, y) => x * y;

// Test case
test('the multiplication function should return the product of two numbers', () => {
  expect(multiply(4, 5)).toBe(20);
});

Higher-order functions ?

These functions take other functions as arguments or return them as results, allowing for more flexible and reusable code.

Example:

// Higher order function
const applyFunction = (fn, x, y) => fn(x, y);

// Test case
test('applyFunction should use the given function in arguments', () => {
  const add = (x, y) => x + y;
  expect(applyFunction(add, 2, 3)).toBe(5);
});

The Perfect Pair: FP and TDD

When FP meets TDD, magic happens. Here's how they complement each other:

Embrace Immutability ?

Immutability ensures data consistency and tests are more reliable because data doesn't change unexpectedly.

Example:

// Immutable function
const add = (x, y) => x + y;

// Test case
test('add function should return the sum of two numbers', () => {
  expect(add(2, 3)).toBe(5);
});

Use pure functions ?

Pure functions are predictable and easy to test because they don't depend on or modify external state.

Example:

// Pure function
const multiplication = (x, y) => x * y;

// Test case
test('the multiplication function should return the product of two numbers', () => {
  expect(multiply(4, 5)).toBe(20);
});

Use higher-order functions ?

Higher-order functions allow you to write abstract and reusable test cases, improving code flexibility.

Example:

// Higher order function
const applyFunction = (fn, x, y) => fn(x, y);

// Test case
test('applyFunction should use the given function in arguments', () => {
  const add = (x, y) => x + y;
  expect(applyFunction(add, 2, 3)).toBe(5);
});

// Simple functions
const increment = x => x + 1;
const double = x => x * 2;

// Function composition
const incrementAndDouble = x => double(increment(x));

// Test case
test('incrementAndDouble should increase and then double', () => {
  expect(incrementAndDouble(3)).toBe(8);
});

Write declarative code ?

Declarative code focuses on what to do, not how to do it, which makes tests clearer and more concise.

Example:

// Declarative code using map
const numbers = [1, 2, 3, 4];
const doubledNumbers = numbers.map(x => x * 2);

// Test case
test('doubledNumbers should contain doubled values', () => {
  expect(doubledNumbers).toEqual([2, 4, 6, 8]);
});

Advantages ?

Predictability: FP's pure functions and immutability make behavior predictable, simplifying testing.
Modularity: FP breaks problems into smaller reusable parts, equivalent to unit testing in TDD.
Readability: Declarative code is easier to understand and test.
Sustainability: TDD ensures that code changes do not introduce bugs, while FP's modular approach simplifies updates.

Andddd....... ?

Combining functional programming with test-driven development can dramatically improve your coding experience. By integrating the immutable principles of FP, pure functions, high-order functions, and declarative code into the test-first approach of TDD, you create a code base that is clean, maintainable, and resilient. It's a match made in coding heaven! ?

Does Test-Driven Development Weaken Debugging Skills? 🐞🧪

Ashish Vaghela — Fri, 28 Jun 2024 06:19:33 +0000

Test-Driven Development (TDD) is a programming method where tests are written before the actual code. The process involves writing a test, failing it, writing the minimum code necessary to pass the test, and refactoring the code if the tests pass. This iterative cycle promotes clean, reliable, and well-tested code. However, there is sometimes a concern that practicing TDD may lead to a decline in traditional debugging skills. Let's explore this concept in detail.

Understanding and Debugging TDD

Before delving into the impact of TDD on debugging skills, it is important to understand the role of each in software development:

Test-Driven Development ( TDD) ?: TDD focuses on writing tests before the actual code. This ensures that the code works as expected from the start. Writing, passing, and rewriting a test that fails helps developers create robust and maintainable code.
Debugging ?: Debugging is the process of identifying, analyzing and correcting code errors. This often requires the use of tools and techniques to find the cause of unexpected software behavior.

Argument: TDD vs. debugging skills ?

The argument that TDD can undermine debugging skills stems from the idea that TDD practitioners spend less time using traditional debugging tools and techniques. Here are some points to consider:

Less exposure to bugs ?: In a TDD workflow, developers write tests that determine the behavior of the code before writing the code itself. This practice can result in fewer bugs entering the codebase because problems are detected early through automated tests. As a result, developers may have fewer opportunities to practice traditional debugging.
Early detection and prevention ?: TDD emphasizes early detection and prevention of errors. By writing the tests first, developers can catch bugs before they reach the code. This proactive approach can reduce the need for extensive debugging later in development.
Different Skills ?: TDD and Debugging require different skills. TDD focuses on writing tests, thinking about edge cases and ensuring code coverage. Debugging, on the other hand, involves diagnosing problems, understanding code flow, and using debugging tools. While TDD may reduce the need for repetitive debugging, it does not necessarily mean that problem solving is reduced. Instead, developers can develop different skills that are equally valuable.
Complementary practices ?: TDD and debugging are not mutually exclusive. Although TDD can reduce the frequency and severity of bugs, debugging is still an important skill for all developers. In production environments, integration points or legacy code bases, there are always complex issues that require traditional debugging skills.

Balance TDD and Debugging Skills ?

Developers can adopt the following practices to maintain a balance between TDD and Debugging skills:

Practice both regularly ?: Although TDD reduces the frequency of bugs, developers should regularly practice debugging to keep your skills sharp. This can be done in code ceilings, working on old projects, or participating in code problems that require debugging.
Use Debugging Tools with TDD ?: Add debugging tools and techniques to your TDD workflow. For example, if a test fails, run the debugger through the code and understand why it failed. This practice helps strengthen debugging skills in a TDD context.
Learn about test failures ?: When a test fails, take the opportunity to thoroughly diagnose the problem. Instead of immediately fixing the code, investigate the error, understand the root cause, and document your findings. This approach combines the strengths of both TDD and debugging.
Contact Complex Systems ?: Work on projects involving complex systems where errors are more likely. These projects provide many opportunities to practice debugging using TDD principles.

Finally ?

While it is true that TDD can reduce the frequency of bugs and the need for extensive debugging, it does not necessarily lead to the loss of debugging capabilities. TDD and debugging are complementary practices that, when used together, can improve a developer's ability to create robust, reliable, and maintainable code. By balancing the two and actively practicing both, developers can maintain their debugging ability while still benefiting from TDD..

Dotfiles: The Developer Secret to the Perfect Setup

Ashish Vaghela — Tue, 25 Jun 2024 12:59:57 +0000

What Are Dotfiles? 📁

Dotfiles are configuration files for Unix-like systems that start with a dot (.). They are usually hidden in your home folder and silently monitor the behavior of applications and the shell. Think of them as the DNA of your development environment.

Common examples are:

.bashrc or .zshrc for shell configuration
.vimrc for Vim configuration
.gitconfig for Git configuration

Why Should Developers Care About Dotfiles? 🚀

Consistency: Ensure your environment looks and works the same on all your machines.
Efficiency: Automate repetitive tasks and create powerful shortcuts.
Version Control: Track changes to settings over time and easily restore them if something goes wrong.
Portability: Moving to a new machine? Your complete configuration is just a git clone away.
Collaboration: Share your best tricks with your team or learn from others by exploring their dotfiles.

The Power of Shell Customization 💻

Your shell is where the magic happens. Let's take a look at some popular options:

Bash: The Trusted Workhorse 🐎

# A colorful and informative prompt
export PS1="\[\033[36m\]\u\[\033[m\]@\[\033[32m\]\h:\[\033[33;1m\]\w\[\033[m\]\$ "

# Useful aliases
alias ll='ls -alF'
alias update='sudo apt update && sudo apt upgrade'

# Enable useful Bash options
shopt -s cdspell
shopt -s histappend

Zsh: A Versatile Option 🔄

# Load Oh My Zsh
export ZSH="$HOME/.oh-my-zsh"
ZSH_THEME="robbyrussell"
plugins=(git docker kubectl)
source $ZSH/oh-my-zsh.sh

# Custom aliases
alias zshconfig="nano ~/.zshrc"
alias ohmyzsh="nano ~/.oh-my-zsh"

Fish: Friendly and Modern 🐟

# Set color scheme
set fish_color_command blue
set fish_color_param cyan

# Custom functions
function mkcd
    mkdir -p $argv; cd $argv
end

Cross-Platform Considerations 🌍

Linux 🐧

Linux is the natural habitat of dotfiles. Most applications store their configuration in the home directory, making it easy to manage with version control.

macOS 🍏

Unix-based macOS works just like Linux. However, some macOS-specific applications may store preferences in ~/Library/Preferences/.

Windows 🖥️

Windows has not traditionally used dotfiles, but the Windows Subsystem for Linux (WSL) and PowerShell now offer similar advantages:

Use WSL to get a Linux environment on Windows.
PowerShell uses a profile script ($PROFILE) similar to .bashrc.

# In $PROFILE
function prompt {
    $p = Split-Path -leaf -path (Get-Location)
    "$p> "
}

Set-Alias open Invoke-Item

Elevating Your Setup 🌟

Terminal Multiplexers 🔄

Tools like tmux allow you to manage multiple terminal sessions. Here is a simple .tmux.conf:

# Change prefix from 'C-b' to 'C-a'
unbind C-b
set-option -g prefix C-a
bind-key C-a send-prefix

# Split panes using | and -
bind | split-window -h
bind - split-window -v

Prompt Customization ✨

Starship is a shell prompt that works on all operating systems. Add this to your shell configuration file:

eval "$(starship init bash)"  # or zsh, fish, etc.

Then customize ~/.config/starship.toml:

[character]
success_symbol = "[➜](bold green)"
error_symbol = "[✗](bold red)"

[git_branch]
symbol = "🌱 "

Version Control 📝

Git is crucial for managing dotfiles. Here's an example of .gitconfig:

[user]
    name = Your Name
    email = your.email@example.com
[alias]
    cm = commit -m
    st = status
[core]
    editor = vim

Getting Started with Dotfiles 🚀

Start Small: Pick one tool you use often and get familiar with its dotfile.
Use Version Control: Create a Git repo for your dotfiles.
Automate: Write a simple script to symlink your dotfiles to their correct locations.
Explore: Check out other developers' dotfiles on GitHub for inspiration.
Experiment: Try different shells and tools like Zsh with Oh My Zsh or Fish.
Share and Learn: The dotfiles community thrives on sharing knowledge and improving setups.

A Day in the Life with Dotfiles 🌅

Imagine starting your day:

You open your terminal and get a custom prompt that shows the Git status, Python version, and current AWS profile.
With one alias wk, you start tmux with the default window layout for your current project.
Vim opens with the desired color scheme, plugins, and key bindings.
As you code, the shell automatically executes commands and suggests corrections for typos.

All this is consistent across all your machines thanks to carefully maintained dotfiles.

Conclusion 🎉

Your dotfiles reflect the way you work. They evolve as you do, becoming more complex and powerful over time. Harness the power of dotfiles and watch your productivity soar on Linux, macOS, or Windows. Start your journey today and discover the efficiency that awaits you in these humble dotfiles. Your future self will thank you!

Remember, the journey of a thousand configurations begins with a single dot. Happy coding! 🚀

🎣 Webhooks: The secret sauce of web communication! 🌐

Ashish Vaghela — Fri, 21 Jun 2024 05:54:00 +0000

Hey Folks!

👋 Today we dive into the world of web hooks — the hidden heroes that make the web more interactive and exciting. Think of web hooks as a secret language that allows different systems to talk to each other in real time. 🗣️💬

🤔 So what exactly is a web hook?

Imagine that you and your best friend have a special mailbox. 📬 If your friend has juicy gossip or a funny meme to share, they drop a letter into this mailbox. 💌 You have the key, so you can receive and reply to the message immediately. 🔑😂

In the digital world, the web hook works the same way. It’s like a unique URL (web address) that you give to another system. When the system has something important to tell you, it sends an HTTP request (like a digital letter) to your special URL. 📨 Your system receives the notification and can act based on the received information. 🎉

🌟 Why Web Hooks are the Coolest Kids on the Block

Web Hooks are like the superheroes of online communication. They swing by and save the day in a variety of situations! 🦸‍♀️🦸‍♂️

1. Live Updates: You don’t have to wait for updates anymore! Web hooks allow you to get data into your system as soon as it happens. It’s like a news feed that never sleeps. 📰🔔

2. Notes: Web hooks are the best messengers! They can send messages from one system to another faster than you can say “You have email!” 📩💨

3. Third Party Integrations: Web hooks are the glue that holds different services together. They allow you to connect and automate workflows across platforms like GitHub, Slack, and Stripe. It’s like a team of digital assistants working seamlessly together. 🤖🔧

💻 Let’s see Web-hooks in action!
Enough talking, let’s code!

Here is a simple example of creating a webhook using Node.js and the Express framework.

const express = require('express');
const app = express();

// Parse JSON request texts
app.use(express.json());

// Define the webhook endpoint
app.post('/webhook', (req, res) => {
  const message = req.body.message;
  console.log('Message received: ', message);
  res.status(200).send('Message received!');
});

app.listen(3000, () => console.log('Server running on port 3000'));

This webhook receives a POST request and logs it to the console.

In this example, if a POST request is sent to the /webhook endpoint with a JSON payload containing the “message” field, the webhook will log the message to the console and send a response 📥 ✅ And that’s it.

Meanwhille we can connect over
https://www.linkedin.com/in/ashish-codejourney/
https://x.com/codejourney_

Renaming Bugs as "UnWritten Test Cases"

Ashish Vaghela — Thu, 20 Jun 2024 04:48:53 +0000

The Code Crusaders Story
There was a team of superheroes called the "Code Crusaders". Their job was to protect the digital world from bad things like glitches and bugs.

One day, they got a call that a virus was causing trouble in Pixelville. The team went to fix it but discovered a very complex bug. They tried and tried but couldn't get rid of the bug.

Then their wise teacher said, "The bug isn't a bug in the code. It's a test you haven't written yet."

This made the team think in a new way.
Instead of seeing the mistake as a failure, they saw it as an opportunity to improve their testing.

They carefully researched the bug to understand how it works. Then they wrote new tests to catch such a bug next time. With new tests, they were finally able to beat the bug!

The people of Pixelville celebrated their heroes. Since then, the Code Crusaders have seen every bug as an opportunity to improve testing.

True Lesson (Simply)
Although the story is a hoax, it teaches an important true lesson about mistakes.

The reality is Bugs doesn't exists in real life, it's just some test cases they didn't wrote.

Instead of fixing the bug, you should write a new test for such a problem. That way it won't happen again.

Handling errors in this way changes your thinking. Not only will you react to mistakes, but you will be better able to prevent them.
It also helps teams work together better.

Instead of blaming, you investigate the error and improve your testing as a team.

This test-focused mindset keeps your skills sharp as technology changes. Testing must also adapt to changing user needs.

Seeing bugs as "missing tests" changes the way you develop software. This leads to higher quality code and a better user experience.

Meanwhille we can connect over
https://www.linkedin.com/in/ashish-codejourney/
https://x.com/codejourney_

DEV Community: Ashish Vaghela

Using Google Sheets as a CMS: A Simple, Powerful Approach to Content Management

Why Google Sheets as a CMS?

How It Works

Setup Guide

Step 1: Create Your Google Sheet

Step 2: Publish Your Sheet as CSV

Step 3: Implement the JavaScript Fetcher

Basic CSV Fetcher

Step 4: Display the Data

Step 5: Initialize Your Application

Step 6: HTML Structure

Step 7: Styling (CSS)

Advanced Features

Filtering and Sorting

Caching for Better Performance

Multiple Sheets Support

Complete Example: Events Website

Best Practices

1. Data Structure

2. Performance Optimization

3. Error Handling

4. Security Considerations

5. SEO Optimization

Limitations and Considerations

Conclusion

Additional Resources

The AI Testing Paradox: How Automated Test Generation Might Kill Unit Testing

The Death Spiral

The False Confidence Problem

The Tragic Irony

The Path Forward

Conclusion

From Overwhelmed to Empowered: My Hacktoberfest 2025 Journey

The Starting Line

Finding My Path: Open Source Weekend

The Registration Flow Challenge

Documentation That Actually Helps

Scaling Up: Open Source Day

Building for the Organizers

The Wild Card: Akash Network

Learning a New World

Documentation for the Confused

Going Technical

What I Learned

The Patterns That Emerged

How Hacktoberfest Changed Me

What I Gained

The Challenges

Advice for Your First Hacktoberfest

Looking Forward

What Open Source Means to Me Now

The Real Prize

Your Turn

Crafting Code with Intent: A Journey to Clarity and Collaboration

The Joy of Beautiful Code

The Reality of Everyday Code

Why Intent-Driven Comments Are Essential

Crafting Intent-Driven Comments

Practical Tips:

Example: Bad vs Good Comment

Where Do You Stand as a Coder?

Balancing Comments and Code

Example:

Fostering Collaboration Through Intent

Example:

Final Thoughts

Mastering JUnit: Techniques from Victor Rentea's Toolbox 🧰

1. Avoid the Waste: Feature Files Nobody Reads 🗑️

(I don't believe in this)

2. Say Goodbye to assertEquals 👋

3. Parameterized Tests: Go Orthogonal or Go Home 🏠

4. From Flaky to Rock-Solid: @RepeatedTest 🛠️

5. Profiling Tests and OutputCapture 🔍

Essential Tools You’ll Need 🧰

Books & Resources for Further Mastery 📚

Wrapping Up 🎉

The Hidden Dangers of Programming: A Lesson From Childhood 🛠️💻

Child Study 🧒🌳

The Fallacy of Functional Software 🚨

2. Say Goodbye to `assertEquals` 👋