I’m working on fixing a reported bug with Wolverine today and its event forwarding from Marten feature. I can’t say that I yet know why this should-be-very-straightforward-and-looks-exactly-like-the-currently-passing-tests bug is happening, but it’s a good time to demonstrate Wolverine’s automated testing support and even how it can help you to understand test failures.

First off, and I’ll admit that there’s some missing context here, I’m setting up a system such that when this message handler is executed:

public record CreateShoppingList();

public static class CreateShoppingListHandler
{
    public static string Handle(CreateShoppingList _, IDocumentSession session)
    {
        var shoppingListId = CombGuidIdGeneration.NewGuid().ToString();
        session.Events.StartStream<ShoppingList>(shoppingListId, new ShoppingListCreated(shoppingListId));
        return shoppingListId;
    }
}

The configured Wolverine + Marten integration should be kicking in to publish the event appended in the handler above to a completely different handler shown below with the Marten IEvent wrapper so that you can use Marten event store metadata within the secondary, cascaded message:

public static class IntegrationHandler
{
    public static void Handle(IEvent<ShoppingListCreated> _)
    {
        // Don't need a body here, and I'll show why not
        // next
    }
}

Knowing those two things, here’s the test I wrote to reproduce the problem:

    [Fact]
    public async Task publish_ievent_of_t()
    {
        // The "Arrange"
        using var host = await Host.CreateDefaultBuilder()
            .UseWolverine(opts =>
            {
                opts.Policies.AutoApplyTransactions();

                opts.Services.AddMarten(m =>
                {
                    m.Connection(Servers.PostgresConnectionString);
                    m.DatabaseSchemaName = "forwarding";

                    m.Events.StreamIdentity = StreamIdentity.AsString;
                    m.Projections.LiveStreamAggregation<ShoppingList>();
                }).UseLightweightSessions()
                .IntegrateWithWolverine()
                .EventForwardingToWolverine();;
            }).StartAsync();
        
        // The "Act". This method is an extension method in Wolverine
        // specifically for facilitating integration testing that should
        // invoke the given message with Wolverine, then wait until all
        // additional "work" is complete
        var session = await host.InvokeMessageAndWaitAsync(new CreateShoppingList());

        // And finally, just assert that a single message of
        // type IEvent<ShoppingListCreated> was executed
        session.Executed.SingleMessage<IEvent<ShoppingListCreated>>()
            .ShouldNotBeNull();
    }

And now, when I run the test — which “helpfully” reproduces reported bug from earlier today — I get this output:

System.Exception: No messages of type Marten.Events.IEvent<MartenTests.Bugs.ShoppingListCreated> were received

System.Exception
No messages of type Marten.Events.IEvent<MartenTests.Bugs.ShoppingListCreated> were received
Activity detected:

----------------------------------------------------------------------------------------------------------------------
| Message Id                             | Message Type                          | Time (ms)   | Event               |
----------------------------------------------------------------------------------------------------------------------
| 018f82a9-166d-4c71-919e-3bcb04a93067   | MartenTests.Bugs.CreateShoppingList   |          873| ExecutionStarted    |
| 018f82a9-1726-47a6-b657-2a59d0a097cc   | System.String                         |         1057| NoRoutes            |
| 018f82a9-17b1-4078-9997-f6117fd25e5c   | EventShoppingListCreated              |         1242| Sent                |
| 018f82a9-166d-4c71-919e-3bcb04a93067   | MartenTests.Bugs.CreateShoppingList   |         1243| ExecutionFinished   |
| 018f82a9-17b1-4078-9997-f6117fd25e5c   | EventShoppingListCreated              |         1243| Received            |
| 018f82a9-17b1-4078-9997-f6117fd25e5c   | EventShoppingListCreated              |         1244| NoHandlers          |
----------------------------------------------------------------------------------------------------------------------

EDIT: If I’d read this more closely before, I would have noticed that the problem was somewhere different than the routing that I first suspected from a too casual read.

The textual table above is Wolverine telling me what it did do during the failed test. In this case, the output does tip me off that there’s some kind of issue with the internal message routing in Wolverine that should be applying some special rules for IEvent<T> wrappers, but was not in this case. While that work fixing the real bug continues for me, what I hope you get out of this is how Wolverine is trying to help you diagnose test failures by providing diagnostic information about what was actually happening internally during all the asynchronous processing. As a long veteran of test automation efforts, I will vociferously say that it’s important for test automation harnesses to be able to adequately explain the inevitable test failures. Like Wolverine helpfully does.

Now, back to work trying to actually fix the problem…

A popular mantra within the disability community is, “Nothing about us without us.” That mantra embodies the strongly held belief that people with disabilities must actively participate in the decisions that impact their lives. Given that technology is an integral part of how all of humanity lives, works, learns, and plays, it is absolutely essential that those of us with disabilities have the opportunity to contribute to and lead, the development of technology.

In the latest installment of the Coding Accessibility series, you’ll learn how blind developers Jamie Teh and Michael “Mick” Curran are living the mantra. They have built thriving communities that are organized by the blind, for the blind. The open source software maintained by these communities is used by hundreds of thousands of blind people globally.

GitHub is honored to provide a home for Jamie, Mick, and their communities of blind developers, contributors, and users. We know that the best way to increase the accessibility of technology is to empower people with disabilities to build it. In this post, you’ll learn how we’re doing that by building a culture that scales accessibility internally within GitHub and beyond.

Required company-wide training

Our culture of accessibility starts with company-wide training that is required for every single Hubber. During the training, Hubbers learn about types of disabilities, assistive technologies that are used by people with disabilities, disability etiquette, and why accessibility is so important for GitHub. That body of knowledge is the foundation for our company-wide accessibility program, and every Hubber has an important role to play as we build a more inclusive GitHub.

Engineering fundamentals

The GitHub Engineering Fundamentals program is another important part of our accessibility culture. Indeed, the Engineering Fundamentals program serves as the foundation for accessibility governance at GitHub. The program was created with the goal of defining, measuring, and sustaining engineering excellence across the GitHub platform. The program includes three pillars, which are accessibility, availability, and security, and uses scorecards to continuously monitor how services meet the expectations defined by each of the three pillars. For example, the accessibility pillar includes two scorecards that measure services against the expectations for accessibility at GitHub. If a service fails to meet those expectations, service owners can easily identify the action items that must be completed.

Learn more about the Engineering Fundamentals program at GitHub.

Accessibility Design Bootcamp

Great accessibility starts with great design. And, we know that the most cost-effective way to prevent and remove accessibility barriers is during design. That’s why we created our Accessibility Design Bootcamp. The bootcamp is a live educational program that consists of exercises, discussions, and knowledge shares to raise awareness of web accessibility best practices, the role designers play in creating accessible products, and how to advocate for accessibility with cross-functional partners. Since its inception in March 2023, four cohorts of designers representing 50% of our design team have completed the bootcamp.

Learn more about the Accessibility Design Bootcamp at GitHub.

Accessibility Champions program

While our Accessibility Design Bootcamp has helped shift accessibility left within our development process, our Accessibility Champions program has empowered Hubbers to lead accessibility within their teams. The program started with a cohort of 17 engineering champions. Those participants gained practical experience creating inclusive digital experiences through hands-on exercises and interactive discussions. Their feedback drove improvements that included more interactive experiences and community engagement, such as monthly Champions Connect meetings, which provide a platform for champions to come together, exchange ideas, and foster a sense of camaraderie. We also organized bug bashes and collaborative events where champions worked together to identify and address accessibility issues in real time. Today, there are 52 accessibility champions at GitHub and we plan to expand the program to include at least 100 champions by the end of the year.

Learn more about the Accessibility Champions program at GitHub.

Primer

The open source Primer design system is a set of guidelines, principles, and patterns for designing and building UI at GitHub. It provides a shared language and standardized approach to delivering cohesive experiences across the GitHub platform. The building blocks of those experiences are Primer components. The Primer team includes accessibility and feedback from users with disabilities throughout their development process. As a result, Primer is our most powerful lever for implementing accessibility at scale.

Learn how we build accessible Primer components and how we improved Primer’s color system to be more inclusive.

Conclusion

Peter Drucker said, “Culture eats strategy for breakfast.” We’ve internalized that wisdom and, as a result, we are working to build a culture of accessibility within GitHub. We know that a strong culture of accessibility is the best way to scale accessibility across the organization. As of this moment, our accessibility culture is built on company-wide training for every Hubber, our Engineering Fundamentals program, our Accessibility Design Bootcamp, our Accessibility Champions program, and the Primer design system. However, we also know that accessibility is never done. GitHub is continually growing and evolving to meet the needs of developers. Our accessibility program must grow with it. Stay tuned to the GitHub blog and accessibility.github.com for the latest news on GitHub accessibility. And, as always, please share feedback on our accessibility community discussion page.

The post Scaling accessibility within GitHub and beyond appeared first on The GitHub Blog.

Microsoft now requires Office Add-in developers to prompt users for permission to access their device capabilities. This applies to add-ins that run on web versions of Microsoft Word, Excel, Outlook, and PowerPoint in Chromium-based browsers (such as Microsoft Edge or Google Chrome). To prompt your users for permissions, you can now implement the Device Permission API in your add-in. A user’s device capabilities include their camera, geolocation, and microphone. This change doesn’t impact add-ins that run in Office on Windows, on Mac, or other browsers like Safari.

If your organization has an existing add-in or is building one that requires access to a user’s device capabilities and will run in Office on the web on Chromium-based browsers, your developers must implement the Device Permission API. This API shows a dialog to the user that contains the following: 

• The name of the add-in requesting permission. 

• The device capabilities the add-in needs to use. 

• The options for the user to Allow, Allow once, or Deny permission to the add-in. 

When a user selects Allow or Deny, their permission is stored in the cache. This prevents the same add-in from prompting the user for the same permission. To change an add-in’s permission to a user’s device capabilities, the user must uninstall, then reinstall the add-in. Alternatively, they can also clear their browser cache. 

In Outlook add-ins that implement event-based activation, browser permissions aren’t inherited. Additionally, the Device Permission API isn’t supported or recommended in these add-ins. 

To learn more about how the user is prompted for permission to their device capabilities, see View, manage, and install add-ins for Excel, PowerPoint, and Word. 

Thank you for your continued support of Office Add-ins on all platforms. 

Additional resources

Office Dev Center 

Privacy and security in Office Add-ins 

The post Device Permission Prompt API available for Office Add-ins on the web appeared first on Microsoft 365 Developer Blog.

Media queries have been around almost as long as CSS itself — and with no flex, no grid, no responsive units, and no math functions, media queries were the most pragmatic choice available to make a somewhat responsive website.

In the early 2010s, with the proliferation of mobile devices and the timely publication of Ethan Marcotte’s classic article “Responsive Web Design”, media queries became much needed for crafting layouts that could morph across screens and devices. Even when the CSS Flexbox and Grid specifications rolled out, media queries for resizing never left.

While data on the actual usage of media queries is elusive, the fact that they have grown over time with additional features that go well beyond the viewport and into things like user preferences continues to make them a bellwether ingredient for responsive design.

Today, there are more options and tools in CSS for establishing layouts that allow page elements to adapt to many different conditions besides the size of the viewport. Some are more widely used — Flexbox and Grid for certain — but also things like responsive length units and, most notably, container queries, a concept we will come back to in a bit.

But media queries are still often the de facto tool that developers reach for. Maybe it’s muscle memory, inconsistent browser support, or that we’re stuck in our ways, but adoption of the modern approaches we have for responsive interfaces seems slow to take off.

To be clear, I am all for media queries. They play a significant role in the work we do above and beyond watching the viewport size to make better and more accessible user experiences based on a user’s OS preferences, the type of input device they’re using, and more.

But should media queries continue to be the gold standard for responsive layouts? As always, it depends, but

It is undeniable that media queries have evolved toward accessibility solutions, making space for other CSS features to take responsibility for responsiveness.

Media queries seemed like a great solution for most responsive-related problems, but as the web has grown towards bigger and more complex layouts, the limits of media queries are more prevalent than ever.

Problem #1: They Are Viewport-Focused

When writing media query breakpoints where we want the layout to adapt, we only have access to the viewport’s properties, like width or orientation. Sometimes, all we need is to tweak a font size, and the viewport is our best bud for that, but most times, context is important.

Components on a page share space with others and are positioned relative to each other according to normal document flow. If all we have access to is the viewport width, knowing exactly where to establish a particular breakpoint becomes a task of compromises where some components will respond well to the adapted layout while others will need additional adjustments at that specific breakpoint.

So, there we are, resizing our browser and looking for the correct breakpoint where our content becomes too squished.

The following example probably has the worst CSS you will see in a while, but it helps to understand one of the problems with media queries.

That same layout in mobile simply does not work. Tables have their own set of responsive challenges as it is, and while there is no shortage of solutions, we may be able to consider another layout using modern techniques that are way less engineered.

We are doing much more than simply changing the width or height of elements! Border colors, element visibility, and flex directions need to be changed, and it can only be done through a media query, right? Well, even in cases where we have to completely switch a layout depending on the viewport size, we can better achieve it with container queries.

Again, Problem #1 of media queries is that they only consider the viewport size when making decisions and are completely ignorant of an element’s surrounding context.

That may not be a big concern if all we’re talking about is a series of elements that are allowed to take up the full page width because the full page width is very much related to the viewport size, making media queries a perfectly fine choice for making adjustments.

See the Pen Responsive Cards Using Media Queries [forked] by Monknow.

But say we want to display those same elements as part of a multi-column layout where they are included in a narrow column as an <aside> next to a larger column containing a <main> element. Now we’re in trouble.

A more traditional solution is to write a series of media queries depending on where the element is used and where its content breaks. But media queries completely miss the relationship between the <main> and <aside> elements, which is a big deal since the size of one influences the size of the other according to normal document flow.

See the Pen Responsive Cards Using Media Queries Inside Container [forked] by Monknow.

The .cards element is in the context of the <aside> element and is squished as a result of being in a narrow column. What would be great is to change the layout of each .card component when the .cards element that contains them reaches a certain size rather than when the viewport is a certain size.

That’s where container queries come into play, allowing us to conditionally apply styles based on an element’s size. We register an element as a “container,” which, in our current example, is the unordered list containing the series of .card components. We’re essentially giving the parent selector a great deal of power to influence the current layout.

.cards {
  container-name: cards;
}

Container queries monitor an element by its size, and we need to tell the browser exactly how to interpret that size by giving .cards a container-type, which can be the container’s size (i.e., in the block and inline directions) or its inline-size (i.e., the total length in the inline direction). There’s a normal value that removes sizing considerations but allows the element to be queried by its styles.

.cards {
  container-name: cards;
  container-type: inline-size;
}

We can simplify things down a bit using the container shorthand property.

.cards {
  container: cards / inline-size;
}

Now, we can adjust the layout of the .card components when the .cards container is a certain inline size. Container queries use the same syntax as media queries but use the @container at-rule instead of @media.

.cards {
  container: cards / inline-size;
}

@container cards (width < 700px) {
  .cards li {
    flex-flow: column;
  }
}

Now, each .card is a flexible container that flows in the column direction when the width of the .cards container is less than 700px. Any wider than that, we have the same to lay them out in a row direction instead.

See the Pen Responsive Cards Using Container Queries [forked] by Monknow.

Style queries are a cousin to container queries in the sense that we can query the container’s styles and conditionally apply style changes to its children, say changing a child element’s color to white when the container’s background-color is set to a dark color. We’re still in the early days, and support for style queries and browser support is still evolving.

I hope this gives you a sense of how amazing it is that we have this context-aware way of establishing responsive layouts. Containers are a completely new idea in CSS (although we’ve used the term synonymously with “parent element” for ages) that is novel and elegant.

NO! While media queries have been the go-to solution for responsive design, their limitations are glaringly obvious now that we have more robust tools in CSS that are designed to solve those limits.

That doesn’t make media queries obsolete — merely a different tool that’s part of a larger toolset for building responsive interfaces. Besides, media queries still address vital accessibility concerns thanks to their ability to recognize a user’s visual and motion preferences — among other settings — at the operating system level.

So, yes, keep using media queries! But maybe reach for them sparingly since CSS has a lot more to offer us.

We’re pleased to announce that the May 2024 release (version 1.9.0) of the Azure Developer CLI (azd) is now available. As always, you can learn about how to get started with the Azure Developer CLI by visiting our documentation.

Here’s what’s new in azd this month:

• New demo mode (azure-dev#3848)
• .NET Aspire enhancements

Our team is working on some exciting updates in relation to AI, so this month’s release is a little smaller than usual. Stay tuned though because we’ll have announcements in relation to Microsoft Build. The conference kicks off on May 21 and registration is still open. You can register for free to attend virtually. We look forward to seeing you there!

New demo mode

We love seeing azd‘s presence grow and it being included in demos! When showing azd outputs publicly, it was a common practice to blur your subscription ID. Because that can be tedious, we’re introducing a new demo mode in which your subscription ID won’t be displayed in the console. No more spending your precious time blurring IDs before uploading a video of you building cool stuff with azd!

This mode introduces the environment variable: AZD_DEMO_MODE. To enable demo mode, run:

export AZD_DEMO_MODE true

If you want demo mode to persist across reboots, you can also run:

setx AZD_DEMO_MODE true

or in PowerShell:

$env:AZD_DEMO_MODE="true"

.NET Aspire enhancements

As a part of azd‘s continued partnership with .NET Aspire, we made a couple noteworthy changes:

• Support for multiple endpoints
• Aspire dashboard support (Region availability varies. As of blog publishing, the support is available in the westcentralus region.)

To learn more about these and other enhancements, check out .NET Aspire’s latest product updates.

Other changes and enhancements

We also added smaller enhancements and fixed issues requested by users that should improve your experience working with the azd. Some notable changes include:

Other features for azd core:

• Filter azd template list using tags (azure-dev#3840)

Bug fixes for azd core:

• Fix cross-build configuration (azure-dev#3707)
• Allow azd env refresh without Bicep (azure-dev#3787)
• Aspire – support args on project.v0 and dokerfile.v0 resources (azure-dev#3678)

New Templates

We officially have over 100 templates in our Awesome-azd template gallery! New templates this month include:

• Chat with your data – Solution accelerator
• Zip Deploy Azure Function from community contributor FBoucher
• RAG using Semantic Kernel with Azure OpenAI and Azure Cosmos DB for MongoDB vCore from community contributor john0isaac
• Serverless AI Chat with RAG using LangChain.js

Do you have an azd template you’d like to share with the rest of the community? You can learn how to with our contributor guide.

Community contributions

We’d also like to extend a special thanks to the community contributors of this release:

• pamelafox:
  • Update search-services.bicep with disableLocalAuth compatibility (azure-dev#3677)
  • Update cognitiveservices.bicep with disableLocalAuth compatibility (azure-dev#3769)

You can use the Azure Developer CLI from:

• Your terminal of choice on Windows, Linux, or macOS.
• Visual Studio Code or GitHub Codespaces by downloading the extension from the Marketplace, or installing it directly from the extension view (Ctrl + Shift + X for Windows or Cmd + Shift + X for macOS) in Visual Studio Code.
• Visual Studio by enabling the preview feature flag.
• You can learn more about the Azure Developer CLI from our official documentation.
• If you run into any problems or have suggestions, file an issue or start a discussion in the Azure Developer CLI repository. You can also try checking out our troubleshooting documentation.

The post Azure Developer CLI (azd) – May 2024 Release appeared first on Azure SDK Blog.