Sr. Content Developer at Microsoft, working remotely in PA, TechBash conference organizer, former Microsoft MVP, Husband, Dad and Geek.
150313 stories
·
33 followers

Postman’s journey and unlocking the power of APIs

1 Share
Lessons learned building a global API platform, navigating hyper-growth, and API-powered AI agents.
Read the whole story
alvinashcraft
13 seconds ago
reply
Pennsylvania, USA
Share this story
Delete

Dev Proxy v2.0 with improved AI telemetry, and small breaking changes

1 Share

We’re excited to announce the release of Dev Proxy v2.0. Following semantic versioning (SemVer), we’re bumping the major version due to breaking changes in this release. While these changes are small, they improve Dev Proxy’s accuracy and behavior – and we want you to be aware of them.

This release also brings .NET 10 support, enhanced AI telemetry capabilities, and important fixes that make your API simulations more reliable.

In this version:

  • Breaking changes in date formatting and telemetry behavior
  • .NET 10 support
  • Improved AI telemetry with cached tokens tracking
  • Bug fixes and improvements

Breaking changes

We’ve made small but important changes that could affect your existing workflows:

Culture-invariant date formatting in Graph mocks

Previously, GraphMockResponsePlugin formatted dates using your system’s culture settings (e.g., 13/11/2025 14:30:00 on French systems vs. 11/13/2025 2:30 PM on US systems). This was a bug – Dev Proxy wasn’t accurately emulating how Microsoft Graph actually works. Graph always returns dates in standardized formats, regardless of where it’s running.

What changed:

All mocked Graph responses now use consistent, culture-invariant formats that align with how Microsoft Graph actually behaves:

  • HTTP Date headers use RFC 1123 format: Sun, 16 Nov 2025 11:16:59 GMT (per RFC 7231)
  • InnerError.Date properties use ISO 8601 format: 2025-11-16T11:16:59

Impact: If you parse dates from mocked responses, you may need to update your code to handle these standardized formats. The upside? Dev Proxy now accurately emulates Microsoft Graph’s real behavior, giving you consistent responses across all environments – just like the actual Graph API does.

Smarter telemetry recording behavior

We’ve improved how the OpenAITelemetryPlugin and OpenAIUsageDebuggingPlugin handle their outputs, making them more consistent with other Dev Proxy recording plugins.

What changed:

  • OpenAITelemetryPlugin now only includes requests captured while recording is active in its generated report – aligning with how other recording plugins work
  • OpenAIUsageDebuggingPlugin now only creates CSV files when Dev Proxy intercepts relevant OpenAI requests
  • Running devproxy –version, or other sub-commands, no longer creates unnecessary output files

Impact: If your automation relies on these files always being created, you’ll need to check for their existence before processing them. This change keeps your workspace clean and ensures you only get reports with actual data.

.NET 10 support

Future-proof your development workflow with .NET 10. Dev Proxy now runs on the latest .NET runtime, giving you access to the newest performance improvements, security patches, and language features.

Upgrading to .NET 10 ensures Dev Proxy stays aligned with Microsoft’s latest development platform, providing you with a faster, more secure, and more capable API simulation tool.

Enhanced AI telemetry with cached tokens tracking

Understanding how your AI-powered applications use tokens is crucial for managing costs and optimizing performance. The OpenAITelemetryPlugin now tracks cached tokens alongside standard token usage, giving you complete visibility into your AI API consumption.

Why this matters:

When your app uses cached prompts, AI providers typically charge significantly less for those tokens. Without tracking cached tokens separately, you couldn’t accurately measure cost savings or optimize your caching strategy. Now you can see exactly how much you’re benefiting from prompt caching, helping you make data-driven decisions about your AI implementation.

Dev Proxy Toolkit

Dev Proxy Toolkit is an extension that makes it easier to work with Dev Proxy from within Visual Studio Code. Alongside the new release of Dev Proxy, we’ve also released a new version of the toolkit, v1.10.0. In this version, we’ve updated all JSON snippets to use v2.0.0 schemas.

Checkout out the changelog for more information on changes and bug fixes.

Why upgrade to v2.0?

While the breaking changes are small, they make Dev Proxy more accurate and reliable. Dev Proxy v2.0 ensures:

  • Consistent behavior – Culture-invariant dates work the same everywhere
  • Accurate cost tracking – Complete visibility into cached tokens
  • Cleaner workflows – No more empty telemetry files cluttering your workspace
  • Future-ready – .NET 10 support keeps you on the latest platform

Try it now

Download Dev Proxy v2.0 today and build better API-connected applications with confidence!

Thanks to Artem Azaraev and for contributing to this release.

Got feedback or ideas? Join us and be part of the conversation.

The post Dev Proxy v2.0 with improved AI telemetry, and small breaking changes appeared first on Microsoft 365 Developer Blog.

Read the whole story
alvinashcraft
28 seconds ago
reply
Pennsylvania, USA
Share this story
Delete

An inspiring tutor, 'New York System' hot dogs, and 'queen spotting.'

1 Share

1139. In this bonus discussion with Martha Barnette back in March, we look at Martha's pivotal twelve-year journey with a polyglot tutor who transformed her understanding of ancient Greek, starting with the etymology of "Oedipus." We also look at her beekeeping adventures, including the unknown-to-me history of the term 'queen bee' and a unique book on spotting them.

Martha Barnette's website

Martha's book, “Friends with Words: Adventures in Languageland”

Martha's podcast, "A Way with Words"

🔗 Share your familect recording via Speakpipe or by calling 833-214-4475

🔗 Watch my LinkedIn Learning writing courses.

🔗 Subscribe to the newsletter.

🔗 Take our advertising survey

🔗 Get the edited transcript.

🔗 Get Grammar Girl books

🔗 Join GrammarpaloozaGet ad-free and bonus episodes at Apple Podcasts or SubtextLearn more about the difference

| HOST: Mignon Fogarty

| Grammar Girl is part of the Quick and Dirty Tips podcast network.

  • Audio Engineer: Dan Feierabend
  • Director of Podcast: Holly Hutchings
  • Advertising Operations Specialist: Morgan Christianson
  • Marketing and Video: Nat Hoopes

| Theme music by Catherine Rannus.

| Grammar Girl Social Media: YouTubeTikTokFacebook.ThreadsInstagramLinkedInMastodonBluesky.


Hosted by Simplecast, an AdsWizz company. See pcm.adswizz.com for information about our collection and use of personal data for advertising.





Download audio: https://dts.podtrac.com/redirect.mp3/media.blubrry.com/grammargirl/stitcher.simplecastaudio.com/e7b2fc84-d82d-4b4d-980c-6414facd80c3/episodes/4f8404ac-779d-4f1b-a6cc-85ae87da0540/audio/128/default.mp3?aid=rss_feed&awCollectionId=e7b2fc84-d82d-4b4d-980c-6414facd80c3&awEpisodeId=4f8404ac-779d-4f1b-a6cc-85ae87da0540&feed=XcH2p3Ah
Read the whole story
alvinashcraft
45 seconds ago
reply
Pennsylvania, USA
Share this story
Delete

Advent of Code 2025 Day 4: Printing Department in C# ✅✅

1 Share
From: Martin Zikmund
Duration: 11:46
Views: 5

Today we help the elves move rolls of paper from their warehouse using forklifts!

Source code: https://github.com/MartinZikmund/advent-of-code

#adventofcode #puzzle #coding #csharp #dotnet #programming

Contents:
0:00 - Intro
0:05 - Part 1
0:45 - Solving part 1
7:45 - Part 2
8:15 - Solving part 2
11:25 - Summary

Read the whole story
alvinashcraft
51 seconds ago
reply
Pennsylvania, USA
Share this story
Delete

Building an AI App with Calum Simpson

1 Share
What's it like building an AI-centric application? Carl and Richard talk to Calum Simpson of SSW about their product YakShaver. Calum talks about building a tool that speeds reporting on issues and ideas, so you can spend more time focusing on key issues rather than "shaving the yak." The use of LLMs makes YakShaver far more capable, and the upcoming V2 uses Model Context Protocol (MCP) servers to expand functionality and feed information directly into bug reports, such as GitHub issues and feature requests. The conversation also turns a bit more philosophical, focusing on innovative uses of LLMs, properly constraining these tools, and maintaining a transparent chain of responsibility for your code.



Download audio: https://dts.podtrac.com/redirect.mp3/api.spreaker.com/download/episode/68871422/dotnetrocks_1979_building_an_ai_app.mp3
Read the whole story
alvinashcraft
1 minute ago
reply
Pennsylvania, USA
Share this story
Delete

Python 3.9 reaches end of life: What it means for RHEL users

1 Share

The Python 3.9 release was in October 2020, the next step in Python’s steady annual release cadence. It brought several improvements that many developers still rely on today, including dictionary union operators, enhanced string methods, type hinting enhancements, new PEG parser infrastructure, and performance enhancements across the standard library. However, after five years of upstream maintenance, Python 3.9 has officially reached its end-of-life (EOL) phase upstream. This article will discuss what this means for Red Hat Enterprise Linux (RHEL) 8 and 9 users.

Upstream: Python 3.9 end of life

According to the Python 3.9 release schedule, the release cycle for Python 3.9 ended on October 31, 2025, with Python 3.9.25 published as the final security release.

Starting now:

  • The 3.9 codebase upstream is frozen.
  • The Python Core Development team will provide no further bug fixes, security patches, or enhancements.
  • No new issues will be accepted for Python 3.9 on the CPython bug tracker.

This means any unresolved upstream issues will remain unresolved, and downstream consumers must make long-term support decisions based on this final upstream state.

Python 3.9 in RHEL

Although upstream support has ended, Python 3.9 plays different roles across Red Hat Enterprise Linux releases.

RHEL 9

RHEL 9 standardizes on Python 3.9 as the system-wide default Python interpreter. Python 3.9 will be fully supported for the entire lifetime of RHEL 9, despite upstream EOL. 

Red Hat will continue to maintain Python 3.9 with critical patches and security backports as part of the RHEL 9 platform guarantees. This makes RHEL 9 a stable, long-term home for Python 3.9 workloads that cannot yet upgrade to newer Python releases.

RHEL 8

In RHEL 8, the python39 module provides Python 3.9 as an alternate Python stack, existing along with the platform’s default Python 3.6.

Key points:

  • Support for Python 3.9 in RHEL 8 ends at the end of November 2025.
  • If you need a newer Python than 3.6 on RHEL 8, you should consider one of the following:
    • Python 3.11, supported until May 2026.
    • Python 3.12, supported until the end of the RHEL 8 lifecycle.
  • If your workloads must remain on Python 3.9 specifically, you can use RHEL 9-based container images: UBI, S2I (refer to the Red Hat Ecosystem Catalog).

Next steps

The upstream Python 3.9 lifecycle has ended, but this does not mean your workloads must immediately migrate. Red Hat provides clear paths to balance stability, security, and long-term maintenance:

  • Upstream support ended on October 31, 2025.
  • RHEL 8: Python 3.9 supported until November 2025. Newer Python versions are available.
  • RHEL 9: Python 3.9 remains the main interpreter, supported for the full lifecycle of RHEL 9.
  • Containers based on RHEL 9 remain a strong option for Python 3.9 workloads on RHEL 8.

For those on RHEL 8, planning an upgrade path now will help ensure long-term security and compatibility. You can upgrade to Python 3.11/3.12 or RHEL 9-based containers.

The post Python 3.9 reaches end of life: What it means for RHEL users appeared first on Red Hat Developer.

Read the whole story
alvinashcraft
1 minute ago
reply
Pennsylvania, USA
Share this story
Delete
Next Page of Stories