-
Ansible
Ansible is a radically simple IT automation platform that makes your applications and systems easier to deploy and maintain. Automate everything from code deployment to network configuration to cloud management, in a language that approaches plain English, using SSH, with no agents to install on remote systems. https://docs.ansible.com.
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
core
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web. (by vuejs)
-
> I've encountered a code written in the 12factor style of using environment variables for configuration, and in that particular case there was no validation nor documentation of the configuration options. Is this typical?
This just feels like bad development and isn't unlike being given a random .properties/.ini file with no explanations of what the values mean. Sounds like someone didn't do their job, or the processes to encourage (require) them to do so weren't in place.
> For onboarding new members, I would have thought it preferable to have a JSON configuration, where both documentation and validation of configuration options are provided by a JSON Schema file.
You know, this can work, but then you need your applications to be able to read that file and feeding it in through your container management solution (which many use for a variety of reasons) wouldn't be as easy. Even without containers, you'd still need to look out so you don't end up with 20 JSON files all of which might need to be changed for a new environment.
Honestly, something like JSON5 https://json5.org/ was pretty cool because of added comments, but otherwise JSON is a bit cumbersome to use. That said, some web servers like Caddy have gone for accepting JSON configuration as well, which lends itself nicely to automation, so it's still a valid approach: https://caddyserver.com/docs/json/
-
> I've encountered a code written in the 12factor style of using environment variables for configuration, and in that particular case there was no validation nor documentation of the configuration options. Is this typical?
I don't know about typical, it comes down to how your team values the code they write.
You can have a .env.example file commit to version control which explains every option in as much or as little detail as you'd like. For my own personal projects, I tend to document this file like this https://github.com/nickjj/docker-flask-example/blob/main/.en....
-
> Also everything was new at one time.
Hah, this is a good point, but in my eyes lots of things that were new... never really grew up and were just deprecated and died.
For example, if someone based their setup on IronFunctions, they might have run into a bit of a painful situation, seeing as the project has been largely abandoned: https://github.com/iron-io/functions
Same for a database solution like Clusterpoint, the support for which just ended and you were left to migrate away to something else: https://github.com/clusterpoint
Ergo, I'd say that it's good for others to suffer the consequences of being trend setters and making wild bets on new and risky products and to just reap the benefits of their efforts later yourself, when things are safer. If a project has survived for a reasonably long time, it's a good indicator that it'll probably keep surviving in the future as well (there was a name for this, sadly can't recall what that was).
-
architecture_decision_record
Architecture decision record (ADR) examples for software planning, IT leadership, and template documentation
The article mentions Architectural Design Records (ADR) which can be included as a folder in the git repo for the project, as a means of documenting the historical decisions that led to the project's current structure. Some of that seems overly complex or formalized (i.e. reinventing UML and all the problems that came with it), but having that history in some kind of constant format would likely help overcome any novelty issues and help people grasp what's going on. The simplest format discussed seems the best for most cases:
https://github.com/joelparkerhenderson/architecture-decision...
-
The article mentions Architectural Design Records (ADR) which can be included as a folder in the git repo for the project, as a means of documenting the historical decisions that led to the project's current structure. Some of that seems overly complex or formalized (i.e. reinventing UML and all the problems that came with it), but having that history in some kind of constant format would likely help overcome any novelty issues and help people grasp what's going on. The simplest format discussed seems the best for most cases:
https://github.com/joelparkerhenderson/architecture-decision...
-
-
-
Joran from TigerBeetle here.
On the contrary, Coil's Interledger [1] project is designing for TigerBeetle, and TigerBeetle will be the core ledger database for Rafiki [2], the open implementation of Interledger.
[1] https://interledger.org
[2] https://github.com/interledger/rafiki
-
rafiki
An open-source, comprehensive Interledger service for wallet providers, enabling them to provide Interledger functionality to their users.
Joran from TigerBeetle here.
On the contrary, Coil's Interledger [1] project is designing for TigerBeetle, and TigerBeetle will be the core ledger database for Rafiki [2], the open implementation of Interledger.
[1] https://interledger.org
[2] https://github.com/interledger/rafiki
Related posts
-
Flask Application Load Balancing using Docker Compose and Nginx
-
Create a local Appwrite instance in 3 steps
-
Deploy Appwrite to AWS using Terraform and Ansible
-
Which Docker variant am I using and where is the daemon running?
-
Short: User Data file for Ubuntu based AWS ec2 instance with docker and docker compose.