I started by creating a small Ansible project with a simple layout: an inventory, a CoreDNS config (Corefile), a hosts file for local records, and a playbook to glue everything together. The folder looked like this:

infra/
  coredns/
    files/
      Corefile
      hosts
    coredns.yml
    inventory.ini

My Corefile defines a basic forwarding resolver plus an internal zone:

. {
    forward . 1.1.1.1
    cache 30
}

whosane.local {
    file /etc/coredns/hosts
    reload
}

The Ansible playbook handles both configuration and the Podman container. First it copies the CoreDNS files to the host, then it runs CoreDNS as a Podman container:

- hosts: homelab
  gather_facts: false
  become: true

  tasks:
    - name: Copy CoreDNS config
      copy:
        src: files/
        dest: /opt/coredns/

    - name: Run CoreDNS container
      containers.podman.podman_container:
        name: coredns
        image: coredns/coredns:latest
        state: started
        restart_policy: always
        ports:
          - "53:53/tcp"
          - "53:53/udp"
        volumes:
          - "/opt/coredns:/etc/coredns:Z"
        command: ["-conf", "/etc/coredns/Corefile"]

One thing I really wanted was for the DNS service to survive reboots and behave like a “real” system service. Instead of manually writing unit files, I used Ansible’s Podman integration to generate a systemd unit for the container and enable it automatically:

    - name: Generate systemd unit for CoreDNS
      containers.podman.podman_generate_systemd:
        name: coredns
        dest: /etc/systemd/system

    - name: Enable and start CoreDNS systemd service
      systemd:
        name: container-coredns.service
        enabled: yes
        state: started

After running the playbook, CoreDNS comes up as a container, is managed by systemd, and persists across reboots without me having to think about it. Adding new internal services is as simple as editing the hosts file and rerunning the playbook. For a home lab, this combination of Podman, Ansible, CoreDNS, and systemd feels surprisingly close to how modern production infrastructure is built—but compact enough to live happily on a single laptop.

func divide(a, b int) (int, error) {
    if b == 0 {
        return 0, fmt.Errorf("division by zero")
    }
    return a / b, nil
}

This divide function returns an error if b is zero. The caller must explicitly check for this error. This explicit error checking enhances code clarity and prevents unexpected crashes.

result, err := divide(10, 2)
if err != nil {
    fmt.Println("Error:", err)
} else {
    fmt.Println("Result:", result)
}

Go's error type is an interface, allowing for flexibility in error representation. Custom error types can be created to provide more context or detail. This example demonstrates the use of a custom error:

type MyError struct {
    Message string
}

func (e *MyError) Error() string { return e.Message }

func myFunction() error {
    return &MyError{Message: "Something went wrong!"} 
}

This MyError type provides a structured way of representing specific errors. The Error() method satisfies the error interface requirement, allowing it to be used just like any other error value. The practice of returning errors as function parameters encourages mindful and robust error management practices.

The errors package provides useful functions for working with errors, such as errors.Is and errors.As, facilitating complex error checks without writing verbose conditional statements. A good understanding of error handling enables building secure, robust, and maintainable applications in Go.

The foundation of our structure centers around separating concerns. We'll group related files based on their function, creating distinct folders for services, models, and any other necessary components. This allows for easier navigation and understanding of the code's purpose. Let's assume we're building a simple e-commerce application.

├── cmd
│ └── main.go
├── internal
│ ├── models
│ │ └── product.go
│ ├── services
│ │ └── product_service.go
│ └── utils
│   └── database.go
└── go.mod

The cmd folder holds the main application entry point (main.go). The internal folder encloses our application's internal packages, ensuring they are not accessible externally. models contains data structures representing our application's domain (e.g., product.go), services contains business logic related to those models (e.g., product_service.go), and utils includes common utility functions (e.g., database interaction in database.go).

This structure promotes modularity. Each service can clearly access and operate on its corresponding models. The utils folder helps to centralize reusable functionality, preventing code duplication and improving consistency. For instance, database interactions can be encapsulated in utils/database.go to ensure all services use the same access methods.

In this e-commerce example, the product_service.go might handle adding, updating, retrieving, and deleting products. It would directly utilize the Product struct defined in models/product.go and the database functions from utils/database.go. This clear separation makes code easier to read, understand, and maintain, fostering collaborative development and seamless scaling of your Go application.

For more advanced scenarios, consider exploring packages like https://cs.opensource.google/go/x/tools for improved code formatting, and further delve into dependency injection patterns for cleaner separation of concerns and better testability. Remember that a consistent and well-defined folder structure is a cornerstone of successful software development.

The if Statement

The if statement allows you to execute commands conditionally. Its basic structure involves a test condition followed by one or more commands that are executed if the condition evaluates to true. A simple example might look like this:

#!/bin/bash

number=10

if [ $number -gt 5 ]; then
    echo "The number is greater than 5"
fi

This script checks if the variable number is greater than 5. The -gt operator performs the numerical comparison. If true, the message is printed. The fi keyword marks the end of the if block. More complex conditions can be created using elif (else if) and else clauses.

The for Loop

for loops are ideal when you need to execute a block of code multiple times. Bash offers several ways to use for loops, including iterating over a sequence of numbers or a list of words. A common pattern iterates over a set of files:

#!/bin/bash

for file in *.txt; do
    echo "Processing file: $file"
done

This script processes all files ending in .txt in the current directory. Each filename is assigned to the variable file in each iteration, and the done keyword marks the end of the loop. Another way to use the for loop is by using an array:

#!/bin/bash

myArray=(
    "apple"
    "banana"
    "cherry"
)

for i in "${myArray[@]}"; do 
    echo "item is: $i"
done

Output:

item is: apple
item is: banana
item is: cherry

Further Reading

To delve deeper, explore Bash's case statement for multiple-condition decision-making and the while and until loops for conditions that are checked before and after each iteration, respectively. The Bash manual provides comprehensive documentation on these and other control flow structures.

One major advantage of Bicep is its improved readability and writability. Unlike ARM templates, which use a JSON structure that can become complex and difficult to read, Bicep utilizes a more concise and intuitive syntax. This makes Bicep templates easier to write, understand, and maintain, particularly for large deployments.

Another key benefit is the improved developer experience. Bicep offers features like auto-completion, linting, and built-in functions that streamline the development process and reduce the risk of errors. This increased developer productivity leads to faster and more reliable deployments.

Consider the following example: deploying a virtual network and subnet. In ARM, this would require a nested JSON structure, while in Bicep, the same task can be accomplished with less verbose code. This difference becomes even more significant when deploying complex deployments involving multiple dependent resources.

Let's illustrate with a simple example. Deploying a simple storage account in ARM requires extensive JSON nesting, whereas in Bicep, the structure is much cleaner:

param location string = resourceGroup().location
param storageAccountName string

resource storageAccount 'Microsoft.Storage/storageAccounts@2021-09-01' = {
  name: storageAccountName
  location: location
  kind: 'StorageV2'
  sku: {
    name: 'Standard_LRS'
  }
}

Bicep's improved syntax and enhanced developer experience make it a compelling alternative to ARM templates for infrastructure-as-code deployments in Azure. Its conciseness and readability improve maintainability and reduce the likelihood of errors, ultimately leading to more efficient and reliable deployments.

For further reading and more advanced Bicep examples, refer to the official Microsoft documentation on Bicep: https://learn.microsoft.com/en-us/azure/bicep/

First, you'll need to install the node-fetch library: npm install node-fetch. Then, you will need a Telegram Bot token, which you can obtain from BotFather on Telegram. This token will be used to authenticate your bot's requests to the Telegram API.

Here's an example of sending a simple text message:

const fetch = require('node-fetch');

async function sendMessage(chatId, text, botToken) {
    const response = await fetch(`https://api.telegram.org/bot${botToken}/sendMessage`, {
        method: 'POST',
        headers: {
        'Content-Type': 'application/json'
        },
        body: JSON.stringify({ chat_id: chatId, text: text })
    });
    const data = await response.json();
    console.log(data);
}

// Example usage:
const chatId = '-123456789'; // Replace with your chat ID
const botToken = 'YOUR_BOT_TOKEN'; // Replace with your bot token
const message = 'Hello from Node.js!';
sendMessage(chatId, message, botToken);

Sending photos requires a slightly different approach. You'll need to send a multipart/form-data request containing the photo's data:

// ... other code ...
async function sendPhoto(chatId, photoPath, botToken) {
    const formData = new FormData();
    formData.append('chat_id', chatId);
    formData.append('photo', fs.createReadStream(photoPath));
    const response = await fetch(`https://api.telegram.org/bot${botToken}/sendPhoto`, {
        method: 'POST',
        body: formData
    });
// ... handling the response ...
}

This functionality can be used in various applications, such as creating chatbots for customer service, automated alerts, or personal task management systems.

For more advanced features and detailed information about the Telegram Bot API, refer to the official Telegram Bot API documentation. You may also want to consider using libraries built on top of the fetch API for more robust error handling and other advanced features.

To get started, you’ll need to install GORM and the SQLite driver. You can do this using Go modules. Run the following command in your terminal:

go get -u gorm.io/gorm
go get -u gorm.io/driver/sqlite

Once the packages are installed, you can start using GORM with SQLite. First, import the necessary packages and define a model. A model in GORM is a Go struct that represents a table in the database. Here’s an example:

package main

import (
    "gorm.io/driver/sqlite"
    "gorm.io/gorm"
)

type User struct {
    ID   uint
    Name string
    Age  int
}

func main() {
    db, err := gorm.Open(sqlite.Open("test.db"), &gorm.Config{})
    if err != nil {
        panic("failed to connect database")
    }

    db.AutoMigrate(&User{})
}

In this example, we define a User struct and use db.AutoMigrate to automatically create the corresponding table in the SQLite database. The database file, test.db, will be created in the same directory as your Go program.

Once your database and table are set up, you can start performing CRUD (Create, Read, Update, Delete) operations. Here’s how you can insert a new record:

user := User{Name: "John", Age: 30}
db.Create(&user)

To query the database, you can use GORM’s methods like First, Find, and Where. For example, to retrieve the first user with the name "John":

var result User
db.First(&result, "name = ?", "John")

Updating and deleting records is just as straightforward. To update a user’s age:

db.Model(&User{}).Where("name = ?", "John").Update("age", 31)

And to delete a user:

db.Delete(&User{}, "name = ?", "John")

To fetch a user by their ID using GORM, you can use the First method. This method allows you to query the database and retrieve the first record that matches the given conditions. Here’s how you can get a user by their ID:

// Define a variable to hold the user record
record := &User{ID: 10}

// Query the database for the user with ID 10
db.First(record)

// Check if the record was found
if record.ID != 0 {
    fmt.Printf("User found: %+v\n", record)
} else {
    fmt.Println("User not found")
}

In this example, record is initialized with the ID of the user you want to retrieve. When db.First(record) is called, GORM will query the database for a user with the specified ID. If the user is found, the record variable will be populated with the user’s data. If no user is found, the ID field will remain 0, which you can use to check if the record exists.

This approach is clean and concise, leveraging GORM’s ability to work directly with structs. It’s a great way to fetch specific records without writing complex queries.

GORM’s simplicity and SQLite’s lightweight nature make them a great combination for small-scale applications or when you need a quick and easy database solution. With just a few lines of code, you can set up your database, define models, and perform CRUD operations without worrying about the underlying SQL.

git merge creates a new merge commit that combines the histories of two branches. This preserves the complete history of both branches, providing a comprehensive view of development. While simple, the resulting history can become complex in projects with frequent merging. Here's an example:

git checkout main
git merge feature-branch

git rebase, on the other hand, rewrites the project history by applying the commits from one branch onto another linearly. This results in a cleaner, more streamlined history, making it easier to follow the progression of changes. However, rewriting history is powerful but potentially disruptive, especially in collaborative settings; it's essential to use it with caution on shared branches.

git checkout feature-branch
git rebase main
git checkout main
git merge feature-branch

Consider a scenario where two developers work on separate features concurrently. git merge maintains both individual feature branches, demonstrating how these features developed independently, while git rebase integrates changes chronologically. The choice depends on prioritization; merging for clarity of changes or rebasing for a cleaner, linear history.

For more detailed information on rebasing and merging, use the official Git documentation. Understanding the nuances of these commands is critical for every software developer.

async function asyncReduceExample() {
    const promises = [
        fetch('https://api.example.com/data1').then(res => res.json()),
        fetch('https://api.example.com/data2').then(res => res.json()),
        fetch('https://api.example.com/data3').then(res => res.json()),
    ];

    const result = await promises.reduce(async (accumulator, currentPromise) => {
        const acc = await accumulator;
        const currentValue = await currentPromise;
        return [...acc, currentValue];
    }, Promise.resolve([]));

    console.log(result);
}

Notice the use of async in the reduce callback, allowing us to use await to resolve each Promise before proceeding. The initial value of the accumulator is set using Promise.resolve([]) to ensure it's a promise that resolves to an empty array. This ensures that the reduce function handles the asynchronous operations correctly by resolving the accumulator before it is used in subsequent iterations. Each Promise is fetched in sequence, and the results are aggregated in the result array which is logged to the console.

For more complex scenarios, error handling is crucial. Here's a revised example that handles potential errors during the asynchronous operations:

async function asyncReduceWithErrorHandling() {
    const promises = [
        fetch('https://api.example.com/data1').then(res => res.json()),
        fetch('https://api.example.com/data2').then(res => res.json()),
        fetch('https://api.example.com/data3').then(res => res.json()),
    ];

    try {
        const result = await promises.reduce(async (accumulator, currentPromise) => {
            const acc = await accumulator;
            const currentValue = await currentPromise;
            return [...acc, currentValue];
        }, Promise.resolve([]));
        console.log('Success:', result);
    } catch (error) {
        console.error('Error:', error);
    }
}

Why Modular Infrastructure Matters

Modular infrastructure design focuses on breaking down large, monolithic configurations into smaller, reusable units. This approach simplifies maintenance and enables teams to rapidly adapt to changing requirements. With Pulumi and C#, you can encapsulate common patterns—such as VNet configurations, Kubernetes clusters, or storage setups—into self-contained modules. These modules can then be packaged as NuGet libraries, making them easily shareable across teams or projects. For instance, a team might create a "StandardVNet" NuGet package that provisions a virtual network with predefined subnets and security rules, allowing other teams to consume it without reinventing the wheel.

Building a Pulumi Module in C

Creating a reusable module in Pulumi involves defining infrastructure components in a structured manner. Consider the example below, where we encapsulate the provisioning of an Azure Storage Account as a reusable component:

using Pulumi;
using Pulumi.AzureNative.Storage;

public class StorageAccountModule : ComponentResource
{
    public Output<string> StorageAccountName { get; private set; }

    public StorageAccountModule(string name, ComponentResourceOptions? options = null) : base("custom:module:StorageAccountModule", name, options)
    {
        var storageAccount = new StorageAccount($"{name}-sa", new StorageAccountArgs
        {
            ResourceGroupName = "my-resource-group",
            Location = "WestEurope",
            Sku = new SkuArgs { Name = SkuName.Standard_LRS },
            Kind = Kind.StorageV2
        });

        StorageAccountName = storageAccount.Name;
        this.RegisterOutputs(new { StorageAccountName });
    }
}

This module can then be used in any Pulumi stack by simply referencing it:

var storageAccount = new StorageAccountModule("appstorage");

Publishing as a NuGet Library

Once you’ve created a module, you can package it as a NuGet library for reuse. Begin by structuring your project with appropriate metadata in the .csproj file. Then, use the dotnet pack command to create the NuGet package. Hosting the package on a private NuGet feed or a public repository like nuget.org allows other teams to integrate it into their projects with minimal effort. Here’s an example of how to add the NuGet package:

> dotnet add package CustomPulumiModules.StorageAccount --version 1.0.0

By adopting this approach, organizations can build a repository of standardized modules, ensuring consistency and reducing duplication.

Best Practices for Modular Design

While modularization simplifies infrastructure management, following best practices is crucial to maximize its benefits. First, maintain clear documentation for each module, outlining inputs, outputs, and intended use cases. Second, implement rigorous versioning to ensure backward compatibility and minimize disruptions. Third, adopt automated testing pipelines to validate modules against predefined scenarios. Finally, encourage collaboration across teams to contribute to and improve shared libraries, fostering a culture of reusability and innovation.

With Pulumi and C#, coupled with NuGet’s distribution model, the possibilities for modular infrastructure design are vast. By investing in reusable modules, organizations can enhance productivity, ensure consistency, and position themselves for long-term success in cloud operations.

The Apply method allows you to interact with resources after Pulumi has created them. This enables you to execute custom logic based on the resource's properties. A common use case is to retrieve resource IDs or connection strings, which are usually available only after deployment completes. To make use of Apply, ensure you have the necessary Azure and Pulumi packages installed in your project. You might need to set up an Azure service principal to authenticate.

Let's consider a scenario where we deploy a storage account and then retrieve its connection string using Apply. Here's a snippet of C# code that demonstrates this:

using Pulumi;
using Pulumi.AzureNative.Resources;
using Pulumi.AzureNative.Storage;
using Pulumi.AzureNative.Storage.Inputs;
using System.Threading.Tasks;

public class MyStack : Stack
{
    [Output]
    public Output<string> ConnectionString { get; private set; }

    public MyStack()
    {
        var resourceGroup = CreateResourceGroup();
        var storageAccount = CreateStorageAccount(resourceGroup);
        this.ConnectionString = GetStorageAccountConnectionString(resourceGroup.Name, storageAccount.Name);
    }

    private ResourceGroup CreateResourceGroup()
    {
        return new ResourceGroup("resourceGroup");
    }

    private StorageAccount CreateStorageAccount(ResourceGroup resourceGroup)
    {
        return new StorageAccount("mystorage", new StorageAccountArgs
        {
            ResourceGroupName = resourceGroup.Name,
            AccountName = "myaccount",
            Sku = new SkuArgs { Name = SkuName.Premium_LRS }
        });
    }

    private Output<string> GetStorageAccountConnectionString(Output<string> resourceGroupName, Output<string> accountName)
    {
        return Output.Tuple(resourceGroupName, accountName).Apply(names =>
        {
            var (rgName, accName) = names;
            return GetStorageAccountPrimaryKey(rgName, accName).Apply(key =>
                $"DefaultEndpointsProtocol=https;AccountName={accName};AccountKey={key};EndpointSuffix=core.windows.net");
        });
    }

    private static async Task<string> GetStorageAccountPrimaryKey(string resourceGroupName, string accountName)
    {
        var accountKeys = await ListStorageAccountKeys.InvokeAsync(new ListStorageAccountKeysArgs
        {
            ResourceGroupName = resourceGroupName,
            AccountName = accountName
        });
        return accountKeys.Keys[0].Value;
    }
}

In this example, I started by creating a Resource Group and a Storage Account using Pulumi's Azure Native provider.

To securely retrieve the primary key, I used the ListStorageAccountKeys function, which is wrapped in an asynchronous method.

The Apply method was then used to combine the Resource Group name and Storage Account name, passing them to the key retrieval function. Once the key was obtained, I constructed a connection string in the format required by Azure.

This approach not only ensures that sensitive information like the primary key is handled securely but also demonstrates how Pulumi's Apply method can elegantly manage dependencies and transform outputs in a clean, readable way. By breaking the code into smaller, single-responsibility methods, the solution becomes more maintainable and easier to extend for future use cases.

Practical applications extend beyond connection strings. Imagine a scenario where you need to register a custom resource provider or configure service endpoints post-deployment. The Apply method provides the flexibility to handle such scenarios, facilitating a more tailored and dynamic infrastructure deployment. By combining the power of Apply with Pulumi's infrastructure-as-code approach, you can effectively manage and automate your Azure environments efficiently.

To further enhance your understanding, explore Pulumi's official documentation, which offers in-depth examples and advanced techniques. Also I found this blog post very useful. Exploring these resources will solidify your grasp on how to make the most of this powerful tool.

• Creating arrays

• Adding elements

• Removing elements

• Accessing an element

• Iterating them

• Filtering them

in PowerShell.

Creating an array

When you create an array by default it’s type is Object[], unless you specify the type.

# using @()
$itemsArray = @('Item 1', 'Item 2', 'Item 3')
# or ()
$itemsArray = ('Item 1', 'Item 2', 'Item 3')
# or just comma separated
$itemsArray = 'Item 1', 'Item 2', 'Item 3'

# Using ranges
$genericArray = 1..10
# instead of @('a', 'b', 'c', 'd', 'e')
$genericArray = 'a'..'e'

# Int32[] array
[int[]]$numbersArray = 1..10

# ArrayList, type will be List`1, Base type: System.Object
$itemsList = New-Object System.Collections.Generic.List[System.Object]

Adding items to an array

# Add one item
$itemsArray += 'Item 4'
# Add a list to array with @()
$itemsArray += @('Item 5', 'Item 6')
# Add a list to array with ()
$itemsArray += ('Item 5', 'Item 6')
# Add a list to array with just comma separated list
$itemsArray += 'Item 5', 'Item 6'

$genericArray += (11..20)
$genericArray += 'z'..'a'

$numbersArray += (11..20)
# The following command will add ASCII codes of the characters,
# because $numbersArray is an array of type Int32[]
$numbersArray += 'a'..'e'

# Add one item
$itemsList.Add('Item 1')
# Add a list to the end of our list with @()
$itemsList.AddRange(@('Item 2', 'Item 3'))
# Add a list to the end of our list with ()
$itemsList.AddRange(('Item 2', 'Item 3'))

# Nope! this doesn't work
$itemsList.AddRange('Item 2', 'Item 3') #Error

Remove an item from an array

Created arrays using @(), () or comma separated items, are fixed arrays. It means you can’t remove items from them, but you can create a new list with remaining items.

$itemsArray = @('Item 1', 'Item 2', 'Item 3')
# Remove 'Item 2'
$newItemsArray = $itemsArray | Where-Object { $_ –ne 'Item 2' }

# Remove 'Item 2'
$newItemsArray = $itemsArray[0, 2]

Or you can use array lists:

$itemsList = New-Object System.Collections.Generic.List[System.Object]
$itemsList.AddRange(@('Item 1', 'Item 2', 'Item 3'))
# Remove 'Item 1'
$isRemoved = $itemsList.Remove('Item 1')

Working with Arrays

Accessing items

$itemsArray = @('Item 1', 'Item 2', 'Item 3')

$itemsArray[0] # => Item 1
$itemsArray[2] # => Item 3
$itemsArray[-1] # => Item 3
$itemsArray[-3] # => Item 1
$itemsArray[-4] # => $NULL, no error
$itemsArray[3] # => $NULL, no error

# The following will throw an error
# OperationStopped: Index was outside the bounds of the array.
$itemsArray[3] = 'Item 4'

$unknownVariable # => $NULL
$unknownVariable[0] # => Error: Cannot index into a null array.

Iterating Arrays

$itemsArray = @('Item 1', 'Item 2', 'Item 3')

# ForEach-Object Pipeline
$itemsArray | ForEach-Object {"Item: [$_]"}

# For loop
foreach ($item in $itemsArray) {
    "Item: [$item]"
}

# Foreach method
$itemsArray.foreach({"Item: [$_]"})
$itemsArray.foreach {"Item: [$_]"}

# For loop
for ($index = 0; $index -lt $itemsArray.count; $index++) {
    "Item: [{0}]" -f $itemsArray[$index]
}

# Switch
switch($itemsArray)
{
    'Item 1'
    {
        "Item: [$_]"
    }
    'Item 3'
    {
        "Item: [$_]"
    }
    Default
    {
        "Item: [$_] not in the list of switch"
    }
}

Filtering Arrays

$itemsArray = @('Item 1', 'Item 2', 'Item 3')

# Where-Object
$itemsArray | Where-Object { $_ -like '*tem*' }

# Where method
$itemsArray.Where({ $_ -like '*tem*' })

Conclusion

This was very short and quick introduction to PowerShell Arrays. You can find more information on PowerShell commands and Arrays at Microsoft documentations on Arrays in PowerShell.

Assume you go to a coffee shop and order coffee with cake.

Here are the list of thing that a worker needs to do:

1. Accept the order and payment, takes 3 minutes

2. Make the coffee, and put it on a tray, takes 5 minutes

3. Put a slice of cake you have ordered and put it on the tray, takes 1 minutes

Synchronous

In a synchronous world, it’s like the coffee shop has only one staff and has to work on the tasks one after another. Here it takes 9 minutes for the worker to complete all above three tasks.

namespace Demo
{
    public class CoffeeShop
    {
        public const int MIN = 60 * 60 * 1000
        public void AcceptPayment()         => Thread.Sleep(3 * MIN);
        public void MakeCoffee()            => Thread.Sleep(5 * MIN);
        public void PrepareSliceOfCake()    => Thread.Sleep(1 * MIN);
    }

    class Program
    {
        static void Main()
        {
            var shop = new CoffeeShop();
            shop.AcceptPayment();
            shop.MakeCoffee();
            shop.PrepareSliceOfCake();
        }
    }
}

Asynchronous

But if we use asynchronous programming, we can me it less.

using System.Threading.Tasks;
namespace Demo
{
    public class CoffeeShop
    {
        ...
        public async Task AcceptPayment()       => await Task.Delay(3 * MIN);
        public async Task MakeCoffee()          => await Task.Delay(5 * MIN);
        public async Task PrepareSliceOfCake()  => await Task.Delay(1 * MIN);
        ...
    }

    class Program
    {
        static void Main()
        {
            var shop = new CoffeeShop();
            var acceptPaymentTask = shop.AcceptPayment();
            var makeCoffeeTask = shop.MakeCoffee();
            var prepareSliceOfCake = shop.PrepareSliceOfCake();

            Task.WaitAll(acceptPaymentTask, makeCoffeeTask, prepareSliceOfCake);
        }
    }
}

We changed the return types of the functions from void to async Task and used Task.WaitAll to wait for all the task to complete so we can drink our coffee with the slice of cake.

Using await in Main needs async Main

We may want to have the coffee even if without the cake, because we are thirsty?

    ...
        static async Task Main()
        {
            var shop = new CoffeeShop();
            var acceptPaymentTask = shop.AcceptPayment();
            var makeCoffeeTask = shop.MakeCoffee();

            Task.WaitAll(acceptPaymentTask, makeCoffeeTask);

            // Drink the coffee while waiting for...

            await shop.PrepareSliceOfCake();

            // The cake is ready :yum:
        }
    ...

You can see we had to add async Task to the Main method as well, because we are using await keyword inside it.

Conclusion

This post was a quick introduction to using async/await in C# which I hope it was helpful. Parallel tasks are still tasks and needs to be done in the same time as the synchronous tasks, but running them asynchronously helps us getting the coffee sooner if we are thirsty. :)