Azure DevOps–How to change the default iteration?

After upgrading to Azure DevOps 2019, I got a question from a customer asking how to change the default iteration used when creating new work items. By default the current iteration is used. If you are creating user stories, this is probably not what you want as these user stories should first be analyzed, groomed, … before they can be planned inside a specific iteration/sprint.

Fortunately this is something that can be changed easily at the team level:

• Click on the Show Team Profile  icon on the Kanban board:

• Click on Team settings:

• Go to Iterations and Areas:

• Click on Iterations:

• Now you change the default iteration how you want:

Fork–A fast and friendly GIT client

Tooling is important and great tools can make a difference. Especially when you are using so rich and complex as GIT can be.

Last week I discovered a new GIT client; Fork.

I was especially impressed by the interactive rebase functionality. Could be a lifesaver if you are now afraid to use rebase…

Remarks: My current favorite is GitKraken in case you want to know. But I’m giving Fork a try and so should you…

Orleans–Fire and forget

The basic building block in Orleans is a ‘Grain’. A grain is an atomic unit of isolation, distribution, and persistence. A grain perfectly matches the OO principles as it encapsulates state of an entity and encodes its behavior in the code logic.

The ‘normal’ way to communicate between Grains is through message passing. This is greatly simplified thanks to the async/await programming model in C# combined with some code generation voodoo. It almost ‘feels’ like normal method invocations.

A consequence of the async programming model is that you always should ‘await’ the results. However there are some situations where you don’t care about the results and want to call another grain in a ‘fire-and-forget’ mode.

To achieve this you can use the InvokeOneWay() extension method on a GrainReference:

Testing–Faking a delay in SQL Server

To test the timeout settings of my application, I needed a query that exceeds a certain time.

This was not that hard to achieve in SQL Server thanks to the WAITFOR statement. This statement blocks the execution of a batch, stored procedure, or transaction until a specified time or time interval is reached, or a specified statement modifies or returns at least one row.

----Delay for 10 seconds
WAITFOR DELAY '000:00:10'
SELECT 'Hello finally!'
GO

More information: https://docs.microsoft.com/en-us/sql/t-sql/language-elements/waitfor-transact-sql?view=sql-server-ver15

MassTransit - A convention for the message type {typename} was not found

While preparing a presentation I created a simple demo app where I wanted to publish a message to a queue.

My first (naïve) attempt looked like this:

This failed with the following error message:

A convention for the message type {typename} was not found

What was my mistake?

In MassTransit you have to make a difference between sending a message and publishing a message. Whereas publishing a message doesn’t require any extra configuration, sending a message does. Why? Because when sending a message you directly target a queue. MassTransit has to know which queue the message should be send to.

We have 2 options to make this work:

1) You specify the target queue using a convention:

2) You use the ISendEndpointprovider to specify a queue:

Reconfigure the ElasticSearch Windows Service

If you are running ElasticSearch on a Windows Cluster you probably are using a Windows Service to run it in the background and make it start automatically at boot time.

This Windows Service feature is available out-of-the-box if you use the .zip package.

Some settings of ElasticSearch are managed as command-line arguments(e.g. the min and max memory usage). To manipulate these settings when using the Windows Service, you have to go through the ElasticSearch Windows Service Manager.

• To open the manager, go the ElasticSearch installation folder. (e.g. c:\elasticsearch-7.4.0\)
• Browse to the bin folder (where you should find a elasticsearch-service.bat file)
• Run the following command:
• elasticsearch-service.bat manager

This will open a GUI where you can manage multiple ElasticSearch settings:

Remark: Most changes will require a restart of the service.

ASP.NET Core gRPC–Unary RPC vs Streams

When creating your gRPC implementation you have to be aware about the difference between Unary RPC and Streams.

Unary RPC

This is the simplest type of RPC, where the client sends a single request and gets back a single response. This is the simplest approach and similar to what we know when using WCF.

Streams

With streaming we have to make a difference between server streaming, client streaming and bidirectional streaming.

A server-streaming RPC is most similar to the Unary RPC, the only difference is that the server sends back a stream of responses instead of a single response after getting the client’s request message. After sending back all its responses, the server’s status details (status code and optional status message) and optional trailing metadata are sent back to complete on the server side. The client completes once it has all the server’s responses.

A client-streaming RPC turns things around, the client sends a stream of requests to the server instead of a single request. The server sends back a single response, typically but not necessarily after it has received all the client’s requests, along with its status details and optional trailing metadata.

In a bidirectional streaming RPC, the call is initiated by the client calling the method and the server receiving the client metadata, method name, and deadline. The server can choose to send back its initial metadata or wait for the client to start sending requests. What happens next depends on the application, as the client and server can read and write in any order - the streams operate completely independently.

It is important that you are aware of the difference as it can greatly impact the performance characteristics of your application. Working with streams can help you reduce the memory footprint of your application as you don’t have to buffer the whole response in memory before returning it to the client. Another advantage is that the client can start processing before all data is returned from the server(or the other way around).

More information: https://grpc.io/docs/guides/concepts/