antonputra

FROM golang:1.23.0-bookworm AS build

ARG upx_version=4.2.4

RUN apt-get update && apt-get install -y --no-install-recommends xz-utils && \
  curl -Ls https://github.com/upx/upx/releases/download/v${upx_version}/upx-${upx_version}-amd64_linux.tar.xz -o - | tar xvJf - -C /tmp && \
  cp /tmp/upx-${upx_version}-amd64_linux/upx /usr/local/bin/ && \
  chmod +x /usr/local/bin/upx && \
  apt-get remove -y xz-utils && \
  rm -rf /var/lib/apt/lists/*

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 {

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;

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

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;

davidfowl

using System;
using System.Threading;

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

EdCharbeneau

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

@code {

pvasek

server:
    http_listen_port: 9080
    grpc_listen_port: 0

positions:
    filename: /tmp/positions.yaml

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

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>();

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