+ To equip software engineers with the knowledge and practices to efficiently deliver high-quality AI applications, leveraging cloud technologies and effective software lifecycle management.
+
+
+
+
+
+
+
My Focus Areas
+
+
+
+
+
+
Developer Advocacy
+
+ Building communities, creating tutorials, delivering talks & workshops, gathering feedback, and championing developer needs.
+
+
+
+
+
+
+
AI Exploration
+
+ Actively learning and experimenting with AI/ML, focusing on areas like LLMs, fine-tuning, and practical applications. Sharing my learning journey.
+
+
+
+
+
+
+
Content Creation
+
+ Crafting clear and engaging technical content: Blog posts, articles, videos, and talks covering AI, Cloud, Data Engineering, and DevRel.
+
+ );
+};
export default ListPosts
\ No newline at end of file
diff --git a/src/components/MainPainal.js b/src/components/MainPainal.js
index ae89368..a4cbb2f 100644
--- a/src/components/MainPainal.js
+++ b/src/components/MainPainal.js
@@ -1,10 +1,11 @@
-import React from 'react'
-import { Col, CardDeck, Card, CardBody } from 'reactstrap';
+import React, { lazy } from 'react'
import { graphql, StaticQuery } from "gatsby"
import JobDesc from "../components/JobDesc";
+import LazyComponent from "./LazyComponent";
-export default () => {
+const Testimonials = lazy(() => import("../components/Testimonials"));
+export default () => {
return (
{
}
}
}
-
}
}
`}
render={data => {
const jobDetails = data.site.siteMetadata.jobDetails;
- return
- {/*
-
-
Now open for ...
-
Open source community contribution!
-
I am new to open source contribution community. I want to be part of OpenSource projects from scratch. If you have an problem to solving and looking for a contributor, Please let me know.
+ )}
+
+ {/* Read More Link */}
+
+ Read full article
+ →
+
+
+
+
+ ))}
+
+ ) : (
+
+
+ No blog posts found. Check back soon for new content!
+
+
+ )}
+
+ {/* Back to Home */}
+
+
+ ←
+ Back to Home
+
+
+
+
+
+ );
+};
+
+export default BlogsPage;
+
+// Head export for SEO
+export const Head = () => (
+ <>
+ Blog | Portfolio
+
+
+
+
+
+
+);
+
+// GraphQL query to fetch all blog posts
+export const pageQuery = graphql`
+ query {
+ allMarkdownRemark(
+ filter: {
+ fileAbsolutePath: { regex: "/src/pages/blogs/" }
+ frontmatter: { published: { ne: false } }
+ }
+ sort: { frontmatter: { date: DESC } }
+ ) {
+ edges {
+ node {
+ id
+ excerpt(pruneLength: 200)
+ fields {
+ slug
+ }
+ frontmatter {
+ date
+ title
+ tags
+ }
+ }
+ }
+ }
+ }
+`;
diff --git a/src/pages/blogs/feature-toggles-ideas-and-uses.md b/src/pages/blogs/feature-toggles-ideas-and-uses.md
index 5b1aeb3..3744664 100644
--- a/src/pages/blogs/feature-toggles-ideas-and-uses.md
+++ b/src/pages/blogs/feature-toggles-ideas-and-uses.md
@@ -1,125 +1,133 @@
---
-title: Feature Toggles Ideas and Uses!
-subtitle: Easier to use! Easiest to Forget! Tools need to maintain! But better then Merge Conflicts!
-date: 20-01-2019
+title: Feature Toggles Ideas and Uses
+subtitle: Easier to use, easiest to forget! Tools needed for maintenance, but better than merge conflicts!
+date: 2019-01-20
auther: Sanjay
-readtime: 4 min
-tags: Git,Toggles,Feature Toggles,CI CD Pipeline,Automation
-keywords: Feature Toggles, Merge Hell, CI CD Pipeline, Automation
+readtime: 5 min # Adjusted read time slightly
+tags:
+ - Git
+ - Toggles
+ - Feature Toggles
+ - CI CD Pipeline
+ - Automation
+keywords: Feature Toggles, Merge Hell, CI CD Pipeline, Automation, Frontend Development, Continuous Integration
externallink: https://medium.com/@panda.sanjay18/feature-toggles-ideas-and-uses-baac271dc906
---
-#### Easier to use! Easiest to Forget! Tools need to maintain! But better then Merge Conflicts!
-> ### *Knife helped us to chopping the onion! Be careful it can cut you fingers.*
+#### Easier to use, easiest to forget! Tools needed for maintenance, but better than merge conflicts!
+
+> ### *A knife helps chop onions, but be careful – it can cut your fingers.*
-This concept is not new, in traditional programming we use some flag to show hide the feature. The flag is stored in the DB and access by API.
+Feature toggles aren't a new concept. In traditional programming, we often use flags (maybe stored in a database and accessed via API) to show or hide features. Today, let's focus on how feature toggles work in modern frontend applications.
+
+Imagine this scenario: two teams (let's say up to five teams is manageable), each with five members, working on the *same codebase*. Each team has its own features to deliver. This setup naturally raises some questions about managing the code effectively.
-Today we will talk about feature toggles in Frontend application.
+## The Challenge: Managing Code Across Teams
-Let see one scenario, we have two (suggest up to 5) team each having 5 members working on same code. Each team having their goal to deliver feature.
+When multiple teams collaborate on one codebase, the first instinct is often to isolate work using feature branches. But this approach frequently leads to complications:
-Here is some questions comes to mind when we work on a multiple team one codebase.
+* **The Long-Running Branch Problem:** Keeping features in separate branches for weeks or months seems safe at first. However, the longer a branch lives apart from the main development line (`develop` or `main`), the higher the risk of complex and painful merges later. Welcome to "merge hell."
-# How to manage code?
+* **The Daily Merge Dilemma:** "Can't we just merge `develop` into our feature branches daily?" Sure, you *can*, but this adds daily overhead and doesn't solve the fundamental problem. If another team merges a large feature (touching, say, 200 files), your "simple" daily merge can suddenly become a complex, conflict-ridden task.
-##### **Can we put all the new features team code in separate branch?**
+* **The Hidden Risks:** Even if you meticulously resolve merge conflicts (often needing significant cross-team discussion), hidden dangers remain. Subtle interactions between the merged codebases can introduce unexpected bugs or break existing functionality in ways that aren't immediately obvious during the merge.
-No, we can’t keep branches long running. When you merge that to develop branch. That might cause merge hell. Believe me that is bad.
+This cycle of complex merges and integration risks is frustrating and can drastically slow down your team's development velocity.
-##### **Can we not take update from develop branch to feature branch every day?**
+## The Testing Hurdle with Branches
-Yes, you can do that every day one of your team members need to take the responsibility.
+"Okay, but can't automated End-to-End (E2E) tests catch these integration issues?"
-##### **What if develop branch code is recently updated by other team a big feature with changes in 200 files.**
+That's a good point! E2E tests *can* help. However, when you merge large, long-lived branches, you often need to spend significant time fixing tests to align with all the new changes. Even if the E2E tests eventually pass, manual testers still face challenges. They need to understand and test new scenarios and interactions they weren't previously aware of, consuming valuable time and effort.
-Now think about the merge conflicts and even if you solve the merge conflict by collaborate between team. You don’t know which part of code might break.
+## The Release Bottleneck with Branches
-If every month if you find this two times also this is frustrating and time consuming.
+"Why not just release the feature branch when the feature is ready?"
-# How to test features?
-##### **Can we not do automated E2E testing which will help to find the issues?**
+Sounds simple, right? You're finally ready to ship your hard work to production – time to celebrate! 🥂
-Very good, you can do that. But the we need to fix the test to allign with new features. E2E test passed but now it’s time for tester to test.
+But then reality hits:
-Now tester will need to understand the new scenario which he was not aware of. Think about the time west every place.
+* "Oh no! The backend API isn't ready yet. That will take a few more weeks."
+* "Oops! The third-party integration we depend on is delayed."
+* "Hold on! Business decided this feature needs to go out *after* another feature, which isn't ready. We need to wait three months."
-# How to release feature?
-Can you not release the feature when that is ready?
-Great you are close to send your hard work to production time for party.🥂
+"No worries," you might think, "we're safe in our separate branch. We'll just wait."
-Oh no! The backend is not ready yet that will take few weeks, a third party integration taking time.
+But we're supposed to be agile! Waiting isn't ideal. The team needs to move on to new features, repeating the whole branching and merging cycle. Meanwhile, who is maintaining that delayed feature branch, keeping it updated with `develop`?
-Or
+Fast forward two weeks or three months...
-Oh no! This feature will go after some other feature. Wait for 3 month.
+"Aha! The backend is finally ready! Let's merge the feature branch!"
-Ok we are in separate branch no worries we will wait.
+A developer estimates, "Give me a couple of hours to handle the merge."
-We are in agile, we can’t wait for things to go. It’s time to move ahead for new features. Let’s repeat all the above.
+Business waits eagerly for the good news.
-Think about who is maintaining that later release branch.
+... "Oh no! Not again!" 🙄 The `develop` branch has accumulated many new changes. Merging the old feature branch now involves resolving numerous conflicts. Afterwards, *both* the original feature *and* the newly integrated changes need thorough testing across all aspects. The release is delayed again, maybe until tomorrow, maybe longer.
-After 2 weeks or three months…
+Repeat this painful process for every delayed feature release.
-Aha..we have the branch ready let’s tell a developer to merge the feature branch to develop.
+If you recognize this pain, let's dive into a potential solution.
-Developer says allow me 2hr I will be ready with build.
-Business is waiting for the good news.
+## Feature Toggles: The Sharp but Helpful Alternative
-Oh no! Not again. Develop branch having new changes we need to merge that resolve conflict then we have to test both feature every aspect. We can go release tomorrow. 🙄
+> ### *Very sharp like a knife, but very helpful.*
-Repeat this for every release.
+Let's revisit our scenario: multiple teams working on the same codebase, each delivering features. How can feature toggles help?
-Now you know/remember the pain. let’s dive into the the solution.
+Think of each new feature being protected by a flag (a simple `if` condition). These flags are typically stored in configuration files (like JSON) within your project.
-# Feature Toggles!
-## Very sharp like knife but very helpful.
-Let’s recap the scenario, we have two (suggest up to 5) micro team each having 5 members working on same code. Each team having their goal to deliver feature.
+**Example:** Team A is building `feature1`, and Team B is building `feature2`. Both teams commit their code (wrapped in feature toggles) directly to the main `develop` branch.
-##### **How feature Toggles help us?**
+* When Team A builds the application for testing, their build configuration enables the `feature1` toggle and disables `feature2`. They only see and test their feature.
+* Conversely, Team B's test build enables `feature2` and disables `feature1`.
-Think that each feature will protected by a flag (e.g If condition) and those flags stored in a json files in your project. (You can store this any format depends on the project)
+How cool is that?
-Example: Team A develop a feature which is given name feature1 and Team B create one which is Feature2.
+With this approach, you avoid long-running feature branches and stay continuously integrated with the main `develop` branch.
-When you build(e.g Make a bundle) your application as a Team A, your expectations is that need to show you only feature1 and hide feature2. Vice versa for Team B.
+### Building Confidence with Toggled Features
-How cool!!
+"How can teams be confident their code works when the main branch contains multiple other teams' untested features?"
-Now we are at stage where we don’t need to create long running feature branches and we are always up-to-date with develop branch.
+This is where disciplined testing, especially E2E testing, becomes crucial. Your automated test suite needs to be toggle-aware. When you commit changes, the CI/CD pipeline should run tests against different toggle combinations.
-Let’s answer some of the questions.
+### How "Toggle-Aware" Testing Works
-##### **How team have confidence on their code when it’s have multiple untested feature?**
+The test suite runs multiple times with different configurations:
-Here is the part you have to be careful with E2E testing. Which will help you when you commit your changes this will perform switch off and switch on testing.
+1. **Build for Team A:** `feature1` toggle ON, `feature2` toggle OFF. Run only the tests relevant to `feature1`.
+2. **Build for Team B:** `feature1` toggle OFF, `feature2` toggle ON. Run only the tests relevant to `feature2`.
+3. **(Optional but Recommended) Full Build:** All toggles ON (or relevant combinations). Run regression tests covering interactions.
-##### **How switch off and switch on testing will work?**
+This ensures features work in isolation and don't break existing functionality when disabled.
-So it will run testing on for both the build for Team A and Team B.
+### Releasing Features to Production
-Take Team A build, which is feature 1 toggle switch on and feature 2 will be switched off. And the test will only run feature 1 test. And the opposite of Team B.
+When a feature (say, `feature1`) is fully tested and ready for release:
-##### **How we will go production?**
+1. Remove the `feature1` toggle flag from the configuration.
+2. Remove the corresponding `if (feature1Enabled)` checks from the codebase.
+3. Deploy the `develop` branch to production.
-When ever we ready with any feature we just remove the toggle from the config and go live from develop.
+If a feature faces delays (like waiting for the backend), just keep its toggle in place (and turned off in the production configuration). The code is merged, but the feature remains hidden from users.
-If any delay in delivery keep the toggle.
+## Adopting the Feature Toggle Workflow
-#### **Life is little different here, we have to adopt some process first.**
+Life with feature toggles requires adopting some new processes:
-1. No long running big feature branch.
-2. Keep team toggle config in different files.
-3. Adopt fail first approach
-4. Everything need to automated.
-5. Unit testing followed by functional testing with toggle on/off test and regression testing with toggle on/off test.
-6. Keep track of your toggles once released feature, remove toggle from code.
-7. Make the removal also automated. Use tool like (https://github.com/facebook/jscodeshift)
+1. **No More Long-Running Feature Branches:** Commit small, incremental changes directly to the main branch, wrapped in toggles.
+2. **Manage Toggle Configurations:** Keep toggle settings organized, perhaps in separate files per environment or team for clarity during development.
+3. **Test Thoroughly:** Implement robust unit, integration, and E2E tests that are toggle-aware. Test features both when toggled ON and OFF.
+4. **Automate Everything:** Automate builds, testing with different toggle configurations, and deployments.
+5. **Clean Up Toggles:** This is critical! Once a feature is fully released and stable, *remove the toggle* and the associated conditional logic from the codebase. Dead toggles add complexity.
+6. **Automate Toggle Removal:** Use tools like codemods (e.g., [jscodeshift](https://github.com/facebook/jscodeshift)) to help automate the removal of toggle code once a feature is launched.
-If your safety precaution is well set then you are all good to use toggle and release your features with confident. All the best!
+With the right safety precautions and automation, feature toggles allow you to release features more confidently and frequently. All the best!
-Please let me know your solution for the above problem. Might that helpful for others!
+---
-##### If you Like, Please give me a clap on [@medium](https://medium.com/@panda.sanjay18/feature-toggles-ideas-and-uses-baac271dc906)
\ No newline at end of file
+What are your solutions to the multi-team, single-codebase challenge? Please share in the comments – it might help others!
diff --git a/src/pages/blogs/test-page.md b/src/pages/blogs/test-page.md
new file mode 100644
index 0000000..ac7259d
--- /dev/null
+++ b/src/pages/blogs/test-page.md
@@ -0,0 +1,95 @@
+---
+title: "Test Markdown Page"
+date: "2025-04-21"
+tags: ["test", "markdown"]
+published: false # Exclude from blog list
+description: "A test page to showcase various Markdown features."
+---
+
+# Heading 1
+
+This is a paragraph demonstrating basic text formatting. You can have **bold text**, *italic text*, and `inline code`.
+
+## Heading 2
+
+Here's an unordered list:
+* Item 1
+* Item 2
+ * Sub-item 2.1
+ * Sub-item 2.2
+* Item 3
+
+And an ordered list:
+1. First item
+2. Second item
+3. Third item
+
+### Heading 3
+
+Let's include a blockquote:
+> This is a blockquote. It can span multiple lines and is often used for citations or highlighting text.
+
+#### Heading 4
+
+Here's a horizontal rule:
+
+---
+
+##### Heading 5
+
+Now for some code blocks.
+
+Inline code: `const greeting = "Hello";`
+
+A fenced code block with syntax highlighting (JavaScript):
+```javascript
+function greet(name) {
+ console.log(`Hello, ${name}!`);
+}
+
+greet('World');
+```
+
+A fenced code block without specified language:
+```
+This is just plain text
+inside a code block.
+ Indentation is preserved.
+```
+
+###### Heading 6
+
+Links and Images:
+
+A link to [Google](https://www.google.com).
+A link to an internal page: [My Works](/works)
+
+An image (requires the image file to exist in the static folder or be handled by Gatsby Image):
+
+
+Tables:
+
+| Header 1 | Header 2 | Header 3 |
+| :------- | :------: | -------: |
+| Align L | Center | Align R |
+| Cell 1 | Cell 2 | Cell 3 |
+| Cell 4 | Cell 5 | Cell 6 |
+
+Task Lists:
+
+* [x] Completed task
+* [ ] Incomplete task
+* [ ] Another task
+
+Emphasis:
+
+* This is *italic*.
+* This is _italic_.
+* This is **bold**.
+* This is __bold__.
+* This is ***bold and italic***.
+* This is ___bold and italic___.
+* This is `inline code`.
+* ~~Strikethrough~~
+
+This file should now be accessible at `/blogs/test-page` but won't appear in your main blog listing if the listing query filters by `published: true` (or similar logic).
diff --git a/src/pages/contact.js b/src/pages/contact.js
new file mode 100644
index 0000000..3e75ba9
--- /dev/null
+++ b/src/pages/contact.js
@@ -0,0 +1,21 @@
+import React from 'react'
+import Layout from '../components/layout'
+import SEO from '../components/seo'
+import PortfolioSideBar from '../components/PortfolioSideBar'
+import SkillsSideBar from '../components/SkillsSideBar'
+import ContactForm from '../components/ContactForm'
+
+const ContactPage = () => (
+
+
+
+
+
+
+
+
+
+
+)
+
+export default ContactPage
\ No newline at end of file
diff --git a/src/pages/index.js b/src/pages/index.js
index 3f2f9d9..df26725 100644
--- a/src/pages/index.js
+++ b/src/pages/index.js
@@ -1,20 +1,95 @@
-import React from "react"
-import { Row } from 'reactstrap';
-import Layout from "../components/layout"
-import SEO from '../components/seo'
-import PortfolioSideBar from "../components/PortfolioSideBar";
-import SkillsSideBar from "../components/SkillsSideBar";
-import MainPainal from "../components/MainPainal";
+import React, { useEffect } from 'react';
+import { graphql } from 'gatsby'; // Import graphql
+import siteConfig from '../config/siteConfig';
+import Layout from '../components/layout';
+import SEO from '../components/seo';
+import Header from '../components/Header';
+import HeroSection from '../components/HeroSection';
+import MissionSection from '../components/MissionSection';
+// Focus Areas and Featured Work imports removed but components kept
+import BlogSection from '../components/BlogSection';
+import YouTubeSection from '../components/youtube/YouTubeSection';
+import ConnectSection from '../components/ConnectSection';
+import Footer from '../components/Footer';
+import { initFadeInSections } from '../utils/animations';
-export default () => {
- return (
-
-
-
-
-
-
-
-
- )
-}
+// Import styles
+import '../styles/global.scss';
+import '../styles/tailwind.css';
+
+// Destructure data from props (including GraphQL result)
+const IndexPage = ({ data }) => {
+ useEffect(() => {
+ // Initialize fade-in animations
+ const cleanup = initFadeInSections();
+
+ // Add dark-bg-pattern class to body
+ document.body.classList.add('dark-bg-pattern', 'text-slate-300', 'antialiased');
+
+ return () => {
+ cleanup();
+ document.body.classList.remove('dark-bg-pattern', 'text-slate-300', 'antialiased');
+ };
+ }, []);
+
+ // Extract blog posts from GraphQL data
+ const latestPosts = data.allMarkdownRemark.edges;
+
+ return (
+ <>
+
+
+
+
+
+ {/* Reordered to show YouTube section before Blog section */}
+
+
+
+
+
+
+ );
+};
+
+export default IndexPage;
+
+// Export Head function for Gatsby 5's built-in head support
+export const Head = () => (
+ <>
+
+
+
+
+
+);
+
+// Add GraphQL query to fetch latest 3 blog posts
+export const pageQuery = graphql`
+ query {
+ allMarkdownRemark(
+ filter: {
+ fileAbsolutePath: { regex: "/src/pages/blogs/" }
+ frontmatter: { published: { ne: false } } # Add filter to exclude published: false
+ }
+ sort: { frontmatter: { date: DESC } }
+ limit: 3
+ ) {
+ edges {
+ node {
+ id
+ excerpt(pruneLength: 100)
+ fields {
+ slug
+ }
+ frontmatter {
+ date(formatString: "MMMM DD, YYYY")
+ title
+ tags
+ }
+ }
+ }
+ }
+ }
+`;
diff --git a/src/pages/works.js b/src/pages/works.js
new file mode 100644
index 0000000..27e2da0
--- /dev/null
+++ b/src/pages/works.js
@@ -0,0 +1,136 @@
+import React, { useState, useEffect } from 'react';
+import { graphql, useStaticQuery } from 'gatsby';
+import Header from '../components/Header';
+import Footer from '../components/Footer';
+import ProjectCard from '../components/ProjectCard';
+import SEO from '../components/seo';
+import siteConfig from '../config/siteConfig';
+
+// Import styles
+import '../styles/global.scss';
+import '../styles/tailwind.css';
+
+const ProjectsPage = () => {
+ const [filter, setFilter] = useState('all');
+
+ useEffect(() => {
+ // Add dark-bg-pattern class to body to match main site design
+ document.body.classList.add('dark-bg-pattern', 'text-slate-300', 'antialiased');
+
+ return () => {
+ document.body.classList.remove('dark-bg-pattern', 'text-slate-300', 'antialiased');
+ };
+ }, []);
+
+ const data = useStaticQuery(graphql`
+ query {
+ site {
+ siteMetadata {
+ projects {
+ title
+ description
+ category
+ tech
+ image
+ github
+ demo
+ }
+ }
+ }
+ }
+ `);
+
+ const projects = data.site.siteMetadata.projects;
+ const filteredProjects = filter === 'all'
+ ? projects
+ : projects.filter(p => p.category.toLowerCase() === filter.toLowerCase());
+
+ const createSlug = (title) => title.toLowerCase().replace(/\s+/g, '-');
+
+ return (
+ <>
+
+
+
+
+ {/* Decorative elements matching the main site */}
+
+
+
+
+ {/* Header */}
+
+
+ My Work
+
+
+ Explore my projects and case studies in full-stack development, data engineering, and cloud architecture.
+
)
-}
\ No newline at end of file
+}
+
+export default ComingSoon;
\ No newline at end of file
diff --git a/src/templates/blog-post.jsx b/src/templates/blog-post.jsx
index 9703acd..e6cf738 100644
--- a/src/templates/blog-post.jsx
+++ b/src/templates/blog-post.jsx
@@ -1,49 +1,113 @@
-import React from 'react';
-import { graphql } from 'gatsby';
-import { Col, Row } from 'reactstrap';
-import Layout from '../components/layout';
-import PortfolioSideBar from '../components/PortfolioSideBar';
-import SkillsSideBar from '../components/SkillsSideBar';
-import SEO from '../components/seo'
+import React from "react"
+import { graphql, Link } from "gatsby"
+import Layout from "../components/layout"
+import SEO from "../components/seo"
+import { useTheme } from "../context/ThemeContext" // Import useTheme hook
+import { calculateReadingTime } from '../utils/readingTime';
+import '../styles/blogPost.scss' // Import blog post specific styles
+import 'prismjs/themes/prism-okaidia.css'; // Import a PrismJS theme for code blocks
-export default ({ data }) => {
+const BlogPost = ({ data, pageContext }) => {
const post = data.markdownRemark;
+ const { previous, next } = pageContext; // Get previous/next post data
+
+ // Basic Scroll to Top functionality
+ const scrollToTop = () => {
+ window.scrollTo({ top: 0, behavior: 'smooth' });
+ };
+
return (
-
-
-
-
})
+