I'd posit this is more knowing your user. Lots of photo editors/multimedia types use Macs, so it would only help GIMP if they offered Mac keybinds out of the box, or even mimicked the keybinds Adobe Photoshop has.
Loki by Grafana Labs is nice (https://grafana.com/oss/loki/). There was a time (3+ years ago) where the product was changing pretty rapidly and much of the documentation was on git, so we had a few headaches doing minor version bumps, but I believe its much more mature now.
- It is non-trivial to setup and operate. It requires properly configuring and orchestrating numerous components - distributor, ingestor, querier, query frontend, compactor, consul, ruler, memcache, index service, etc. - see https://grafana.com/docs/loki/latest/get-started/architectur...
- Its' configs tend to break with every new release, since some configs become obsolete and some configs change names and/or structure.
- It is very slow on "needle in the haystack" queries such as "search for logs containing some rarely seen trace_id", since it needs to read, unpack and scan all the logs at object storage. This may be also very expensive if the object storage service charges for read IO.
- It doesn't support log fields with big number of unique values (aka high-cardinality log fields). It you'll try storing logs with high-cardinality fields into Loki, then it will quickly explode with enormous RAM usage. Recent Loki releases provide half-baked solution for this problem - "structured metadata" ( https://grafana.com/docs/loki/latest/get-started/labels/stru... ), but it is still experimental and requires non-trivial configs (aka it doesn't work).
I am teaching myself some more full-stack dev and try out AI assisted coding, I decided to build Terminal Tinder, a way for your machine to learn what colorschemes you like, and maybe generate some novel ones for you.
Would love for people to try it out and hopefully find some fun or use out of it!
You solve a lot of the same problems that other tech companies solve, just with different constraints. An example I like to use is: "Facebook can afford to lose a 'like' on a post -- whether that is through data loss or just eventual consistency -- while we cannot afford to lose a penny (exaggerating a bit here) since there are people making live decisions on that penny"
Those sort of problems are more on the product side, along with the regular slew of product development tech problems. On the infrastructure/platform side (where I work) it is remarkably close to "regular tech". Same types of distributed systems problems, database issues, CI/CD pipelines, engineering efficiency, etc. The "new" part here is working with the finance specific areas such as physical data centers and networking to clients, or domain specific items such as data retention for compliance.
The firm I work at developed an internal library (open source soon hopefully!) that does all our templating in Python, example:
import os
"""
Imports redacted, but this imports our library
"""
NAME = "my_app"
PORT = 5000
DEPLOY_ENV = os.environ["DEPLOY_ENV"]
deploy_all(
create_stateful_service(
NAME, http_port=PORT, cpu=2000, memory=500
),
create_ingress(
NAME,
service_name=NAME,
service_port=PORT,
hostnames=["myapp.internal.com"],
),
)
In the background, this converts a bunch of objects to YAML, leveraging the fact that objects in Python are just dictionaries. It then takes these objects and sends them to the K8S API. Really improved our DevEx since you can do complex tasks like "define a deployment, deploy it, and then check server status" because it is all just Python at the end of the day.
I was tinkering with a similar approach to this, using Python objects to generate the YAML. I'm not working in it right now, but I'd love to see other tools use this approach.
It should be like that from the very beginning, any and all configuration management systems that chose YAML as base instead of DSL (even if DSL is just a subset of Python or Lua) have same problems.
reply