docs: proofread and finalize blips for v8
This commit is contained in:
Stefan Rotsch
committed by
Stefan Rotsch
Stefan Rotsch
parent
60f12f9549
commit
0fedaab680
@@ -9,27 +9,27 @@ The [12-factor app](https://12factor.net/de/) methodology, originally developed
|
||||
|
||||
### Core Principles of 12-Factor Apps
|
||||
|
||||
1) **Codebase**: Maintain a single codebase tracked in version control, with multiple deployments.
|
||||
2) **Dependencies**: Explicitly declare and isolate dependencies.
|
||||
3) **Config**: Store configuration in the environment.
|
||||
4) **Backing Services**: Treat backing services as attached resources.
|
||||
5) **Build, Release, Run**: Strictly separate build and run stages.
|
||||
6) **Processes**: Execute the app as one or more stateless processes.
|
||||
7) **Port Binding**: Export services via port binding.
|
||||
8) **Concurrency**: Scale out via the process model.
|
||||
9) **Disposability**: Maximize robustness with fast startup and graceful shutdown.
|
||||
10) **Dev/Prod Parity**: Keep development, staging, and production as similar as possible.
|
||||
11) **Logs**: Treat logs as event streams.
|
||||
12) **Admin Processes**: Run admin/management tasks as one-off processes.
|
||||
1. **Codebase**: Maintain a single codebase tracked in version control, with multiple deployments.
|
||||
2. **Dependencies**: Explicitly declare and isolate dependencies.
|
||||
3. **Config**: Store configuration in the environment.
|
||||
4. **Backing Services**: Treat backing services as attached resources.
|
||||
5. **Build, Release, Run**: Strictly separate build and run stages.
|
||||
6. **Processes**: Execute the app as one or more stateless processes.
|
||||
7. **Port Binding**: Export services via port binding.
|
||||
8. **Concurrency**: Scale out via the process model.
|
||||
9. **Disposability**: Maximize robustness with fast startup and graceful shutdown.
|
||||
10. **Dev/Prod Parity**: Keep development, staging, and production as similar as possible.
|
||||
11. **Logs**: Treat logs as event streams.
|
||||
12. **Admin Processes**: Run admin/management tasks as one-off processes.
|
||||
|
||||
### Extending to 15 Factors
|
||||
|
||||
The 15-factor model builds upon the original principles by adding:
|
||||
|
||||
13) **API First**: Design APIs first to ensure interoperability and future-proofing.
|
||||
14) **Telemetry**: Implement robust telemetry for monitoring and diagnostics.
|
||||
15) **Authentication and Authorization**: Incorporate strong, centralized authentication and authorization mechanisms.
|
||||
13. **API First**: Design APIs first to ensure interoperability and future-proofing.
|
||||
14. **Telemetry**: Implement robust telemetry for monitoring and diagnostics.
|
||||
15. **Authentication and Authorization**: Incorporate strong, centralized authentication and authorization mechanisms.
|
||||
|
||||
### Relevance
|
||||
|
||||
For us this rather old pattern is still very relevant and many methods, patterns and practices on our radar are related and enable these pattern in their core. To name a few [Kubernetes](/platforms-and-aoe-services/kubernetes/), [Prometheus](/platforms-and-aoe-services/prometheus/), [Self-Service Infrastructure](/platforms-and-aoe-services/self-service-infrastructure/) or the [API-First Design Approach](/methods-and-patterns/api-first-design-approach/) are very related, others like [Shared Responsibility Models](/methods-and-patterns/shared-responsibility/) are easier to implement based on this pattern.
|
||||
For us, this rather old pattern is still very relevant, and many methods, patterns, and practices on our radar are related and enable these patterns at their core. To name a few, [Kubernetes](/platforms-and-aoe-services/kubernetes/), [Prometheus](/platforms-and-aoe-services/prometheus/), [Self-Service Infrastructure](/platforms-and-aoe-services/self-service-infrastructure/), or the [API-First Design Approach](/methods-and-patterns/api-first-design-approach/) are very related. Others, like [Shared Responsibility Models](/methods-and-patterns/shared-responsibility/), are easier to implement based on this pattern.
|
||||
|
||||
@@ -5,13 +5,11 @@ quadrant: tools
|
||||
tags: [devops]
|
||||
---
|
||||
|
||||
[Apache APISIX](https://apisix.apache.org/) is an open-source, high-performance API gateway, designed for
|
||||
microservices, cloud-native and container-based architecture. It provides a wide range of features to manage
|
||||
and secure API services:
|
||||
[Apache APISIX](https://apisix.apache.org/) is an open-source, high-performance API gateway designed for microservices, cloud-native, and container-based architecture. It provides a wide range of features to manage and secure API services:
|
||||
|
||||
- Scalability: Load balancing and routing, dynamic scaling
|
||||
- Performance: Fast and reliable, supports caching and rate limiting
|
||||
- Multi-Protocol Support: Supports HTTP, HTTPS, WebSockets and gRPC
|
||||
- Customization: Plugins for authentication, authorization and traffic management
|
||||
- **Scalability**: Load balancing and routing, dynamic scaling
|
||||
- **Performance**: Fast and reliable, supports caching and rate limiting
|
||||
- **Multi-Protocol Support**: Supports HTTP, HTTPS, WebSockets, and gRPC
|
||||
- **Customization**: Plugins for authentication, authorization, and traffic management
|
||||
|
||||
APISIX is currently in trial at AOE and is being used in multiple projects.
|
||||
APISIX is currently in trial at AOE and is being used in multiple projects.
|
||||
|
||||
@@ -4,3 +4,5 @@ ring: adopt
|
||||
quadrant: tools
|
||||
tags: [ci/cd]
|
||||
---
|
||||
|
||||
Argo CD has proven its effectiveness in various projects by successfully simplifying and automating Kubernetes application deployments.
|
||||
|
||||
@@ -16,9 +16,6 @@ The use of [GitHub Copilot](/tools/github-copilot/) is currently project-based a
|
||||
### Potential Risks and Mitigation Strategies
|
||||
|
||||
- **Code Quality and Reliability**: Validate and review generated code before integration into the project. Manual code reviews and testing should remain fundamental to the development process.
|
||||
|
||||
- **Security Vulnerabilities**: Conduct thorough security assessments and penetration testing to identify and rectify potential weaknesses. Stay updated with security best practices and ensure AI-generated code aligns with secure coding guidelines.
|
||||
|
||||
- **Intellectual Property Concerns**: Scrutinize licensing and usage terms of AI tools. Exercise caution when incorporating code snippets from external sources and ensure compliance with relevant licenses.
|
||||
|
||||
- **Data Privacy**: Review data access and privacy policies of AI tools meticulously. Prevent inadvertent exposure or sharing of sensitive or confidential information with third parties.
|
||||
|
||||
@@ -10,9 +10,6 @@ tags: [academy training, frontend, quality assurance]
|
||||
### Key Updates and Enhancements of the Past Years
|
||||
|
||||
- **Broader Browser Support**: Cypress now supports a wider range of browsers, including Edge and WebKit, in addition to Chrome, Firefox, and Electron. This expansion ensures comprehensive testing across more environments.
|
||||
|
||||
- **Improved Performance**: The latest versions of Cypress have focused on enhancing test execution speed. Optimizations in the core engine and better resource management have resulted in faster and more reliable test runs, even for large and complex test suites.
|
||||
|
||||
- **Enhanced Debugging Capabilities**: Debugging has become even more user-friendly with improved tooling. Features like time travel, where developers can step through each test command, and better error messages help in quickly identifying and resolving issues.
|
||||
|
||||
- **CI/CD Integration**: Cypress has strengthened its integration with popular CI/CD tools. Improved plugins and configurations for platforms like GitHub Actions, GitLab CI, CircleCI, and Jenkins make it easier to incorporate Cypress tests into continuous integration and continuous deployment pipelines.
|
||||
|
||||
@@ -9,7 +9,5 @@ featured: false
|
||||
In recent years, messaging systems have become more robust, scalable, and easier to integrate with existing applications. This has increased the importance of messaging in modern software architectures, making it an essential strategy for decoupling components and ensuring the resilience and stability of distributed systems:
|
||||
|
||||
- **Event Streaming**: Platforms such as [Apache Kafka](/tools/kafka/) have evolved significantly to handle massive data streams with enhanced reliability and integration capabilities.
|
||||
|
||||
- **Serverless Messaging**: The rise of [serverless computing](/methods-and-patterns/serverless/) has simplified the creation of scalable, event-driven architectures, allowing developers to build complex workflows and event-processing pipelines without the overhead of managing infrastructure.
|
||||
|
||||
- **Advanced Observability**: Improved tools for monitoring and managing messaging systems now offer detailed insights into message flows and system performance, enabling faster diagnosis and resolution of issues.
|
||||
|
||||
@@ -5,12 +5,10 @@ ring: assess
|
||||
tags: [coding, devops]
|
||||
---
|
||||
|
||||
[DevSpace](https://www.devspace.sh/) is an open-source developer tool for Kubernetes that lets you develop and
|
||||
deploy cloud-native software faster. As a "client-only" development tool, it is very simple to develop kubernetes
|
||||
native applications in local or any remote cluster.
|
||||
[DevSpace](https://www.devspace.sh/) is an open-source developer tool for Kubernetes that lets you develop and deploy cloud-native software faster. As a "client-only" development tool, it is very simple to develop Kubernetes-native applications in local or any remote cluster.
|
||||
|
||||
- **Build**, test and debug applications directly inside Kubernetes
|
||||
- **Develop** with hot reloading: updates your running containers without rebuilding images or restarting containers
|
||||
- **Unify** deployment workflows within your team and across dev, staging and production
|
||||
- **Automate** repetitive tasks for image building and deployment
|
||||
- **Hot-Reloading** allows to recompile and restart Pods in local or remote clusters
|
||||
- **Build**, test, and debug applications directly inside Kubernetes.
|
||||
- **Develop** with hot reloading: updates your running containers without rebuilding images or restarting containers.
|
||||
- **Unify** deployment workflows within your team and across dev, staging, and production.
|
||||
- **Automate** repetitive tasks for image building and deployment.
|
||||
- **Hot-Reloading** allows to recompile and restart Pods in local or remote clusters.
|
||||
|
||||
@@ -6,4 +6,4 @@ tags: [devops]
|
||||
featured: false
|
||||
---
|
||||
|
||||
While we continue to recommend the ELK Stack for specific use cases, we now prefer [Loki](/platforms-and-aoe-services/loki/) for most [Kubernetes](/platforms-and-aoe-services/kubernetes/)-based setups due to its seamless integration, cost efficiency and user-friendly query language.
|
||||
While we continue to recommend the ELK Stack for specific use cases, we now prefer [Loki](/platforms-and-aoe-services/loki/) for most [Kubernetes](/platforms-and-aoe-services/kubernetes/)-based setups due to its seamless integration, cost efficiency, and user-friendly query language.
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: "GitHub Copilot"
|
||||
ring: adopt
|
||||
quadrant: "tools"
|
||||
quadrant: tools
|
||||
tags: [ai, architecture, coding]
|
||||
---
|
||||
|
||||
|
||||
@@ -5,4 +5,4 @@ quadrant: tools
|
||||
tags: [devops]
|
||||
---
|
||||
|
||||
[k3d](https://k3d.io/) is a lightweight wrapper to run [k3s](https://k3s.io) (Rancher Lab’s minimal Kubernetes distribution) in docker. It is a very useful tool to create kubernetes native development environments or use it as sandbox to test out things locally.
|
||||
[k3d](https://k3d.io/) is a lightweight wrapper to run [k3s](https://k3s.io) (Rancher Lab’s minimal Kubernetes distribution) in Docker. It is a very useful tool to create Kubernetes-native development environments or use it as a sandbox to test out things locally.
|
||||
|
||||
@@ -10,15 +10,10 @@ tags: [ai]
|
||||
## Key Features
|
||||
|
||||
- **Integration with Multiple NLP Models**: LangChain supports the integration of various NLP models, allowing developers to choose the best-suited models for their specific use cases.
|
||||
|
||||
- **Support for Vector Databases**: The framework can seamlessly connect with different vector databases, which are crucial for implementing RAG patterns and enhancing the retrieval process in NLP applications.
|
||||
|
||||
- **Preconfigured Chains**: LangChain provides pre-built chains for typical NLP tasks, such as question-answering and chatbots, reducing the time and effort required to build these functionalities from scratch.
|
||||
|
||||
- **Compatibility with Open-Source Libraries**: LangChain is designed to work well with established open-source libraries, making it easier for developers to incorporate it into their existing workflows and leverage a wide range of tools and resources.
|
||||
|
||||
- **Ease of Deployment**: The framework simplifies the deployment process of NLP applications, ensuring that they can be quickly and efficiently moved from development to production.
|
||||
|
||||
- **Versatile Use Cases**: LangChain is suitable for a variety of NLP applications, making it a versatile tool for developers working in different domains.
|
||||
|
||||
LangChain stands out as a powerful framework for developers, utilizing and integrating well-known open-source libraries.
|
||||
|
||||
@@ -7,7 +7,7 @@ tags: [agile, architecture]
|
||||
|
||||
A core concept of Domain-Driven Design (DDD) is the distillation of the problem domain into distinct, bounded contexts, with dedicated teams assigned to and responsible for those contexts. Microservices are often used to implement these bounded contexts in software applications. The communication patterns between teams will shape how these microservices are designed and interact, as per Conway's Law.
|
||||
|
||||
Team autonomy is crucial for achieving a truly independent microservice architecture, driving innovation and agility. However, full autonomy can lead to the formation of microsilos: isolated teams working independently, often resulting in inconsistent implementations, communication gaps, and hidden dependencies and redundancies.
|
||||
Team autonomy is crucial for achieving a truly independent microservice architecture, driving innovation and agility. However, full autonomy can lead to the formation of microsilos: isolated teams working independently, often resulting in inconsistent implementations, communication gaps, hidden dependencies, and redundancies.
|
||||
|
||||
### Mitigation Strategies
|
||||
- **Strategic Domain-Driven Design**: Ensure that bounded contexts and their interrelationships are well-defined, both organizationally (team structure) and technically (interfaces).
|
||||
|
||||
@@ -12,11 +12,8 @@ The concept of the strategic monolith stems from the idea that starting with a m
|
||||
### Benefits
|
||||
|
||||
- **Future-Proof Architecture**: Modular design within a monolith allows for parts of the system to be easily extracted into individual microservices as requirements evolve or the business grows. This approach ensures that the architecture can adapt to changing needs without extensive refactoring.
|
||||
|
||||
- **Operational Simplicity**: Starting with a monolithic architecture simplifies deployment and management by keeping all modules within a single deployable unit. This reduces the complexity and overhead associated with distributed systems, such as handling inter-service communication, distributed data management, and comprehensive monitoring.
|
||||
|
||||
- **Performance and Latency Benefits**: Intra-process communication within a monolith results in lower latency and higher performance compared to inter-service communication in microservices. This ensures that the system remains responsive and efficient as it scales.
|
||||
|
||||
- **Reduced Complexity**: A "monolith first" approach avoids the initial challenges of distributed systems, allowing teams to focus on building robust features and gaining a deep understanding of the domain before considering a transition to microservices.
|
||||
|
||||
At AOE, we strive to follow this approach when starting greenfield projects. We aim to balance between creating systems that are "as small as possible" yet "as big as necessary," ensuring robust and maintainable architectures that can scale and evolve with business needs. This provides a balanced path that aligns immediate development needs with long-term architectural goals.
|
||||
|
||||
@@ -5,5 +5,3 @@ quadrant: platforms-and-aoe-services
|
||||
tags: [devops]
|
||||
featured: false
|
||||
---
|
||||
|
||||
OCI Containers are a well-established industry standard now.
|
||||
|
||||
@@ -5,12 +5,12 @@ quadrant: tools
|
||||
tags: [ai, coding]
|
||||
---
|
||||
|
||||
Running large language models local?
|
||||
Running large language models locally?
|
||||
|
||||
Downloading [Ollama](https://ollama.com/download) and typing `ollama run llama3` is all you need.
|
||||
|
||||
Ollama is great to run various open source (open weight) models local and interact with them. You can do this either via the command line or via the [Ollama API](https://github.com/ollama/ollama/blob/main/docs/api.md).
|
||||
Ollama is great for running various open source (open weight) models locally and interacting with them. You can do this either via the command line or via the [Ollama API](https://github.com/ollama/ollama/blob/main/docs/api.md).
|
||||
|
||||
Ollama takes care of downloading and running models and it supports the specification of own model packages in a "Modelfile".
|
||||
Ollama takes care of downloading and running models, and it supports the specification of your own model packages in a "Modelfile".
|
||||
|
||||
At AOE, we use it for local development and testing.
|
||||
|
||||
@@ -5,16 +5,15 @@ quadrant: tools
|
||||
tags: [architecture]
|
||||
---
|
||||
|
||||
The [OpenAPI Specification](https://www.openapis.org/) (OAS) is a broadly adopted industry standard for describing modern REST APIs.
|
||||
Other initiatives like RAML have [joined](https://blogs.mulesoft.com/dev/api-dev/open-api-raml-better-together/) the OpenAPI Initiative.
|
||||
The [OpenAPI Specification](https://www.openapis.org/) (OAS) is a broadly adopted industry standard for describing modern REST APIs. Other initiatives like RAML have [joined](https://blogs.mulesoft.com/dev/api-dev/open-api-raml-better-together/) the OpenAPI Initiative.
|
||||
|
||||
**OpenAPI v3**
|
||||
|
||||
The current version OpenAPI v3 added more features to the specification - for example the ability to describe APIs supporting request/callback pattern.
|
||||
The current version, OpenAPI v3, added more features to the specification, for example, the ability to describe APIs supporting request/callback patterns.
|
||||
|
||||
There is a very good api designer https://www.apicur.io/ and a good mock generator http://microcks.github.io/
|
||||
There is a very good API designer: [Apicurio](https://www.apicur.io/) and a good mock generator: [Microcks](http://microcks.github.io/).
|
||||
|
||||
The general tool support is excellent. See https://openapi.tools/
|
||||
The general tool support is excellent. See [OpenAPI Tools](https://openapi.tools/).
|
||||
|
||||
**TM Forum Open API**
|
||||
|
||||
|
||||
@@ -5,4 +5,4 @@ quadrant: platforms-and-aoe-services
|
||||
tags: [devops]
|
||||
---
|
||||
|
||||
[OpenTofu](https://opentofu.org/) is a open source, community driven fork of terraform in response to HashiCorps license changes. It's terraform 1.6 compatible and can act as a drop-in replacement. We watch development and ecosystem growth closely and evaluate a move from terraform to OpenTofu in some projects.
|
||||
[OpenTofu](https://opentofu.org/) is an open-source, community-driven fork of [Terraform](/platforms-and-aoe-services/terraform/) in response to HashiCorp's license changes. It's Terraform 1.6 compatible and can act as a drop-in replacement. We watch development and ecosystem growth closely and evaluate a move from Terraform to OpenTofu in some projects.
|
||||
|
||||
@@ -5,12 +5,8 @@ quadrant: languages-and-frameworks
|
||||
tags: [ci/cd, devops]
|
||||
---
|
||||
|
||||
[PKL](https://pkl-lang.org/) -- pronounced Pickle -- is a configuration language created by Apple. It provides rich support for data templating
|
||||
and validation and can be used, simply from commandline, integrated into build-pipelines or embedded into programs. PKL
|
||||
also provides some tooling around package-management, which makes it easy to split up bigger project into packages or
|
||||
just consume packages that are already out there.
|
||||
[PKL](https://pkl-lang.org/) -- pronounced Pickle -- is a configuration language created by Apple. It provides rich support for data templating and validation and can be used simply from the command line, integrated into build pipelines, or embedded into programs. PKL also provides some tooling around package management, which makes it easy to split up bigger projects into packages or just consume packages that are already out there.
|
||||
|
||||
Available PKL packages and docs can be found [here](https://pkl-lang.org/package-docs/).
|
||||
|
||||
At AOE we are using pkl currently for generation of different kinds of DevOps resources like Gitlab-CI
|
||||
Pipelines or Kubernetes resources, but this might change.
|
||||
At AOE, we are currently using PKL for the generation of different kinds of DevOps resources like GitLab CI pipelines or Kubernetes resources, but this might change.
|
||||
|
||||
@@ -6,4 +6,4 @@ tags: [devops]
|
||||
featured: false
|
||||
---
|
||||
|
||||
Puppet works well for over 11 years for us.
|
||||
Puppet has worked well for us for over 11 years.
|
||||
|
||||
@@ -5,8 +5,8 @@ quadrant: languages-and-frameworks
|
||||
tags: [coding, frontend]
|
||||
---
|
||||
|
||||
With Remix v2.2.0 Remix itself is now just a Vite plugin. This gives us access to the entire ecosystem of Vite plugins and even more, for example:
|
||||
With Remix v2.2.0, Remix itself is now just a Vite plugin. This gives us access to the entire ecosystem of Vite plugins and even more, for example:
|
||||
|
||||
- **Near-instant dev startup.** Vite lazily compiles your app code on-demand, so the dev server can boot immediately.
|
||||
- **Pre-bundled dependencies.** Vite only processes dependencies once, so large libraries like Material UI and AntD don’t become bottlenecks for rebuilds nor hot updates.
|
||||
- **Incremental hot updates.** Vite keeps track of dependencies so it only needs to reprocess app code that depends on the changes.
|
||||
- **Near-instant dev startup**: Vite lazily compiles your app code on-demand, so the dev server can boot immediately.
|
||||
- **Pre-bundled dependencies**: Vite only processes dependencies once, so large libraries like Material UI and AntD don’t become bottlenecks for rebuilds or hot updates.
|
||||
- **Incremental hot updates**: Vite keeps track of dependencies so it only needs to reprocess app code that depends on the changes.
|
||||
|
||||
@@ -18,8 +18,8 @@ tags: [ai]
|
||||
### Challenges
|
||||
|
||||
- **Latency**: Retrieving and processing external data in real-time can introduce latency, potentially slowing down response times compared to purely generative models.
|
||||
- **Dependence on external data quality**: The accuracy and relevance of the generated content is highly dependent on the quality and reliability of the external data sources. Poor quality or outdated data can negatively impact the results.
|
||||
- **Security and privacy**: Accessing *external* data sources can expose the system to security vulnerabilities and privacy concerns. Mitigation strategies include careful data access management and robust security measures in the retrieval process.
|
||||
- **Dependence on external data quality**: The accuracy and relevance of the generated content are highly dependent on the quality and reliability of the external data sources. Poor quality or outdated data can negatively impact the results.
|
||||
- **Security and privacy**: Accessing external data sources can expose the system to security vulnerabilities and privacy concerns. Mitigation strategies include careful data access management and robust security measures in the retrieval process.
|
||||
- **Maintenance overhead**: Regular updates and maintenance of the retrieval system and data sources are required to ensure continued accuracy and relevance, adding to the operational burden.
|
||||
- **Potential for bias**: The retrieval process can introduce biases present in the external data, which can be propagated into the generated content, affecting the fairness and objectivity of the outputs.
|
||||
|
||||
|
||||
@@ -2,6 +2,6 @@
|
||||
title: "RxJava"
|
||||
ring: trial
|
||||
quadrant: tools
|
||||
tags: [coding, architecture]
|
||||
tags: [architecture, coding]
|
||||
featured: false
|
||||
---
|
||||
|
||||
@@ -2,6 +2,6 @@
|
||||
title: "Self-Service Infrastructure"
|
||||
ring: trial
|
||||
quadrant: platforms-and-aoe-services
|
||||
tags: [devops, agile]
|
||||
tags: [agile, devops]
|
||||
featured: false
|
||||
---
|
||||
|
||||
@@ -5,10 +5,6 @@ quadrant: platforms-and-aoe-services
|
||||
tags: [architecture, devops, security]
|
||||
---
|
||||
|
||||
Service Meshes are part of all our Kubernetes implementations now.
|
||||
We value the additional security features they provide to our platforms.
|
||||
Service Meshes are part of all our Kubernetes implementations now. We value the additional security features they provide to our platforms.
|
||||
|
||||
We are using [Istio](https://istio.io/) on multiple production clusters
|
||||
and are assessing [Cillium](https://docs.cilium.io/en/latest/network/servicemesh/)
|
||||
as it also improves on Kubernetes' NetworkPolicies. We also consider [Linkerd](https://linkerd.io)
|
||||
a good candidate when looking for a Service Mesh for your project.
|
||||
We are using [Istio](https://istio.io/) on multiple production clusters and are assessing [Cilium](https://docs.cilium.io/en/latest/network/servicemesh/) as it also improves on Kubernetes' NetworkPolicies. We also consider [Linkerd](https://linkerd.io) a good candidate when looking for a Service Mesh for your project.
|
||||
|
||||
@@ -5,4 +5,4 @@ quadrant: tools
|
||||
tags: [architecture, coding]
|
||||
---
|
||||
|
||||
[Socket.IO](https://socket.io) is a library for enabling real-time, bidirectional communication between web clients and servers based on websockets. It simplifies complex tasks involved in real-time data transfer and supports features like automatic reconnection and fallback to different transports if needed. This makes it ideal for applications such as chat apps, live notifications, and collaborative tools. Its event-based architecture and support for namespaces and rooms make it versatile and scalable. We are currently evaluating if its usage could be benificial for some of our projects.
|
||||
[Socket.IO](https://socket.io) is a library for enabling real-time, bidirectional communication between web clients and servers based on websockets. It simplifies complex tasks involved in real-time data transfer and supports features like automatic reconnection and fallback to different transports if needed. This makes it ideal for applications such as chat apps, live notifications, and collaborative tools. Its event-based architecture and support for namespaces and rooms make it versatile and scalable. We are currently evaluating if its usage could be beneficial for some of our projects.
|
||||
|
||||
@@ -11,6 +11,6 @@ In addition, new tools and techniques have emerged that support the practical ap
|
||||
|
||||
* **Core Domain Charts**: Introduced by Eric Evans in 2019, these support the identification and prioritization of core business domains, ensuring that critical areas receive appropriate focus and resources.
|
||||
* **Event Storming**: A popular workshop format for collaboratively exploring complex domains, facilitating a shared understanding and uncovering domain insights.
|
||||
* **Wardley Maps**: Created by Simon Wardley, are a visualization tool that helps organizations understand their business landscape, anticipate change, and identify strategic opportunities.
|
||||
* **Wardley Maps**: Created by Simon Wardley, these are a visualization tool that helps organizations understand their business landscape, anticipate change, and identify strategic opportunities.
|
||||
|
||||
The continuing relevance of Eric Evans' *Domain-Driven Design*, more than 20 years after after the book was first published, underscores its importance in modern software development.
|
||||
The continuing relevance of Eric Evans' *Domain-Driven Design*, more than 20 years after the book was first published, underscores its importance in modern software development.
|
||||
|
||||
@@ -9,7 +9,7 @@ Facebook has released [StyleX](https://stylexjs.com/), an open-source JavaScript
|
||||
|
||||
It supports frameworks like [React](/languages-and-frameworks/react/) and [Angular](/languages-and-frameworks/angular/). Styles are defined using an object syntax and `create()` API, and can be conditionally applied within components.
|
||||
|
||||
### Key Features:
|
||||
### Key Features
|
||||
- **Atomic CSS**: Minimizes CSS output
|
||||
- **Type-Safe**: Ensures reliability in large projects
|
||||
- **Composable**: Facilitates reusable components
|
||||
|
||||
@@ -7,7 +7,7 @@ tags: [devops, security]
|
||||
|
||||
Software supply chain security is a complex endeavor. Attack vectors range from external dependencies in source code to operating systems and tools used in build, test, and production environments. Compromise of a single stage of the supply chain may lead to compromise of the produced software and subsequently of customers that rely on it.
|
||||
|
||||
Over the last years, successful attacks on large software vendors have demonstrated the potential impact of such attacks. For instance, the SolarWinds Orion software was [compromised](https://en.wikipedia.org/wiki/SolarWinds#2019%E2%80%932020_supply_chain_attacks) due to an insecure password that allowed attackers to inject a backdoor into software artifacts. Several SolarWinds customers, including US federal government agencies, were compromised as a result of this attack. The [xz backdoor](https://tukaani.org/xz-backdoor/) showed that malicious parties are also stepping up their efforts to place backdoors in widely used open-source software projects in ways that are very hard to detect and prevent.
|
||||
Over the last few years, successful attacks on large software vendors have demonstrated the potential impact of such attacks. For instance, the SolarWinds Orion software was [compromised](https://en.wikipedia.org/wiki/SolarWinds#2019%E2%80%932020_supply_chain_attacks) due to an insecure password that allowed attackers to inject a backdoor into software artifacts. Several SolarWinds customers, including US federal government agencies, were compromised as a result of this attack. The [xz backdoor](https://tukaani.org/xz-backdoor/) showed that malicious parties are also stepping up their efforts to place backdoors in widely used open-source software projects in ways that are very hard to detect and prevent.
|
||||
|
||||
Software libraries and other external dependencies are a major attack vector when building software. We use the following measures regarding external dependencies to improve supply chain security:
|
||||
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: "Svelte"
|
||||
ring: trial
|
||||
quadrant: "languages-and-frameworks"
|
||||
quadrant: languages-and-frameworks
|
||||
tags: [coding, frontend]
|
||||
featured: false
|
||||
---
|
||||
|
||||
@@ -8,6 +8,6 @@ featured: false
|
||||
|
||||
Terraform has become a de facto standard as a cloud-provider-agnostic infrastructure-as-code tool in recent years.
|
||||
|
||||
Unfortunately, the [license change for HashiCorp products in August 2023](https://www.hashicorp.com/blog/hashicorp-adopts-business-source-license) has caused [some](https://blog.gruntwork.io/the-future-of-terraform-must-be-open-ab0b9ba65bca) [turmoil](https://zeet.co/blog/the-impact-of-hashicorps-license-change-on-terraform-users-and-providers-what-you-need-to-know) within the open source community. Terraform can no longer be considered truly open source. Of particular concern are the [usage limitations that prohibit "competitive offerings" to HashiCorp's products](https://www.hashicorp.com/license-faq#usage-limitations). The vagueness of this definition, coupled with the fact that HashiCorp can change their interpretation of what constitutes a "competitive offer" at any time, poses a potential liability for agencies and their customers.
|
||||
Unfortunately, the [license change for HashiCorp products in August 2023](https://www.hashicorp.com/blog/hashicorp-adopts-business-source-license) has caused [some](https://blog.gruntwork.io/the-future-of-terraform-must-be-open-ab0b9ba65bca) [turmoil](https://zeet.co/blog/the-impact-of-hashicorps-license-change-on-terraform-users-and-providers-what-you-need-to-know) within the open-source community. Terraform can no longer be considered truly open source. Of particular concern are the [usage limitations that prohibit "competitive offerings" to HashiCorp's products](https://www.hashicorp.com/license-faq#usage-limitations). The vagueness of this definition, coupled with the fact that HashiCorp can change their interpretation of what constitutes a "competitive offer" at any time, poses a potential liability for agencies and their customers.
|
||||
|
||||
As a result, we are currently [assessing OpenTofu](/platforms-and-aoe-services/opentofu/) as a drop-in replacement for Terraform. [OpenTofu](https://opentofu.org) is an open source fork under the umbrella of the Linux Foundation, created from the last commit before Terraform's license change.
|
||||
As a result, we are currently [assessing OpenTofu](/platforms-and-aoe-services/opentofu/) as a drop-in replacement for Terraform. [OpenTofu](https://opentofu.org) is an open-source fork under the umbrella of the Linux Foundation, created from the last commit before Terraform's license change.
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
title: "Trivy"
|
||||
ring: adopt
|
||||
quadrant: tools
|
||||
tags: [ci/cd,devops,security]
|
||||
tags: [ci/cd, devops, security]
|
||||
featured: false
|
||||
---
|
||||
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: "Turborepo"
|
||||
ring: trial
|
||||
quadrant: "tools"
|
||||
quadrant: tools
|
||||
tags: [frontend]
|
||||
featured: false
|
||||
---
|
||||
|
||||
@@ -2,6 +2,6 @@
|
||||
title: "Unleash"
|
||||
ring: adopt
|
||||
quadrant: tools
|
||||
tags: [coding, frontend, devops]
|
||||
tags: [coding, devops, frontend]
|
||||
featured: false
|
||||
---
|
||||
|
||||
@@ -2,6 +2,6 @@
|
||||
title: "Vistecture"
|
||||
ring: assess
|
||||
quadrant: tools
|
||||
tags: [documentation, architecture]
|
||||
tags: [architecture, documentation]
|
||||
featured: false
|
||||
---
|
||||
|
||||
@@ -11,6 +11,6 @@ Visual regression tests address several challenges. They ensure consistency in t
|
||||
|
||||
Moreover, integrating visual regression tests into development pipelines enhances the reliability of deployments. By catching visual discrepancies early, it prevents potential UI issues from reaching end-users. This not only saves time and resources but also maintains the application's quality and reputation.
|
||||
|
||||
Currently there are several AOE teams that use visual regression tests with [Playwright](/tools/playwright/) in their daily operations, with more teams expected to adopt this practice in the future.
|
||||
Currently, several AOE teams use visual regression tests with [Playwright](/tools/playwright/) in their daily operations, with more teams expected to adopt this practice in the future.
|
||||
|
||||
In summary, visual regression tests are an invaluable tool for frontend developers. They streamline the development process, ensure visual consistency, and maintain high-quality user interfaces, making them an essential part of modern web development workflows.
|
||||
|
||||
Reference in New Issue
Block a user