NanoPy is the standard IDE for Oxocard projects. However, thanks to the ESP32 microcontroller at the heart of the Oxocard, programming with C++ via the Arduino IDE is also a viable development option. Here's how to get started...

The post Programming the Oxocard Connect with Arduino appeared first on Make: DIY Projects and Ideas for Makers.

Are you looking for a bookish gift for the reader or the writer in your life? We have put together this post on bookish gifts for you.

We hope you find something you like.

The 23 Best Bookish Gifts

1. Wall Scrabble

2. Romeo and Juliet Tights

3. Real Men Read Books Tote

4. Shakespearean Insult Bandages

5. Writers Write Gift Voucher – make someone’s writing dreams come true.

6. Bookish Tape

7. To Quote Hamlet Shirt

8. The Hobbit Map Shirt

9. Just One More Chapter Duvet Set

10. Coffee and Literary Rage T-Shirt

11. Readers’ Necklaces

12. Harry Potter Beachwear

13. Team Katniss Shirt

14. Library Card Socks

15. Ampersand Necklace

16. Library Stamp T-Shirt

17. Grammar Police Pencils

18. Booktrovert Mug

19. Little Free Library – (‘Take a book, return a book’)

20. Mr Darcy Candle

21. Sherlock Holmes Key Fob

22. Jules Verne Inspired Seampunk Flask

23. Book Nerd Necklace

by Amanda Patterson

Top Tip: Find out more about our workbooks and online courses in our shop.

The post The 23 Best Bookish Gifts appeared first on Writers Write.

Joe and Tamás look back at what happened in 2025, and where we are heading in 2026. See you all next year with exciting new guests in the next season!

Welcome to the latest digest of news from the Swift project.

Each edition, we share updates that we hope will be useful to you whether you’re writing code with Swift or contributing to the language as a whole, and we start with an introduction from this edition’s guest contributor:

As we near the end of the year, it’s a time for reflection and gratitude. We’re profoundly grateful for the energy, creativity, and dedication of our community: the hundreds of contributors who submit code to improve Swift, those who create and steward ecosystem packages with thoughtfulness, and the developers building remarkable things with this language.

Indeed, it has been a monumental twelve months for Swift as an open source project.

From its relatively humble roots as an open source project, starting with a simple blog post ten years ago this month, the Swift project now comprises over 70 repositories, with hundreds of contributors every week bringing fresh perspectives, performance improvements, and tooling enhancements to the ecosystem.

The release of Swift 6.2 brings more approachable concurrency with defaults that align with a philosophy of progressive disclosure: making advanced features available when you need them, but keeping them out of your way when you don’t. Swift 6.2 also adds WebAssembly support, deep C++ interoperability, and improved memory safety features.

This year proved that Swift truly runs everywhere, across a variety of platforms and use cases:

• Embedded: Embedded Swift is rapidly evolving, moving from experimental to practical use cases, with significant updates targeted for the upcoming 6.3 release.
• Android: The workgroup is making strides with daily snapshot builds and end-to-end demos, bringing native Swift development closer to reality on Android devices.
• Windows: Support is maturing fast, with richer tooling via the VS Code extension and a growing library of packages that support Windows out of the box.
• BSD: The preview of Swift on FreeBSD support is now available for FreeBSD 14.3 and later, and will be featured in a FOSDEM 2026 talk about Porting Swift to FreeBSD.
• AI: The ecosystem is evolving quickly, with MLX providing a Swift-friendly API for machine learning on Apple Silicon, and numerous packages from Hugging Face for Swift development.
• Server: Backend development remains a major growth area. At the recent AWS re:Invent conference, Amazon announced integrated support for Swift in Amazon Linux and adoption of the AWS Lambda Runtime, signaling that the cloud is ready for Swift’s memory safety and speed.

And of course, Swift remains the unrivaled language of choice for building apps across all Apple platforms, whether you’re building an app or a game for iPhone, iPad, Mac, Apple Watch, Apple TV, or Apple Vision Pro!

So thank you, once more, on behalf of all of us working on Swift: there would be no Swift community without you!

— Tim Sneath

To end this milestone year, let’s take a look at some of the things that caught our attention this month.

Swift at FOSDEM 2026

Get ready for FOSDEM, the world’s largest independently run open source conference, taking place in Brussels in late January / early February. The Swift community will be there, with a Pre-FOSDEM Community Event. The Call for Proposals is open for short talk submissions through January 5th, 2026 (23:59 CET).

Outside of the pre-conference event, Swift talks will appear in several FOSDEM devrooms including Containers, BSD, LLVM, and SBOMs. Hope to see you there!

Talks worth watching

• Beyond Web Services: Swift for Low-Level Container infrastructure - Eric Ernst introduces us to Apple’s Containerization and Container open source projects, built entirely in Swift.
• Separate code from configuration with Swift Configuration - Swift Configuration provides a unified approach to handling configuration in your Swift applications. For more information, also check out the Swift Configuration 1.0 announcement from last week.
• Getting started with gRPC Swift - A deep dive into the Swift package for gRPC, a key building block of performant cloud services.

Behind the scenes interviews

• Running Swift in AWS Lambda | Serverless Office Hours - Sebastien Stormacq answered developer questions and was live coding with Swift on AWS Lambda. Also check out the related Swift AWS Lambda Runtime package.
• Observability in Server Side Swift, with Moritz Lang - Dev Conversations #16 - This interview covers all things distributed tracing and Swift OTel.
• Code-along: Start building with Swift and SwiftUI - Originally live streamed, a developer code-along that walks you through building a complete iOS interface using Swift and SwiftUI, followed by a Q&A session to answer developer questions.

Swift blog highlights

In case you missed it, here are several recent blog posts you’ll want to check out:

• Exploring the Swift SDK for Android - Common questions about Swift on Android are answered by the Android workgroup, and new Swift 6.3 SDK nightly previews were announced.
• Temporal Swift SDK introduced - Temporal has also blogged about using Swift with Temporal.
• 2025 Google Summer of Code contributors had posts featuring work related to several Swift-related projects, everything from Bringing Swiftly support to VS Code, Extending Swift-Java Interoperability, Improved code completion for Swift, and Improved console output for Swift Testing.

Swift everywhere

As this month’s guest contribution shared, Swift continues to expand to new platforms. Here are a few recent examples from the community:

• Using Swift SDKs with Raspberry Pi - Did you know Swift can run on a Raspberry Pi? This blog post does a deep dive, it’s time to open your terminal and follow along!
• Swift for WASM December 2025 updates - An update on progress related to Swift for WASM. In December the community also had an online meetup including talks.
• AWS blog post about AWS Lambda runtime - The Swift AWS Lambda Runtime moved to the official AWS Labs GitHub organization, delivering a vendor-supported approach to running Swift on AWS Lambda.
• Swift on a Pebble watch - A fun example of how a developer used Swift’s embedded support to build a “hello world” example on a 10-year-old Pebble Time Round watch.

Swift Evolution

The Swift project adds new language features to the language through the Swift Evolution process. These are some of the proposals currently under discussion or recently accepted for a future Swift release.

Under Active Review:

• SE-0501 HTML Coverage Report - This proposal adds HTML coverage report generation to Swift Package Manager’s swift test command. Currently, SwiftPM only generates JSON coverage reports, which are useful for automated tools but difficult for developers to read directly. The new --coverage-format option would allow generating HTML reports alongside or instead of JSON, enabling visual inspection in CI systems and faster feedback during development.

Recently completed:

• SE-0497 Controlling function definition visibility in clients - The @inlinable attribute in Swift allows function definitions to be visible to callers, enabling optimizations like specialization and inlining. This proposal introduces explicit control over whether a function generates a callable symbol and makes its definition available for optimization purposes.
• SE-0493 Support async calls in defer bodies - Swift’s defer statements provide scope-based cleanup but currently cannot perform asynchronous work, forcing developers to either manually insert cleanup on every exit path or spawn detached tasks. This proposal allows await calls within defer bodies when the enclosing context is async, with the defer statements implicitly awaited at scope exit to ensure proper cleanup completion.

Editor Note: With this update, we’re going to take a break from the blog for the next couple of weeks. Wishing everyone a restful end to 2025!

November 2025 was a busy month for Microsoft Copilot Studio, marked by major announcements at Microsoft Ignite 2025 and a wave of new features now rolling out to makers.

The post What’s new in Microsoft Copilot Studio: November 2025 appeared first on Microsoft 365 Blog.

When you only need to update part of a resource, such as changing a user’s email address or adjusting a product price, the HTTP PATCH method is the best fit. Introduced in RFC 5789, PATCH applies partial updates to an existing resource, making it more efficient than PUT for targeted updates.

This guide explains what the PATCH method is, how it differs from PUT and POST, and how to implement PATCH requests effectively with Postman.

Example: Updating a user’s role

PATCH /api/users/12345 HTTP/1.1
Content-Type: application/json

{
  "role": "Senior Developer"
}

The server updates only the role field and leaves all other properties unchanged:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": "12345",
  "name": "Patia Ostman",
  "email": "p.ostman@example.com",
  "role": "Senior Developer"
}

PATCH vs PUT vs POST

Understanding when to use PATCH, PUT, and POST is fundamental to RESTful API design.

*PATCH is not inherently idempotent, but many APIs design PATCH requests to be idempotent when possible.

How the same update behaves differently

PATCH: send only what changes

PATCH /api/users/12345 HTTP/1.1
Content-Type: application/json

{
  "email": "newemail@example.com"
}

Result: Only the email field is updated.

PUT: send everything

PUT /api/users/12345 HTTP/1.1
Content-Type: application/json

{
  "id": "12345",
  "name": "Patia Ostman",
  "email": "newemail@example.com",
  "role": "Developer"
}

Result: The entire resource is replaced. If you omit any fields, they might be removed or reset to default values.

When not to use PATCH

PATCH is powerful, but it isn’t always the right choice.

Avoid PATCH when:

• You intend to replace the entire resource (use PUT instead).

• Updates are inherently non-idempotent (consider POST for action-based changes).

• Your API contract requires full validation of all fields on every update.

• The resource does not yet exist (return 404 and use POST to create).

PATCH request formats

APIs typically support PATCH using one of two formats: merge-based updates or operation-based updates.

JSON merge patch

A merge patch sends a JSON object containing only the fields to update:

PATCH /api/users/12345
Content-Type: application/merge-patch+json

{
  "email": "updated@example.com",
  "role": "Manager"
}

This approach is simple and intuitive, but it can be ambiguous for nested objects and null values.

JSON Patch

JSON Patch (RFC 6902) provides precise control using an array of operations:

PATCH /api/users/12345 Content-Type: application/json-patch+json [ { “op”: “replace”, “path”: “/email”, “value”: “new@example.com” }, { “op”: “add”,

PATCH /api/users/12345
Content-Type: application/json-patch+json

[
  { "op": "replace", "path": "/email", "value": "new@example.com" },
  { "op": "add", "path": "/phone", "value": "+1-555-0123" },
  { "op": "remove", "path": "/temporary_field" }
]

Available operations:

• add → Add a new field or array element

• remove → Delete a field

• replace → Update an existing field

• move → Move a value to a different location

• copy → Copy a value to a new location

• test → Verify a value before applying operations

Common PATCH response codes

Success responses:

• 200 OK → Update succeeded, returns the updated resource

• 204 No Content → Update succeeded with no response body

• 202 Accepted → Update accepted for asynchronous processing

Error responses:

• 400 Bad Request → Invalid patch format or data

• 401 Unauthorized → Authentication required

• 403 Forbidden → Insufficient permissions

• 404 Not Found → Resource doesn’t exist

• 409 Conflict → Update conflicts with the current resource state

• 422 Unprocessable Entity → Valid JSON, but semantically incorrect

Understanding PATCH idempotency

Idempotency means that applying the same request multiple times produces the same result as applying it once. This property is crucial for safely handling network retries.

PATCH is not inherently idempotent, but many APIs design PATCH requests to behave idempotently for reliability and safe retries.

Idempotent PATCH example:

PATCH /api/users/12345

{
  "email": "consistent@example.com"
}

Sending this request multiple times results in the same final state.

Non-idempotent PATCH example:

PATCH /api/products/789

{
  "inventory_adjustment": -5  // Subtract 5 from inventory
}

Each request subtracts 5 inventory, resulting in a different final state.

Best practices for idempotency

Use absolute values instead of relative changes:

Non-idempotent:

{ "views": "+1" }

Idempotent:

{ "views": 1501 }

For operations that require relative updates, use dedicated POST endpoints for actions rather than PATCH for modifications.

Real-world PATCH use cases

PATCH is ideal for targeted updates across many domains.

User profile updates

PATCH /api/users/profile
{ "bio": "API enthusiast and developer advocate" }

E-commerce inventory

PATCH /api/products/789
{ "price": 29.99, "inventory": 47 }

Application settings

PATCH /api/settings
{ "theme": "dark", "notifications": true }

Task management

PATCH /api/tasks/456
{ "status": "completed", "completed_at": "2024-11-24T14:30:00Z" }

Content publishing

PATCH /api/articles/789
{ "status": "published", "featured": true }

Testing PATCH requests in Postman

Postman makes it easy to test PATCH endpoints and verify partial update behavior.

Creating a PATCH request

1. Click New → HTTP Request.

2. Select PATCH from the method dropdown.

3. Enter the endpoint URL: https://api.example.com/users/12345

4. Add headers:

   • Content-Type: application/json

   • Authorization: Bearer your_token

5. Add the request body:

{
  "email": "newemail@example.com"
}

6. Click Send to see the response.

Testing partial updates

Create multiple requests to verify that only the specified fields change.

Test 1: Update email only

{ "email": "test1@example.com" }

Test 2: Update role only

{ "role": "Manager" }

Send a GET request after each PATCH to confirm other fields remain unchanged.

Adding test scripts

Verify PATCH responses automatically:

pm.test("Status code is 200", function () {
    pm.response.to.have.status(200);
});

pm.test("Email was updated", function () {
    const jsonData = pm.response.json();
    pm.expect(jsonData.email).to.eql("newemail@example.com");
});

pm.test("Other fields unchanged", function () {
    const jsonData = pm.response.json();
    pm.expect(jsonData.name).to.exist;
});

Best practices for PATCH implementation

Follow these guidelines to build reliable PATCH endpoints.

Design PATCH to be idempotent where possible

Prefer absolute field values over incremental updates.

Document patchable fields

Clearly specify which fields can be modified and which cannot.

PATCH /api/users/{id}

Patchable fields:
- email (string, valid email format)
- role (string: "user", "admin", "manager")
- preferences (object)

Protected fields (cannot be patched):
- id, created_at, username

Validate before applying changes

Validate all fields first and apply updates only if all validations pass.

// Validate all fields first
if (patch.email && !isValidEmail(patch.email)) {
  return 400;
}

if (patch.role && !validRoles.includes(patch.role)) {
  return 400;
}

// Only apply if all validations pass
applyPatch(resource, patch);

Handle null explicitly

Differentiate between omitted fields (leave unchanged) and explicit null values (clear the field).

Return the updated resource

After a successful PATCH, return the complete updated resource so clients can confirm changes.

PATCH security considerations

Because PATCH modifies existing data, strong security controls are essential.

Require authentication and authorization

Always verify the caller’s identity and ensure their permissions are valid. Make sure that users can only modify resources they own or have permission to edit.

Restrict access to sensitive fields

Never allow PATCH to modify system-managed or security-critical fields, such as id, created_at, password_hash, or permission flags.

Validate all input

Treat PATCH data like any user input. Validate types, formats, and ranges to prevent injection attacks and data corruption.

Enforce HTTPS

PATCH requests often contain sensitive data. Always use HTTPS to encrypt data in transit.

Apply rate limiting

Prevent abuse by limiting PATCH requests per user or IP address.

Common mistakes to avoid

• Treating PATCH like PUT. Don’t require all fields in a PATCH request. Send only what needs to change.

• Creating resources with PATCH instead of POST. Return 404 Not Found when trying to PATCH non-existent resources. Use POST to create resources.

• Allowing updates to immutable fields. Protect system-managed fields from modification through clear validation rules.

• Ignoring dependencies between related fields. Some fields depend on others. Validate these relationships before applying changes.

• Skipping transport security. Even with proper authentication, always use HTTPS to encrypt PATCH requests and protect sensitive data.

FAQs

Final thoughts

The HTTP PATCH method is primarily used to express what changes should be made to a resource without resending its entire state. When PATCH requests are clearly scoped, validated upfront, and designed to behave predictably, they reduce accidental data loss and make APIs easier to evolve over time. Used this way, PATCH becomes a powerful tool for building APIs that scale without breaking clients.

The post HTTP PATCH Method: Partial Updates for RESTful APIs appeared first on Postman Blog.