PurpleBooth

Project Title

One Paragraph of project description goes here

Getting Started

These instructions will get you a copy of the project up and running on your local machine for development and testing purposes. See deployment for notes on how to deploy the project on a live system.

Prerequisites

noelbundick

Running Distributed Locust on Azure Container Instances

Locust is an open source load testing tool that can be run inside a container

Below is how I got Locust up and running on Azure Container Instances

Note: I prefer head/workers, controller/nodes, etc, but I've used master/slave for clarity & consistency with the Locust docs in this doc

Design

wingrime

 public static class Retry
    {
        public static async Task<T> DoAsync<T>(Func<Task<T>> action,
            Func<T, bool> validateResult = null,
            int maxRetries = 10, int maxDelayMilliseconds = 2000, int delayMilliseconds = 200)

        {
            var backoff = new ExponentialBackoff(delayMilliseconds, maxDelayMilliseconds);

            var exceptions = new List<Exception>();

pvasek

server:
    http_listen_port: 9080
    grpc_listen_port: 0

positions:
    filename: /tmp/positions.yaml

clients:
    - url: http://loki:3100/api/prom/push

EdCharbeneau

@if (IsLoading)
{
    @LoadingTemplate
}
else
{
    @ContentTemplate
}

@code {

davidfowl

using System;
using System.Threading;

namespace PureDI
{
    class Program
    {
        static void Main(string[] args)
        {
            // Create the singletons once

andrewrk

const std = @import("std");
const net = std.net;
const fs = std.fs;
const os = std.os;

pub const io_mode = .evented;

pub fn main() anyerror!void {
    var general_purpose_allocator = std.heap.GeneralPurposeAllocator(.{}){};
    const allocator = &general_purpose_allocator.allocator;

jeremydmiller

A Contrarian Take on Architecture

I’ve spent an inordinate amount of time the past half decade across multiple companies working with very large, long running enterprise systems. Especially in long running, constantly changing systems, you want the code to be easy to understand, relatively painless to extend or modify, and when advantageous, be simple to modernize with updated technology. Unfortunately, the systems I’ve worked on have consistently failed to satisfy these goals.

Ironically enough though, my judgment is that the code in these systems has been hard to understand, extend or change, and modernize because they had all adopted much of the very industry conventional wisdom about how to build large, maintainable systems.

In particular, I want to demonstrate and explain why I think that prescriptive, layered architectural styles like Clean or Onion Architecture can actually cause harm in larger systems. I also want us to train our sights on how teams attempt to hide the actual persistence technol

Tyrrrz

internal partial class ResizableSemaphore : IDisposable
{
    private readonly object _lock = new();
    private readonly Queue<TaskCompletionSource> _waiters = new();
    private readonly CancellationTokenSource _cts = new();

    private bool _isDisposed;
    private int _maxCount = int.MaxValue;
    private int _count;

pwbh

const std = @import("std");
const net = std.net;
const Allocator = std.mem.Allocator;

pub const io_mode = .evented;

var client_id_counter: u32 = 0;
var should_server_close: bool = false;

pub fn main() !void {