Microsoft just finished its 48-hour live online event, MSBuild 2020, and I enjoyed it immensely! I was fortunate to be invited for two sessions: a panel discussion on building serverless APIs, and a connect with the community session. I also threw in some pixel art just for fun, more on that later.
It is now May 12th, four days after the ServerlessDays Amsterdam 2020 virtual conference. The conference was incredibly fun and slightly terrifying at the same time.
I had two roles during the conference; in the morning, I would do the hosting with Lian Li (who really has a talent for MC-ing), and during the entire day, I would be responsible for the technical part. In specific that means that I’d be calling in speakers & panelists into the Skype group call, and controlling the streaming software (OBS), switching scenes, configuring webcam sources, shared screens, names, and starting the prerecorded sessions.
Well, ok, not everyone, but a lot of meetups & conferences which were previously only offline and IRL have an online presence these days. It really lowers the boundary of attending these events, and I think this is great!
ServerlessDays Amsterdam (which I’m co-organizing) is also moving online for both the meetups and the conference. In this post, I’m highlighting some details on how we’re setting this up.
This is the fourth part of the Durable Functions series where I look into the DurableOrchestrationClient. In the video I’ll talk about the Human Interaction pattern, which deals with raising events from the client and waiting for events in the orchestrator.
Here’s the video, please give it a thumbs up if you like it and subscribe to my channel so you’ll be notified of new videos.
The source code that is used for this demo can be found on GitHub.
In my previous post, I wrote about why and how I created the Azure Functions Updates Twitterbot. This bot has been posting updates about Azure Functions related GitHub repositories (and Azure Service announcements) since February 2019, so that’s well over 6 months. It monitors 24 repositories, including itself, and the Azure Service Updates RSS feed, filtered for Azure Functions related updates. The full list of sources is listed on GitHub. The function app that runs the bot has captured 128 GitHub releases, 8 Azure Service Update posts and posted 154 messages to Twitter (the introductory tweets were posted manually).
In this post, I want to highlight some of the actions I took and the insights I’ve got after I put the Twitterbot live. I’m going to cover: failure & resiliency, monitoring & alerts, performance, and costs.
This post is the third part of a series of blogs/vlogs to discover the Durable Functions API.
Go to https://twitter.com/az_func_updates and follow that account to stay up to date with new Azure Functions releases!
This post is the second part of a series of blogs/vlogs to discover the Durable Functions API.
This post is the first part of a series of blogs/vlogs to discover the Durable Functions API.
Whenever I see examples or implementations of Azure Functions I always see this:
[FunctionName("myfunction")]
Where the function name is present as a direct string literal. I’m not questioning that it is a string because that’s simply the way the FunctionName attribute works currently. I’m more concerned how the string got there.
I’d like to show two ways to refer to function names in a safe and consistent way. This is especially useful when you’re using Durable Functions and need to refer to activity function names in your orchestration function.
