161–170 of 351 posts
Earlier quoted context omitted.
If you think the whitespace is bad, just wait till you see the implicit casting: https://hitchdev.com/strictyaml/why/implicit-typing-removed/
God, I hate programming some times.
Earlier quoted context omitted.
Also see `webpack` as a successful example of code-as-configuration in the wild.
Not sure if it was successful when people call it a hell to maintain and newer simpler alternatives like Parcel is gaining popularity.
That being said, the concept of defining a function in, essentially, a config file seems like a step in the right direction. I don't think I'd trust that functionality outside of builds or infra-as-code, though.
Helm reminds me of the 90s level of webtech. I.e. php cgi files mixing html, logic and includes.
I believe people are back to doing that for web stuff. Open up any modern web stuff and it looks like "const widget = foo ". Not making this up! https://reactjs.org/docs/introducing-jsx.html
- (Templated HTML)
- (JS OR Typescript)
- (CSS OR SASS/etc)
I know I'm in a minority, but I really dislike YAML... I recently did a lot of Ansible and boy, at the beginning, I was just struggling a lot. Syntactic whitespace kills me. I don't like it in Python either, but for some reason, when I write Python, it's a lot easier. Maybe YAML is just a bit more complex (and Python has better IDE support..?)
I find YAML to be almost unusable. IMO it's just not intuitive. If I get to choose a format for my config files I would only use TOML, it's just better (again IMO).
Also, I'm guessing I'm in a tiny minority who loves YAML but hates Python's semantic indentation...
Earlier quoted context omitted.
No comments, constant need to quote every string, inane comma requirements, no multiline string, little typing support.
Many language require strings to be quoted, and calling the comma requirements inane is an opinion, not an objective fact. You're not saying anything about the readability of one versus another, you're just listing gripes you have about JSON.
His main argument is that you need to template differently for different environments (dev/stage/prod) and cloud regions (us-west/us-east/emea/apac). This is actually a solved problem, and you shouldn't be doing it in your YAML/JSON templates. You should be using an external parameter store to do this, and using a single template for everything. See https://aws.amazon.com/blogs/compute/query-for-the-latest-am... This…
Based on the appearance of Helm, this is probably referring to Kubernetes, which really does have per-environment things that can't be represented in any form other than namespaces. For example, you have an app running (that's a deployment in k8speak). You want network traffic to get to this app, so you set up a load balancer. The load balancer config needs to know the name of your app (or more precisely, a selector…
Parameters: AMI: Type: AWS::SSM::Parameter::Value Default: /aws/service/ecs/optimized-ami/amazon-linux/recommended/image_id
That gives you the latest, fully patched base OS image no matter which of 19 regions you launch it in.
Even hardcoding that in a K/V store is going to get outdated unless you manually update it. Parameters like this are great because you can simply write your code once and never have to update unless you're adding new functionality. All base parameters and external systems (APIs, etc) are parameterized and never need to get updated, except by your SaaS partners that update them for you.
His main argument is that you need to template differently for different environments (dev/stage/prod) and cloud regions (us-west/us-east/emea/apac). This is actually a solved problem, and you shouldn't be doing it in your YAML/JSON templates. You should be using an external parameter store to do this, and using a single template for everything. See https://aws.amazon.com/blogs/compute/query-for-the-latest-am... This…
> It's a solved problem For who, exactly?
I think they are missing the real selling point of JSON. It's basically interoperable with JavaScript objects. That means you write it, send it, store it, operate on it, etc. with little or no modification. The author says "converting between the two is trivial" which may be true, but the developer overhead is less trivial. And it will always be JSON in the client - JS doesn't support YAML objects.
Earlier quoted context omitted.
God, I hate programming some times.
Stick with a config format that isn't overengineered and too clever for its own good, like... anything but YAML?
We get better and better tools each year but it still seems unavoidable. We're ultimately building incredibly complex systems with each layer using multiple development approaches, style choices, language choices, degrees of quality/time investment by the creator, etc.
TLDR: you can't help bang your head against the wall in any real-world day-to-day programming
Helm reminds me of the 90s level of webtech. I.e. php cgi files mixing html, logic and includes.
I believe people are back to doing that for web stuff. Open up any modern web stuff and it looks like "const widget = foo ". Not making this up! https://reactjs.org/docs/introducing-jsx.html