2 ms·

I you are just learning the language, I'd suggest skipping this particular book altogether for now. I'd start with a "Re-introduction" tutorial on MDN [1] foll

I you are just learning the language, I'd suggest skipping this particular book altogether for now. I'd start with a "Re-introduction" tutorial on MDN [1] followed by another Axel's book - "JavaScript for impatient programmers" [2]. Don't read the whole book at first, focus on specific chapters: parts on Modularity, Collections and Asynchronicity. As for TypeScript, the official Handbook [3] is great. Don't dwell much on intricacies of TS type system. Use it here and there to aid your editor or IDE in highlighting mistakes in your code, and get deeper into it once you get a good grip with JavaScript in general. [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/A_re-introduction_to_JavaScript https://developer.mozilla.org/en-US/docs/Web/JavaScript/A_re... [2] https://exploringjs.com/impatient-js/toc.html https://exploringjs.com/impatient-js/toc.html [3] https://www.typescriptlang.org/docs/handbook/intro.html https://www.typescriptlang.org/docs/handbook/intro.html

bloopernova 5y ago
Excellent, thank you! I bought the impatient book, and I'll check out the TypeScript handbook too. It's going to be a shock going from declarative DSLs like Puppet and Terraform to a real coding language! Most of my coding experience has been in shell scripting and some Perl/Ruby from ages ago.
- k__ 5y ago
  I used the CDK for quite some time now and I can say that it's usually simpler to write things in TS than YAML. Being able to throw in some loops here and there is quite a simplification on its own.
- fimbulvetr 5y ago
  IMO you should try to keep the code as DSL as possible, and only use the imperative features when it makes a lot of sense. For instance if you have like 10 security groups to add and you just put it in a for loop. You should not embed actual account numbers, regions, etc etc in your code (i.e. a cdk synth should not show arns with arn:aws:1283830383 but rather arn:aws:ACCOUNT_NUMBER) you do that by doing something like: resources: [`arn:aws:${cdk.Aws.AccountNubmer}`] (I know I got the arn format wrong and probably messed up the account number, but you get the gist I hope) The reason is if you follow those rules strictly enough, you can still deploy that template in most accounts (dev, test, prod and so on), which has always been one of the core strengths of CF (and others) when done properly. And I prefer to NOT use If statements in typescript if it can be done in Cloudformation with conditions or other items. For instance, if you only want to deploy a secondary rds slave in prod, use a CF condition and not a typescript 'if (accountNumber === myProdAccount)' because that means your typescript needs to know which account it's synthing for, which by default it does not. IOW, try to use typescript to build DSL that's still in the spirit of DSL and you'll avoid a lot of traps that novices get themselves into.

bloopernova 5y ago

Excellent, thank you! I bought the impatient book, and I'll check out the TypeScript handbook too. It's going to be a shock going from declarative DSLs like Puppet and Terraform to a real coding language! Most of my coding experience has been in shell scripting and some Perl/Ruby from ages ago.

k__ 5y ago
I used the CDK for quite some time now and I can say that it's usually simpler to write things in TS than YAML. Being able to throw in some loops here and there is quite a simplification on its own.
fimbulvetr 5y ago
IMO you should try to keep the code as DSL as possible, and only use the imperative features when it makes a lot of sense. For instance if you have like 10 security groups to add and you just put it in a for loop. You should not embed actual account numbers, regions, etc etc in your code (i.e. a cdk synth should not show arns with arn:aws:1283830383 but rather arn:aws:ACCOUNT_NUMBER) you do that by doing something like: resources: [`arn:aws:${cdk.Aws.AccountNubmer}`] (I know I got the arn format wrong and probably messed up the account number, but you get the gist I hope) The reason is if you follow those rules strictly enough, you can still deploy that template in most accounts (dev, test, prod and so on), which has always been one of the core strengths of CF (and others) when done properly. And I prefer to NOT use If statements in typescript if it can be done in Cloudformation with conditions or other items. For instance, if you only want to deploy a secondary rds slave in prod, use a CF condition and not a typescript 'if (accountNumber === myProdAccount)' because that means your typescript needs to know which account it's synthing for, which by default it does not. IOW, try to use typescript to build DSL that's still in the spirit of DSL and you'll avoid a lot of traps that novices get themselves into.