AJR/TechradarDev
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

docs: fix spelling issues in v5 release (#165)

Browse Source
This commit is contained in:
Stefan Rotsch
2023-02-22 19:02:16 +01:00
committed by Bastian
parent 03783eee3b
commit 46c32eefbe
7 changed files with 74 additions and 35 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
radar/2022-03-28/api-first-design-approach.md
View File

@@ -5,7 +5,13 @@ quadrant: methods-and-patterns
tags: [architecture] tags: [architecture]
--- ---
The API of any software we develop shapes in which way developers, teams, customers and users interact with our software. The API of any software we develop shapes in which way developers, teams, customers and users interact with our
No matter if a Frontend-API like GraphQL, a rpc-API like gRPC or an internal API published by a module in a larger project or shared library, messing the API up always creates headaches and is hard to correct. software.
If we stick to semantic versioning, it's actually pretty impossible to change a once-published API without breaking consumers.
By todays standards we priorize API design before actual development, to be clear on how our software interacts, and thus move this pattern to "adopt". No matter if a Frontend-API like GraphQL, a rpc-API like gRPC or an internal API published by a module in a larger
project or shared library, messing the API up always creates headaches and is hard to correct.
If we stick to semantic versioning, it's actually pretty impossible to change a once-published API without breaking
consumers.
By today's standards we prioritize API design before actual development, to be clear on how our software interacts, and
thus move this pattern to "adopt".

18
radar/2022-03-28/argocd.md
View File

@@ -5,10 +5,20 @@ quadrant: tools
tags: [ci/cd] tags: [ci/cd]
--- ---
We've been managing the state of application deployments in YAML files via Git repositories in the past. But we still wouldn't call this GitOps. A lot of custom glue code and tools were involved. While [helmfile](https://github.com/roboll/helmfile) replaces some of our custom tooling in a nice way we've also been trying a new approach with [Argo CD](https://argoproj.github.io/cd/). We've been managing the state of application deployments in YAML files via Git repositories in the past. But we still
wouldn't call this GitOps. A lot of custom glue code and tools were involved.
While [helmfile](https://github.com/roboll/helmfile) replaces some of our custom tooling in a nice way we've also been
trying a new approach with [Argo CD](https://argoproj.github.io/cd/).
Argo CD watches Git repositories continuously and makes sure the state defined there is applied to the Kubernetes cluster. It introduces a couple of CRDs including one representing a Helm deployment. Using an "[app of apps](https://argo-cd.readthedocs.io/en/stable/operator-manual/cluster-bootstrapping/#app-of-apps-pattern)" pattern you can bundle multiple apps together and use existing Git workflows (branching, tagging, PR) to manage releases to your various stages. Argo CD watches Git repositories continuously and makes sure the state defined there is applied to the Kubernetes
cluster. It introduces a couple of CRDs including one representing a Helm deployment. Using
an "[app of apps](https://argo-cd.readthedocs.io/en/stable/operator-manual/cluster-bootstrapping/#app-of-apps-pattern)"
pattern you can bundle multiple apps together and use existing Git workflows (branching, tagging, PR) to manage releases
to your various stages.
Also, the fact the Argo CD only needs read-only access to the Git repositories makes it a lot cleaner from a security point of view since no credentials to any clusters need to be buried in any CI/CD pipelines anymore. Also, the fact the Argo CD only needs read-only access to the Git repositories makes it a lot cleaner from a security
point of view since no credentials to any clusters need to be buried in any CI/CD pipelines anymore.
Additionally Argo CD comes with a nice web frontend that gives a lot of insight into what has been deployed and where problems might exist. For many developers this view on the cluster (with focus on their apps) might be the first go-to for checking their apps and troubleshooting issues making other tools like Lens or access via kubectl obsolete. Additionally, Argo CD comes with a nice web frontend that gives a lot of insight into what has been deployed and where
problems might exist. For many developers this view on the cluster (with focus on their apps) might be the first go-to
for checking their apps and troubleshooting issues making other tools like Lens or access via kubectl obsolete.

3
radar/2022-03-28/colima.md
View File

@@ -7,7 +7,8 @@ featured: false
[Colima](https://github.com/abiosoft/colima) provides container runtimes on macOS with minimal setup. [Colima](https://github.com/abiosoft/colima) provides container runtimes on macOS with minimal setup.
At AOE, we are using colima as drop-in replacement for [Docker Desktop](https://www.docker.com/products/docker-desktop/). At AOE, we are using Colima as drop-in replacement
for [Docker Desktop](https://www.docker.com/products/docker-desktop/).
The main benefits are The main benefits are

9
radar/2022-03-28/conventionalcommits.md
View File

@@ -4,6 +4,11 @@ ring: adopt
quadrant: methods-and-patterns quadrant: methods-and-patterns
--- ---
Conventional commits are being widely used in our teams, therefore we're changing this to adopt. Using commit messages which follow the [conventional commits specification](https://www.conventionalcommits.org/en/v1.0.0/) helps us to easily process changes made within a software release. It also helps to reduce confusion around commit message requirements for new team members. Conventional commits are being widely used in our teams, therefore we're changing this to adopt. Using commit messages
which follow the [conventional commits specification](https://www.conventionalcommits.org/en/v1.0.0/) helps us to easily
process changes made within a software release. It also helps to reduce confusion around commit message requirements for
new team members.
The [Semanticore](https://github.com/AOEpeople/semanticore) release bot is a tool we published, which utilizes conventional commits to maintain the release notes of our software and suggests the correct version of the upcoming release. The [Semanticore](https://github.com/AOEpeople/semanticore) release bot is a tool we published, which utilizes
conventional commits to maintain the release notes of our software and suggests the correct version of the upcoming
release.

38
radar/2022-03-28/nocode-lowcode.md
View File

@@ -6,27 +6,43 @@ featured: true
tags: [coding] tags: [coding]
--- ---
No-code or low-code refers to tools that allow application software to be created via graphical user interfaces and configuration - instead of (classic) text-based programming. No-code or low-code refers to tools that allow application software to be created via graphical user interfaces and
configuration - instead of (classic) text-based programming.
Low-code platforms additionally supports certain scripting possibilities. Low-code platforms additionally supports certain scripting possibilities.
No-code and low-code platforms have raised a lot of funding and the ecosystem is growing fast. There are more than 400 platforms listed on software selection websites like g2. No-code and low-code platforms have raised a lot of funding and the ecosystem is growing fast. There are more than 400
The promise of this ecosystem sounds logical: there is a growing demand for digital products and solutions in all sectors - and skilled teams of developers are scarce. platforms listed on software selection websites like g2.
That's why platforms like [bubble.io](https://bubble.io/), [airtable](https://www.airtable.com/), [appsheet](https://about.appsheet.com/home/), [bryter](https://bryter.com/), [ninox](https://ninox.com/de) and co promise to build digital products faster and better. The promise of this ecosystem sounds logical: there is a growing demand for digital products and solutions in all
sectors - and skilled teams of developers are scarce.
And the platforms have developed and the ecosystem is emerging. AI technics are being used to improve the creation process and modern low-code platforms also come with built-in release and operations support. We have used some low-code platforms for internal tools, for example to help organise events or onboarding activities. That's why platforms
like [bubble.io](https://bubble.io/), [airtable](https://www.airtable.com/),
[appsheet](https://about.appsheet.com/home/), [bryter](https://bryter.com/), [ninox](https://ninox.com/de)
and co promise to build digital products faster and better.
And the platforms have developed and the ecosystem is emerging. AI technics are being used to improve the creation
process and modern low-code platforms also come with built-in release and operations support. We have used some low-code
platforms for internal tools, for example to help organise events or onboarding activities.
Here are our thoughts on this: Here are our thoughts on this:
* We see opportunities to improve communication and collaboration between developers on such platforms and non-technical professionals (domain experts), as they can collaborate on the platform directly during the process of creating the digital product. * We see opportunities to improve communication and collaboration between developers on such platforms and non-technical
professionals (domain experts), as they can collaborate on the platform directly during the process of creating the
digital product.
* If the use case fits into the sweet spot of the platform, the results are very fast and surprising. * If the use case fits into the sweet spot of the platform, the results are very fast and surprising.
* There is a logical trade-off between simplicity and flexibility: platforms with a high level of abstraction and a low learning curve can deliver good results very quickly. However, if you have requirements that do not fit into the "standard" of the platform, it becomes difficult to customise. On the other hand, platforms that allow a lot of configuration and scripting come with a higher learning curve. And in some respects it may end beeing similar to using a programming framework. * There is a logical trade-off between simplicity and flexibility: platforms with a high level of abstraction and a low
learning curve can deliver good results very quickly. However, if you have requirements that do not fit into the
"standard" of the platform, it becomes difficult to customise. On the other hand, platforms that allow a lot of
configuration and scripting come with a higher learning curve. And in some respects it may end being similar to using
a programming framework.
* Operating costs can become a relevant factor - especially if you pay for high performance and higher utilisation. * Operating costs can become a relevant factor - especially if you pay for high performance and higher utilisation.
* You have to realise that with complex applications there is much more to do than "just" writing code. Test architecture, api design, integrations, careful design of the solution, proper testing, CI/CD strategy.... etc. So there is still a need for skilled (development) teams to do this work. * You have to realise that with complex applications there is much more to do than "just" writing code. Test
architecture, api design, integrations, careful design of the solution, proper testing, CI/CD strategy etc. So
there is still a need for skilled (development) teams to do this work.
Thinking about the different aspects, we will not consider low-code platforms as the core technology in complex software
Thinking about the different aspects, we will not consider low-code platforms as the core technology in complex software development projects - but we think that even in larger IT projects or organisations there are valid use cases or certain "bounded contexts" where using a low-code platform is a proper choice and helps to deliver results faster. development projects - but we think that even in larger IT projects or organisations there are valid use cases or
certain "bounded contexts" where using a low-code platform is a proper choice and helps to deliver results faster.

7
radar/2022-03-28/spock_geb.md
View File

@@ -5,10 +5,11 @@ quadrant: languages-and-frameworks
tags: [coding, quality assurance] tags: [coding, quality assurance]
--- ---
[spockframework.org](http://www.spockframework.org) - Spock is a testing and specification framework for Java and Groovy applications. [spockframework.org](http://www.spockframework.org) - Spock is a testing and specification framework for Java and Groovy
applications.
For the most parts we switched from Groovy to Java or Kotlin with JUnit 5. In this regard we think that the active community and regular For the most parts we switched from Groovy to Java or Kotlin with JUnit 5. In this regard we think that the active
updates and extension libraries of JUnit 5 cover everything we want or need. community and regular updates and extension libraries of JUnit 5 cover everything we want or need.
[gebish.org](http://www.gebish.org) - Geb is a browser automation solution. [gebish.org](http://www.gebish.org) - Geb is a browser automation solution.