Welcome to our technology blog. We use Open Source solutions on a daily basis here at Allegro. Why not work on our karma and give something in return?
Practical guidance on writing better unit tests: apply the FIRST principles (Fast, Isolated, Repeatable, Self-validating, Timely); group tests by functionality or fixtures; name tests after the behavior they verify; structure test bodies using patterns like Object Mother and Assert Object to hide irrelevant details; prefer testing behavior over implementation details; and consider fakes over mocks to improve readability and resilience.
The article describes a structured "Architect & Coder" agent workflow for using GitHub Copilot in VS Code to produce predictable, rule-compliant code. It proposes repo-level files (.github/copilot-instructions.md and copilot-architect-*.chatmode.md) to capture project DNA and an Architect persona that generates precise tasks for a Coder agent. A detailed Angular v20+ example (coding conventions, signals, Reactive Forms, PrimeFlex) and testing guidelines (Cypress for component/E2E, Jasmine for unit tests) demonstrate the pattern; a brief FastAPI/Python example shows portability.
A personal recap of JavaZone 2025 covering venue and logistics, sponsor/corridor interactions, and summaries of selected technical talks. Major themes included Java/JVM and language topics (class file API, ByteBuddy, Kotlin immutability, annotations, Valhalla), ML/AI sessions (RAG, LLM testing, an ML case study), and design/architecture discussions (Domain Storytelling, Event Storming, DDD), plus monitoring/bug‑related talks and maker/sponsor activities.
A practical introduction to how Go's garbage collector (Go 1.19+) works: explains the tricolor mark-and-sweep algorithm, stack vs heap and escape analysis, GC pauses and concurrency, and the impact on latency and throughput. The article also covers tuning and diagnostics (GOGC, GODEBUG, debug.SetGCPercent, GOMAXPROCS, go build -gcflags) and gives guidance on trade-offs between CPU and memory.
Part 3 of a Gradle mistakes series: recommended Gradle plugins and how to use them. Covers Integration Test Plugin (separate integration tests), Test Logger (readable test output), Axion Release Plugin (Git-based versioning and GitHub Actions integration), Dependency Graph Generator (visualize multi-module dependencies), Typesafe Conventions (use version-catalog accessors in convention plugins), and Binary Compatibility Validator (Kotlin API stability). Includes example plugin blocks and Gradle commands, and describes CI/workflow integrations (GitHub Actions, API dump + LLM checks).
Practical guidance for calling REST APIs in integration tests: hide HTTP implementation details behind an api() facade organized by bounded context, name test helper methods to mirror controller endpoints, and use dedicated aggregating classes to improve readability and maintainability (examples in Kotlin using WebTestClient; Testcontainers mentioned).
Allegro engineers analyze the expensive long->wide pivot step in ML feature engineering and benchmark several approaches. Snowflake's built-in PIVOT was slow at scale; pandas is memory-bound. They present two effective alternatives: (1) a custom pipeline that reads per-feature parquet partitions (PyArrow), uses DuckDB and parallel processes to build wide-format parquet files in Azure Blob (benchmark ~7 minutes on their sample), and (2) an in-Snowflake technique using object_agg via Snowpark that produces the wide table much faster (~3 minutes) without exporting data. The article discusses memory budgeting, parallelism heuristics, and trade-offs, and notes future exploration of Dask, Ray, and PySpark.
Practical Gradle best practices: prefer lazy configuration (tasks.register/configureEach), extract shared logic into convention plugins (buildSrc), use dependencyResolutionManagement in settings to centralize repositories, align multi-module artifact versions with java-platform, use dependencyInsight (not just dependencies) to debug resolution, enable Gradle build cache and configuration cache, prefer Kotlin DSL (kts) over Groovy for type safety, and split frontend/backend modules using the node-gradle plugin for frontend tasks. Examples use Java/Spring Boot and Node/NPM; CI caching with GitHub Actions is mentioned.
Allegro describes building a domain-specific "LLM-as-a-Judge" (synthetic annotator): how to design annotation instructions and datasets, choose and prompt LLMs, build an evaluation pipeline (they used GPT-4 deployed on Azure via Allegro's allms python library), run ablation experiments (few/zero/one/five-shot, context, label swapping, neutral labels), post-process outputs, and compare to human labels. Results were modest (Cohen's Kappa ≈ 0.2) and the authors caution that LLM-based judges require careful design and are not yet a full replacement for human annotation in production.
Opinion piece examining the "dual-use" dilemma of AI using China as an example: discusses facial recognition, NLP, deepfakes, data collection, military–civil fusion, surveillance and cyber risks, and argues for public awareness and education rather than purely restrictive regulation.
Allegro’s engineering team optimized opbox-web (a Node.js frontend microservice) by deprecating remote FaaS components, consolidating renderer/workers into a single-process design run in Node cluster mode, increasing per-pod CPU, and addressing Node.js event-loop scheduling (including using setImmediate and a synchronous wait for css-bundler). These changes increased per-instance RPS (~10→~50), cut k8s instance count drastically, and saved ~64% CPU and ~70% memory across the platform.
The article describes a reliable batch-based pipeline ("Kopiowaczka") to copy immutable rows from PostgreSQL into BigQuery under connectivity constraints: export rows to CSV, upload to Google Cloud Storage, load into a temporary BigQuery table, insert only non-duplicate rows into the final table, and verify record counts. It discusses alternatives (Dataflow/Apache Beam, Datastream, Debezium+Kafka) and explains why a controlled batch process was chosen to guarantee consistency.
Allegro describes using the Resilience4j Circuit Breaker (implemented in Kotlin/Java) beyond HTTP clients to automatically disable failing payment methods. A microservice consumes payment-failure events from a message broker, updates per-method CircuitBreakers stored in a registry, persists state changes to a repository, and thus improves reliability and response time to third-party failures.
An Allegro engineering post listing common Gradle anti-patterns and recommended fixes for JVM projects. It covers redundant plugin application, duplicated JDK/toolchain declarations, misapplied plugins (application/maven-publish/java-library), dummy root projects, setting explicit defaults, scattered dependency versions and how to centralize them with a Version Catalog (libs.versions.toml), unnecessary annotation processing (spring-boot-configuration-processor / kapt), overlapping formatters (ktlint vs detekt-formatting), global dependencies via allprojects/subprojects, brittle task-by-name configuration vs type-based config, using buildSrc vs an included build (build-logic), redundant Gradle wrapper configuration, and build-performance tips (configuration cache, parallel execution).
The article examines the relationship between the DRY principle and the Single Responsibility Principle, arguing that duplication can be appropriate when different actors/teams cause different reasons to change. It uses coffee-machine code examples and a real Allegro Archive frontend component case (listing component, Opbox libraries, health checks) to show when merging similar code harms maintainability and when deliberate duplication preserves single responsibility.
Allegro built an automated code-migration pipeline that integrates Dependabot with a custom GitHub App (@allegro-rewrite) and OpenRewrite recipes. When Dependabot opens version-bump PRs (e.g., for an internal spring-boot-starter), the app triggers GitHub workflows on runners that apply OpenRewrite transformations, commit and push changes to the PR branch, and optionally auto-approve or force-merge by deadline. The article describes comment-based commands, a CLI distributed via an internal homebrew tap, encountered edge cases (Groovy/Kotlin/YAML/JVM settings), and plans to open-source the solution.
A hands-on guide to speeding up Groovy + Spock tests in a Kotlin/Java + Spring codebase. The author measures Gradle task timings, compares hardware (M3 Pro vs Intel), and applies Gradle features—Groovy compilation avoidance and incremental compilation—plus test refactors (reducing timeouts/retries, using StepVerifier.withVirtualTime) and Gradle JVM/cache/daemon settings. The result: test-suite runtime reduced from ~6 minutes to under 3 minutes with large per-test speedups.
Personal account and practical tips from an engineer returning to programming after a 21-month break (maternity leave). The author describes emotional phases during the first three months, family and opportunity-cost challenges, and gives actionable advice for self-care, company-side onboarding and technical catch-up (including reading technical roadmaps and learning libraries such as zod and Redux Toolkit/RTK Query).
Engineer-led case study of migrating end-to-end tests from Selenium to Playwright in Java. The post covers code changes (BaseTest/BasePage examples), comparisons of API ergonomics and execution speed, Page Object Model benefits, CI integration via GitHub Actions (including Playwright install or using Playwright Docker image), and Allure reporting. The author concludes Playwright is faster and more stable and outlines next steps.
Allegro engineers diagnosed large CPU spikes and P99 latency spikes at JVM-based service startup caused by heavy JIT (C2) recompilation. After diagnosing with flamegraphs and thread dumps, they experimented with -XX:CICompilerCount to increase compiler threads and implemented a warmup using a Spring health indicator and Kubernetes startupProbe to run synthetic requests until the hottest code was compiled. This removed startup CPU spikes and made restarts transparent to users.
