From the example provided I can see that the KCL K8s sample had 18 lines whereas the generated YAML file had 21 lines.
I'm sort of missing the point here as to how KCL is helping here.
The core features of KCL are its modeling and constraint capabilities, and the basic functions of KCL revolve around the two core features. In addition, KCL follows the user-centric configuration concept to design its basic functions, which can be understood from two aspects:
Domain model-centric configuration view: With the rich features of KCL language and KCL OpenAPI tools, we can directly integrate a wide range of well-designed models in the community into KCL (such as the K8s resource model). We can also design and implement our own KCL models or libraries according to different scenarios, forming a complete set of domain models for other configuration end users to use.
End user-centric configuration view: With KCL's code encapsulation, abstraction and reuse capabilities, the model architecture can be further abstracted and simplified (for example, the K8s resource model is abstracted into an application-centered server model) to minimize the end user configuration input*, simplify the user's configuration interface, and facilitate manual or automatic API modification.
No matter what configuration view is centered on, for configuration code, there are requirements for configuration data constraints, such as type constraints, required/optional constraints on configuration attributes, range constraints, and immutability constraints. This is also one of the core issues KCL is committed to solving.
> What was even more surprising, to me, is that Mercedes had this amazing nice center console unit to control things with your arm in a rested position. They removed that piece of brilliance!
Mazda also has this beautiful dial-joystick which we can operate in a rested position. It is so intuitive that I stopped using the touchscreen console itself.
On the other hand even when we operate using a dial and buttons we take our eyes for an instant to look at the screen to check the changes. Now imagine looking away at a touchscreen just to see what operation to perform etc. This is a major distraction.
Mazda has actually been going in the opposite direction by removing their touchscreens; 2016 Mazdas came with touchscreens, but the newest models go without. Personally, owning a 2016 Mazda I never actually used the touch screen once, due to as you note, the great dial interface.
BMW at one point had (and may still have) a dial joystick, but I found it really unintuitive. Maybe it was poor software design, but it was never clear to me when I needed to turn the dial vs move the stick to navigate menus. Did you find it easier to use the control in the Mazda? Was the UX better?
This was around 2009. A colleague in the team was checking a high cpu alert on a payment system cluster. He found some PIDs that were consuming high cpu and asked someone in the team on how to get more details. He was asked to use fuser to check.
He did use the fuser but it was fuser -cuk. The -k for killing the process created quite a mess.
This is indeed surprising.
Any time we have slowness issues the usual recommendation would be to throw resources at the problem; increase cpu, add more memory et al. We used to lament that we should spend time debugging the problem and fix the actual issue. We then used to say that probably at places like AWS and the other biggies they'd be following some excellent best practices and we should also strive to reach that level of excellence.
> We had a lot of little scripts here and there which would solve extremely specific situations but no focus was ever put on in building a general framework or trying to reduce the ticket count.
wow, honestly this is surprising. For me as an end customer I was always impressed with the way the services are engineered. Kudos to people like you for making this happen. But then I was also under the impression that AWS has very good best practices to take care of repeating issues.
Wouldn't interim patch-ups cause stability issues in the long term?
> Wouldn't interim patch-ups cause stability issues in the long term?
No matter what people tell you or put on their marketing blog, it feels like this is the state of play for 99% of software teams. The only time it doesn't end up like this is when you leave time up front to pay down technical debt (like Intel's tick-tock model), and almost no one does that.
