— 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…
— by Olena Semiankiv
The right tool with a variety of ready-to-use features and possibility to extend it!
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”
— 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. …
— by Olena Semiankiv
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…
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.
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…
by Tom Burton
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.
Towards the end of 2019, we…
— for startups
by Khalil Najjar
And the reason for that is simple: developers ❤ TypeScript.
by Tom Burton
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…