AI 资讯

Modern cloud-native developer environments are fantastic. Frameworks like .NET Aspire have revolutionized local development by providing a unified developer dashboard, automatic service discovery, and OTLP telemetry collection. But what happens when it's time to deploy your microservice topology on-premises? If your target is IIS on Windows Server or a systemd service on Linux , you've likely realized that deploying the standard .NET Aspire stack on-prem is a complex puzzle. There is no native hosting model for IIS, gRPC telemetry port mapping is fragile, and the dashboard's constant WebSocket connections can consume excessive resources on on-premises virtual machines. Enter AppPipe.Hosting —a lightweight, developer-friendly NuGet package designed specifically to bring the best features of .NET Aspire to your on-premises environments. The Problem: On-Premises Microservice Orchestration is Hard While cloud platforms have native orchestration (like Kubernetes or ECS), traditional Windows and Linux environments still host a massive volume of enterprise applications. When running microservices on IIS or Linux servers, developers face three major friction points: Port Conflicts & Service Discovery : Dynamically assigning ports to multiple microservices in IIS or systemd and injecting them into dependent services is tedious. Telemetry Aggregation : Running an OpenTelemetry Collector just to aggregate traces, logs, and metrics for a small on-prem cluster is heavy and complex to configure. Resource Exhaustion : Standard Blazor Interactive Server dashboards maintain constant WebSockets and high memory usage, which quickly drains limited hosting environments. The Solution: AppPipe AppPipe is a lightweight alternative that integrates a routing gateway, an in-memory telemetry store, and a visual dashboard directly into a single library. graph TD Client(Browser/Client) -->|HTTP| Gateway subgraph User's Application Space Backend1[Backend Microservice A] Backend2[Backend Microserv

Hey DEV community! 👋 How many times a day do you need to format a messy JSON string, convert a CSV file, or parse a timestamp? And how many times do you find yourself pasting that data—which might contain API keys, user emails, or proprietary code—into a random website you found on Google? We’ve all done it, but in an era of constant data leaks, it’s a massive security risk. That’s exactly why I built Parsify . What is Parsify? Parsify is an all-in-one data converter and developer toolset designed to handle your daily formatting, parsing, and data manipulation tasks completely offline and client-side. No servers, no tracking, and absolutely no data leaks. Everything happens right inside your browser sandbox. 🚀 Key Features 100% Secure & Offline: Your data never leaves your local machine. Once the page loads, you can literally pull your internet plug and it will still work perfectly. All-in-One Toolkit: No more bookmarking ten different sites for ten different tasks. From JSON formatting and base64 encoding to data conversions, it’s all under one roof. Built for Speed: A clean, lightning-fast UI with batch-processing support to keep your workflow uninterrupted. Privacy by Design: Zero tracking scripts, zero ads, and zero database logging. Why I Built It Most online utilities are bloated with tracking pixels, pop-up ads, and cookies. Worse, you have no idea what happens to the data you paste into their input fields. As a developer, I wanted a tool that felt like a local desktop app but possessed the accessibility of a web app. Parsify is the bridge. It gives you the convenience of a web utility with the strict security boundaries of local execution. Check It Out (It's Free!) If you’re tired of compromising on data privacy for quick utilities, give it a spin: 👉 parsify.tools I’m actively working on adding more tools and converters to the suite. I would absolutely love to get the DEV community's feedback! What converters or formatting utilities do you use daily that you

Contacts are messier than they look. A user's real address book is spread across the people they've saved by hand, the people they've emailed often enough that the provider auto-collected them, and the colleagues in their company directory. Google exposes these through the People API; Microsoft through Graph; both model the data differently and split it across sources you have to query separately. The Nylas Contacts API unifies all of that behind one schema and one grant_id . You read saved contacts, auto-collected contacts, and directory contacts through the same endpoint, create and update entries that sync back to the provider, and organize them into groups. This post walks the contact surface from the HTTP API and the Nylas CLI , which mirrors every operation for terminal use. I work on the CLI, so the terminal commands below are the ones I run when I'm exploring an address book. The contact model and its three sources A contact in Nylas carries the fields you'd expect — given_name , surname , emails , phone_numbers , company_name , job_title , notes — plus richer ones like im_addresses , physical_addresses , and web_pages . The schema is the same across providers, so a Google contact and a Microsoft contact deserialize into one struct. The detail that trips people up is source . Every contact has one of three sources, and they mean very different things: address_book — contacts the user saved deliberately. This is the real address book. inbox — contacts the provider auto-collected because the user emailed them. These were never explicitly saved. domain — contacts from the organization's directory (coworkers). Knowing the source matters because "all contacts" usually isn't what you want. If you're building a contact picker, the inbox source can flood it with one-off recipients the user doesn't think of as contacts. Filter by source deliberately. See the Contacts API overview for the full data model. Before you begin You need a Nylas API key and a connected accou

Meeting notes are the feature everyone wants and nobody wants to build. The hard part isn't the summary — an LLM handles that. The hard part is getting into the meeting: a bot that joins Zoom, Google Meet, and Microsoft Teams, survives each platform's waiting room and admission flow, records cleanly, and produces a transcript you can feed downstream. Each provider has its own join mechanics, and none of them ships a tidy "record this meeting" API. The Nylas Notetaker API is that bot as a service. You point it at a meeting link, it joins on schedule, records, and generates a transcript, and you fetch the recording and transcript through one endpoint. This post walks the Notetaker surface from the HTTP API and the Nylas CLI , which mirrors the whole lifecycle for terminal use and quick testing. I work on the CLI, so the terminal commands below are exactly what I run when I'm testing a notetaker against a live meeting. Two ways to run a notetaker: grant-scoped or standalone Before any code, there's one architectural choice worth understanding, because it changes the endpoint you call. A grant-scoped notetaker is tied to a connected account and lives under /v3/grants/{grant_id}/notetakers . Use it when the bot acts on behalf of a specific user — it can read that user's calendar and join their meetings as them. A standalone notetaker has no grant at all and lives under /v3/notetakers . You hand it a raw meeting link and it joins, no connected account required. This is the one to reach for when you just have a URL and want a recording — a public webinar, a meeting on an account you haven't connected, or a system that deals in links rather than users. Same request body, same lifecycle, same media output; the only difference is whether there's a grant_id in the path. See the Notetaker overview for how both models fit together. Before you begin You need a Nylas API key. If you're using a grant-scoped notetaker you also need a connected account; for standalone, the API key al

If your integration polls Nylas every minute to check for new email, you're doing too much work and still getting stale data. Polling is a tax: you burn rate limit on requests that mostly return nothing, and a message that arrives at 12:00:05 doesn't reach your app until the next poll. Webhooks flip that around. Nylas pushes a notification to your endpoint the moment something happens — a message arrives, an event changes, a contact is created — and your app reacts in real time. This post walks the webhook surface from both sides: the HTTP API that registers and manages webhooks, and the Nylas CLI , which has genuinely useful tooling for the part everyone gets stuck on — verifying signatures and testing webhooks against local code. I work on the CLI, so the terminal commands below are the ones I run when I'm wiring up a webhook receiver. Triggers and destinations A webhook has two halves: the trigger types it listens for and the destination URL it pushes to. Trigger types are dotted event names like message.created , event.updated , and contact.created , grouped into categories — grant, message, thread, event, contact, calendar, folder, and notetaker. You subscribe one destination to as many triggers as you want. The CLI lists every available trigger so you don't have to guess the names: # All trigger types nylas webhook triggers # Only message-related triggers nylas webhook triggers --category message Webhooks are application-scoped, not grant-scoped: one webhook registered on your application receives notifications for every connected account, identified by the grant_id in each payload. See the notifications overview for the full event model. Before you begin You need a Nylas API key — webhook management is admin-level, so it uses the application's API key rather than a grant. You also need an HTTPS endpoint reachable from the public internet to receive the notifications. The CLI gets the key set up: nylas init # create an account, generate an API key For local de

Scheduling features look simple until you build them. Google Calendar speaks its own REST API with events.insert ; Microsoft 365 wants Graph and POST /me/calendar/events ; Apple and a long tail of providers expect CalDAV. The moment your app needs to read a user's events, drop a meeting on their calendar, or check whether three people are free at 2pm, you're staring down three integrations that disagree on field names, time formats, and recurrence rules. The Nylas Calendar API gives you one interface over all of them. Connect a user's account once, get a grant_id , and read calendars, manage events, send RSVPs, and compute free/busy with the same request shape whether the backing provider is Google or Microsoft. This post walks the calendar surface from both sides: the HTTP API your backend calls, and the Nylas CLI for testing the same operations in a terminal. I work on the CLI, so the terminal snippets below are the commands I actually run when I'm poking at a calendar. Calendars, events, and the calendar_id A connected account has one or more calendars , and every event belongs to exactly one of them. Most operations take a calendar_id , and the special value primary resolves to the account's default calendar — so you don't need to look up an ID to act on the main calendar. One exception: iCloud doesn't support primary , so for iCloud accounts you pass a real calendar ID from nylas calendar list . An event carries a title , a when object holding its start and end times, a list of participants , an optional location , and flags like busy . That schema is identical across providers, which is the whole point: you read a Google event and a Microsoft event into the same struct. See the Calendar API overview for how calendars, events, and availability fit together. Before you begin You need a Nylas API key and a connected account with calendar scopes. The CLI gets you there in two commands: nylas init # create an account, generate an API key nylas auth login # connect

Over the course of a few posts, I will be constructing an NES emulator that will allow you to play NES ROMs. Today’s post is the first in this series, where I will be walking through the process of emulating the CPU the NES used, the MOS 6502. STRUCTURE The 6502 has 6 primary registers we need to emulate in our program. The A register is the accumulator, which is 1 byte long The X register is an index register, which is also 1 byte long The Y register is another index register, also 1 byte long The Program Counter is 2 bytes long, allowing for accessing 65536 memory locations The Stack Pointer is 1 byte long, allowing a 256 byte stack The P register is a status register that is 1 byte long, containing the CPU status flags Below is the struct I used for the 6502 typedef struct { uint8_t A ; uint8_t X ; uint8_t Y ; uint16_t pc ; uint8_t S ; uint8_t P ; } cpu_6502 ; MEMORY The 6502 can read up to 64kb of memory thanks to the 2 byte long program counter. For my implementation, the memory is just a simple uint8_t array declared like so: uint8_t memory[65536] = {0}; This just implements an array of 65536 bytes that we will load programs into, that the CPU will then step through. However, we need to have a function that is able to decode the commands. OPCODES An opcode (operation code) is a number that represents an instruction for the CPU. The 6502 has 56 distinct (useful) opcodes I will be emulating today. A full list of the opcodes can be found in this handy little table. Since there are so many opcodes, I will not go through them all. The full code can be found in my GitHub repo here: https://github.com/benjaminavachon/6502-emulator Here we can discuss a few of the operations so you can get a feel for what they do. The first one we will discuss is very simple. It is LDA; it simply loads the piece of data after the opcode stored in memory into the A register and increments the program counter to the next memory address. A simple example of this would be: LDA 0x05 This i

Whether you're brand new to Power BI or just getting started with data analytics, this guide walks you through everything you need to know about data modeling — from how tables connect, to the schemas that make your reports fast and reliable. What Is Data Modeling in Power BI? Imagine you have three spreadsheets: one with your customers , one with your products , and one with your sales transactions . Individually, each table tells you something. But together, they can tell you which customer bought which product, when, and for how much . That's exactly what data modeling is: the process of organizing your data tables and defining how they relate to each other so Power BI can combine them into meaningful reports and dashboards. A data model in Power BI has three core building blocks: Tables — your data sources (Excel files, databases, CSVs, cloud services, etc.) Relationships — the links between tables that tell Power BI how data connects Measures & Calculations — formulas (in DAX) that compute totals, averages, and other insights A well-designed data model is the difference between a report that loads in seconds and one that takes forever. It's also what keeps your numbers accurate and your dashboards easy to use. Why Does Data Modeling Matter? Here's a simple analogy: a city without roads is just a collection of buildings. Data modeling is the road system that lets you travel between your tables. Without a good data model: Your visuals may show incorrect or duplicated numbers Filters in one chart won't affect another Reports will be slow and hard to maintain With a good data model: Clicking on a customer in one visual automatically filters every other visual Calculations are accurate and consistent You can easily add new data sources without rebuilding everything Types of Tables: Facts vs. Dimensions Before diving into schemas and relationships, you need to understand the two types of tables that make up most Power BI models. Fact Tables A Fact table stores the ev

Half a year ago I asked a simple question: during an online call, could a short, to-the-point hint appear on my screen in a second or two — while the other person is still talking? Not an after-the-fact transcript, but help in the moment. The result is a desktop assistant (macOS + Windows). Below is an honest breakdown of what turned out to be hard, and which solutions worked. Engineering only, no marketing. Architecture in one paragraph On the device there are only two things: audio capture and a thin UI overlay. All the "brains" (provider keys, prompts, model selection) live on the server. The client gets a short-lived per-session token and streams audio; the server returns the transcript and the generated answer. I picked this split not for "security theater" but because otherwise keys and prompts would have to be baked into the binary — and both leak instantly. Hard part #1: system audio, not the microphone The mic only captures you. You need the other party's audio — i.e. the system output. And that's where the platform pain starts: macOS. For a long time there was no native "give me system audio" API; the classic path was a virtual audio device (BlackHole/Soundflower-style) or, in recent versions, ScreenCaptureKit, which can hand you a process's audio. ScreenCaptureKit turned out to be the best option: no kernel extensions for the user to install. Windows. WASAPI loopback saves you — you can grab whatever is going to the output device, without virtual cables. Takeaway: "system audio capture" is not one feature but two different subsystems for two OSes, and most of the early bugs were about permissions and device selection, not about audio itself. Hard part #2: latency is everything A hint that arrives 6 seconds late is useless — the conversation has already moved on. The latency budget has three parts: STT (speech → text). Streaming only. Batch "recognize after the phrase ends" immediately adds 1–2 seconds. The key metrics weren't "overall accuracy on a benchm

If you're building a SaaS AI agent product and you're already on Kinde, you already know the problem. Mastra is the TypeScript-first AI agent framework. It ships with official auth providers for Clerk, Auth0, Supabase, Firebase, WorkOS, and Better Auth. Kinde is not on that list. The obvious question is why not reach for one of those providers, since Auth0 is already there. Most developers who choose Kinde rely on far more than its login. Kinde ships with the organizational structures, permission systems, and monetization tools that products actually need, bringing auth, billing, feature flags, and multi-tenancy together in one platform. If you're building a B2B SaaS product on Kinde, you're using Kinde orgs to segment your customers, Kinde billing to manage subscriptions, and Kinde feature flags to gate features by plan. Switching to Auth0 or Clerk to support a Mastra agent would mean rebuilding all of that elsewhere, which is not a real option. That gap is the problem. You need Kinde to work with Mastra, and until now there was no clean way to connect them. That's why I built mastra-auth-kinde . What Mastra's auth system actually does When you add an auth provider to Mastra, it protects two things at once: all your API routes ( /api/agents/* , /api/workflows/* , and so on) and your Mastra Studio UI. Every request to a protected route goes through your provider before it reaches anything else. You extend Mastra's MastraAuthProvider base class and implement two methods: authenticateToken(token, request) verifies the JWT and returns the decoded user, or null if it fails authorizeUser(user, request) returns true to let the request through, or false for a 403 Mastra handles everything else: extracting the Bearer token from the Authorization header, calling your methods in order, and storing the verified user in the request context so your agents and tools can access it. Why Kinde specifically Beyond the billing and org story above, a few things make Kinde the right fit

Howdy all. I'm Zack :wave:. I've been thinking about the problem of misguided AI pull requests and figured I'd throw a possible solution out there for feedback. Basically, CleverCrow lets supporters give tokens to a GitHub repo (or set of issues in that repo) for the maintainers to use to build/fix stuff. The fun implementation challenges have been around implementing the pooling dynamics and keeping the maintainers in charge while the backers are motivated to support their work.

The history books are littered with the corpses of corporate record labels started by companies that had no business being in the music industry. Bose thinks it can be the exception to the rule. It thinks it can be Red Bull. And, while Bose has more of a right to dip its toes into the […]

Thinking about trying FtrIO? The new CLI makes it easy to start with just one feature flag If you've been curious about FtrIO (the .NET feature toggle library that replaces if (featureFlags.IsEnabled(...)) with a [Toggle] attribute woven directly into your compiled IL) but weren't sure where to start, the experimental release of FtrIO.onetwo just made that first step a lot smaller. You don't need to commit to a full migration. You don't need to rip out your existing flag library. You just need one method and 20 minutes. What FtrIO.onetwo does FtrIO.onetwo is a .NET CLI audit tool. Its default mode scans your source tree, finds every FtrIO toggle reference, and tells you exactly what's live right now: dotnet tool install --global FtrIO.onetwo --version 1.1.1-experimental ftrio.onetwo --source C: \P rojects \M yApp But in this experimental release it does two new things: ftrio.onetwo import : pulls your current flag state from LaunchDarkly, Flagsmith, flagd, environment variables, or an HTTP endpoint directly into appsettings.json . Your existing flag library keeps working unchanged. ftrio.onetwo migrate : scans your .cs files for LaunchDarkly or Flagsmith SDK call patterns using Roslyn, cross-references them against your live flag state, and generates a report showing exactly what each flag would look like in FtrIO and how to migrate it. The "try it on one flag" workflow The migrate report categorises every flag it finds: ✅ Ready to migrate : boolean flag, no targeting rules, straightforward [Toggle] replacement ⚠️ Needs review : targeting rules, number flags, needs a decision ❌ Cannot migrate : JSON flags, recommend moving to IConfiguration For every ready flag it shows the suggested refactor. Something like: new - checkout - flow → NewCheckoutFlow File : Services \ OrderService . cs : 42 Current code : if ( client . BoolVariation ( "new-checkout-flow" , user , false )) { ValidateCart (); ApplyDiscounts (); ProcessPayment (); } Suggested action : Extract the if bloc