docs: fix spelling issues in v5 release (#165)
This commit is contained in:
@@ -2,10 +2,16 @@
|
|||||||
title: "API-First Design Approach"
|
title: "API-First Design Approach"
|
||||||
ring: adopt
|
ring: adopt
|
||||||
quadrant: methods-and-patterns
|
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".
|
||||||
|
|||||||
@@ -2,13 +2,23 @@
|
|||||||
title: "Argo CD"
|
title: "Argo CD"
|
||||||
ring: trial
|
ring: trial
|
||||||
quadrant: tools
|
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.
|
||||||
|
|||||||
@@ -1,13 +1,14 @@
|
|||||||
---
|
---
|
||||||
title: "Colima"
|
title: "Colima"
|
||||||
ring: assess
|
ring: assess
|
||||||
quadrant: tools
|
quadrant: tools
|
||||||
featured: false
|
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
|
||||||
|
|
||||||
@@ -19,4 +20,4 @@ as well as the usual requirements for container runtimes like
|
|||||||
- Docker and Containerd support
|
- Docker and Containerd support
|
||||||
- Port forwarding
|
- Port forwarding
|
||||||
- Volume mount
|
- Volume mount
|
||||||
- Kubernetes
|
- Kubernetes
|
||||||
|
|||||||
@@ -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.
|
||||||
|
|||||||
@@ -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.
|
||||||
|
|||||||
@@ -2,16 +2,17 @@
|
|||||||
title: "Spock + Geb"
|
title: "Spock + Geb"
|
||||||
ring: hold
|
ring: hold
|
||||||
quadrant: languages-and-frameworks
|
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.
|
||||||
|
|
||||||
UI testing with Geb is replaced by Cypress or Playwright.
|
UI testing with Geb is replaced by Cypress or Playwright.
|
||||||
|
|
||||||
<!--except-->
|
<!--except-->
|
||||||
|
|||||||
@@ -2,7 +2,7 @@
|
|||||||
title: "Vistecture"
|
title: "Vistecture"
|
||||||
ring: assess
|
ring: assess
|
||||||
quadrant: tools
|
quadrant: tools
|
||||||
tags: [documentation, architecture]
|
tags: [documentation, architecture]
|
||||||
---
|
---
|
||||||
|
|
||||||
[Vistecture](https://vistecture.me/) is a tool for the visualization and analysis of distributed
|
[Vistecture](https://vistecture.me/) is a tool for the visualization and analysis of distributed
|
||||||
|
|||||||
Reference in New Issue
Block a user