I'm having a package.json file with a custom section. So, basically, something such as:
{
"name": "foo",
"version": "0.0.1",
"dependencies": { ... },
"mySection": { ... }
}
Accessing this custom section is quite easy: Simply require the package.json file and access the mySection property. That's it.
Now, I would like to have some validation on this: Check that some mandatory keys are actually there, provide default values to missing values that are defined as optional, check types, ...
What's the easiest way to achieve this?
PS: I know that, e.g. for validating, I could use a JSON schema. This would solve my problem at least partially, but JSON schemas is not really ... well, easily usable. For many cases, it's IMHO a little bit over-sized.
I reckon the easiest way would be to just write a small validation function that would assign defaults and check for missing properties. I would prefer this way instead of adding a dependency of any sort for just a simple one off task (if that is a case)
Related
My swagger.json on the backend lists two different paths for each operation like so:
"paths": {
"/api/Clients": {
...
"/api/Clients({key}: {"
...
When I try to edit the OpenAPI markup directly and add new path, it says duplicate path.
I also tried adding {key} as an optional parameter to the existing Clients opeartion, but it didnt like being marked optional, but having the value come from the path. From this post it looks like its possible, but I cannot figure out how.
Based on the post that you shared, the recommendation was to use a path like /api/Clients/{key} and then rewrite the URI as required.
To be exact to the recommendation, you could go for /api/{entity}/{key} itself, catching all entities.
In Airflow, we've created several DAGS. Some of which share common properties, for example the directory to read files from. Currently, these properties are listed as a property in each separate DAG, which will obviously become problematic in the future. Say if the directory name was to change, we'd have to go into each DAG and update this piece of code (possibly even missing one).
I was looking into creating some sort of a configuration file, which can be parsed into Airflow and used by the various DAGS when a certain property is required, but I cannot seem to find any sort of documentation or guide on how to do this. Most I could find was the documentation on setting up Connection ID's, but that does not meet my use case.
The question to my post, is it possible to do the above scenario and how?
Thanks in advance.
There are a few ways you can accomplish this based on your setup:
You can use a DagFactory type approach where you have a function generate DAGs. You can find an example of what that looks like here
You can store a JSON config as an Airflow Variable, and parse through that to generate a DAG. You can store something like this in a Admin -> Variables:
[
{
"table": "users",
"schema": "app_one",
"s3_bucket": "etl_bucket",
"s3_key": "app_one_users",
"redshift_conn_id": "postgres_default"
},
{
"table": "users",
"schema": "app_two",
"s3_bucket": "etl_bucket",
"s3_key": "app_two_users",
"redshift_conn_id": "postgres_default"
}
]
Your DAG could get generated as:
sync_config = json.loads(Variable.get("sync_config"))
with dag:
start = DummyOperator(task_id='begin_dag')
for table in sync_config:
d1 = RedshiftToS3Transfer(
task_id='{0}'.format(table['s3_key']),
table=table['table'],
schema=table['schema'],
s3_bucket=table['s3_bucket'],
s3_key=table['s3_key'],
redshift_conn_id=table['redshift_conn_id']
)
start >> d1
Similarly, you can just store that config as a local file and open it as you would any other file. Keep in mind the best answer to this will depend on your infrastructure and use case.
In kitchen.yml, I would like to have an expression in the attributes: part. However it seems it is just a static file with literal values.
Is it somehow possible to have the values in attributes: evaluated?
The reason for that need is that I have some node.defaults in defaults.rb, and some of them are URLs at the same host, say, http:foo.org/service. And in the kitchen.yml I want to parametrize the host. So I would have:
...
attributes: { serviceX_baseURL: "http://bar.org/service" }
I want the override to happen with kitchen_*.yml override and not attributes/*.rb (that would be easier) because the override happens later in the process, after the main kitchen.yml file is already generated.
Any practical solutions for that are welcome.
You can use Erb formatting in the .kitchen.yml for some very simplistic templating, but you didn't really give a concrete example. Chances are you should not do this, generally parameterizing both the code and tests on the same input means the tests are brittle or not testing what you think they are.
I have an attributes file that looks like this:
default['ftp_provision']['vsftpd']['pasv_ip'] = "192.168.0.10"
where the first attribute is the cookbook name, the second is the program, and the third is the option I want to change, implemented in a template .erb file as:
pasv_ip=<%node['ftp_provision']['vsftpd']['pasv_ip']%>
This is working correctly as expected.
However, I would like to add a role to change these attributes as required for several nodes. I'm using knife role create ftp_node1 to do that doing something like:
"default_attributes": {
"ftp_provision" => {"ftp_provision" => "vsftpd" => "pasv_ip" => "192.168.0.10"}
},
I keep getting syntax errors. All the examples I've been able to see have referenced making JSON files from Ruby DSL with only one level deep of attributes (e.g. default['key']['value']) so I'd like to know how to do this correctly per role.
you'll need to use actual JSON for this, and not sure what you mean about one level deep. this will create a hash 3 or 4 levels deep, depending on how you count it. i haven't seen issues with going further with attributes, and see many cookbooks in the wild with default['really']['freakin']['long']['strings']['of'] = attributes
i took a look at chef's examples and they're using ruby's hash format there rather than json, and that method of creating hashes makes rubocop squawk and say it's been deprecated. i can certainly see how that example would mislead you.
use a linter when building json, here's one https://jsonlint.com/
also I think this may work for you:
{
"ftp_provision": {
"vsftpd": {
"pasv_ip": "192.168.0.10"
}
}
}
I'm working on setting up configuration files in AngularJS. Is it possible to create a factory in AngularJS whose key cannot be overwritten? For example, I can set up a constant like this, which cannot be overwritten
module.constant('animals', {"cat": "meow", "dog": "woof"});
But I'd like to do something like this that allows for overwritten values but not the factory itself
module.value('catSound','meow')
.value('dogSound','woof')
.factory('animals', ['catSound','dogSound', function(catSound, dogSound) {
return {
"cat": catSound,
"dog": dogSound
}
});
The above factory can be overwritten allowing for another piece of code to have module.factory('animals',function(){ return 7 }) and break everything. However, as a factory, the individual values can (and should) be overwritable, so I should be able to assign module.value('catSound','hiss') and have things still work as expected.
I've tried injecting into constants, but as far as I've been able to understand that isn't possible. How can I prevent my factory declaration from being overwritten? I realize that constant probably isn't the correct term when describing what I want, but I do want the factory's function definition to be constant.
Everything is mutable in javascript, so setting up something like this is tricky and never completely fail-safe. I've looked around in the angular code and found no evidence of any attempt at a protection mechanism like you seem to be asking for.
My advise would be to just live with the risk. It's not worth trying to protect yourself other than with tests and nice long names. I assume you've been bitten once, but I think the chances are quite low, unless you define factories with very short names.