Updating font size of headings

assets/css/common/main.css

@@ -7,7 +7,7 @@
 }
 
 .page-header h1 {
-    font-size: 48px;
+    font-size: 42px;
 }
 
 .pagination {

assets/css/common/post-single.css

@@ -44,29 +44,29 @@
 }
 
 .post-content h1 {
-    margin: 40px auto 32px;
-    font-size: 40px;
+    margin: 24px auto 22px;
+    font-size: 24px;
 }
 
 .post-content h2 {
-    margin: 40px auto 32px;
-    font-size: 40px;
+    margin: 22px auto 20px;
+    font-size: 22px;
 }
 
 .post-content h3 {
-    font-size: 32px;
+    font-size: 20px;
 }
 
 .post-content h4 {
-    font-size: 28px;
+    font-size: 20px;
 }
 
 .post-content h5 {
-    font-size: 24px;
+    font-size: 20px;
 }
 
 .post-content h6 {
-    font-size: 22px;
+    font-size: 20px;
 }
 
 .post-content a,

content/blog/efficient-data-modelling-hibernate-strategies-for-shared-colums.md

@@ -5,15 +5,15 @@ draft: false
 tags: ["java", "hibernate", "orm"]
 ---
 
-## Introduction
+# Introduction
 
 In database tables, common columns are often used to store metadata about entries, serving purposes such as auditing, multi-tenancy, and soft deletion. These common columns may include information like `created_by`, `updated_by`, `created_at`, and `last_modified_at`. While it's possible to duplicate these columns in entity objects, there's a more efficient way to handle this. Let's explore that.
 
-## Scenario
+# Scenario
 
 Consider a scenario where a set of resource tables shares common columns, such as `created_at` and `last_modified_at`. When mapping these tables to (javax.persistence) entities, we notice that all entity classes have common fields like `created_at` and `last_modified_at`.
 
-## Implementation
+# Implementation
 
 To adhere to the DRY (Don't Repeat Yourself) principle and leverage inheritance, we can create a parent class named `ParentEntity.java` to encapsulate these common attributes. Since we don't intend to create an object of this class, let's make it abstract.
 

content/blog/embracing-code-quality-with-pre-commit-framework.md

@@ -7,11 +7,11 @@ tags: ["pre-commit", "hooks", "git"]
 
 In the fast-paced world of software development, maintaining code quality is crucial. One effective way to ensure consistent coding standards and catch issues early in the development process is by using a pre-commit framework. In this blog article, we will explore the benefits and implementation of the pre-commit framework to streamline your development workflow.
 
-## What is the Pre-Commit Framework?
+# What is the Pre-Commit Framework?
 
 The [pre-commit framework](https://pre-commit.com/) is a powerful tool that allows developers to define and automate checks on their code before it is committed to version control. It acts as a gatekeeper, ensuring that only clean and high-quality code makes its way into the repository. By running a series of checks and tests before committing changes, developers can catch issues early, preventing bugs and maintaining a high standard of code.
 
-## Key Benefits:
+# Key Benefits:
 
 1. **Consistent Coding Standards:**
     Enforcing coding standards is crucial for readability and maintainability. Pre-commit hooks can be configured to check for adherence to coding style guides, ensuring that all team members follow the same conventions.
@@ -20,7 +20,7 @@ The [pre-commit framework](https://pre-commit.com/) is a powerful tool that allo
 3. **Reduced Code Review Overhead:**
     With pre-commit checks in place, the code that reaches the review phase is already vetted for common issues. This reduces the burden on code reviewers, allowing them to focus on higher-level aspects of the codebase.
 
-## Implementation:
+# Implementation:
 
 1. **Installation:**
     Start by integrating the pre-commit framework into your project. Detailed installation steps can be found [here](https://pre-commit.com/#install).
@@ -31,6 +31,6 @@ The [pre-commit framework](https://pre-commit.com/) is a powerful tool that allo
 3. **Running Checks:**
     Pre-commit hooks automatically run when you attempt to commit changes. If the hooks' checks pass, the changes are committed. If the checks fail, the commit does not occur, and you'll need to make the necessary changes before you can proceed with the commit. To manually run these checks without committing, use the command `pre-commit run --all-files`.
 
-## Conclusion:
+# Conclusion:
 
 The pre-commit framework is a valuable ally in the quest for code quality. By automating checks and tests, developers can catch issues early, reduce the likelihood of bugs, and foster collaboration within the team. Integrating pre-commit into your workflow is a proactive step towards maintaining a high standard of code and streamlining the development process. Embrace the power of pre-commit, and watch your codebase become more robust and maintainable.

content/blog/what-is-gitleaks.md

@@ -11,13 +11,13 @@ tags: ["gitleaks", "git", "security"]
 
 *"Use Gitleaks before a hacker uses it to exploit you."*
 
-## How to Use Gitleaks?
+# How to Use Gitleaks?
 
 Before using Gitleaks, you need to install it. There are various installation options, and we'll cover the best ones based on different scenarios. You can find a list of all available options [here](https://github.com/zricethezav/gitleaks#getting-started).
 
 Here are the most common scenarios where Gitleaks proves useful:
 
-### Scenario 1: Detecting Secrets in Committed Code
+## Scenario 1: Detecting Secrets in Committed Code
 
 If you want to detect secrets committed to your Git source code repository:
 
@@ -30,7 +30,7 @@ If you want to detect secrets committed to your Git source code repository:
 
 If you find secrets, consider using tools like BFG Repo Cleaner to remove them.
 
-### Scenario 2: Preventing Secrets from Being Committed
+## Scenario 2: Preventing Secrets from Being Committed
 
 To ensure you don't commit any secrets:
 
@@ -44,7 +44,7 @@ To ensure you don't commit any secrets:
 8. For detailed information on detected secrets in the staging area: `gitleaks protect --staged -v`
 9. If secrets are detected, remove them and add the changes back to the staging area.
 
-### Scenario 3: Automating Pre-Commit Checks
+## Scenario 3: Automating Pre-Commit Checks
 
 Automate the process from Scenario 2 by adding the `gitleaks protect --staged -v` command to your pre-commit hook file.
 
@@ -56,7 +56,7 @@ Automate the process from Scenario 2 by adding the `gitleaks protect --staged -v
 
 You can also use the pre-commit script provided by the Gitleaks community.
 
-### Scenario 4: Team-wide Prevention
+## Scenario 4: Team-wide Prevention
 
 To ensure the entire team doesn't check in any secrets:
 
@@ -75,14 +75,14 @@ To ensure the entire team doesn't check in any secrets:
 6. Install pre-commit: `pre-commit install`
 7. When committing, the pre-commit hook checks for secrets. Make sure each developer installs pre-commit using steps 1 and 6.
 
-### Scenario 5: CI Integration
+## Scenario 5: CI Integration
 
 Scan the project whenever anyone pushes code to the repository using `gitleaks detect` in CI tools like Github Actions.
 
-### Scenario 6: Using Gitleaks with Non-Git Repositories
+## Scenario 6: Using Gitleaks with Non-Git Repositories
 
 Gitleaks can be used with any source code repository, even if not version-controlled by Git. Use Gitleaks with a non-Git repository: `gitleaks detect --no-git`
 
-## Conclusion
+# Conclusion
 
 This blog covers various scenarios on how to use Gitleaks to detect and protect your source code from accidental leaks. The next blog will delve into how to remove detected secrets from your source code repository.