标签：#work

Turn Google Sheets into a Fully Interactive, Differential ACID Mutation Console for Apache Iceberg without Reverse ETL SaaS or Cloud Servers. Hero Infographic: Interactive Bidirectional Lakehouse Writeback via Google Sheets & Apache Iceberg. Enables business operators to query filtered records from an open Apache Iceberg table on Google Cloud Storage, visually edit values, add new rows, or purge obsolete records directly within a Google Sheets grid with an embedded dark-themed console, and commit atomic, microsecond-tolerant ACID mutations back to Parquet storage via BigQuery without Reverse ETL SaaS or persistent servers. Structural Analysis of the Hero Infographic: The hero infographic illustrates the complete, self-contained operational loop connecting frontline spreadsheet agility with immutable open lakehouse storage across three interconnected stages: 1. Predicate Query (Apache Iceberg Open Lakehouse on GCS) : The left section shows the enterprise analytical foundation hosted on Google Cloud Storage, where Apache Iceberg manages immutable Parquet data files, hierarchical Avro metadata, and commit snapshots. When a user requests high-value records, BigQuery acts as an on-demand distributed compute accelerator, executing SQL queries with predicate pushdown (e.g., SELECT * WHERE price > 1000 ORDER BY id ASC ) to fetch precise subsets in sub-seconds. 2. Frontline Editing in Google Sheets (Intuitive Operational Experience) : The central section features a modern, user-friendly Google Sheets grid docked with the sleek dark-themed Iceberg Lakehouse Console sidebar. A business user effortlessly modifies data on the grid with immediate visual feedback: modifying existing values (e.g., updating price from 1500 to 123 ), appending new rows with unique primary keys ( + ADD (New Row id:121) ), and deleting obsolete rows ( 🗑️ DELETE (Removed id:104) ). Native cell validation guarantees data cleanliness, while a Privacy Mode toggle ( [🔒 Privacy: ON] ) automatically masks sen

Even though networking fundamentals are often taught at the early stages of a tech career, their relevance becomes far more important when you begin working with distributed IoT and edge-driven architectures. Concepts like subnetting, routing, NAT, DNS, firewalls, and VPNs evolve from simple textbook ideas into core architectural tools that determine how devices communicate, how secure the system remains, and how reliably data moves between the edge and the cloud. This refresher looks at these fundamentals from the perspective of someone building and supporting real IoT and edge environments. The goal is not to re-teach the basics, but to reconnect them with the realities of large-scale, low-power, and cloud-connected systems. 1. Subnetting as the Backbone of IoT Network Segmentation Subnetting plays a much bigger role in IoT and edge-driven environments than most people realize. In traditional networking, subnets help organize traffic and reduce broadcast noise. In IoT, they become a core part of the system architecture. When you’re dealing with sensors, gateways, and edge compute nodes running side by side, the network must be segmented in a way that keeps each function secure and predictable. A typical LoRaWAN setup shows this clearly. The gateway LAN, the packet-forwarder network, and the edge analytics node usually sit in different subnets. This separation allows you to apply strict ACLs around what each component can communicate with, especially because IoT devices often have limited security controls of their own. Subnetting also helps manage traffic flow, ensuring that noisy sensor broadcasts don’t interfere with time-sensitive edge workloads. Beyond security, good subnet design improves fault isolation. If a node misbehaves, the impact is contained within its segment. This structure also supports multi-tenant IoT deployments, where different applications or departments share the same physical infrastructure without touching each other’s data paths. In short

Every messenger you use has a hidden dependency: a working network path to a datacenter. Drop into a basement, a packed stadium, a moving train through a tunnel, an exam hall with jammers, or a remote area with no plan, and the app is just a spinner. The people you want to reach are often standing a few meters away, but your message still has to travel to a server on another continent and back. When that path is gone, so is the app. Kabootar is my attempt to remove that dependency entirely. It is a messenger with no backend at all. Your phone forms a peer-to-peer mesh with other phones nearby, and messages hop device to device over Bluetooth and Wi-Fi until they reach the recipient. No internet, no servers, no SIM. It is built in Flutter, and the routing core is plain Dart. The core idea: delay-tolerant networking The insight that makes this work is refusing to assume the recipient is reachable right now . Normal networking is connection-oriented: open a path end to end, then send. If there is no path, there is no delivery. Kabootar instead treats the network as a delay-tolerant network (DTN). A message does not need a live end-to-end path at the moment you hit send. It needs a chain of carriers that will exist over time . You hand your message to whoever is nearby. They hold onto it, carry it as they walk around, and pass it along to the next phone they meet. Eventually a carrier bumps into the recipient and the message lands, even if that is minutes later and both you and the recipient have long since walked away. This is store-and-forward, the same shape as a durable, at-least-once message queue, except the queue is running across a swarm of phones instead of inside a datacenter. How a message actually travels The routing strategy is epidemic routing: flooding. When you send a message, it spreads to everyone in range like a rumor. Each device that receives it re-broadcasts it onward, so the message replicates through the crowd, taking every path at once. That red

The idea I wanted a small side project that could actually run itself once shipped — no cron jobs to babysit, no upstream API to go down at 3am and take my uptime with it. That constraint led somewhere specific: an API that validates common business data formats — phone numbers, IBAN, VAT/tax IDs, BIC/SWIFT codes, credit card numbers, postal codes — using nothing but offline checksum and format rules. No third-party lookups. No API keys to rotate for an upstream provider. No rate limits inherited from someone else's infrastructure. If it's slow or wrong, it's my bug, not a dependency's outage. The stack Hono on Cloudflare Workers — TypeScript, no cold starts, runs on the free tier comfortably up to 100k requests/day libphonenumber-js , ibantools , jsvat , card-validator — all well-maintained, all pure computation, zero network calls Vitest for tests, run against real fixtures (not made-up test data — every "valid" example in my test suite is a real IBAN/VAT/card number pulled from each library's own published examples, verified against the actual library output before I trusted it) The whole thing is about 300 lines of TypeScript across the router and six validator modules. Small enough to actually reason about, which mattered more to me than feature breadth. app . post ( " /v1/iban/validate " , async ( c ) => { const body = await c . req . json < { iban ?: string } > (). catch (() => null ); if ( ! body ?. iban ) { return c . json ({ error : " missing required field: iban " }, 400 ); } return c . json ( validateIban ( body . iban )); }); The part that actually surprised me I expected the code to be the hard part. It wasn't. Deploying and listing it on RapidAPI was. Two things stood out: CORS mattered even though I "shouldn't" need it. Real production traffic through RapidAPI's gateway is server-to-server — CORS is a browser-enforced concept, so I assumed it was irrelevant. But RapidAPI's own in-dashboard request tester runs as a real browser fetch, and without an O

If your AWS bill has a NAT Gateway line, you are paying twice for the same packet: once for the gateway to merely exist, and again for every gigabyte it carries. The fix for most teams is dull and free. Add an S3 and a DynamoDB gateway endpoint, route the heavy traffic away from NAT, and only then argue about anything fancier. That single change is free to turn on, takes minutes, and stops the most expensive traffic from ever touching the meter. This is a playbook, not a lecture. The trick with NAT Gateway pricing is that the two charges hide in different places on the bill, so most teams only ever see half of it. Numbers first, then the fixes, in the order I would actually do them. What you are actually being charged for NAT Gateway has two charges, and people forget the second one until they read the bill closely. Hourly charge — you pay for every hour the gateway is provisioned and available, whether or not a single byte moves through it. In us-east-1 (N. Virginia) and us-east-2 (Ohio) this is $0.045 per NAT Gateway-hour . That is roughly $32.85 a month per gateway just to keep the lights on. Partial hours bill as full hours. Data processing charge — you pay $0.045 per GB processed through the gateway, in the same region, on top of the hourly charge. This applies to every gigabyte, inbound or outbound, regardless of source or destination. And then there is the part the pricing page mentions almost in passing: standard AWS data transfer charges still apply on top. NAT processing is an extra meter on traffic you were already paying to move. The hourly charge is fixed and visible. The per-GB charge is the one that catches teams out, because it scales with traffic you mostly cannot see: package installs, container image pulls, S3 reads from private subnets, telemetry shipped out, cross-region calls. The rate varies by region (it runs higher in places like São Paulo, where both the hourly and per-GB rates sit around $0.093), so check your own region rather than trusti

Adapted from my original Japanese article , with AI-assisted translation and editing. My manager: “Test this device.” (Doesn't really know the product or the technology.) Me: “Sure.” (Also doesn't really know the product or the technology.) If you've worked in infrastructure, that may sound familiar. I'm Goda, a network engineer sharing things I learned while figuring out the job. SNMP comes up in a lot of network device testing. For a while, my idea of an SNMP test was simple: Run snmpwalk . Watch a pile of OIDs and values scroll past. Mark SNMP as working. A screen full of output is reassuring. It certainly looks like something is being monitored. Then I was asked to write a test plan for a device. I added an item along the lines of “Confirm that information can be retrieved using SNMP” and sent it for review. The feedback was: Which OIDs will you use for CPU and memory? The customer will probably ask. You should at least cover those. That was when it clicked: a successful walk and successful retrieval of the metrics we need are two different things. My other thought was, “Fine, you write the test plan, then.” But the feedback was fair. Getting something back is not the same as getting what you need. What did the successful walk actually prove? snmpwalk is useful. Net-SNMP's tool uses GETNEXT requests to walk through a subtree starting from a specified OID. Net-SNMP manual If it successfully returns values, you've established that you could read those values under those test conditions . That matters. It does not, by itself, establish that your CPU and memory monitoring requirements are satisfied, or that every required OID is available. I had been treating a successful command as a much broader result than it actually was. Break “SNMP testing” into specific checks Today, I'd separate at least these questions: Question What to check Can I communicate over SNMP? Whether the device responds to the intended request under the defined conditions Can I monitor CPU? The

Yash K Saini — Engineer, building in public — AI/ML, low-level (Rust/C/C++), and open source. GitHub...

One directory is the task manager my agents share was the most-read thing I have published, and it left out the part that matters most: who works the queue. For the first month the honest answer was mostly me. The nightly run drained a few entries, and every mechanical finding, a drifted git hook, a dependency advisory, a stale path, still waited for me to notice it and route it. I counted one day's commits: 68 across eight repos, about 48 of them the fleet maintaining itself with me as the router. The queue routed work. Nothing routed time. So the fleet maintains itself now, in four moves. Detection files its own work. Every night the deterministic lenses sweep every repo and file an allowlisted set of finding classes straight into the queue, through the same atomic door a session uses. The allowlist is the whole design: a stale gate, a test that runs only in CI, a dead path, a tool behind its pack. Judgment classes stay out. A file over budget is an editorial call, a missing contract gets authored, anything the sweep marks as risk is a ruling. A wrong work order costs more than a report line. Progress is measured on the contract, never on commits. The first version of the night loop counted a round as productive when the child committed. The benchmark night showed why that is the wrong delta: eleven of fifteen spawns committed, six of them the same appended paragraph, while the entry each was spawned for never moved. A round is fruitless per entry now: workable at child start, still pending and workable at child exit. An entry that takes fruitless rounds on three distinct nights is parked as needing me, with a note, through the door's own verb. A lease a dead child left behind is reaped at the start of the next run. The night converges on queue state instead of spinning on it. night 1 pending ──child──▶ pending fruitless: 1 night 2 pending ──child──▶ pending fruitless: 2 night 3 pending ──child──▶ pending fruitless: 3 ──▶ needs: owner one line in the brief, one ba

Ev Ağı Nasıl Çalışır? Bir ev ağını en basit haliyle şöyle düşünebiliriz: Internet │ ISP ağı │ Ev Router'ı │ ┌─────────────┼─────────────┐ │ │ │ Laptop Telefon NAS Ev router'ı burada iki farklı dünyayı birbirine bağlar: ISP üzerinden ulaştığı dış ağ ve evdeki cihazların bulunduğu yerel ağ. Bu basit topolojinin arkasında LAN, WAN, subnet, DHCP, routing, NAT, firewall, bridge ve VLAN gibi kavramlar birlikte çalışır. 1. Ev ağı, ISP ve internet tarafı LAN ve WAN LAN — Local Area Network , router'ın yerel ağ tarafıdır. Evdeki laptop, telefon, NAS, televizyon gibi cihazlar genellikle bu tarafta bulunur. Örneğin router'ın LAN adresi: 192.168.1.1/24 olsun. Cihazlar da: Laptop 192.168.1.20 Telefon 192.168.1.30 NAS 192.168.1.50 adreslerini kullanabilir. Bunların tamamı aynı: 192.168.1.0/24 yerel IP ağına aittir. WAN — Wide Area Network ise router'ın kendi yerel ağı dışındaki bir upstream ağa bağlandığı taraftır. Tipik bir evde: Internet / ISP │ WAN │ Router │ LAN │ Ev cihazları şeklinde görünür. LAN ve WAN, Ethernet kablosunun fiziksel türünü tanımlamaz. Aynı standart Ethernet bağlantısı bir router için LAN, başka bir router için WAN rolünde olabilir. Örneğin: Internet │ Upstream Router LAN: 192.168.1.1 │ │ Ethernet ▼ Downstream Router WAN: 192.168.1.50 LAN: 192.168.10.1 Buradaki 192.168.1.0/24 ağı: upstream router açısından LAN, downstream router açısından WAN tarafıdır. Dolayısıyla LAN ve WAN kavramları hangi router açısından baktığımıza göre anlam kazanır . Upstream ve downstream Ağda internet veya daha üstteki ağa doğru olan yön upstream , son kullanıcı cihazlarına doğru olan yön ise downstream olarak adlandırılır. Internet │ Upstream Router │ Downstream Router │ Laptop Downstream router'ın internete doğru bağlandığı router onun upstream router'ıdır. Bu terminoloji özellikle evde bir modem/router arkasına ikinci bir router bağlandığında kullanışlı hale gelir. ISP'nin rolü ISP — Internet Service Provider , ev ağını daha büyük internet altyapısına bağlayan servis sağlayıcıdı

In this podcast, Shane Hastie, Lead Editor for Culture & Methods, spoke to Adam Wachtel, CTO at Click Boarding, about hiring for personality and problem-solving over pure skillset, turning around a platform and team in crisis, and how AI is reshaping team size and composition without ending SAAS. By Adam Wachtel

When building an online game in Unity, the question is often framed as: Should I use Photon, Netcode for GameObjects, FishNet, or Mirror? That question is too small. In 2026, there is still no single networking product that is optimal for every Unity game. The real decision is a stack : transport, netcode, authority model, session management, server hosting, and backend services. For a GameObject-based action game that needs client prediction, Photon Fusion 2.1 is a strong first PoC baseline . If your priorities are Unity Gaming Services, DOTS/ECS, self-hosting, source access, or deterministic simulation, the starting point changes. This article explains how to make that decision in production terms: latency, cheating, reconnection, hosting, bandwidth, operations, and total cost. This article uses official documentation checked on August 31, 2026 as its factual baseline. SDK versions, pricing, licensing, and service availability can change, so re-check them before committing a production project. What I mean by a real-time multiplayer game The target is roughly this class of game: 2–32 players in the same session continuously synchronized players, enemies, projectiles, or interactable objects input latency that directly affects game feel reconnects, host loss, and late joining that must be handled co-op action, FPS/TPS, racing, or competitive action If you only need turn-based play, leaderboards, chat, friends, or asynchronous PvP, you may not need a sophisticated state-synchronization netcode at all. A backend such as Nakama, PlayFab, or Unity Gaming Services may be the more important part of the architecture. Do not treat “networking” as one product A production multiplayer stack has at least five layers. Layer Responsibility Examples Transport Packet delivery, reliability, connection path, secure channel integration Unity Transport, Photon transport, UDP/WebSocket-based transports Netcode Replication, RPCs, input, prediction, interpolation, rollback Fusion, NGO,

Users can search for emails or draft documents using the new conversational feature

The acquisition also leaves Sequoia-backed Serval as the de facto startup leader in AI IT service automation, industry watchers believe.

A startup called Mostik has a wild new approach to combining the capabilities of AI models.

I spent years supporting WorkMail and SES at AWS, and even became a Subject Matter Expert in both services. Here's how I moved my own mail off it, start to finish... and got sentimental doing it. Level: 200 (intermediate). Assumes you're comfortable with the AWS CLI, IAM roles, S3, and KMS. Amazon WorkMail is winding down... AWS has announced end of support for March 31, 2027. If you're running a mailbox or two on WorkMail, now is a good time to think about where that mail is going to live next. In my case, I'm moving my domain's mail over to Google Workspace, and I wanted to bring years of old email along for the ride. I'll be straight with you up front, though... this one's personal, and writing a guide to leave WorkMail behind is genuinely bittersweet. I'll get into why at the end... but first, let's do the work. Here's the important part... WorkMail gives you a clean, supported way to get your mail out: the StartMailboxExportJob API. It drops every message into an S3 bucket as a KMS-encrypted .zip of standard .eml files. From there, getting those messages into Gmail is just a matter of speaking IMAP. In this post, we're going to walk through the whole path... exporting the mailbox, wiring up the IAM and KMS pieces the export needs, downloading and inspecting the archive, uploading everything into Gmail with a small Python script, bringing the calendar over, tearing WorkMail down when you're done, and finally locking the domain down with SPF, DKIM, and DMARC so your new Gmail-hosted mail actually lands. Along the way I'll call out the gotchas that cost me time, so they don't cost you any. The shape of the solution Before we touch a command, let's set the mental model. There are two halves to this migration: Get the mail out of WorkMail. StartMailboxExportJob writes an encrypted .zip to S3. This needs a KMS key and an IAM role the WorkMail export service can assume. Get the mail into Gmail. Gmail speaks IMAP, and IMAP has an APPEND command that uploads a raw messa

Christopher was sick of being ghosted by AI recruiters. So he unleashed ChatGPT on his robot interviewer.

Upgrading Juniper MX Networks from 100GbE to 400GbE: What Engineers Need to Know Moving a production network from 100 Gigabit Ethernet to 400 Gigabit Ethernet sounds simple on paper: Replace a 100G interface with a 400G interface and get four times the bandwidth. In a real carrier or data-center network, however, the interface is only one part of the equation. The router's forwarding silicon, switch fabric, midplane, power system, cooling, optics, software release, slot selection, redundancy configuration, and licensing can all determine whether the expected capacity is actually available. Juniper's MX240, MX480, and MX960 platforms provide an interesting example because these systems can be upgraded with newer generations of Modular Port Concentrators rather than requiring an immediate chassis replacement. One particularly useful case study is the Juniper MPC10E-15C , a Trio 5-based line card capable of supporting both 100GbE and 400GbE interfaces. This article isn't about whether you should buy a particular line card. Instead, we'll use the MPC10E-15C to examine the engineering questions that should be answered before attempting a 100G-to-400G upgrade on an existing Juniper MX network. Video Overview The video provides a short overview of the hardware. Below, we'll go deeper into the architecture and the deployment considerations that matter when integrating this class of line card into an existing MX environment. Why Moving from 100G to 400G Isn't Just a Port Upgrade Suppose an edge router has four heavily utilized 100GbE connections. At first glance, replacing those links with 400GbE interfaces appears straightforward. But consider what happens behind the physical port. Traffic entering that 400G interface must travel through several parts of the system: Interface → Packet Forwarding Engine → Fabric → Other line cards/interfaces Every component in that path needs sufficient capacity. A 400GbE optic connected to a router that cannot move 400 Gbps through its inte

Swiggy developed an in house predicted lifetime value model using more than 350 pre order features and a multi task MLP for Food and Instamart. Adding order count as an auxiliary task reduced model parameters by 63% while improving predictive performance. The pLTV signal is used with Google Target ROAS bidding to optimize customer acquisition. By Leela Kumili

Hello, I'm Maneshwar, and I'm building LiveReview — a blast-radius aware AI code review built for your business-critical systems. Star us to help devs discover the project, give it a try, and share your feedback to help improve the product. You open a video and it starts playing in about a second. Somewhere between your thumb and that first frame, your request crossed maybe fifteen different companies' equipment, possibly an ocean, and came back. Nobody coordinated it. That is the part I find genuinely strange about the internet, and it is the part most explanations skip. They tell you the internet is "a global network of networks", which is true and tells you nothing. So let's actually take it apart. There is no internet. There are 75,000 of them. The single most useful thing to understand up front: the internet is not a thing anyone built. It is roughly 75,000 independent networks that agreed on how to hand traffic to each other. Your ISP is one. Your university is one. Cloudflare is one. They own their own cables and routers, they answer to nobody in particular, and they interconnect voluntarily. Once you see it that way, every weird thing about the internet starts making sense. The whole arrangement has three parts: The edge is everything that actually wants to say something. Your phone, a laptop, a server in a rack, and increasingly a doorbell. These are called hosts or end systems , and they split roughly into clients that ask and servers that answer. The access network is your on-ramp. Fibre or cable at home, the office network, 5G from your pocket. Its only job is getting you to the first router. It is also, almost always, the slowest part of the entire journey, which is worth remembering next time you blame a website for being slow. The core is the mesh in the middle. Routers and the links between them, and nothing else. No control room, no master server, no company that owns it. Nobody reserved you a line Here is where the design gets clever. Before the in

Last week I deleted a function that had been "documented" by a comment explaining a behavior the function hadn't had in three versions. The comment was confident. The function was gone. This is the real failure mode of AI-generated docs: they can be fluent, plausible, and wrong. Not because the model is bad, but because no human verified what the text claims. The fix isn't to avoid AI. It's to build a checkpoint where the model drafts and the human signs off. The Ownership Split A model can summarize code, describe parameters, and turn commit messages into release notes. It cannot know why a decision was made, which edge cases are career-ending, or which comments are now dangerous. My rule of thumb: The model drafts: API descriptions, usage examples, parameter tables, changelog bullets from git history. A human owns: security implications, business rules, architectural trade-offs, deprecation warnings, anything tied to customer promises. The pipeline below makes that split explicit. It generates a draft, then forces a review issue with a checklist that separates the two categories. The Pipeline I run this as a GitHub Actions workflow on every merged PR that touches src/ . It takes the diff, sends it to a language model with a strict output schema, and opens a documentation review issue. Here's a condensed version of the workflow YAML: name : docs-draft on : pull_request : types : [ closed ] branches : [ main ] jobs : draft : runs-on : ubuntu-latest steps : - uses : actions/checkout@v4 with : fetch-depth : 0 - name : Generate doc draft env : API_BASE : ${{ secrets.MONKEYCODE_API_BASE }} API_KEY : ${{ secrets.MONKEYCODE_API_KEY }} run : | git diff origin/main HEAD -- src/ > diff.txt python draft_docs.py diff.txt - name : Open review issue uses : actions/github-script@v7 with : script : | const body = require('fs').readFileSync('review_body.md', 'utf8') await github.rest.issues.create({ owner: context.repo.owner, repo: context.repo.repo, title: `Docs review: ${context.