Image source

by Joseph Welling

I completed a 9 week Full Stack Development bootcamp in Berlin and I have some thoughts on the whole process and hopefully I can help some people decide whether or not it is for them. This is part one of a series of posts about changing career into tech. I will also write about successfully job searching and how to be a successful junior engineer.

The entry bar for coding camps is simply time and money.

I applied to a number of bootcamps in Berlin before settling on one and each of the bootcamps had similar…


Getting started with API performance testing

by Olena Semiankiv

The right tool with a variety of ready-to-use features and possibility to extend it!

Recently, at Alteos we started our performance testing project and I was looking for an appropriate tool for it. After some research, our choice fell on Gatling.

Gatling is an open source, Scala-based tool for load testing, which will help you measure the load your API can handle.

It has many advantages — the main one for us being:

- Easy DSL (Domain Specific Language), which makes scripting much easier

- Full power of Scala (and therefore of Java) “under the hood”


One more step towards the automation of a daily routine

by Artur Rybak

One of the primary goals of the QA team at Alteos is to minimize the amount of manual work within daily activities in our projects.

Before rolling out a new product version to production, we test our ‘release candidate build’ in a sandbox environment.

In order to define the scope of testing, provide the visibility of testing progress and share testing results with interested parties, we used to create testing artifacts (e.g. test plan) in Jira.

We soon realized how time-consuming it was, to execute test cases manually in Jira. …


Our journey with Robot Framework

by Olena Semiankiv

A failing test at Alteos (kidding — we have thin monitors.)

Who we are — and why Test Automation is necessary for our projects.

We are a relatively small team, working on fast developing projects: we produce new features quite rapidly and often, we adjust already existing ones.

It’s not easy to keep track of every change we do and predict its impact.

Due to the nature of our projects, not only the development team but also “biz-ops” (including Product Managers, among others) are able to perform changes and could potentially break things.

So manual testing alone is not an option for us. It would be extremely slow and expensive.

In addition, as we move to CI/CD, automated tests


How entire companies are being built with mostly one language.

Some love it, some hate it, everybody uses it — JavaScript is present in almost every single website you’ve ever visited. And if you don’t believe me, try surfing the web after disabling JavaScript in your browser — good luck with that, truly.

Nobody can deny the strong influence JavaScript has had in the world wide web, as all major browsers can execute JS, which developers use to add interactivity to web pages and enhance our experience.

But how are things looking for JavaScript, beyond our browsers?

JavaScript beyond our browsers

JavaScript is no longer being used solely on the client side, but this…


An honest account of a startup’s experience with GitOps

In part 1, I explored some of the questions we asked ourselves while adopting GitOps. This post is a continuation of that, with more of a deep dive into our current setup.

Question 6, March 2020 — How can we better align our requirements with the tooling that is available?

In the wake of our latest setback with FluxCD, we were feeling somewhat deflated. Is GitOps what it’s cracked up to be? Is it that our system is too complicated for GitOps?

The answer to these questions is “yes” and “absolutely not!”.

It’s easy to slip into the mindset that the current tooling available may not be enough for your use case. That your system somehow needs a…


An honest account of a startup’s experience with GitOps.

by Tom Burton

A step in the right direction

What started as Infrastructure as Code (I.a.C) has now morphed into something even greater. I.a.C gave us a simple way of maintaining a single source of truth for our infrastructure in Git. Combine this with leveraging Git to perform deployments and you get GitOps. A way of using Git as the arbiter of our releases.

The term “GitOps” was first coined by Weaveworks. Since then, they have gone on to release one of the more popular tools in the trade, FluxCD. I will come back to this particular software later on.

Towards the end of 2019, we…


— for startups

by Khalil Najjar

At this point you, I and… well basically every developer in the world has heard of TypeScript. It has been part of the JavaScript world for a few years and its increase in popularity has shown no signs of slowing ever since its inception.

And the reason for that is simple: developers ❤ TypeScript.


Our journey with Kubernetes and Cloud

by Tom Burton

Illustration courtesy of Alteos Design Team

An Idea.

Welcome to the inaugural post of the Alteos Technology Blog!

Here we’ll share the technical challenges and discoveries we’ve made along the way.

In 2018 we founded Alteos, with the focus of automating the German insurance market.

To do this, we would have to build an API that was both scalable and configurable.

Modularity would play an important role in the success or failure of this new venture.

Our journey has been one of exploration and discovery. We tried a wealth of technologies and tooling to find the perfect combination for us.

In this first blog post…

ALTEOS Tech

Alteos unleashes the potential of a digital insurance

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store