Forem: Sivantha Paranavithana

The Art of Git Commits: Writing Messages That Your Future Self Will Thank You For

Sivantha Paranavithana — Sun, 16 Feb 2025 14:47:54 +0000

TL;DR

Learn how to write meaningful Git commits that enhance collaboration, make code reviews easier, and help maintain a clean project history. We'll cover commit message structure, conventional commits, and tools to enforce commit standards.

Introduction

If you're reading this, you probably know that Git is the most widely used version control system. While most developers use Git daily, not everyone makes the most of its commit functionality. Let's dive into how we can level up our commit game.

What is a Git Commit?

Think of a Git commit as a snapshot of your project at a specific point in time. It's like saving your progress in a video game - you want to save after completing important missions, not randomly in the middle of one.

Each commit represents:

A checkpoint in your project's timeline
A record of what changed and why
A reference point you can return to if needed

The Anatomy of a Good Commit

Have you ever looked at your commit history and wondered, "What was I thinking?" You're not alone. A good commit message should tell a story about what changed and why.

Bad Commit Messages:

fix stuff
updated code
final commit
final final commit
PLEASE WORK

Good Commit Messages:

fix(auth): resolve JWT token expiration issue
feat(dashboard): add real-time data updates
docs: update API authentication guidelines

Quick Tips for Better Commit Messages

Here are some immediate improvements you can make to your commit messages:

Avoid Unnecessary Capitalization
Instead of "Added New Feature", use "add new feature"
Double Check Spelling
Typos in commit messages make it harder to search history and look unprofessional
Skip Punctuation in Summary Lines
Don't end your commit message summaries with periods or other punctuation

These simple guidelines make your repository more visually appealing and easier to search through.

Use the Imperative Mood

A powerful trick for writing better commit messages is using the imperative verb form. Think of your commit message as completing this sentence:

"If applied, this commit will..."

Examples:

❌ "fixed login bug"
✅ "fix login bug"

❌ "updated user documentation"
✅ "update user documentation"

Real-world example:

add new Kief-the-kraken Keanu-Kief to keif gallery

modify menu.yml and keif-gallery.md related to ticket #12345

Commit Frequently

One of the best ways to improve your commit messages is simply to commit more often. Here's why:

Smaller changes are easier to describe
Each commit has a clear, single purpose
You're less likely to lose work
Code reviews become more manageable

Imagine trying to write a commit message after a full day of uncommunicated changes - it's nearly impossible to be concise and clear. Instead, commit each meaningful change as you make it.

Git Commit Workflow

The journey to a perfect commit involves three main steps:

Make Changes: Write your code and test it thoroughly
Stage Changes: Use git add to select which changes to include
Commit Changes: Create your snapshot with a meaningful message

Conventional Commits: A Standard That Makes Sense

Conventional Commits provide a structured format that makes commit histories readable and automated tools possible. This specification has become the de facto standard for many open-source projects and development teams.

One of the most powerful aspects of Conventional Commits is its ability to automate various DevOps processes:

Automated Changelog Generation: Tools can parse commit messages to automatically create and update changelogs
Version Management: Following Semantic Versioning (SemVer), commit types directly correlate to version bumps:
- fix: commits trigger PATCH version increments (1.0.0 -> 1.0.1)
- feat: commits trigger MINOR version increments (1.0.0 -> 1.1.0)
- BREAKING CHANGE: commits trigger MAJOR version increments (1.0.0 -> 2.0.0)
Release Management: Automated release notes and version tagging based on commit history
CI/CD Integration: Automated deployment workflows based on commit types and scopes Here's the basic structure:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Common Types:

feat: New features
fix: Bug fixes
docs: Documentation changes
style: Formatting changes
refactor: Code restructuring
test: Adding or modifying tests
chore: Maintenance tasks

Real-world Example:

feat(payment): implement PayPal integration

Add PayPal as a payment option for checkout process.
This change includes:
- PayPal SDK integration
- Payment verification flow
- Success/failure handling

BREAKING CHANGE: Updates payment processor interface
Closes #123

Git Hooks: Your Commit Quality Guardian

Git hooks are scripts that run automatically before or after Git commands. They're perfect for enforcing commit message standards.
We can run Commitlint as a commit hook to ensure the quality of our commit messages.

Setting Up Commitlint

Install commitlint:

npm install -g @commitlint/cli @commitlint/config-conventional

Add configuration:

echo "module.exports = {extends: ['@commitlint/config-conventional']}" > commitlint.config.js

Install husky for Git hooks:

npm install husky --save-dev
npx husky install
npx husky add .husky/commit-msg 'npx --no -- commitlint --edit $1'

You can refer to Commitlint Documentation for more details.

Tools to Make Your Life Easier

If you're using VS Code, the "Conventional Commits" extension by vivaxy is a game-changer. It provides:

Interactive commit message building
Type and scope suggestions
Conventional Commits specification compliance

Install the extension here

The Long-Term Benefits

Investing time in writing quality commit messages pays off in numerous ways:

Easier debugging when issues arise
Smoother code reviews
Better project documentation
Clearer project history
More efficient team collaboration

Remember: The time you spend writing good commit messages is an investment in your project's future maintainability.

Conclusion

Writing good commit messages is an art that pays dividends in the long run. It makes collaboration smoother, code reviews more efficient, and debugging less painful. Start implementing these practices today, and your future self (and teammates) will thank you.

Discussion

What's your approach to writing commit messages? Share your best practices and tools in the comments below!

If you found this article helpful, consider following me for more development tips and best practices.

Git Branching - A Production-Grade Branching Strategy for Enterprise Teams

Sivantha Paranavithana — Thu, 13 Feb 2025 04:26:14 +0000

Enterprise teams need robust, battle-tested branching strategies to handle complex release cycles while maintaining code stability. In this guide, I'll share a production-grade modification of the Gitflow branching model that has proven successful in enterprise environments.

Why Another Gitflow Guide? 🤔

While the classic Gitflow model is excellent, enterprise teams often need more control over their release process, especially when dealing with multiple environments and strict QA requirements. This modified approach introduces dedicated QA and staging branches, making it perfect for teams that:

Require thorough testing before production
Manage multiple release environments
Need strict control over what goes into production
Handle frequent hotfixes alongside regular feature development

The Branch Structure 🌿

Core Branches

Main Branch (`main`)

The source of truth for your production code. Think of it as your production environment's mirror.

✅ Contains only production-ready code
🚫 Never commit directly here
🏷️ All production releases are tagged
🔧 Source for hotfix branches

Development Branch (`develop`)

Your integration hub where features come together.

🔄 Latest development changes live here
👥 First stop for all new features
🧪 Integration testing happens here
🚫 Not for direct feature branching

QA Branch (`release/qa`)

Your dedicated testing environment.

🧪 QA team's workspace
⬆️ Updated from develop
✅ Verification checkpoint
🚫 No feature branching allowed

Staging Branch (`release/staging`)

The final stop before production.

🎭 Pre-production environment
✨ Contains release-ready features
🔍 Final verification point
🎯 Merges to main for releases

Working Branches

Feature Branches (`feature/*`)

Where new features come to life.

# Creating a feature branch
git checkout main
git checkout -b feature/awesome-new-feature

Hotfix Branches (`hotfix/*`)

For those urgent production fixes.

# Creating a hotfix branch
git checkout main
git checkout -b hotfix/critical-bug-fix

Bugfix Branches (`bugfix/*`)

For fixing issues in unreleased features.

# Creating a bugfix branch
git checkout feature/parent-feature
git checkout -b bugfix/feature-bug-fix

Real-World Scenarios 🎯

Scenario 1: Developing a New Feature

Create your feature branch:

git checkout main
git checkout -b feature/user-authentication

Follow the PR flow:
- First PR: Your branch → develop
- After merge: develop → release/qa
- After QA: Your branch → release/staging
- Release time: release/staging → main

Scenario 2: Fixing Production Issues

Create a hotfix branch:

git checkout main
git checkout -b hotfix/login-error

Follow the same PR flow as features
Gets priority in the release cycle

Golden Rules for Success 🌟

Never:

❌ Branch from develop or release/qa
❌ Pull from develop into working branches
❌ Mix unrelated changes in PRs
❌ Commit directly to protected branches

Always:

✅ Branch from main for new work
✅ Keep changes focused and atomic
✅ Follow the proper environment flow
✅ Maintain a clean commit history

Pro Tips for Team Success 💡

Branch Hygiene
- Delete merged branches promptly
- Use clear, descriptive branch names
- Keep branches focused on single features
Commit Practices
- Write meaningful commit messages
- Commit regularly but thoughtfully
- Squash commits before merging
Release Management
- Use semantic versioning
- Tag all production releases
- Maintain a changelog

Tools to Make Your Life Easier 🛠️

Git Aliases

# Add to your .gitconfig
[alias]
    feature = "!f() { git checkout main && git checkout -b feature/$1; }; f"
    hotfix = "!f() { git checkout main && git checkout -b hotfix/$1; }; f"

Branch Protection Rules

Require PR reviews
Enforce status checks
Lock protected branches

Conclusion 🎉

Although this modified Gitflow approach might initially seem complex, it provides a robust foundation for enterprise development. It's battle-tested and scales well with team size and project complexity.

Remember: The goal isn't to follow these rules blindly but to understand and adapt them to your team's needs while maintaining code quality and release stability.

Share Your Thoughts! 💭

How does your team handle branching strategies? Have you modified Gitflow for your needs? Share your experiences in the comments below!

Node.js E2E Testing with Cypress: A Comprehensive Setup Guide

Sivantha Paranavithana — Wed, 12 Feb 2025 07:35:54 +0000

Introduction

End-to-end testing is crucial for ensuring your Node.js applications work flawlessly from the user's perspective. In this comprehensive guide, we'll walk through setting up Cypress for e2e testing in a Node.js Express project, complete with code coverage, Docker-based test databases, and best practices for organizing your test suites.

What You'll Learn 🎯

Setting up Cypress with Node.js and Express
Configuring test databases using Docker
Implementing code coverage with NYC
Organizing test suites effectively
Writing maintainable test cases
TypeScript integration
Best practices for e2e testing

Prerequisites

Before we dive in, make sure you have:

Node.js installed (v14 or later)
Basic understanding of Express.js
Docker installed (for test databases)
Your favorite code editor (VSCode recommended)

Setting Up Your Testing Environment

1. Installing Essential Dependencies

First, let's install the necessary packages:

yarn add -D cypress
yarn add -D nyc
yarn add -D ts-node
yarn add -D @cypress/code-coverage

2. Docker-Based Test Database Setup

For consistent testing environments, we'll use Docker. Here's how to set up both MySQL and MongoDB:

MySQL Configuration:

# docker-compose.yml
services:
  test-db:
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: ${DB_PASSWORD}
      MYSQL_DATABASE: ${DB_NAME}
    ports:
      - ${DB_PORT}:3306
    command: --default-authentication-plugin=mysql_native_password
    healthcheck:
      test: ['CMD', 'mysqladmin', 'ping', '-h', 'localhost']
      timeout: 20s
      retries: 10

MongoDB Configuration:

# docker-compose.yml
services:
  mongodb:
    image: mongo:latest
    command: mongod --replSet rs0 --bind_ip_all
    environment:
      MONGO_INITDB_DATABASE: ${DB_NAME}
    ports:
      - ${DB_PORT}:27017
    healthcheck:
      test: mongosh --eval "try { rs.status() } catch (err) { rs.initiate() }"
      interval: 10s
      timeout: 10s
      retries: 5

3. Environment Configuration

Create a .env.test file for your test environment:

PORT=3000
ENV="test"
PACKAGE_NAME="my-api"
DB_USERNAME="root"
DB_PASSWORD="root"
DB_HOST="127.0.0.1"
DB_PORT=3300
DB_NAME="test-db"

Configuring Code Coverage with NYC

NYC (Istanbul) provides detailed code coverage metrics. Here's how to set it up:

// .nycrc
{
  "all": true,
  "include": ["src/**/*.ts"],
  "exclude": [
    "**/*.spec.ts",
    "**/*.test.ts",
    "**/*.cy.ts",
    "coverage/**"
  ],
  "extension": [".ts"],
  "reporter": ["json", "lcov", "text", "html"],
  "report-dir": "coverage/cypress",
  "temp-dir": ".nyc_output"
}

Cypress Configuration

Create a cypress.config.ts file to configure Cypress with code coverage:

import { defineConfig } from 'cypress';
import path from 'path';
import environment from './src/config/env.config';

export default defineConfig({
  e2e: {
    setupNodeEvents(on, config) {
      require('@cypress/code-coverage/task')(on, config);
      return config;
    },
    baseUrl: `http://localhost:${environment.port}/api`,
    env: {
      packageName: environment.packageName,
      packageVersion: environment.packageVersion,
      env: environment.env,
      apiKey: environment.apiKey,
      dbURI: environment.dbURI,
      codeCoverage: {
        url: `http://localhost:${environment.port}/__coverage__`,
        expectBackendCoverageOnly: true,
      },
    },
    defaultCommandTimeout: 5000,
  },
  screenshotOnRunFailure: false,
  video: false,
});

Organizing Your Cypress Tests

Project Structure

Here's a clean, maintainable structure for your Cypress tests:

cypress/
├── constants/          # Test data and constants
├── e2e/               # Test files
├── plugins/           # Cypress plugins
├── support/           # Commands and types
└── tsconfig.json      # TypeScript config

Writing Effective Test Suites

Let's look at a real-world example of a well-structured test suite:

describe('POST /v1/users', () => {
  const { apiKey, dbURI } = Cypress.env();

  beforeEach(() => {
    cy.task('cleanupUsers', { dbURI });
  });

  it('should create a user with required fields', () => {
    cy.request({
      method: 'POST',
      url: '/v1/users',
      headers: { 'x-api-key': apiKey },
      body: {
        name: 'John Doe',
        email: 'john@example.com'
      }
    }).then((response) => {
      expect(response.status).to.eq(201);
      expect(response.body).to.have.property('id');
    });
  });

  // More test cases...
});

Custom Commands

Create reusable test operations:

// commands/users.commands.ts
Cypress.Commands.add('createUser', (userData) => {
  return cy.request({
    method: 'POST',
    url: '/v1/users',
    headers: { 'x-api-key': Cypress.env('apiKey') },
    body: userData,
    failOnStatusCode: false,
  });
});

Best Practices for E2E Testing

Clean State for Each Test
- Use beforeEach hooks to reset the database
- Avoid test interdependence
Organized Test Structure
- Group related tests in describe blocks
- Use meaningful test descriptions
- Follow the AAA pattern (Arrange, Act, Assert)
Error Handling
- Test both success and failure scenarios
- Validate error messages and status codes
- Check edge cases
Performance Considerations
- Use appropriate timeouts
- Minimize database operations
- Implement parallel test execution when possible

Common Pitfalls and Solutions

Database Connection Issues
- Always check your connection strings
- Implement proper error handling
- Use connection pooling
Flaky Tests
- Add proper wait conditions
- Don't rely on arbitrary timeouts
- Use Cypress's built-in retry mechanism

TypeScript Integration

Ensure your tsconfig.json includes these essential compiler options:

{
  "compilerOptions": {
    "target": "es5",
    "lib": ["es5", "dom"],
    "types": ["cypress", "node"],
    "esModuleInterop": true,
    "sourceMap": true
  },
  "include": ["**/*.ts"]
}

Conclusion

Setting up end-to-end testing with Cypress in your Node.js applications might seem daunting at first, but with proper organization and best practices, it becomes a powerful tool in your testing arsenal. Remember to:

Keep your test environment consistent
Maintain clean and organized test code
Follow best practices for reliable tests
Regular monitoring of code coverage

Resources

What's Next?

Implementing CI/CD with Cypress
Advanced test patterns
Visual regression testing
API mocking strategies

Happy testing! 🚀

API Endpoint Design: CRUD vs Action-Specific Endpoints - A Developer's Guide

Sivantha Paranavithana — Tue, 11 Feb 2025 13:57:59 +0000

API Endpoint Design: The Great Debate 🤔

Hey there, fellow developers! 👋 Today, we're diving deep into one of the most crucial decisions you'll make when designing APIs: choosing between CRUD endpoints and action-specific endpoints. Let's break this down in a way that will help you make better architectural decisions for your next project.

The Two Contenders in the Ring 🥊

Before we jump into the nitty-gritty, let's understand what we're comparing:

1. The CRUD Champion

These are your traditional REST-style endpoints that follow the Create, Read, Update, Delete pattern. Think of them as your Swiss Army knife for resource manipulation.

GET    /api/resources          # List all the things!
POST   /api/resources          # Create new stuff
GET    /api/resources/{id}     # Get that specific thing
PUT    /api/resources/{id}     # Update all the things
PATCH  /api/resources/{id}     # Update just some things
DELETE /api/resources/{id}     # Goodbye, thing!

2. The Action-Specific Challenger

These endpoints are like specialized tools, each designed for a specific job. They're more explicit about what they do:

POST /api/resources/{id}/activate    # Power up! ⚡
POST /api/resources/{id}/deactivate  # Power down! 💤
POST /api/resources/{id}/archive     # Into the vault! 📦
POST /api/resources/{id}/publish     # Show time! 🎉

The CRUD Approach: Pros and Cons 📊

What's Awesome About CRUD

Follows REST conventions like a well-behaved API should
Keeps your API surface clean and minimal
Your code stays DRY (Don't Repeat Yourself)
Documentation practically writes itself
Flexibility to handle various update scenarios

The Not-So-Great Parts

Business operations can feel a bit... hidden
Validation logic can get messy
Authorization rules might feel shoehorned
Sometimes exposes more than you want
Business intent can get lost in translation

Action-Specific Endpoints: The Good and The Bad 🎯

The Good Stuff

Crystal clear about what's happening
Lock down those permissions like Fort Knox
Validation rules that make sense
Audit logs that tell the whole story
Optimize all the things!

The Challenges

More endpoints = More maintenance
Endpoint multiplication is real
REST purists might raise an eyebrow
Code reuse needs extra attention

Real-World Example: Show Me The Money! 💰

Let's look at a payment processing system because, hey, money talks!

The CRUD Way

PATCH /api/payments/{id}
Content-Type: application/json
{
    "status": "pending"
}

The Action-Specific Way

POST /api/payments/{id}/mark-as-pending
Content-Type: application/json
{
    "reason": "awaiting_verification",
    "note": "Additional documentation required"
}

Making The Choice: Your Decision Framework 🤔

Go CRUD When:

You're just moving data around
Business logic is straightforward
Standard auth patterns work fine
Side effects are minimal
Resource states are simple

Go Action-Specific When:

You're implementing business processes
Complex rules are in play
You need granular access control
Side effects matter
Audit trails are crucial
State transitions need tracking

The Hybrid Approach: Best of Both Worlds? 🌟

Here's a pro tip: You don't have to choose just one! Many successful APIs use CRUD for simple operations and action-specific endpoints for complex business processes. It's like having both a Swiss Army knife and a specialized toolbox.

Final Thoughts 💭

Remember, there's no one-size-fits-all solution in API design. The key is understanding your use case and choosing the approach that brings the most value to your team and your users.

The best API is the one that:

Makes sense to your team
Is easy to maintain
Serves your business needs
Keeps your users happy

What's your take on this? Have you used both approaches? Share your experiences in the comments below! 👇

P.S. If you found this helpful, don't forget to like and share! Follow me for more API design insights and development tips! 🚀

Organizing styles better with BEM + ITCSS + Sass

Sivantha Paranavithana — Sun, 26 Sep 2021 19:16:36 +0000

Writing CSS is easy.

But maintaining them is not!

On smaller projects, how you organize your code isn’t usually a big concern. However, when it comes to larger, complex projects, how you write and organize code can affect at least in three ways.

How long it takes to write code.
How much code you have to write.
How much loading your browser have to do.

Organizing code becomes really important when you are working with a team. The code you write should be transparent. In other words, it should be clear and obvious to understand. And also they should be consistent. Having consistent code throughout the project reduces the amount of mental overhead needed when writing new code, debugging or refactoring.

Another importance of organizing code is to make the code self documenting as much as possible. In that way we don't have to lose time in writing or reading lengthy, supplementary documentation or give boring KTs to other developers.

There are plenty of methodologies to reduce the CSS footprint, organize collaboration and maintain large CSS codebases. Among them the mix of BEM, ITCSS and the power of Sass is the most favorite of mine.

Let me convince you why it should be your favorite as well.

Let's start with ITCSS.

ITCSS

ITCSS is a CSS architecture to make your CSS more scalable and maintainable. ITCSS stands for "Inverted Triangle CSS". What that mean is that dividing the CSS codebase to several sections (called layers), which take the form of an inverted triangle.

ITCSS works with other methodologies such as SMACSS, OOCSS and even BEM. Also, we can take the advantage of the power of a preprocessor such a Sass to make it more flexible and powerful.

The layers in ITCSS are ordered in a way that it takes the full advantage of some of the most fundamental concepts of CSS, cascade, inheritance and specificity.

It start out with the most generic, low-level, catch-all, unremarkable styles, and eventually progress to more explicit and specific rules as we move through the project.

In other words, selectors in the beginning of the triangle affect a lot of the DOM and the reach gets narrower as we go down the triangle.

So it's all about organization. We can use a folder structure as below to organize our styles according to the ITCSS architecture.

// folder structure

theme
│
└─── settings
│    ├── _settings.colors.scss
│    ├──  _settings.fonts.scss
│    ├──  ...
│    └─── _index.scss
│
└─── tools
│    ├──  _tools.gradients.scss
│    ├──  _tools.font-sizing.scss
│    ├──  ...
│    └─── _index.scss
│
└─── generics
│    ├──  _generics.page.scss
│    ├──  _generics.normalize.scss
│    ├──  ...
│    └─── _index.scss
│
└─── elements
│    ├──  ...
│    └─── _index.scss
│
└─── objects
│    ├──  ...
│    └─── _index.scss
│
└─── components
│    ├──  ...
│    └─── _index.scss
│
└─── trumps
│    ├──  ...
│    └─── _index.scss
│
└─── _index.scss

Note that here we are using a Sass concept called partials for stylesheets inside layers. A partial is a small chunk of styles which we can later import into another sass file. We name partials with a preceding underscore.

Inside each layer we create an _index.scss file. Inside that file, we use the @forward rule in sass to combine everything inside that layer and forward it as a module.

// theme/settings/_index.scss

@forward './settings.colors';
@forward './settings.fonts';

Then we import all the modules into the _index.scss file using the @use rule as below.

// theme/_index.scss

@use './settings';
@use './tools';
@use './generics';
@use './elements';
@use './objects';
@use './components';
@use './trumps';

These _index.scss files are optional and we use this pattern only if we want a single global style file. Otherwise it is recommended to use each layer as modules using @use rule or use individual partials by themselves.

You can learn more about sass "at-rules" in here.

Notice that in each sass at-rule (@forward or @use), underscore and the '.scss' extension is omitted

Here we have used @use rule instead of @import since Sass recommend the use of @use over @import for many reasons. You can read more about that in here

Now let's take a look at each layer of ITCSS.

Settings

This layer holds any global settings for your project. We should include settings which can be accessed from anywhere in this layer. For examples, font size, color palettes and configuration available for the entire project should be included in this layer.

In here we can use Sass variables to define colors, fonts used in the project as settings, then we can use that variable around the project.

// theme/settings/_settings.color.scss

$primary: #ea691e;
$secondary: #ff9988;
$primary-light: #fbcfc7;

// theme/components/_components.button.scss

@use '../settings/settings.colors' as colors;

.example-button {
    background-color: colors.$primary;
}

When using variables, mixing, etc. inside another partial, it is recommended to use the @use rule with an alias instead of using @import to import everything inside the partial.

Because, if we import the same stylesheet more than once, it will be evaluated again each time. If that stylesheet just defines functions and mixins, this usually isn’t a big deal, but if it contains style rules they’ll be compiled to CSS more than once.

With this approach, if you realize you need to change something, for an example the theme color, you only need change it in one place.

Tools

This layer houses the globally available tooling, namely mixins and functions.

Note that in here as well, we only keep globally available stuff in here. Any mixin or function that does not need accessing globally should belong in the partial to which it relates.

Tools layer comes after the Settings layer because, these mixins and functions may need global settings as parameters.

Examples for tooling that goes inside this layer are gradient mixins, font-sizing mixins, etc.

// theme/tools/_tools.gradients.scss

@mixin linear-gradient($direction, $colors) { 
  background: -webkit-linear-gradient($direction, $colors);
  background: -moz-linear-gradient($direction, $colors);
  background: -o-linear-gradient($direction, $colors);
  background: linear-gradient($direction, $colors);  
}

Generics

The Generic layer is the layer that houses very high-level, far reaching styles. It contains things like global box-sizing rules, normalize styles, CSS resets, etc.

// theme/generics/_generics.input.scss

input[type="search"]::-webkit-search-decoration,
input[type="search"]::-webkit-search-cancel-button {
  -webkit-appearance: none;
}

Elements

This layer includes the styles which are applied to bare HTML elements. We basically use HTML tag selectors in this layer. This is still a very low-specificity layer, but affects slightly less of the DOM, and is slightly more opinionated, hence its location in the Triangle.

// theme/elements/_elements.headings.scss
@use '../settings/settings.fonts' as fonts;

h2 {
  font-size: 25rem;
  font-family: fonts.$primary;
}

Typically, this layer is the last layer we'd find bare HTML element selectors. After this layer we'll basically be using classes to define everything else.

Objects

This is the first layer in which we find class selectors. As the name imply, we write the styles aiming objects which defines undecorated design patterns. Such objects can range from something simple as a .container of layout systems to complex object with many children.

If we are going to combine our partials to a single file, it's better to prefix everything inside our partials some keyword to avoid conflicts between class names.
(We have used xmpl as our prefix from here on)

// theme/objects/_objects.container.scss
@use '../settings/settings.breakpoints' as breakpoints;

.xmpl-container {
  width: 100%;
  padding-right: 15px;
  padding-left: 15px;
  margin-right: auto;
  margin-left: auto;

  @media screen and (max-width: breakpoints.$medium) {
    max-width: 720px;
  }

  @media screen and (max-width: breakpoints.$small) {
    max-width: 540px;
  }
}

Note that here we have used nesting to add the @media queries to the class.

This layer affects less of the DOM than the last layer, yet making modifications to the classes inside this layer could potentially have effects in a lot of other unrelated places.

Components

This I where we begin to style the recognizable parts of our UI. So, this is where the majority of our work takes place. In here also we are using classes for defining styles. Therefore the specificity has not increased yet. We shouldn't find any selectors with a lower specificity than one class in this layer.

// theme/components/_components.button.scss

.xmpl-button {
  display: inline-block;
  font-weight: 400;
  text-align: center;
  white-space: nowrap;
  vertical-align: middle;
  border: 1px solid transparent;
  padding: .375rem .75rem;
  font-size: 1rem;
  line-height: 1.5;
  border-radius: .25rem;
  transition: all 0.5s ease;
}

Trumps

This is the highest specificity layer. It includes the most explicit types of rule, with the most narrow focus.

Typically this layer beats (trumps) all other layers, and has the power to override anything at all that has gone before it. This layer contains utility and helper classes, hacks and overrides.

A lot of the declarations in this layer will carry !important tag.

// theme/trumps/_trumps.utilities.scss

.text-center {
  text-align: centre !important;
}

So, with ITCSS we are breaking our CSS codebase into groups based around specificity, reach and explicitness. This format allows us to write our CSS in an order that only ever adds to and inherits from what came previously.

So, now you might be wondering (or not),

what if I want to change the h2 tag in a specific page?
Where do I put that style?
Should it go inside the elements layer in the headings partial, or should I define those kind of style outside the ITCSS folder structure?
Maybe inside another separate stylesheet or go with in-line styles?

Well, personally I don't like inline styles. And defining those styles outside the ITCSS folder structure in a different stylesheet is not right as well.

So, if we need to change the styles of the h2 tag in a specific page (let's call it my-page), what we have to do is create a _components.my-page.scss inside the components layer and create a specific class for that h2 element and bind that h2 element to that class instead of binding to the html element directly.

<!-- my-page.html -->

<div>
   <h2 class="xmpl-my-page__title">Hello world</h2>
</div>

// theme/components/_components.my-page.scss

.xmpl-my-page__title {
  color: #ffffff
}

In my experience, with this approach we end-up creating so many component partials inside the component layer as well. Therefore, I prefer to maintain another layer right below the components layer called features or pages to keep these kind of styles separate. But it's not in the ITCSS architecture. It's just my preference 🤓.

So, that's pretty much everything (As I know) about the ITCSS architecture. Right now we have organized all of our stylesheets (files) in a scalable and maintainable manner.

Now let's move into how we can organize the code we write inside all the partials we have created to house them.

You might have noticed in the above example that I have used a strange way to name my class (xmpl-my-page__title). Well, that's the BEM convention. Let's dig deeper on that topic.

BEM

BEM stands for "Block Element Modifier". It is a naming convention that makes our code more consistent, transparent, scalable and maintainable. The BEM approach ensures that everyone in the team works with a single codebase and speaks the same language.

Now, what are Blocks, Elements and Modifiers?

Blocks

Blocks are the standalone entities which are meaningful on its own. For examples, we can identify a header, a list, a menu, a checkbox, an input, etc. as an entity.

Elements

An element is a part of a block that has no standalone meaning and is semantically tied to its block. For an example, we can identify a single item of a menu as an element, or the caption of a checkbox, or an item of a list, etc.

We use __element suffix to denote elements in BEM approach.

Modifiers

A modifier is a flag on a block or an element. We can use them to identify a change appearance or behavior of a particular block or an element. For an example, we can identify 'disabled' as the modifier in a disabled menu item, or the 'color yellow' of a container, etc.

We use --modifier suffix to denote elements in BEM approach.

So, how can BEM be any help?

Either we follow ITCSS or not, we have to write CSS class names sooner or later. But when naming those classes, we need to have a specific way of doing that. That's where BEM comes into play.

We can use the BEM's Blocks, Elements and Modifier pattern to name each class we create.

But why is it REALLY helpful?

The power of BEM comes with a preprocessor such as Sass.

Let's see why with an example.

<button>
   <img src="/assets/icon.svg" />
   <span>Submit</span>
</button>

Let's say we need to style the above button which has an icon inside (A sharable component). Also we need to have three background colors for the button to support default, success and danger scenarios as below.

Let's try to follow the previously learned ITCSS style as well.

In this case, first we need to create a partial to hold this component. Let's name it _components.button.scss. Then we need to identify Blocks, Elements and Modifiers. So, in this case the Block would be the <button> itself. We can identify the <img> & <span> as elements. And we can identify default, success and danger as modifiers.

Now we can get into naming classes.

We can name the Block as btn since it is a button. From there we start to name elements as below.

<button class="btn">
   <img class="btn__icon" src="/assets/icon.svg" />
   <span class="btn__text">Submit</span>
</button>

What we have right now is this.

With that we can define the styles as below.

// theme/components/_components.button.scss

.btn {
  padding: 0.5rem 1rem;
  margin: 1rem;
  display: flex;
  border-radius: 10px;
  justify-content: center;
  align-items: center;
  background-color: #cdcccc;

  &__icon {
    margin-right: 0.5rem;
  }

  &__text {
    font-size: 15px;
    color: #000000;
  }
}

This is the beauty of BEM + Sass. We can nest the classes using the & operator of Sass. What it does is, basically denoting the parent objects name. So that &__icon equals to .btn__icon and &__text equals to .btn__text. Since here we have the BEM's Blocks and Elements notations as well, nesting like this doesn't make our code unreadable.

After applying those styles, now we have this.

Since we need three buttons to show three states, we can create three btn blocks with the modifiers to denote each state.

<button class="btn">
   <img class="btn__icon" src="/assets/icon.svg" />
   <span class="btn__text">Submit</span>
</button>

<button class="btn btn--success">
   <img class="btn__icon" src="/assets/icon.svg" />
   <span class="btn__text">Submit</span>
</button>

<button class="btn btn--danger">
   <img class="btn__icon" src="/assets/icon.svg" />
   <span class="btn__text">Submit</span>
</button>

Now we have this,

Notice that we haven't used the --default modifier since, it is not needed as we already have the default state without any modifiers.

Now we can take the advantage of the BEM's modifiers in the stylesheet to create the other two states.

// theme/components/_components.button.scss

.btn {
  padding: 0.5rem 1rem;
  margin: 1rem;
  display: flex;
  border-radius: 10px;
  justify-content: center;
  align-items: center;
  background-color: #cdcccc;

  &__icon {
    margin-right: 0.5rem;
  }

  &__text {
    font-size: 15px;
    color: #000000;
  }

  &--success {
    background-color: #709558;
  }

  &--danger {
    background-color: #ca5b5b;
  }
}

We have nested the --success and --danger modifiers inside the .btn class, so that we can get the resulting classes as .btn--success and .btn--danger as we have used in our HTML.

Also notice that we haven't changed the btn class name in our HTML. Instead, we have added the btn--success class as another new class to the class list. Doing so, the styles defined under the .btn class also get applied to the button and only the background-color property gets replaced when the modifier class get applied.

Now we have this,

There are few more changes have to be done. We have to invert the color of the icon in success and danger states. And we also have to change the color of the text to white in that states as well.

For this we can introduce more modifiers to our HTML like below and use them to style them.

<button class="btn">
   <img class="btn__icon" src="/assets/icon.svg" />
   <span class="btn__text">Submit</span>
</button>

<button class="btn btn--success">
   <img class="btn__icon btn__icon--inverted" src="/assets/icon.svg" />
   <span class="btn__text btn__text--white">Submit</span>
</button>

<button class="btn btn--danger">
   <img class="btn__icon btn__icon--inverted" src="/assets/icon.svg" />
   <span class="btn__text btn__text--white">Submit</span>
</button>

// theme/components/_components.button.scss

.btn {
  padding: 0.5rem 1rem;
  margin: 1rem;
  display: flex;
  border-radius: 10px;
  justify-content: center;
  align-items: center;
  background-color: #cdcccc;

  &__icon {
    margin-right: 0.5rem;

    &--inverted {
      filter: invert(1);
    }
  }

  &__text {
    font-size: 15px;
    color: #000000;

    &--white {
      color: #ffffff;
    }
  }

  &--success {
    background-color: #709558;
  }

  &--danger {
    background-color: #ca5b5b;
  }
}

With that, now we have the final result.

Additionally, we also can prefix the .btn class at the root with some keyword (eg: .xmpl-btn) so that we won't get any conflicts in class names later on.

That's how we can take the advantage of BEM to write more organized CSS.

There are 3 major benefits we get with BEM approach.

Modularity

Block styles are never dependent on other elements on a page, so you will never experience problems from cascading.

You can also export the blocks from your old finished projects to new ones with ease.

Reusability

Composing independent blocks in different ways, and reusing them intelligently, reduces the amount of CSS code that you will have to maintain.

Also, with the power of a preprocessor such as Sass, you can further reduce the amount of code you have to write using nesting.

Structure

BEM methodology gives your CSS code a solid and consistent structure that remains simple and easy to understand.

That's it folks. It was quite a long article. But I hope this will be helpful guide for you.

See you in the next article. ✌️

Render props in React

Sivantha Paranavithana — Sat, 25 Sep 2021 21:52:46 +0000

In the previous articles, we discussed what is stateful logic sharing, why do we need it and one of the popular solution for that, HOCs.

In this articles let's take a look at another popular solution for the stateful logic sharing.

For the explanation I will use the same example that I have used in the previous articles.

In that examples we had three separate components before applying HOCs, with some duplicated stateful logic inside them. I will mention them here as well for the ease of reference.

If we take a closer look at these components, we can see that the only thing that are different from each other is the render method (And the name of the component obviously 😅).

So what if we just created a single component and pass what to render to that component as a prop?

That's exactly what we are going to do.

We can create a component called Counter and put the sharable stateful logic inside of it. And instead of rendering specific content we are going to render the content dynamically.

For that, we can use the render prop.

The render prop is, is an ordinary prop like any other whose value is a function. This function is responsible of rendering the dynamic content. And we can pass whatever information we need to share to that function as arguments.

Let's see that in code.

In below Counter component you can see that we just execute the render prop inside the render method. Also, we are passing the count and the increment handler as arguments to the this.props.render() function.

Then we can create a Button counter using the Counter component as below

const newButtonCounter = <Counter render={(count, increment) => <ButtonCounter count={count} increment={increment} />} />;

If we extract out the function inside the render prop...

(count, increment) => <ButtonCounter count={count} increment={increment} />

Here you can see that the argument which were passed to the function inside the render prop, are passed again to the ButtonCounter as props. Then we can use them inside the ButtonCounter as below.

import React, { Component } from "react";

export class ButtonCounter extends Component {
  render() {
    const { count, increment } = this.props;
    return <button onClick={increment}>Clicked {count} times!</button>;
  }
}

export default ButtonCounter;

In this way we don't have to write the stateful logic inside the ButtonCounter.

Likewise, we can create InputCounter and HoverCounter or any other component we want by this technique and not duplicate the stateful logic.

HOCs in React

Sivantha Paranavithana — Tue, 21 Sep 2021 13:43:49 +0000

In the previous post we discussed what is stateful logic sharing and why do we need it.

In this article let's discuss about HOCs which is one of the popular solution for the stateful logic sharing.

According to the React documentation, a higher-order component is a function that takes a component and returns a new component.

In other words, a higher order component is a function that transform a component into another enhanced component.

const EnhancedComponent = higherOrderComponent(WrappedComponent);

HOCs are used in common React libraries such as Redux’s connect and Relay’s createFragmentContainer.

Now let's see how HOCs can help us in avoiding duplication and stateful logic sharing.

In the previous article we saw that in each counter component, there were sharable stateful logic. We can move that into a HOC and wrap our counters from that HOC.

Let's see that in code.

First, we create a function called withCounter which takes a component as an argument. This function will return a new React component. And we can move all the sharable stateful logic inside of that new component.

Then we can pass the count state and the increment handler as props to the wrapped component.

Notice that we are also passing any additional props that might get passed into the new component we are creating, to the original component through {...this.props} notation. In that way we can still pass props to the original component even after wrapping it by the HOC.

Since we are now passing the count state and the increment handler as props, we have to reflect that change in each component as below, where we get the count and the increment handler from props.

import React, { Component } from "react";

export class ButtonCounter extends Component {
  render() {
    const { count, increment } = this.props;
    return <button onClick={increment}>Clicked {count} times!</button>;
  }
}

export default ButtonCounter;

With that, we can create the components with the counter functionality without duplicating the code using the HOC as below.

const ButtonWithCounter = withCounter(ButtonCounter);
const HoverWithCounter = withCounter(HoverCounter);
const InputWithCounter = withCounter(InputCounter);

With that, we don't need to lift the state up to share the state and the logic, therefore we can reuse this stateful logic in anywhere in the react component tree.

Not all HOCs look the same. Sometimes they accept only the component we want to wrap as the argument. Eg: withRouter HOC in React Router.

const NavbarWithRouter = withRouter(Navbar);

Some HOCs accept additional arguments. Usually these arguments are used inside the HOCs for configurations of the HOC. eg: createContainer in Relay.

const CommentWithRelay = createContainer(Comment, config);

Some HOCs look like below.

const ConnectedMyComponent =  connect(mapStateToProps, mapDispatchToProps)(MyComponent);

This pattern is common in React Redux. connect is just a function that returns an HOC. Then that HOC is used to wrap the MyComponent. We can see it clearly when we break it down as below.

const enhance = connect(mapStateToProps, mapDispatchToProps);
const ConnectedMyComponent = enhance(MyComponent);

If we want to talk more about HOCs, there are few things to keep in mind when creating HOCs.

We should avoid mutating the original component inside the HOC at all costs.

The reason for this is, when you mutate the original component's prototype inside the HOC, it affects every instance of the original component. This makes the original component unreliable to use anywhere else.

For an example, let's say we created an HOC which mutate the prototype of a component, and wrapped a component named MyComponent with that HOC. Then even when we use MyComponent without wrapping it with the HOC, it will still contain the mutation that the HOC did. Furthermore, if we apply another HOC on top of that, it might replace the first HOCs logic accidentally as well. Therefore, making HOCs as pure functions is crucial.

Don't use HOCs inside the render method.

Each time render method returns a component, React compares the previous component subtree recursively with the new subtree to identify any changes and decide either to update the component subtree or to unmount the current subtree completely and render the new subtree as a new.

And when using HOCs to wrap components, each of these components receive separate states. If we were apply HOC to a component inside a render method, each time the component get unmounted, the state of that component and all of children to be lost.

Instead of applying inside the render method, apply HOCs outside the component definition so that the resulting component is created only once. Then, its identity will be consistent across renders.

Static methods must be copied over.

Static methods inside a component won't be available in the new component which wrapped the original component with an HOC. Therefore we must copy all the static methods to the new component before returning it.

Refs aren't passed through

Although we pass refs as props to components, it's really not a prop. It is handled specially by React just like the key prop. Therefore refs won't be passed to the original component from the wrapped component through {...this.props} notation. Therefore, instead of using refs we should use forwardRefs and that is discussion for another time😉.

Now that we talked about HOCs, let's talk about render props which we can use as another solution for the stateful logic sharing in the next article.

What is stateful logic sharing and why do we need it?

Sivantha Paranavithana — Tue, 21 Sep 2021 12:59:11 +0000

Stateful logic is any code that uses the state. The stateful logic sharing is sharing stateful logic between multiple react components.

I believe the best way to understand this is with an example.

Let's say you want to create a component which has a button that increments a counter on click. We can implement that using a class component as below.

This will result a view like this, the counter increments with each button click.

Now, let's say we want another component which increments a counter on hover over a div. We can implement that using a class component as below.

This will result a view like this. The counter increments when the mouse is hovered over the div.

Now, let's say we want another component which increments a counter on each key press. We can implement that using a class component as below.

This will result a view like this. The counter increments on each keypress.

Now, let's backup for a minute. We can see that, in each of these scenarios we duplicated some logic. Specifically this part,

constructor(props) {
    super(props);

    this.state = {
        count: 0,
    };
}

increment = () => {
    this.setState((prevState) => ({ count: prevState.count + 1 }));
};

This part uses the component's local state, therefore this is a stateful logic. And in each component it stayed basically the same, since the logic is the same.

Although in this example we only had to duplicate a simple few lines of code, this situation can occur in more complex scenarios as well.

So, how can we avoid this duplication?

The immediate thought (At least in my mind😉) is to "lift the state up".

We can declare the state and the increment handler in the parent component and pass down the state and the handler to children as props.

But this can be done only when we can create the same parent for the children. If the components are scattered throughout the react component tree, lifting the state up is not gonna be the current solution,

In that case, we need another solution to share this stateful logic between each component to avoid duplication.

That's where HOCs (Higher Order Components) and render props comes into the rescue. We will discuss about HOCs and render props in the upcoming articles.

GitHub Student Developer Pack [FREE]

Sivantha Paranavithana — Sat, 18 Jul 2020 12:40:30 +0000

Are you a student?

No matter what you are studying, this post is for you.

Everyone knows that hands-on experience is very important. But the cost of most tools can be overwhelming. That's why GitHub started this program seven years ago to provide the best professional-grade developer tools and training for students for free.

It offers a lot of tools that are very useful for developers as well as designers, analysts, etc.

But first of all, you need to verify that you are eligible for the offer.

To be eligible for the GitHub Student Developer Pack, you must:

Be currently enrolled in a degree or diploma-granting course of studies such as a high school, secondary school, college, university, homeschool, or similar educational institution.
Have a verifiable school-issued email address or upload documents (school ID, class schedule, transcript, affiliation or enrollment verification letter) that prove your current student status.
Have a GitHub user account. (Obviously!)
Be at least 13 years old.

If you are eligible for the offer you can get the pack. It might take few days to verify your information. Once your information is verified you will get access to tons of good dev tools and courses for free.

So, let's take a brief look at what they offer this year,

A free 3-month individual subscription to learn about data science from the world’s top data scientists.

Domain registration, hosting, and management with 1 year free domain name registration on the .me TLD and SSL certification.

Domain names, web hosting, and websites with 1 year free domain name and Advanced Security (SSL, privacy protection, and more)

Free AWS Educate Starter Account worth $100 with access to the AWS cloud, free training, and collaboration resources.

Free access to 25+ Microsoft Azure cloud services plus $100 in Azure credit and learning resources.

Real-time development platform used to create half of the world’s games with free Unity Student Plan while you are a student.

A free subscription for professional desktop IDEs such as IntelliJ IDEA, PyCharm, and more.

A flexible, easy-to-use platform to deploy, run, and manage your apps with one free Hobby Dyno for up to two years.

1 year free pro tier access to a professional graphics and design platform.

$50 worth of platform credits for cloud hosting on DigitalOcean.

Six free months of 60+ courses covering in-demand topics like Web Development, Python, Java, and Machine Learning on educative.

A free license for Bootstrap Studio which is a powerful desktop app for creating responsive websites using the Bootstrap framework.

Free GitHub Pro while you are a student.

One standard .TECH domain free for 1 year and 2 free email accounts with 100 MB free storage.

Free 6-months access to all courses and workshops on Frontend Masters which provides in-depth JavaScript, Node.js & front-end engineering courses.

MongoDB is a general-purpose, document-based, distributed database. With the GitHub pack, you get $200 in MongoDB Atlas Credits, plus access to MongoDB Compass and MongoDB University including free certification.

Free access to Pro versions of GitKraken Git GUI, GitKraken Boards, and GitKraken Timelines while you're a student.

free 30-day One Month subscription to learn HTML, CSS, JavaScript, and Python in just 30 days!

Free Arduino Create Maker plan for 6 months and discounts on selected hardware.

GitHub Campus Experts are students who build technical communities on campus, with training and support from GitHub. You can apply to become part of the program while you’re a student.

With next.tech you can learn tech skills and build software directly from your browser with real, online computing environments. With the GitHub pack, you get free access to all interactive courses and cloud computing environments for 12 months.

A Web Hosting platform to host assignment & project work. You get the Designer package for free for 1 year & discounted upgrade offers with the GitHub pack.

An SSH client that works on desktop and mobile. Termius securely syncs data across all your devices. You get free access to the Premium plan while you're a student.

Iconscout is a design resources marketplace to get high-quality icons, illustrations, and stock images.
With the GitHub pack, you can download 60 premium icons per month for 1 year.

And the list goes on

There over 80+ tools from categories like monitoring tools, analytic tools, IDEs, server management tools, APIs, optimization tools, cloud-services, translation management tools, security tools, and many others which I failed to mention here.

I'll be sure to update the list as much as I can.

Get the GitHub Student Developer Pack. Thank me later 😉

Java OOP Cheatsheet

Sivantha Paranavithana — Thu, 16 Jul 2020 06:58:50 +0000

Liquid syntax error: 'raw' tag was never closed

Java Under the Hood

Sivantha Paranavithana — Sun, 12 Jul 2020 16:17:17 +0000

This post offers a brief introduction to how Java executes a code written in Java Language under the hood.

Here is the list that I am going to explore,

1. Java Compiler
2. JVM

Java Compiler

Is Java a compiled-language or an interpreted-language?

Kinda like both! The reason lies within the compilation process of Java.
In many other languages, their compilers convert the source code into machine-specific code and then the machine will execute the instructions resides in that machine code.

But in Java, the Java Compiler does not convert Java source code into machine code (i.e. Binary) directly. Instead, it converts the source code into an intermediary code called bytecode. Then the Java Virtual Machine (JVM) will execute that bytecode by interpreting it to the machine code. But JVM uses a Just In Time (JIT) compiler to compile some of the code into native code (machine code). Therefore, Java is both compiled and interpreted language.

The javac is a component of the Java Development Kit (JDK) which specifies the Java compiler.

The Java compiler transforms the source code located in .java files into .class files which are essentially the bytecodes of those Java Codes.

Not only just Java, basically any language can implement its compiler that parses the source code into valid bytecode, and then it can be executed using the JVM.

If you have multiple classes in a single .java file then, it will generate a .class file for each class.

Java Virtual Machine

After javac compiles the source code to bytecode, JVM executes it. This is called the program run phase.

The JVM is divided into three main subsystems.

Classloading Subsystem
Runtime Data Areas
Execution Engine

Other than that it consists of Native Method Libraries which are platform-specific executable code (written in c/c++) contained in libraries or DLLs and a Java Native Interface (JNI) which the interface that Execution Engine use to interact with the Native Method Libraries.

Classloading Subsystem

Classloading Subsystem is used for loading, linking and the initialization of the .class files generated by the javac

Loading

Java classes aren't loaded into memory all at once. They get loaded when they are required by an application (dynamic loading). Classes are loaded with the help of three class loaders.

Bootstrap Classloader - This loader is responsible for loading the core classes such as java.lang.Object, java.lang.Class and java.lang.Classloader from bootstrap classpath which is rt.jar. This Classloader is the parent of all the Classloaders.
Extention Loader - This loader continues the loading process by loading the classes that are an extension of the standard core Java classes. These classes are available to all applications running on the platform (i.e. JRE).
Application Loader - The loading ends by loading the initial user-defined class which resides in the application level classpath, which mentioned in the Environment Variable.

Above classloaders will follow Delegation Hierarchy Algorithm while loading class

What is Delegation Hierarchy Algorithm?

When a Classloader is requested to load a class, the Classloader will delegate the request to the parent Classloader.

For example, if the JVM is requested to load a class, the Application Classloader will delegate it to the Extension Classloader. Then the Extension Classloader will delegate it to the Bootstrap Classloader. If the Bootstrap Classloader is unsuccessful in loading the class, then the Extension Classloader will try to load it. Only if the Extension Classloader fails to find the class, then the Application Classloader will try to load the class.

If the class is not found even after the Application Classloader tries to load it, then an error will be thrown.

Linking

Linking a class involves following operations,

Verification - Ensure the bytecode is structurally correct.
Preparation - Memory will be allocated for static variables and the default values will be assigned to them.
Resolution - Symbolic memory references will be replaced with the actual values.

Initialization

This is the final phase of the Classloading subsystem. Here, all static variables will be assigned with their original values and then the static block will get executed. As a result, the main() method will get executed, therefore the other classes as well. It will cause the loading, linking, and initialization of those classes.

Runtime Data Area

The JVM creates multiple runtime data areas. Some of them are created and destroyed with the JVM and some get created when a new thread is created and destroyed when the respective thread ends.

There are five major data areas in the JVM.

Method Area

The simplest type of memory to manage. This is a shared resource. There is only one Method Area per JVM. It can consist of anything that can be completely determined at compile time such as static variables, constants(perhaps), code.

Heap Area

The least organized and most dynamic data area. This is a resource that is shared with all threads. The Heap is used to dynamically allocate and deallocate memory for class instances (objects) and arrays. Special operations such as new are needed to allocate heap storage. The memory assigned for objects never explicitly deallocated and this space is reclaimed by the garbage collector(discussed later). The memory assigned for the Heap is not contiguous. Deallocation may leave "holes" in the heap (a.k.a fragmentation).

Stack Area

For every thread, a separate runtime stack will be created. Therefore data stored in the stack are thread-safe, unlike in Method Area and Heap Area. For every method call, one entry will be made in the stack called a Stack Frame. A Stack Frame is divided into three subentities.

Local Variable Array - stores local variables and their corresponding values.
Operand Stack - If any intermediate operation is required to perform, then this will act as a runtime workspace to operate.
Frame Data - All symbols corresponding to the method are stored here. The catch block information is also stored here.

PC Registers

Each thread will have separate PC Register to hold the address of the machine instruction which is currently executing.

Native Method Stacks

For each thread, a Native Method Stack will be created to hold the native method information provided by the Native Method Libraries.

Execution Engine

After the bytecode load into memory and the Runtime Data Areas are allocated, then the execution of the bytecode will be done by the Execution Engine. Execution Engine consists of three subsystems.

Interpreter

The interpreter interprets the bytecode faster but executes slowly. If one method is called multiple times, every time the interpreter will interpret it.

JIT Compiler

The Just In Time (JIT) compiler will identify the hotspots of the code which are the code that gets repeated and get interpreted repeatedly, and compile those code into native code (machine-specific code) which improves the performance. The JIT compiler consists of the following components.

Intermediate Code Generator - Produces intermediate code for optimization.
Code Optimize - optimize the intermediate code generated above. Such as elimination of common sub-expressions, translation from stack operations to register operations, reduction of memory accesses by register allocation, etc.
Target Code Generator - Generate Machine Code (Native Code)
Profiler - Finds hotspots in the bytecode.

Garbage Collector

Collects and removes unreferenced objects(inaccessible objects / orphans). Garbage Collection can also be triggered manually by calling System.gc().

Thanks for reading.

See you in the next post!

Forem: Sivantha Paranavithana

The Art of Git Commits: Writing Messages That Your Future Self Will Thank You For

TL;DR

Introduction

What is a Git Commit?

The Anatomy of a Good Commit

Bad Commit Messages:

Good Commit Messages:

Quick Tips for Better Commit Messages

Use the Imperative Mood

Examples:

Commit Frequently

Git Commit Workflow

Conventional Commits: A Standard That Makes Sense

Common Types:

Real-world Example:

Git Hooks: Your Commit Quality Guardian

Setting Up Commitlint

Tools to Make Your Life Easier

The Long-Term Benefits

Conclusion

Discussion

Git Branching - A Production-Grade Branching Strategy for Enterprise Teams

Why Another Gitflow Guide? 🤔

The Branch Structure 🌿

Core Branches

Main Branch (main)

Development Branch (develop)

QA Branch (release/qa)

Staging Branch (release/staging)

Working Branches

Feature Branches (feature/*)

Hotfix Branches (hotfix/*)

Bugfix Branches (bugfix/*)

Real-World Scenarios 🎯

Scenario 1: Developing a New Feature

Scenario 2: Fixing Production Issues

Golden Rules for Success 🌟

Never:

Always:

Pro Tips for Team Success 💡

Tools to Make Your Life Easier 🛠️

Git Aliases

Branch Protection Rules

Conclusion 🎉

Share Your Thoughts! 💭

Node.js E2E Testing with Cypress: A Comprehensive Setup Guide

Introduction

What You'll Learn 🎯

Prerequisites

Setting Up Your Testing Environment

1. Installing Essential Dependencies

2. Docker-Based Test Database Setup

MySQL Configuration:

MongoDB Configuration:

3. Environment Configuration

Configuring Code Coverage with NYC

Cypress Configuration

Organizing Your Cypress Tests

Project Structure

Writing Effective Test Suites

Custom Commands

Best Practices for E2E Testing

Common Pitfalls and Solutions

TypeScript Integration

Conclusion

Resources

What's Next?

API Endpoint Design: CRUD vs Action-Specific Endpoints - A Developer's Guide

API Endpoint Design: The Great Debate 🤔

The Two Contenders in the Ring 🥊

1. The CRUD Champion

2. The Action-Specific Challenger

The CRUD Approach: Pros and Cons 📊

What's Awesome About CRUD

The Not-So-Great Parts

Action-Specific Endpoints: The Good and The Bad 🎯

The Good Stuff

The Challenges

Real-World Example: Show Me The Money! 💰

Main Branch (`main`)

Development Branch (`develop`)

QA Branch (`release/qa`)

Staging Branch (`release/staging`)

Feature Branches (`feature/*`)

Hotfix Branches (`hotfix/*`)

Bugfix Branches (`bugfix/*`)