DEV Community: Saurabh Mhatre

I Built a 7-Level Valentine Week Game Using GitHub Copilot CLI

Saurabh Mhatre — Sat, 14 Feb 2026 12:46:37 +0000

This is a submission for the GitHub Copilot CLI Challenge

What I Built

I have built “Valentine Week Love Quest”, a browser-based 2D mini-game created with the help of GitHub Copilot CLI and the Claude 4.5 Haiku model. The game turns the 7 days of Valentine’s Week into a fun, interactive journey where the player helps a character reach their partner by completing themed challenges for each day.

The experience starts by asking for both partners’ names, which makes the entire journey feel personal. The player then progresses through seven unique levels, each inspired by a day from Valentine’s Week:

🌹 Rose Day: Collect roses within a time limit
💍 Propose Day: Reach the partner while avoiding moving obstacles
🍫 Chocolate Day: Collect disappearing chocolates before they respawn
🧸 Teddy Day: Carry a teddy while movement becomes slower
🤝 Promise Day: Choose and collect meaningful promise tokens
🤗 Hug Day: Navigate through a small maze to reunite
❤️ Valentine’s Day: Final challenge with obstacles leading to the proposal scene

To make the gameplay engaging, I added:

A lives system and score tracking
Increasing difficulty across levels
Timers, moving obstacles, and small strategic elements
Smooth transitions and visual feedback on level completion

After completing all seven levels, the final moment is unlocked: a personalized proposal message based on the names entered at the beginning. This creates an emotional payoff and turns a simple game into a story-driven experience.

The project was built using:

HTML Canvas for rendering
Vanilla JavaScript for game logic
GitHub Copilot CLI to generate and refine gameplay mechanics
Claude 4.5 Haiku from Github Copilot CLI interface

The goal was to create something light, fun, and relatable that combines gameplay, storytelling, and AI-generated content into a single interactive Valentine’s experience.

Demo

Demo Link:-
Valentines Week Quest

This game is designed as a 7-day love journey. Each level represents a day from Valentine’s Week, where the player moves one step closer to reaching their partner. Below is a walkthrough of the experience through each stage.

Video demo:-

We first ask for players' and their partner's name for personalisation:-

🌹 Level 1 — Rose Day

The journey begins with a simple mission: collect roses scattered across the map within a limited time. This level introduces the player to movement, collection mechanics, and the core objective is moving forward with small gestures:

💍 Level 2 — Propose Day

Now the challenge increases. The player must reach their partner while avoiding moving obstacles. One wrong move can cost a life, making timing and positioning important:

🍫 Level 3 — Chocolate Day

Chocolates appear and disappear across the map, adding urgency. The player must quickly collect them before they respawn elsewhere.

🧸 Level 4 — Teddy Day

The objective is to carry a teddy to the partner. Movement slows down while carrying it, which makes planning the path more important.

🤝 Level 5 — Promise Day

This level introduces choice. The player collects meaningful promise tokens for their partner.

🤗 Level 6 — Hug Day

A maze-like layout adds a navigation challenge. The player must find the correct path to reach their partner while avoiding moving blockers.

❤️ Level 7 — Valentine’s Day (Finale)

The final level brings everything together. The player must survive obstacles and reach their partner with at least one life remaining.

Once completed, a personalized proposal message is generated using the names entered at the beginning, creating a heartfelt ending to the 7-day journey.

My Experience with GitHub Copilot CLI

This project was built almost entirely through an iterative workflow using GitHub Copilot CLI, and it genuinely changed how quickly I could move from an idea to a working prototype.

Instead of starting with a fixed game design, I began with a single step: a small Valentine-themed browser game. From there, I used Copilot CLI as a thinking partner to gradually expand the idea into a 7-level experience representing each day of Valentine’s Week.

What worked really well was the ability to describe features in plain language and let Copilot generate structured starting points. I used it to:

Scaffold the initial HTML Canvas game setup
Add player movement and collision detection
Introduce collectible items and scoring
Evolve the game from a single level into a multi-level system
Add timers, lives, and increasing difficulty

The biggest productivity boost came from making small, focused prompts. Instead of asking for everything at once, I extended the game step by step, first building the core mechanic, then layering in challenges, transitions, and polish. This made the development feel fast and iterative rather than overwhelming.

Copilot CLI was especially helpful when:

Converting a prompt to a multi-level game which mainly uses emojis
Adding gameplay enhancements like obstacles and timers
Refining UI elements and transitions

I mainly used Claude 4.5 Haiku in GitHub Copilot CLI. Overall, Copilot CLI felt less like a code generator and more like a rapid prototyping companion. It allowed me to focus on the fun parts like gameplay ideas, level design, and storytelling, while speeding up the repetitive parts of implementation.

This project started as a simple Valentine's Day idea and grew into a complete 7-level interactive journey, and Copilot CLI played a central role in making that evolution smooth and fast.

That was it from my end for today. If you liked the concept, then some appreciation for the article. See you all in the next post 👋

Security, Cloud Costs, and Bugs: How I solved the Developer's Three Biggest Nightmares in a single app

Saurabh Mhatre — Sun, 08 Feb 2026 14:11:04 +0000

This is a submission for the Algolia Agent Studio Challenge: Consumer-Facing Non-Conversational Experiences

What I Built

Introducing DevSolve
DevSolve is a "Smart Helper" for software developers. It works like a specialised search engine that scans our project files and instantly gives us the answers we need to keep our app safe by checking vulnerabilities in npm packages, cheap by checking for cloud costs, and bug-free by giving solutions to common console errors.

Instead of forcing us to chat with an AI or look through endless pages of documentation, DevSolve looks at our work and proactively tells us three things:

Is our code safe?
It looks at the npm packages our app uses and compares them against a global list of known security threats. If an npm package we’re using is "broken" or dangerous, DevSolve flags it and tells us exactly which version we can use to fix it.
How much will app deployment cost?
Building in the "cloud" (like AWS) can get expensive fast. DevSolve reads our infrastructure plans(Terraform IaC snippet) and instantly estimates our monthly bill. It’s like having a price tag appear on our code before we buy it.
Why is the app broken?
When our code crashes, it usually leaves a messy "error log." DevSolve cleans up that mess by checking console log errors, finding the specific error code, and showing us the official fix from the documentation so we can get back to work faster.
How healthy is my entire project? (Stack Health Advisor)
This is the "Control Room" of the app. By selecting our framework and infrastructure, we get a bird’s-eye view of our project's health. It provides a letter grade (like an A+) based on security, tells us our total estimated cost, and gives us a stability score based on common error patterns.

Demo

We can find the app demo here:- DevSolve Link

Also, here's a video demonstration of app's features:-

DevSolve is divided into four sections:-

1. Vulnerabilities check
Most developers only check for vulnerabilities when a build fails or an automated email arrives. The Vulnerabilities section is the "security guard" of our app, which instantly highlights if an npm package used in our app is compromised by instantly checking the package.json.

When users visits the vulnerabilities section, we show them the option to either paste package.json from their app into the app or search for vulnerabilities from the search bar. A list of common vulnerabilities is shown in list view below search as well:-

Once the user pastes package.json, we show compromised packages if there are any, along with a solution to fix the package on the right side panel:-

2. Smart Error Analysis
Documentation is often thousands of pages long. When our app crashes, we don't have time to read; we need to fix it. DevSolve turns messy error logs into instant solutions.

What it does:
The Error Analysis tool acts as an intelligent bridge between our broken code and the official fix. It allows us to:

Paste Raw Logs: We can simply paste console error output or a cryptic error message directly into the analyser.

Automatic Extraction: The app instantly "scans" the text to identify specific error codes (like 401 Unauthorised or 500 Internal Server Error).

Proactive Diagnostics: Once an error is found, the Auto-Diagnostic sidebar immediately pulls the "Truth Layer" solution from the documentation.

We can directly paste the error log or search for specific error codes when we open this section. Also list of common errors are shown in the list below:-

When the user pastes a console error in the search section, the app automatically shows the error caused and the solution to fix the error:-

3. Cloud Cost Estimation & Risk
Cloud pricing is notoriously complex and often leads to 'bill shock' at the end of the month. DevSolve brings financial transparency directly into our code editor.

What it does:
The Cloud Cost tool acts as a real-time financial auditor for our infrastructure. Instead of manually checking provider pricing pages, we can:

Analyse IaC Snippets: User can paste Terraform or CloudFormation code directly into the analyser or search for current prices of components using search.

Once the user pastes the Terraform IAC snippet, we get smart analysis as shown below:-

Automatic Resource Detection: The app identifies specific resources, such as an aws_instance of type t3.medium, and instantly matches it to its current market price.

Visual Cost Estimates: As seen in the screenshots, the app generates a clean report showing the provider, region, and exact monthly cost for each resource.

Key Feature: Risk Prevention
DevSolve doesn't just show us prices, it helps us avoid expensive mistakes before they happen.

4.Stack Health Advisor
Choosing the right technology is only half the battle; knowing how that stack performs in the real world is the other. The Stack Health Advisor gives us an instant 'Pulse Check' on our architectural choices.

The Stack Health Advisor acts as a strategic consultant for our project. By selecting our primary components, we get an immediate breakdown of three critical factors:

Security Risk: It assigns a letter grade (like an A+) to our stack. It proactively checks if our specific framework version has any known vulnerabilities that haven't been patched yet.
Monthly Cost: It calculates our estimated infrastructure spend based on the components we have selected (e.g., AWS EC2 vs. ElastiCache). This helps us see the financial impact of our technical choices in real-time.
Stability Index: It provides a percentage-based stability score by cross-referencing our stack against common error patterns in the app's knowledge base. A high score means the user's chosen tools are historically reliable and well-documented.

In the above example, the Stack Health Advisor is evaluating a Vue.js frontend running on an AWS t3.medium instance. We can see an 'A+' security rating, a $30 monthly cost estimate, and a 98% stability index. This bird's-eye view allows leads and architects to validate their stack's health in seconds, ensuring the project remains secure and within budget.

Algolia AI Agent Studio integration
I was also able to integrate Algolia AI Agent Studio filter suggestions API locally in the app to show filters in error analysis section, as shown in below screenshot:-

For this, I created an AI agent in Algolia Agents studio section using a modified instructions prompt to filter data from error codes related Algolia index based on search query(error code) inserted by the user.

This allowed me to test the agent capabilities in agent studio sandbox as shown below:-

Then filterSuggestions option was added in widgets code section to show filter suggestions to the end user.

The filter suggestions can be used by the users for intelligent, deeper search of error codes and similar filter suggestions can be also added in other three sections of the app as well.

Due to a rate limit issue on the free-tier provided by AI API providers, I did not deploy it on netlify app link mentioned earlier in the article.

How I Used Algolia Agent Studio

In the Vulnerabilities section, Algolia's Custom Search acts as the high-speed "lookup engine" that connects your project dependencies to the sample data pulled from GitHub Advisory Database. It transforms a simple list of packages into a live security report by handling the complex matching logic behind the scenes. For the sample app, I inserted a few vulnerabilities in Algolia's index, which can be later populated with more comprehensive database entries for in depth vulnerabilities search.

In the error analysis section, I used Algolia's Custom Search Function to intercept every keystroke in the Error Analysis bar. If the input matches a known error pattern, we use Optional Filters to boost troubleshooting guides to the top, ensuring the most helpful 'Fix' is always what the user sees first.

For the Cloud Cost section, I used Algolia to index some sample cloud pricing tiers. I implemented a custom HCL/YAML parser that extracts resource types and regions from pasted snippets. These are then sent as search queries to Algolia, which retrieves the most accurate, region-specific pricing data.

In the stack health advisor section, I used Algolia’s multipleQueries feature to fire off three simultaneous searches every time a user changes their stack. One query checks the security index for framework risks, another hits the pricing index for cost, and the third searches the error base for stability issues. We then aggregate these results into a single, easy-to-read dashboard.

To fit the hackathon category, I used Agent Studio to create proactive filter suggestions:
For example, when a user searches for an error like "401," the Agent doesn't just show the error results; it proactively retrieves additional filters and displays them as the primary filters below the search input.

Why Fast Retrieval Matters

In a developer tool like DevSolve, fast retrieval isn't just a "nice-to-have" feature; it is the core engine that enables a Non-Conversational experience.

1. Maintaining "Flow State"
Developers work in a high-concentration "flow state." Every second spent waiting for a spinner or a slow AI response is a moment where that focus can break and flow state goes away.

Instant Feedback: Algolia provides search results in milliseconds, meaning the moment a developer pastes an error log, the fix is already there.

Zero Latency: Unlike LLMs that "stream" text slowly, fast retrieval allows the UI to update as fast as the users can blink.

2. Enabling "Proactive" Intelligence
For a tool to be proactive, it must be faster than the user's next thought.

Real-Time Auditing: In our Security section, the "Agent" must cross-reference lot of vulnerabilities instantly to flag a risk before the developer moves to the next file.

Dynamic Costing: As seen in your Cloud Costs section, fast retrieval allows the "price tag" to update instantly as soon as the user pastes the IAC snippet, making financial impact immediate and visible.

3. Accuracy Over Hallucination
Fast retrieval allows us to query a Verified Source of Truth (like the GitHub Advisory Database) rather than relying on a generative model's memory.

Precision: Speed allows us to perform multiple "behind-the-scenes" searches simultaneously, checking security, cost, and stability all at once, without slowing down the user interface.

Reliability: When the fix appears instantly from a trusted index, the developer trusts the tool more than an AI assistant that might guess the answer or give incorrect or outdated solutions.

I chose Algolia because, in development, speed is a feature. By reducing retrieval time, DevSolve disappears into the background of the workflow. It doesn't feel like a separate 'search step'; it feels like our code is simply telling us what it needs to be safe and cost-effective.

Conclusion

DevSolve is built on a simple premise: developer tools should be proactive. By focusing on high-speed retrieval over conversation, we’ve created a "Truth Layer" that respects a developer's most valuable asset: their time.

The Algolia Advantage
Using Algolia allowed us to turn complex datasets like the GitHub Advisory Database and Cloud Pricing Lists into instant, actionable insights.

Speed as a Feature: By delivering results in milliseconds, we ensure that security and cost checks happen during the workflow, not after.

Precision over Hallucinations: Because we query a verified index, the "Fixes" provided are always accurate and backed by documentation.

Beyond the Hackathon
While DevSolve solves the "Three Nightmares" of security, costs, and bugs today, the architecture is ready for more. The next steps for this project include:

Multi-Cloud Support: Expanding the pricing index to include Google Cloud and Azure for cross-provider comparisons.

Collaborative Health Reports: Allowing teams to share Stack Health Advisor scores to standardize best practices across an organization.

Thank you for exploring DevSolve. I hope this project inspires you as a reader to build such tools that prioritize the "Source of Truth" and empower developers to build with more confidence and less friction.

That's it from my end for today. See you all in the next article 👋

I Built a 3D Game-Style Interactive Developer Portfolio with Three.js, Gemini & AntiGravity

Saurabh Mhatre — Sun, 25 Jan 2026 12:50:22 +0000

This is a submission for the New Year, New You Portfolio Challenge Presented by Google AI

About Me

Hello, I am Saurabh Mhatre, a Senior Frontend Developer with 10 years of experience in frontend development. For the past few months, I have been focusing on AI-driven frontend engineering, mainly using the Gemini Canvas feature and Google Antigravity.
My goal with this portfolio was to create a 3d interactive digital home that feels alive and closely resembles my daily developer life. I wanted to showcase not just my career achievements but also my developer contributions outside of work and technical content creation, which I do side by side.

Portfolio

This 3d portfolio is created to resemble a game-like experience where the user can roam around the 4 rooms of the house, each covering a part of my personal and professional life.

First is the office where my career and skills are covered
Second is the studio where my GitHub side projects and YouTube channel are added
Third is a hobby room where you can play a 3d interactive game called Debug Hero. In this game, the main goal is to squash bugs using code projectiles and power-ups. You can also find my social media channels which I post tech jokes and AI art for fun.
Fourth is the library, where my Medium blog profile and favourite books are covered.
If you walk towards the backside of the garden, you can play a special "Your Name in Galaxy" game where your name appears among stars and you can move your name with hand movements.
There's also a cute little cat mode to roam around as a cat. Also, night mode shows a spectacular view of the house with indoor lighting.

Video demonstration:-

Link for viewing portfolio:- 3dPortfolio

How I Built It

I first created an image of porfolio using Gemini Nano Banana Pro as shown below:-

Then I created a prompt to generate this portfolio and create an initial prototype using the Gemini canvas feature:-

In this prototype, I implemented main character movement, basic home structure and where all interactive items would be in the house. I also added popups, which open when an interactive item is clicked.

Next, I created 3d animated images of items created using Gemini Nano Banana Pro and uploaded them to Sam3d for converting them into 3d models:-

Finally, I integrated the 3d models into the portfolio using Google AntiGravity and made lots of customisations using Agent mode in the editor.

Also for character walking animated movement, I used Adobe Mixamo with some character editing done in Blender.

Tech Stack and tools used:-

Three.js for real-time 3D rendering
Gemini for AI-assisted workflows using the canvas feature
Meta SAM 3D for turning images into 3D models
Adobe Mixamo for animated character movement
Google Antigravity to orchestrate the full experience
Dockerized and hosted on Google Cloud Run.

What I'm Most Proud Of

All four sections in the portfolio showcase my professional achievements, personal projects and social channels. I also added previously created Debug Hero 3d game access in the same app as well. Also, there is an easter egg to generate your name in the galaxy and interact with it using hand gestures, which you will surely enjoy.

What makes it fun to explore:

Fully animated 3D scenes with smooth interactions
Performance-focused frontend decisions
Creative use of AI and 3D tooling
Interactive moments that reward curiosity, including playful surprises as you roam

This portfolio is a great reminder that standing out doesn’t mean being louder; it means being more intentional and creative with the tools we have.

That's it from my end for today. See you all in the next post 👋

Purpose of @SpringBootApplication Annotation in Spring Boot

Saurabh Mhatre — Thu, 26 Oct 2023 16:09:56 +0000

The @SpringBootApplication annotation is a powerful and fundamental annotation in the Spring Boot framework. It encapsulates several other annotations and serves as the entry point for your Spring Boot application.

What is @SpringBootApplication?

The @SpringBootApplication annotation is a combination of three annotations:

@SpringBootConfiguration: Denoting that this class provides configuration for the application.
@EnableAutoConfiguration: Enabling Spring Boot's auto-configuration mechanism, which automatically configures the application based on the libraries on the classpath.
@ComponentScan: Instructing Spring to scan the specified package (and sub-packages) for annotated components.

Why Use @SpringBootApplication?

This annotation simplifies the setup of a Spring Boot application. By placing it on your main class, you declare it as the starting point of your application. Spring Boot then handles much of the configuration and bootstrapping for you.

Example Usage:

Let's consider a basic Spring Boot application with the @SpringBootApplication annotation:

@SpringBootApplication
public class MyApplication {

    public static void main(String[] args) {
        SpringApplication.run(MyApplication.class, args);
    }
}

In this example, MyApplication is marked with @SpringBootApplication. The main method then uses SpringApplication.run(...) to bootstrap the application.

Benefits:

Simplified Setup: The annotation-driven approach reduces the need for manual configuration, allowing you to focus more on writing application logic.
Auto-Configuration: Spring Boot's auto-configuration feature sets up your application with sensible defaults based on the libraries you have in your classpath.
Component Scanning: The application will automatically scan for annotated components like @Component, @Service, @Repository, etc., making it easy to wire dependencies.
Readability and Maintainability: By using @SpringBootApplication, you clearly indicate the entry point of your application, making it easier for other developers to understand your code.

Conclusion:

The @SpringBootApplication annotation is a cornerstone of Spring Boot development. By using it, you leverage the power of auto-configuration and component scanning, simplifying the setup and development process of your application. This annotation-driven approach encourages best practices and accelerates your development workflow.

Check out my Youtube channel for more content:-
SaurabhNative Youtube

Understanding the POM File in Spring: A Comprehensive Guide

Saurabh Mhatre — Wed, 25 Oct 2023 14:48:22 +0000

1. Introduction to POM File

1.1 What is a POM File?

A POM (Project Object Model) file is an XML file that serves as the fundamental building block of a Maven project. It contains information about the project and configuration details to manage dependencies, plugins, build settings, and more.

1.2 Importance of the POM File

The POM file is pivotal in Maven-based projects for various reasons:

Dependency Management: It defines project dependencies and their versions, ensuring that the required libraries are available during compilation and runtime.
Lifecycle Management: It defines the build lifecycle phases and their associated goals, allowing developers to execute tasks such as compilation, testing, packaging, etc.
Plugin Configuration: It specifies which plugins should be used in the build process and how they should be configured.

2. Structure of a POM File

2.1 Project Information

This section includes details like groupId, artifactId, version, packaging, and name that uniquely identify the project.

2.2 Dependencies

The dependencies section lists the external libraries and frameworks that the project relies on.

2.3 Plugins

The build section includes information about plugins and their configurations. Plugins can perform various tasks like compiling code, generating documentation, or packaging the project.

2.4 Build Settings

This section includes properties like sourceDirectory, testSourceDirectory, and others, which customize the build process.

3. Managing Dependencies with POM

3.1 Dependency Coordinates

Dependencies are defined with coordinates like groupId, artifactId, and version. These coordinates are used by Maven to fetch the required libraries from repositories.

3.2 Transitive Dependencies

Maven automatically resolves dependencies transitively, meaning if a library A depends on library B, Maven will also fetch B.

3.3 Version Management

Using properties for versions allows for centralized version management. This is particularly useful when multiple modules share dependencies.

4. Lifecycle and Build Phases

4.1 Clean Phase

This phase removes files generated by the previous build.

4.2 Default Phase

This phase includes goals like compiling source code, running tests, and packaging the project.

4.3 Site Phase

The site phase generates project documentation, reports, and other resources.

4.4 Deploy Phase

The deploy phase involves copying the final package to a remote repository for sharing.

5. Profiles in POM

5.1 What are Profiles?

Profiles in Maven allow for customizing builds based on different environments or specific requirements.

5.2 Using Profiles for Build Customization

Profiles can be used to define different sets of dependencies, plugins, or build configurations for specific scenarios, such as development, testing, or production.

6. Inheritance and Parent POMs

6.1 Defining Parent POMs

A parent POM is a way to share common configurations across multiple projects. It helps in standardizing settings and dependencies.

6.2 Inheriting from Parent POMs

A project can inherit configurations from a parent POM by specifying the parent's groupId, artifactId, and version.

7. Plugin Configuration in POM

7.1 What are Plugins in Maven?

Plugins are extensions to Maven that provide additional functionality. They can be used for tasks like compiling code, running tests, generating documentation, etc.

7.2 Configuring Plugins in POM

Plugin configurations are specified in the build section of the POM file. This includes details like the plugin's groupId, artifactId, version, and specific settings.

8. Best Practices for Managing POM Files

8.1 Keep Versions Updated

Regularly update dependency versions to benefit from bug fixes, performance improvements, and new features.

8.2 Use Bill of Materials (BOM)

A BOM is a POM file that defines a set of default dependencies and their versions. It helps in managing versions across multiple modules.

8.3 Avoid Dependency Scope Ambiguity

Use appropriate dependency scopes (compile, runtime, etc.) to avoid conflicts and ensure that dependencies are used in the correct context.

9. Conclusion

Understanding and effectively managing the POM file is crucial for successful Maven-based project development. It not only ensures proper dependency management but also streamlines the build process, making development more efficient and maintainable.

Check out my Youtube channel for more content:-
SaurabhNative Youtube Channel

Tech update - Major tech companies catching upto chatGPT’s popularity

Saurabh Mhatre — Thu, 02 Mar 2023 15:26:33 +0000

As OpenAI’s ChatGPT surges in popularity, more companies, including Microsoft, Google,Meta and even Snapchat, are exploring opportunities in the generative AI space.

ChatGPT will now be available to Snapchat users in the form of AI based friend with which users can have daily conversations. Named “My AI,” Snapchat’s chatGPT based bot will be pinned to the app’s chat tab above conversations with friends and will be available only to Snapchat plus subscribers. The idea behind this is that in addition to talking to friends and family every day, users are going to talk to AI every day.
Microsoft is bringing AI powered search experience to taskbar in windows 11. This is first step towards Microsoft’s plans of AI powered windows. The search box is used by over half a billion people on a regular basis.
Meta is now dedicating a team towards building AI powered chat experiences and personas designed to help people in various ways. They are planning to use this tools within each of their apps.

In conclusion, the rise of AI language models and their popularity among major tech companies is a positive development for the field of natural language processing, and it will be exciting to see how these technologies continue to evolve and improve in the future.

Advantages and disadvantages of server side rendering in react.js -Frontend Interview Question

Saurabh Mhatre — Wed, 01 Mar 2023 16:52:11 +0000

Server-side rendering (SSR) in React.js is the process of rendering a web page on the server-side and sending the fully rendered HTML to the client browser. This is in contrast to the traditional client-side rendering (CSR) approach, where the HTML is generated by JavaScript running in the browser.

Server-side rendering (SSR) in React.js has several advantages and disadvantages, which are discussed below:
Advantages of Server-side Rendering in React.js:

Faster Initial Load Time: With server-side rendering, the initial HTML, CSS, and JavaScript files are preloaded on the server and sent to the browser as a complete HTML page, which results in a faster initial load time, especially for slow network connections. This can improve the user experience and reduce the bounce rate.
Improved SEO: Server-side rendering is beneficial for search engine optimization (SEO) as search engines can easily crawl the content of the pages, which can lead to better search engine rankings. SSR generates static HTML pages, which can be easily indexed by search engines, and provide better metadata for search engines to crawl.
Better Accessibility: Server-side rendering provides better accessibility as it ensures that content is available to users who might not have JavaScript enabled or are using a screen reader.
Improved Performance: Server-side rendering can improve the performance of your application as it reduces the time taken to download, parse and execute JavaScript files in the browser. This can lead to faster page loads and better user experience.

Disadvantages of Server-side Rendering in React.js:

Increased server load: Server-side rendering can increase the load on the server as the server needs to generate HTML pages for every request. This can result in increased server costs and decreased performance, especially for high-traffic websites.
More complex setup: Setting up server-side rendering can be more complex compared to client-side rendering as it requires additional infrastructure and configuration.
Delayed Interactivity: Server-side rendering can delay interactivity as the client-side JavaScript must be downloaded and parsed before user interaction can take place. This can result in a slower user experience, especially for complex applications.
Increased bandwidth usage: Server-side rendering can increase the amount of data transferred over the network, as the server needs to send the complete HTML, CSS, and JavaScript files to the browser. This can result in increased bandwidth usage, which can be a problem for users with limited data plans or slow internet connections.

Concepts explained in video tutorial:

In summary, server-side rendering in React.js has several advantages, such as faster initial load time, improved SEO, and better accessibility, but it also has some disadvantages, such as increased server load, more complex setup, delayed interactivity, and increased bandwidth usage. The choice to use server-side rendering or not depends on the specific needs and requirements of your application.

Bringing back informal communication in remote work

Saurabh Mhatre — Sun, 30 Jan 2022 12:43:01 +0000

Overview

Hell everyone,

Since the past few years, most of the software engineers and engineering teams across the world have started working from home and are slowly adjusting to remote working culture. Remote engineering has brought in its own set of advantages and challenges as well. Even companies across the world are trying to adapt to these new changes.
One thing which we all surely might miss is having casual conversations with colleagues, discussing random side-project ideas with them or hobbies and even favourite web series/movies we watched last weekend.

I recently came across an interesting article about informal communication in a remote environment from Gitlab's remote working handbook which is a massive 2000+ pages resource for learning about good remote working practices. Shared below are a few key points that I personally found interesting from the article:

1. Reasons for having informal communication at the workplace

Remote workers who are all-work all the time can risk facing burnout or loneliness. One of the best ways to combat loneliness and burnout is through relationship-building by prioritizing regular social interactions via informal communication throughout the workday, week, and month.
Informal communication is important, as it enables friendships to form at work related to matters other than work. Those who feel they have genuine friends at work are more likely to enjoy their job, perform at a high level, feel invested in the company, and serve others within the organization.

For all-remote companies, leaders should not expect informal communication to happen naturally. There are no hallways for team members to cross paths in, no carpools to the office, etc.

At the same time we should also keep in mind that while some people thrive on spending time to get to know others, others are annoyed by non-work-related texts and messages. Informal communication among diverse team members requires a high level of empathy.

It's helpful to be transparent and considerate about communication preferences from the employee's end so that managers and teammates can know and respect everyone's boundaries.

2. Ways to foster informal communication in a remote environment

Below are a few of the ways we can create to foster informal communication referenced from Gitlab's handbook. All-remote companies and employees can iterate on these and implement them as desired.

Social call: A series of optional calls once a month on a Tuesday, to which everyone in the organization is invited. Have no set agenda, but items can be added to the linked document. This is just a time set aside for everyone to talk openly and where everyone is a moderator.
Contribute Unconference: An in-person, annual week-long event where we can bring the entire company together in one location to get to know each other better.
Group conversations: Few times a week the company can get together virtually to discuss an area of the business. Slides can be provided for context but not presented.
Coffee chats: Working remotely leads to mostly work-related conversations with fellow team members, so everyone at all remote companies can be encouraged to dedicate a few hours a week to having social calls with anyone in the company.
It's a great chance to get to know who you work with, talk about everyday things and share a coffee, tea, or your favourite beverage. Most of us surely want to make friends and build relationships with the people we work with to create a more comfortable, well-rounded environment.
Coworking calls: These video calls are scheduled working sessions on Zoom where team members can work through challenging tasks with a coworker, or simply hang out while each person works on their own tasks. This recreates a productive working session we might have in-person in a traditional office setting but from the comfort of our own desk.
Social hours: Informal social calls can be organized within immediate teams to get to know each other on a more personal level.
Local meetups: Co-located team members can be encouraged to organize their own meetups, whether it's a coworking space or getting dinner together.
Channels for informal activities: Slack/Discord channels for informal communications can be added throughout the company, whether it's a team-specific channel or a channel dedicated to sharing vacation photos with other team members.

Companies can have a #gaming Slack channel where fans of video games and digital board games can connect. Coordinating shared gaming sessions is a great way to informally connect with team members and collaborate toward goals outside of work.

#music_making channel can be a place where artists can come together and collaborate synchronously or asynchronously to make music together.

Personal Addition: We can even have a #jokes/memes channel where people can share jokes or memes with others.
Zoom calls: Not only do we get to know our coworkers better by seeing them in real-time during video calls, but we also get to know their pets and families too. This visual engagement helps us relate to each other on a more personal level, so when we meet in person, we already know each other.
Collaborative virtual quizzes: A collaborative quiz tool like Kahoot can be used for virtual team-building activities. Employees can split into smaller breakout groups on Zoom to get to know each other and answer the questions. Employers can incorporate some friendly competition by offering a prize for the winners.

3. Leading with empathy

Each work-related call can begin with an earnest, genuine "How are you?", or a similar and appropriate introduction.

It's important to remember that everyone is facing a battle that we know nothing about, and in a remote setting we should actively listen.

The above point is my personal favourite from the handbook 😁

4. Using emojis to convey emotion 😄

Though emojis have commonly been reserved for personal conversations that occur outside of the workplace, all-remote employees can feel comfortable using them in everyday discourse with team members.

Perception has shifted on using emojis in professional settings. In Slack alone, north of 26 million custom emojis has been created since the feature was introduced. In all-remote settings, where you may never meet a colleague in person, leveraging visual tools to convey nuance in tone, emphasis, and emotion can lead to more empathy and a tighter human connection.

5. Celebrations and holidays

A team that is distributed across the globe creates opportunities for many celebrations. Different countries and cultures celebrate in their own way, enabling team members to gain an understanding of key dates and events that matter to colleagues. A culture that encourages a team to thoughtfully express their celebrations on company calls is a healthy, inclusive one.

There are a lot more things to share but I want this article to be just a summary and not the exact replica of the original resource. If you would like to add a few more informal activities which your organisation undertakes, then please add them in the comments so that others can learn about them as well.

That's it from my end for today. See you all in the next article.

Improving your Github repos presentation using projects feature

Saurabh Mhatre — Sat, 29 Jan 2022 04:03:43 +0000

So today we are going to understand how to use the projects tab on Github for improving the presentation of your GitHub repos. Now one of the problems which it solved for me is lying in front of you. When publishing a full-stack project on Github, we usually create multiple repos for different purposes.

For example, in the below case, a video game sales prediction project, which contained a front end repo written in React.js, the backend repo written in Python flask and the ML notebook repo written in Python again, and I wanted to club these three repos together.

If we come to the projects section, here you can see that we have the same project presented in a different manner in which we have the three repos linked and we have a general description.

So when you are like explaining your code in front of an interviewer or showcasing your projects to someone, this tab might be a better way to showcase your projects, because you can have a basic title than a description and details about the project.

More importantly, if you click on the project inside, then you can showcase some resources related to the project.
In this case, I have added the technical stack used to create the project, the links to each individual repo and the article written after finishing the project in different tabs. Now you can customise this as per your requirements as well.

Let’s deep dive into the process of creation of this project next.
First, in the repos tab, filter out the repos that you need for creating the project. Once done we can start off with the project creation part.

Go to the projects tab on your GitHub profile and click on new project as shown below:-

Then add a title, description and repositories you want to link for a project in the next step:-

Before proceeding ahead, keep in mind that the projects section is built mainly for task management. But this is an alternative way, in which I thought of using this section since the columns can be renamed and after we are done with the project, the task management section becomes redundant to use.

You can then add cards and column names within the project as per your requirements:-

Once done, change the project privacy settings from private to public to showcase your project with the rest of the world.

You can also go through this process visually by going through the video tutorial shared below:-

That's it from my end for today. See you all in the next article 👋

Visualising the simplest Math problem no one can solve using React.js

Saurabh Mhatre — Sun, 19 Sep 2021 08:03:08 +0000

Hello, amazing reader,

Hope you are doing fine in your life. I wanted to share some interesting insights I had after watching the 3x+1 problem on Veritasium last week:-

Series Explanation

The rules of the series are as follows:-

Start with any positive integer n.
Then each term is obtained from the previous term as follows:
- If the previous term is even, the next term is one half of the previous term.
- If the previous term is odd, the next term is 3 times the previous term plus 1.
  - The conjecture is that, no matter what value of n, the sequence will always reach 1.

Although the explanation is surprisingly easy to follow from the Youtube video above, no one has been able to prove the series yet.

Visualisation using react.js

The problem in itself is really interesting to watch, but I personally found the practical examples and visualisations used in explaining the problem quite fascinating.

Therefore I wanted to see if I can replicate a few of the visualisations of the series which is popularly known as collatz conjecture using react.js this week. I was successful in building a basic graph of the first 10 numbers in the series as shown below:

You can directly check out the code for this graph here on Codesandbox:-
3x+1 in React.js

There is a utility function in the code to generate the series for a particular number:-

export default function generateSeries(x) {
  const series = [x];
  let n = x;
  while (n !== 1) {
    if (n % 2 === 0) {
      n = n / 2;
    } else {
      n = 3 * n + 1;
    }
    series.push(n);
  }
  return series;
}

We then use this function in seriesGeneration component to create series for the first 10 numbers. The numbers are then visualised using recharts library.

I am planning to build a few more visualisations on the same number series, so stay tuned for upcoming articles.

Connect with me on:
Twitter

10 useful sections to improve your Github README files

Saurabh Mhatre — Thu, 16 Sep 2021 15:41:16 +0000

Hello everyone

Today we are going to cover a list of 10 important sections you can add to your GitHub projects for improving your README files.

So let's begin...

Section 1: Add title, description and socialify image(optional)

The title and description for a Github project can provide the user with basic information about the project.
Additionally, we can create a project info image using socialify service to improve project presentation.

Example:-

Socialify helps you showcase your project to the world by generating a beautiful project image that can be used in Github README

Section 2: Add shields io badges

Shields.io is a service for creating legible badges in SVG format, which can easily be included in GitHub readmes or any other web page.
This will help to provide project information in a condensed manner:-

Section 3: Project Demo

Project demo URL helps the viewer to see live projects easily. We can also use this to show live previews to prospective interviewers quickly during interviews.

Example:-

Section 4: Project Screenshots

Project screenshots help users to see the product even before opening the live demo link. For frontend/full-stack projects this is a must-have section.

Example:-

Section 5: Features

Features section can be used to list down all the advantages end users will have while using our project as well as some technical plus points for dev interviews.

Example:-

Section 6: Installation Steps

If someone wants to use our project for their own software development purposes, then installation instructions can help them in setting up the project correctly.

Example:-

Section 7: Contribution Guidelines(Optional)

If someone wants to contribute to our project in some way via pull requests or feature recommendations they will first go through contribution guidelines listed in the project.

Example:-

Section 8: Technologies used(Optional)

In this section, we can list down technologies or modules which we used while building the project to help others understand the creation components in a better manner.

Example:-

Section 9: License Information(Optional)

Here we can provide information about the licenses used in the project for others to know the usage guidelines.

Example:-

Section 10: Enter Support Information(Optional)

Here we can add links for asking people to star the project or support our efforts via donations.
Example:-

You can a sample repo with all this sections added here:- Stories Feed Github

Also I have recently created a tool which you all can use to add this sections easily in your Github README files using form based input:-

Project Demo:- README Gen
Github Source Code:- README Gen Github

Hope this article was helpful to you all. Follow me for more such articles in future.

Learnings from daily dev job - Part 1

Saurabh Mhatre — Thu, 05 Aug 2021 09:08:24 +0000

Hello everyone, so today I'm starting a new series in which I'm going to share a few programming tips which I learn from my day to day job on my own and with my colleagues. So let's begin with the first tip...

Which side to choose when a bug can be fixed from both backend and frontend?

When a bug can be fixed from let's say backend as well as the front end side then which side should we choose from?

The first thing which we can consider in this case is whether our application is cross-platform and whether a back end fix will fix the bug both on the website as well as a mobile application. In that case, it makes sense to fix the bug from the backend.

The other scenario is when the bug is specific to a single platform like let's say web or mobile and backend fix might not fix it for both platforms at once. In that case, it makes sense for the frontend developers to take initiative to fix the bug from his/her own side instead of waiting for the backend developer to take the initiative and fix it from their end.
If it is not fixable from our own end at all or if it is easier to fix it from the other end then picking up the other side for a bug fix makes sense.

Smaller PRs makes life easier for reviewers as well as future project maintainers

Let's just say you have a big feature in which you need to make a lot of changes in your code. In that case my advice is to break that feature into smaller modules and create pull request in smaller chunks, because the thing that happens is, if your commit is huge with lots of files into your committed code for a particular pull request, then the person who is going to review your pull request might feel like it's a headache for him/her to review all those file changes at once.
That is why it is advisable to break down your changes into smaller modules and create smaller PRs. Then send them to your reviewer, so that he or she is able to review them properly and tell you where the actual issues or corrections might be required.

There is a popular saying he goes by if your PR is 500 lines of code there won't be any single review comment and if you have committed just 10 lines of code, you might have 5 to 10 corrections in that.

That's actually true because larger files or code changes, tend to get ignored and smaller ones are easy to review. So my tip for the day is to make sure to divide your entire module of code changes into smaller chunks and get smaller PRs reviewed daily so that the code reviewers don't have to review through a large quantity of code at once missing useful fixes and bugs. It is generally good practice for us to create smaller PRs also because future maintainers of the project are able to see changelog or history easily and make sense of what happened in the project when a particular pull request was merged into the project. I have personally made the mistake of committing huge chunks of code in a single PR a lot of times in the past. But currently, I try my best to make sure there are not a lot of code changes in a single PR for review.

That's it from for this article. If you found this article useful hit the like button and follow me to learn more about such small but useful tips in future. Also if you have any different opinions on the topic than my own then feel free to share them in the comments. I am not a subject expert in these things and would love to learn from your opinions, perspectives or points as well.

Have a nice day ahead 👋🏽