Teknik
Välkommen till vår teknikblogg! Håll dig uppdaterad, följ oss på LinkedIn
What about Java 26
// Ove Lindström
Java 25 was released in September 2025 but the rampdown phase for Java 26 has already begun and it will be generally available in the middle of March 2026.
But how much can actually happen in 6 months? Let me tell you.
Beyond Find-And-Replace - a 15-Year Java Leap using OpenRewrite
// Ove Lindström
During the fall, I worked for a Swedish government organisation that has a large legacy codebase. This is a summary of the findings and ways of working that emerged during the project.
From Confusion to Mastery - My Journey with Kotlin Coroutines and Building "KoCache"
// Anders Asplund
Kotlin Coroutines have become the standard for asynchronous programming in the Kotlin ecosystem. While I might not reach for them in every single task, they remain one of the most powerful tools in my developer toolbox. However, using them effectively requires more than just knowing syntax, it requires understanding the underlying mechanics of concurrency.
Go SIMD part 4: Ray-Sphere intersection acceleration
// Erik Lupander
Recently, a proposal for adding low-level SIMD support to Go was “Accepted” and will be included in Go 1.26 as a GOEXPERIMENT. In the last part I took a look at “thinking in SIMD” in regard to structuring data for SIMD use. In this part, we’ll become more practical, looking at converting a scalar ray-intersection function for data parallelism.
Go SIMD part 3: Thinking in SIMD
// Erik Lupander
Recently, a proposal for adding low-level SIMD support to Go was “Accepted”. In the last part took a look at SIMD for dot product computations in order to speed up ray-sphere intersection testing. In this blog post, it’s time to “think in SIMD” to hopefully make better use of SIMD.
The black t-shirt architect, part 3: Evolution is inevitable
// David Ström
This is the third and final part of my blog series The black t-shirt architect. Thus far in this series we have concluded that there are no perfect solutions in part 1 so that any architectural decisions becomes a trade-off. We followed up by looking at a way to document architectural decisions in a clear and concise way in part 2. It is finally time for Evolution is inevitable in which we look at how we can balance the need for up-front design without falling into the trap of overengineering the solution.
The black t-shirt architect, part 2: The 'why' is more important than the 'how'
// David Ström
This is the continuation of my blog series The black t-shirt architect, a name I hope brings to mind the image of an architect still deeply involved in the nitty-gritty details of software development. In this blog series we take a closer look at three fundamental rules of software architecture: Everything is a trade-off, The ‘why’ is more important than the ‘how’ and finally Evolution is inevitable. In the first part we saw how it is essential to consider different alternatives when making significant design decisions and in this part we will follow up by looking at why documenting those design decisions is so important.
The black t-shirt architect, part 1: Everything is a trade-off
// David Ström
This is a new blog series (and my first!) that I have christened The black t-shirt architect. I chose this title to conjure an image of an architect with a background as senior developer still very much involved in the code. I hope it also represents the mindset of a constant learner. Also, I think it sounds rather cool.
Go SIMD part 2: Hands-on dot product
// Erik Lupander
Recently, a proposal for adding low-level SIMD support to Go was “Accepted”. In a previous blog post I covered the basics. In this blog post, it’s time to become more practical, looking at possibly accelerating ray-sphere intersections in a toy ray-tracer I’ve written by leveraging SIMD-acceleration of dot product computations abundant in ray tracing.
Spec-driven utveckling – från kravinsamling till färdig app med AI-assistent
// Hans Thunberg
På Callista har vi varje år ett antal bootcamps, en slags träningsläger där vi tar chansen att träna på saker vi tycker verkar intressanta. Det handlar inte så mycket om att bygga muskler och kondition, mer om att bygga kompetens och självförtroende kring intressant teknologi, arbetssätt, prylar eller vad som helst egentligen.
Vid fikapauserna på höstens bootcamp hamnade jag i spännande diskussioner om MCP-lösningar för hårdvaruövervakning, specialtränade språkmodeller för systemkonfiguration, och WebAuthn/passkeys för modern autentisering. Mitt eget fokus låg på spec-driven utveckling med AI-assistenter, ett arbetssätt där vi beskriver vad vi vill uppnå istället för hur det ska kodas.
Målet? Att köra igenom ett helt utvecklingsflöde från kravinsamling till färdig implementation, med hjälp av strukturerade specifikationer och Claude Code som AI-assistent.
Magnus Larssons bok om mikrotjänster med Spring Boot nu i 4:e upplagan
// Jan Västernäs • Magnus Larsson
Magnus Larssons bok har kommit ut med en 4:e upplaga och vi är lite nyfikna på vad den innehåller och hur är det egentligen att skriva en bok? Vi lyssnar med Magnus vad han säger.
Go SIMD part 1: Trying out Go with native SIMD support
// Erik Lupander
Recently, a proposal for adding low-level SIMD support to Go was marked as “Likely Accept”. In this blog post, we do some early experiments with the simd package using gotip to access the work-in-progress implementation.
Observability with OpenTelemetry
// Martin Holt
In my last blog post we took a dive into OpenTelemetry and how it could be used to gather signals from your applications. One thing was absent - trace! This blog will take a dive into adding trace to the scenario and what you can get out from it.
The cost of ignoring dependencies
// Ove Lindström
There is a place in Norway named Hell. It is a small community of fewer than 2,000 people, and everyone knows each other. And everyone depends on each other.
But what happens when your dependencies in your application freeze over? And what is the cost of not having a Dependency Management Strategy?
Impacts of Java 25 - what will they learn?
// Ove Lindström
Java 25 is here!
How will the latest release transforms the way we write, teach, and learn Java? What will streamlined source files and powerful new features bring to the table? And what will all the old developers that thinks Java is good as it is think?
Ready to see how Java 25 impacts your code?
The Discovery of REST APIs
// Ove Lindström
In my previous blog post Good habits when designing REST APIs, I sort of ended with a little cliffhanger that there are more things that could be done to make life easier for your fellow developers. Today, we are diving into The Discovery of REST APIs and the magical use of HAL and HATEOAS.
Good habits when designing REST APIs
// Ove Lindström
I have previously shared some thoughts about when to use REST and when not to in and the REST is history. In that post, I stated that a good time to use REST is when “you need public APIs that are easy to understand and use”.
Working with public APIs is fun and rewarding—if you design your APIs the right way.
If you don’t, your users will be angry and complain.
In this post, I have gathered some of the more general best practices for building a good REST API. I coach (force?) developers I work with to follow them and use this as a checklist when I do code reviews on REST API code.
and the REST is history
// Ove Lindström
In his PhD dissertation “Architectural Styles and the Design of Network-based Software Architectures”, Roy Fielding defined the REST architecture style.
“This has made a lot of people very angry and been widely regarded as a bad move”. - The Hitchhiker’s Guide to the Galaxy, Douglas Adams
Do I agree with this statement? Is the REST history? Or is it just misunderstood and misused?
Observability with OpenTelemetry
// Martin Holt
Tooling for Observability has exploded in the last decade offering a rich portfolio of products and features to choose from. Ironically this has created some other challenges; vendor specific agents that misbehave, vendor lock in, licensing costs, inflexible centralised observability platforms, and platforms that operate outside the scope of their intended use. The result is often a complex and brittle observability infrastructure that requires significant effort to use and maintain.
It is good to remember that the value added by Observability is the ability to grasp the needs of our customers and to quickly react to incidents. Spending time wrestling with Observability infrastructure detracts from this.
In this blog I will look at OpenTelemetry and how adopting this can ease your Observability journey.
React At Light Speed
// Stephen White
One of the things I love, appreciate, respect, adore … about Callista is our focus on learning and our ability to go on conferences! It’s essential in helping us grow and stay current with tech trends and mingle with other like-minded tech geniuses …
Having got back from AppConf.js in Kraków at the end of May I felt compelled to do something fun for the React Gothenburg meetup.