Everyone is live streaming!

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.

Human Interaction Pattern

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.

Resources

The source code that is used for this demo can be found on GitHub.

Links to other posts in this series

• Starting Orchestrations (DurableOrchestrationClient Part 1)
• Retrieving the Orchestration Status (DurableOrchestrationClient Part 2)
• Purge & Terminate Orchestrations (DurableOrchestrationClient Part 3)

Some quick facts about the Twitterbot

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.

DurableOrchestrationClient(Base) class - Purge & Terminate

This post is the third part of a series of blogs/vlogs to discover the Durable Functions API.

TL;DR

Go to https://twitter.com/az_func_updates and follow that account to stay up to date with new Azure Functions releases!

DurableOrchestrationClient(Base) class - Retrieving status

This post is the second part of a series of blogs/vlogs to discover the Durable Functions API.

DurableOrchestrationClient(Base) class - Starting & waiting for completion

This post is the first part of a series of blogs/vlogs to discover the Durable Functions API.

Function Names in the Wild

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.

The Function Chaining Pattern

This is the third part of the Durable Functions series. In this video I’ll talk about the function chaining pattern which can be used to create function workflows.

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.

Resources

The source code that is used for this demo can be found on GitHub.

Eternal orchestrations & external events

This is the second part of the Durable Functions series. In this video I’ll talk about eternal function orchestrations and external events.

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.

Resources

The source code that is used for this demo can be found on GitHub.

Guidelines for Function Apps

Earlier today I read a tweet where a developer wasn’t sure when to group several Azure Functions in one Function App. The Azure Function engineers responded swiftly and they’ll extend the official docs with some guidelines in this area soon. I think this is a really interesting topic so let’s start with a few ideas of my own.

Durable Functions Videos

I’ve decided to create some video’s to explain and demonstrate the Durable Functions framework.

The first video covers a very basic ‘Hello World’ example and shows how to use the OrchestrationClient and DurableOrchestrationContext objects.

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.

Resources

The source code that is used for this demo can be found on GitHub.

Durable Function Walkthrough

In my previous post I gave an introduction on Durable Functions, an extension on Azure Functions which can be used to write stateful and long-running orchestration functions.

In this post we’ll look into more detail at the HttpStart and HelloWorld functions from the previous post. We’ll run them locally by triggering them using Postman and looking at the responses.

Durable Functions

Since my Getting started with Serverless Architectures using Azure Functions session at Techdays I’ve been closely monitoring the latest news about Azure Functions. The most recent addition is called Durable Functions. With this extension long running and stateful function orchestrations can be developed. This is a welcome addition to the Azure serverless product suite since it is now much easier to implement function chaining and fan-in/fan-out messaging scenarios.

Techdays 2017

A few weeks ago I was presented with a fantastic opportunity, to speak at the biggest Microsoft conference in the Netherlands, TechDays 2017. The session was about my favorite subjects nowadays, serverless architectures and Azure Functions.

Below you can find my slides of this session and a link to the demo I made.

Holiday Project

This summer holiday I’m working on a hobby project which involves a Raspberry Pi Zero and a Pi camera module. Part of the solution is uploading the pictures the Pi takes to the cloud, Microsoft Azure to be more specific. I plan to write a couple of blog posts about this project. This first post is about installing the Azure SDK on the Pi Zero.

In my previous post I described how to setup an automated build for a Sitecore Helix project. In this post I’ll be covering the configuration of the automated deployment environment using Octopus Deploy.

In my previous posts I’ve shown how our team is able to add new feature or foundation modules easily. Now let’s take a look at the effect of the modular architecture on the build and packaging of a Sitecore Helix style solution. This is a topic which is receiving loads of attention lately and has been blogged about before by other Sitecore community fanboys ;).

In my previous post I showed how I got to a solution which allows the developers in my team to create new Feature and Foundation modules with ease.

I showed the moving parts of the solution but I did not go into much detail of the most important part so that’s what I’ll do in this post. This would be particularly useful if you want to change the script yourself to match it to your needs.

Embracing Sitecore Helix

Ever since I attended Anders Laub his presentation at SUGCON Europe 2015 about component based architecture in Sitecore solutions I have been a strong advocate of these modular principles. I even went to Pentia to learn about this in full detail.

I was very happy to see that Sitecore finally got their act together and published their Helix guidelines and recommended practices on the web.

For the last half year my team is using the modular Helix style architecture with success and it’s time to share some experiences.

Time for an upgrade

I finally made some time available to work on this blog. There were a couple of things I wanted to improve since I moved to GitHub Pages/Jekyll.

1. Better looking index page. Before todays change it was a very simple (and boring) bulleted list of links containing the date and title of individual blogposts.
2. Improved content structure. Having a well defined content structure improves SEO.
3. Higher performance. Faster page loads makes both users and Google happy.

‘Uncle Bob’ wrote the following in Clean Code: A Handbook of Agile Software Craftsmanship:

“The ratio of time spent reading (code) versus writing is well over 10 to 1 … (therefore) making it easy to read makes it easier to write.”

So think about that when you write your next bit of code. You need to make sure your code is easily readable and understandable for others, you hardly ever write code just for yourself.

Sitecore PowerShell Extensions first encounter

Although I had heard of Sitecore PowerShell Extensions (SPE) several years ago I never used it myself until earlier this month. My interest was raised again during the Accelerated development with Sitecore PowerShell Extensions session by Adam Najmanowicz during SUGCON Europe 2016.

Right after I got back from SUGCON the project I was working on had a nice challenge. Workflows were being set on existing templates and hundreds of content items had already been created using these templates and had no workflow or workflow state set on them. We needed a way to update the content items with the workflow that was set on the Default workflow field on the updated templates.

For me this was an excellent opportunity to try SPE. I wrote a Sitecore PowerShell script to update Workflow and Workflow state fields, posted it in a gist and tweeted about it. I got in contact with Michael West and Adam Najmanowicz (the developers of SPE) who made some excellent suggestions to improve the user friendliness of the script.

A colleague showed me this error today in the Sitecore log:

ERROR There is no appropriate index for [item path - {GUID}]. You have to add an index crawler that will cover this item

‘I’ve never seen that!’ was my first reaction…

This issue occurred when a Sitecore zip package with content items was installed on another environment. There were quite some lines in the Sitecore log which mentioned the same error but for different item paths and GUIDS. I looked up the GUIDS on my local machine and they were all Bucket folder items with no content items in them.

Here’s an example of how that looks like (when you’ve checked the Buckets option in the View toolbar):

Deploying Sitecore items with Sitecore.Ship

As I mentioned in the previous post Sitecore.Ship can be used to install Sitecore update or zip packages by posting HTTP requests to the Sitecore site.