WEBVTT

1
00:00:00.200 --> 00:00:05.200
<v Speaker 1>The digital world often feels like this vast, intricate may is,

2
00:00:05.240 --> 00:00:07.480
<v Speaker 1>doesn't it? Oh totally, From the apps you tap every

3
00:00:07.519 --> 00:00:10.720
<v Speaker 1>morning to the hidden systems humming behind them, it's all

4
00:00:10.880 --> 00:00:15.480
<v Speaker 1>just incredibly complex, it really is. So today we're diving

5
00:00:15.519 --> 00:00:18.199
<v Speaker 1>deep into what it truly means to be a full

6
00:00:18.239 --> 00:00:22.359
<v Speaker 1>stack developer in this rapidly evolving tech landscape.

7
00:00:22.440 --> 00:00:25.000
<v Speaker 2>That's right, And our goal isn't to bombard you with

8
00:00:25.079 --> 00:00:29.679
<v Speaker 2>every single technical detail or like obscure language out there. Instead,

9
00:00:29.800 --> 00:00:33.039
<v Speaker 2>we want to simplify this huge topic, maybe uncover some

10
00:00:33.079 --> 00:00:36.719
<v Speaker 2>surprising facts, and offer you a clear shortcut to being

11
00:00:36.840 --> 00:00:40.320
<v Speaker 2>genuinely well informed across the entire software development life cycle.

12
00:00:40.479 --> 00:00:41.920
<v Speaker 1>Yeah, give you the map sort of.

13
00:00:42.039 --> 00:00:45.719
<v Speaker 2>Exactly, And we're drawing from a really comprehensive source, the

14
00:00:45.799 --> 00:00:47.560
<v Speaker 2>full stack developer exactly.

15
00:00:47.600 --> 00:00:49.840
<v Speaker 1>So think of this deep dive as your chance to

16
00:00:49.880 --> 00:00:52.799
<v Speaker 1>gain real clarity on the whole system, the stuff that

17
00:00:52.920 --> 00:00:55.759
<v Speaker 1>underpins the digital tools you interact with every single day.

18
00:00:55.880 --> 00:00:58.200
<v Speaker 1>M hm. Whether you're prepping for a big meeting, maybe

19
00:00:58.200 --> 00:01:01.200
<v Speaker 1>getting up to speed in a new field, or honestly

20
00:01:01.399 --> 00:01:04.200
<v Speaker 1>just curious, you'll walk away with a much clearer picture.

21
00:01:04.400 --> 00:01:07.239
<v Speaker 1>All right, let's unpack this thing So let's kick things

22
00:01:07.280 --> 00:01:11.159
<v Speaker 1>off with this term full stack developer. When I first

23
00:01:11.200 --> 00:01:13.799
<v Speaker 1>heard that, I kind of pictured someone who's like a

24
00:01:13.879 --> 00:01:15.959
<v Speaker 1>master of absolutely everything imaginable, you.

25
00:01:15.920 --> 00:01:17.280
<v Speaker 2>Know, right, the Unicorn development.

26
00:01:17.359 --> 00:01:20.000
<v Speaker 1>Yeah, from the deepest back end code to the slickest

27
00:01:20.079 --> 00:01:25.480
<v Speaker 1>user interface. But our source suggests maybe a different way

28
00:01:25.480 --> 00:01:28.640
<v Speaker 1>to look at it, perhaps more realistic. How should we

29
00:01:28.680 --> 00:01:30.159
<v Speaker 1>really think about that role today?

30
00:01:30.680 --> 00:01:34.280
<v Speaker 2>Yeah, it's an interesting shift. Actually, the core idea of

31
00:01:34.319 --> 00:01:37.560
<v Speaker 2>a full stack developer has definitely evolved beyond being a

32
00:01:37.599 --> 00:01:41.400
<v Speaker 2>wizard in every single tech stack. Okay, what's really insightful

33
00:01:41.439 --> 00:01:45.000
<v Speaker 2>here is that it's more about being a specializing generalist.

34
00:01:45.680 --> 00:01:46.840
<v Speaker 1>Specializing generalist.

35
00:01:46.920 --> 00:01:50.159
<v Speaker 2>Yeah, so you have deep expertise in certain areas, maybe

36
00:01:50.200 --> 00:01:53.519
<v Speaker 2>front end or back end, but crucially you understand how

37
00:01:53.560 --> 00:01:56.640
<v Speaker 2>to bridge the different disciplines. You grasp the full picture,

38
00:01:57.079 --> 00:01:59.560
<v Speaker 2>how all the pieces fit together to bring value to

39
00:01:59.599 --> 00:02:02.359
<v Speaker 2>the organization. It's about connecting the dots, you know.

40
00:02:02.680 --> 00:02:06.239
<v Speaker 1>I really like that framing specializing generalists. It's like understanding

41
00:02:06.239 --> 00:02:09.080
<v Speaker 1>the whole ecosystem, not just one specific part. And speaking

42
00:02:09.120 --> 00:02:13.000
<v Speaker 1>of ecosystems, the Web itself has grown, I mean massively,

43
00:02:13.039 --> 00:02:13.400
<v Speaker 1>hasn't it.

44
00:02:13.479 --> 00:02:13.680
<v Speaker 2>Yeah.

45
00:02:13.719 --> 00:02:16.719
<v Speaker 1>It started out as basically static documents. Like you said,

46
00:02:16.719 --> 00:02:17.560
<v Speaker 1>digital pamphlets.

47
00:02:17.599 --> 00:02:21.879
<v Speaker 2>Almost, you got it. The web has just profoundly transformed

48
00:02:21.919 --> 00:02:26.520
<v Speaker 2>into this world of rich, interactive web applications. I mean,

49
00:02:27.319 --> 00:02:31.639
<v Speaker 2>think about early days. The lack of consistent offline functionality

50
00:02:31.800 --> 00:02:32.680
<v Speaker 2>was a real barrier.

51
00:02:32.759 --> 00:02:33.759
<v Speaker 1>Oh yeah, I remember that.

52
00:02:33.919 --> 00:02:37.879
<v Speaker 2>But now with mobile connectivity everywhere and cool features like

53
00:02:37.960 --> 00:02:42.759
<v Speaker 2>service workers, web apps can offer really robust offline experiences.

54
00:02:42.800 --> 00:02:45.199
<v Speaker 2>They act much more like native desktop apps.

55
00:02:44.960 --> 00:02:47.520
<v Speaker 1>Sometimes, so the lines have really blurred. Then, yeah, is

56
00:02:47.560 --> 00:02:50.759
<v Speaker 1>there even a meaningful difference anymore between a simple website

57
00:02:51.080 --> 00:02:53.240
<v Speaker 1>and a context web application or is it all just

58
00:02:53.280 --> 00:02:54.159
<v Speaker 1>sort of apps?

59
00:02:54.199 --> 00:02:57.199
<v Speaker 2>Now that's a great question, and it is blurry, but

60
00:02:57.319 --> 00:03:00.280
<v Speaker 2>our source does highlight that there is still a useful distinction.

61
00:03:00.479 --> 00:03:04.520
<v Speaker 2>You've got your content based website think information articles, blogs, okay,

62
00:03:04.599 --> 00:03:07.719
<v Speaker 2>and then you have your data modifying web application, something

63
00:03:08.039 --> 00:03:12.639
<v Speaker 2>where you're creating, updating, managing data. Think online banking or

64
00:03:12.680 --> 00:03:16.919
<v Speaker 2>project management tool. Right, and many projects, maybe most projects

65
00:03:17.000 --> 00:03:20.800
<v Speaker 2>actually combine both, right, like an online story browse products

66
00:03:20.800 --> 00:03:21.560
<v Speaker 2>like a website.

67
00:03:21.840 --> 00:03:25.199
<v Speaker 1>But the shopping cart and check out that's an application precisely.

68
00:03:25.919 --> 00:03:28.840
<v Speaker 2>The inventory management behind it is definitely an application. The

69
00:03:28.919 --> 00:03:32.280
<v Speaker 2>key is understanding whether you're building an interactive tool, a

70
00:03:32.280 --> 00:03:36.120
<v Speaker 2>static info hub, or more likely a blend.

71
00:03:36.400 --> 00:03:41.680
<v Speaker 1>That distinction really helps clarify things. And something surprising from

72
00:03:41.680 --> 00:03:44.840
<v Speaker 1>the source was how much more predictable web development has

73
00:03:44.879 --> 00:03:47.479
<v Speaker 1>actually become. It mentioned the browser wars kind of ending

74
00:03:47.520 --> 00:03:48.319
<v Speaker 1>as a big factor.

75
00:03:48.400 --> 00:03:51.719
<v Speaker 2>Absolutely. Remember those days you'd build something it looked perfect

76
00:03:51.960 --> 00:03:54.240
<v Speaker 2>in say Internet Explorer.

77
00:03:53.879 --> 00:03:54.960
<v Speaker 1>Oh, don't remind me, and it.

78
00:03:54.919 --> 00:03:58.039
<v Speaker 2>Would be completely broken in Netscape, Navigator or Firefox. That

79
00:03:58.159 --> 00:03:59.360
<v Speaker 2>was the browser wars era.

80
00:03:59.479 --> 00:03:59.919
<v Speaker 1>Yeah, totally.

81
00:04:00.919 --> 00:04:03.520
<v Speaker 2>Thankfully that era is largely behind us. There's much more

82
00:04:03.520 --> 00:04:07.560
<v Speaker 2>collaboration now, much more consistency in web standards, and that

83
00:04:07.680 --> 00:04:11.080
<v Speaker 2>truly makes development more predictable and frankly far less of

84
00:04:11.120 --> 00:04:13.719
<v Speaker 2>a headache for engineers. It's kind of a silent revolution

85
00:04:13.879 --> 00:04:16.759
<v Speaker 2>that really enabled the modern web apps we rely on.

86
00:04:17.079 --> 00:04:19.879
<v Speaker 1>Okay, so when you think about actually building these complex

87
00:04:19.959 --> 00:04:23.879
<v Speaker 1>digital products, planning is obviously key. For a long time,

88
00:04:23.959 --> 00:04:29.600
<v Speaker 1>that meant like huge upfront documents, rigid blueprints, the waterfall model. Yeah, right,

89
00:04:29.759 --> 00:04:33.439
<v Speaker 1>then came agile. But our source makes it really clear

90
00:04:33.480 --> 00:04:36.000
<v Speaker 1>that agile is much more than just you know, trendy

91
00:04:36.040 --> 00:04:38.480
<v Speaker 1>buzzwords or specific rituals. Isn't it.

92
00:04:38.480 --> 00:04:42.000
<v Speaker 2>It's fundamental. If we connect this back, the agile manifesto

93
00:04:42.120 --> 00:04:44.079
<v Speaker 2>is really a mindset of philosophy.

94
00:04:44.160 --> 00:04:44.839
<v Speaker 1>Okay, mindset.

95
00:04:44.920 --> 00:04:49.319
<v Speaker 2>Yeah. It explicitly values individuals and interactions over processes and

96
00:04:49.399 --> 00:04:53.240
<v Speaker 2>tools and responding to change over following a plan.

97
00:04:53.439 --> 00:04:55.240
<v Speaker 1>That second one feels huge. It is.

98
00:04:55.720 --> 00:04:58.720
<v Speaker 2>It emphasizes that it's not just about the ceremonies, the

99
00:04:58.800 --> 00:05:02.600
<v Speaker 2>daily stand ups, the respectives writing user stories, but it's

100
00:05:02.639 --> 00:05:05.439
<v Speaker 2>a fundamental way of thinking. It helps minimize rework and

101
00:05:05.560 --> 00:05:09.120
<v Speaker 2>helps teams react effectively when things inevitably change, which they

102
00:05:09.120 --> 00:05:13.199
<v Speaker 2>always do. It's all about that continuous feedback and being flexible.

103
00:05:13.279 --> 00:05:15.879
<v Speaker 1>So it's less about doing agile and more about being agile.

104
00:05:15.920 --> 00:05:16.959
<v Speaker 2>That's a great way to put.

105
00:05:16.759 --> 00:05:19.240
<v Speaker 1>It, okay. And a key part of agile planning is

106
00:05:19.279 --> 00:05:24.240
<v Speaker 1>often user stories. What makes a user story actually, you know, effective,

107
00:05:24.439 --> 00:05:25.600
<v Speaker 1>not just a task description.

108
00:05:26.079 --> 00:05:30.560
<v Speaker 2>Good user stories according to the source follow the ininvest criteria.

109
00:05:30.639 --> 00:05:36.279
<v Speaker 2>Have you heard of this? Remind me invest independent, negotiable, valuable, estimatable, small,

110
00:05:36.319 --> 00:05:37.480
<v Speaker 2>and testable right?

111
00:05:37.560 --> 00:05:37.879
<v Speaker 1>Okay?

112
00:05:38.000 --> 00:05:42.240
<v Speaker 2>This framework helps ensure clarity and crucially, that the story

113
00:05:42.279 --> 00:05:45.600
<v Speaker 2>actually delivers value. The source is a great example of this.

114
00:05:46.279 --> 00:05:49.399
<v Speaker 2>A poorly framed story might be something like, as a user,

115
00:05:49.480 --> 00:05:51.199
<v Speaker 2>I want to register for an account so I can

116
00:05:51.279 --> 00:05:54.439
<v Speaker 2>check out quarter. Sounds reasonable, It sounds like a user net. Yeah,

117
00:05:54.720 --> 00:05:57.680
<v Speaker 2>but often the real driver is the business, so a

118
00:05:57.800 --> 00:06:01.680
<v Speaker 2>more accurate, more valuable story reviewing The true why could be.

119
00:06:02.120 --> 00:06:05.079
<v Speaker 1>As the business, I want users to register accounts so

120
00:06:05.079 --> 00:06:08.079
<v Speaker 1>I can gain more insight into my customers and maybe

121
00:06:08.079 --> 00:06:11.279
<v Speaker 1>add and our research shows account holders are more likely

122
00:06:11.360 --> 00:06:12.920
<v Speaker 1>to return. See the difference.

123
00:06:13.000 --> 00:06:15.879
<v Speaker 2>Ah. Yeah, it focuses on the business value the outcome,

124
00:06:16.000 --> 00:06:19.160
<v Speaker 2>not just the feature, so that part is critical exactly.

125
00:06:19.279 --> 00:06:22.680
<v Speaker 1>It forces you to justify why you're building it. Okay,

126
00:06:22.720 --> 00:06:25.759
<v Speaker 1>so how do teams actually track this work day to day?

127
00:06:26.199 --> 00:06:28.040
<v Speaker 1>Scrum is super popular?

128
00:06:28.199 --> 00:06:32.079
<v Speaker 2>Yeah, Scrum's huge. It's built around a prioritized backlog of

129
00:06:32.120 --> 00:06:36.360
<v Speaker 2>those user stories. Teams work in fixed length sprints, usually

130
00:06:36.360 --> 00:06:39.800
<v Speaker 2>one to four weeks, and each sprint aims to produce

131
00:06:40.000 --> 00:06:43.519
<v Speaker 2>a potentially shippable interment of the product, so you're adding

132
00:06:43.560 --> 00:06:44.879
<v Speaker 2>real value regularly.

133
00:06:45.160 --> 00:06:45.480
<v Speaker 1>Okay.

134
00:06:45.759 --> 00:06:48.399
<v Speaker 2>What's kind of fascinating though, is that one of Scrum's

135
00:06:48.439 --> 00:06:52.399
<v Speaker 2>strengths it's focused on cross functional teams where everyone can

136
00:06:52.439 --> 00:06:55.000
<v Speaker 2>pitch in. Can sometimes be a weakness. It kind of

137
00:06:55.000 --> 00:06:58.399
<v Speaker 2>assumes everyone can work on every task, which gets tricky

138
00:06:58.439 --> 00:07:00.000
<v Speaker 2>if your team is highly specialized.

139
00:07:00.399 --> 00:07:03.600
<v Speaker 1>Ah, interesting point. And then there's can bond, which feels

140
00:07:03.600 --> 00:07:04.839
<v Speaker 1>a bit different, more fluid.

141
00:07:04.839 --> 00:07:06.040
<v Speaker 2>Maybe canban is different.

142
00:07:06.120 --> 00:07:06.800
<v Speaker 1>Yeah.

143
00:07:06.839 --> 00:07:10.879
<v Speaker 2>In contrast to Scrum's fixed sprints, canben focuses on visualizing

144
00:07:10.879 --> 00:07:14.360
<v Speaker 2>the workflow, often on a board, and critically it emphasizes

145
00:07:14.439 --> 00:07:17.879
<v Speaker 2>limiting work in progress or WIP limiting WIP.

146
00:07:18.000 --> 00:07:19.720
<v Speaker 1>Okay, why is that so important?

147
00:07:19.759 --> 00:07:23.000
<v Speaker 2>Because it prevents bottlenecks and helps workflow smoothly through the system.

148
00:07:23.040 --> 00:07:26.120
<v Speaker 2>It's all about continuous improvement and optimizing that flow rate

149
00:07:26.519 --> 00:07:29.480
<v Speaker 2>rather than being locked into timeboxes like Scrum got it.

150
00:07:30.360 --> 00:07:35.560
<v Speaker 1>So visualizing flow limiting work in progress. Now, speaking of planning,

151
00:07:37.120 --> 00:07:40.920
<v Speaker 1>have you ever noticed how project estimates always seem to

152
00:07:40.920 --> 00:07:43.959
<v Speaker 1>get well fuzzier the further out you look.

153
00:07:44.079 --> 00:07:45.920
<v Speaker 2>Oh, absolutely, every single time.

154
00:07:46.000 --> 00:07:48.920
<v Speaker 1>That's what our source calls the cone of uncertainty. Can

155
00:07:48.959 --> 00:07:50.800
<v Speaker 1>you impact that a bit? What does it mean for

156
00:07:51.079 --> 00:07:52.120
<v Speaker 1>estimating projects?

157
00:07:52.920 --> 00:07:56.279
<v Speaker 2>The cone of uncertainty is just a really useful visual metaphor.

158
00:07:56.560 --> 00:07:58.759
<v Speaker 2>It shows that right at the start of a project

159
00:07:59.079 --> 00:08:01.399
<v Speaker 2>your estimate could be off maybe by a factor for

160
00:08:01.560 --> 00:08:02.199
<v Speaker 2>or even more.

161
00:08:02.480 --> 00:08:02.759
<v Speaker 1>Wow.

162
00:08:02.879 --> 00:08:05.279
<v Speaker 2>But as you progress, as you build things, and learn more.

163
00:08:05.360 --> 00:08:08.879
<v Speaker 2>The uncertainty narrows, the cone gets tighter, so estimations for

164
00:08:08.920 --> 00:08:11.600
<v Speaker 2>work happening next week are inherently more reliable than for

165
00:08:11.680 --> 00:08:13.160
<v Speaker 2>work planned six months from now.

166
00:08:13.040 --> 00:08:14.399
<v Speaker 1>Which seems obvious when you say.

167
00:08:14.240 --> 00:08:18.079
<v Speaker 2>It, but stakeholders often want hard dates. So the takeaway

168
00:08:18.120 --> 00:08:20.959
<v Speaker 2>is that it's often much more realistic and frankly honest

169
00:08:21.240 --> 00:08:24.920
<v Speaker 2>to communicate date ranges rather than concrete dates, especially early on.

170
00:08:25.480 --> 00:08:28.680
<v Speaker 2>Manage those expectations upfront, acknowledge that things will change.

171
00:08:28.839 --> 00:08:31.560
<v Speaker 1>That makes a lot of sense setting realistic expectations.

172
00:08:32.519 --> 00:08:36.320
<v Speaker 2>But even with the best planning, software development, like any

173
00:08:36.360 --> 00:08:42.080
<v Speaker 2>big project, really accumulates imperfections, stuff you wish you'd done differently.

174
00:08:42.480 --> 00:08:43.919
<v Speaker 2>We call that technical.

175
00:08:43.519 --> 00:08:46.480
<v Speaker 1>Debt, right yep, tech debt. It's like financial debt, but

176
00:08:46.600 --> 00:08:47.120
<v Speaker 1>with code.

177
00:08:47.159 --> 00:08:51.159
<v Speaker 2>How do we manage that without it just completely crippling

178
00:08:51.399 --> 00:08:52.720
<v Speaker 2>progress down the line.

179
00:08:52.879 --> 00:08:56.399
<v Speaker 1>Yeah, it's a real challenge because every project has it.

180
00:08:56.399 --> 00:08:59.200
<v Speaker 1>It just builds up over time like a house needing

181
00:08:59.279 --> 00:09:03.720
<v Speaker 1>ongoing mate. Good analogy. The source suggests a really pragmatic approach,

182
00:09:04.039 --> 00:09:07.639
<v Speaker 1>borrowing from the boy Scouts. The boy Scout rule.

183
00:09:07.679 --> 00:09:08.320
<v Speaker 2>Okay, what's that?

184
00:09:08.679 --> 00:09:11.759
<v Speaker 1>Always leave the code base cleaner than you found it. Simple.

185
00:09:12.039 --> 00:09:14.759
<v Speaker 1>I like it. It is simple, but powerful. It means

186
00:09:14.799 --> 00:09:18.399
<v Speaker 1>tackling technical debt incrementally. If you're working on a new

187
00:09:18.399 --> 00:09:21.120
<v Speaker 1>feature and you stumble across some messy code related to it,

188
00:09:21.559 --> 00:09:23.600
<v Speaker 1>you clean it up as part of that feature work.

189
00:09:23.879 --> 00:09:26.080
<v Speaker 1>You build the fix right into that estimate.

190
00:09:25.879 --> 00:09:28.120
<v Speaker 2>So you chip away at it rather than letting it

191
00:09:28.159 --> 00:09:32.639
<v Speaker 2>become this huge, scary monster task later on. Exactly, it

192
00:09:32.679 --> 00:09:36.000
<v Speaker 2>prevents it from piling up into this massive crippling problem

193
00:09:36.200 --> 00:09:41.799
<v Speaker 2>that requires a huge, dedicated refactoring project. It's about continuous tidying,

194
00:09:42.039 --> 00:09:42.320
<v Speaker 2>all right.

195
00:09:42.399 --> 00:09:44.399
<v Speaker 1>Let's shift gears a bit to the more human side

196
00:09:44.399 --> 00:09:47.039
<v Speaker 1>of things. User Experience or UX. I think a lot

197
00:09:47.080 --> 00:09:50.519
<v Speaker 1>of people, maybe myself included, sometimes equate UX with just

198
00:09:51.039 --> 00:09:53.799
<v Speaker 1>you know, making things look pretty, a nice user interface,

199
00:09:53.919 --> 00:09:54.679
<v Speaker 1>the UI.

200
00:09:54.559 --> 00:09:55.200
<v Speaker 2>Right, the visuals.

201
00:09:55.360 --> 00:09:56.960
<v Speaker 1>Well, it's much deeper than that, isn't it.

202
00:09:57.000 --> 00:10:00.559
<v Speaker 2>Oh? Indeed, way deeper. UX goes far on just a

203
00:10:00.600 --> 00:10:03.600
<v Speaker 2>pretty interface, although that's part of it. It really encompasses

204
00:10:03.600 --> 00:10:07.039
<v Speaker 2>the entire system and its underlying principles. It's all about

205
00:10:07.360 --> 00:10:10.440
<v Speaker 2>how a user interacts with a product, and maybe more importantly,

206
00:10:10.519 --> 00:10:13.399
<v Speaker 2>how they feel about that interaction. Is it easy? Frustrating

207
00:10:13.919 --> 00:10:15.679
<v Speaker 2>into intuitive? The whole journey.

208
00:10:15.720 --> 00:10:18.960
<v Speaker 1>The whole journey, and there are key roles within UX.

209
00:10:19.000 --> 00:10:22.120
<v Speaker 1>You've got UX designers focusing on interaction and visual design.

210
00:10:22.200 --> 00:10:25.519
<v Speaker 1>You have researchers or user testers who conduct studies to

211
00:10:25.600 --> 00:10:28.120
<v Speaker 1>really understand how users behave and why.

212
00:10:28.279 --> 00:10:31.320
<v Speaker 2>And then you have information architects who think about the

213
00:10:31.360 --> 00:10:34.240
<v Speaker 2>structure of the whole system. How is content organized, where

214
00:10:34.240 --> 00:10:37.559
<v Speaker 2>do users expect to find things? Getting that right is huge,

215
00:10:37.799 --> 00:10:38.919
<v Speaker 2>so making.

216
00:10:38.639 --> 00:10:42.679
<v Speaker 1>The whole thing feel intuitive, logical. And I know you're

217
00:10:42.679 --> 00:10:44.159
<v Speaker 1>a fan of this, but it brings up that old

218
00:10:44.159 --> 00:10:48.000
<v Speaker 1>computer science joke the three hardest things are cash, in validation,

219
00:10:48.240 --> 00:10:49.519
<v Speaker 1>off by one errors.

220
00:10:49.240 --> 00:10:50.679
<v Speaker 2>And naming things exactly.

221
00:10:50.759 --> 00:10:53.799
<v Speaker 1>They see, how does information architecture relate to that naming

222
00:10:53.879 --> 00:10:54.799
<v Speaker 1>things problem.

223
00:10:55.039 --> 00:10:58.240
<v Speaker 2>It's funny because it's true. What's fascinating here is how

224
00:10:58.399 --> 00:11:04.000
<v Speaker 2>information architecture directly tackles that naming things headache that plagues developers.

225
00:11:04.120 --> 00:11:08.200
<v Speaker 2>How So, it's all about organizing content and functionality logically,

226
00:11:08.360 --> 00:11:11.240
<v Speaker 2>so users find information where they expect it at the

227
00:11:11.320 --> 00:11:13.480
<v Speaker 2>right level of detail, and a huge part of that

228
00:11:13.639 --> 00:11:18.000
<v Speaker 2>is consistent, clear naming using terms the user understands, not

229
00:11:18.039 --> 00:11:21.320
<v Speaker 2>just internal business jargon. Getting the naming right makes a

230
00:11:21.360 --> 00:11:24.679
<v Speaker 2>massive difference in usability and avoids that classic frustration of

231
00:11:24.799 --> 00:11:26.159
<v Speaker 2>where did they put that feature?

232
00:11:26.360 --> 00:11:29.679
<v Speaker 1>That makes perfect sense user centric naming, not internal code exactly.

233
00:11:29.679 --> 00:11:32.679
<v Speaker 1>And a big part of understanding users is well testing

234
00:11:32.720 --> 00:11:35.840
<v Speaker 1>with them user testing? How do you actually go about that?

235
00:11:35.879 --> 00:11:37.000
<v Speaker 1>What are the different approaches?

236
00:11:37.320 --> 00:11:41.919
<v Speaker 2>User testing is crucial. You've got qualitative methods, think small groups,

237
00:11:42.480 --> 00:11:46.639
<v Speaker 2>maybe observing five users interacting with a prototype. You get

238
00:11:46.679 --> 00:11:49.240
<v Speaker 2>deep insights into why they struggle or succeed.

239
00:11:49.600 --> 00:11:50.440
<v Speaker 1>Okay, but why?

240
00:11:50.559 --> 00:11:54.480
<v Speaker 2>Then you have quantitative methods, things like website analytics, tracking clicks,

241
00:11:54.759 --> 00:11:57.519
<v Speaker 2>seeing what users do on a large scale. This gives

242
00:11:57.519 --> 00:12:00.000
<v Speaker 2>you broad but often shallower.

243
00:11:59.519 --> 00:12:02.000
<v Speaker 1>Insights what verse why makes sense?

244
00:12:02.240 --> 00:12:06.000
<v Speaker 2>A common quantitative method is AB testing. You show different

245
00:12:06.080 --> 00:12:08.679
<v Speaker 2>variants of a page, say variant A and variant B,

246
00:12:08.840 --> 00:12:11.399
<v Speaker 2>to different groups of users plus a control group who

247
00:12:11.440 --> 00:12:14.639
<v Speaker 2>sees the original. Then you see which version performs better

248
00:12:14.679 --> 00:12:17.879
<v Speaker 2>against a specific goal based on statistical significance.

249
00:12:18.120 --> 00:12:20.840
<v Speaker 1>AB testing sounds powerful, but I bet it has its

250
00:12:20.879 --> 00:12:21.679
<v Speaker 1>limitations too.

251
00:12:21.919 --> 00:12:24.559
<v Speaker 2>It certainly does you need a decent amount of traffic

252
00:12:24.600 --> 00:12:27.919
<v Speaker 2>to get statistically reliable results, so it's often not great

253
00:12:28.000 --> 00:12:31.440
<v Speaker 2>for low traffic areas of a site and running too

254
00:12:31.440 --> 00:12:33.919
<v Speaker 2>many AB tests at once can mess up your results,

255
00:12:33.919 --> 00:12:35.919
<v Speaker 2>and they interfere with each other. But maybe the most

256
00:12:35.919 --> 00:12:38.679
<v Speaker 2>important point the source raises here is ethical.

257
00:12:38.919 --> 00:12:39.399
<v Speaker 1>Ethical.

258
00:12:39.600 --> 00:12:43.840
<v Speaker 2>How so, user testing, especially ab testing, is essentially a

259
00:12:43.879 --> 00:12:46.000
<v Speaker 2>form of experimentation on humans.

260
00:12:46.120 --> 00:12:48.440
<v Speaker 1>Hmm. Hadn't thought of it quite like that.

261
00:12:48.440 --> 00:12:52.679
<v Speaker 2>Right, So it requires informed consent, respecting users, being transparent,

262
00:12:53.120 --> 00:12:56.399
<v Speaker 2>and developers and designers have an ethical responsibility to push

263
00:12:56.440 --> 00:12:58.320
<v Speaker 2>back against dark patterns.

264
00:12:58.559 --> 00:13:02.159
<v Speaker 1>Dark patterns like making it possible to unsubscribe from an email.

265
00:13:01.879 --> 00:13:06.679
<v Speaker 2>List exactly, or making account deletion incredibly difficult, hiding opt

266
00:13:06.679 --> 00:13:10.960
<v Speaker 2>out checkboxes, tricking users into sharing more data than they intended.

267
00:13:11.360 --> 00:13:14.600
<v Speaker 2>These interface tricks nudge users in ways they might not want.

268
00:13:15.080 --> 00:13:18.240
<v Speaker 2>The source really underscores that user trust is paramount and

269
00:13:18.360 --> 00:13:19.960
<v Speaker 2>using these patterns erodes it.

270
00:13:20.399 --> 00:13:22.960
<v Speaker 1>That's a really important point. So design isn't just about looks.

271
00:13:23.000 --> 00:13:26.440
<v Speaker 1>It's about ethics and trust too, fundamentally, And when it

272
00:13:26.440 --> 00:13:29.360
<v Speaker 1>comes to actually building these front end experiences you mentioned,

273
00:13:29.399 --> 00:13:33.600
<v Speaker 1>the need for close collaboration between designers and developers, especially

274
00:13:33.600 --> 00:13:35.039
<v Speaker 1>with responsive design.

275
00:13:35.039 --> 00:13:39.159
<v Speaker 2>Absolutely critical. The rise of responsive design, where one design

276
00:13:39.240 --> 00:13:42.039
<v Speaker 2>has to work beautifully on a tiny phone screen, a tablet,

277
00:13:42.159 --> 00:13:45.799
<v Speaker 2>a huge desktop monitor really forced designers and developers to

278
00:13:45.840 --> 00:13:47.200
<v Speaker 2>work together much more closely.

279
00:13:47.879 --> 00:13:49.000
<v Speaker 1>How did it change things?

280
00:13:49.559 --> 00:13:53.960
<v Speaker 2>It shifted the focus away from those rigid, pixel perfect

281
00:13:54.080 --> 00:13:57.679
<v Speaker 2>specification documents. You couldn't just hand over a static picture anymore, right,

282
00:13:57.679 --> 00:14:00.159
<v Speaker 2>because it needs to flow in a DApp exactly. It

283
00:14:00.159 --> 00:14:04.360
<v Speaker 2>became more about communicating the abstract design intent. Developers needed

284
00:14:04.360 --> 00:14:07.759
<v Speaker 2>to truly understand the designer's vision the rules behind the

285
00:14:07.840 --> 00:14:10.919
<v Speaker 2>layout to translate it accurately into flexible code.

286
00:14:11.080 --> 00:14:13.279
<v Speaker 1>I can imagine that requires a whole different level of

287
00:14:13.279 --> 00:14:17.360
<v Speaker 1>communication and shared understanding totally. And A really fundamental concept

288
00:14:17.399 --> 00:14:20.279
<v Speaker 1>for any front edd developer is the CSS box model.

289
00:14:21.120 --> 00:14:23.600
<v Speaker 1>It sounds basic, but what exactly is it and why

290
00:14:23.600 --> 00:14:24.840
<v Speaker 1>does it matter so much? Ah?

291
00:14:24.960 --> 00:14:28.000
<v Speaker 2>The box model it is fundamental. It describes how every

292
00:14:28.000 --> 00:14:30.799
<v Speaker 2>element on a web page is essentially a rectangular box,

293
00:14:31.200 --> 00:14:33.240
<v Speaker 2>and that box is made up of the content itself,

294
00:14:33.399 --> 00:14:36.159
<v Speaker 2>than padding around the content, than a border around the padding,

295
00:14:36.480 --> 00:14:40.200
<v Speaker 2>and finally margin outside the border, creating space between elements.

296
00:14:40.559 --> 00:14:42.879
<v Speaker 1>Content, padding, border, margin.

297
00:14:43.039 --> 00:14:47.600
<v Speaker 2>Okay, Understanding how these four parts interact determines the element's

298
00:14:47.679 --> 00:14:50.720
<v Speaker 2>size and how it sits relative to other elements. It's

299
00:14:50.840 --> 00:14:52.639
<v Speaker 2>literally the foundation of web layout.

300
00:14:53.120 --> 00:14:54.080
<v Speaker 1>So why is it tricky.

301
00:14:54.440 --> 00:14:58.039
<v Speaker 2>The surprising insight is how often communication breaks down. Right here,

302
00:14:58.840 --> 00:15:02.360
<v Speaker 2>a designer might vision group, padding and border as part

303
00:15:02.399 --> 00:15:05.480
<v Speaker 2>of the element, while a developer sees them as distinct

304
00:15:05.559 --> 00:15:10.440
<v Speaker 2>CSS properties. They can literally see space differently. Mastering the

305
00:15:10.440 --> 00:15:13.679
<v Speaker 2>BOSS model isn't just about CSS rules. It's about mastering

306
00:15:13.720 --> 00:15:18.039
<v Speaker 2>that translation between design vision and code implementation without endless

307
00:15:18.080 --> 00:15:19.600
<v Speaker 2>back and forth pixel adjustments.

308
00:15:19.600 --> 00:15:22.440
<v Speaker 1>Fascinating. So getting that shared understanding is key. Okay, Once

309
00:15:22.440 --> 00:15:25.399
<v Speaker 1>you grasp those basic building blocks, how do you scale design?

310
00:15:25.480 --> 00:15:27.679
<v Speaker 1>How do you make sure things are consistent and reusable

311
00:15:27.960 --> 00:15:30.519
<v Speaker 1>across maybe hundreds of pages in a big application.

312
00:15:30.720 --> 00:15:33.320
<v Speaker 2>That's where design systems come in. And a really compelling

313
00:15:33.360 --> 00:15:37.720
<v Speaker 2>framework mentioned in the source is Bradfrost's atomic design. Atomic

314
00:15:37.759 --> 00:15:41.440
<v Speaker 2>design sounds scientific, it's a great analogy. It provides a

315
00:15:41.480 --> 00:15:46.200
<v Speaker 2>hierarchical structure, like building with lados. You start small with atoms.

316
00:15:46.240 --> 00:15:49.440
<v Speaker 2>These are the absolute basic UI elements A button and

317
00:15:49.600 --> 00:15:52.720
<v Speaker 2>input field. A label cannot be broken.

318
00:15:52.399 --> 00:15:54.080
<v Speaker 1>Down further, Okay, the smallest bets.

319
00:15:54.159 --> 00:15:57.360
<v Speaker 2>Then you combine atoms to form molecules like a search form.

320
00:15:57.399 --> 00:15:59.679
<v Speaker 2>That's a molecule made of a label atom and input

321
00:15:59.679 --> 00:16:01.080
<v Speaker 2>atom and a button atom.

322
00:16:01.200 --> 00:16:03.399
<v Speaker 1>Got it? Atoms make molecules, right.

323
00:16:03.200 --> 00:16:06.639
<v Speaker 2>Then molecules combined to form organisms, which are more complex

324
00:16:06.799 --> 00:16:10.120
<v Speaker 2>UI components, forming a distinct section of an interface. Think

325
00:16:10.159 --> 00:16:13.000
<v Speaker 2>of a website header. It might contain a logo atom

326
00:16:13.080 --> 00:16:17.559
<v Speaker 2>or molecule, navigation molecule, and maybe a search form molecule.

327
00:16:17.679 --> 00:16:19.639
<v Speaker 2>That whole header section is an organism.

328
00:16:19.679 --> 00:16:22.200
<v Speaker 1>Okay, atoms, molecules, organisms.

329
00:16:22.240 --> 00:16:25.320
<v Speaker 2>Then you have templates, which are essentially page level layouts.

330
00:16:25.440 --> 00:16:28.320
<v Speaker 2>They show the structure placing organisms and molecules, but without

331
00:16:28.320 --> 00:16:32.240
<v Speaker 2>the final content, like a wireframe with components the blueprint exactly.

332
00:16:32.480 --> 00:16:36.279
<v Speaker 2>And finally you have pages, which are specific instances of

333
00:16:36.399 --> 00:16:40.720
<v Speaker 2>templates filled with real content. This whole system maps beautifully

334
00:16:40.720 --> 00:16:43.399
<v Speaker 2>to how you build components in HTML and CSS. It

335
00:16:43.440 --> 00:16:49.440
<v Speaker 2>promotes reusability, consistency, and makes managing large UIs much much easier.

336
00:16:49.840 --> 00:16:54.080
<v Speaker 1>That lego analogy really clicks brilliant. And now let's talk

337
00:16:54.080 --> 00:16:58.600
<v Speaker 1>about something crucial accessibility sometimes shortened to eleven rye. Many

338
00:16:58.639 --> 00:17:00.960
<v Speaker 1>people probably think this is just about designing for people

339
00:17:01.000 --> 00:17:04.640
<v Speaker 1>with disabilities, but the source suggests that's not the full picture.

340
00:17:04.359 --> 00:17:06.960
<v Speaker 2>Right, not at all. Accessibility isn't just for users with

341
00:17:07.000 --> 00:17:10.279
<v Speaker 2>diagnosed disabilities. It genuinely benefits everyone.

342
00:17:10.400 --> 00:17:11.559
<v Speaker 1>How So give me example.

343
00:17:11.640 --> 00:17:15.079
<v Speaker 2>Okay, think about keyboard navigation essential for someone who can't

344
00:17:15.160 --> 00:17:17.799
<v Speaker 2>use a mouse right, but lots of power users prefer

345
00:17:17.880 --> 00:17:21.039
<v Speaker 2>keyboard shortcuts because they're faster. Or subtitles on a video

346
00:17:21.119 --> 00:17:23.079
<v Speaker 2>vital for someone who is deaf or hard of hearing,

347
00:17:23.119 --> 00:17:25.160
<v Speaker 2>but super useful if you're watching in a noisy place

348
00:17:25.279 --> 00:17:26.079
<v Speaker 2>or with the SoundOff.

349
00:17:26.200 --> 00:17:28.160
<v Speaker 1>Good point, I use subtitles all the time.

350
00:17:28.400 --> 00:17:30.759
<v Speaker 2>See and the key insight from the source here is

351
00:17:30.799 --> 00:17:34.920
<v Speaker 2>really interesting. Web pages are actually accessible by default. Basic

352
00:17:35.079 --> 00:17:39.160
<v Speaker 2>HTML is readable by screen readers, navigable by keyboard. It's

353
00:17:39.200 --> 00:17:43.359
<v Speaker 2>the complexity we add fancy JavaScript widgets, non semantic markup

354
00:17:43.400 --> 00:17:46.039
<v Speaker 2>that often inadvertently introduces inaccessibility.

355
00:17:46.079 --> 00:17:49.680
<v Speaker 1>Wow, okay, so simpler is often better for accessibility in

356
00:17:49.720 --> 00:17:50.200
<v Speaker 1>many ways.

357
00:17:50.279 --> 00:17:53.680
<v Speaker 2>Yes, that's why the emphasis is on building accessibility in

358
00:17:53.799 --> 00:17:57.519
<v Speaker 2>from day one, making it accessible from the start, rather

359
00:17:57.559 --> 00:17:59.079
<v Speaker 2>than trying to bolt it on at the end, which

360
00:17:59.119 --> 00:18:00.480
<v Speaker 2>is much harder and less effective.

361
00:18:00.920 --> 00:18:03.759
<v Speaker 1>So if you're building something complex, what are some specific

362
00:18:03.799 --> 00:18:06.720
<v Speaker 1>tools or techniques developers used to maintain accessibility?

363
00:18:06.799 --> 00:18:11.160
<v Speaker 2>There are several key techniques. Using semantic HTML, using tags

364
00:18:11.200 --> 00:18:15.960
<v Speaker 2>like navarticle button correctly gives inherent meaning to content for

365
00:18:16.039 --> 00:18:17.799
<v Speaker 2>assistive technologies.

366
00:18:17.240 --> 00:18:19.680
<v Speaker 1>Using HML properly basically pretty much.

367
00:18:20.319 --> 00:18:24.960
<v Speaker 2>Then there's ARIA accessible rich Internet applications. These are extra

368
00:18:25.039 --> 00:18:27.759
<v Speaker 2>attributes you can add to HTML to define roles like

369
00:18:28.000 --> 00:18:32.359
<v Speaker 2>dialogue or tab list and states like checked or expanded

370
00:18:32.680 --> 00:18:36.240
<v Speaker 2>for custom JavaScript components that don't have native HTML equivalents.

371
00:18:36.720 --> 00:18:39.680
<v Speaker 2>This helps screen readers understand what these complex widgets are

372
00:18:39.720 --> 00:18:40.880
<v Speaker 2>and how to interact with them.

373
00:18:41.000 --> 00:18:43.119
<v Speaker 1>Okay, ARIA for custom stuff.

374
00:18:43.480 --> 00:18:47.359
<v Speaker 2>Careful focus management is also critical for interactive UIs. Making

375
00:18:47.400 --> 00:18:49.880
<v Speaker 2>sure keyboard users can clearly see where they are on

376
00:18:49.920 --> 00:18:53.319
<v Speaker 2>the page and can navigate logically, and providing proper text

377
00:18:53.359 --> 00:18:57.039
<v Speaker 2>alternatives for images, especially icons that are purely decorative, is

378
00:18:57.039 --> 00:19:00.519
<v Speaker 2>important so screen readers don't just announce meaningless file names

379
00:19:00.599 --> 00:19:04.319
<v Speaker 2>or icons. It's about ensuring everyone can perceive and operate

380
00:19:04.359 --> 00:19:05.000
<v Speaker 2>the interface.

381
00:19:05.400 --> 00:19:08.480
<v Speaker 1>Okay, moving up a layer. Building a modern web app

382
00:19:08.519 --> 00:19:10.519
<v Speaker 1>isn't just about the front end. It's often about building

383
00:19:10.599 --> 00:19:13.799
<v Speaker 1>an entire system lots of moving parts. And when you

384
00:19:13.799 --> 00:19:16.759
<v Speaker 1>think about how these systems are structured, two big approaches

385
00:19:16.799 --> 00:19:21.400
<v Speaker 1>often come up. Monoliths versus micro services. What's the fundamental

386
00:19:21.400 --> 00:19:22.799
<v Speaker 1>difference there? When would you pick one?

387
00:19:23.000 --> 00:19:26.200
<v Speaker 2>Yeah? This is a huge architectural decision. So connecting this

388
00:19:26.319 --> 00:19:30.240
<v Speaker 2>to the bigger picture, a monolith is essentially one large,

389
00:19:30.400 --> 00:19:34.799
<v Speaker 2>single application codebase. Everything is deployed together as one un

390
00:19:35.119 --> 00:19:38.640
<v Speaker 2>big blob kind of. They're generally easier to get started with,

391
00:19:38.799 --> 00:19:41.720
<v Speaker 2>simpler to deploy initially, which is great for new projects

392
00:19:41.799 --> 00:19:45.599
<v Speaker 2>or small teams. The downside, as they grow, they can

393
00:19:45.640 --> 00:19:49.359
<v Speaker 2>become really unwieldy, hard to change without affecting everything else,

394
00:19:49.720 --> 00:19:53.000
<v Speaker 2>and difficult for multiple teams to work on simultaneously without

395
00:19:53.000 --> 00:19:54.319
<v Speaker 2>stepping on each other's toes.

396
00:19:54.519 --> 00:19:56.680
<v Speaker 1>Right the big ball of mud problem exactly.

397
00:19:57.200 --> 00:20:00.000
<v Speaker 2>Micro Services, on the other hand, break the application down

398
00:20:00.160 --> 00:20:04.279
<v Speaker 2>into many smaller, independent services. Each service focuses on a

399
00:20:04.279 --> 00:20:10.240
<v Speaker 2>specific business capability, maybe user management, product catalog order processing.

400
00:20:09.799 --> 00:20:11.599
<v Speaker 1>Like legos again, but for the back end.

401
00:20:11.759 --> 00:20:14.920
<v Speaker 2>It's a good analogy. Each service can be developed, deployed,

402
00:20:14.960 --> 00:20:19.359
<v Speaker 2>and scaled independently. It's like applying the single responsibility principle

403
00:20:19.519 --> 00:20:22.599
<v Speaker 2>you use encoding. But at the system level this offers

404
00:20:22.640 --> 00:20:26.279
<v Speaker 2>way more flexibility, technology, diversity, and resilience in the long run.

405
00:20:26.519 --> 00:20:29.440
<v Speaker 2>If one service fails, it doesn't necessarily bring down the

406
00:20:29.440 --> 00:20:30.079
<v Speaker 2>whole system.

407
00:20:30.279 --> 00:20:31.640
<v Speaker 1>Sounds great, What's the catch?

408
00:20:31.839 --> 00:20:35.480
<v Speaker 2>The catch is complexity. You now have lots of small

409
00:20:35.519 --> 00:20:40.519
<v Speaker 2>things to manage, deploy, and monitor. Communication between services becomes

410
00:20:40.519 --> 00:20:44.240
<v Speaker 2>a challenge. You're essentially dealing with a distributed system, which

411
00:20:44.319 --> 00:20:48.920
<v Speaker 2>introduces a whole new set of problems around network latency, consistency,

412
00:20:48.960 --> 00:20:51.480
<v Speaker 2>and operational overhead trade offs.

413
00:20:51.759 --> 00:20:54.680
<v Speaker 1>As always, so, if you have a system with lots

414
00:20:54.680 --> 00:20:57.359
<v Speaker 1>of these components or micro services, how do they actually

415
00:20:57.400 --> 00:20:58.119
<v Speaker 1>talk to each other?

416
00:20:58.279 --> 00:21:01.759
<v Speaker 2>Good question. The primary farely communicate in two main ways,

417
00:21:02.400 --> 00:21:06.839
<v Speaker 2>synchronously using request response patterns. The most common example is

418
00:21:06.960 --> 00:21:11.759
<v Speaker 2>RESTful APIs over HTTP. One service sends a request, waits

419
00:21:11.799 --> 00:21:15.279
<v Speaker 2>for a response, then continues. It's simple direct okay, like

420
00:21:15.319 --> 00:21:18.359
<v Speaker 2>a phone call exactly. The other way is asynchronously, often

421
00:21:18.480 --> 00:21:21.640
<v Speaker 2>using message queues or event streams. One service publishes a

422
00:21:21.680 --> 00:21:25.119
<v Speaker 2>message or event order placed without waiting for a direct reply.

423
00:21:25.599 --> 00:21:28.440
<v Speaker 2>Other interested services subscribe to those messages and react when

424
00:21:28.440 --> 00:21:29.119
<v Speaker 2>they receive.

425
00:21:28.880 --> 00:21:31.079
<v Speaker 1>Them, more like sending a letter or an email.

426
00:21:30.960 --> 00:21:35.000
<v Speaker 2>Yeah, or posting on a noticeboard. This decouples the services more.

427
00:21:35.279 --> 00:21:37.839
<v Speaker 2>The sending service doesn't need to know who's listening or

428
00:21:37.880 --> 00:21:40.640
<v Speaker 2>even if they're available right now. This makes the system

429
00:21:40.720 --> 00:21:43.799
<v Speaker 2>more resilient and scalable, as services don't have to wait

430
00:21:43.839 --> 00:21:44.359
<v Speaker 2>for each other.

431
00:21:44.880 --> 00:21:49.240
<v Speaker 1>Interesting, so synchronous for direct needs, asynchronous for decoupling and

432
00:21:49.279 --> 00:21:50.759
<v Speaker 1>resilience generally yes.

433
00:21:51.200 --> 00:21:54.720
<v Speaker 2>And beyond just the core features, there are these cross

434
00:21:54.720 --> 00:21:59.279
<v Speaker 2>functional requirements that massively influence system design. Right, things that

435
00:21:59.319 --> 00:22:01.640
<v Speaker 2>aren't about what the system does, but how well it

436
00:22:01.680 --> 00:22:02.039
<v Speaker 2>does it.

437
00:22:02.119 --> 00:22:04.319
<v Speaker 1>You mean, like performance, security.

438
00:22:03.960 --> 00:22:08.200
<v Speaker 2>Stuff like that exactly. These are critical non functional requirements

439
00:22:08.200 --> 00:22:11.680
<v Speaker 2>that cut across the entire system. Performance is huge. You

440
00:22:11.720 --> 00:22:15.200
<v Speaker 2>need to think about caching strategies to store frequently accessed

441
00:22:15.240 --> 00:22:19.160
<v Speaker 2>data closer to the user, maybe using content delivery networks CDNs.

442
00:22:19.480 --> 00:22:22.079
<v Speaker 2>You might need patterns like the circuit breaker circuit breaker

443
00:22:22.319 --> 00:22:25.640
<v Speaker 2>like in my house similar idea. If a downstream service

444
00:22:25.680 --> 00:22:28.680
<v Speaker 2>is failing or slow, the circuit breaker trips and stop

445
00:22:28.799 --> 00:22:32.279
<v Speaker 2>sending requests to it for a while, preventing cascading failures

446
00:22:32.359 --> 00:22:35.680
<v Speaker 2>and allowing the system to degrade gracefully instead of crashing entirely.

447
00:22:36.039 --> 00:22:39.039
<v Speaker 2>Smart and security, of course, has to be baked in

448
00:22:39.079 --> 00:22:43.000
<v Speaker 2>from the very beginning. It affects everything, how services authenticate

449
00:22:43.000 --> 00:22:47.000
<v Speaker 2>each other, how data is encrypted, how user access is controlled.

450
00:22:47.359 --> 00:22:49.480
<v Speaker 2>You can't just sprinkle security on at the end.

451
00:22:49.599 --> 00:22:52.440
<v Speaker 1>Definitely not. Okay, let's talk about the language that seems

452
00:22:52.480 --> 00:22:54.359
<v Speaker 1>to power so much of this, especially on the web.

453
00:22:54.559 --> 00:22:59.240
<v Speaker 1>JavaScript it has kind of a let's say, mixed reputation. Yeah,

454
00:22:59.279 --> 00:23:03.160
<v Speaker 1>partly due to that infamous designed in ten Days origin story.

455
00:23:03.279 --> 00:23:05.640
<v Speaker 2>Oh yeah, Brendan Iike's legendary sprint.

456
00:23:05.720 --> 00:23:09.160
<v Speaker 1>But despite that, it's become utterly ubiquitous. How did that happen?

457
00:23:09.440 --> 00:23:13.200
<v Speaker 2>JavaScript's journey is truly remarkable. It started as this simple

458
00:23:13.319 --> 00:23:17.519
<v Speaker 2>scripting language inside the Netscape browser, meant for basic page manipulation,

459
00:23:17.640 --> 00:23:21.079
<v Speaker 2>maybe validating a form and yeah, it's rush design led

460
00:23:21.119 --> 00:23:23.920
<v Speaker 2>to some quirks, giving it that mixed reputation early.

461
00:23:23.680 --> 00:23:24.960
<v Speaker 1>On weird parts, Yeah.

462
00:23:24.759 --> 00:23:28.559
<v Speaker 2>Exactly, but it was the only language browsers universally supported.

463
00:23:28.799 --> 00:23:32.319
<v Speaker 2>Then came things like ajax allowing pages to update without

464
00:23:32.359 --> 00:23:35.519
<v Speaker 2>full reloads, which made web apps feel much more dynamic.

465
00:23:35.759 --> 00:23:38.279
<v Speaker 2>And the really big shift was no JS.

466
00:23:37.880 --> 00:23:39.440
<v Speaker 1>No JS letting JavaScript run.

467
00:23:39.279 --> 00:23:43.279
<v Speaker 2>On the server, precisely that blue thing's wide open. Suddenly

468
00:23:43.319 --> 00:23:45.319
<v Speaker 2>you could use the same language for both the front

469
00:23:45.400 --> 00:23:47.599
<v Speaker 2>end and the browser and the back end on the server.

470
00:23:48.319 --> 00:23:52.440
<v Speaker 2>This enabled a new style of isomorphic or universal JavaScript apps,

471
00:23:52.799 --> 00:23:56.720
<v Speaker 2>where you can share code even rendering logic, between client

472
00:23:56.839 --> 00:23:59.920
<v Speaker 2>and server. Huge productivity boosts.

473
00:23:59.799 --> 00:24:02.480
<v Speaker 1>Went from browser toy to full stack powerhouse.

474
00:24:02.559 --> 00:24:05.039
<v Speaker 2>Pretty much. It's incredibly versatile now.

475
00:24:05.079 --> 00:24:09.960
<v Speaker 1>In One of JavaScript's defining characteristics is that it's inherently asynchronous.

476
00:24:10.400 --> 00:24:12.680
<v Speaker 1>What does that actually mean for developers and why is

477
00:24:12.720 --> 00:24:13.880
<v Speaker 1>it so important for the web?

478
00:24:14.359 --> 00:24:18.119
<v Speaker 2>Being asynchronous is fundamental to JavaScript, especially in the browser.

479
00:24:18.519 --> 00:24:20.920
<v Speaker 2>It means the language can start a long running operation

480
00:24:21.119 --> 00:24:23.640
<v Speaker 2>like fetching data from a server or waiting for a timer,

481
00:24:23.680 --> 00:24:27.519
<v Speaker 2>without stopping everything else. The user interface remains responsive, the

482
00:24:27.559 --> 00:24:28.880
<v Speaker 2>browser doesn't freeze.

483
00:24:29.079 --> 00:24:31.759
<v Speaker 1>Crucial for a good experience, absolutely.

484
00:24:31.599 --> 00:24:35.319
<v Speaker 2>But managing this asynchronicity used to be painful. Anyone who

485
00:24:35.359 --> 00:24:38.160
<v Speaker 2>coded JS back in the day probably has nightmares about

486
00:24:38.200 --> 00:24:38.799
<v Speaker 2>callback hell.

487
00:24:38.960 --> 00:24:40.400
<v Speaker 1>Callback hell sounds ominous.

488
00:24:40.720 --> 00:24:44.960
<v Speaker 2>It was you'd have functions nested inside functions inside functions

489
00:24:45.240 --> 00:24:49.119
<v Speaker 2>handling the results of asynchronous operations. The code ended up

490
00:24:49.160 --> 00:24:53.519
<v Speaker 2>looking like this deeply indented pyramid, incredibly hard to read

491
00:24:53.599 --> 00:24:55.599
<v Speaker 2>and debug. A real mess.

492
00:24:55.720 --> 00:24:58.039
<v Speaker 1>Okay, I can picture that spaghetti.

493
00:24:57.559 --> 00:25:01.759
<v Speaker 2>Code, total spagheari. Thankfully, the lang whige evolved significantly. We

494
00:25:01.839 --> 00:25:05.279
<v Speaker 2>got promises which provide a much cleaner way to handle

495
00:25:05.319 --> 00:25:09.119
<v Speaker 2>asynchronous results. And then even better, the async and a

496
00:25:09.160 --> 00:25:10.480
<v Speaker 2>weight keywords arrived.

497
00:25:10.599 --> 00:25:13.720
<v Speaker 1>Ah Yes, async a weight that seems much more readable.

498
00:25:14.000 --> 00:25:17.480
<v Speaker 2>It makes asynchronous code look almost synchronous. It's much easier

499
00:25:17.480 --> 00:25:21.039
<v Speaker 2>to reason about avoiding that nested callback nightmare. It's a

500
00:25:21.160 --> 00:25:23.000
<v Speaker 2>huge improvement for managing complexity.

501
00:25:23.079 --> 00:25:25.359
<v Speaker 1>Definitely sounds like it. And another term I've heard in

502
00:25:25.400 --> 00:25:28.799
<v Speaker 1>the JS world is transplation. What's that all about? How

503
00:25:28.839 --> 00:25:31.960
<v Speaker 1>does it help? Jsta? Modern but also compatible?

504
00:25:32.119 --> 00:25:35.559
<v Speaker 2>Transplation is sort of the secret sauce behind JavaScript's rapid

505
00:25:35.559 --> 00:25:40.119
<v Speaker 2>evolution while maintaining backward compatibility. So JavaScript itself evolves quickly.

506
00:25:40.319 --> 00:25:44.200
<v Speaker 2>New features get added to the language standard ECMAScript, but browsers,

507
00:25:44.279 --> 00:25:47.480
<v Speaker 2>especially older ones, take time to adopt these new features.

508
00:25:47.599 --> 00:25:51.920
<v Speaker 2>The adoption lag exactly. Transpilers like Babble is the most

509
00:25:51.920 --> 00:25:54.759
<v Speaker 2>famous one are tools that take your modern JavaScript code

510
00:25:54.799 --> 00:25:58.200
<v Speaker 2>written using the latest features and automatically convert it into

511
00:25:58.319 --> 00:26:02.440
<v Speaker 2>an older, equivalent version of JavaScript that nearly all browsers understand.

512
00:26:02.640 --> 00:26:06.319
<v Speaker 1>Uh so it translates future JS into PASTJS.

513
00:26:06.519 --> 00:26:08.200
<v Speaker 2>That's a great way to put it. Think of it

514
00:26:08.279 --> 00:26:11.720
<v Speaker 2>like an advanced auto prefixer for CSS, but for the

515
00:26:11.839 --> 00:26:16.200
<v Speaker 2>entire language. It lets developers use nice, new efficient syntax

516
00:26:16.240 --> 00:26:19.920
<v Speaker 2>today while still ensuring their code runs for the widest

517
00:26:19.960 --> 00:26:20.759
<v Speaker 2>possible audience.

518
00:26:20.880 --> 00:26:21.319
<v Speaker 1>Very clever.

519
00:26:21.599 --> 00:26:26.200
<v Speaker 2>And alongside that, we finally got robust module systems. For years,

520
00:26:26.240 --> 00:26:30.039
<v Speaker 2>managing dependencies and avoiding naming conflicts in JS was messy.

521
00:26:30.359 --> 00:26:33.759
<v Speaker 2>Now we have standardized systems like common JS primarily used

522
00:26:33.799 --> 00:26:36.400
<v Speaker 2>in NOJS, and e S six modules, which are the

523
00:26:36.400 --> 00:26:39.359
<v Speaker 2>standard way to import an export code in modern JavaScript,

524
00:26:39.519 --> 00:26:43.119
<v Speaker 2>both browser and node. That was another huge leap forward

525
00:26:43.160 --> 00:26:44.640
<v Speaker 2>for organizing larger projects.

526
00:26:44.720 --> 00:26:47.240
<v Speaker 1>Makes sense. Okay, this all sounds complex and powerful, but

527
00:26:47.319 --> 00:26:50.200
<v Speaker 1>how do we actually know these systems work correctly all

528
00:26:50.200 --> 00:26:52.000
<v Speaker 1>these moving parts. That's where testing comes in.

529
00:26:52.000 --> 00:26:54.319
<v Speaker 2>Right, Absolutely essential testing is you confidence.

530
00:26:54.680 --> 00:26:58.079
<v Speaker 1>And there's this concept of the test pyramid. What does

531
00:26:58.079 --> 00:26:58.680
<v Speaker 1>that represent?

532
00:26:59.000 --> 00:27:02.160
<v Speaker 2>The test pyramid is a really useful model for thinking

533
00:27:02.160 --> 00:27:05.680
<v Speaker 2>about your testing strategy. It suggests you should have different

534
00:27:05.720 --> 00:27:07.880
<v Speaker 2>types of tests in different proportions.

535
00:27:07.960 --> 00:27:08.960
<v Speaker 1>Okay, what are the layers.

536
00:27:09.279 --> 00:27:11.519
<v Speaker 2>At the broad base of the pyramid, you have lots

537
00:27:11.559 --> 00:27:15.440
<v Speaker 2>of unit tests. These are fast, isolated tests that check

538
00:27:15.640 --> 00:27:18.519
<v Speaker 2>small pieces of code, like a single function or module.

539
00:27:18.839 --> 00:27:21.920
<v Speaker 2>In isolation. They're cheap to write and run quickly.

540
00:27:22.279 --> 00:27:24.839
<v Speaker 1>Lots of small, fast tests at the bottom exactly.

541
00:27:25.440 --> 00:27:28.640
<v Speaker 2>Then in the middle layer you have fewer integration tests.

542
00:27:29.359 --> 00:27:33.279
<v Speaker 2>These check that several units or components work together correctly.

543
00:27:33.680 --> 00:27:36.519
<v Speaker 2>They're a bit slower and more complex than unit tests.

544
00:27:36.640 --> 00:27:38.400
<v Speaker 1>Okay, checking connections right.

545
00:27:38.680 --> 00:27:40.599
<v Speaker 2>And at the very narrow top of the pyramid, you

546
00:27:40.640 --> 00:27:42.480
<v Speaker 2>have a small number of end to end E to

547
00:27:42.640 --> 00:27:47.240
<v Speaker 2>E tests. These simulate real user journeys through the entire application,

548
00:27:47.559 --> 00:27:51.039
<v Speaker 2>often using browser automation tools. They test the whole stack

549
00:27:51.119 --> 00:27:52.240
<v Speaker 2>working together.

550
00:27:52.000 --> 00:27:53.839
<v Speaker 1>The full user experience. YEP.

551
00:27:54.119 --> 00:27:56.640
<v Speaker 2>E to E tests give you the highest confidence that

552
00:27:56.680 --> 00:27:59.599
<v Speaker 2>things actually work from a user's perspective, but they are

553
00:27:59.599 --> 00:28:03.200
<v Speaker 2>the slow, most brittle, and most expensive to write and maintain.

554
00:28:03.480 --> 00:28:07.000
<v Speaker 1>So the idea is lots of fast, cheap unit tests,

555
00:28:07.319 --> 00:28:11.799
<v Speaker 1>fewer integration tests, and very few slow, expensive E two

556
00:28:11.839 --> 00:28:12.400
<v Speaker 1>E tests.

557
00:28:12.559 --> 00:28:15.039
<v Speaker 2>That's the core principle. You rely on unit tests for

558
00:28:15.119 --> 00:28:18.480
<v Speaker 2>detailed coverage and catching bugs early, and use the higher

559
00:28:18.559 --> 00:28:22.640
<v Speaker 2>level tests more sparingly for verifying broader integration and workflows.

560
00:28:22.880 --> 00:28:26.319
<v Speaker 1>Got it, And a specific development approach often linked with

561
00:28:26.400 --> 00:28:30.559
<v Speaker 1>testing is test driven development or TDD. How does that

562
00:28:30.599 --> 00:28:31.960
<v Speaker 1>work in practice? What's the cycle?

563
00:28:32.079 --> 00:28:35.359
<v Speaker 2>KDD has a very distinct rhythm, the red green refactor cycle.

564
00:28:35.480 --> 00:28:36.200
<v Speaker 1>Are refractor?

565
00:28:36.240 --> 00:28:38.759
<v Speaker 2>Okay, First you write a test for a small piece

566
00:28:38.759 --> 00:28:41.440
<v Speaker 2>of functionality you haven't implemented yet. You run the test

567
00:28:41.480 --> 00:28:43.119
<v Speaker 2>and of course it fails. That's the red light.

568
00:28:43.279 --> 00:28:44.559
<v Speaker 1>Write a failing test first.

569
00:28:44.680 --> 00:28:48.039
<v Speaker 2>Interesting, Then you write the minimum amount of production code

570
00:28:48.039 --> 00:28:51.000
<v Speaker 2>needed to make that specific test pass. Run the test

571
00:28:51.079 --> 00:28:53.480
<v Speaker 2>again and hopefully it passes. That's the green light.

572
00:28:53.519 --> 00:28:54.319
<v Speaker 1>Okay, make it work.

573
00:28:54.559 --> 00:28:56.640
<v Speaker 2>Finally, now that you have a working piece of code

574
00:28:56.680 --> 00:28:59.960
<v Speaker 2>covered by test, you refactor. You clean up the code,

575
00:29:00.119 --> 00:29:04.160
<v Speaker 2>improve its design, remove duplication, all while making sure the

576
00:29:04.200 --> 00:29:05.400
<v Speaker 2>test still passes.

577
00:29:05.680 --> 00:29:08.039
<v Speaker 1>Improve the code while keeping it working exactly.

578
00:29:08.440 --> 00:29:10.680
<v Speaker 2>Then you repeat the cycle for the next small piece

579
00:29:10.720 --> 00:29:14.839
<v Speaker 2>of functionality. The idea is that TDD forces you to

580
00:29:14.880 --> 00:29:18.480
<v Speaker 2>think about requirements upfront in the test, ensures you only

581
00:29:18.480 --> 00:29:21.160
<v Speaker 2>write necessary code, and results in a code base with

582
00:29:21.279 --> 00:29:23.920
<v Speaker 2>high test coverage, almost as a side effect, leading to

583
00:29:23.960 --> 00:29:25.960
<v Speaker 2>a cleaner, more maintainable code.

584
00:29:26.160 --> 00:29:29.440
<v Speaker 1>What about behavior driven development BDD? How does that differ

585
00:29:29.480 --> 00:29:31.759
<v Speaker 1>from TDD? Is it just writing tests differently?

586
00:29:32.240 --> 00:29:35.279
<v Speaker 2>BDD builds on the ideas of TDD, but puts a

587
00:29:35.359 --> 00:29:39.759
<v Speaker 2>much stronger emphasis on collaboration and shared understanding between technical

588
00:29:39.759 --> 00:29:43.519
<v Speaker 2>and non technical people. Collaboration, how it often involves a

589
00:29:43.559 --> 00:29:46.519
<v Speaker 2>technique called the Three amigos. Getting a business person like

590
00:29:46.559 --> 00:29:49.119
<v Speaker 2>a product owner, a developer, and a tester together to

591
00:29:49.160 --> 00:29:51.119
<v Speaker 2>discuss requirements before coding starts.

592
00:29:51.279 --> 00:29:54.279
<v Speaker 1>Business dev QA talking together, right.

593
00:29:54.279 --> 00:29:57.440
<v Speaker 2>And they work together to define executable specifications using a

594
00:29:57.480 --> 00:30:01.960
<v Speaker 2>structured natural language format, typically given when, then ah, I've.

595
00:30:01.799 --> 00:30:05.079
<v Speaker 1>Seen those given, I am logged in. When I click

596
00:30:05.160 --> 00:30:07.440
<v Speaker 1>my profile, then I should see my email.

597
00:30:07.200 --> 00:30:11.599
<v Speaker 2>Address exactly like that. These scenarios describe the desired behavior

598
00:30:11.640 --> 00:30:14.680
<v Speaker 2>of the system from a user's perspective. They serve as

599
00:30:14.680 --> 00:30:19.559
<v Speaker 2>both documentation and automated tests using tools like Cucumber or Speckflow.

600
00:30:20.119 --> 00:30:22.599
<v Speaker 2>BDD aims to ensure everyone is on the same page

601
00:30:22.599 --> 00:30:25.599
<v Speaker 2>about what the software should do, focusing on business value

602
00:30:25.640 --> 00:30:29.599
<v Speaker 2>and observable behavior rather than just technical implementation details.

603
00:30:29.799 --> 00:30:33.440
<v Speaker 1>So TDD is more developer focused cycle BDD is more

604
00:30:33.440 --> 00:30:36.079
<v Speaker 1>about shared understanding through specific examples.

605
00:30:36.200 --> 00:30:38.319
<v Speaker 2>It's a prettyod summary. Yeah, they often compliment each other.

606
00:30:38.640 --> 00:30:42.680
<v Speaker 1>And finally, on testing, there's this distinction between automated tests,

607
00:30:42.839 --> 00:30:46.559
<v Speaker 1>which we've mostly discussed in manual testing. Is there still

608
00:30:46.599 --> 00:30:50.039
<v Speaker 1>a place for humans clicking around? Aren't automated tests always better?

609
00:30:50.359 --> 00:30:54.240
<v Speaker 2>Automated tests are fantastic for catching regressions, ensuring new changes

610
00:30:54.279 --> 00:30:57.440
<v Speaker 2>didn't break old stuff, and for running repetitive checks quickly

611
00:30:57.480 --> 00:31:00.519
<v Speaker 2>and consistently. They're essential, but the only check what you

612
00:31:00.680 --> 00:31:04.400
<v Speaker 2>tell them to check. They're not good at finding unexpected issues,

613
00:31:04.640 --> 00:31:09.200
<v Speaker 2>judging visual appeal or usability nuances, or exploring edge cases

614
00:31:09.240 --> 00:31:10.440
<v Speaker 2>you didn't think to script.

615
00:31:10.720 --> 00:31:13.960
<v Speaker 1>Right. They like intuition creativity exactly.

616
00:31:14.599 --> 00:31:18.599
<v Speaker 2>That's where manual and exploratory testing performed by skilled humans

617
00:31:18.720 --> 00:31:22.880
<v Speaker 2>is still incredibly valuable. Testers can explore the application, try

618
00:31:22.960 --> 00:31:26.799
<v Speaker 2>unusual things, notice subtle visual glitches, or assess the overall

619
00:31:26.880 --> 00:31:30.119
<v Speaker 2>user experience in a way automated scripts just can't. It's

620
00:31:30.119 --> 00:31:34.599
<v Speaker 2>about balance. Automate the predictable checks, use human intelligence for

621
00:31:34.680 --> 00:31:36.599
<v Speaker 2>exploration and subjective evaluation.

622
00:31:36.920 --> 00:31:39.839
<v Speaker 1>Okay, let's talk about data. It's often called the new oil, right,

623
00:31:40.200 --> 00:31:43.440
<v Speaker 1>super valuable for any organization building these systems. What are

624
00:31:43.440 --> 00:31:45.720
<v Speaker 1>the fundamental ways we store data? What are the main

625
00:31:45.759 --> 00:31:46.839
<v Speaker 1>types of databases?

626
00:31:46.880 --> 00:31:50.519
<v Speaker 2>Broadly speaking, when storing structured or semi structured data, systems

627
00:31:50.599 --> 00:31:54.000
<v Speaker 2>usually choose between two main families, relational databases and no

628
00:31:54.079 --> 00:31:55.640
<v Speaker 2>secal databases.

629
00:31:55.119 --> 00:31:58.759
<v Speaker 1>Relation as SQL right tables, rows, columns exactly.

630
00:31:58.920 --> 00:32:03.279
<v Speaker 2>SEQL databases like postgrasscoal MYQL SQL server. They're built on

631
00:32:03.319 --> 00:32:07.160
<v Speaker 2>a foundation of strict schemas defined relationships between tables, and

632
00:32:07.240 --> 00:32:09.039
<v Speaker 2>they typically guarantee a.

633
00:32:09.160 --> 00:32:11.559
<v Speaker 1>City properties acid What does that stand for?

634
00:32:12.160 --> 00:32:18.640
<v Speaker 2>Atomicity, consistency, isolation, durability. Essentially, it guarantees that transactions are reliable.

635
00:32:18.880 --> 00:32:23.519
<v Speaker 2>Either the whole transaction completes successfully atomicity, the database remains

636
00:32:23.519 --> 00:32:28.079
<v Speaker 2>in a valid state. Consistency, concurrent transactions don't interfere with

637
00:32:28.119 --> 00:32:31.640
<v Speaker 2>each other, isolation, and once a transaction is committed, it

638
00:32:31.680 --> 00:32:34.119
<v Speaker 2>stays committed even if the system crashes.

639
00:32:34.359 --> 00:32:39.160
<v Speaker 1>Durability okay, So very strict guarantees good for financial data, perfect.

640
00:32:38.920 --> 00:32:43.119
<v Speaker 2>For financial data inventory management. Anywhere strict consistency is non negotiable,

641
00:32:43.200 --> 00:32:45.680
<v Speaker 2>the trade off is sometimes scalability and flexibility.

642
00:32:45.799 --> 00:32:47.559
<v Speaker 1>Right, So what about no SQL? What does that offer?

643
00:32:47.839 --> 00:32:51.200
<v Speaker 2>No SQL is a broad category encompassing different types key

644
00:32:51.319 --> 00:32:56.759
<v Speaker 2>value stores like Rettis, document databases like MANGOODIB, columner stores

645
00:32:56.799 --> 00:33:01.480
<v Speaker 2>like Cassandra, graph databases like neofog. They generally offer more

646
00:33:01.519 --> 00:33:05.720
<v Speaker 2>flexible data models, no rigid scheme as required, more adaptable yeah,

647
00:33:05.759 --> 00:33:09.720
<v Speaker 2>and they often prioritize scalability and availability over strict consistency.

648
00:33:10.039 --> 00:33:13.240
<v Speaker 2>Many no school databases lean towards base properties.

649
00:33:13.319 --> 00:33:14.960
<v Speaker 1>Okay, Another acronym.

650
00:33:14.839 --> 00:33:20.400
<v Speaker 2>Base basically available soft state, eventually consistent. This means the

651
00:33:20.440 --> 00:33:24.200
<v Speaker 2>system is generally available, basically available, its state might change

652
00:33:24.240 --> 00:33:28.119
<v Speaker 2>over time even without input. Soft state and data consistency

653
00:33:28.119 --> 00:33:31.160
<v Speaker 2>will eventually be reached across the system, but maybe not

654
00:33:31.279 --> 00:33:33.799
<v Speaker 2>instantaneously eventually consistent.

655
00:33:33.920 --> 00:33:36.680
<v Speaker 1>So consistency might lag a bit, but you get better

656
00:33:36.759 --> 00:33:37.960
<v Speaker 1>uptime and scale.

657
00:33:38.079 --> 00:33:40.640
<v Speaker 2>That's the common trade off. Think about a social media feed.

658
00:33:40.680 --> 00:33:42.519
<v Speaker 2>If you're like count takes a second or two to

659
00:33:42.559 --> 00:33:46.640
<v Speaker 2>update everywhere globally, that's usually acceptable. Base properties allow these

660
00:33:46.640 --> 00:33:49.680
<v Speaker 2>systems to scale massively in ways that are harder for

661
00:33:49.720 --> 00:33:54.000
<v Speaker 2>traditional ACID databases. It's a fundamental architectural choice driven by

662
00:33:54.039 --> 00:33:56.799
<v Speaker 2>your specific data needs and consistency requirements.

663
00:33:57.079 --> 00:34:01.519
<v Speaker 1>Fascinating relational acid for strictness, no school base for flexibility

664
00:34:01.519 --> 00:34:04.839
<v Speaker 1>and scale, and protecting all this data, whether relational or

665
00:34:04.839 --> 00:34:07.759
<v Speaker 1>no SUCLE is obviously critical. What are the core things

666
00:34:07.759 --> 00:34:08.519
<v Speaker 1>to think about there?

667
00:34:08.760 --> 00:34:12.360
<v Speaker 2>Protecting data isn't just a technical chore. Our source really

668
00:34:12.440 --> 00:34:16.559
<v Speaker 2>emphasizes it's a profound legal and ethical obligation.

669
00:34:16.320 --> 00:34:19.360
<v Speaker 1>Right regulations like GDPR, CCPA exactly.

670
00:34:19.920 --> 00:34:23.360
<v Speaker 2>Data is a valuable asset and mishandling it through breaches

671
00:34:23.440 --> 00:34:27.639
<v Speaker 2>or misuse can have massive reputational on financial consequences. Core

672
00:34:27.679 --> 00:34:32.599
<v Speaker 2>considerations include regular tested backups, of course, and robust encryption.

673
00:34:32.760 --> 00:34:35.039
<v Speaker 1>Encryption you mean for data moving over the network.

674
00:34:34.760 --> 00:34:39.360
<v Speaker 2>Yes, encryption in transit, typically using TLSSSL so people can't eavesdrop,

675
00:34:39.800 --> 00:34:43.159
<v Speaker 2>but also encryption at rest, encrypting the data when it's

676
00:34:43.199 --> 00:34:46.360
<v Speaker 2>stored on disk, in the database or in backups. If

677
00:34:46.360 --> 00:34:49.199
<v Speaker 2>someone steals a hard drive, the data is useless without

678
00:34:49.199 --> 00:34:49.800
<v Speaker 2>the key.

679
00:34:49.679 --> 00:34:51.519
<v Speaker 1>Both moving and sitting still got it.

680
00:34:51.719 --> 00:34:55.199
<v Speaker 2>And beyond the technical there are serious ethical implications. How

681
00:34:55.280 --> 00:34:58.119
<v Speaker 2>is user data being collected? Is it truly necessary? Is

682
00:34:58.199 --> 00:35:01.519
<v Speaker 2>consent clear? The source points out that even anonymized data

683
00:35:01.679 --> 00:35:05.760
<v Speaker 2>needs care. It's often surprisingly possible to re identify individuals

684
00:35:05.760 --> 00:35:09.320
<v Speaker 2>by combining seemingly anonymous data points, especially from different sources

685
00:35:09.599 --> 00:35:10.960
<v Speaker 2>think Cambridge Analytica.

686
00:35:11.119 --> 00:35:14.360
<v Speaker 1>That's a sobering reminder about responsibility. Okay, let's shift to

687
00:35:14.400 --> 00:35:18.760
<v Speaker 1>API's Application programming interfaces. I've heard them described as the

688
00:35:18.880 --> 00:35:21.719
<v Speaker 1>language systems used to talk to each other. Is that accurate?

689
00:35:21.840 --> 00:35:24.119
<v Speaker 2>That's a great way to think about it. APIs defined

690
00:35:24.159 --> 00:35:27.639
<v Speaker 2>the contract for how different software components, whether internal micro

691
00:35:27.719 --> 00:35:32.360
<v Speaker 2>services or external third party applications, interact. Our source frames

692
00:35:32.360 --> 00:35:36.039
<v Speaker 2>them nicely as the user experience for other applications.

693
00:35:35.559 --> 00:35:38.159
<v Speaker 1>Huh ux for code. I like that. Yeah.

694
00:35:38.199 --> 00:35:41.079
<v Speaker 2>They need to be well designed, predictable, and easy to use,

695
00:35:41.280 --> 00:35:43.880
<v Speaker 2>just like a good UI. The most dominant style on

696
00:35:43.880 --> 00:35:45.159
<v Speaker 2>the web today is RESTful.

697
00:35:45.199 --> 00:35:48.840
<v Speaker 1>APIs rest okay. What makes an API RESTful?

698
00:35:48.960 --> 00:35:53.239
<v Speaker 2>Rest leverages the existing features of HTDP. It uses standard

699
00:35:53.360 --> 00:35:56.960
<v Speaker 2>HTTP verbs get to retrieve data, post to create new data,

700
00:35:57.280 --> 00:36:00.000
<v Speaker 2>put me to update existing data, delete to remove data.

701
00:36:00.280 --> 00:36:03.440
<v Speaker 2>It's generally stateless, meaning each request contains all the information

702
00:36:03.559 --> 00:36:06.840
<v Speaker 2>needed to process it, and it uses standard HGTWOP status

703
00:36:06.840 --> 00:36:10.199
<v Speaker 2>codes to indicate success or failure like two hundred okay,

704
00:36:10.280 --> 00:36:13.320
<v Speaker 2>two one created, four oh four not found five hundred

705
00:36:13.360 --> 00:36:14.239
<v Speaker 2>internal server.

706
00:36:14.119 --> 00:36:16.679
<v Speaker 1>Error using the webs built in language pretty much.

707
00:36:17.280 --> 00:36:20.480
<v Speaker 2>This contrasts with older approaches like SOP, which had its

708
00:36:20.519 --> 00:36:25.239
<v Speaker 2>own complex XML based protocol and often required specific tooling.

709
00:36:25.679 --> 00:36:29.559
<v Speaker 2>Res is generally simpler, more flexible, and leverages the web's infrastructure.

710
00:36:29.960 --> 00:36:33.519
<v Speaker 1>And you mentioned those verbs get T, post, put delete.

711
00:36:33.920 --> 00:36:35.280
<v Speaker 1>Is there anything special about them?

712
00:36:35.599 --> 00:36:39.480
<v Speaker 2>Yes, Understanding their properties is important. Get pt and delete

713
00:36:39.800 --> 00:36:43.119
<v Speaker 2>are typically idempatant idempatent, meaning meaning you can make the

714
00:36:43.119 --> 00:36:45.719
<v Speaker 2>same request multiple times and the result will be the

715
00:36:45.719 --> 00:36:48.760
<v Speaker 2>same as making it just once. Fetching data with get

716
00:36:48.760 --> 00:36:52.840
<v Speaker 2>T multiple times doesn't change the data. Updating a resource

717
00:36:52.840 --> 00:36:55.960
<v Speaker 2>with PT using the same data multiple times results in

718
00:36:56.000 --> 00:36:59.679
<v Speaker 2>the same final state. Deleting something multiple times still results

719
00:36:59.679 --> 00:37:00.559
<v Speaker 2>in it being deleted.

720
00:37:00.679 --> 00:37:02.000
<v Speaker 1>Okay, safe to repeat.

721
00:37:01.760 --> 00:37:05.440
<v Speaker 2>Right, PT, however, is generally not identatent. Sending the same

722
00:37:05.480 --> 00:37:08.599
<v Speaker 2>pos to your request multiple times will typically create multiple

723
00:37:08.599 --> 00:37:12.079
<v Speaker 2>new resources thanks submitting an order form twice, you'll probably

724
00:37:12.079 --> 00:37:15.960
<v Speaker 2>get two orders. Understanding this helps prevent accidental duplicate actions

725
00:37:16.239 --> 00:37:18.480
<v Speaker 2>and build more robust clients and servers.

726
00:37:18.760 --> 00:37:22.599
<v Speaker 1>That's a really useful distinction. So simpler, flexible rest winds

727
00:37:22.679 --> 00:37:27.119
<v Speaker 1>for most web stuff. And what about securing these APIs?

728
00:37:27.159 --> 00:37:31.000
<v Speaker 1>If they're the doors between systems, you need locks, right absolutely.

729
00:37:31.199 --> 00:37:34.840
<v Speaker 2>API security involves two key concepts you often hear together,

730
00:37:35.159 --> 00:37:36.880
<v Speaker 2>authentication and authorization.

731
00:37:37.239 --> 00:37:37.840
<v Speaker 1>What's the difference.

732
00:37:37.880 --> 00:37:41.440
<v Speaker 2>Authentication is proving who you are? Are you really user Alice?

733
00:37:41.960 --> 00:37:46.440
<v Speaker 2>This might involve API keys, tokens like JWT's, or protocols

734
00:37:46.440 --> 00:37:49.760
<v Speaker 2>like oh off. Authorization is proving what you're allowed to

735
00:37:49.840 --> 00:37:53.239
<v Speaker 2>do once you're authenticated. Just because your user Alice doesn't

736
00:37:53.239 --> 00:37:56.800
<v Speaker 2>mean you can delete user Bob's data. Authorization checks permission,

737
00:37:56.920 --> 00:37:58.760
<v Speaker 2>who you are versus what you can do got it?

738
00:37:59.000 --> 00:38:02.280
<v Speaker 2>And another crucial as aspect is rate limiting. This prevents

739
00:38:02.320 --> 00:38:06.480
<v Speaker 2>abuse both accidental and malicious by restricting how many requests

740
00:38:06.480 --> 00:38:08.840
<v Speaker 2>a specific client or user can make within a certain

741
00:38:08.840 --> 00:38:11.880
<v Speaker 2>time period. It protects your API from being overwhelmed.

742
00:38:12.000 --> 00:38:15.880
<v Speaker 1>Makes sense, limit the calls now security. More broadly, it

743
00:38:15.880 --> 00:38:18.519
<v Speaker 1>feels like this constant battle a moving target is there

744
00:38:18.559 --> 00:38:20.519
<v Speaker 1>like a golden rule developer should always keep in.

745
00:38:20.440 --> 00:38:23.679
<v Speaker 2>Mind, there absolutely is, and it's fundamental mentioned prominently in

746
00:38:23.679 --> 00:38:26.039
<v Speaker 2>the source. Never trust user input.

747
00:38:26.400 --> 00:38:30.000
<v Speaker 1>Never trust user input sounds simple, but deep.

748
00:38:30.519 --> 00:38:34.480
<v Speaker 2>It underpins so much of web security. It means any

749
00:38:34.559 --> 00:38:37.400
<v Speaker 2>data that comes from outside your systems control, whether it's

750
00:38:37.440 --> 00:38:39.800
<v Speaker 2>from a user typing into a form a parameter in

751
00:38:39.840 --> 00:38:43.079
<v Speaker 2>a URL data from another API, must be treated as

752
00:38:43.079 --> 00:38:47.159
<v Speaker 2>potentially malicious until proven otherwise. It needs to be thoroughly

753
00:38:47.239 --> 00:38:50.440
<v Speaker 2>validated and sanitized, ideally right at the edge where it

754
00:38:50.559 --> 00:38:52.800
<v Speaker 2>enters your system, before you process it or.

755
00:38:52.760 --> 00:38:55.599
<v Speaker 1>Store it, So assume it's hostile until cleaned up.

756
00:38:55.639 --> 00:38:58.360
<v Speaker 2>Pretty much, sticking to this one principle prevents a huge

757
00:38:58.480 --> 00:38:59.960
<v Speaker 2>range of common vulnerabilities.

758
00:39:00.320 --> 00:39:02.360
<v Speaker 1>Can you give us some quick examples of what happens

759
00:39:02.400 --> 00:39:04.320
<v Speaker 1>if you don't follow that rule. What are some of

760
00:39:04.320 --> 00:39:05.559
<v Speaker 1>those common vulnerabilities?

761
00:39:05.639 --> 00:39:09.000
<v Speaker 2>Sure, If you don't validate or sanitize input properly, you

762
00:39:09.079 --> 00:39:13.000
<v Speaker 2>open the door to injection attacks. The classic is SQL injection,

763
00:39:13.119 --> 00:39:16.679
<v Speaker 2>where someone enters malicious SQL code into say a search box,

764
00:39:16.880 --> 00:39:19.559
<v Speaker 2>and if you're not careful, that code gets executed directly

765
00:39:19.639 --> 00:39:22.599
<v Speaker 2>on your database, potentially dumping and deleting all your data.

766
00:39:22.599 --> 00:39:23.039
<v Speaker 1>OUCH.

767
00:39:23.199 --> 00:39:27.199
<v Speaker 2>Then there's cross site scripting EXSSS. If you display user

768
00:39:27.239 --> 00:39:30.199
<v Speaker 2>provided input on a page without cleaning it, an attacker

769
00:39:30.199 --> 00:39:34.119
<v Speaker 2>could inject malicious JavaScript code that runs in other user's

770
00:39:34.159 --> 00:39:37.440
<v Speaker 2>browsers when they view the page, potentially stealing their session

771
00:39:37.440 --> 00:39:41.760
<v Speaker 2>cookies or log in credentials. Gary there's insecure direct object

772
00:39:41.840 --> 00:39:45.000
<v Speaker 2>references ID or. This is where maybe a URL looks

773
00:39:45.079 --> 00:39:48.039
<v Speaker 2>like user one two three profile. If the system doesn't

774
00:39:48.039 --> 00:39:50.400
<v Speaker 2>properly check if the logged in user is allowed to

775
00:39:50.440 --> 00:39:53.079
<v Speaker 2>see profile one two three, an attacker might just change

776
00:39:53.079 --> 00:39:56.079
<v Speaker 2>the number in the URL to user four five six

777
00:39:56.199 --> 00:39:58.400
<v Speaker 2>profile and access someone else's data.

778
00:39:58.320 --> 00:39:59.599
<v Speaker 1>Just guessing IDs YEP.

779
00:40:00.079 --> 00:40:03.719
<v Speaker 2>Sensitive data exposure happens when confidential data like passwords or

780
00:40:03.719 --> 00:40:06.679
<v Speaker 2>credit card numbers isn't properly encrypted at rest or in

781
00:40:06.719 --> 00:40:10.480
<v Speaker 2>transit in cross site request forgery CSRF tricks a logged

782
00:40:10.480 --> 00:40:13.079
<v Speaker 2>in users browser into making an unwanted request to a

783
00:40:13.119 --> 00:40:16.039
<v Speaker 2>site they trust, like transferring money or changing their password

784
00:40:16.039 --> 00:40:18.119
<v Speaker 2>about their knowledge. These are just a few big ones,

785
00:40:18.159 --> 00:40:20.639
<v Speaker 2>but they all stem in large part from trusting input.

786
00:40:20.719 --> 00:40:25.199
<v Speaker 1>You shouldn't wow. That paints a very clear, if slightly

787
00:40:25.320 --> 00:40:29.639
<v Speaker 1>terrifying picture of why that golden rule is so vital. Okay,

788
00:40:29.679 --> 00:40:33.719
<v Speaker 1>let's stop passwords. Are they still the best we've got?

789
00:40:34.239 --> 00:40:36.639
<v Speaker 1>Or are they, as our source suggests, maybe a bit

790
00:40:36.639 --> 00:40:37.639
<v Speaker 1>of a problematic relic.

791
00:40:37.840 --> 00:40:41.719
<v Speaker 2>The source is quite provocative here, calling passwords potentially the

792
00:40:41.760 --> 00:40:44.519
<v Speaker 2>worst security patterns still in widespread.

793
00:40:44.119 --> 00:40:46.199
<v Speaker 1>Use strong words why, because they.

794
00:40:46.119 --> 00:40:49.760
<v Speaker 2>Rely on secrets that humans are notoriously bad at managing.

795
00:40:50.159 --> 00:40:53.599
<v Speaker 2>People reuse passwords, choose weak ones, write them down fall

796
00:40:53.599 --> 00:40:57.400
<v Speaker 2>for phishing attacks. While necessary in many systems today, the

797
00:40:57.440 --> 00:41:00.239
<v Speaker 2>emphasis really needs to be on mitigating their weakness.

798
00:41:00.519 --> 00:41:01.159
<v Speaker 1>How do you do that?

799
00:41:01.440 --> 00:41:04.880
<v Speaker 2>First? Strong hashing for storage, Never store plain text passwords.

800
00:41:05.400 --> 00:41:08.639
<v Speaker 2>Use modern slow hashing algorithms like argonto or be crypt

801
00:41:08.679 --> 00:41:12.079
<v Speaker 2>with unique salts per user. Enforce minimum length and complexity.

802
00:41:12.119 --> 00:41:15.480
<v Speaker 2>The length is generally more important than demanding weird special characters,

803
00:41:15.760 --> 00:41:19.199
<v Speaker 2>and most importantly, push hard for multi factor authentication to

804
00:41:19.360 --> 00:41:20.159
<v Speaker 2>FA or MFA.

805
00:41:20.360 --> 00:41:22.880
<v Speaker 1>Something you know, password plus something you have a phone

806
00:41:22.920 --> 00:41:25.519
<v Speaker 1>app key, or something you are a fingerprint exactly.

807
00:41:25.719 --> 00:41:29.639
<v Speaker 2>It provides a crucial second layer of defense. Even if

808
00:41:29.679 --> 00:41:32.159
<v Speaker 2>an attacker gets the password, they still can't log in

809
00:41:32.239 --> 00:41:35.440
<v Speaker 2>without the second factor. Also, pay close attention to password

810
00:41:35.440 --> 00:41:38.400
<v Speaker 2>reset mechanisms. They're a very common attack factor, so they

811
00:41:38.440 --> 00:41:40.039
<v Speaker 2>need to be incredibly robust.

812
00:41:40.119 --> 00:41:44.239
<v Speaker 1>Good point. The reset flow is critical. So security clearly

813
00:41:44.320 --> 00:41:47.119
<v Speaker 1>isn't just about the application code itself.

814
00:41:46.719 --> 00:41:51.119
<v Speaker 2>Absolutely not. It extends to the entire delivery pipeline. How

815
00:41:51.159 --> 00:41:53.960
<v Speaker 2>do you manage secrets for your build tools? Who has

816
00:41:54.000 --> 00:41:57.800
<v Speaker 2>access to your source code repositories? Are your dependencies audited

817
00:41:57.800 --> 00:42:02.159
<v Speaker 2>for known vulnerabilities? Is your production infrastructure securely configured and patched?

818
00:42:02.519 --> 00:42:05.679
<v Speaker 2>It's a holistic concern. Security needs to be embedded everywhere

819
00:42:05.800 --> 00:42:07.840
<v Speaker 2>from developer laptop to production server.

820
00:42:08.079 --> 00:42:11.119
<v Speaker 1>Okay, so the code is written hopefully securely, how do

821
00:42:11.159 --> 00:42:13.880
<v Speaker 1>we actually get it out to users? That's deployment. And

822
00:42:13.920 --> 00:42:16.480
<v Speaker 1>there's this concept I've seen mentioned the twelve factor app.

823
00:42:16.639 --> 00:42:18.280
<v Speaker 1>What's that about? Is it like a checklist?

824
00:42:18.480 --> 00:42:21.000
<v Speaker 2>It's more like a set of principles or best practices

825
00:42:21.280 --> 00:42:24.760
<v Speaker 2>popularized by the platform as a service company Heroku. They

826
00:42:24.800 --> 00:42:29.079
<v Speaker 2>distilled twelve factors that tend to make applications robust, stalable, maintainable,

827
00:42:29.320 --> 00:42:33.280
<v Speaker 2>and well suited for modern cloud environments, minimizing friction during

828
00:42:33.320 --> 00:42:34.440
<v Speaker 2>deployment and operation.

829
00:42:34.599 --> 00:42:35.800
<v Speaker 1>Okay, what are some examples?

830
00:42:35.880 --> 00:42:39.440
<v Speaker 2>Things like having one code base tracked in version control,

831
00:42:39.679 --> 00:42:43.440
<v Speaker 2>but allowing for many deploys from that codebase, explicitly declaring

832
00:42:43.480 --> 00:42:47.199
<v Speaker 2>and isolating dependencies rather than relying on system wide packages.

833
00:42:47.719 --> 00:42:52.320
<v Speaker 2>Storing configuration like database passwords or API keys in environment

834
00:42:52.400 --> 00:42:55.840
<v Speaker 2>variables not checked into the code. Treating backing services like

835
00:42:55.920 --> 00:42:59.400
<v Speaker 2>databases as attached resources. Running the app is one or

836
00:42:59.519 --> 00:43:03.960
<v Speaker 2>more stateless processes, treating logs as event streams. Adhering to

837
00:43:04.000 --> 00:43:07.199
<v Speaker 2>these principles makes your app much easier to deploy, scale,

838
00:43:07.239 --> 00:43:09.639
<v Speaker 2>and manage consistently across different environments.

839
00:43:09.760 --> 00:43:12.599
<v Speaker 1>Sounds like a solid blueprint for cloud native apps. And

840
00:43:12.679 --> 00:43:17.400
<v Speaker 1>another powerful idea is Infrastructure as code or IAC. That

841
00:43:17.480 --> 00:43:19.880
<v Speaker 1>sounds transformational. What does it mean? In practice?

842
00:43:20.039 --> 00:43:23.719
<v Speaker 2>IAC is a huge shift. Instead of manually clicking around

843
00:43:23.719 --> 00:43:26.199
<v Speaker 2>in a cloud console or s assession into servers to

844
00:43:26.280 --> 00:43:32.639
<v Speaker 2>configure them, you define your entire infrastructure, servers, networks, load balancers, databases,

845
00:43:33.239 --> 00:43:37.079
<v Speaker 2>everything in configuration files using tools like Terraform or cloud.

846
00:43:36.840 --> 00:43:39.960
<v Speaker 1>Formation, defining infrastructure and code files exactly.

847
00:43:40.400 --> 00:43:43.760
<v Speaker 2>These files are stored inversion control just like your application code.

848
00:43:44.000 --> 00:43:47.199
<v Speaker 2>You can review changes, track history, and apply them automatically.

849
00:43:47.360 --> 00:43:50.840
<v Speaker 2>This enables amazing things like Phoenix deployments.

850
00:43:50.880 --> 00:43:54.280
<v Speaker 1>Phoenix deployments reborn from the ashes kind of.

851
00:43:54.639 --> 00:43:57.559
<v Speaker 2>Because your infrastructure is defined in code, you can regularly

852
00:43:57.599 --> 00:44:02.559
<v Speaker 2>tear down entire environments staging even production sometimes and rebuild

853
00:44:02.559 --> 00:44:05.679
<v Speaker 2>them completely from scratch in minutes just by running your

854
00:44:05.679 --> 00:44:10.639
<v Speaker 2>ISIC scripts. This guarantees consistency, eliminates configuration drift where manual

855
00:44:10.719 --> 00:44:14.719
<v Speaker 2>changes accumulate over time, and makes your environments incredibly resilient.

856
00:44:14.960 --> 00:44:17.960
<v Speaker 1>Wow. That sounds like a game changer for consistency and reliability.

857
00:44:18.320 --> 00:44:21.159
<v Speaker 1>What about managing risk when deploying new features? I've heard

858
00:44:21.159 --> 00:44:23.719
<v Speaker 1>about feature flags or toggles. How do they help?

859
00:44:23.920 --> 00:44:27.760
<v Speaker 2>Feature flags are incredibly useful for decoupling deployment from release.

860
00:44:28.320 --> 00:44:32.800
<v Speaker 2>They're essentially conditional statements like if statements in your code

861
00:44:32.800 --> 00:44:34.039
<v Speaker 2>that wrap around new.

862
00:44:33.880 --> 00:44:36.199
<v Speaker 1>Features, so you can turn features on or.

863
00:44:36.119 --> 00:44:39.320
<v Speaker 2>Off precisely you deploy the code with the new feature

864
00:44:39.320 --> 00:44:43.079
<v Speaker 2>included but turned off by default via the flag. Then

865
00:44:43.360 --> 00:44:47.000
<v Speaker 2>through a configuration system, often external to the code, you

866
00:44:47.039 --> 00:44:50.119
<v Speaker 2>can turn that feature on, maybe just for internal testers first,

867
00:44:50.400 --> 00:44:53.079
<v Speaker 2>then for a small percentage of real users a canary

868
00:44:53.119 --> 00:44:56.599
<v Speaker 2>release or phased rollout, then eventually for everyone.

869
00:44:56.360 --> 00:44:58.000
<v Speaker 1>So you can test in production safely.

870
00:44:58.280 --> 00:45:01.840
<v Speaker 2>Yes, it allows for a gradual rollouts, ab testing different

871
00:45:01.840 --> 00:45:05.840
<v Speaker 2>implementations of a feature, and crucially provides an instant kill switch.

872
00:45:06.400 --> 00:45:09.119
<v Speaker 2>If the new feature causes problems, you can immediately turn

873
00:45:09.159 --> 00:45:11.920
<v Speaker 2>it off via the flag configuration without needing to roll

874
00:45:11.960 --> 00:45:14.760
<v Speaker 2>back the code or deploy a hot fix. It massively

875
00:45:14.800 --> 00:45:16.239
<v Speaker 2>reduces the risk of deployments.

876
00:45:16.599 --> 00:45:19.079
<v Speaker 1>Very powerful. Okay, so the codes out there, features are

877
00:45:19.079 --> 00:45:21.599
<v Speaker 1>being managed, but making sure it all runs well in

878
00:45:21.639 --> 00:45:24.519
<v Speaker 1>production day and day out. That brings us to the

879
00:45:24.519 --> 00:45:27.760
<v Speaker 1>DevOps mindset. What's really at the core of that cultural shift?

880
00:45:28.119 --> 00:45:31.119
<v Speaker 2>At its heart, the DevOps culture as described in the

881
00:45:31.159 --> 00:45:34.519
<v Speaker 2>source often embodies the principle of you build it, you

882
00:45:34.599 --> 00:45:34.920
<v Speaker 2>run it.

883
00:45:35.000 --> 00:45:36.519
<v Speaker 1>Build it, run it, meaning.

884
00:45:36.280 --> 00:45:39.960
<v Speaker 2>Meaning the development teams take ownership and responsibility for how

885
00:45:39.960 --> 00:45:44.280
<v Speaker 2>their software actually operates and performs in production. It breaks

886
00:45:44.280 --> 00:45:47.559
<v Speaker 2>down the traditional silos between development who build the code,

887
00:45:47.840 --> 00:45:52.840
<v Speaker 2>and operations who ran the code. This reduces communication overhead,

888
00:45:53.039 --> 00:45:56.960
<v Speaker 2>eliminates finger pointing, it works on my machine, and fosters

889
00:45:57.000 --> 00:46:00.000
<v Speaker 2>a shared sense of ownership for the entire software life site,

890
00:46:00.280 --> 00:46:04.760
<v Speaker 2>from idea to production stability. It really transforms the developer's role.

891
00:46:04.920 --> 00:46:07.719
<v Speaker 1>I can see how that shared ownership would change things dramatically.

892
00:46:07.880 --> 00:46:10.320
<v Speaker 1>And I've heard of teams doing fire drills in production.

893
00:46:10.400 --> 00:46:13.760
<v Speaker 1>That sounds intense. What are those and why would you

894
00:46:13.800 --> 00:46:14.800
<v Speaker 1>deliberately break things?

895
00:46:14.840 --> 00:46:19.559
<v Speaker 2>Fire drill, sometimes called chaos engineering, involve intentionally injecting failures

896
00:46:19.559 --> 00:46:23.480
<v Speaker 2>into your systems, yes, sometimes even carefully in production, using

897
00:46:23.519 --> 00:46:27.840
<v Speaker 2>tools like Netflix's famous chaos Monkey to proactively test your

898
00:46:27.840 --> 00:46:31.519
<v Speaker 2>system's resilience and identify weaknesses before a real incident occurs

899
00:46:31.519 --> 00:46:35.360
<v Speaker 2>when you're least prepared. Do your monitoring alerts actually fire,

900
00:46:35.519 --> 00:46:38.719
<v Speaker 2>does your auto scaling work? Does the failover mechanism kick

901
00:46:38.760 --> 00:46:42.280
<v Speaker 2>in correctly? It's like practicing emergency procedures so you know

902
00:46:42.360 --> 00:46:44.920
<v Speaker 2>how the system and the team will respond under stress.

903
00:46:45.039 --> 00:46:47.239
<v Speaker 1>Better to find out during a drill than a real

904
00:46:47.320 --> 00:46:48.639
<v Speaker 1>crisis exactly.

905
00:46:49.199 --> 00:46:51.880
<v Speaker 2>These often go hand in hand with creating run books

906
00:46:51.960 --> 00:46:55.400
<v Speaker 2>or playbooks, detailed step by step guides for how to

907
00:46:55.440 --> 00:46:58.880
<v Speaker 2>respond to specific types of incidents, what metrics to check,

908
00:46:59.119 --> 00:47:01.960
<v Speaker 2>what logs to exit examin, who to contact, what commands

909
00:47:02.000 --> 00:47:05.079
<v Speaker 2>to run. Both fire drills and run books aim to

910
00:47:05.079 --> 00:47:09.119
<v Speaker 2>build resilience, improve response times, and ensure teams are prepared

911
00:47:09.199 --> 00:47:11.800
<v Speaker 2>and calmer when real problems inevitably hit.

912
00:47:11.960 --> 00:47:16.079
<v Speaker 1>That sounds incredibly valuable for building truly robust operational systems.

913
00:47:16.559 --> 00:47:19.320
<v Speaker 1>So how do these teams know what's actually happening? What's

914
00:47:19.360 --> 00:47:21.280
<v Speaker 1>the system is live? What keeps them informed?

915
00:47:21.760 --> 00:47:25.280
<v Speaker 2>That's where monitoring and alerting come in. It's crucial. This

916
00:47:25.320 --> 00:47:28.639
<v Speaker 2>involves collecting all sorts of metrics from the application and infrastructure,

917
00:47:28.679 --> 00:47:33.119
<v Speaker 2>things like server CPU memory usage, request latency, air rates,

918
00:47:33.360 --> 00:47:37.719
<v Speaker 2>database connection, pool size, business metrics like orders, permitt tracking

919
00:47:37.760 --> 00:47:40.639
<v Speaker 2>everything pretty much. Then you set up alerts based on

920
00:47:40.679 --> 00:47:43.679
<v Speaker 2>thresholds for key metrics, alert me if disk space is

921
00:47:43.719 --> 00:47:45.920
<v Speaker 2>below ten percent or alert me if the air rate

922
00:47:45.960 --> 00:47:49.639
<v Speaker 2>exceeds five per minute for five minutes. You also need detailed,

923
00:47:49.719 --> 00:47:52.440
<v Speaker 2>structured logs from your application that allow you to diagnose

924
00:47:52.480 --> 00:47:56.760
<v Speaker 2>problems when they occur. Good monitoring and alerting allow teams

925
00:47:56.760 --> 00:48:01.280
<v Speaker 2>to proactively identify potential issues, understand system health in real time,

926
00:48:01.599 --> 00:48:05.119
<v Speaker 2>and quickly pinpoint the root cause When things go wrong. Plus,

927
00:48:05.239 --> 00:48:08.239
<v Speaker 2>analyzing these metrics helps understand user behavior.

928
00:48:07.840 --> 00:48:10.320
<v Speaker 1>And product performance makes sense. You can't fix what you

929
00:48:10.360 --> 00:48:13.920
<v Speaker 1>can't see. And finally, looking across this entire landscape, a

930
00:48:14.000 --> 00:48:17.239
<v Speaker 1>key characteristic that seems essential for a full stack developer

931
00:48:17.639 --> 00:48:20.719
<v Speaker 1>or frankly anyone thriving in tech today is this idea

932
00:48:20.719 --> 00:48:21.639
<v Speaker 1>of constant learning.

933
00:48:21.960 --> 00:48:26.880
<v Speaker 2>Oh, absolutely non negotiable. The digital world, the technologies, the

934
00:48:26.920 --> 00:48:30.960
<v Speaker 2>best practices, they are constantly evolving at a dizzying pace.

935
00:48:31.320 --> 00:48:34.679
<v Speaker 2>What was cutting edge five years ago might be legacy today.

936
00:48:34.480 --> 00:48:36.360
<v Speaker 1>So you can never really arrive never.

937
00:48:36.639 --> 00:48:38.840
<v Speaker 2>It's no longer enough to just build something, ship it

938
00:48:38.880 --> 00:48:43.119
<v Speaker 2>and move on. Teams and individuals must continuously learn, experiment

939
00:48:43.159 --> 00:48:46.480
<v Speaker 2>with new tools and techniques, and use analytics and feedback

940
00:48:46.480 --> 00:48:49.119
<v Speaker 2>to understand how their product is actually being used and

941
00:48:49.119 --> 00:48:53.559
<v Speaker 2>how it's performing. This constant feedback loop drives product evolution

942
00:48:53.679 --> 00:48:57.280
<v Speaker 2>based on real world data and user needs, not just assumptions.

943
00:48:57.599 --> 00:49:00.519
<v Speaker 2>It's truly a journey of perpetual discovery and act adaptation.

944
00:49:00.880 --> 00:49:02.239
<v Speaker 2>Hashtag tag tag outro.

945
00:49:02.800 --> 00:49:05.960
<v Speaker 1>Wow, Okay, what an incredible deep dive into the full stack.

946
00:49:06.239 --> 00:49:09.159
<v Speaker 1>It's really clear that being a full stack developer, or

947
00:49:09.199 --> 00:49:13.400
<v Speaker 1>even just truly understanding This whole intricate landscape is fundamentally

948
00:49:13.440 --> 00:49:15.960
<v Speaker 1>about navigating constant change, isn't it?

949
00:49:16.000 --> 00:49:21.360
<v Speaker 2>Definitely, and connecting all these diverse disciplines design, code, data, operations, security, Yeah.

950
00:49:21.159 --> 00:49:24.119
<v Speaker 1>And building systems that are resilient, user centric and secure

951
00:49:24.519 --> 00:49:26.679
<v Speaker 1>right from that initial idea all the way through to

952
00:49:26.800 --> 00:49:29.159
<v Speaker 1>running smoothly in production exactly.

953
00:49:29.480 --> 00:49:33.840
<v Speaker 2>We really hope this overview, comprehensive but hopefully digestible, has

954
00:49:33.880 --> 00:49:38.039
<v Speaker 2>equipped you, the listener, to understand and maybe even question

955
00:49:38.199 --> 00:49:41.159
<v Speaker 2>the digital world around you with greater insight.

956
00:49:41.400 --> 00:49:44.679
<v Speaker 1>Yeah, hopefully you now have a clearer picture of all

957
00:49:44.719 --> 00:49:48.000
<v Speaker 1>those intricate layers that make our digital lives work, and

958
00:49:48.039 --> 00:49:51.519
<v Speaker 1>the incredible range of skills involved in building and maintaining them.

959
00:49:51.599 --> 00:49:54.079
<v Speaker 2>It's a lot but fascinating stuff.

960
00:49:53.800 --> 00:49:56.159
<v Speaker 1>It really is, and that leads us perfectly to our

961
00:49:56.159 --> 00:50:00.559
<v Speaker 1>provocative thought for today, Considering just how rapidly web and

962
00:50:00.599 --> 00:50:04.280
<v Speaker 1>all its related tech has evolved. What seemingly minor detail

963
00:50:04.400 --> 00:50:07.760
<v Speaker 1>or merging technology today may be something in AI or

964
00:50:07.800 --> 00:50:11.639
<v Speaker 1>web assembly or decentralized systems. What little thing today might

965
00:50:11.679 --> 00:50:14.840
<v Speaker 1>become the next foundational pillar of the full stack tomorrow.

966
00:50:15.400 --> 00:50:18.320
<v Speaker 1>Good question, something to ponder on your next digital adventure.