3 ms·

It sounds like you should store your configuration in some sort of KVS (Consul or etcd) or database (SQL) with a frontend rather than flat text files. There exi

by 3np 6y ago

It sounds like you should store your configuration in some sort of KVS (Consul or etcd) or database (SQL) with a frontend rather than flat text files. There exists tooling for all of that. If you're really going for Excel, why not even make a plugin that hooks in to it. Personally I'd find that horrible, but if it works for you and your team has no objections, why not. I'd wager that the major reason no one has taken it that far is that your preferences are very rare. But who knows, if you build it and make it available maybe others will find it useful too. You're probably getting downvoted because unless I'm misinterpreting your previous comments, you're mixing up abstraction levels and concerns when you're talking about types. Personally I think yaml is a terrible and confusing format in general (yes I do understand it quite well), I see your point with JSON, but I wouldn't personally say it's a fundamental issue the way you're describing it.

jiggawatts 6y ago
There is an awful lot of middle ground between the scale where it's faster to just click through a GUI, and the scale where a database engine makes sense. Sure, if I were provisioning 10K+ more-or-less-but-not-entirely-the same objects, I'd be reaching for a SQL database engine of some sort. For about 10 things I'd just grit my teeth and click through a GUI manually. In between 10 items and 10K is where things get interesting. Inefficient tools can waste more time than they save. Full-on programming languages are right out. You have to consider dealing with people who aren't programmers. People that aren't DBAs. This in-between-land of, say, 50-5000 instances is where configuration data files live. It's where Excel works well enough at the moment, but I feel that something better is just waiting to be invented.
- 3np 6y ago
  To each their own, I guess. I’m guessing many people who work with the kind of environments you’re describing are like me in that I prefer everything as pure text and pipes (*sh/vim/sed/grep/awk/jq/tr/cut/xargs/curl/etc). It definitely is a longer learning curve but at some point everything becomes the same whereas with GUIs there’s a new flow for every system and there’s a bottleneck in how much you can manage manually and visually. There’s no going back to GUIs when the shell and keyboard become and extension of your mind. But I think you have a point in that there’s an big user base of somewhat-power-users that prefer visual interfaces and that there’s a better middle ground to be found. The biggest hurdle I see is that tools like that easily become outdated, have selective platform support, aren’t as extendable and customizable, etc. it’s a vastly bigger undertaking to make something that can work everywhere with everything in the way text UIs can.
- GoblinSlayer 6y ago
  There's https://www.gnu.org/software/recutils/ https://www.gnu.org/software/recutils/ aimed for that scale.
- cmwelsh 6y ago
  From an enterprise background, I’ve seen it go wrong so many times. It’s worth it to script even 1 table change or 1 column schema definition. It’s kind of a “trust me” thing, but seriously, you get used to it. Your future “you”s will thank you.

by 3np 6y ago

jiggawatts 6y ago

There is an awful lot of middle ground between the scale where it's faster to just click through a GUI, and the scale where a database engine makes sense. Sure, if I were provisioning 10K+ more-or-less-but-not-entirely-the same objects, I'd be reaching for a SQL database engine of some sort. For about 10 things I'd just grit my teeth and click through a GUI manually. In between 10 items and 10K is where things get interesting. Inefficient tools can waste more time than they save. Full-on programming languages are right out. You have to consider dealing with people who aren't programmers. People that aren't DBAs. This in-between-land of, say, 50-5000 instances is where configuration data files live. It's where Excel works well enough at the moment, but I feel that something better is just waiting to be invented.

3np 6y ago
To each their own, I guess. I’m guessing many people who work with the kind of environments you’re describing are like me in that I prefer everything as pure text and pipes (*sh/vim/sed/grep/awk/jq/tr/cut/xargs/curl/etc). It definitely is a longer learning curve but at some point everything becomes the same whereas with GUIs there’s a new flow for every system and there’s a bottleneck in how much you can manage manually and visually. There’s no going back to GUIs when the shell and keyboard become and extension of your mind. But I think you have a point in that there’s an big user base of somewhat-power-users that prefer visual interfaces and that there’s a better middle ground to be found. The biggest hurdle I see is that tools like that easily become outdated, have selective platform support, aren’t as extendable and customizable, etc. it’s a vastly bigger undertaking to make something that can work everywhere with everything in the way text UIs can.
GoblinSlayer 6y ago
There's https://www.gnu.org/software/recutils/ https://www.gnu.org/software/recutils/ aimed for that scale.
cmwelsh 6y ago
From an enterprise background, I’ve seen it go wrong so many times. It’s worth it to script even 1 table change or 1 column schema definition. It’s kind of a “trust me” thing, but seriously, you get used to it. Your future “you”s will thank you.