Twenty years ago today, I embarked on my very first job straight out of college. Coming from a computer science background, I had a solid understanding of programming and building small-scale software, thanks to various mini and major projects. These included reservation systems and designing and administering my college website—for which I used a telnet terminal and an ERNET FTP server to upload content. However, the technology used in real-world production systems was completely different from what I had practiced.

As an eager 21-year-old arriving in Chennai, it was decided (likely at random) that I would be trained on Oracle Apps and assigned to a project. Since it was a service-based company, these were client-facing projects. Although university had taught me SQL and Oracle databases, I had no idea how to build software with them without a programming language like Java. Following training—which I topped by the narrowest of margins—my work revolved primarily around Oracle Forms, which allowed users to input and save data into an Oracle database, and Reports, which formatted and displayed that data on the screen. All of this was part of Oracle Apps, an Enterprise Resource Planning (ERP) system, similar to SAP.

After nearly a year, I relocated to Hyderabad to join a very small company—what we would call a bootstrapped startup today—focused on financial technology. My role involved downloading stock exchange data using Bloomberg’s C API and storing it in a PostgreSQL database. We built web portals to analyze and present this data, and even performed “what-if” analyses on stock and option data. Much of our prototyping started in Microsoft Excel with VBA scripting before being migrated to a production stack of PHP, Apache, and PostgreSQL on Linux servers. We used PostgreSQL instead of MySQL because it was closer to Oracle, free, and, unlike MySQL at the time, fully supported views.

One of the most interesting aspects of that role was developing stock charts and a custom chat application. Because JavaScript libraries weren’t mature enough yet to build native stock charts like Open-High-Low-Close (OHLC) charts, we adopted Adobe Flex. Flex was a rising technology for building Rich Internet Applications (RIAs), powered by ActionScript (the language behind Adobe Flash) and MXML, a declarative markup language used to define the user interface. Since it was licensed software, we initially explored an open-source alternative called OpenLaszlo, but we eventually abandoned it due to lack of maturity and stuck with Adobe. The beauty of Adobe Flex and Adobe AIR was their ability to compile into standalone desktop executables for Windows and other platforms. Our primary limitation was file I/O, as it was originally built for browsers and could only write to a specific directory called “fscommand”. We also experimented with Visual Basic, which offered better performance and did not require the Flash runtime.

For the chat application, PHP turned out to be our best option. While PHP had a reputation for being fragile, we utilized it in a strongly-typed, object-oriented manner. This was back in 2007, and we drew heavy inspiration from Skype, which we relied on for international voice calls and group chats. We tailored our chat system specifically for the financial domain. Looking back, this startup environment is where I experienced the fastest professional growth of my entire career.

My next move was to a technology giant, which gave me my first look at the culture of a major product organization. The scale was massive, featuring an array of in-house tooling including proprietary email, conferencing, and build systems. It was an exceptional place to work and profoundly shaped my career. I spent over five years there across multiple teams, largely continuing the Oracle application work from my first job—but this time, building it as a vendor. It was a remarkable period; we were delivering rich, browser-based applications where updating data without refreshing the page (partial page rendering) was still a major feat. Although Ajax had been adopted by Gmail three years prior, it had not yet taken hold in the enterprise space. Oracle used a lightweight JRE called JInitiator, which downloaded to the desktop on first access and launched Java applets directly from the browser. While Forms and Reports handled transactional workflows, background tasks were powered by concurrent programs running PL/SQL or shell scripts.

The domain at this point was Supply Chain, where terms like Purchase Order, Sales Order, and Consigned Inventory were predominant. The mobile version of the application ran on handheld devices with a DOS prompt connecting to a telnet server powered by Java. It is worth remembering that the iPhone had not even been born yet.

This was where I met people who went on to build truly remarkable things. In my view, Oracle served as a vital stepping stone and career accelerator for many entry-level engineers. We managed to navigate the 2008 financial crisis together, forging incredible connections that remain strong to this day.

At that time, social media in India was predominantly Orkut, though by 2008, Facebook and Twitter began grabbing major market share. Yahoo Messenger was also soon replaced by Google Talk, which was lightweight and embedded right inside Gmail.

Sometime around 2010, I became fascinated by web services and began building them inside Oracle. While Oracle already had SOA, which prominently relied on SOAP (and all the WSDL complexity), the simplicity of REST captured my interest. Around the same time, Sun Microsystems was acquired by Oracle, making Java a central focus of innovation with new technologies like JavaFX, GlassFish, and NetBeans.

With the introduction of Google App Engine, I developed a strong interest in Platform as a Service (PaaS) and started using it for my personal projects. Back in 2009, it only supported Python, but once Java support was added, I decided to take a gamble and change my domain altogether.

This transition welcomed me into the world of gaming, which was culturally very different. For the first time, I was collaborating with an incredibly diverse group of people, including designers, artists, and product managers. Even the engineers working on the game clients were highly specialized, possessing deep knowledge of game engines and physics. Working at Electronic Arts (EA) was an incredibly fast-paced experience, both in terms of technology and people. Within months, your project could change, features could be shut down, or you might find yourself working with team members from a completely different region of the globe. One of the greatest lessons I learned there was how to be truly agile—sometimes you only found out the day’s top priority that morning. I also traveled extensively to other studios during this time, which gave me firsthand insight into the work culture and discipline of other parts of the world, especially the USA and Canada.

One of my notable projects at EA was working on the World Series of Poker, which introduced me to the functional programming paradigm of Erlang and Elixir. It completely changed how I thought about procedures and variables. Another project was Monopoly Bingo, which squeezed out every bit of potential from the then-limited Google App Engine. Because Datastore was our only persistence layer (which was NoSQL), our architecture had to be designed around key-based access rather than traditional SQL filters. Since writing to storage was expensive but compute was cheap and horizontally scalable, we leveraged techniques like sequential random number generators instead of storing every state. We jokingly called this “cost-oriented programming” 🙂.

It was a project of many firsts in my career: we used Gatling for load testing, Swrve for A/B testing, PagerDuty for alerting, and TestNG for unit tests. We even utilized Incredibuild to harness the idle power of everyone’s desktop machines to accelerate our build system. Later, I worked on titles like Tetris Blitz and Bejeweled Blitz, which used a LAMP stack. This was my first time using AWS as the main cloud provider, giving me a chance to brush up on PHP, which I hadn’t touched in years. Similar to Google’s Datastore, we used Couchbase for NoSQL, which eventually transitioned to DynamoDB in the Amazon ecosystem, while ElastiCache served as our equivalent to App Engine’s Memcache. Since Kubernetes didn’t exist yet, everything ran on individual VMs behind a load balancer.

Later, I moved to JDA, which was completely a Google shop. By then, Google Cloud Platform offered a rich suite of services, including BigQuery, Dataflow, Cloud Storage, Cloud SQL, and Pub/Sub. We used BigQuery and Dataflow to handle high-scale data ingestion and validation, while Pub/Sub enabled us to scale out, ultimately saving master data in Cloud SQL to service the Angular-facing APIs. Principles like Single Source of Truth (SSOT), Infrastructure as Code (IaC), Keep It Simple, Stupid (KISS), and “You Aren’t Gonna Need It” (YAGNI) became our daily buzzwords. Ultimately, this role provided a huge learning curve on how to operate in a modern cloud environment, designing multiple microservices that interacted not just through synchronous REST calls, but also via Pub/Sub push and pull subscriptions.

My next major milestone was at Salesforce, where we built the Loyalty System from the ground up on their highly mature and adaptable platform. It was incredible to experience how much out-of-the-box functionality was available with minimal custom code—a testament to a platform versatile enough to support virtually any business domain. Indeed, with Apex on the backend and LWC on the frontend, one can construct robust applications in hours without worrying about database management, web servers, or API routing. This role served as a masterclass in maximizing the utility of reusable shared components across various teams and organizational units, while also bringing valuable exposure to GitOps, service-to-service communication configurations, and IAM roles.

Currently, I am at Microsoft, a role that offers our team the autonomy to select our technology stack and own our projects end-to-end—from infrastructure at the VM and container level to requirement design, always treating security and compliance as non-negotiable foundations. It has been a rewarding journey so far, diving deep into everything from the fundamentals of authentication and public key infrastructure (PKI) to the consumer security domain. Working alongside AI as a co-developer has fundamentally transformed the development experience compared to years past. It is an incredibly exciting time to build, with boundless opportunities ahead for what we can create and deliver.

Two decades later, technology exists in an entirely different dimension. While I sometimes miss the days of sharing high-resolution photos on Flickr, it is incredibly exciting to connect with so many people who share my interests on Instagram and LinkedIn. Although the current wave of AI-generated “slop” is frustrating and makes finding genuine information difficult, I believe a consolidation is inevitable. Platforms will eventually adapt to user feedback, learning to surface what actually matters and letting low-effort content fade away, ultimately discouraging those looking for shortcuts.

I do miss the clean, chronological flow of linear email threads. Tools like Slack and Teams, with their constant stream of messages and bot notifications, can feel overwhelming. Yet, there is no denying they make us move faster. With a bit of self-discipline and clear team guidelines on what warrants attention, these channels can be highly streamlined. Indeed, we could never have survived the sudden shift to remote work during COVID-19 without the rapid advancement and adoption of video tools like Zoom and Meet, or collaboration hubs like Slack and Teams.

The convenience today is remarkable. I can reach government authorities with a single click and complete official transactions using Aadhaar authentication, eliminating the need to print endless photocopies. Airport travel is equally seamless: Digi Yatra allows me to bypass physical tickets and IDs entirely. I just show my face to pass through airport security scanners—no QR code needed until actual boarding (though a QR is still required while boarding).

It is truly an amazing time. I recently refactored a codebase for a pet project that I had struggled with for five years in just a single night using AI agents. I don’t even write down structured ideas anymore—I just “vibe code” it.

Ultimately, witnessing this twenty-year evolution of technology should help us better distinguish genuine innovation from temporary hype. Hopefully, this shared experience guides us to make the right investments rather than falling prey to knee-jerk reactions.

Handwritten by me, with grammar and typos corrected by AI.

Let’s Look at the Process

For the astronomical landing page, the first thing I did was get a good subdomain name. Firebase gives out .web.app subdomains so the choice of hosting was easy. It’s just a static site (for now) so the entire logic is in JavaScript. I used Antigravity for coding and let it run in “Fast mode” and occasionally just approved commands. It by default gave a mobile-friendly page which I am ok with because people mostly would launch this on mobile.

Initially the prompt was something very basic like “Create a landing page that shows astronomical events like sunrise and sunset times, moon phases, and other celestial occurrences. Also include Indian calendar details like zodiac signs.” This was a good start but had a lot of numbers on the page. I wanted more visual indicators like a progress bar showing things like how far the day or night has progressed before the next sunrise or sunset.

The good thing about Antigravity was that it can fire up the Chrome agent and launch the app locally and take a screenshot to check if it has implemented correctly and iterate if required. While iterating I realized occasionally it breaks the working functionality while implementing new things. For example, while implementing the planetary chart it ended up messing up the embedded sky chart. So I decided to create a snapshot of features using markdown file based on the current feature (especially describing the functional UI components like progress bars and the start and end time). This markdown file could just be my reference to the coding agent for regression testing and make sure they always keep working when new features are added.

The Good and Bad

While I am really glad that I could implement it in a matter of 5 hours, I think at the same time I feel I am not aware of the code structure and where to fix minor bug fixes if needed (without any AI tool help). It’s less likely I will have to do any changes without an AI coding tool’s help. It’s just I am not sure how maintainable this code would be in the long run. I guess I will have to wait and see how it goes.

For example, I wanted the sky map to be zoomable but Antigravity wasn’t able to implement it, though I gave a lot of feedback over and over. It just implemented the wheel scroll event and plus/minus buttons which don’t work because when you scroll the wheel the entire page scrolls. Even it could not implement the multi-touch way of being able to zoom on a touch device like mobile. I know with correct guidance it would be able to implement correctly eventually, but the problem is I don’t know much about the exact code where these JS components are implemented in the codebase so that I could give the context to the coding agent like tagging the exact file and function name.

This is a drawback I think for the future where we are getting super dependent on autonomous agents. This was not really a problem when we copied and pasted code from the chat window, at least the code was in our visual range and our brain could recall it. Possibly I should give it a prompt such that it generates an architecture diagram going through the current implementation and I try to understand it by going through it.

Running Out of Quota

The second biggest issue was that I ran out of quota for Antigravity. I had to wait for the quota to reset on Monday morning to continue working on the news podcast app.

Now what pic.twitter.com/nMXUx0kPkB

— Neil Ghosh (@neilghosh) January 3, 2026

So I moved to good old GitHub Copilot where I happen to have a very large quota (if not unlimited). It’s good but I won’t have the browser agent so I would mostly give the feedback manually by looking at the rendered UI. Also the news podcast app was a bit complex instead of simply a client UI. I have a few services running in cloud functions written in Python and a JS client calling them. It has authentication implemented and CORS handling. So simulating all this locally with emulator was difficult (which is the right thing to do for quicker iteration), so I mostly relied on re-deployment in the cloud. While the Firebase site hosting was quick to be redeployed, deploying Gen 2 cloud functions was time consuming (although multiple functions were deployed in parallel). So the iteration cycle was a bit slow.

At some point I did get the Antigravity quota reset (even using a different model gives you some more time with Antigravity) but the browser agent quota was still not available.

How do people automatically push feedback (and update instructions for future improvement) from autonomous agents every time they fail or take too long to execute?

This should definitely be easier than traditional systems that require source-code changes with correct syntax.

— Neil Ghosh (@neilghosh) January 2, 2026

What I Learned

While creating the news podcast app I learned that it’s always better to let the AI agent itself write the prompt that we use in the runtime inside the app (while calling Gemini API to generate news transcript and audio). My handwritten prompt was not very efficient although the intent was clear. So it’s more efficient to give the AI agent the intent which creates the prompt which in turn is used in runtime to get AI API output.

This is why it’s also wise to generate the copilot-instructions.md file (or any other Agent.md file if you are using other tools like Claude Code) using Copilot itself just by giving the intent in your own version of English. Over a period of time, even to enhance the instruction file I give a prompt like “Summarize the learning from the current chat session and update the instructions file such that it can get the correct result in one shot next time. Examples should be generalized and not specific to the task in hand.” This “upserts” the new instructions properly in the existing instructions file.

Sometimes I also issue the following prompt “Make the instructions file (add the file in context) concise and to the point by removing any redundant information.” This way the instruction file does not bloat over a period of time.

What I Want for the Future

Ultimately, though I got good results, I would like to “engineer” these kinds of development tasks using autonomous agents instead of random back and forth in the chat window. When I say “engineer”, I mean there has to be a proper process to provide the initial intent and generate a plan and try to visualize what it would make and then create the first version say “pre-MVP” and there has to be a mechanism to provide persistent feedback and enhance the plan which would again automatically create the desired version and so on.

In this way since my requirements would always be built progressively it’s unlikely it will regress and also it would have a blueprint handy for a new engineer or even myself in the future to understand the code structure and be able to fix minor issues without much help from an AI coding agent.

Probably spec-driven development is the answer to this. More about this in another post when I explore more.

There were non-functional requirements like Google Analytics integration, SEO optimizations, dark mode etc which are common across projects, I could implement in one shot with minimal instructions. This gives developers time back to focus on building things which are unique to the app instead of spending time on plumbing work.

Try the Apps

Do let me know your thoughts about the following:

• Stargazing App: https://stargazing.web.app
• News Podcast App: https://newscast.web.app

Well the title is a bit click bait-y. It basically means running Large Language Models (LLMs) locally on your computer, even in a VM for that matter. Think of it as having your own personal AI assistant that runs entirely on your hardware, without sending any data to external servers.

There are two major advantages of running LLMs locally:

• It’s free! You don’t have to pay for subscriptions like ChatGPT Plus ($20/month) or Gemini Pro. Once you download a model, you can use it as much as you want without any usage limits or API costs.

• Privacy and Data Control: Though there are free versions of commercial LLMs, running on your own computer makes it completely private. You’re not giving away your personal queries, interests, and data to third-party servers. This is especially important if you’re asking health-related questions, working with confidential business data, or discussing sensitive topics.

Additionally, you get:

• No internet dependency: Once models are downloaded, you can use them offline
• Customization: You can fine-tune models for specific tasks
• No rate limits: Use the model as much as you want without throttling

Setting up Ollama

Firstly, you need to install and start ollama. Ollama is a tool that simplifies running LLMs locally. It handles model management, provides a simple API, and optimizes model execution for your hardware.

On Mac, you can install it using Homebrew:

brew install ollama

For Linux:

curl -fsSL https://ollama.com/install.sh | sh

For Windows, download the installer from the Ollama website.

Next, we need to start the Ollama server. This runs in the background and handles all model inference requests:

ollama serve

The server will start on http://localhost:11434 by default. Keep this terminal window open as it needs to run continuously.

Choosing and Running a Model

Now we need to decide which model to download. The model choice depends on your hardware capabilities:

• Small models (2B-7B parameters): Run on most laptops, faster responses, less capable
• Medium models (13B-30B parameters): Need 16GB+ RAM, good balance of speed and quality
• Large models (70B+ parameters): Need 64GB+ RAM, best quality, slower

I chose to run a very large model from Google’s Gemma family (gemma3:27b with 27 billion parameters) because I have a powerful machine - a Mac Studio with M2 Ultra chip and 128GB unified memory. The “27b” in the model name indicates it has 27 billion parameters.

Note: Each billion parameters roughly needs 2GB of RAM when loaded. So a 27B model needs about 54GB of available RAM to run smoothly.

Open a new terminal (keep the ollama serve running in the first one) and run:

ollama run gemma3:27b

For the first time, depending on the model size, it will download the model files (this can take several minutes for large models). Once downloaded, you’ll see:

>>> Send a message (/? for help)

Testing the Model

Now you can chat with the model directly in the terminal:

>>> Who are you? Whats todays date
Hi there! I'm Gemma, an open-weights AI assistant. I'm a large language model trained by Google DeepMind. The Gemma team are my creators.

Today is November 21, 2023.

Important: The date is much in the past because the model was trained around that time. LLMs don’t have real-time information - they only know what was in their training data. The model’s knowledge is frozen at its training cutoff date, and it cannot learn or update itself with new information without retraining.

>>> What's your knowledge cut off and Parameters?
My knowledge cut-off is **September 2021**. This means I don't have information about events that occurred after that date. So, I won't know about things that happened in 2022, 2023, or beyond unless specifically included in my training data.

As for my parameters, I come in two sizes:

*   **Gemma 2B:** Has **2 billion parameters**. This is a smaller, faster model suitable for resource-constrained environments.
*   **Gemma 7B:** Has **7 billion parameters**. This is a larger, more capable model that generally delivers better performance.

I'm the open-weights version, meaning the model weights are publicly available! You can find more details on the Gemma models here: [https://ai.google.dev/gemma](https://ai.google.dev/gemma)

Understanding Parameters: The number of parameters (weights) in a neural network directly correlates with its capability to understand and generate text. More parameters generally mean better understanding of context, nuance, and ability to generate higher quality responses, but at the cost of more memory and slower inference.

Let’s test its knowledge of recent developments:

>>> What's an MCP server
An MCP server refers to a server used for playing **Minecraft: Pocket Edition (MCPE)** using a third-party server software called **Multiplayer for Pocket Edition (MCPC)**, or sometimes just "MCP." Here's a breakdown of what it is and why it's different from
regular Minecraft servers:

As you can see, it doesn’t know that “MCP Server” now refers to the Model Context Protocol - a new standard introduced by Anthropic in late 2024 that has become a hot topic in the AI space. This clearly demonstrates the model’s knowledge cutoff limitation.

Despite this limitation, the model is still very powerful for:

• General knowledge questions (up to its training date)
• Coding and programming help
• Writing and content creation
• Analysis and reasoning tasks
• Mathematical calculations

Adding a Web Interface with Open WebUI

While the terminal interface works great, you might prefer a more user-friendly ChatGPT/Gemini-style chat interface in your browser. That’s where Open WebUI comes in - it’s an open-source, self-hosted web interface that connects to Ollama.

To run Open WebUI, you need Docker Desktop installed, though there are also Python-based installation methods available.

If you have Docker Desktop running, execute this command:

docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main

What this command does:

• -d: Runs the container in detached mode (background)
• -p 3000:8080: Maps port 8080 in the container to port 3000 on your host
• --add-host=host.docker.internal:host-gateway: Allows the Docker container to communicate with Ollama running on your host
• -v open-webui:/app/backend/data: Creates a persistent volume for chat history and settings
• --restart always: Automatically restart the container if it crashes or after system reboot

Once the Docker container is running, open your browser and navigate to http://localhost:3000/

Using the Ollama API

You can also interact with Ollama programmatically using its REST API. This is useful for integrating LLMs into your own applications:

curl http://localhost:11434/api/generate -d '{
  "model": "gemma3:27b",
  "prompt":"Who was first President of India"
}'

neilghosh@neilghosh-mac-studio ~ % curl http://localhost:11434/api/generate -d '{  "model": "gemma3:27b",   "prompt":"Who was first President of India"}'
{"model":"gemma3:27b","created_at":"2025-12-28T11:43:47.941022Z","response":"The","done":false}
{"model":"gemma3:27b","created_at":"2025-12-28T11:43:47.980486Z","response":" first","done":false}
{"model":"gemma3:27b","created_at":"2025-12-28T11:43:48.019804Z","response":" President","done":false}
{"model":"gemma3:27b","created_at":"2025-12-28T11:43:48.059296Z","response":" of","done":false}
{"model":"gemma3:27b","created_at":"2025-12-28T11:43:48.098868Z","response":" India","done":false}
{"model":"gemma3:27b","created_at":"2025-12-28T11:43:48.138344Z","response":" was","done":false}
{"model":"gemma3:27b","created_at":"2025-12-28T11:43:48.177787Z","response":" **","done":false}
{"model":"gemma3:27b","created_at":"2025-12-28T11:43:48.217355Z","response":"Dr","done":false}
{"model":"gemma3:27b","created_at":"2025-12-28T11:43:48.25691Z","response":".","done":false}
{"model":"gemma3:27b","created_at":"2025-12-28T11:43:48.296326Z","response":" Raj","done":false}
{"model":"gemma3:27b","created_at":"2025-12-28T11:43:48.335835Z","response":"endra","done":false}
{"model":"gemma3:27b","created_at":"2025-12-28T11:43:48.375877Z","response":" Prasad","done":false}
...
...
Indian","done":false}
{"model":"gemma3:27b","created_at":"2025-12-28T11:43:50.230835Z","response":" Constitution","done":false}
{"model":"gemma3:27b","created_at":"2025-12-28T11:43:50.27012Z","response":".","done":false}
{"model":"gemma3:27b","created_at":"2025-12-28T11:43:50.309673Z","response":"\n\n\n\n","done":false}
{"model":"gemma3:27b","created_at":"2025-12-28T11:43:50.34898Z","response":"","done":true,"done_reason":"stop","context":[105,2364,107,15938,691,1171,5376,529,4673,106,107,105,4368,107,818,1171,5376,529,4673,691,5213,9231,236761,15105,37888,91520,84750,236743,108,2209,7779,699,236743,236770,236819,236810,236771,531,236743,236770,236819,236825,236778,236764,1646,16492,10911,236761,1293,691,496,2307,8575,528,506,6225,21555,7296,1680,4673,16531,21555,236764,532,6657,496,3629,3853,528,66582,506,6225,20901,236761,110],"total_duration":2903714459,"load_duration":156688500,"prompt_eval_count":15,"prompt_eval_duration":337553125,"eval_count":62,"eval_duration":2382672126}

Understanding Token Streaming

The responses come in small chunks because of the fundamental nature of how LLMs work. The model generates and streams back one token at a time (a token is roughly a word or part of a word). This isn’t just a fancy UI effect to make it look like it’s “thinking” - it’s actually how the model generates text:

1. The model predicts the most likely next token based on all previous tokens
2. That token is sent to the client immediately (streaming)
3. The model then uses that token as input to predict the next token
4. This process repeats until the model decides to stop

This is why you see the "done":false in each JSON response until the final one. Streaming allows users to start reading the response before generation is complete, which is especially valuable for long responses.

Specialized Models for Different Tasks

While Gemma3:27b is a powerful general-purpose LLM, there are specialized models optimized for specific tasks. For coding and programming tasks, qwen2.5-coder:32b is excellent.

Qwen2.5-Coder is specifically trained on massive amounts of code and technical documentation, making it particularly good at:

• Code generation and completion
• Debugging and code review
• Explaining code
• Converting between programming languages
• Writing documentation

To run it:

ollama run qwen2.5-coder:32b

Other popular models available through Ollama:

• llama3.1:70b - Meta’s flagship open model
• deepseek-coder:33b - Another excellent coding model
• mistral:7b - Fast and efficient general-purpose model
• codellama:34b - Meta’s specialized code model

Integrating with VS Code using Continue

To use these local models directly in VS Code (similar to GitHub Copilot or other AI coding assistants), you can install the Continue extension. This brings the power of local LLMs right into your editor with features like:

• Chat interface: Ask coding questions in a sidebar
• Code editing: Select code and ask the AI to modify it
• Autocomplete: Get inline code suggestions as you type
• Code explanation: Understand complex code

Install Continue from the VS Code marketplace, then configure it to use your local Ollama models by editing its config file (~/.continue/config.json):

name: Local Config
version: 1.0.0
schema: v1
models:
  - name: Qwen3 30B
    provider: ollama
    model: qwen3:30b
    roles:
      - chat
      - edit
      - apply      
  - name: qwen2.5-coder:32b
    provider: ollama
    model: qwen2.5-coder:32b
    roles:
      - autocomplete

Understanding the roles:

• chat: Used for the chat sidebar where you ask questions
• edit: Used when you select code and ask the AI to modify it
• apply: Used for applying changes suggested by the AI
• autocomplete: Used for inline code completion as you type

The configuration above uses the larger Qwen3 30B for interactive tasks (chat, edit, apply) where quality matters, and the specialized qwen2.5-coder for fast autocomplete suggestions.

If you see it asking for API keys of subscription-based services, double-check that local config is properly enabled in the Continue plugin settings.

Continue CLI for Terminal Users

For developers who prefer working in the terminal, Continue also offers a CLI tool that functions like GitHub Copilot CLI or Gemini CLI. It allows you to ask coding questions and get AI assistance directly in your terminal:

npm install -g @continuedev/cli

After installation, you can use commands like:

continue "how do I parse JSON in Python"
continue "explain this error: ModuleNotFoundError"
continue "write a function to sort an array"

Managing Models

You can list all models that are downloaded on your system at any time:

ollama list

Output:

NAME                 ID              SIZE     MODIFIED
deepseek-r1:32b      edba8017331d    19 GB    45 hours ago
qwen3:30b            ad815644918f    18 GB    2 days ago
qwen2.5-coder:32b    b92d6a0bd47e    19 GB    2 days ago
gemma3:27b           a418f5838eaf    17 GB    2 days ago

This shows all downloaded models, their IDs, disk space usage, and when they were last used.

Useful Ollama commands:

ollama ps                    # Show currently running models
ollama pull <model>          # Download a model
ollama rm <model>            # Remove a model to free up space
ollama show <model>          # Show model information and parameters
ollama cp <src> <dest>       # Copy a model

Note: Models are automatically loaded into memory when you use them and unloaded after a period of inactivity to free up RAM. Use ollama ps to see which models are currently loaded in memory.

Conclusion

Running LLMs locally gives you privacy, cost savings, and complete control over your AI assistant. While local models may not be as capable as the latest GPT-4 or Claude models, they’re constantly improving and are more than sufficient for most everyday tasks. The ecosystem of tools like Ollama, Open WebUI, and Continue makes it easier than ever to get started with local AI.

I used to lose sleep over GitHub secrets. Every deployment credential stored in my repository felt like a ticking time bomb—what if someone accidentally logged it? What if my former colleague still had access to the org? What if the credentials leaked?

Then I discovered OIDC Federated Identity, and honestly, it changed how I think about CI/CD security.

Let me walk you through how we’re deploying a .NET 8 API to Azure App Service without storing a single password, using a real application as our example.

The Problem We’re Solving

Traditional deployment workflows look like this:

# The old way (please don't do this anymore)
- name: Login to Azure
  uses: azure/login@v2
  with:
    creds: $  # This is a full JSON object with a password

When you use AZURE_CREDENTIALS, you’re storing something that looks like this in your GitHub secrets:

{
  "clientId": "abc123...",
  "clientSecret": "super-secret-password-here",
  "subscriptionId": "...",
  "tenantId": "..."
}

That clientSecret is the problem. It’s:

• Rotatable only by hand (easy to forget)
• Visible in logs if leaked (one mistake and it’s compromised)
• Active even when not needed (sitting there 24/7)

The Modern Solution: Keyless Deployment with OIDC

Instead, GitHub can generate a short-lived token (OIDC token) that’s cryptographically signed with GitHub’s private key. Azure validates this signature and trusts the token automatically.

No passwords. No rotating credentials. Just a temporary, signed token that expires in minutes.

Here’s what we changed:

# The new way (keyless)
- name: Log in to Azure using Managed Identity
  uses: azure/login@v2
  with:
    client-id: $        # Just an ID
    tenant-id: $        # Just an ID
    subscription-id: $  # Just an ID

Notice the difference? We’re only storing IDs now. They’re not secrets—they’re public information that identifies which Azure resources and tenant we’re authenticating to. The actual authentication happens via OIDC token exchange.

Our Real Application: A Simple .NET 8 API

Let me introduce our test subject. It’s a straightforward ASP.NET Core Web API:

// Program.cs - Dependency injection setup
var builder = WebApplication.CreateBuilder(args);

builder.Services.AddControllers();
builder.Services.AddScoped<IIpAddressService, OutboundIpService>();
builder.Services.AddScoped<IIpifyProxy, IpifyProxy>();
builder.Services.AddHttpClient<IpifyProxy>();

var app = builder.Build();
app.UseRouting();
app.MapControllers();
app.Run();

It’s a layered architecture with services, proxies, and controllers. Nothing fancy. The kind of app you might be deploying yourself.

We containerize it with a multi-stage build:

# Dockerfile - Multi-stage build for smaller image size
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY simple-dotnet-service.csproj .
RUN dotnet restore
COPY . .
RUN dotnet publish -c Release -o /app/publish simple-dotnet-service.csproj

FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS runtime
WORKDIR /app
COPY --from=build /app/publish .
ENV ASPNETCORE_URLS=http://+:8080
ENV ASPNETCORE_ENVIRONMENT=Production
EXPOSE 8080
ENTRYPOINT ["dotnet", "SimpleDotnetService.dll"]

This gets pushed to Azure Container Registry (ACR), then deployed to App Service.

How the Workflow Actually Works

Here’s our complete three-job deployment pipeline:

Job 1: Build & Test (No Azure Access Needed)

build-and-test:
  runs-on: ubuntu-latest
  permissions:
    contents: read
  
  steps:
  - name: Checkout code
    uses: actions/checkout@v4
  
  - name: Setup .NET
    uses: actions/setup-dotnet@v4
    with:
      dotnet-version: '8.0.x'
  
  - name: Restore dependencies
    run: dotnet restore simple-dotnet-service.sln
  
  - name: Build
    run: dotnet build simple-dotnet-service.sln --configuration Release --no-restore
  
  - name: Run tests
    run: dotnet test simple-dotnet-service.sln --no-build --verbosity normal --configuration Release

This runs on every push and PR. It doesn’t touch Azure at all. If the build fails, we stop before wasting time on Docker operations.

Job 2: Build & Push Docker (OIDC Magic Happens Here)

build-and-push-docker:
  runs-on: ubuntu-latest
  needs: build-and-test
  if: github.event_name == 'push' || github.event_name == 'workflow_dispatch'
  permissions:
    contents: read
    id-token: write  # ← This is the key! Allows GitHub to generate OIDC token
  
  steps:
  - name: Log in to Azure using Managed Identity
    uses: azure/login@v2
    with:
      client-id: $
      tenant-id: $
      subscription-id: $
  
  - name: Log in to Azure Container Registry
    run: az acr login --name simpledotnetregistry565
  
  - name: Build and push Docker image to ACR
    run: |
      docker build -t simpledotnetregistry565.azurecr.io/simple-dotnet-service:$ \
                   -t simpledotnetregistry565.azurecr.io/simple-dotnet-service:latest .
      docker push simpledotnetregistry565.azurecr.io/simple-dotnet-service:$
      docker push simpledotnetregistry565.azurecr.io/simple-dotnet-service:latest

Look at that permissions block. id-token: write tells GitHub Actions: “I need permission to generate an OIDC token for this job.”

Here’s what happens behind the scenes:

1. GitHub generates an OIDC token - This token is cryptographically signed with GitHub’s private key and contains information about the workflow (repo, branch, commit, etc.)

2. azure/login passes it to Azure - The azure/login@v2 action receives the token and sends it to Microsoft Identity Platform

3. Azure validates the signature - Azure uses GitHub’s public key to verify the token is legitimate

4. Azure checks the federated credential - Azure verifies that this specific repo on this specific branch is allowed (we’ll set this up next)

5. Azure issues an access token - If everything checks out, Azure gives back a temporary access token

6. All subsequent az commands use that token - No passwords needed

The result? Your Docker image is securely pushed to ACR.

Job 3: Deploy to App Service

deploy-to-app-service:
  runs-on: ubuntu-latest
  needs: build-and-push-docker
  if: github.event_name == 'push' || github.event_name == 'workflow_dispatch'
  permissions:
    contents: read
    id-token: write
  
  steps:
  - name: Log in to Azure using Managed Identity
    uses: azure/login@v2
    with:
      client-id: $
      tenant-id: $
      subscription-id: $
  
  - name: Configure App Service to use container image
    run: |
      az webapp config container set \
        --name simple-dotnet-service \
        --resource-group simple-dotnet-service-rg \
        --container-image-name simpledotnetregistry565.azurecr.io/simple-dotnet-service:latest \
        --container-registry-url https://simpledotnetregistry565.azurecr.io
  
  - name: Enable Managed Identity for ACR access
    run: |
      az webapp identity assign \
        --name simple-dotnet-service \
        --resource-group simple-dotnet-service-rg \
        --identities [system]
  
  - name: Restart App Service
    run: |
      az webapp restart \
        --name simple-dotnet-service \
        --resource-group simple-dotnet-service-rg

Same OIDC flow, fresh token for this job. Now we tell App Service:

• “Here’s your container image”
• “Use Managed Identity to pull it from ACR”
• “Restart so you pick up the new version”

The One-Time Setup: Trusting GitHub in Azure

This is the magic part. In your Azure subscription, you create a Federated Credential that says: “Trust OIDC tokens from GitHub when they come from this specific repository on the main branch.”

Option 1: Azure Portal (GUI)

1. Go to Azure Portal → Search for App registrations
2. Click your app registration
3. Go to Certificates & secrets (left sidebar)
4. Click Add a credential → Federated credential
5. Choose scenario: GitHub Actions deploying Azure resources
6. Fill in:
   • Organization: your-github-org
   • Repository: simple-dontnet-service
   • Entity type: Branch
   • Branch name: main
7. Click Add

Option 2: Azure CLI (Faster)

# Get your app registration object ID
APP_OBJECT_ID=$(az ad app list --display-name "YourAppName" --query "[0].id" -o tsv)

# Create the federated credential
az ad app federated-credential create \
  --id $APP_OBJECT_ID \
  --parameters '{
    "name": "GitHub-Actions-simple-dotnet-service",
    "issuer": "https://token.actions.githubusercontent.com",
    "subject": "repo:your-org/simple-dontnet-service:ref:refs/heads/main",
    "audiences": ["api://AzureADTokenExchange"]
  }'

That’s it. After this, GitHub can deploy your app without any additional secrets.

Why This Matters (Security Wins)

Let me be specific about what we’ve gained:

❌ Old Way Problems

• Password stored 24/7 in GitHub (compromise window is huge)
• Manual rotation required (easy to forget)
• Password visible if accidentally logged (one mistake ruins everything)
• Same credential used for weeks (compromise goes undetected longer)

✅ New Way Benefits

• No passwords stored - Just IDs, which are public information
• Automatic token generation - New token every workflow run
• Tokens expire in minutes - Compromise window is tiny
• Tokens are signed - GitHub and Azure verify cryptographically
• Audit trail - Exactly which repo ran which deployment when
• Scope-limited - Token only works for this repo/branch combination

Visualizing the Flow

GitHub Push
    ↓
build-and-test job (no Azure)
    ↓
build-and-push-docker job
    ├─ Generate OIDC token (GitHub private key)
    ├─ Send to Azure
    ├─ Azure validates (GitHub public key)
    ├─ Azure checks federated credential
    ├─ Azure issues access token
    ├─ Build Docker image
    └─ Push to ACR
    ↓
deploy-to-app-service job
    ├─ Generate fresh OIDC token
    ├─ Exchange for new access token
    ├─ Configure App Service
    ├─ Enable Managed Identity
    └─ Restart App Service
    ↓
Application running with new version

The Real-World Impact

I’ve been using this setup in production for months. Here’s what changed:

1. I stopped checking if passwords were leaked - They don’t exist
2. Zero credential rotation overhead - It’s automatic
3. Better sleep at night - No late-night “did someone get my credentials?” anxiety
4. Cleaner audit logs - Every deployment is traceable to a specific commit
5. Easier for teams - New team members don’t need special secret management

And honestly? It was simpler to set up than I expected. A few minutes in the Azure Portal, and we were done.

Getting Started

If you want to implement this yourself:

1. Create or identify your Azure App Registration - You need the client ID
2. Get your tenant ID and subscription ID - These are in Azure Portal
3. Create the federated credential - Use the Portal or CLI command above
4. Add three GitHub secrets:
   • AZURE_CLIENT_ID
   • AZURE_TENANT_ID
   • AZURE_SUBSCRIPTION_ID
5. Update your workflow - Use the azure/login@v2 action with OIDC (add id-token: write permissions)
6. Delete old secrets - Like AZURE_CREDENTIALS or REGISTRY_PASSWORD

You can see the full workflow in our repository: .github/workflows/azure-app-service-deploy.yml

What About Other Platforms?

This pattern works with:

• AWS - OIDC provider, similar setup
• GCP - Workload Identity Federation
• HashiCorp Cloud - OIDC support
• Any platform with OIDC support - The pattern is standardized

Final Thoughts

Keyless deployment isn’t bleeding-edge anymore. It’s the sensible default. If you’re still storing full credentials in GitHub secrets, I’d encourage you to make the switch.

Your future self will thank you when you don’t have to panic about credential rotations at 2 AM.

Questions or running into issues? The Azure documentation on OIDC is excellent. Also check out GitHub’s official guide.

Happy deploying! 🚀

I could also put a snippet of post in this blog and redirect the users to the full post in medium but that sounds like a duplicate effort as of now.

Please head over to my latest posts https://medium.com/@neilghosh.

In future I may migrate all the post hosted here (I came here gtom Blogger.com via wordpress :) ) to my medium page but I am skeptical about being locked to a propriatory platform right now.

Generating key pair

ssh-keygen -t ed25519 -C "Your EMail"

Provide the file name this time.

Enter file in which to save the key (/Users/sabyasachi.ghosh/.ssh/id_ed25519): github

Once can use the default key generated (without any file name specified) globally for all git hosts, however there is a chance you are using two different git servers and want to keep the keys separate. This becomes really important in cases you are using the same machine for work and personal git repos.

laptop % ls -ltr ~/.ssh/
total 56
-rw-------@ 1 sabyasachi.ghosh  staff   432 Oct 27 13:20 id_ed25519
-rw-r--r--@ 1 sabyasachi.ghosh  staff   113 Oct 27 13:20 id_ed25519.pub
-rw-------@ 1 sabyasachi.ghosh  staff   411 Nov  9 10:16 github
-rw-r--r--@ 1 sabyasachi.ghosh  staff   102 Nov  9 10:16 github.pub
-rw-r--r--@ 1 sabyasachi.ghosh  staff    84 Nov  9 10:38 config
-rw-------@ 1 sabyasachi.ghosh  staff  1523 Nov  9 10:39 known_hosts

In this case you have to explicitly provide the key generated specifically for a git server in ~/.ssh/config file. For example

Host github.com
  AddKeysToAgent yes
  UseKeychain yes
  IdentityFile ~/.ssh/github

Now you can test the connection (even before attempting to clone)

ssh -T git@github.com

Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'github.com' (ED25519) to the list of known hosts.
Hi neilghosh! You've successfully authenticated, but GitHub does not provide shell access.

Now we can go ahead and go all git operation.

1. Enable Wifi in GoPro. (Fastest way is to connect from mobile app and view media).
2. Connect your PC/Mac to the GoPro’s WiFi e.g. “GoPro Hero 10 Black”
3. Navigate to http://10.5.5.9/videos/DCIM/100GOPRO/, it should give the directory listing.
4. You can download files one by one by right clicking and downloading
5. You can use wget to download in a bulk as well. wget -r -np -nH -nc -A MP4 "http://10.5.5.9/videos/DCIM/100GOPRO/?dd"

One can play with wget’s options to download specific file pattern i.e. extension or even append dd to the query string to sort the listing in and download oldest file first.

These embeddings can be stored in a vector database and various queries like finding similar images on the basis of distances can be done on the stored vector data.

In this post, we will generate embeddings from photos stored in Google Cloud Storage and save them PostgreSQL database with pg-vector enxtension. Then we will query for images which are similar to any given images on the data set. We will use a notebook in Collab Enterprise which is a great way of interactively playing with code snippets and iterating like a REPL. It is backed by computing resources (called Runtimes) from Google Cloud which can spin up and scale very quickly. Notebooks in the cloud can also be shared with others who can contribute text and code simultaneously.

Let’s get started …

Setting up

Launching Notebook.

Collab Enterprise can be accessed directly under the Vertext AI menu in Google Cloud Console. Once enabled with billing account and all necessary APIs are enabled we should be able to create notebooks.

Setup gcloud

Since we will use various CLI commands from Google Cloud SDK, gcloud needs to be installed and authorised with the GCP project whose resources will be used.

!curl https://sdk.cloud.google.com | bash
!gcloud init
!gcloud config set project <project_id>

Generate embeddings from Images

For this we will use the multimodal API from Vertext AI. This API takes both text and image. In the case of image, it takes either the image data (in base64 encoded bytes) or URL of the GCS object. GCS URLs would take less time to transfer the data from local run-time storage, so we would go for that option.

Following is the API Request Payload. We have kept the dimension to be the minimum supported so that we get a quick and small response for the experiment. Larger dimensions would give us more accuracy while searching at a later stage by retaining more information from the images into the embedding vectors.

Request

{
  "instances": [
    {
      "image": {
        "gcsUri": "gs://<gcs_bucket>/IMG001.jpg"
      }
    }
  ],
  "parameters": {
    "dimension": 128
  }
}

Python Client

location : str = "us-central1",
api_regional_endpoint: str = "us-central1-aiplatform.googleapis.com"):
client_options = {"api_endpoint": api_regional_endpoint}
self.client = aiplatform.gapic.PredictionServiceClient(client_options=client_options)

image_struct = instance.fields['image'].struct_value
image_struct.fields['gcsUri'].string_value = gcs_url
instances = [instance]

parameter = struct_pb2.Struct()
parameter.fields['dimension'].number_value = 128
parameters = parameter

endpoint = (f"projects/{self.project}/locations/{self.location}"
      "/publishers/google/models/multimodalembedding@001")
response = self.client.predict(endpoint=endpoint, instances=instances, parameters=parameters)

The response would be an array of numbers, similar to the following

Response

{
  "predictions": [
    {
      "imageEmbedding": [
        0.00262696808,
        -0.00198890246,
        0.0152047109,
        -0.0103145819,
        [...]
        0.0324628279,
        0.0284924973,
        0.011650892,
        -0.00452344026
      ]
    }
  ]
}

The above API (python client) only supports one image at a time so that it can be called for each image found in a GCS bucket where we have uploaded the image files. There is a Batch API for this but that only supports the text far. This is one of the reasons why we chose to use GCS object URLs directly instead of encoding the image into base64 bytes and sending the full content in the API.

Invoke API and Save Embeddings

We use Google Cloud Python SDK again to list the images found in the bucket parse the response from the API and save as a CSV file.

bucket_name = "birdwalk"
storage_client = storage.Client()
blobs = storage_client.list_blobs(bucket_name)
for blob in blobs:
	instance = struct_pb2.Struct()
	gcs_url = os.path.join("gs://", bucket_name, blob.name)
	image_struct = instance.fields['image'].struct_value
	image_struct.fields['gcsUri'].string_value = gcs_url

	response = client.get_embedding(image_bytes=image_file_contents, gcs_url=gcs_url)
	
	row = response.image_embedding;
	row.insert(0, blob.name) #add the image name as key
	rows.append(row)

with  open('embeddings.csv', 'w') as f:
write = csv.writer(f)
write.writerows(rows)

Inspect the results

We chose to save the result locally and inspect it either by clicking on the file directly in the notebook runtime file system or just loading it to pandas and printing.

import pandas as pd
DATASET_URL='embeddings.csv'
image_embeddings = pd.read_csv(DATASET_URL, header=None)
image_embeddings.head(5)

Setup Cloud SQL

We will create a small instance of Cloud SQL and install the pg-vector extension to support the VECTOR data type. We chose 1 CPU and 1.7 GB memory to minimise cost as we are not going to store and query a lot of data. Cloud SQL instance is charged as long as it’s up so we can stop the instance once we are done and start it when we intend to use it again. It will still charge for the storage and IP etc but they are negligible as compared to the instance running cost.

    DATASET_URL='embeddings.csv'
    image_embeddings = pd.read_csv(DATASET_URL, header=None)

    loop = asyncio.get_running_loop()
    async with Connector(loop=loop) as connector:
        # Create connection to Cloud SQL database.
        conn: asyncpg.Connection = await connector.connect_async(
            f"{project_id}:{region}:{instance_name}",  # Cloud SQL instance connection name
            "asyncpg",
            user=f"{database_user}",
            password=f"{database_password}",
            db=f"{database_name}",
        )

        await conn.execute("CREATE EXTENSION IF NOT EXISTS vector")
        await register_vector(conn)

        await conn.execute("DROP TABLE IF EXISTS image_embeddings")
        # Create the `product_embeddings` table to store vector embeddings.
        await conn.execute(
            """CREATE TABLE image_embeddings(
                                image_id VARCHAR(1024),
                                content TEXT,
                                embedding vector(128))"""
        )

        # Store all the generated embeddings back into the database.
        for index, row in image_embeddings.iterrows():
            await conn.execute(
                "INSERT INTO image_embeddings (image_id, content, embedding) VALUES ($1, $2, $3)",
                row[0],
                "",
                np.array(row[1:]),
            )

Query For Similar Images

Now we can query the database for similar image to a specific image.

        result = await conn.fetch(
            '''
              SELECT
                image_id,
                embedding <-> ( SELECT
                                  embedding
                                FROM image_embeddings
                                WHERE image_id = $1) as distance
              FROM image_embeddings
              WHERE image_id != $1
              ORDER BY distance
              LIMIT 5;
            ''',
            image_id )

This query essentially takes the name of the image file as image_id and compares its embeddings with the embeddings of other images and returns the top 5 images (excluding the input image whose distance of course will be zero) whose distance is closer to the supplied image. In this example I wanted to find if there are similar images to the photo of the plane and if you notice in the result, it returns 4 planes of which the first two’s distance is very less ( < 0.2 because it was the same plane taken from different angle) and other two have higher distance (betwene 0.3 to .4) . The last image is actually of a bird hence has an even higher distance( < 0.5). By doing the following changes the results could have been more accurate i.e. distance of the same plane would have been very small as compared to a that of different plan or a bird for which distance was expected to be very high.

• The dimension of the embedding could be increased so that more features of the images could have been used for comparison/distance.
• The input image itself could have been processed (e.g. cropped to the object) so that the sky which is common in all images couldn’t have dominated the similarity.

I’ll soon upload the the fully working notebook (of course Bring Your Own GCP Project).

I just realised that my last post was in August 2022. That’s nearly 8 months. I doubt if there has been such a long gap in the past between the two posts. Honestly, I don’t have anything specific to post today, definitely not related to tech. I am just trying to create a habit, of writing, at least the content that can be posted publicly. Something like Snapchat streak, just heard about it from one of my 17-year-old cousins though I never used it. I know resolutions are taken in the new year usually but after all, April is the beginning of the financial year in India and in my opinion, more things reset in April than in January. So it’s not really a bad time for starting anything.

So what’s going on in this world? I actually have no idea, at least it’s hard to articulate whatever bits and pieces I think what’s going on. How do I start putting them down?

One of the ways to start a conversation, especially one-on-one is to ask “What’s on top of your mind?”, not a bad strategy though needless to say the conversation will always start with something on top of my mind unless the agenda is defined for any meeting. Nevertheless, let’s go with that strategy.

I can’t really write anything personal, like relationships, financial goals or even career aspirations at this point but at least mention my world view of mine which is definitely in the top 10 things in mind if not the top 5 - which is probably all occupied with very personal things.

Firstly - The potential return of Covid is definitely one of the concerning me right now. Finally, people started to live their lives like the pre-covid era but again there is news. New Covid Cases Up By 186% In Maharashtra, 4 Deaths In 24 Hours. I don’t even see the chart that used to come in google’s search result till a few months back. The only good thing that happened during covid is people learned to work remotely be it tech or teaching. I see a lot of parents could be returned to work while they were forced to take a break to take care of their children at home. Well, all these are not comparable with the lives lost during covid waves. All I can do is keep an eye on numbers right now and don’t forget some hygiene and behaviour are applicable always be it covid or not. Even if we don’t mask up always, washing hands and unnecessary physical contact should be avoided.

Next, I think the financial slowdown had affected a lot of people I know. People have lost their jobs, especially in tech, the very industry which went through great resignation during even peak of the covid. It is unbelievable. Surprisingly the “Product based” companies suffered more than the “Service based” companies which have been always looked down upon in tech industries. Not sure who would have the last laugh. I never thought there is a comparison. Yes, the average salaries of the service companies may be less than the product companies but look at the layoff numbers now. Also, I have so many friends who made their fortune working for services companies for overseas clients only to move to the client location for good if not end up working for the clients themselves.

There are other things like climate change that are always a concerning thing year after year.

Hopefully, my next post will be tech related but I am glad I am able to write.

The agenda of this two and half-day summit was a mix of sessions from special speakers from Google Developer Relations, Community Leaders, Cultural Programs and visits to nearby tourist places. However, the biggest benefit was probably the opportunity to connect with people in person which people have been deprived of lately due to the pandemic.

The preparation for the journey involved making sure one is fit for high altitudes like Ladakh and packing a bunch of warm clothes including jackets. The weather was actually bright and sunny and not much of use for the jacket until late evening when it starts to get a bit cold and breezy.

The beauty of the Himalayan range can be seen right from the plane to Ladakh. Most flights in fact start from New Delhi. The stay was one of the best hotels in Ladakh with a beautiful view of the Karakoram range through the window of the room.

Day 1 when everyone landed from various parts of India was mostly recommended to be spent acclimatising the altitude. So there wasn’t much activity but it was well utilised networking with each other.

Day 2 started with very inspiring keynotes from various members of Google Developer Relations and some of the community sessions who presented on some of the designated topics. End of the day there was a trip to the Thikse Monastery which was quite a bit of a climb but the place and the view of Ladakh from the top were definitely worth it.

The day ended with the musical performance of Tongue Drum (which everyone in the audience got as a gift as well) by Karthik Mani and cultural programs by the Ladakh Art and Culture Group.

Day 3 continued with some of the breakout sessions for GDEs and the remaining community sessions. It also had fun team-building activities. Post lunch we again set out for local sightseeing including the Shanti Stupa and Ladakh Palace which was very close to Ladakh market as well. End of the day 3 involved a show by Magician/Mentalist Suhani Shah and the “gala dinner”.