<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" ><generator uri="https://jekyllrb.com/" version="4.4.1">Jekyll</generator><link href="https://blog.allegro.tech/feed.xml" rel="self" type="application/atom+xml" /><link href="https://blog.allegro.tech/" rel="alternate" type="text/html" /><updated>2026-06-16T16:02:42+02:00</updated><id>https://blog.allegro.tech/feed.xml</id><title type="html">blog.allegro.tech</title><subtitle>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?</subtitle><entry><title type="html">Finding the Needle: Taming 150,000+ Backstage Entities with a Type-Safe Search and Command Palette</title><link href="https://blog.allegro.tech/2026/06/taming-backstage-entities-with-a-type-safe-search-and-command-palette.html" rel="alternate" type="text/html" title="Finding the Needle: Taming 150,000+ Backstage Entities with a Type-Safe Search and Command Palette" /><published>2026-06-16T00:00:00+02:00</published><updated>2026-06-16T00:00:00+02:00</updated><id>https://blog.allegro.tech/2026/06/taming-backstage-entities-with-a-type-safe-search-and-command-palette</id><author><name>jordan.andrzejczak</name></author><category term="tech" /><category term="frontend" /><category term="backstage" /><category term="search" /><category term="command palette" /><category term="type-safe" /><category term="react" /><category term="typescript" /><summary type="html"><![CDATA[This article describes how Allegro built “Commander,” a keyboard-first ⌘+K command palette designed to instantly search and manage over 150,000 entities within Allegro’s developer portal, built on Spotify’s Backstage framework. It highlights the tool’s underlying stack-based mini-router architecture, which combines advanced TypeScript and Zod for zero-boilerplate type safety alongside client-side caching for instant performance.]]></summary></entry><entry><title type="html">Spec-Driven Development (SDD) — best practices (so far)</title><link href="https://blog.allegro.tech/2026/06/spec-driven-development-best-practices.html" rel="alternate" type="text/html" title="Spec-Driven Development (SDD) — best practices (so far)" /><published>2026-06-08T00:00:00+02:00</published><updated>2026-06-08T00:00:00+02:00</updated><id>https://blog.allegro.tech/2026/06/spec-driven-development-best-practices</id><author><name>konrad.piechna</name></author><category term="tech" /><category term="ai" /><category term="sdd" /><category term="spec-driven development" /><category term="ai-assisted development" /><summary type="html"><![CDATA[The traditional approach of working with current large language models (LLMs) through free-form conversations (a.k.a. vibe coding) typically leads to: accumulation of technical debt, architectural inconsistency, unmet requirements, gradual model drift away from our intent (a.k.a. intent drift). What if there were a way to tame the pain points of coding agents and actually boost our productivity? The answer to the limitations of current LLMs in autonomous software development is Spec-Driven Development (SDD).]]></summary></entry><entry><title type="html">GeeCON 2026 — a recap</title><link href="https://blog.allegro.tech/2026/05/geecon-2026-recap.html" rel="alternate" type="text/html" title="GeeCON 2026 — a recap" /><published>2026-05-26T00:00:00+02:00</published><updated>2026-05-26T00:00:00+02:00</updated><id>https://blog.allegro.tech/2026/05/geecon-2026-recap</id><author><name>malgorzata.karmazyn</name></author><category term="tech" /><category term="conference" /><category term="geecon" /><category term="java" /><category term="jvm" /><category term="ai" /><category term="llm" /><summary type="html"><![CDATA[The 2026 edition of GeeCON didn’t look promising at first. I arrived in Kraków expecting the same slow decline I’d been hearing about — no crowds, only five sponsor booths, and talks from sponsors about their great products. Last year I heard the conference business was slowly dying, and I kinda agreed.]]></summary></entry><entry><title type="html">Two schools of TDD explained</title><link href="https://blog.allegro.tech/2026/05/two-schools-of-TDD-explained.html" rel="alternate" type="text/html" title="Two schools of TDD explained" /><published>2026-05-13T00:00:00+02:00</published><updated>2026-05-13T00:00:00+02:00</updated><id>https://blog.allegro.tech/2026/05/two-schools-of-TDD-explained</id><author><name>michal.przysucha</name></author><category term="tech" /><category term="tdd" /><category term="Kotlin" /><category term="testing" /><category term="test doubles" /><category term="mock" /><category term="stub" /><category term="fake" /><category term="dummy" /><category term="spy" /><summary type="html"><![CDATA[This article presents two approaches of how TDD can be applied. The first is the classic one where the objects are treated as black-boxes and verification is based on the objects state. The second one is focused on interactions.]]></summary></entry><entry><title type="html">Thoughts on the Boiling Frogs 2026 conference</title><link href="https://blog.allegro.tech/2026/04/thoughts-on-boiling-frogs-2026.html" rel="alternate" type="text/html" title="Thoughts on the Boiling Frogs 2026 conference" /><published>2026-04-28T00:00:00+02:00</published><updated>2026-04-28T00:00:00+02:00</updated><id>https://blog.allegro.tech/2026/04/thoughts-on-boiling-frogs-2026</id><author><name>piotr.bakalarski</name></author><category term="tech" /><category term="conference" /><category term="boiling frogs" /><summary type="html"><![CDATA[On the 21st of March I traveled to Wrocław for the Boiling Frogs conference — my first in a while. I expected a day of technical talks. What I got instead was a surprisingly philosophical look at what it means to be a software engineer right now: why we work, whether AI is coming for our jobs, and how many LEGO bricks fit in a tube.]]></summary></entry><entry><title type="html">Static code analysis in Kotlin — tools overview</title><link href="https://blog.allegro.tech/2026/03/static-code-analysis-kotlin.html" rel="alternate" type="text/html" title="Static code analysis in Kotlin — tools overview" /><published>2026-03-31T00:00:00+02:00</published><updated>2026-03-31T00:00:00+02:00</updated><id>https://blog.allegro.tech/2026/03/static-code-analysis-kotlin</id><author><name>mikolaj.wroblewski</name></author><category term="tech" /><category term="kotlin" /><category term="detekt" /><category term="static analysis" /><category term="code quality" /><summary type="html"><![CDATA[Recently in our team we decided that it could be beneficial for us to have a solution in place that would allow to automatically organise or at least verify the order of methods and fields in our Kotlin code.]]></summary></entry><entry><title type="html">How to stub external services in integration tests</title><link href="https://blog.allegro.tech/2026/02/how-to-stub-external-services.html" rel="alternate" type="text/html" title="How to stub external services in integration tests" /><published>2026-02-12T00:00:00+01:00</published><updated>2026-02-12T00:00:00+01:00</updated><id>https://blog.allegro.tech/2026/02/how-to-stub-external-services</id><author><name>piotr.klimiec</name></author><category term="kotlin" /><category term="testing" /><category term="integration tests" /><category term="rest" /><summary type="html"><![CDATA[In my previous post, I shared a way to hide technical boilerplate and make REST API calls more expressive within your integration tests. To further improve your tests, you also need a strategy for handling integrations with the “outside world.”]]></summary></entry><entry><title type="html">Battle-testing Lynx at Allegro</title><link href="https://blog.allegro.tech/2026/02/battle-testing-lynx-js-at-allegro.html" rel="alternate" type="text/html" title="Battle-testing Lynx at Allegro" /><published>2026-02-05T00:00:00+01:00</published><updated>2026-02-05T00:00:00+01:00</updated><id>https://blog.allegro.tech/2026/02/battle-testing-lynx-js-at-allegro</id><author><name>[&quot;wojciech.moczydlowski&quot;, &quot;tomasz.gebarowski&quot;]</name></author><category term="tech" /><category term="lynx" /><category term="mobile" /><category term="mbox" /><summary type="html"><![CDATA[How do you ship consistent, high-performance mobile UIs across iOS, Android, and Web - without slowing your teams down? For us at Allegro, this question quickly became a daily reality, forcing constant trade-offs between performance and iteration speed, native quality and cross-platform reach, flexibility and long-term maintainability. Along the way, it led us from our own internal solutions to an unexpected open-source challenger — and to rethinking how we build mobile interfaces at scale.]]></summary></entry><entry><title type="html">Starting a New Service: From Naming to Structuring the Project</title><link href="https://blog.allegro.tech/2026/01/starting-a-new-service-from-naming-to-structuring-the-project.html" rel="alternate" type="text/html" title="Starting a New Service: From Naming to Structuring the Project" /><published>2026-01-13T00:00:00+01:00</published><updated>2026-01-13T00:00:00+01:00</updated><id>https://blog.allegro.tech/2026/01/starting-a-new-service-from-naming-to-structuring-the-project</id><author><name>piotr.klimiec</name></author><category term="architecture" /><category term="tech" /><summary type="html"><![CDATA[This post describes how our team at Allegro started building a new service. We’ll go through the process step by step: first ensuring we have a clear understanding of the business process to implement, then choosing the service name, and finally setting up the project structure. By the end, you’ll see how to create a solid application skeleton that makes developing subsequent features straightforward and efficient.]]></summary></entry><entry><title type="html">The Seven Deadly Sins of Test Automation</title><link href="https://blog.allegro.tech/2025/12/testing-7-deadly-sins.html" rel="alternate" type="text/html" title="The Seven Deadly Sins of Test Automation" /><published>2025-12-22T00:00:00+01:00</published><updated>2025-12-22T00:00:00+01:00</updated><id>https://blog.allegro.tech/2025/12/testing-7-deadly-sins</id><author><name>malgorzata.kozlowska</name></author><category term="tech" /><category term="testing" /><summary type="html"><![CDATA[I’ve spent a significant part of my career building and maintaining test automation suites, and I’ve learned one thing for certain: a test suite that isn’t trusted is worse than no test suite at all. We’ve all felt that familiar dread of a CI/CD pipeline that’s constantly red, where the team spends more time debugging flaky tests than shipping features. If you’re a test automation engineer or a developer feeling the pressure of a complex and fragile test suite, this post is for you. It’s a confession, a guide, and a collection of hard-won lessons I’ve learned throughout my career on how to pull our test suites back from the brink.]]></summary></entry></feed>