今日已更新 344 条资讯 | 累计 37249 条内容
关于我们

标签:#Google

找到 513 篇相关文章

AI 资讯

Progressive cluster upgrades at scale: A technical guide to GKE rollout sequencing with custom stages

Upgrading Kubernetes clusters across a large enterprise fleet is often a balancing act between staying current with security patches and avoiding outages. By default, Google Kubernetes Engine (GKE) rolls out automatic upgrades progressively according to Google Cloud regional timelines. While regional rollout works well for standalone clusters, it does not understand your organization's business topology. If you run staging clusters in us-central1 and critical production clusters in us-east1 , a standard regional rollout could upgrade your production environment before your pre-production validation completes. The General Availability (GA) release of GKE rollout sequencing with custom stages solves this challenge. It provides platform teams with declarative control to sequence cluster upgrades across fleets, environments, and even distinct Google Cloud organizations according to business criticality rather than cloud geography. How rollout sequencing works Rollout sequencing builds on GKE fleet management. Fleets serve as logical boundaries for environments such as development, staging, and production. With rollout sequencing, you define an ordered pipeline of upgrade stages managed by a central resource called RolloutSequence . When GKE publishes a new automatic upgrade target for a release channel, or when you explicitly trigger a target version, the system creates a Rollout object. This rollout progresses through your defined stages sequentially: Control plane upgrades start in the first stage. Once all control planes in that stage reach the target version, a stage soak timer begins. Node upgrades run in parallel with control plane upgrades, respecting node pool upgrade strategies such as surge or blue-green. When both control planes and nodes complete their upgrade and satisfy the configured soak duration, the rollout advances to the next stage in the sequence. If an individual stage contains clusters that take longer than 30 days to finish upgrading—due to restr

2026-08-27 原文 →
AI 资讯

How I Built a Serverless AI Accounting App with AI assistant and Saved My Family from Spreadsheet Chaos

Link to the Source Code As a data engineer, I spend my days designing clean, optimized data structures. But at home, I face a much tougher crowd: my family. We manage our shared finances together to optimize our budget, and because of where we live and work, we have to do this in several different currencies (like USD, EUR, CZK, and UAH) Like any developer, I first tried to find a ready-made app to solve this. But I ran into a classic problem: they were either bloated with a million features we didn’t care about, or they were missing the exact features we actually needed. So, we did what any desperate family does: we opened a Google Sheet . We tracked our money there for a while, not because it was perfect, but because it helped us figure out what we actually needed from a real application. It was our "living schema design" before I wrote a single line of code. In this article, I want to show you how I looked at this problem from two sides—as a frustrated user who just wants to log expenses, and as a data engineer obsessed with clean database design. Here is the story of how I built our custom home accounting server. Part 1: Django, a Star Schema, and the Framework Battle By 2025, I was ready to replace our Google Sheet. My main programming language is Python, so I had three realistic choices: FastAPI, Flask, or Django. FastAPI is the cool kid on the block for high-speed APIs, but we didn’t expect millions of requests (unless my family suddenly grew by a factor of a million). We also needed a friendly web UI, which FastAPI isn't naturally built for. I had just used Flask for my previous project, but I wanted to challenge myself and learn something new. Django felt like an old friend I hadn't seen in years. It has amazing built-in tools (like the admin panel and great translation support), and using it was the perfect way to refresh my skills and grow as a developer. The Database: Why a "Star Schema" Actually Makes Sense As a data engineer, I didn’t want a messy data

2026-08-27 原文 →
AI 资讯

My Cloud Run Multi-Agent Fleet Passed Its Demo. The Architecture Was Still Wrong.

The correlation notice fired. Three sites, same anomaly type, inside the time window. The orchestrator caught it and logged it, live, against the deployed service. Clean, first try. Then I asked myself a question I almost didn't bother asking, because the thing had just worked: why did it work? The answer wasn't "because the logic is correct." It was "because Cloud Run happened to route both requests to the same running instance." Well, shit. My orchestrator was holding its list of recent risk events in a plain Python list, in process memory. Worked in local testing because there's only one process. Worked live because Cloud Run, under light traffic, often reuses the same instance instead of spinning up a second one. Neither one's a guarantee. The moment traffic patterns shifted and two readings landed on two different instances, the second instance wouldn't have a clue the first one existed. A correlation that should fire would just silently not. A bug that passes its own demo is the hardest kind to catch. There's no error to chase. There's just a checkmark. What I was building VES Fleet is a network of independent site-agents (Bori, Choba, Etche, three real survey sites in the Niger Delta). Each one reads an underground electrical survey, send current into the ground, measure how it flows back, a real physical signal of what's down there, and calibrates its own contamination-risk threshold from its own site's real history. Not a number copied from anywhere else. An orchestrator watches for the same risk signature showing up at more than one site inside a time window. It's my submission to the Fortified Enterprise Fleet track of Google's All Things Agentic Hackathon. Architectural discipline is 30% of the score there. Proving it actually runs on Google Cloud is a separate 30%. So a bug that only looked fixed was never going to survive someone actually reading the state-management story. Checking the thing that already worked Once I understood the actual failure mod

2026-08-26 原文 →
AI 资讯

Building a Data Trust Score Engine on Google Cloud with BigQuery, Data Catalog & Vertex AI

Data has become one of the most valuable assets for modern enterprises, powering everything from business intelligence dashboards to machine learning models and generative AI applications. However, the biggest challenge organizations face today is not collecting data — it is trusting it. Enterprise data often contains duplicate records, missing values, inconsistent schemas, outdated information, and inaccurate entries that silently reduce the quality of analytics and AI predictions. These hidden data quality issues can lead to poor business decisions, increased operational costs, compliance risks, and unreliable AI outcomes. While most organizations implement basic validation rules, traditional data quality frameworks are largely rule-based, difficult to maintain, and unable to detect complex anomalies that continuously evolve across modern cloud data platforms. This article introduces the Data Trust Score Engine, an AI-powered cloud-native solution designed to automatically measure and improve enterprise data reliability. Instead of relying solely on manual validation or predefined rules, the platform combines metadata intelligence, large-scale analytics, and machine learning to calculate a dynamic Trust Score (0–100) for every dataset. The score is generated by evaluating multiple quality dimensions, including data completeness, consistency, uniqueness, freshness, schema compliance, null-value distribution, statistical anomalies, and AI-detected outliers. As a result, organizations can quickly identify fake, duplicate, corrupted, or low-quality datasets before they impact reporting, business intelligence, or downstream AI models. Learn about Medium’s values The solution is built entirely on Google Cloud Platform (GCP) using BigQuery as the scalable analytical data warehouse, Data Catalog for centralized metadata management and governance, and Vertex AI for intelligent anomaly detection and predictive quality analysis. BigQuery processes billions of records efficie

2026-08-25 原文 →
开发者

Android is getting its own weird dots to cure car sickness

Google is rolling out a new Android feature that's been proven to reduce, or even eliminate, motion sickness when using a phone inside a moving vehicle. Dubbed Motion Assist by Google, it's very similar to Apple's Motion Cues, first introduced in 2024. The Android 17 feature appears to be rolling out in phases, with some […]

2026-08-25 原文 →
AI 资讯

De-Googled GrapheneOS is coming to Motorola’s foldables next year

GrapheneOS, an open source version of Android that prioritizes security and privacy, has detailed its plans for supporting Motorola smartphones. Official support is set to arrive next year, starting with traditional flagships, before rolling out to Motorola's foldable phones and perhaps cheaper models, eventually. In a Mastodon thread, the GrapheneOS Foundation announced that it will […]

2026-08-24 原文 →
开发者

How to Build a Real-Time Google Docs for Code

What happens when two developers edit the EXACT same line of code at the EXACT same millisecond? Race conditions, overwritten data, and a crashed server. Today, we’re tearing down the magic behind Figma and Google Docs to build a real-time collaborative code editor using Next.js 16 and CRDTs ⏱️ CHAPTER 1: The Collaborative Text Editing Trap "Building a single-user code editor is simple: a React state variable, a text area, and a save button.But the moment two developers open that same code file at the exact same millisecond... everything breaks. User A types a function name at index 5, while User B deletes a line at index 2. If you simply push text updates to a database over HTTP, you get catastrophic race conditions, overwritten code, and cursor teleportation.So, how do platforms like Google Docs, Figma, and Replit allow thousands of users to type simultaneously in real-time without locking files or destroying data? Welcome back to Behind the Abstraction. Today, we’re building a real-time collaborative code editor using Next.js 16. We’ll strip away the magic of real-time state, compare Operational Transformation vs CRDTs, and implement WebSocket edge routing using modern Full-Stack architecture." ⏱️ CHAPTER 2: OT vs CRDTs - The Core Math of Real-Time "Before writing a single line of Next.js code, we must solve a fundamental computer science problem: Mathematical Consistency across Distributed Systems.There are two primary ways to resolve typing conflicts: Operational Transformation (OT): Used by classic Google Docs. Every keypress sends an 'operation' (like Insert "a" at index 10) to a central server. The server acts as the absolute referee, transforming index positions and broadcasting the fix back to all clients. The Problem: Centralized OT servers are complex, memory-heavy, and difficult to scale horizontally at the Edge. CRDTs (Conflict-free Replicated Data Types): Used by modern tools like Figma and VS Code Live Share. Instead of raw array indexes, every chara

2026-08-23 原文 →
AI 资讯

Building an Escalation Root-Cause Agent with Gemini and ADK

Gen AI Academy APAC — Track 1 (AI Agents with Gemini, ADK, and Cloud Run) Why I built this I lead a customer service team of 25 agents at Amazon, handling both buyer-side and marketplace seller support. A big part of my job is reviewing escalated cases — calls or chats where a customer asked for a supervisor — and figuring out why they escalated in the first place. Was it a policy gap? A training issue? A system limitation nobody flagged? Right now, that review is manual. Every escalation gets read, tagged, and turned into a coaching note by a human — usually me, or one of my leads. It works, but it doesn't scale well, and patterns across dozens of cases are easy to miss when you're reviewing them one at a time between everything else on your plate. So for Track 1 of the Gen AI Academy APAC program, I built an agent that does the first pass of this analysis automatically: read an escalation summary, classify the root cause against a standard taxonomy, flag whether it looks like a repeat pattern, and draft a coaching note — the same way I would, just faster and more consistently. What it does The agent takes a case summary like this: Customer requested a refund for a damaged item outside the standard return window. Agent denied it citing policy; customer says a rep last month approved a similar exception for someone else. And returns a structured analysis: { "root_cause_category" : "policy_misapplication" , "severity" : "medium" , "is_likely_repeat_pattern" : true , "pattern_reasoning" : "Inconsistent policy application across agents suggests a training or documentation gap rather than an isolated error." , "coaching_note" : "..." } It's built on Google's Agent Development Kit (ADK) with Gemini as the underlying model, and deployed as a live service on Cloud Run . The agent has one tool — a lookup function for the standard root-cause taxonomy — which keeps the categories consistent and easy to update without touching the core prompt. For batch review, I also built a

2026-08-22 原文 →