Our great sponsors
-
noyaml
A silly emotional rant about the state of devops tooling/the infrastructure sector in 2018. #noyaml.com
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
blooddy_crypto
ActionScript (AS3) library for processing binary data. This library contains MD5, SHA-1, SHA-2 ( SHA-224 и SHA-256 ), Base64, CRC32 algorithms, JSON encoder & decoder as well as PNG and JPEG encoders.
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
Joins can certainly work in a data format like YAML. For an example, see Honey SQL from the Clojure community [0] (though without something to contrast strings like Clojure's keywords, you miss out on the automatic parameterization).
You mentioned moving JOINs around, so I'll mention that if represented as structured data, you can move any of the top level components around, so you could more closely follow the "true order of SQL" [1]. For example, I would love to be able to put FROM before SELECT in all or almost all cases. There's also being able to share and add to something like a complicated WHERE clause, where essentially all programming languages have built-in facilities for robustly manipulating ordered and associative data compared to string manipulation, which is not well-suited for the task.
Now don't get me wrong, I don't particularly care for YAML (though it doesn't bother me that much), but as someone who's done their fair share of programmatic SQL creation and manipulation in strings, not having a native way to represent SQL as data is a mistake in my opinion.
0: https://github.com/seancorfield/honeysql#big-complicated-exa...
For anyone looking for such a script, there's some CLIs that make it easy. One is `yq -o props` [1], another way is to use `yq -j` or `yj` [2] to convert to JSON and pipe it to `gron` [3].
[1] https://github.com/mikefarah/yq
[2] https://github.com/sclevine/yj
[3] https://github.com/tomnomnom/gron
For anyone looking for such a script, there's some CLIs that make it easy. One is `yq -o props` [1], another way is to use `yq -j` or `yj` [2] to convert to JSON and pipe it to `gron` [3].
[1] https://github.com/mikefarah/yq
[2] https://github.com/sclevine/yj
[3] https://github.com/tomnomnom/gron
I think JSON5 is fairly close to this: https://json5.org
I reckon the only thing it's missing to be truly accessible to non-techies is that string values still need to be quoted, i.e. you can't have:
key: this is my value
(I'm definitely not saying it would be a good idea to allow quotes to be dropped, just that that's the only potential stumbling block I see for non-techies.)
Hjson is very similar to JSON5 but allows quotes to be dropped and can use newlines instead of commas. There are implementations for a lot of different languages, I myself contributed the C++ implementation. I wanted something smaller than Yaml but more lax than JSON, found Hjson to suit my needs perfectly.
https://hjson.github.io/
The more I look at it, the more I think that Deno is actually a perfect fit for infrastructure as code.
The first reaction I get is usually "What, JavaScript!?". Here is why its better than it looks like.
Deno easily runs TypeScript without a compile step. TypeScript is a very mature, developer friendly language that was designed to model the super complicated types often seen in JS. This includes unions and intersections which help you model complex rules between optional properties, as well as template literal types which can help you restrict string constants. As it so happens, those same types of objects are present in our configurations.
TypeScript is also flexible about how much you'd like to model. Do you want only properties with really nice autocomplete with docs from the language server? Sure we can do just that. Do you want to only allow strings that look like a time duration for that property? Can be done too with template literal types. You choose where to invest your energy.
Building abstractions on top of IaC is seen as painful and obscure. TypeScript has tools to help you avoid that, such as api-extractor: https://api-extractor.com/ - it can enforce that all your function abstractions are documented and it can generate that documentation for you.
The larger ecosystem also comes with a lot of ready-made codegen tools that can help, from small modules such as json-schema-to-typescript (https://www.npmjs.com/package/json-schema-to-typescript) to larger mature projects such as jsii and https://github.com/cdklabs/json2jsii . They can be used to build the tooling to import things like CRDs and other external schemas.
What about running arbitrary code, launching rockets, turing completness? This is where Deno comes in, with its permissions model (https://docs.deno.com/runtime/manual/basics/permissions). You can allow only a subset of commands (lets say, `helm` and `kustomize`, while you're migrating away from them), a subset of (writable) directories, accessible network hosts - or none at all.
What about the pains of managing JS modules? Deno lets you import files directly from URLs. It also allows you to set private tokens in env vars to ensure the imports succeed: https://docs.deno.com/runtime/manual/basics/modules/private - as a result, you can manage your IaC libraries the way that makes sense to you, without dealing with the unwieldy package managers of the node ecosystem.
https://github.com/wkhere/bcl
Will not immediately help for all of YAML usages, but at least for defining resources in a Terraform-like style. In fact, it's already it's already helpful as a replacement for HCL in one internal project, that was a final motivation to hack it.
In a bigger picture, I have no idea how to help with YAML omnipresence in Kubernetes. More than a half of my problems in a $daily_job is how crude is consolidating a final Helm chart from different sources. I am not saying that Helm would be inherently a bad tool or my company has chosen pretty bad way of using it - I guess everyone is doing their best considering the ciscumstances. But manipulating textual templates is just too error prone, and the detection of errors happens too late. I dare to say - Kubernetes would do much better with custom format based on a C-like syntax, instead if trying to prove how cool YAML is, especially when it isn't.
Have you seen ucl? https://github.com/vstakhov/libucl
It seems very similar.
I agree. I find working with templated YAML so cumbersome that I ended up creating a tool (Cels - https://github.com/pacha/cels) because of it. I like Jsonnet and Starlark but in practice I don’t usually need a new programming language for most use cases. Most of the time I just want to create a base document and apply patches to do modifications. That simplifies everything a lot.
I worked for a shop that made Flash games for Symbian phones (i.e. old Nokias). That's a lot more resource-constrained environment than any of iPhone or Android ever were. And it ran fine, if you knew what you were doing.
When Android just appeared on the market, I worked for a company that was making a video chat Facebook app. It was written in AS3 and one of the main features was to apply various effects to video. We tested it on Android, and it worked fine, even though that's a very memory and CPU intensive app.
Really, Flash player was not the problem. It couldn't go toe-to-toe with native code, but optimized AS3 code would beat unoptimized native code.
It was some form of code-golf to write Base64 encoding in AS3 and benchmark it. Usually comparing to the implementation in Flex. When Flash Alchemy came out, I wrote a version of Base64 encoding that beat it something like 100:1. A friend of mine who was known by his forum / Github user name "bloodhound" (here's some of his stuff: https://github.com/blooddy/blooddy_crypto/tree/master/src/by... ) wrote a bunch of encoding / decoding libraries for various formats (he also improved upon my Base64 code). And these were used all over the place for things like image uploads / image generation online. This stuff would beat similar Java libraries for example.
Not sure if you remember this, but at one point in the past Facebook had a Java applet that they used to manage image uploads to your "albums". Later they replaced it by Flash applet. It didn't work any worse that's for sure.
----
The performance problems were in Adobe AS3 code, not the player. Flex was a very inefficiently written framework. And so were AS components. But if you take AS3 3D engines, even those that were fully on CPU... you had plenty of proper 3D games. Eg. Tanki Online (a Russian game made with Alternativa3D Flash engine) was a huge hit. Even if the phone could handle a fraction of that, you'd still have plenty of room for less complex UI.