|
ctps: wtf are these js devs doing with environment variables? wtf is this poo poo? Instead of pulling these values from, ya know, the ENVIRONMENT there's whole layers of plugins at every level of the js/npm/webpack shitshow to handle putting that poo poo on the filesystem and reading them into your react app or whatever. I want to set up all the environment vars in docker-compose and in our CI/CD system but it's not working because poo poo's loving hard-coded in a .env or config file or something. I wanna beat the frontend guy with a trout but I know it's not really his fault this is just js dev. edit: hahahahaa this is the saddest stupidest thing I've read about js https://www.npmjs.com/package/dotenv quote:Dotenv is a zero-dependency module that loads environment variables from a .env file into process.env. Storing configuration in the environment separate from code is based on The Twelve-Factor App methodology. Oh wow guys we'll just hard-code these values in a different file and we'll be 12-factor!!! A file is just part of the environment, after all, like birds and trees and beers or whatever. Finster Dexter fucked around with this message at 21:00 on Aug 2, 2018 |
#
?
Aug 2, 2018 20:43
|
|
|
|
| # ? Apr 25, 2024 15:18 |
|
|
i think you're supposed to use .env for defaults and dev, and then use actual environment variables non locally fundamentally that's not horrible, idk what your people are doin direnv is better tho
|
|
#
?
Aug 2, 2018 21:07
|
|
|
Mao Zedong Thot posted:i think you're supposed to use .env for defaults and dev, and then use actual environment variables non locally The current frontend guy's readme says: Put necessary env vars in the appropriate `.env.*` file. Any local variables you don't want committed go in `.env.local` These .env are absolutely intended to go to source control and be used for prod builds. But near as I can tell from the source code, everything is wired up with dotenv, so setting environment variables on my local env or even in a docker container are just flat ignored and it complains about not having a .env value for that variable. This seems so awful. And I've read 6 articles about webpack now that all say that is how you should do it: "gently caress env, put everything in .env files or pass them as arguments to your webpack calls in package.json"
|
|
#
?
Aug 2, 2018 21:15
|
|
|
most javascript utilities are written by javascript developers and consequently they are laughably bad. (mlmp)
|
|
#
?
Aug 2, 2018 21:19
|
|
|
vs2017 wanted me to install node externally to build a js client project so I just decided not to do that.
|
|
#
?
Aug 2, 2018 21:20
|
|
|
Shaggar posted:vs2017 wanted me to install node externally to build a js client project so I just decided not to do that. good decision
|
|
#
?
Aug 2, 2018 21:21
|
|
|
cinci zoo sniper posted:it worked the other way around and now everyone’s attention is squarely on them, since they themselves admitted the bullshit trivial to verify well, it would have been a smart play if they didn't gently caress it up!
|
|
#
?
Aug 2, 2018 21:23
|
|
|
storing environment-specific configuration in the artifact is not a fuckup committed solely by js devs, unfortunately ask me about: 1) having to do an emergency hotfix in code to update a database endpoint 2) repackaging jars at runtime with environment specific property files
|
|
#
?
Aug 2, 2018 21:38
|
|
|
our gateway/routing config is compiled directly into artifact which is just great and has never caused problems
|
|
#
?
Aug 2, 2018 21:49
|
|
|
all config management sucks. there are no solutions
|
|
#
?
Aug 2, 2018 22:25
|
|
|
redleader posted:all config management sucks. there are no solutions
|
|
#
?
Aug 2, 2018 22:27
|
|
|
http://mikehadlow.blogspot.com/2012/05/configuration-complexity-clock.html
|
|
#
?
Aug 2, 2018 22:32
|
|
|
Finster Dexter posted:The current frontend guy's readme says: Put necessary env vars in the appropriate `.env.*` file. Any local variables you don't want committed go in `.env.local` your dev is an idiot. the first faq entry on dotenv package: quote:Should I commit my .env file?
|
|
#
?
Aug 2, 2018 22:44
|
|
|
we use dotenv and it works fine if you set a variable in the environment, it supersedes the one in .env. as is documented in the package. fire your dev
|
|
#
?
Aug 2, 2018 22:45
|
|
|
into the sun (along with javscsript)
|
|
#
?
Aug 2, 2018 22:46
|
|
|
we wrote a property management system that works really well and is a really great concept but is garbage cans full of burning trash under the hood still proud of it tho
|
|
#
?
Aug 2, 2018 23:06
|
|
|
Blinkz0rz posted:we wrote a property management system that works really well and is a really great concept but is garbage cans full of burning trash under the hood out of sight out of mind
|
|
#
?
Aug 2, 2018 23:16
|
|
|
it's the linchpin of services we spend $18m/year running on aws and it's literally loving nodejs but it works flawlessly
|
|
#
?
Aug 2, 2018 23:42
|
|
|
I was kind of amazed to hear that most of our teams were manually janitoring config or doing 'oh poo poo make sure you copy the right file to prod' type stuff because all our stuff used nice neat config files that had a section per environment and a host-env mapping so your app would always read the right properties. turns out that's all off the back of an internal dll some dude wrote in 2004 that we've built off ever since, I just thought it was normal because it was all I'd ever seen  latest versions will pull config details from a remote service that authenticates the host and calling process so you don't have any details in plaintext config and can't accidentally connect non prod to prod. it owns tbh
|
|
#
?
Aug 3, 2018 00:20
|
|
|
Powerful Two-Hander posted:I was kind of amazed to hear that most of our teams were manually janitoring config or doing 'oh poo poo make sure you copy the right file to prod' type stuff because all our stuff used nice neat config files that had a section per environment and a host-env mapping so your app would always read the right properties. turns out that's all off the back of an internal dll some dude wrote in 2004 that we've built off ever since, I just thought it was normal because it was all I'd ever seen Yeah that poo poo owns, I only got to see that actually work correctly while I was at Amazon. It went to so far as to define which other services could call your teams services, and let you go down to the granularity of each HTTP verb and it's endpoint.
|
|
#
?
Aug 3, 2018 00:23
|
|
|
a good article quote:What we need is a business rules engine quote:Initially there was hope that non-technical business users would be able to use the GUI to configure the application this is the programming equivalent of original sin
|
|
#
?
Aug 3, 2018 06:29
|
|
|
Yeah that's a good read thanks Bloody
|
|
#
?
Aug 3, 2018 06:37
|
|
|
this protocol buffer thing looks interesting. any major problems with it?
|
|
#
?
Aug 3, 2018 07:49
|
|
|
cinci zoo sniper posted:this protocol buffer thing looks interesting. any major problems with it? People do dumb things with default values, also try to use them for more than just on the wire messages
|
|
#
?
Aug 3, 2018 07:54
|
|
|
it robs you of the chance to roll your own serialization format + library. despite what some might say, this is a negative
|
|
#
?
Aug 3, 2018 07:55
|
|
|
Basically it's good for what it's designed for, just be really firm with idiots wanting to get creative with use cases.
|
|
#
?
Aug 3, 2018 07:58
|
|
|
it's really tempting to want to use them for stuff like immutable value types, especially if they happen to match your wire types anyway. (what, are you going to write them once as a proto, a second time as an AutoValue, plus write converters?) but you'll inevitably run into an immutable value type that can't be a proto, and now you have two totally incompatible ways of doing immutable value types in your codebase. not sure what the best solution is tbh
|
|
#
?
Aug 3, 2018 08:04
|
|
|
jit bull transpile posted:People do dumb things with default values, also try to use them for more than just on the wire messages so would serialising it to file be a good or dumb choice, as a document store? your answer provides me with a suspicion that it’s mean for internal message transfer strictly
|
|
#
?
Aug 3, 2018 08:06
|
|
|
cinci zoo sniper posted:so would serialising it to file be a good or dumb choice, as a document store? your answer provides me with a suspicion that it’s mean for internal message transfer strictly Let me just say that I have seen attempts to store databases of protobufs and they were painful to use.
|
|
#
?
Aug 3, 2018 08:26
|
|
|
Sapozhnik posted:a good article extremely true see also "we'll just write our own document storage system, it's easy" and anything involving goddamn workflows
|
|
#
?
Aug 3, 2018 08:55
|
|
|
Powerful Two-Hander posted:extremely true about this: what is a good system for version control and storage of documents?
|
|
#
?
Aug 3, 2018 08:58
|
|
|
Storing serialised protobufs is just fine. What you'll want to be careful with is if you want to actually query your data (e.g. "look up all the things where foo = 12") - at that point you want a database, not just a bunch of files. e: talking to cinci
|
|
#
?
Aug 3, 2018 08:59
|
|
|
Boiled Water posted:about this: xml i feel, you can version files and their schemes nicely e: brainfarted about format, not system. system is a good question. cinci zoo sniper fucked around with this message at 09:09 on Aug 3, 2018 |
|
#
?
Aug 3, 2018 09:07
|
|
|
jit bull transpile posted:Let me just say that I have seen attempts to store databases of protobufs and they were painful to use. Jabor posted:Storing serialised protobufs is just fine. hm, makes sense
|
|
#
?
Aug 3, 2018 09:08
|
|
|
cinci zoo sniper posted:xml i feel, you can version files and their schemes nicely no like marketing has a bunch of word and pdf files in different version how do you keep track of them in a way that's not terrible?
|
|
#
?
Aug 3, 2018 09:10
|
|
|
make them write in LaTeX and use git?
|
|
#
?
Aug 3, 2018 09:33
|
|
|
eschaton posted:make them write in LaTeX and use git? lol
|
|
#
?
Aug 3, 2018 09:47
|
|
|
Boiled Water posted:no like marketing has a bunch of word and pdf files in different version how do you keep track of them in a way that's not terrible? please see the thread title
|
|
#
?
Aug 3, 2018 10:11
|
|
|
Boiled Water posted:about this: they're all bad tbh but if ones I've used in descending order of badness: * something involving blobs in mongo (lol) * sharepoint (arguably worse than blobs in mongo because users can and will gently caress everything up whilst thinking its great and then make you fix it) * file share where everyone has root <--technically the worst but OK if you can avoid any responsibility for what happens when someone deletes the entire store * documentum used directly via its godawful interface * file share with granular permissions * documentum buffered via applications that use webservices to do presentation edit: file shares don't do versions obviously, but if that's all you've got you'll just have people up loading final_copy.1.final.this.one.docx to it anyway and even if they had versioning they probably would use it and would carry on naming everything like that because they're dumb and don't want to change the way they work. at like any point doing anything with documents someone will say "but I know where the documents are, why should I have to change" Powerful Two-Hander fucked around with this message at 10:58 on Aug 3, 2018 |
|
#
?
Aug 3, 2018 10:53
|
|
|
|
| # ? Apr 25, 2024 15:18 |
|
|
https://cloud.google.com/knative/ Looks pretty sweet, server less functions but 1) run via docker so not limited to js and 2) runs in your own cluster so you don't pay per request or anything. im for sure going to find some way to squeeze it into my current jerk-off hobby project
|
|
#
?
Aug 3, 2018 12:59
|
|
