DEV Community: Aabhas Sao

Google I/O 2026: AI Built an OS in 12 Hours. I Spent Mine Sorting Screenshots. 🤦

Aabhas Sao — Sun, 24 May 2026 21:18:41 +0000

This is a submission for the Google I/O Writing Challenge

I haven't watched a tech keynote in a really long time. They usually feel like 2 hours of "the future is here!" slides with product demos that never work on stage.

But Google I/O 2026 actually got me. Watched the whole thing and came away genuinely excited and slightly stressed about how fast things are moving.

They Built a Full OS in 12 Hours

Google's team built a full blown OS using Gemini agents. 93 sub-agents, 15K model requests, 2.6 billion tokens, all under $1,000 in credits. Twelve hours total.

Less than a thousand dollars. For 2.6 billion tokens. That's wild efficiency.

Gemini 2.5 Flash clocks 200 tokens/second output speed. Claude Sonnet sits around 40-60/sec. That gap is huge when you're running 93 agents in parallel and explains why this was even possible in that timeframe.

Gemini Spark Felt Like a MoltBot Alternative

Gemini Spark runs agents in a secure private cloud fully managed by Google. You don't worry about infrastructure, just give it tasks. The closest thing I could think of was MoltBot but living entirely inside Google's ecosystem.

Agentic AI you don't have to host, secure, or manage yourself sounds genuinely appealing. Haven't gotten deep access yet but it's on my list.

Search Is Getting Agentic

For years Google Search has been a box you type into. Now it's a box that talks back, remembers, and proactively reaches out.

They showed concert updates for your city. You can ask Search to notify you when shows for an artist you like get announced. I live in Mumbai and would love to test how well this actually works here because currently I find out about shows after tickets are sold out.

AI autocomplete that doesn't just finish your query but suggests better ones based on intent. Proactive updates that follow up on your interests without you asking again. Search is slowly becoming something closer to a smart assistant.

Yes, Google, take my data, please.

Agents Are Buying Coffee Now

This was the part that felt most science-fiction-turned-real.

Universal Commerce Protocol lets AI agents interact with e-commerce systems. Agent Payments Protocol lets them actually complete payments on your behalf.

The live demo had an agent order coffee through DoorDash, selecting the item, going through checkout, completing payment. No human in the loop at any point.

Picture this: you tell your AI "book me a flight to Bangalore next Friday under ₹8,000, window seat" and it just... does it. Hotels too. Payments too.

Is this a privacy nightmare waiting to happen? Probably worth thinking about. But as a demo, genuinely impressive.

Gemini Live Replied in Haryanvi and I Was Not Ready

Small moment but a meaningful one. During the Gemini Live demo, the model replied in Haryanvi, a regional dialect spoken mostly in Haryana, India. Not just Hindi. Haryanvi. That was cool to see.

Work Onward (Inspiring real Antigravity and Stitch work usage case study)

Holly Jooyoung Diamond built Work Onward using Antigravity and Stitch. The problem she was solving was real: how do restaurant owners post jobs easily?

Job postings via SMS so owners don't need to sit at a laptop filling out forms. Multilingual job descriptions automatically so the listings open up to more candidates immediately.

Really inspiring to see that the access to build ideas is with everyone now.

Small thing but I actually used Gemini myself while writing this article to fetch the specific timestamp of the Work Onward demo from the keynote video because I had forgotten the details after watching. That worked surprisingly well.

WeatherNext Predicted a Category 5 Hurricane 3 Days Out

WeatherNext predicted a Category 5 hurricane in Jamaica three full days before it happened.

3-day advance warnings at category-level accuracy are the kind of thing that saves lives. Not a dev tool but a reminder that the same underlying models powering our autocomplete are doing genuinely important work elsewhere.

Fine-Tuning Gemma 4 with Antigravity

This is the one I keep coming back to.

Google showed fine-tuning Gemma 4 directly from the Antigravity CLI for custom use cases. I haven't worked much with local models yet but the cost of calling a large cloud LLM for every single query adds up fast, especially for repetitive domain-specific tasks.

If you're building a product that does the same type of classification or extraction thousands of times a day, running that against a fine-tuned Gemma locally is far cheaper than hitting a frontier API each time. That's the promise here.

I want to try this. Will write about it when I do.

Playing With the Antigravity CLI

Enough keynote recap. Here's what I actually tried.

Installing it

curl -fsSL https://antigravity.google/cli/install.sh | bash

One thing I hit right away: after installation, typing agy or antigravity opened the Antigravity IDE instead of the CLI. Turned out I had an older IDE version installed and its PATH entry was winning.

Had to manually remove the old PATH entry from ~/.zshrc and re-source it. After that the CLI came up fine. Not sure if it's a bug or just my setup, but if you hit the same thing, check your .zshrc for conflicting PATH entries before assuming something is broken.

Organizing 200+ Screenshots

I had a Desktop full of screenshots going back two years. Totally unorganized, no naming convention, nothing. I thought, let's see what Antigravity does with this.

My prompt was: organize my screenshots, categorize them into folders, and give them meaningful names.

Gemini came back with a solid plan: a Swift OCR tool using macOS's native Vision Framework to extract text from each screenshot, paired with a Python script that classifies them into folders (Coding, Meetings, AI-Assistants, Communication, Finance, Design, Media, General) and renames them with date and keyword info like 2024-12-15_Brave_GitHub_GoogleMeet.png.

Using macOS's native Vision Framework instead of a third-party OCR library was a smart call, zero extra dependencies.

I gave the green flag and it started running. Midway through the dry run I got impatient and used the /btw command to check progress without interrupting the session. That's a genuinely useful feature, like tapping someone on the shoulder to ask "hey how far along are you" without stopping their work.

Files got organized in the end but honestly OCR alone isn't enough context to make great categorization decisions. A screenshot of a GitHub PR and a screenshot of VS Code might have similar text but very different purposes. Some files ended up in slightly wrong folders.

Not the model's fault, it's a genuinely hard problem. But it got me thinking: if the agent could actually see the screenshot using vision instead of just reading extracted text, the categories would be way more accurate.

Modern Web Guidance Plugin

agy plugin install https://github.com/GoogleChrome/modern-web-guidance

This gives Antigravity context about modern web best practices, similar to what the Chrome Modern Web Guidance docs cover for Claude Code.

Using the CLI feels noticeably faster than AI-powered IDEs. No Electron overhead, no waiting for a UI to re-render. Just your terminal, the model, and results.

Every time I use a native CLI tool I wonder why Teams and VS Code are built on Electron. I get the history. Still.

I tried redesigning a section of my portfolio to add a tech stack display with icons. Gave it a screenshot reference and it couldn't nail the visual. Gave it a full URL to a reference site and the result was still not great honestly. Not sure if my prompts were bad or if this is just a CLI vs IDE thing, because the IDE felt like it gave better results. I don't know, need to experiment more.

Gemini Omni and SynthID

Almost forgot: Gemini Omni now has an evolved sense of physics for generating stylized videos. Generated video that actually behaves like it understands how things move and interact.

Also SynthID and C2PA credentials for detecting AI-generated content. As generated media gets better, tooling to authenticate what's real becomes critical infrastructure. Good to see it being built in at the platform level.

Final Thoughts

Google I/O 2026 didn't feel like a hype keynote. It felt like a company that had spent a year quietly building and was now ready to show it.

Fine-tuning Gemma 4 is the thing I most want to play with.

The agents-everywhere story is clearly where things are heading. The question is whether the underlying protocols stay open enough that indie devs can build on top of them. Hoping they do.

What was your favourite part of Google I/O 2026? Let me know in the comments, especially if you've played with Antigravity or Gemini Spark!

SOLID Principles Explained in a Solid Way

Aabhas Sao — Fri, 15 May 2026 09:27:02 +0000

Hello friend,

If you have read hundreds of articles and even watched a lot of videos but still confused about SOLID. Help me help you. You are in safe hands.

What are SOLID principles

SOLID principles help write maintainable, testable code. These principles were initially pointed out by Robert C. Martin a.k.a. "Uncle Bob". If you have not watched his lectures, I would highly suggest to go on YouTube and watch, those are pure fun and knowledge.

Now let's go over each of these principles. I will try to write examples that are more real in terms of software usage (no more Bike extending Vehicle class, no offense to anyone 😊).

Single Responsibility Principle

"A class should have one, and only one, reason to change."

❌ Bad Example: The "Do-It-All" Controller

This Spring controller handles HTTP routing, manual SQL execution, external API payments, and email alerts. If your database schema or your email provider changes, this class breaks.

@RestController
public class OrderController {
    @PostMapping("/orders")
    public ResponseEntity<String> createOrder(@RequestBody OrderRequest request) {
        // 1. Validation
        if (request.getItems().isEmpty()) return ResponseEntity.badRequest().body("No items");

        // 2. Direct Database Connection & SQL
        Connection conn = DriverManager.getConnection("jdbc:mysql://localhost/db");

        // 3. Third-party Payment API HTTP call
        HttpClient.newHttpClient().send(paymentRequest, HttpResponse.BodyHandlers.ofString());

        // 4. Email Notification
        Transport.send(emailMessage);

        return ResponseEntity.ok("Order Processed");
    }
}

✅ Good Example: Layered Architecture

@RestController
public class OrderController {
    @Autowired private OrderService orderService;

    @PostMapping("/orders")
    public ResponseEntity<Order> createOrder(@RequestBody OrderRequest request) {
        return ResponseEntity.ok(orderService.processOrder(request));
    }
}

@Service
public class OrderService {
    @Autowired private PaymentProcessor paymentProcessor;
    @Autowired private OrderRepository orderRepository;
    @Autowired private NotificationService notificationService;

    @Transactional
    public Order processOrder(OrderRequest request) {
        paymentProcessor.charge(request.getAmount());
        Order order = orderRepository.save(Order.from(request));
        notificationService.sendConfirmation(order);
        return order;
    }
}

Now the controller handles response handling, business logic is offloaded to service class. Even in service class the database configuration is delegated to repository classes.

Open/Closed Principle

"Software entities should be open for extension, but closed for modification."

❌ Bad Example: The Infinite If-Else
Every time your security team introduces a new auth method (like OAuth or WebAuthn), you have to modify this core security filter, risking breaking changes to existing auth flows.

@Component
public class AuthenticationFilter extends OncePerRequestFilter {
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response) {
        String authType = request.getHeader("X-Auth-Type");

        if ("JWT".equals(authType)) {
            // Complex JWT Validation logic...
        } else if ("API_KEY".equals(authType)) {
            // Complex Database API Key validation...
        } else if ("BASIC".equals(authType)) {
            // Basic Auth logic...
        }
    }
}

✅ Good Example: The Strategy Pattern
By abstracting authentication into a strategy interface, Spring automatically injects all implementations. Adding a new auth method means writing a new class, completely leaving the filter untouched.

public interface AuthStrategy {
    boolean supports(HttpServletRequest request);
    Authentication authenticate(HttpServletRequest request);
}

@Component
public class AuthenticationFilter extends OncePerRequestFilter {
    @Autowired private List<AuthStrategy> strategies; // Automatically injected by Spring

    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response) {
        strategies.stream()
            .filter(s -> s.supports(request))
            .findFirst()
            .ifPresent(s -> SecurityContextHolder.getContext().setAuthentication(s.authenticate(request)));
    }
}

// To add OAuth, just create this class. The Filter remains untouched!
@Component
public class OAuthStrategy implements AuthStrategy { ... }

Spring automatically injects all AuthStrategy beans into the filter. Add a new auth method? Just create a new @Component that implements the interface. The filter never changes!

Liskov Substitution Principle

"Subclasses must be substitutable for their superclasses without breaking the application."

❌ Bad Example: Shoving Incompatible Behavior into a Subclass

ReadOnlyStorage inherits from FileStorage but throws unexpected runtime crashes when a consumer tries to use a perfectly valid parent method (write).

public class FileStorage {
    public byte[] read(String path) { return Files.readAllBytes(Paths.get(path)); }
    public void write(String path, byte[] data) { Files.write(Paths.get(path), data); }
}

public class ReadOnlyStorage extends FileStorage {
    @Override
    public void write(String path, byte[] data) {
        // ⚠️ CRASH! Violates LSP because it breaks the expected behavior of the base class
        throw new UnsupportedOperationException("Cannot write to a read-only bucket!"); 
    }
}

✅ Good Example: Splitting Contracts

Segregate capabilities into a clear hierarchy so that the type system prevents consumers from attempting invalid actions.

public interface ReadableStorage {
    byte[] read(String path);
}

public interface WritableStorage extends ReadableStorage {
    void write(String path, byte[] data);
}

// Implements both read and write
public class S3Storage implements WritableStorage { ... }

// Only implements read, perfectly honoring its type contract
public class ReadOnlyBackupStorage implements ReadableStorage { ... }

Now ReadOnlyStorage doesn't pretend to be something it's not. The type system prevents misuse.

Interface Segregation Principle

"Clients should not be forced to depend on interfaces they don't use."

❌ Bad Example: Fat interface:

A read-only public document viewer widget is forced to provide empty implementations or throw boilerplate exceptions for admin features it shouldn't even know exist.

public interface DocumentService {
    Document getDoc(String id);
    void deleteDoc(String id);
    byte[] exportToPdf(String id);
    List<AuditLog> getAuditTrail(String id);
}

public class PublicDocumentViewer implements DocumentService {
    @Override
    public Document getDoc(String id) { return database.find(id); }

    // Forced to implement methods it doesn't need just to compile
    @Override public void deleteDoc(String id) { throw new UnsupportedOperationException(); }
    @Override public byte[] exportToPdf(String id) { throw new UnsupportedOperationException(); }
    @Override public List<AuditLog> getAuditTrail(String id) { return Collections.emptyList(); }
}

✅ Good Example: Role-Based Micro-Interfaces

Break the large interface into focused capabilities. Clients can pick and choose only what they actually require.

public interface DocumentReader { Document getDoc(String id); }
public interface DocumentExporter { byte[] exportToPdf(String id); }
public interface DocumentAuditor  { List<AuditLog> getAuditTrail(String id); }

// The viewer widget remains simple, clean, and safe
public class PublicDocumentViewer implements DocumentReader {
    @Override
    public Document getDoc(String id) { return database.find(id); }
}

// The admin panel implements multiple interfaces as needed
public class AdminDocumentManager implements DocumentReader, DocumentExporter, DocumentAuditor {
    // Implements all required methods cleanly
}

Each class now depends only on the interfaces it actually uses!

Dependency Inversion Principle

"Depend on abstractions, not concretions."

❌ Bad Example: Hardcoded Concrete Implementations

The high-level NotificationService is tightly coupled to a concrete TwilioSmsClient. If you want to switch to AWS SNS or mock the SMS client for local unit testing, you are forced to rewrite this core service class.

import com.yourcompany.clients.TwilioSmsClient; // Concrete import

public class NotificationService {
    private TwilioSmsClient smsClient = new TwilioSmsClient(); // Hardcoded dependency

    public void sendAlert(String userId, String message) {
        smsClient.send(userId, message);
    }
}

✅ Good Example: Injecting Abstractions

NotificationService depends entirely on an interface. It does not know or care who is sending the message under the hood, making it decoupled and testable.

public interface MessageSender {
    void send(String target, String body);
}

@Service
public class NotificationService {
    private final MessageSender messageSender;

    // Spring injects the interface bean automatically via the constructor
    public NotificationService(MessageSender messageSender) {
        this.messageSender = messageSender;
    }

    public void sendAlert(String userId, String message) {
        messageSender.send(userId, message);
    }
}

// The concrete implementation Spring will inject
@Component
public class TwilioSender implements MessageSender {
    @Override
    public void send(String target, String body) {
        twilioClient.messages.create(target, body);
    }
}

// Swapping to SNS later? Just create this — NotificationService is untouched
@Component
public class AwsSnsSender implements MessageSender {
    @Override
    public void send(String target, String body) {
        snsClient.publish(target, body);
    }
}

Now NotificationService doesn't know or care about concrete implementations. You can:

Add new channels without modifying NotificationService
Mock channels easily for testing
Swap implementations at runtime
Configure channels via dependency injection

Key Takeaways

Principle	In one line
Single Responsibility	One class, one job
Open/Closed	Add new features without disrupting old ones
Liskov Substitution	Subclasses should work anywhere the parent class works. Don't break contracts
Interface Segregation	Many small, focused interfaces beat one large interface
Dependency Inversion	Depend on interfaces, not concrete classes. Use dependency injection

Why SOLID Matters

Following SOLID principles leads to:

Testable code: Easy to mock dependencies
Maintainable code: Changes are localized
Flexible code: Easy to extend without breaking existing functionality
Readable code: Clear responsibilities and dependencies

SideNote

All these rules are like trade offs. In software engineering rules are not strict but more dependent on specific trade offs for the task at hand.

E.g. Adding interfaces that have only single implementations, just for flexibility in future, I can skip it if I'm sure I won't be adding new implementations in near future. Premature optimization is evil.

Remember: SOLID isn't about being dogmatic. It's about writing code that's easier to change when requirements inevitably evolve. Start applying these principles gradually, and you'll see the benefits compound over time.

Happy coding! 🚀

Stop Writing ../../../../../../ in Your Imports

Aabhas Sao — Thu, 12 Mar 2026 05:37:50 +0000

Something clicked for me recently when I was staring at this line in my codebase:

import Button from "../../../../../../components/Button.tsx"

Six levels deep. And honestly, what does that even tell you? You have to mentally trace backwards from wherever you currently are just to figure out where that file lives. The path is relative to this file, which means it looks different in every single file that imports the same component.

There is a cleaner way.

import Button from "@/components/Button.tsx"

Same component. But now the path is absolute, it reads clearly, and it looks identical no matter which file you paste it into. You immediately know where to find it in the project. No counting ../ hops.

Setting It Up

It takes about five minutes. In your tsconfig.json:

{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@/*": ["src/*"]
    }
  }
}

If you are using Vite:

// vite.config.ts
import { defineConfig } from "vite"
import path from "path"

export default defineConfig({
  resolve: {
    alias: {
      "@": path.resolve(__dirname, "src"),
    },
  },
})

Webpack has its own resolve.alias config, same idea.

The VSCode Thing

By default, VSCode still suggests relative imports even after you set up aliases. To fix that, add this to your settings:

"typescript.preferences.importModuleSpecifier": "non-relative"

After that, auto import suggestions will use @/ paths instead of ../ chains.

When Are Relative Imports Actually Fine?

Honestly, for files that are right next to each other. If you have utils.ts sitting right beside index.ts, doing import { helper } from "./utils" is totally fine. The problem starts when you cross multiple folders.

The rule I follow: if the import needs more than one ../, reach for the alias.

The One Upside of Relative Imports

Zero setup. They work out of the box in every project. That is their only real advantage, and it stops mattering the moment a project grows past a handful of files.

Most serious projects configure path aliases from day one now. If your current project does not have it set up, it is worth the five minutes. Future you, three months from now, deep in a nested feature folder, will appreciate it.

No JavaScript, it's a no. Quite funny how when I used JavaScript extensively. I used to hate Java's quirks, and today I'm picking on JavaScript.

Now off you go, clean up the imports.

Creating Nested Routes in Gin

Aabhas Sao — Mon, 23 Jun 2025 15:59:44 +0000

Do you place all your application API endpoints in main.go file. I'm pretty sure the main file has become messy with all those handler imports and endpoints at one place. Imagine getting to a situation like below and simple act of refactoring routes coming to rescue.

I have loved the idea of structuring the project based on features instead of layer based structure. Below two code snippets show comparison of feature based and layer based structure.

The benefit of feature based structure lies in the fact that we are trying to divide our project based on logical boundaries which can be independent modules/actors interacting with each other.

feature_first/
├── main.go
├── pizzas/
│   ├── handler.go
│   ├── service.go
│   ├── repository.go
│   └── model.go
├── noodles/
│   ├── handler.go
│   ├── service.go
│   ├── repository.go
│   └── model.go
└── utils/
    └── logger.go

layer_first/
├── main.go
├── handlers/
│   ├── pizzas.go
│   └── noodles.go
├── services/
│   ├── pizzas.go
│   └── noodles.go
├── repositories/
│   ├── pizzas.go
│   └── noodles.go
├── models/
│   ├── pizzas.go
│   └── noodles.go
└── utils/
    └── logger.go

Let's see how we can structure our routes so that we easily bake them into our feature-based project structure.

Create a sample project in a folder and initialize a go project using below command.

go mod init nested-routing

Let's install dependencies for gin using

go get -u github.com/gin-gonic/gin

Below is a sample main.go code running a simple server and on hitting localhost:8080/ping you will get pong as a message.

package main

import (
    "net/http"

    "github.com/gin-gonic/gin"
)

func main() {
    r := gin.Default()
    r.GET("/ping", func(c *gin.Context) {
        c.JSON(http.StatusOK, gin.H{"message": "pong"})
    })

    r.Run()
}

Modularizing Routes on Basis of features

Now let's create a router component in router/router.go which will register routes for all our nested routes.

package router

import (
    "nested-routing/noodles"
    "nested-routing/pizzas"

    "github.com/gin-gonic/gin"
)

func SetupRoutes(r *gin.Engine) {
    api := r.Group("/api/v1")

    pizzasGroup := api.Group("/pizzas")
    noddlesGroup := api.Group("/noodles")

    pizzas.SetupRoutes(pizzasGroup)
    noodles.SetupRoutes(noddlesGroup)
}

We can now place all the routes related to noodles in the noodles package noodles/handler.go.

package noodles

import (
    "net/http"

    "github.com/gin-gonic/gin"
)

func SetupRoutes(r *gin.RouterGroup) {
    r.GET("/", func(c *gin.Context) {
        c.JSON(http.StatusOK, gin.H{"message": "noodles"})
    })
}

below is pizza/handler.go.

package pizzas

import (
    "net/http"

    "github.com/gin-gonic/gin"
)

func SetupRoutes(r *gin.RouterGroup) {
    r.GET("/", func(c *gin.Context) {
        c.JSON(http.StatusOK, gin.H{"message": "pizzas"})
    })
}

Ping http://localhost:8080/api/v1/noodles to get a json response with message as noodles. Yay!, we have successfully nested our routes.

I would love to hear how you create routes in your projects. I love the little blue demon (go 🙈) and will be sharing interesting ideas and learnings regarding golang. Follow me on Dev, if you would like to join this ship to go for an adventure (pun intended).

Thank you for your time.

My Journey to Appreciating Java in 2025

Aabhas Sao — Sun, 09 Feb 2025 12:22:02 +0000

I always dreaded Java. I started my journey with JavaScript and was using it for backend with Node.js. I loved simplicity and versatility of javascript to use it to build anything from frontend, backend, ML, to crypto projects. Yet, despite Java's popularity, running on billions of devices from mobile phones to POS systems, I couldn’t bring myself to like it. Let me share my personal journey to liking Java and why my perception changed over time.

When eyes meet with Java

Remember the time before Android or iOS became popular? The early touch screen phones used to come with games with Java jar files. I have fond memories of playing so many games and they had size of under 1 MB only!

I started learning HTML, CSS, JavaScript to build website and then later learned Node.js. Why switch when you can build backend with JavaScript.

Occasionally, I tried exploring Java but avoided diving deeper. Writing System.out.println("Hello World") just to print a single line felt unnecessarily verbose. On top of that, there was widespread negativity toward Java from YouTube content creators. People were constantly talking about Rust, Go, Ruby on Rails, and Zig, leaving Java to feel like an outdated relic.

We Meet Again

During my first job, our backend application is written in Java. So I had no other option but to learn it.

Debugging Frustrations: Now the first pain point for me was the fact that to make any changes I had to compile the class file and replace it in an .ear file and restart Tomcat server, the whole process would take about 5 mins. It was frustrating. In NodeJS I just had to use nodemon to get the changes reflected.

Understanding OOP code: Getting used to read OOP (Object Oriented Programming) based code was new to me. It got confusing sometimes, classes extending, implementing and what not.

The Perception of Obsolescence: My overall perception was that no one is starting new projects in Java in 2024. The most of the resources I find online are pretty outdated, they might be relevant but in JavaScript, you'll always find the most fresh content out there.

Living with the Pain

The pain of Debugging

If you aren't familiar above is a sample image of how stack trace in Java looks like. Initially it was really scary to search in the log file of 50K lines and seeing a lot of caused by chains. The above image paints a nice picture of how debugging in Java can be sometimes. but with time I realised that the useful message is in the bottom most caused by chain mostly.

But sometimes the root cause might be wildly unrelated to the error thrown but this is not something specific to Java, I have faced issues like this javascript as well.
I learned patience and to analyse problems deeply before taking any action to avoid the tedious process of compiling class files and replacing them in the ear archives deployed on Tomcat.

Java has Evolved but has your organisation?

One major feature of Java is its excellent backward compatibility. While this ensures stability, it also means that organizations tend to avoid updating older systems. For instance:

Using XML-based configurations for Spring Beans.
Relying on Enterprise Java Beans (EJBs).
Employing Ant for complex build processes.

These older practices can make development unnecessarily complex. Modern tools like Spring Boot and Gradle are far more developer-friendly, yet many companies stick to the old ways. 🥲

Discovering Spring Boot & Lombok: Java has evolved a lot and modern Java helped me resolve some of the frustrating developer experience that I had. When using Spring Boot I no longer have to change class files inside a war file but the changes get reflected quickly as it uses an embedded tomcat server. Using Lombok annotations I no longer have define getter, setters, and a lot of things get shorter.

Final Thoughts

I have just started my journey and learning more about Java, Spring. Please let me know what are your thoughts on Java, whether you haven't started yet, want to or are a veteran.

But regardless, Java you're a pookie don't let anyone tell you, you're boring, old fashioned, tedious. You're reliable, and understanding you takes time but it's worth it 💖

Kubernetes Bedtime Stories

Aabhas Sao — Wed, 11 Jan 2023 18:11:24 +0000

Once upon a time there was a web app name App. App loved kids and to serve stories and videos to them was App's calling.

Once a dev named Bart did some changes to code but for another dev Joe things broke due to the changes. When Bart was asked about the issue he said that the code works on his machine. Paul and Andrew started fighting over this issue and then App stepped in.

App: I have to do something about this. What should I don't know whose fault is this but this trouble with people having different local environments is bringing flakiness.

App is very tensed and wants to relieve this burden of environment dependency from life. Who will help him.

Enter Docker.

Docker: Hey App I can help you. I know how it feels when stuff runs on one machine and does not work on another.

App: Thanks Docker now I feel good. I get updated quickly due to issues related to environment dependency have reduced. Even I have become easier to deploy. Come to my home I'll treat you with cookies. Bring linux and Go as well.

Usually the traffic for App was 100,000 concurrent users but kids found about the coolness of App and concurrent users started growing to 1 million+. The codebase started to get real complex and the developers started to face difficulty working on features.

One day a dev Paul was working on the Authentication system but Joe had made some changes in the Accounts system and the whole thing broke. Several such instances started taking place. Adding new feature was getting difficult without breaking things.

App: Hey Docker what should I do there are millions of kids sending me requests. We are not able to scale and our team is not able to co-ordinate well given the complexity of codebase. I feel bad if I will not be able to help them. How will they sleep at night without hearing lullabies and how will their moms' make them to eat without the videos.

Amidst this chaos a brilliant idea came to Docker's mind.

Docker: App don't worry let's contact Alice. She might be back from vacation in Hawaii.

With the suggestion of Docker, App contacted Alice who was the CTO of the company and mentioned the ongoing problems.

Alice (The CTO): Ohh, this seems like a serious trouble. Hey, App why don't we try shifting to a micro-services (break down the code base to several different services). Let's say a different service for Authentication, one for Accounts, etc. This would help teams work independently without conflicts. Also we will be having a lot containers, so we need someone very skilled to manage all those.

App: Alice, do you know someone who can do the job of managing containers.

Alice (The CTO): Yes, I just happen to know the right guy.

App: Who

Alice (The CTO): Kubernetes 🤩.

Through Alice's referral App called Kubernetes for help.

Enter Kubernetes.

Kubernetes: Hey folks I can help you out. I have some experience being a ship captain and I can sail the ships with containers (docker containers 😂). I can handle scaling of containers, logging, monitoring of containers, handle crashes and automatic failures.

App: How much does it cost the company.

Kubernetes: I believe in open source. My parents (Google) taught me the spirit of open source and the importance of open source community. I take inspiration from open source projects like linux and understand how crucial they are in the software world.

App: Ohh, thats gr8. Hey Kube guy I like you I have a cool nick name for you k8s.

Kubernetes: I love that name. I will gladly take it.

After a lot of effort and collaboration from the developers, Alice, Docker, k8s. App was again able to make the kids happy. Now Kids won't cry as they can watch their favourite videos on App.

Executing Shell Scripts with NodeJS

Aabhas Sao — Tue, 08 Mar 2022 19:29:51 +0000

You might have seen .sh files in many popular GitHub repositories. Even some of you might have used shell file to install node's latest version in Ubuntu. What the hell are those? Let's get started

What is Shell? 🐚

Shell is a command line tool through which you can interact with the kernel. Through shell commands many crucial things can be done like accessing the hardware resource, spawning child processes and many more.

What is NodeJS? ☊

Node is a javascript runtime, usually used to create a backend server. Initially JavaScript could only run on the browser. But the curiosity of one man named Ryan Dahl changed it. JavaScript is slower than statically typed languages. But V8 engine developed by Google improved the javascript performance.

Ways to execute shell scripts 🚴‍♂️

You can run shell script by creating a file with .sh extension. bash, zshrc, and more are modifications on top of shell. Unix like systems have bash shell as default. Windows has command shell and powershell.

Why execute shell scripts in Node? 🤔

Say you need to use a library or tool which is only available as CLI. You don't have any npm module to do that specific task. What you would do now? Don't worry I have a solution for you.

The first time I used it 🐣

In one of the projects I had to access a CLI tool installed on the docker container using Node server. I was using Cura engine a CLI tool installed in my docker container running ubuntu. The basic function of the CLI tool was to convert STL 3d object to G-code. For those of you who don't know what a G-code file is, it is a code which serves as instructions for a 3d printer to print a model. It contains instructions on how to move and how much material to drop, which material to choose etc.
So in my server I was taking a STL file as multipart data and returning a G-code file as response.

Let's try a fun example 🚀

First install Node.js if you don't have it already. Let's create a node project.

Install emoj globally so that we can call it via command line. Create a directory and then change your directory into that. Install nodemon globally as well so we don't have to reload the server manually.

npm i -g emoj nodemon

Initialise the node project with all default parameters.

npm i init -y

Create a server.js file. The main logic of our code will be in this file.

touch server.js

Add an npm script to run the server.

  "scripts": {
    "start": "nodemon server.js"
  }

Now let's create a node server. Add the code below in server.js file.

import express from 'express'
const app = express()

const PORT = 3000;

app.get('/', (req, res) => {
  res.send('hello world!');
});

app.listen(PORT, () => {
  console.log(`server running on port: ${PORT}`);
})

Run the server and try localhost:3000/ in your browser. You will see hello world! if there is no error.

  npm start

Now let's code the most fun part. We will use exec function that node.js provides.

The function of exec is beautifully described in node.js documentation. I would like to quote it here.

Spawns a shell then executes the command within that shell, buffering any generated output.

You can check out the node.js documentation to learn more about exec.

const { exec } = require("child_process");

Add the fun request in server.js before app.listen.

app.get('/fun', async (req, res) => {
  const { commandText } = req.query;
  console.log(req.query)
  await exec(`emoj ${commandText}`, (error, stdout, stderr) => {
    if (error) {
      console.error(`exec error: ${error}`);
      return res.send('some error happened: 😭');
    }

    return res.status(200).send(stdout);
  });
});

Now the final server.js file looks like below.

const express = require('express');
const app = express()
const { exec } = require("child_process");

const PORT = 3000;

// app.use(express.urlencoded());

app.get('/', (req, res) => {
  res.send('hello world!');
});

app.get('/fun', async (req, res) => {
  const { commandText } = req.query;
  console.log(req.query)
  await exec(`emoj ${commandText}`, (error, stdout, stderr) => {
    if (error) {
      console.error(`exec error: ${error}`);
      return res.send('some error happened: 😭');
    }

    return res.status(200).send(stdout);
  });
});

app.listen(PORT, () => {
  console.log(`server running on port: ${PORT}`);
});

To test our fun route send a get request via any tool like Postman or use browser itself. For postman create a parameter named commandText and pass some cool text.

localhost:3000/fun?commandText=winter is coming

Disclaimer

Passing input arguments taken from user directly to exec function can be dangerous. In a way it is similar to how SQL injection happens. Thanks @antongolub for the feedback.
Consider using following libraries to abstract out risks mentioned above.
github.com/google/zx
github.com/shelljs/shelljs

Outro 💚

Congratulations! You just executed shell command from node.js. I hope you found this article useful. Incase you want to connect with me and discuss about anything feel free to connect with me on LinkedIn💕

If you are an organisation and want a freelance tech content engineer feel free to connect with me