Earlier quoted context omitted.
> Technical writers: documentation by example is good only for newbies skimming through. People familiar with your product need a reference and exhaustive lists, not explanation for different fields spread over 10 tutorial pages. Focus on those that use the product day in and day out, not solely on the "onboarding" procedure. I agree. We all would benefit by giving more exposure to documentation frameworks such as ht…
Also https://docs.divio.com/documentation-system/
Take a look at Traefik, even if you don't use containers
211–220 of 266 posts
Re: Take a look at Traefik, even if you don't use containers
#212Earlier quoted context omitted.
Do not agree WRT ansible, been using it for well over 5 years and usually a google search points me right at the correct part of the documentation to answer my question. Ansible, the tool itself, can be a bit obtuse, largely IMHO because of the YAML source language, so some concepts are hard to translate into the tool, but the documentation has never bothered me. As far as "a lot of words written, can't find what you…
Alright, please link me to an exhaustive list of Jinja filters supported by Ansible out of the box. I'll wait. What you are given is https://docs.ansible.com/ansible/latest/playbook_guide/playb... and you need basically to read/scan each example until you find what you need [1]. Do you call that good , especially when these are basically the only way of doing anything a little complex? That's a sure way of killing my…
That said, when I have a question about jinja2, I find that the jinja2 docs are better than the ansible docs.
Re: Take a look at Traefik, even if you don't use containers
#213Earlier quoted context omitted.
My primary use case for LLMs so far has indeed been to avoid terrible technical documentation.
I'm on the lookout for an LLM that is relatively small and focused on technical documentation. I don't need it to write prose or haiku, just answer my questions based on documentation
Re: Take a look at Traefik, even if you don't use containers
#214Traefik is pretty cool, but suffers from the same, terrible problem of Ansible: there is a lot of documentation, and a lot of words written, yet you can never find anything you need. I have used it since v1 and I routinely get lost in their docs, and get immensely frustrated. I have been using Caddy for smaller projects simply because its documentation is not as terrible (though not great by any stretch) Technical wr…
- Having documentation split between v1 and v2, that is similar yet different enough to yield half-baked configurations before you realize what you did wrong. The website itself provides the barest of subtle changes to distinguish the two. Edit: I learned all this prior to v3.
- Supporting multiple config formats (TOML and YAML) which makes it that much harder to hunt down relevant forum posts for support. That wouldn't be a huge problem if it weren't for things that you need that aren't in the documentation (above)
- Multiple configuration _modes_. You can set options on the CLI, or in config files, and they are not 100% reflected between the two; some things must be in config files no matter what. Config files themselves are split between "dynamic" and "static" configs, and you must place the correct options in the right file.
- The one thing that Traefik does well is routing traffic to/from containers. Container labels are used to drive this. How to map those label namespaces to various internal and user provided aspects of Traefik is unclear in the docs, at best.
- Traefik exposes a dashboard web GUI by default. Yet much of the useful diagnostic and troubleshooting information is only found in the container logs.
Retiring v1 completely, picking a single configuration language/mode, and providing a rich library of example docker-compose configs, would go a very long way to securing this project's future.
Re: Take a look at Traefik, even if you don't use containers
#215Traefik is pretty cool, but suffers from the same, terrible problem of Ansible: there is a lot of documentation, and a lot of words written, yet you can never find anything you need. I have used it since v1 and I routinely get lost in their docs, and get immensely frustrated. I have been using Caddy for smaller projects simply because its documentation is not as terrible (though not great by any stretch) Technical wr…
Re: Take a look at Traefik, even if you don't use containers
#216We've been using Traefik in prod for 2 years. While I used NGINX in the past, I decided to migrate to Traefik mainly because of the automatic let's encrypt integration. I am sorry for that decision. Traefik's documentation does not make sense to me or my team. It is finicky and misbehaves without proper logging. As an example - when I want to recreate the certificates - it fails sporadically leaving prod down for an…
I’ve always just used go’s built in reverse proxy if I need an API gateway. You can adapt it to meet any specific need, easily find libraries to do common tasks (CORS, rate limiting, retries, etc), and the best part: no configuration language. You just write go.
My reverse proxy offered a service mesh, live config reloads, managed TLS certs, and automatically rerouted traffic around down services. The whole thing was a few hundred LOC anyone could understand in its entirety. It ran in production for years unchanged and never caused an outage.
Re: Take a look at Traefik, even if you don't use containers
#217Traefik is pretty cool, but suffers from the same, terrible problem of Ansible: there is a lot of documentation, and a lot of words written, yet you can never find anything you need. I have used it since v1 and I routinely get lost in their docs, and get immensely frustrated. I have been using Caddy for smaller projects simply because its documentation is not as terrible (though not great by any stretch) Technical wr…
One of the problems that the yaml interpreter class of languages, or whatever you'd call them, suffer from is the fact that yaml itself is a language and tends to be more or less undocumented in the interpreter docs. It's sort of assumed that you are going to do extremely simple tasks on very flat data structures. That doesn't tend to be the reality that most of us live in. And to really get the most out of these lan…
Re: Take a look at Traefik, even if you don't use containers
#218Traefik is pretty cool, but suffers from the same, terrible problem of Ansible: there is a lot of documentation, and a lot of words written, yet you can never find anything you need. I have used it since v1 and I routinely get lost in their docs, and get immensely frustrated. I have been using Caddy for smaller projects simply because its documentation is not as terrible (though not great by any stretch) Technical wr…
Eg: https://doc.traefik.io/traefik/routing/services/
If you visit that page in your desktop browser you'll get less words per column then seeing this on the iPad (works even in dev tools window). Mind blowing.
Re: Take a look at Traefik, even if you don't use containers
#219Traefik is pretty cool, but suffers from the same, terrible problem of Ansible: there is a lot of documentation, and a lot of words written, yet you can never find anything you need. I have used it since v1 and I routinely get lost in their docs, and get immensely frustrated. I have been using Caddy for smaller projects simply because its documentation is not as terrible (though not great by any stretch) Technical wr…
I share the same sentiments. I dread having to go through Ansible docs because it's so densely packed. Meanwhile Caddy's docs feel too sparse, and too many spread out tutorials. The reference isn't well thought out either imo.
Re: Take a look at Traefik, even if you don't use containers
#220Traefik is pretty cool, but suffers from the same, terrible problem of Ansible: there is a lot of documentation, and a lot of words written, yet you can never find anything you need. I have used it since v1 and I routinely get lost in their docs, and get immensely frustrated. I have been using Caddy for smaller projects simply because its documentation is not as terrible (though not great by any stretch) Technical wr…
Possibly unpopular opinions to follow. This is made even worse by: - Having documentation split between v1 and v2, that is similar yet different enough to yield half-baked configurations before you realize what you did wrong. The website itself provides the barest of subtle changes to distinguish the two. Edit: I learned all this prior to v3. - Supporting multiple config formats (TOML and YAML) which makes it that mu…