AWS Summit ANZ 2021 - Driving a test-first strategy with CDK and test driven development
AWS Summit ANZ 2021 - Driving a test-first strategy with CDK and test driven development
AWS Cloud Development Kit (CDK) gives you the expressive power of programming languages for defining infrastructure. In this session, we examine how the ancient concept of a test driven development can be applicable to modern software delivery. We guide you through advanced CDK concepts, such as Aspects and level 3 constructs refactoring, as well as some great practices you can apply immediately to your own applications.
To see what’s coming up from Amazon Web Services in Australia and New Zealand, visit https://go.aws/3FTtDM6
Subscribe:
More AWS videos http://bit.ly/2O3zS75
More AWS events videos http://bit.ly/316g9t4
ABOUT AWS
Amazon Web Services (AWS) hosts events, both online and in-person, bringing the cloud computing community together to connect, collaborate, and learn from AWS experts.
AWS is the world’s most comprehensive and broadly adopted cloud platform, offering over 200 fully featured services from data centers globally. Millions of customers—including the fastest-growing startups, largest enterprises, and leading government agencies—are using AWS to lower costs, become more agile, and innovate faster.
#AWS #AmazonWebServices #CloudComputing
Content
10.46 -> Hello, thanks for joining me
12.74 -> today for this AWS Summit
14.95 -> session on 'Driving a test-first
16.94 -> strategy with CDK
19.4 -> and Test Driven Development'.
22.25 -> My name is Nelli Lovchikova, and I'm a Solutions
24.95 -> Architect here at AWS. I am
27.95 -> delighted to be here with you to
29.84 -> talk about building a reliable
31.7 -> and well-documented
33.08 -> infrastructure. We are in the
37.4 -> new era now, when development
40.19 -> and ops collided in mighty DevOps
43.01 -> and cloud computing allows us to
45.26 -> spin up resources at our wish,
48.02 -> and then discard when we no
49.85 -> longer want them. As a developer,
53.69 -> I'm excited to be able to
55.19 -> control that power using tools
57.77 -> I'm already familiar with like
59.96 -> JavaScript or my personal
62.39 -> preference: TypeScript. Now
65.33 -> let's set the scene, I'm going
67.85 -> to talk a little bit about how
69.92 -> you can build your
70.82 -> Infrastructure-as-Code in the
73.19 -> AWS environment.
76.17 -> AWS Cloud Development Kit, CDK
79.16 -> is a multi-language software
80.81 -> development framework for
82.7 -> modeling cloud infrastructure
84.56 -> as a review usable component.
87.65 -> We don't write actual code that
90.02 -> is going to create our
91.37 -> infrastructure, we
93.41 -> write code that models the
95.72 -> desired state we want for our
97.58 -> infrastructure. And then we
100.28 -> pass this state to provisioning
101.93 -> engine, such as AWS
103.85 -> CloudFormation. And we're going to
106.43 -> look at this model and realise
108.74 -> that configuration for us.
112.22 -> Here at the slide, you can see
113.86 -> supported languages. And yay! We
116.38 -> have new one coming and also you
119.74 -> can see an example of the code.
122.64 -> It is just a normal typescript set
125.11 -> of statements.
126.43 -> And the good news is
127.66 -> IntelliSense support it. There
130.33 -> are a few concepts you need to
132.25 -> know so my demo looks a little
134.32 -> bit more comprehensive.
137.57 -> Stack - unit of deployment. All AWS
140.91 -> resources defined within the
142.74 -> scope of a stack, either directly
145.29 -> or indirectly, are provisioned
147.27 -> as a single unit. Stack can have
150.69 -> multiple construct or resources.
154.32 -> Constructs are the basic
156.45 -> building blocks of AWS CDK.
158.25 -> A construct
161.19 -> represents a 'cloud component'.
164.49 -> I like to think about
165.84 -> constructs as classes, for
168.27 -> example, I'm building static
170.28 -> site so my S3 bucket and CloudFront
173.72 -> Origin are going to
175.41 -> live together in a construct
177.36 -> because they're logically linked.
180.78 -> Construct would have multiple
182.58 -> resources and also can have
185.07 -> nested constructs. Resource is
189.33 -> the representation of AWS
190.95 -> resource, for example, an
193.35 -> S3 bucket, or a Lambda.
196.92 -> Aspects is the way to apply
199.69 -> operation to all constructs or
202.3 -> resources in the given scope.
204.84 -> You can then use it to make
206.46 -> changes or validate
208.42 -> something. For example, you can
210.96 -> use Aspects to apply tags
213.09 -> to all resources.
216.79 -> We introduced a Cloud Development Kit, CDK, in 2018,
222.03 -> and it's become very popular.
224.79 -> CDK is a technology of
226.68 -> choice for many organisations.
229.95 -> The power of CDK is flexibility
233.58 -> and also you don't need to learn
236.04 -> any new concepts. All previous
239.13 -> knowledge you had as a
240.18 -> developer still relevant: loops, conditions,
244.35 -> glasses, components, language
246.24 -> syntax, event tooling.
250.26 -> If you look at the code, you will
251.94 -> notice there isn't anything new
254.16 -> there. What does it mean? It
257.64 -> means
258.21 -> it can become messy and
259.95 -> bugging. What else could go
263.55 -> wrong? I'll tell you what. It is
266.88 -> not something we often talk
268.38 -> about, but infrastructure
270.63 -> debugging takes a lot of time
273.54 -> and quite complicated. You need
276.09 -> to deploy first, where are you
278.34 -> going to deploy? Do you have
280.95 -> environment per developer? Or,
282.9 -> you have development environment
284.97 -> and everybody deploy and test
286.8 -> there, how people not to step on
289.95 -> each other. And it takes time to
292.91 -> deploy and test. So if the
295.28 -> feedback loop is very, very long.
299.67 -> The other problem is documentation, with
302.18 -> dynamically changing
303.29 -> environment, how you keep track
305.21 -> of those changes? We all know
309.02 -> software was never perfect and
311.21 -> won't get perfect. But it is
314.27 -> not definitely a license to
315.92 -> create a bad software. How often
320 -> have you started a new job to
322.19 -> go look at the code and then
323.93 -> immediately want it to disappear
325.82 -> and never see it again, but
327.68 -> you'll have a few tickets
329.12 -> assigned to you? Have you ever
333.14 -> been on the other side? When the
335.36 -> new engineer joined and you try
337.94 -> to explain your infrastructure
339.5 -> code and you apologise few
341.66 -> times, and when they ask for
344.3 -> documentation, you sort of pull
346.52 -> up a PDF document that is two
348.38 -> years old and only slightly
350.75 -> resembled the actual state of
352.4 -> your workload? And those
355.7 -> problems aren't new. We've
357.35 -> already seen them before, but I
359.78 -> believe that having a bug free,
362.18 -> clean code for infrastructure
364.04 -> is even more important because
366.77 -> of the cost of error. And what is
370.34 -> the cost of
370.82 -> the bug? From my experience, it
374.36 -> can be significant, but I have a
378.26 -> solution. Let me introduce to you
381.56 -> Test Driven Development, and I'm
383.93 -> sure you heard about it. It is
386.15 -> an old concept. Kent Beck gave it
389.78 -> a name in his book published in
391.94 -> 2002, but you can find traces of
395.3 -> it in Dijkstra's 'The Humble
397.34 -> Programmer' book published in 1972
399.89 -> Test Driven Development
404.03 -> is a set of techniques that
405.95 -> encourages simple design and
408.41 -> test suites that inspire confidence.
412.79 -> By driving development with
414.83 -> automated tests, and then
416.57 -> eliminating
417.62 -> duplication, any developer can
420.35 -> write reliable, bug-free code
423.59 -> no matter what its level of
425.51 -> complexity. This is very
428.93 -> important part of the talk. Just
431.09 -> hear me out: any developer,
435.62 -> any level of complexity.
437.63 -> Isn't it awesome? Moreover, TDD
441.74 -> encourages programmers to learn
443.6 -> quickly, communicate clearly and
446.72 -> seek out constructive feedback.
449.54 -> So if you practice it, it makes
452.36 -> you a better developer.
456.6 -> Many developers use unit tests and
458.75 -> TDD interchangeably, especially
461.15 -> during job interview, let's be
463.23 -> clear. Unit tests is a piece of
467.06 -> code that sets up inputs and
469.92 -> validates outputs of a function.
473.4 -> Test Driven Development, TDD,
475.56 -> is a process of designing
478.17 -> business logic using unit tests
480.78 -> as a drive. Let's look at the
483.96 -> other benefits. Number of bugs
486.78 -> reduced, don't trust me on that,
489.99 -> there was a white paper
491.88 -> published in 2008 by researchers
494.67 -> from IBM and Microsoft. The
497.7 -> result of these case studies
499.38 -> indicate that the pre-release
501.57 -> defect density of the four
503.76 -> products decreased between 40
506.28 -> and 90% relative to similar
508.98 -> projects that did not practice
511.44 -> TDD. Then it is a design time
515.52 -> observability. What does it
517.71 -> mean? It means when test failed,
521.64 -> an error happened, you not only
523.69 -> know there's an issue, but you
526.14 -> know exactly what happened and
528.99 -> what functional expectation is
531.09 -> no longer met. And the
533.85 -> refactoring is a breeze.
536.31 -> You're going to run your test
537.57 -> suite locally and even before
539.46 -> you commit your code, you know
541.74 -> nothing is broken. So it removes
544.68 -> this anxiety part of software
546.42 -> delivery. The last benefit, your
550.53 -> code gets shipped with the full
552.75 -> set of documentation that
554.61 -> described in details, how
556.53 -> exactly it's supposed to work
558.9 -> and I'm going to demonstrate it.
561.69 -> So the process look like that.
564.87 -> Add a test, run all tests, and see
569.16 -> the particular test to fail.
571.5 -> Very important part: if your
573.57 -> test didn't fail, there may be a
575.64 -> problem. Then you need to make it
578.66 -> test working by implementing the
580.38 -> actual feature. Run all tests and
584.22 -> observed them all green.
587.16 -> Refactor and cleanup, just
590.73 -> notice you first define your
593.22 -> expectations and then you
595.26 -> implement them. And also we
598.71 -> first make things work and
601.08 -> then make it clean and elegant.
605.46 -> Let's explore that a little bit
607.26 -> deeper. So I'm going to
609.15 -> demonstrate how it is in
610.38 -> practice. But before I need to
613.35 -> explain the context.
615.81 -> Because Test Driven Development, TDD, is
618.03 -> not the technical practice, but
619.83 -> behavioural and it doesn't make
622.62 -> sense without good problem to
624.54 -> solve. I am a big fan of Star
627.6 -> Trek. So I'm going to work for
630.06 -> Klingons and they would like to
633.39 -> join Federation, and joining
636.45 -> means we're going to have
637.92 -> extensive communications.
641.53 -> Since Klingons are very strict on their
642.96 -> heritage, those communication
645.24 -> channels need to have certain
647.2 -> standards. My job, is to
650.67 -> build an API component that is
653.01 -> going to be used by others in
654.63 -> Klingon community to exchange
657.06 -> information and trade with the
659.22 -> rest of the Federation.
661.78 -> I'm going to demonstrate building an
663.48 -> API that others in the Klingon
666.21 -> community are going to use. Some
669.18 -> only need information to flow in
671.31 -> one direction and others need
673.77 -> bi-directional communication.
677.13 -> And I'm going to split this
678.24 -> problem into smaller parts and
680.16 -> attack them individually.
682.96 -> By defining expectations upfront,
685.29 -> then making them work and make
687.3 -> code a little bit cleaner.
690.96 -> I created CDK project using CDK init
693.47 -> command and set the language to
695.61 -> TypeScript and give it an app name.
697.65 -> And here a repository for the
700.77 -> code I'm going to demonstrate.
703.44 -> And it is demo time. This is a
706.01 -> newly initiated CDK project, the
708.39 -> only thing I did is installed an
710.13 -> API Gateway library. Also Jest
712.89 -> library is already added and
714.69 -> configured for testing. Now -
717.93 -> I'm going to demonstrate my
719.31 -> first test.
721.47 -> I like to think about test as a story.
726.17 -> So this story about building
728.85 -> bi-directional communication
730.23 -> channel, from practical point of
733.14 -> view, this channel should allow
734.91 -> for Federation to submit
736.56 -> everything about that new
738.15 -> starship they're building. When I
741.81 -> write stories, I use Behavioural
743.64 -> Style because it's offers
745.47 -> very clear framework for story
747.36 -> definition. It doesn't describe
750 -> implementation or UI, but it
752.34 -> focuses on a business value.
755.7 -> It always starts from defining
757.23 -> context, then it outlines
759.9 -> conditions of the situation, and
762.24 -> then it states what expected to
764.49 -> happen. So first I define the
768.09 -> context, given the communication
770.31 -> channel is needed. Then I
772.63 -> define an input: when changes
775.14 -> are allowed. And at last I
777.39 -> define expectations: the
779.4 -> requester can create a new
780.93 -> record. Notice there aren't any
784.5 -> mentions of API, http
786.36 -> verbs or anything, just the
788.07 -> business value. Now we can
790.8 -> actually set our inputs and
792.3 -> outputs in the code. So here I
794.13 -> have an empty stack, as you may
796.29 -> remember, it is a unit of
798.09 -> deployment and also provides a
800.25 -> scope. Then I'm attaching the
802.02 -> channel construct to this empty
804.36 -> stack. Notice the ReadOnly
806.49 -> is false indicating you can
808.23 -> create a record. And the last
810.57 -> statement I validate that the
813.12 -> output has an API Gateway
814.92 -> method POST. Let's run it.
819.42 -> I updated the Jest command to
821.28 -> run in the watch mode. So it
823.41 -> retests everything on saving every file.
827.06 -> What is happening right now?
829.49 -> CDK builds the project
831.53 -> creates in memory CloudFormation
833.3 -> template, and we are going to
835.79 -> validate it. As you can see the test
840.25 -> has failed. It doesn't like
842.95 -> the channel class because,
844.63 -> surprise, we didn't create it.
848.2 -> Just pause here and notice
852.49 -> how we already know the shape of
854.8 -> the component we are going to
856.51 -> create? My next step is
859.21 -> to make it green. I'm going to
860.98 -> check out next branch and test
863.74 -> is going to run again because I
865.78 -> configure it just in this way.
868.63 -> Notice the test is now green.
871.87 -> Let me show you around.
875.32 -> I created class channel that
877.99 -> extends construct, as you
880.24 -> remember, construct is a
882.1 -> component, like a container for
884.41 -> AWS resources so I can
886.48 -> logically link them.
889.63 -> All construct accept scope and every
892.63 -> single resource or construct
894.43 -> created within the scope of a
895.96 -> stack. I created an API Gateway
901.39 -> and added POST method.
905.44 -> Also, I created a channel prop
906.94 -> interface for inputs, and
908.98 -> added it into construct. Since the
912.49 -> test is green now, I am confident
915.19 -> this first functional
916.51 -> expectation is met now. Let's
919.87 -> add another one. Switching to
923.83 -> branch number 3. There I
927.34 -> added one more test. Notice we
930.04 -> are still in the same context,
932.53 -> but now have different input.
935.62 -> In this scenario, we need to make
936.97 -> sure the channel may be
938.95 -> configured for consumption
940.48 -> purposes only. For example,
943.3 -> Klingons happy to share their
945.13 -> fighting laws, but don't want
947.56 -> aliens to change them.
951.09 -> So input changes not allowed, and the
955.24 -> expectation user have no ability
958.51 -> to create a record. I also made
964.12 -> some changes because I don't
966.49 -> want duplications. I moved
968.56 -> stack to a global variable and
970.96 -> instantiates new one before. Also,
977.35 -> the previous test is still there and
979.48 -> ensures we didn't compromise
981.52 -> previous expectation by
983.11 -> introducing new code.
987.17 -> A new test already run and fail.
989.75 -> If you check what
991.18 -> is failed, you find the exact
993.01 -> scenario. How cool is that?
995.92 -> Imagine being new to this part
997.99 -> of the code, made a change, and
1000.69 -> not only see what is failed but
1003.26 -> also understand the context and
1005.81 -> intention. Let's implement that
1008.81 -> code. Switching to branch
1011.66 -> number 4 with the last part
1013.85 -> of this demo. Here I implemented
1017.39 -> an input based decision making
1019.31 -> process. Notice I have to add
1023.06 -> GET method because you cannot
1025.01 -> really have an API without any
1027.08 -> methods. If I comment it out my
1031.37 -> test is going to fail. And this
1033.86 -> is really up to you how you
1035.45 -> want to deal with it. You might
1036.71 -> want to create another test to
1038.18 -> ensure everything working as
1039.71 -> expected, or I can just leave
1042.02 -> it there. What have we done?
1046.52 -> I demonstrated a Test Driven
1048.26 -> Development workflow using Cloud
1050.87 -> Development Kit. Started from first
1054.02 -> test, defined my functional
1055.88 -> expectation, then implemented it.
1058.82 -> made some refactoring,
1060.8 -> repeated again until all
1062.57 -> requirements converted to tests
1064.79 -> and all those tests pass.
1068.44 -> Before teeing off on examples being too
1071.27 -> simple, spend 15 seconds.
1074.33 -> Imagine a world in which all code
1076.85 -> code was this clear and direct,
1081.2 -> where there's no complicated
1083.15 -> solutions, only apparently
1085.61 -> complicated problems begging
1087.68 -> careful thought. Let's have a
1090.11 -> little bit more complicated
1091.4 -> example, as an owner of the
1094.01 -> component I'm allowing other
1096.89 -> people to add integrations
1098.72 -> between API and their part of
1100.97 -> the business. As I mentioned,
1103.19 -> Klingons have standards and I
1106.01 -> need to check all provided
1107.96 -> integrations for wildcard
1109.82 -> permissions because
1111.65 -> I don't want, for example, Lambda
1113.72 -> integration to be able to create
1115.91 -> new users. We don't want
1119.12 -> Federation to create fake
1120.95 -> Klingons. I'm going to use
1123.77 -> Aspects. If you don't remember,
1126.14 -> Aspects is the way to apply
1128.3 -> curation to all constructs or
1130.7 -> resources in the given scope.
1133.04 -> This cool ability allows us to
1135.41 -> inspect given collection of
1137.15 -> resources and do something
1139.1 -> interesting. I'll show you how.
1143.2 -> Here again we have brand
1145.24 -> new project with installed
1147.4 -> Identity and Access Management Library.
1151.38 -> Let's write the first test.
1153.65 -> I'm going to write a
1154.99 -> little bit different that time.
1158.02 -> First I define a context,
1160.72 -> given the scope is provided.
1163.6 -> Then define an input when there
1166.84 -> is an allowable policy.
1170.2 -> And here's the difference: I have a
1171.94 -> second input and then the last
1174.4 -> node. You might have more nested
1178.45 -> content, it very much depends
1180.67 -> on your test structure. I'm going
1182.97 -> to put another test under that
1184.56 -> context. There is this test
1188.25 -> implementation. I'm preparing
1191.82 -> input by creating new stack and
1195.9 -> attaching new resources,
1197.19 -> including policy we need to
1198.75 -> check. Then I apply Aspects
1202.29 -> statement that should inspect
1204.57 -> my resources.
1207.29 -> And here I need to decide
1210.99 -> what kind of validation I want and I have couple options.
1216.39 -> First I can expect an
1218.37 -> exception and the other is to
1221.7 -> use native CDK annotations.
1224.61 -> Annotation is a metadata - can be
1227.31 -> just info, warning, error or
1229.59 -> deprecating note. If it is an
1232.77 -> error, you won't be able to
1234.84 -> synthesise the output file. And I
1238.09 -> actually don't want an error or
1239.61 -> exception. I want users of this
1243.15 -> component to know I'm not happy,
1245.97 -> but they still can proceed.
1249.81 -> Unfortunately, I couldn't find
1251.61 -> right implementation for jest
1253.17 -> matcher so I did it myself and learnt
1256.77 -> something along the way. Here I
1260.55 -> declared my Jest Matcher
1262.59 -> globally and then I
1265.89 -> implemented it. So first I
1270.04 -> sythesise the artifact using
1272.22 -> CDK utility and then inspect it
1275.82 -> for warnings. If a warning
1278.76 -> message matches this provided
1281.1 -> then pass it.
1287.49 -> And hear how I use it. Just to note,
1292.03 -> when I was exploring this
1294.14 -> functionality, I had about five
1296.99 -> unit tests in order to produce
1298.88 -> this matcher. I'm not going
1301.64 -> to demonstrate it, just want to
1303.77 -> point that every single
1305.39 -> expectation has to be defined as
1307.85 -> a test. As you can see, a test
1312.08 -> is red and my mission now to
1315.98 -> make it more acceptable colour.
1319.67 -> As you can see, I implemented
1321.35 -> the permission check class with
1323.69 -> this simplest implementation
1325.97 -> that makes my test green.
1330.46 -> Let's implement the second test.
1332.2 -> So I'm switching to branch number
1333.35 -> 4, and it has the same
1336.38 -> context, but the different
1340.35 -> second input and expectations.
1344.78 -> Now, if resources specified,
1349.01 -> look at this Lambda, then no
1351.14 -> warning should be added. Here
1353.87 -> is how the code looks like. Switching
1357.44 -> to the next branch, and here I
1361.72 -> made it work. At first I found
1365.89 -> out it is the policy at all
1368.2 -> and if it is then check the
1370.9 -> resource is a star. If it is
1375.52 -> then add a warning. And here we
1377.77 -> go, it is
1378.52 -> green. Switching to a new branch.
1384.96 -> I noticed I never checked for
1387.03 -> denying. Let's make denied test.
1390.81 -> I'm not going to isolate deny in
1393.09 -> its own context because in this
1395.34 -> case only one test is required.
1399.36 -> Here we go. Input and denied
1401.46 -> permission with a star as a
1403.68 -> resource and check there isn't
1406.17 -> any warnings.
1409.55 -> Implement it and now, yeah. Here are the
1413.06 -> implementation and now we're
1414.63 -> going to go green.
1419.18 -> In this demo, I explored the little bit
1422.19 -> more advanced concept with
1423.54 -> Aspects. So I gradually built my
1426.3 -> story using unit tests. Did you
1429.93 -> notice I have never deployed
1432.27 -> any resources in AWS
1433.86 -> Environment and all evaluations
1436.38 -> have been made locally in
1437.88 -> memory. I instantly knew
1441.42 -> something was wrong and was able to
1443.19 -> locate the problem and intended
1444.78 -> expectations. There are
1447.84 -> a few frequently asking
1449.19 -> questions. First, I have too many
1452.46 -> tests. Sometimes it happens and
1455.82 -> often it's okay, but you need to
1458.7 -> make sure each test has a domain
1461.55 -> expectation and not the code
1463.65 -> line. The second concern is
1467.25 -> that each change breaks a lot of
1470.1 -> tests and actually slows you
1472.02 -> down. Try not to think about
1476.1 -> implementation when you write
1477.78 -> code, consider implementation,
1479.97 -> unknown until you actually
1481.8 -> start coding it. Then your tests
1484.44 -> are going to be less specific to
1486.99 -> implementation and bring in more
1489.06 -> business value. And my favourite
1492.54 -> one and takes so much time. And
1496.11 -> it is true, according with the
1498.75 -> Microsoft white paper, the
1500.78 -> initial development might take
1502.83 -> up to
1503.61 -> 35% more time. And if you think
1508.68 -> about coding as an independent
1510.78 -> activity, it is a significant
1513.3 -> drawback. But if you think about
1516.54 -> software delivery lifecycle
1518.67 -> as a whole and the risks and
1521.73 -> overheads associated with it you
1524.55 -> probably find that having less
1526.56 -> bugs very positively affects not
1529.62 -> only the speed of the delivery,
1532.26 -> but also developer's mental
1533.82 -> health. Nobody likes to fix
1536.13 -> defects. If you need to know
1538.91 -> more, please check CDK
1541.01 -> Developer guide and API docs, it
1543.86 -> contains all information you
1545.72 -> need to start. You can practice
1548.99 -> CDK using our workshop
1551.09 -> tutorials. There is a link to
1553.61 -> this Microsoft and IBM White
1555.8 -> Paper. I mentioned few slides
1557.42 -> before, and if you
1560 -> want to know more about TDD
1562.85 -> or you have problems with that,
1564.89 -> the original Test Driven
1566.3 -> Development book is available on
1568.22 -> Amazon and has most of the
1570.32 -> answers. I highly recommend to
1572.57 -> read it. The technique I
1574.7 -> demonstrated today is a process,
1577.52 -> and like any process, it can
1579.23 -> be mastered. It is going to be
1582.05 -> awkward and uncomfortable at the
1583.73 -> beginning, you would want to do
1586.34 -> implementation and do not
1588.44 -> write these stupid tests. Soon you
1592.46 -> would notice a difference,
1594.23 -> your components become more
1595.61 -> testable and reusable. Getting
1598.76 -> back to the code you wrote year ago
1601.1 -> will be easy. I put Kata here
1607.07 -> and those who practice TDD
1609.17 -> already familiar with this term.
1611.39 -> It came from Japan and means you
1614.36 -> select the movement and then
1616.46 -> work on it until perfection. So
1619.67 -> I recommend
1620.3 -> to do so, select the problem and
1623.66 -> work your way through multiple
1625.88 -> times, look for different
1627.74 -> solutions. At some point, you
1630.77 -> will look back and see how your
1633.14 -> skills improved. Join the
1636.02 -> CDK community, it is way
1639.59 -> more fun to code together. You
1644.63 -> joined AWS Summit to learn,
1647.18 -> and you can keep learning beyond
1649.31 -> the Summit with resources,
1650.81 -> from AWS Training and
1652.28 -> Certification for DevOps. We
1655.67 -> offer over 45 online digital
1658.61 -> training that is available on
1660.41 -> demand. You can go deeper with
1663.59 -> a three day, instructor led
1665.15 -> course 'DevOps: Engineering on
1667.1 -> AWS'. You can gain
1670.07 -> credibility and confidence with
1672.14 -> two related certifications.
1675.35 -> You can also explore labs, white
1678.2 -> papers, and other technical
1679.64 -> resources by downloading the
1681.92 -> AWS Ramp-Up Guides.
1685.08 -> For more information visit
1687.32 -> aws.training/DevOps
1690.47 -> I talked today a lot about how
1692.18 -> to use CDK, but if you want to
1694.76 -> know more about why you use
1696.92 -> CDK and hear real customer
1699.05 -> stories, please check 'Empowering
1701.87 -> Your Development Teams with CDK,
1704.21 -> for speed and safety with Shri.
1706.98 -> It was Nelli Lovchikova with you. Please enjoy coding.
1712.22 -> And I hope if you get to this
1714.05 -> point you at least have sound
1717.03 -> feelings toward the topic, or me
1719.07 -> personally, please go to the
1721.83 -> survey link provided and write
1724.05 -> it down. I desperately need your
1726.21 -> attention.
Source: https://www.youtube.com/watch?v=1R7G_wcyd3s