1 00:00:00,000 --> 00:00:03,100 Software engineering involves a lot of decisions and that 2 00:00:03,100 --> 00:00:06,400 decision has some trade-offs. So we have bars and cards and so 3 00:00:06,400 --> 00:00:08,300 on. It's not like one decision is 4 00:00:08,300 --> 00:00:11,400 always better than the other. Sometimes you are not aware 5 00:00:11,400 --> 00:00:15,900 about trade off at the decision time, but later after a year or 6 00:00:15,900 --> 00:00:19,600 two, this is costly. So maybe this cost could be 7 00:00:19,700 --> 00:00:25,900 validated. Hey everyone. 8 00:00:26,400 --> 00:00:31,400 My name is Henry Surya Barragan. And you're listening to the 9 00:00:31,400 --> 00:00:34,900 tekhelet Juno, the show will be bringing you the greatest 10 00:00:34,900 --> 00:00:38,600 technical leaders practitioners and thought leaders in the 11 00:00:38,600 --> 00:00:43,500 industry to discuss about their Journey ideas and practices that 12 00:00:43,500 --> 00:00:46,600 we all can learn and apply to build a highly performing 13 00:00:46,600 --> 00:00:50,400 technical team and to make an impact in your personal work. 14 00:00:51,100 --> 00:00:59,100 So let's dive into our Journal. Hello, everyone. 15 00:00:59,300 --> 00:01:00,900 Welcome. Back to another episode of the 16 00:01:00,900 --> 00:01:03,500 technology. Not podcast with me, Ojos Henry 17 00:01:03,500 --> 00:01:05,900 Surya with Robin. Thank you for tuning in and 18 00:01:05,900 --> 00:01:08,500 spending your time with me today, listening to this 19 00:01:08,500 --> 00:01:11,100 episode. If you're new to this podcast, 20 00:01:11,300 --> 00:01:14,100 please follow technology, you know on your podcast app and 21 00:01:14,100 --> 00:01:16,300 social media on LinkedIn. Twitter. 22 00:01:16,300 --> 00:01:19,700 And Instagram also consider supporting the show by 23 00:01:19,700 --> 00:01:21,900 subscribing as a patron at technology. 24 00:01:21,900 --> 00:01:26,200 No, dot f /, Patron, and support me to continue producing, great 25 00:01:26,200 --> 00:01:29,300 content every week. Speaking about software 26 00:01:29,300 --> 00:01:31,900 mistakes. I'm pretty sure that many of us 27 00:01:31,900 --> 00:01:35,200 have made such mistakes in our software projects in whatever 28 00:01:35,200 --> 00:01:39,300 shapes or forms, or how about having to decide on important 29 00:01:39,300 --> 00:01:41,900 trade-offs to incorporate in your software design. 30 00:01:42,500 --> 00:01:45,800 And if you look back to those experienced, some of you who got 31 00:01:45,800 --> 00:01:47,600 them, right? Will be patting yourself on the 32 00:01:47,607 --> 00:01:50,500 back for being able to choose the right solutions for your 33 00:01:50,500 --> 00:01:54,000 software problems. However, I also believe that a 34 00:01:54,008 --> 00:01:57,400 lot of us could point back in time and say, yeah, I think I 35 00:01:57,400 --> 00:01:58,400 got that one. Wrong. 36 00:01:58,700 --> 00:02:01,700 And what a big mistake that was personally. 37 00:02:01,900 --> 00:02:05,400 I've made a number of those costly mistakes and how I wish I 38 00:02:05,400 --> 00:02:08,300 could use some guidance, that can teach me how to avoid 39 00:02:08,300 --> 00:02:11,500 typical and common software mistakes and trade-offs. 40 00:02:12,100 --> 00:02:15,400 Fortunately, Our Guest for today's episode has written a 41 00:02:15,400 --> 00:02:17,800 book just on that particular topic. 42 00:02:18,500 --> 00:02:21,700 Thomas leg is the author of software mistakes and 43 00:02:21,700 --> 00:02:24,800 trade-offs, how to make good programming decisions. 44 00:02:25,400 --> 00:02:27,800 In this episode, Thomas shared what? 45 00:02:27,900 --> 00:02:31,100 Let him to write this book and also shared one of his past 46 00:02:31,100 --> 00:02:34,000 software mistakes taken from his career experience. 47 00:02:34,000 --> 00:02:38,200 He also gave advice on how we as software developers should 48 00:02:38,200 --> 00:02:40,200 approach the potential software mistakes. 49 00:02:40,200 --> 00:02:43,700 We could make and explain some trade-offs that we typically 50 00:02:43,700 --> 00:02:45,200 face. When making software, 51 00:02:45,200 --> 00:02:48,300 engineering, design decisions these days such as code, 52 00:02:48,300 --> 00:02:52,300 duplication forces flexibility, premature optimization versus 53 00:02:52,300 --> 00:02:56,800 optimizing hot path data locality and memory and finally 54 00:02:56,800 --> 00:02:59,200 different. Semantics and there are 55 00:02:59,208 --> 00:03:01,700 trade-offs in building distributed systems. 56 00:03:02,300 --> 00:03:05,000 There is so much to learn from Thomas about software, 57 00:03:05,000 --> 00:03:08,500 trade-offs, in this episode. And I hope you learn a lot from 58 00:03:08,500 --> 00:03:12,100 this episode as well. And if you do help the show, by 59 00:03:12,100 --> 00:03:15,800 giving it a rating and review on your podcast app or share some 60 00:03:15,800 --> 00:03:17,800 comments on the social media channels. 61 00:03:18,300 --> 00:03:22,000 It may sound trivial, but those reviews and comments are one of 62 00:03:22,000 --> 00:03:25,300 the best ways to get this podcast to reach more listeners, 63 00:03:25,600 --> 00:03:29,000 and hopefully, they can also benefit from All the contents in 64 00:03:29,000 --> 00:03:31,900 this podcast. So let's start our episode 65 00:03:32,000 --> 00:03:34,300 right. After our short sponsor message. 66 00:03:34,600 --> 00:03:36,500 Are you looking for a new cool swag? 67 00:03:36,800 --> 00:03:39,400 Tackle it Journal. Now offers you some swags that 68 00:03:39,400 --> 00:03:43,200 you can purchase online. These wax are printed on demand 69 00:03:43,200 --> 00:03:46,600 based on your preference and will be delivered safely to you 70 00:03:46,700 --> 00:03:49,200 all over the world where shipping is available. 71 00:03:49,600 --> 00:03:52,200 Check out all the cool strikes available by visiting 72 00:03:52,200 --> 00:03:55,600 technology, you know, dot, f / shop and don't forget to break 73 00:03:55,600 --> 00:03:58,300 yourself. Once you receive any of those X. 74 00:04:01,200 --> 00:04:03,800 Hello everyone, welcome back to another episode of the package, 75 00:04:03,800 --> 00:04:07,000 you know, podcast today I have with me someone named Thomas 76 00:04:07,000 --> 00:04:09,200 lelik. He's actually the author of 77 00:04:09,500 --> 00:04:12,800 soon-to-be published book by many called software mistakes 78 00:04:12,800 --> 00:04:15,400 and trade-offs. So when we talk about writing 79 00:04:15,400 --> 00:04:18,100 software, most of the times actually, yes, we do care about 80 00:04:18,100 --> 00:04:20,200 correctness. We do care about performance and 81 00:04:20,200 --> 00:04:23,000 things like that. But sometimes we also need to be 82 00:04:23,000 --> 00:04:26,900 aware of what kind of possible mistakes or trade-offs that we 83 00:04:26,900 --> 00:04:29,200 need to think about when. When we write software so that 84 00:04:29,200 --> 00:04:32,300 it performs based on the context that we want to build it from 85 00:04:32,500 --> 00:04:34,400 and also the business requirements. 86 00:04:34,400 --> 00:04:37,000 And also in terms of maybe functional correctness and also 87 00:04:37,000 --> 00:04:39,300 performance. So today, I think Thomas will 88 00:04:39,300 --> 00:04:42,500 discuss a lot about this and hopefully, we can learn from him 89 00:04:42,500 --> 00:04:45,600 about all the mistakes that maybe have seen throughout his 90 00:04:45,600 --> 00:04:48,800 career or we some of the Epic stories Thomas. 91 00:04:48,800 --> 00:04:52,100 Currently works at data stacks for company that built databases 92 00:04:52,100 --> 00:04:54,800 such as the Sandra and also a few other things. 93 00:04:55,100 --> 00:04:57,500 Yeah, Thomas really happy to have you in the show and looking 94 00:04:57,500 --> 00:05:00,300 forward for This conversation. All right, welcome. 95 00:05:00,300 --> 00:05:03,300 Oh, so Thomas maybe in the beginning for you to introduce 96 00:05:03,300 --> 00:05:05,800 yourself, maybe telling us more about your career Journey or 97 00:05:05,800 --> 00:05:07,800 maybe any highlights or turning points? 98 00:05:08,600 --> 00:05:09,200 Yeah. Sure. 99 00:05:09,500 --> 00:05:11,900 So I've started in the ships that company. 100 00:05:11,900 --> 00:05:15,900 It was like on the Scandinavian Market at all Scandinavian 101 00:05:16,100 --> 00:05:20,800 people were reading for content stores, like newspaper and also 102 00:05:20,800 --> 00:05:24,800 websites providing news, but it was only to millions of people 103 00:05:24,900 --> 00:05:27,200 and users. So that scale was not so big. 104 00:05:27,400 --> 00:05:30,300 So, Really? I promise to Allegro the send 105 00:05:30,300 --> 00:05:32,600 eCommerce website here in Poland. 106 00:05:32,600 --> 00:05:35,700 The biggest one, we have 20 million of active users. 107 00:05:36,000 --> 00:05:38,500 And there was a lot of interesting problems that are 108 00:05:38,600 --> 00:05:41,400 big data problems. And we were collecting users, 109 00:05:41,400 --> 00:05:45,400 traffic and saving dots for the future analytics, much learning. 110 00:05:45,400 --> 00:05:49,200 And so on the data was like eight years or so, so there was 111 00:05:49,200 --> 00:05:52,300 a petabytes of data. So was involved in streaming 112 00:05:52,400 --> 00:05:57,400 Solutions when using Kafka also microservices architecture that 113 00:05:57,400 --> 00:06:00,200 will Amount of services a picture with like hundreds of 114 00:06:00,200 --> 00:06:02,500 Miles. Davis is living there was 700 of 115 00:06:02,500 --> 00:06:06,000 them and each of like a service was deployed to multiple nodes 116 00:06:06,000 --> 00:06:09,300 that was auto-scaling. Also rolling deployment, of 117 00:06:09,300 --> 00:06:12,300 those batteries that are well known in this ecosystem. 118 00:06:12,600 --> 00:06:15,700 And also be greatest solution, space Millennials park because 119 00:06:15,700 --> 00:06:19,800 it's Advanced and has some advantages over how to bunt and 120 00:06:19,800 --> 00:06:22,600 those old Solutions after almost four years. 121 00:06:22,600 --> 00:06:25,500 I've proposed to data stocks because here we have a lot 122 00:06:25,500 --> 00:06:29,600 bigger scale as you mentioned. We are providing ecosystem 123 00:06:29,600 --> 00:06:32,100 around Cassandra and some tools around it. 124 00:06:32,200 --> 00:06:35,600 Like for example, I know Stargate API that provides a 125 00:06:35,608 --> 00:06:39,400 variety of apis to our customers that could speak to Cassandra 126 00:06:39,600 --> 00:06:43,800 but not deep directing VAR C ql but also for example grdc 127 00:06:43,800 --> 00:06:46,800 graphql and so on. Also, I was involved in a cop 128 00:06:46,800 --> 00:06:49,400 car collector. So it was based on connect three 129 00:06:49,400 --> 00:06:53,400 more cred by confluent. So we provided a way to insert 130 00:06:53,400 --> 00:06:56,500 data to Cassandra and Link instruction that price from 131 00:06:56,500 --> 00:06:59,500 Kafka platform. Was quick out there for sure as 132 00:06:59,500 --> 00:07:02,100 well. So we needed to take part was 133 00:07:02,100 --> 00:07:03,600 consideration. Seriously. 134 00:07:03,800 --> 00:07:06,400 I was involved in some performance test things as well 135 00:07:06,400 --> 00:07:09,200 and so on, and main product was also double driver. 136 00:07:09,500 --> 00:07:13,700 So the main entry point for some data, from jvm ecosystem to the 137 00:07:13,700 --> 00:07:17,000 jvm world also design trade-offs, interesting 138 00:07:17,000 --> 00:07:19,900 decisions that I was involved as a part of the team. 139 00:07:20,200 --> 00:07:22,900 So that's a summary of my journey besides that. 140 00:07:22,900 --> 00:07:25,800 I am also a technical trainer here in Poland. 141 00:07:25,800 --> 00:07:29,400 So that's also an interesting. Audience because I can teach 142 00:07:29,400 --> 00:07:32,400 folks from different companies, but also I can learn from them 143 00:07:32,400 --> 00:07:36,200 from their questions by doing. So I'm better at the world. 144 00:07:36,200 --> 00:07:40,000 I am teaching them or something Kafka or caching Solutions 145 00:07:40,000 --> 00:07:41,500 performance. That's and so on. 146 00:07:42,200 --> 00:07:44,700 Thanks for sharing your journey. It seems like throughout your 147 00:07:44,700 --> 00:07:46,900 career. You have to work a lot with kind 148 00:07:46,900 --> 00:07:50,700 of big data problem, distributed systems microservices and also 149 00:07:50,700 --> 00:07:53,700 like optimizing to the low-level you mention about building like 150 00:07:53,700 --> 00:07:55,800 connectors drivers and things like that. 151 00:07:55,800 --> 00:07:59,400 So obviously you have seen Of different types of software. 152 00:07:59,500 --> 00:08:01,900 Most they are for high performance characteristics. 153 00:08:02,200 --> 00:08:05,200 But in the first place, why are you interested in writing a book 154 00:08:05,200 --> 00:08:07,400 about software mistakes and trade-offs? 155 00:08:07,600 --> 00:08:10,800 This is quite interesting because I don't see much of such 156 00:08:10,800 --> 00:08:12,800 book except yet some mental patterns. 157 00:08:12,800 --> 00:08:15,400 Maybe there is, but in the first place software mistakes and 158 00:08:15,400 --> 00:08:17,000 trade-offs. Why do you want to publish this 159 00:08:17,000 --> 00:08:19,200 kind of book? Yeah. 160 00:08:19,200 --> 00:08:22,200 So from the beginning of my career, I've started this thing 161 00:08:22,200 --> 00:08:25,200 that software engineering involves a lot of decisions, and 162 00:08:25,200 --> 00:08:27,000 the decision has some trade-offs. 163 00:08:27,000 --> 00:08:29,200 So we have pros and cons and so on. 164 00:08:29,300 --> 00:08:32,299 It's not like, one decision is always better than the other. 165 00:08:32,500 --> 00:08:35,700 But of course, you can have more than two options as 166 00:08:35,700 --> 00:08:38,400 possibilities. When I was involved in this 167 00:08:38,400 --> 00:08:41,700 variety of systems, in some business, strictly e-commerce 168 00:08:41,700 --> 00:08:45,300 systems, be data, streaming processing us on the team 169 00:08:45,300 --> 00:08:47,200 tackle. A lot of those decisions and 170 00:08:47,200 --> 00:08:50,200 trade-offs are different levels. So the solutions are the 171 00:08:50,200 --> 00:08:53,800 low-level, like, code patterns. That's, every supplier engine is 172 00:08:53,800 --> 00:08:57,600 to make them almost every day, but also more architecture. 173 00:08:57,900 --> 00:09:00,800 Just that you can like discuss with your team which screened or 174 00:09:00,800 --> 00:09:04,200 h 2 weeks or even more high-level positions that will 175 00:09:04,200 --> 00:09:06,900 influence your evolution of your software. 176 00:09:07,200 --> 00:09:11,300 Its maintenance flexibility also performance during those 177 00:09:11,300 --> 00:09:15,100 breaking points in my career. When we choose one solution over 178 00:09:15,100 --> 00:09:19,600 another I've started to writing a personal list of those 179 00:09:19,600 --> 00:09:23,500 decisions and how they end up. Like, from the time perspective. 180 00:09:23,600 --> 00:09:27,100 For example, how this decision impacted our software after one 181 00:09:27,100 --> 00:09:30,500 year after, Three years and so on because all psychic pleasure 182 00:09:30,500 --> 00:09:35,000 to remove those systems, not only during the development, but 183 00:09:35,000 --> 00:09:38,300 also made the nurse and when the system was deployed to 184 00:09:38,300 --> 00:09:41,000 production and I so actual usage of it. 185 00:09:41,200 --> 00:09:43,300 After that. I've created this list of 186 00:09:43,300 --> 00:09:46,000 decisions. It was like, 15, hold them. 187 00:09:46,000 --> 00:09:49,700 That were really important. And after some time I saw that, 188 00:09:49,700 --> 00:09:53,500 those words are quite generic, so I decided to share it with 189 00:09:53,500 --> 00:09:55,800 for the engineers Architects and so on. 190 00:09:56,000 --> 00:10:00,100 So they will not make Same mistakes and they will be aware 191 00:10:00,100 --> 00:10:03,200 of those trade-offs because sometimes you are not aware 192 00:10:03,200 --> 00:10:07,700 about trade off at the decision time, but later after year or 193 00:10:07,700 --> 00:10:11,600 two, this is costly. So maybe discussed could be a 194 00:10:11,600 --> 00:10:15,700 lady that after we will read one of my chapters of my book. 195 00:10:16,200 --> 00:10:19,500 So it's interesting that you started this from like curating 196 00:10:19,500 --> 00:10:23,200 your personal list of decisions and trade-offs in your career. 197 00:10:23,400 --> 00:10:27,200 Maybe if you can share maybe one or two, the costliest mistakes 198 00:10:27,200 --> 00:10:29,300 that you have. Senior career based on this 199 00:10:29,300 --> 00:10:30,700 list. Welcome. 200 00:10:30,700 --> 00:10:36,200 So first one and I'm touching on that in chapter 10 of my book. 201 00:10:36,400 --> 00:10:39,800 So we're building a streaming solution and we needed some kind 202 00:10:39,800 --> 00:10:43,300 of scheduling Library scheduling framework that will work 203 00:10:43,300 --> 00:10:46,300 efficiently. So we need to count like ten 204 00:10:46,300 --> 00:10:48,200 thousands of requests per second. 205 00:10:48,300 --> 00:10:51,400 At least our system has distributed was based on Hazel 206 00:10:51,400 --> 00:10:54,600 cast work. Then we picked one solution one 207 00:10:54,600 --> 00:10:57,700 Library without realizing all its trade-offs. 208 00:10:57,800 --> 00:11:01,500 We hold properly analyzing its source calls because on the one 209 00:11:01,500 --> 00:11:04,500 hand, and this library was documenting that it should work 210 00:11:04,500 --> 00:11:08,400 properly in distributed system, but in practice, in reality, it 211 00:11:08,400 --> 00:11:11,400 turns out that this problematic, if you have multiple nodes, 212 00:11:11,700 --> 00:11:14,400 there were some problems of synchronization, the domain was 213 00:11:14,400 --> 00:11:17,500 totally different and the library was not well prepared 214 00:11:17,500 --> 00:11:19,800 for that. So, this was caused to be saved 215 00:11:19,800 --> 00:11:22,000 because we needed to debug those problems. 216 00:11:22,300 --> 00:11:25,800 And then after some time, turns out that this is a lot easier to 217 00:11:25,800 --> 00:11:28,700 just implement the me. Even product. 218 00:11:28,700 --> 00:11:30,900 That provides those functionalities for arms, 219 00:11:30,900 --> 00:11:34,000 instead of using food party software, that we didn't fully 220 00:11:34,000 --> 00:11:38,000 understand and we didn't have enough influence on fixing that. 221 00:11:38,300 --> 00:11:41,900 So I think that was one of the mistakes that could be judged. 222 00:11:42,400 --> 00:11:46,200 That would be generalized to a fact that we should know the 223 00:11:46,200 --> 00:11:49,000 trading model of a libraries that we are importing. 224 00:11:49,400 --> 00:11:52,500 So for example, even if you have some long block right now, there 225 00:11:52,500 --> 00:11:55,900 is a chance to influence microservices that works using 226 00:11:55,900 --> 00:11:59,400 non-blocking Solutions can gladly Node.js and so on. 227 00:11:59,700 --> 00:12:02,200 Sometimes if you are using libraries that are not well 228 00:12:02,200 --> 00:12:06,100 suited for that reading model. You may block you on, mine dress 229 00:12:06,100 --> 00:12:08,500 processing. It made turns out that it Blocks 230 00:12:08,500 --> 00:12:10,500 Your Mind flow and impact your performance. 231 00:12:10,800 --> 00:12:13,500 So that's should be found at the design stage. 232 00:12:13,800 --> 00:12:17,100 And also, we find a way around if you have quite simple flow, 233 00:12:17,100 --> 00:12:20,100 that works in synchronous way using an awesome College 234 00:12:20,100 --> 00:12:22,000 library. Also, you should be aware about 235 00:12:22,000 --> 00:12:25,600 problems that may arise because you need to be our about 236 00:12:25,600 --> 00:12:28,600 ordering about multitrack. Being feisty. 237 00:12:28,600 --> 00:12:30,900 When you are introducing most challenging to your code. 238 00:12:31,000 --> 00:12:34,000 It means that you need to be aware of that, and it means that 239 00:12:34,000 --> 00:12:37,500 we will have additional problems or maintenance costs. 240 00:12:37,700 --> 00:12:40,600 Maybe sometimes there may be hidden, like, for example, in 241 00:12:40,600 --> 00:12:44,200 chapter 5 of this example of java streams API and using 242 00:12:44,200 --> 00:12:48,200 parallel stream of Destruction. So it hides the internal for 243 00:12:48,200 --> 00:12:50,800 between pool that is doing processing in the multitrader 244 00:12:50,800 --> 00:12:53,500 dry. So, at the first glance at the 245 00:12:53,500 --> 00:12:55,900 code, complexity level, there is no change at all. 246 00:12:56,300 --> 00:12:59,600 You are just changing strings. Method, invocation, two, 247 00:12:59,600 --> 00:13:03,400 parallel streams, but underneath you on creating goal of Triads 248 00:13:03,600 --> 00:13:06,800 and your compass multi-threaded. Now attaching, I'm not into 249 00:13:06,800 --> 00:13:10,800 chapters of my book basically, so, as a software developer, I 250 00:13:10,808 --> 00:13:14,200 know that a lot of times as a developer's, we tend to work 251 00:13:14,200 --> 00:13:16,800 based on just business requirements and you know, just 252 00:13:16,800 --> 00:13:19,900 ensuring that the functional correctness, the input produces 253 00:13:19,900 --> 00:13:22,700 the correct output. So in your opinion, right, what 254 00:13:22,700 --> 00:13:25,800 should be the attitude of developers or software engineers 255 00:13:25,800 --> 00:13:29,200 in terms of looking at? Bible Software mistakes and 256 00:13:29,200 --> 00:13:31,200 trade-offs. Is it something that they have 257 00:13:31,200 --> 00:13:33,700 to be aware since the beginning before they even write the 258 00:13:33,700 --> 00:13:37,400 software or is it like during the implementation, or like, how 259 00:13:37,400 --> 00:13:41,000 should you advice for software developers to relook at all 260 00:13:41,000 --> 00:13:43,100 these potential software mistakes and trade-offs. 261 00:13:43,900 --> 00:13:45,900 Yes. I think there are two different 262 00:13:45,900 --> 00:13:48,700 approaches to that. So, first one is when you are 263 00:13:48,700 --> 00:13:53,400 peaking at some framework library, that will shape your 264 00:13:53,400 --> 00:13:56,100 code base and influence your code base alone. 265 00:13:56,700 --> 00:13:59,900 So, for example, in the VM Ward, if you are picking spring 266 00:13:59,900 --> 00:14:03,800 framework and well if you guys are called base and will be hard 267 00:14:03,800 --> 00:14:06,300 to change it to something else in the future. 268 00:14:06,500 --> 00:14:09,900 Also, for example, if you are picking a queue solution and you 269 00:14:09,900 --> 00:14:13,200 are picking Kafka, we need to be aware about the stray dogs. 270 00:14:13,600 --> 00:14:17,300 It is favoring availability over consistency, depending on the 271 00:14:17,300 --> 00:14:21,100 settings of acknowledgements with a distributed system that 272 00:14:21,100 --> 00:14:23,400 you are integrating with, the, you need to ask the same 273 00:14:23,400 --> 00:14:27,500 questions like how to influence, consistency, availability. 274 00:14:27,700 --> 00:14:30,500 And so on. So for those situations, I think 275 00:14:30,500 --> 00:14:32,600 it's better to fry those up front. 276 00:14:32,700 --> 00:14:35,400 You can see possible to know them upfront by doing good 277 00:14:35,400 --> 00:14:38,100 research and prototyping. On the other hand. 278 00:14:38,100 --> 00:14:40,900 There are those low-level decisions, like refactoring of 279 00:14:40,900 --> 00:14:44,600 the cloud and picking a specific pattern or design in this 280 00:14:44,600 --> 00:14:46,800 situation. Maybe it's part of those to 281 00:14:46,800 --> 00:14:49,900 experiment with the code and comparing like to approach 282 00:14:49,900 --> 00:14:52,000 sighs. So maybe it's not so cozy to it. 283 00:14:52,100 --> 00:14:55,600 For example, Implement a solution using inheritance, but 284 00:14:55,600 --> 00:14:57,400 also implant. Another solution is 285 00:14:57,400 --> 00:14:59,400 incomprehensible. This is going to be one imploded 286 00:14:59,400 --> 00:15:03,200 by two engineers and then you can compare your Solutions at 287 00:15:03,200 --> 00:15:05,900 pick, the better one. So basically in the second 288 00:15:05,900 --> 00:15:08,900 scenario, the cost of experimentation is slower. 289 00:15:09,300 --> 00:15:13,000 So maybe you can postpone the decision about which one would 290 00:15:13,000 --> 00:15:16,300 you choose and in the first one is the cost is higher because 291 00:15:16,300 --> 00:15:19,400 once you have this in your applications alucard's to 292 00:15:19,400 --> 00:15:22,700 migrate some of its better to read about this educated about 293 00:15:22,700 --> 00:15:24,600 these and all those trade-offs up front. 294 00:15:25,100 --> 00:15:27,600 So maybe let's go into some of the software. 295 00:15:27,700 --> 00:15:30,700 Where mistakes and trade-offs that you covered in the book, 296 00:15:30,800 --> 00:15:34,300 let's start with the first one which is code duplication versus 297 00:15:34,400 --> 00:15:37,100 flexibility. Maybe tell us more about these 298 00:15:37,100 --> 00:15:39,100 kind of trade-offs. Like what do you mean by 299 00:15:39,200 --> 00:15:43,400 duplication forces flexibility. So I'm considering this problem 300 00:15:43,400 --> 00:15:45,400 to wise. First one is at the 301 00:15:45,400 --> 00:15:49,100 architectural level. I would focus on that firstly in 302 00:15:49,100 --> 00:15:51,800 the microservices ward or multiple Services. 303 00:15:52,100 --> 00:15:55,600 Each service is responsible for some specific Business Online. 304 00:15:55,600 --> 00:15:59,900 Ideally and contains some Self-contained functionalities. 305 00:16:00,200 --> 00:16:03,400 So if you have for example to microservices, it is often the 306 00:16:03,400 --> 00:16:07,000 case that they may share a similar code in some way like 307 00:16:07,000 --> 00:16:10,700 for example autorización set up being the token and submitting 308 00:16:10,700 --> 00:16:13,700 it or maybe some kind of validation or things like that. 309 00:16:14,100 --> 00:16:17,500 So if you have this duplication between Services the first idea, 310 00:16:17,500 --> 00:16:19,900 maybe to just remember that will unify it using. 311 00:16:19,900 --> 00:16:24,300 For example, library and use it in both Michael statuses, but it 312 00:16:24,300 --> 00:16:27,300 also has a trade-offs. So for example, if you have the 313 00:16:27,300 --> 00:16:29,200 common Code. You have the tight coupling 314 00:16:29,200 --> 00:16:31,200 between two microservices and this Library. 315 00:16:31,500 --> 00:16:35,000 So it means that it may impact the evolution of your code base. 316 00:16:35,300 --> 00:16:38,600 Also, the fact that this code was duplicated at the beginning, 317 00:16:38,900 --> 00:16:41,400 doesn't mean that it was the same functionality. 318 00:16:41,600 --> 00:16:45,600 Maybe they needed to evolve in a different way in that situation, 319 00:16:45,600 --> 00:16:49,000 really hard to evolve it because you will have some obstruction 320 00:16:49,000 --> 00:16:52,500 that is not fitting properly. All these cases, you will need 321 00:16:52,500 --> 00:16:56,600 to add additional content to the library development and so on 322 00:16:56,800 --> 00:16:59,900 and suddenly, I've applied coupling and also flexibility of 323 00:16:59,900 --> 00:17:03,100 your software is lower. So you are not able to deliver 324 00:17:03,100 --> 00:17:06,400 your software as quick as possible or the solution would 325 00:17:06,400 --> 00:17:09,300 be to just extract this new functionality to order 326 00:17:09,300 --> 00:17:12,000 microservice. But also it has other problems 327 00:17:12,000 --> 00:17:15,599 like additional Network request response time, additional 328 00:17:15,599 --> 00:17:19,400 latency deployment, but we need to create for this micro service 329 00:17:19,400 --> 00:17:22,099 and so on. So at this architectural level, 330 00:17:22,200 --> 00:17:24,200 sometimes sound code duplication. 331 00:17:24,200 --> 00:17:26,800 It's not blocker. For example, you have two 332 00:17:26,800 --> 00:17:30,800 components that Are doing a similar job and you slowly start 333 00:17:30,800 --> 00:17:33,500 seeing some obstruction in those two components and you are, for 334 00:17:33,500 --> 00:17:36,200 example, decide to use inheritance to reduce. 335 00:17:36,200 --> 00:17:40,500 The duplication of components solemnly are dependent on this. 336 00:17:40,500 --> 00:17:43,200 New component, got an inheritance and the same 337 00:17:43,200 --> 00:17:45,900 situation can happen here as it meant result. 338 00:17:45,900 --> 00:17:49,100 That's obstruction, doesn't fit the evolution of those two 339 00:17:49,100 --> 00:17:51,900 components. Maybe you decided to extract it 340 00:17:51,900 --> 00:17:53,900 too soon. And I'll be stages, may be 341 00:17:53,900 --> 00:17:57,000 really hard to get it back to the previous solution and of all 342 00:17:57,000 --> 00:17:59,700 those components. The palanquin, similarly, you 343 00:17:59,708 --> 00:18:03,700 will introduce tight coupling and impact, the speed of 344 00:18:03,900 --> 00:18:05,900 delivery, flexibility of your code. 345 00:18:06,600 --> 00:18:08,300 I think this is quite a common case, right? 346 00:18:08,300 --> 00:18:11,300 Whereas the software Engineers. We are also kind of like hot. 347 00:18:11,400 --> 00:18:13,200 So you have to remove duplication. 348 00:18:13,200 --> 00:18:15,500 Don't repeat yourself dry principle. 349 00:18:15,600 --> 00:18:18,400 Also, like, when you see things over the internet, you have so 350 00:18:18,400 --> 00:18:21,300 many open source project their basic creating libraries 351 00:18:21,300 --> 00:18:24,400 Frameworks and reusable components and things like that. 352 00:18:24,600 --> 00:18:27,300 So we are kind of like hot in a way that okay. 353 00:18:27,600 --> 00:18:31,200 Location might not be a good idea and also reuse abilities or 354 00:18:31,200 --> 00:18:33,400 important. So in the first place when we 355 00:18:33,400 --> 00:18:36,500 are tackling a particular problem, what is your advice for 356 00:18:36,500 --> 00:18:39,200 software engineer to actually be look at this perspective. 357 00:18:39,400 --> 00:18:42,800 Should you start with just a simple implementation first and 358 00:18:42,800 --> 00:18:45,200 over the time, you'll see some kind of abstraction that could 359 00:18:45,200 --> 00:18:48,000 be built around that or you should start seeing the 360 00:18:48,000 --> 00:18:50,500 obstruction in the beginning based on the particular context 361 00:18:50,500 --> 00:18:52,600 that you know, like, what's your approach here? 362 00:18:53,500 --> 00:18:56,000 That I think the same solution is the second one. 363 00:18:56,000 --> 00:18:57,500 I don't. Why not starting from the 364 00:18:57,500 --> 00:19:01,600 abstraction but why some time until this will settle out. 365 00:19:01,900 --> 00:19:05,200 So if you have a couple of components and they were leaving 366 00:19:05,200 --> 00:19:08,100 for some time, so we are quite stable state. 367 00:19:08,100 --> 00:19:10,300 So it's not a frequent ablution place. 368 00:19:10,400 --> 00:19:13,900 If you see some extraction, then it's a good time to extract it 369 00:19:14,100 --> 00:19:16,600 at the beginning. You may be doing that too soon 370 00:19:16,700 --> 00:19:20,600 and it may be hard to unwind that, but there's also this 371 00:19:20,600 --> 00:19:23,700 argument that if you don't start earlier, where you You can reuse 372 00:19:23,700 --> 00:19:26,300 some of these stuffs. It can also be costly in the 373 00:19:26,300 --> 00:19:29,700 future where you have to tweet your existing software refactor, 374 00:19:29,700 --> 00:19:32,200 it in order to make it more reasonable generic, and things 375 00:19:32,200 --> 00:19:35,400 like that. So any fog around this, there is 376 00:19:35,400 --> 00:19:38,400 no simple answers here. Also, if you will go to the 377 00:19:38,400 --> 00:19:40,400 extreme, your code will not be good. 378 00:19:40,600 --> 00:19:43,800 But yeah, I think it also comes to a fact that you need to have 379 00:19:43,800 --> 00:19:46,000 a good test coverage of your components. 380 00:19:46,000 --> 00:19:49,500 So this is not an excuse to not create good quality code, also 381 00:19:49,500 --> 00:19:53,800 need to have one that stood component if Our what the status 382 00:19:53,800 --> 00:19:56,800 is, of course, easier to refactor, but there are some 383 00:19:56,800 --> 00:20:00,200 functionalities that you can be sure that they will be reused. 384 00:20:00,300 --> 00:20:03,400 For example, some simple string manipulation, like what you have 385 00:20:03,400 --> 00:20:07,300 in standard as the case, some connection to Excel on systems 386 00:20:07,300 --> 00:20:11,600 and so on Coop, so let's move on to the next trade-offs, which is 387 00:20:11,600 --> 00:20:15,300 what you call premature optimization versus optimizing 388 00:20:15,400 --> 00:20:17,600 hot path. May be the first term. 389 00:20:17,600 --> 00:20:19,300 Almost all Engineers will be familiar. 390 00:20:19,300 --> 00:20:21,900 With premature optimization is the root of all evil. 391 00:20:22,000 --> 00:20:24,000 They all say, The second term here. 392 00:20:24,000 --> 00:20:26,300 Optimizing Hot Pot. What do you mean by that? 393 00:20:27,200 --> 00:20:30,500 So in chapter 5, I will propose in your cream work. 394 00:20:30,600 --> 00:20:33,800 If you have code, that you don't want to prevent to optimize how 395 00:20:33,800 --> 00:20:37,800 to make it an early optimization or just in time optimization how 396 00:20:37,800 --> 00:20:40,400 to have enough data to optimize it. 397 00:20:40,700 --> 00:20:43,000 So we need to have two things at all. 398 00:20:43,000 --> 00:20:46,000 Lakewood decision, which code values to optimize. 399 00:20:46,300 --> 00:20:48,800 So the first one is number of requests per s. 400 00:20:48,800 --> 00:20:52,300 Also expected to both on your path so assume that we have two 401 00:20:52,300 --> 00:20:55,000 endpoints. Let's say 1 and point is only 402 00:20:55,000 --> 00:20:57,400 one request per second. And second one is only done 403 00:20:57,400 --> 00:21:01,000 because per second. So having that data, you might 404 00:21:01,000 --> 00:21:03,200 be tempted to just go and optimize. 405 00:21:03,200 --> 00:21:05,600 The centrepointe block is executed 10 times per second, 406 00:21:05,900 --> 00:21:09,000 but it is not enough because we need to have latency data. 407 00:21:09,200 --> 00:21:12,300 So once we have data about latency, for example, you can 408 00:21:12,300 --> 00:21:15,400 get average latency for the first opponent s 1. 409 00:21:15,800 --> 00:21:19,700 Then you can multiply a number of requests and average latency 410 00:21:20,100 --> 00:21:22,700 and have a distribution of overall Legend. 411 00:21:22,900 --> 00:21:25,500 She overdosed to and phones having the data. 412 00:21:25,800 --> 00:21:28,000 You can detect the power of that is executed. 413 00:21:28,000 --> 00:21:30,300 Most open. I'm calling it hot bath. 414 00:21:30,600 --> 00:21:34,100 It means that it is executed almost for every user requests 415 00:21:34,400 --> 00:21:37,300 in a system. So that was working with, it was 416 00:21:37,300 --> 00:21:39,900 very often, the case that they were following this Peridot 417 00:21:39,900 --> 00:21:44,000 principal distribution. So for example, like 80% of 418 00:21:44,100 --> 00:21:49,000 value was delivered by 20% of the code or it was ten ninety. 419 00:21:49,200 --> 00:21:52,600 Thirty seventy and so on. And it means basically, that's 420 00:21:52,600 --> 00:21:53,400 it. Focus. 421 00:21:53,400 --> 00:21:56,800 Your optimization efforts on the smaller part of the code you 422 00:21:56,800 --> 00:22:00,100 will gain a lot of benefits. So I'm proposing, there is how 423 00:22:00,100 --> 00:22:03,900 to detect this hot tough. So the smaller part of code that 424 00:22:04,000 --> 00:22:08,600 optimizing will result in future benefits and how to make this 425 00:22:08,600 --> 00:22:10,800 decision. So, we are basic, you need to 426 00:22:10,800 --> 00:22:13,400 have this requests per second smash of latency. 427 00:22:13,700 --> 00:22:17,700 When we have the data you can detect hot puff and dig deeper 428 00:22:17,700 --> 00:22:20,200 in your code. So you can go to the specific 429 00:22:20,200 --> 00:22:22,700 parts of this hot bath and measure each of those. 430 00:22:22,900 --> 00:22:26,000 Those parts and then you can focus on optimization efforts on 431 00:22:26,000 --> 00:22:29,900 specific thing. It is basically a way to limit 432 00:22:29,900 --> 00:22:33,800 the scope of your work because in production systems, it is not 433 00:22:33,800 --> 00:22:36,900 possible to optimize every possible path. 434 00:22:37,400 --> 00:22:40,600 If you detect the whole class, we will can make a rational 435 00:22:40,600 --> 00:22:43,700 decision. It is a place where you can do 436 00:22:43,700 --> 00:22:47,600 some additional efforts and they will readily be worthy. 437 00:22:47,800 --> 00:22:49,500 After optimizing. The whole path is going to 438 00:22:49,508 --> 00:22:52,800 result that you will reduce latency so much that it is not 439 00:22:53,200 --> 00:22:57,000 Responsible for the most of the overall utilization on your 440 00:22:57,000 --> 00:23:01,300 system, but it may also turns out that still optimizing this 441 00:23:01,300 --> 00:23:05,300 hot path will give you better benefits than optimizing other 442 00:23:05,300 --> 00:23:08,600 groups in your course evenly, for example this first endpoint 443 00:23:08,600 --> 00:23:12,000 that was one request per second average latency is for example, 444 00:23:12,100 --> 00:23:16,500 500 milliseconds and the hot pipe is even 50 or 10. 445 00:23:16,800 --> 00:23:19,700 If you multiply that with this number of requests, we have the 446 00:23:19,700 --> 00:23:22,700 full context and make turns out that series 1. 447 00:23:22,900 --> 00:23:25,600 Optimizing. Maybe a little bit of recap. 448 00:23:25,600 --> 00:23:28,300 So yeah, you should know the true put of your system requests 449 00:23:28,300 --> 00:23:32,300 per second and also the latency of each of that request. 450 00:23:32,400 --> 00:23:34,900 And then you multiply it, get a sense of distribution. 451 00:23:34,900 --> 00:23:37,100 Right? What's your P95, maybe your 452 00:23:37,100 --> 00:23:40,400 average your maximum and things like that, maybe a little bit of 453 00:23:40,400 --> 00:23:42,900 tips here, because sometimes Engineers when they write 454 00:23:42,900 --> 00:23:45,500 software, I don't think they have this in mind in the first 455 00:23:45,500 --> 00:23:48,100 place, what kind of tools or what kind of techniques that 456 00:23:48,100 --> 00:23:51,100 they should introduce to their software in order to get all 457 00:23:51,100 --> 00:23:54,600 these numbers easily. If you have system have defined 458 00:23:54,600 --> 00:23:58,200 as alive, so if there is a, some kind of a nice light should stay 459 00:23:58,300 --> 00:24:02,300 at or system should be able to accept some requests per second 460 00:24:02,300 --> 00:24:06,000 within specified like like and see if you don't have this data, 461 00:24:06,100 --> 00:24:10,100 then you'll need to measure it somehow to get latency. 462 00:24:10,200 --> 00:24:14,400 You should write benchmarks that will validate your application. 463 00:24:14,500 --> 00:24:18,200 So you can, for example, use got linked to WR K tool. 464 00:24:18,200 --> 00:24:22,100 There's a lot of stomach acid also has its own testing, three 465 00:24:22,100 --> 00:24:24,200 morgue. You can, of course, use it to 466 00:24:24,300 --> 00:24:27,500 extract the latency, but there are a number of requests per 467 00:24:27,500 --> 00:24:30,900 second in it to help from us alike or from some product 468 00:24:30,900 --> 00:24:33,000 information. Maybe what kind of traffic are 469 00:24:33,000 --> 00:24:35,800 you expected, Albert, traffic will grow over time. 470 00:24:36,000 --> 00:24:38,900 So then you can adopt your test and measure again. 471 00:24:39,800 --> 00:24:42,400 So sometimes also I think these days people, classify these 472 00:24:42,400 --> 00:24:46,300 things as observability, right? So having good monitoring or 473 00:24:46,300 --> 00:24:49,000 Matrix, as part of your software, maybe instrument your 474 00:24:49,000 --> 00:24:51,300 code base to that you can get this data easily. 475 00:24:51,400 --> 00:24:53,700 Maybe even a profiler. Some tools these days. 476 00:24:53,800 --> 00:24:56,400 They can embed instrumentation code inside your code, so that 477 00:24:56,400 --> 00:24:58,600 you can get this providing statistics easily. 478 00:24:58,900 --> 00:25:02,200 So, thanks for highlighting this importance, about optimizing, 479 00:25:02,200 --> 00:25:04,300 Hot Pot. Let's move on to the next one, 480 00:25:04,300 --> 00:25:07,900 which is what you mention about data, locality and memory. 481 00:25:08,100 --> 00:25:10,200 Maybe can share a little bit more about this. 482 00:25:10,900 --> 00:25:14,600 That's also in the Big Data Systems, but also all the data 483 00:25:14,600 --> 00:25:17,500 intensive systems. There is an important 484 00:25:17,500 --> 00:25:19,800 optimization that you should make. 485 00:25:20,000 --> 00:25:22,500 And all those recent remarks are doing those. 486 00:25:22,700 --> 00:25:26,300 Optimizations. But also the impact the way how 487 00:25:26,300 --> 00:25:29,200 the system's Big Data remorse on spark. 488 00:25:29,200 --> 00:25:33,100 How do a song are built and some complexities in them. 489 00:25:33,600 --> 00:25:37,100 If someone is new to a big data, ecosystem may think that those 490 00:25:37,100 --> 00:25:41,900 complexities are unnecessary or easily hard to enter point is 491 00:25:41,900 --> 00:25:44,100 high. But they do quality means that 492 00:25:44,100 --> 00:25:46,500 you are moving your computations to data. 493 00:25:46,800 --> 00:25:48,400 And not they got two computations. 494 00:25:48,700 --> 00:25:51,100 What does it mean? So, in Luxor example, if you 495 00:25:51,100 --> 00:25:54,500 have your data saved, almost People notes like a dog knows, 496 00:25:54,500 --> 00:25:56,900 five sister knows even database nodes. 497 00:25:57,200 --> 00:26:00,200 If you have some big data processing or processing 498 00:26:00,200 --> 00:26:04,400 ecology, like for example find the average of some value and 499 00:26:04,400 --> 00:26:06,200 your processing is on different nodes. 500 00:26:06,400 --> 00:26:10,000 Then you are not fetching the data from the nodes or perform 501 00:26:10,100 --> 00:26:14,100 operations on the computation node, but you are serializing 502 00:26:14,100 --> 00:26:17,900 the computations and sending them to the data nodes as 503 00:26:17,900 --> 00:26:21,400 sending computations is fast, because they will not take a lot 504 00:26:21,400 --> 00:26:24,600 of data this way. Basically sterilizing your Java 505 00:26:24,600 --> 00:26:29,100 Scala or other language program into binary format, sending it 506 00:26:29,100 --> 00:26:32,500 over the wire to the data nodes on the diagonals. 507 00:26:32,500 --> 00:26:36,000 Also, some kind of an Executor has to be running to the 508 00:26:36,000 --> 00:26:40,500 sterilize, the computation and apply it to the data that is on 509 00:26:40,500 --> 00:26:43,000 the local node. It can be done in a distributed 510 00:26:43,000 --> 00:26:44,800 way. So multiple data nodes. 511 00:26:45,000 --> 00:26:48,800 Each of those is processing part of the data and then there's 512 00:26:48,800 --> 00:26:52,500 another place of coalescing, the result is sometimes display. 513 00:26:52,800 --> 00:26:56,700 Involves sending data because for example, it depends on the 514 00:26:56,700 --> 00:26:58,800 partition or partitioning scheme. 515 00:26:59,100 --> 00:27:02,400 Sometimes you need to send some data, but the amount of data we 516 00:27:02,400 --> 00:27:04,700 usually will be substantially reduced. 517 00:27:04,800 --> 00:27:08,300 If you do it from the beginning, send the data at the beginning. 518 00:27:08,500 --> 00:27:12,500 That's basically as the simplest description of data locality, 519 00:27:12,800 --> 00:27:16,200 but implementation of it is provided within those 520 00:27:16,200 --> 00:27:19,800 distributed systems, and I'm focusing on Apache spark because 521 00:27:19,800 --> 00:27:22,500 it's a recent technology that is available planet. 522 00:27:22,600 --> 00:27:26,600 It's over the old how to based Technologies, mainly because it 523 00:27:26,600 --> 00:27:29,800 does a lot of processing in around not on the disk. 524 00:27:30,000 --> 00:27:33,300 The good example of data locality could be using the join 525 00:27:33,300 --> 00:27:36,100 operation. So if you are joining data sets 526 00:27:36,400 --> 00:27:39,900 and we have one big data set and second maybe smaller ones, for 527 00:27:39,900 --> 00:27:44,000 example, you have a list of accounts and all purchases made 528 00:27:44,000 --> 00:27:46,300 by those accounts. So there will be a lot of 529 00:27:46,300 --> 00:27:49,600 purchases and number buttons, will be smaller, leveraging 530 00:27:49,600 --> 00:27:51,300 data. Locality also would mean that 531 00:27:51,300 --> 00:27:55,500 you are making a sign. Visions which data is sent to 532 00:27:55,500 --> 00:27:57,000 other nodes. In that case. 533 00:27:57,000 --> 00:28:00,200 We would send a smaller data set to the bigger data, set to 534 00:28:00,200 --> 00:28:04,000 reduce this network traffic impact within scope Network 535 00:28:04,000 --> 00:28:06,300 shuffling and that's one of the biggest value. 536 00:28:06,300 --> 00:28:10,400 We need to focus one writing the data processing to optimize - 537 00:28:10,400 --> 00:28:13,900 processing, but with Calculus to generalize to just normal to 538 00:28:13,900 --> 00:28:16,800 occasions, right? If you need to fetch some data, 539 00:28:17,000 --> 00:28:19,900 you need to answer the question. Maybe it's better to tell the 540 00:28:19,900 --> 00:28:23,100 system to compute that and then we only Results. 541 00:28:23,400 --> 00:28:26,700 Also, the second aspect here is partitioning that is important 542 00:28:26,900 --> 00:28:29,700 and picking the proper partitioning scheme for your 543 00:28:29,700 --> 00:28:32,200 processing. So we need to optimize your 544 00:28:32,200 --> 00:28:36,400 partitions to your patterns. For example, if you need to 545 00:28:36,400 --> 00:28:40,800 analyze data pronounce, then it will be nice if one data node 546 00:28:41,000 --> 00:28:43,000 will keep the data for the whole month. 547 00:28:43,200 --> 00:28:45,900 If that's feasible. Then you will send a computation 548 00:28:45,900 --> 00:28:48,800 to this data node and competitions will be local to 549 00:28:48,800 --> 00:28:52,500 the whole long and they could be executed in a local way. 550 00:28:52,800 --> 00:28:55,600 On the other hand, if you have data Partition by, for example, 551 00:28:55,600 --> 00:28:59,800 account ID in that case, and you need to extract data for the 552 00:28:59,800 --> 00:29:01,400 whole month. It would mean that you will need 553 00:29:01,400 --> 00:29:04,700 to scan the data from each data node, and then it involves 554 00:29:04,700 --> 00:29:07,200 Network partitions. So yeah, I'm showing couple of 555 00:29:07,200 --> 00:29:10,500 those examples in this chapter and how to basically help to 556 00:29:10,500 --> 00:29:14,500 feed this partitioning depending on the processing that you plan 557 00:29:14,500 --> 00:29:17,400 to execute. So, thanks for sharing all these 558 00:29:17,400 --> 00:29:21,200 details about how big data distributed system works because 559 00:29:21,200 --> 00:29:24,300 I think like for small kind. Data, normally people, I'm not 560 00:29:24,300 --> 00:29:27,400 really aware of such trade-offs. But yeah, it makes a lot of 561 00:29:27,400 --> 00:29:29,100 difference. If you are processing a lot of 562 00:29:29,100 --> 00:29:32,300 data and where you store the data, especially if your data 563 00:29:32,300 --> 00:29:34,800 cluster is large. So the thing that I pick up from 564 00:29:34,800 --> 00:29:37,600 your explanation, just now, instead of sending the data to 565 00:29:37,600 --> 00:29:40,200 the computation. Why not doing it the other way 566 00:29:40,200 --> 00:29:41,900 around? So you sending the computation, 567 00:29:41,900 --> 00:29:44,900 which is your coat, and you can call it the functional code, 568 00:29:45,000 --> 00:29:48,100 serialize it to Binary and then sent to the data, do some local 569 00:29:48,100 --> 00:29:51,200 processing that and just send the result back or maybe you do 570 00:29:51,200 --> 00:29:53,800 some kind of joy in and Reduce operation right. 571 00:29:53,800 --> 00:29:56,900 In terms of Hadoop Paradigm mapreduce, you basically send 572 00:29:56,900 --> 00:29:59,400 all this map operations, two different notes and then you 573 00:29:59,408 --> 00:30:02,200 reduce them and aggregate them into one possible result. 574 00:30:02,400 --> 00:30:04,500 So look at this data locality of. 575 00:30:04,500 --> 00:30:07,700 Could you also actually apply this to like micro service? 576 00:30:07,700 --> 00:30:09,600 Is that kind of architecture pattern? 577 00:30:09,800 --> 00:30:13,200 Is that something around that or is this just applicable for Big 578 00:30:13,200 --> 00:30:14,400 Data? Yeah. 579 00:30:14,400 --> 00:30:16,600 I think it's going to be also, of course applied to 580 00:30:16,600 --> 00:30:21,000 microservices Microsoft is often leads to such a lot of data from 581 00:30:21,000 --> 00:30:25,700 other services to Eight and and result for customer, or maybe 582 00:30:25,700 --> 00:30:28,700 for another microservice. If you start noticing that a 583 00:30:28,700 --> 00:30:32,600 Microsoft business to such a lot of data from multiple services 584 00:30:32,800 --> 00:30:35,800 and speech services returning, thousands of records. 585 00:30:36,100 --> 00:30:38,900 And then you are just iterating over those records. 586 00:30:39,100 --> 00:30:42,900 Filtering some subset of those circles or even coalescing into 587 00:30:42,900 --> 00:30:46,400 the one result. Maybe that's a situation when 588 00:30:46,400 --> 00:30:48,800 you put send to the second microservice. 589 00:30:48,900 --> 00:30:51,600 Just Computing this body. When the twin this one value. 590 00:30:51,900 --> 00:30:55,100 In that case, you will Reduce the traffic, the computations 591 00:30:55,100 --> 00:30:57,100 will be done on this second microservice. 592 00:30:57,300 --> 00:31:00,700 And only the result will be returned and that case you will 593 00:31:00,700 --> 00:31:04,700 save Network bandwidth. And also processing, CPU time, 594 00:31:04,700 --> 00:31:07,300 and so on. So, yeah, maybe a little bit on 595 00:31:07,300 --> 00:31:09,500 this, right? May be some kind of a Viewpoint 596 00:31:09,500 --> 00:31:12,800 because last time in traditional way, we used to have this 597 00:31:12,800 --> 00:31:16,100 database stored procedure to process database queries, and 598 00:31:16,100 --> 00:31:18,600 sure that you can actually compute on the database node, 599 00:31:18,700 --> 00:31:21,700 but over the time people move on from that strategy then actually 600 00:31:21,700 --> 00:31:23,200 put the application. Coat. 601 00:31:23,200 --> 00:31:25,000 So to speak, like a back-end API, right? 602 00:31:25,000 --> 00:31:27,400 Where you just query the data and you compute on the 603 00:31:27,400 --> 00:31:29,800 application back. And so what's your view on this? 604 00:31:30,000 --> 00:31:32,900 I think the last time we used to do it near to the data, which is 605 00:31:32,900 --> 00:31:35,600 the database itself, maybe throughout the time, because of 606 00:31:35,600 --> 00:31:38,400 scalability, because of may be other considerations. 607 00:31:38,400 --> 00:31:41,400 People are moving away, that kind of computation away from 608 00:31:41,400 --> 00:31:44,300 where the data is residing. Do you have any thoughts around 609 00:31:44,300 --> 00:31:47,000 that? Good stored procedures, hit a 610 00:31:47,008 --> 00:31:50,500 couple of problems, may be testing the stability over time 611 00:31:50,500 --> 00:31:53,300 and also, it could be very vendor-specific. 60, you are 612 00:31:53,300 --> 00:31:57,300 coupling to a specific vendor and other problems so that 613 00:31:57,300 --> 00:31:59,500 implementation of it was not ideal. 614 00:31:59,600 --> 00:32:03,200 But the under Direction, had some classes, those trade-offs. 615 00:32:03,500 --> 00:32:07,200 And so you are keeping the computations on the known as you 616 00:32:07,200 --> 00:32:08,800 mentioned. There is a trend to move, 617 00:32:08,800 --> 00:32:12,200 computations back to the data and all the data promoters are 618 00:32:12,200 --> 00:32:14,600 doing that. But they are doing that on a 619 00:32:14,600 --> 00:32:17,700 little bit higher level to provide some obstruction to note 620 00:32:17,700 --> 00:32:20,900 tied to a specific vendor. For example, when you spark, it 621 00:32:20,900 --> 00:32:25,000 doesn't matter what format They tell you have it can be a brawl 622 00:32:25,000 --> 00:32:29,500 Arquette or I system just plain text files and so on one 623 00:32:29,500 --> 00:32:33,500 Cassandra and database collector that crisis abstraction and all 624 00:32:33,500 --> 00:32:36,200 the logic is in actual programming language. 625 00:32:36,400 --> 00:32:39,100 So it's easier to test easier to maintain. 626 00:32:39,400 --> 00:32:41,300 There are some forms of these approaches. 627 00:32:41,300 --> 00:32:43,900 Of course. Yeah, looking at the distributed 628 00:32:43,900 --> 00:32:45,400 data framework. I must say that. 629 00:32:45,400 --> 00:32:48,200 It's also exciting. So I've used like Apache, beam 630 00:32:48,200 --> 00:32:50,000 data flow as well. Like spark. 631 00:32:50,200 --> 00:32:53,300 I think there are lots of Innovations around That I'm 632 00:32:53,300 --> 00:32:55,700 really glad that some people actually writing this kind of 633 00:32:55,700 --> 00:32:58,400 software, so that as an end user, so to speak software 634 00:32:58,400 --> 00:32:59,800 Engineers. They just need to understand the 635 00:32:59,800 --> 00:33:02,100 Paradigm and write the code appropriately. 636 00:33:02,300 --> 00:33:04,800 Let's move on to the next trade-offs, which is what you 637 00:33:04,800 --> 00:33:07,900 call delivery semantics in distributed systems. 638 00:33:07,900 --> 00:33:09,500 So what's the importance of delivery? 639 00:33:09,500 --> 00:33:11,300 Semantics? Or maybe in the beginning 640 00:33:11,300 --> 00:33:14,100 explain tool some of us, what is delivery semantics? 641 00:33:14,900 --> 00:33:18,200 So system that you are interacting with gives you on 642 00:33:18,200 --> 00:33:21,200 the data. It will be delivered to us, at 643 00:33:21,200 --> 00:33:22,600 least, once it could be at least. 644 00:33:22,800 --> 00:33:26,600 Once at most once or exactly, once basically, if you are 645 00:33:26,600 --> 00:33:30,700 interacting with network call or any distributed system, then 646 00:33:30,700 --> 00:33:33,900 those delivers a man things are important for you. 647 00:33:34,200 --> 00:33:37,700 Even if you have two simplest microservices and one is sending 648 00:33:37,700 --> 00:33:40,400 a request to the second one, there could be a network 649 00:33:40,400 --> 00:33:42,200 partition. For example, when the response 650 00:33:42,200 --> 00:33:45,900 get back to the first microservice, in that case, the 651 00:33:45,900 --> 00:33:48,200 second microscope is accept the data process. 652 00:33:48,200 --> 00:33:51,600 It properly may be saved to the database, but the first service 653 00:33:51,600 --> 00:33:53,200 doesn't know what. Happen. 654 00:33:53,500 --> 00:33:56,300 And in that case, you need to make a decision from the 655 00:33:56,300 --> 00:33:57,700 perspective of the first service. 656 00:33:58,000 --> 00:34:00,500 What to do, we can retry the request. 657 00:34:00,700 --> 00:34:02,700 In that case. You will have a consistent view 658 00:34:02,700 --> 00:34:05,100 of your system if the request succeeded. 659 00:34:05,200 --> 00:34:08,400 But it means that you have submitted more than one request. 660 00:34:08,699 --> 00:34:11,699 So, you may have to duplicate and this will be at least once 661 00:34:11,699 --> 00:34:14,900 you will deliver the message, but you could deliver it more 662 00:34:14,900 --> 00:34:19,400 than once, it gives a good quantities on both systems, but 663 00:34:19,400 --> 00:34:22,000 it also has some problems because the second system leads 664 00:34:22,000 --> 00:34:25,500 to be Prepare for that. So, it means that the could be 665 00:34:25,500 --> 00:34:28,400 duplicates. You can design a system to the 666 00:34:28,400 --> 00:34:30,600 item potent. So it doesn't matter. 667 00:34:30,600 --> 00:34:32,300 If you are replaying in my search. 668 00:34:32,400 --> 00:34:34,600 It will result in the same outcome. 669 00:34:34,900 --> 00:34:38,300 Like, for example, deleting the body for a specific primary key, 670 00:34:38,300 --> 00:34:40,600 maybe item portal, because it doesn't matter. 671 00:34:40,600 --> 00:34:44,500 If you lose it once or 10 times, it will be just deleted. 672 00:34:44,699 --> 00:34:47,600 But there are some operations that are harder to design them 673 00:34:47,600 --> 00:34:49,800 to be. Identical told like updating, 674 00:34:49,800 --> 00:34:52,500 for example, some counter because it will be 675 00:34:52,699 --> 00:34:55,699 Inconsistencies there. So we have at least once in that 676 00:34:55,699 --> 00:34:59,800 situation, if the customer system is not aware of this, 677 00:35:00,100 --> 00:35:03,200 those applications may result in the data. 678 00:35:03,200 --> 00:35:05,900 I'd inconsistent State. And on the other hand on the 679 00:35:05,900 --> 00:35:08,500 producer side. We might decide that in such a 680 00:35:08,500 --> 00:35:11,200 situation. You are not be trying, but it 681 00:35:11,200 --> 00:35:15,200 also has a problem because the fact that response didn't count 682 00:35:15,200 --> 00:35:18,400 to the first service. It can also mean that it wasn't 683 00:35:18,400 --> 00:35:20,900 processed at all. It was a failure in that 684 00:35:20,900 --> 00:35:22,900 situation. The first service will not We 685 00:35:22,900 --> 00:35:26,500 try and it led to a sound that the second one didn't get the 686 00:35:26,500 --> 00:35:29,500 value at all. So it was lost at most once. 687 00:35:29,500 --> 00:35:33,200 So it means that it could be delivered 20 times or one time. 688 00:35:33,200 --> 00:35:37,400 It will be no duplicates but possibility, 40 and delivery, of 689 00:35:37,400 --> 00:35:41,200 course as everyone can be aware that can have problems because 690 00:35:41,200 --> 00:35:43,500 you lost son. Had a gun in transmission. 691 00:35:43,700 --> 00:35:45,100 There are some cases of the disease. 692 00:35:45,100 --> 00:35:48,500 Also, good enough, like, for example, collecting celebrities 693 00:35:48,500 --> 00:35:51,400 that are collected every millisecond or something like 694 00:35:51,400 --> 00:35:53,700 this and if you will Lost some love them. 695 00:35:53,700 --> 00:35:55,900 It may be not problematic. Lastly. 696 00:35:55,900 --> 00:35:59,400 You can have effective exactly once because when the network is 697 00:35:59,400 --> 00:36:03,200 involved, you will need to make decision about retrying at some 698 00:36:03,200 --> 00:36:05,100 point. It'll be done even on the 699 00:36:05,100 --> 00:36:09,300 protocol level ACP layer and so on so ineffective exactly. 700 00:36:09,300 --> 00:36:12,400 Once basically you have this duplication that can use hidden 701 00:36:12,400 --> 00:36:16,000 somewhere or some kind of a transaction built into your 702 00:36:16,100 --> 00:36:18,700 system. It's hard to implement because 703 00:36:18,700 --> 00:36:22,500 some problems complexities also big performance overhead view. 704 00:36:22,700 --> 00:36:25,500 We need to build it and be aware of that. 705 00:36:25,800 --> 00:36:28,100 Also, what's important, if you have to smuggle service 706 00:36:28,100 --> 00:36:30,400 architectures, when there is multiple, Microsoft is 707 00:36:30,400 --> 00:36:33,300 connecting with each other, even if there is effective ones 708 00:36:33,300 --> 00:36:37,200 between two of them, the next one, if does not provide 709 00:36:37,200 --> 00:36:39,200 effective, exactly. Once they will be the same 710 00:36:39,200 --> 00:36:41,600 problems. So your whole pipeline needs to 711 00:36:41,600 --> 00:36:44,600 work in this way. So maybe just to recap again. 712 00:36:44,600 --> 00:36:46,700 There are three delivery semantics. 713 00:36:46,700 --> 00:36:50,500 So like at least once at most once and exactly once. 714 00:36:50,800 --> 00:36:53,900 So from my experience in my career, Most of the systems 715 00:36:53,900 --> 00:36:56,900 especially the distributed systems, they will opt for the 716 00:36:56,900 --> 00:37:00,100 at least once delivery, semantics because maybe it seems 717 00:37:00,100 --> 00:37:02,500 like it's a much cheaper to accomplish. 718 00:37:02,700 --> 00:37:05,900 And also it's less complex in terms of how to guarantee that. 719 00:37:06,000 --> 00:37:09,100 So in your point of view, is it fair to say that for most of the 720 00:37:09,100 --> 00:37:12,800 use case, we should design our system using this at least once 721 00:37:12,800 --> 00:37:13,800 delivery? Semantics. 722 00:37:14,600 --> 00:37:15,200 Yes. Yes. 723 00:37:15,200 --> 00:37:18,600 The other effects correct. We can remove the need for the 724 00:37:18,600 --> 00:37:22,100 duplication by designing our system to be item button with 725 00:37:22,100 --> 00:37:23,900 require. So I'm thinking for example, if 726 00:37:23,900 --> 00:37:27,200 because events based system which requires some thinking but 727 00:37:27,200 --> 00:37:29,700 it's feasible. So, for example, you can send 728 00:37:29,700 --> 00:37:32,300 the whole state instead of following updates. 729 00:37:32,500 --> 00:37:35,200 Like if you have the whole state, you don't need to do this 730 00:37:35,200 --> 00:37:38,600 counter updates as I mentioned, so there will be no possibility 731 00:37:38,600 --> 00:37:40,800 of making the other that inconsistent. 732 00:37:41,000 --> 00:37:44,100 So if you are designing your system to behind important, at 733 00:37:44,100 --> 00:37:46,600 least once will work in a very good way. 734 00:37:46,900 --> 00:37:49,900 Also, you can build up the duplication mechanics of. 735 00:37:49,900 --> 00:37:52,300 So, for example, each event, each message can have some 736 00:37:52,300 --> 00:37:55,100 unique Eid. It's going to be uuid and at the 737 00:37:55,100 --> 00:37:58,600 consumer side, you can keep just some kind of a table persistent 738 00:37:58,600 --> 00:38:02,900 map or you are mapping the ID to the fact if it was processed or 739 00:38:02,900 --> 00:38:06,300 not, but also it has its own problems because you might 740 00:38:06,400 --> 00:38:09,800 operate with distributed database that also lay involves 741 00:38:09,800 --> 00:38:12,700 Network partition. That's why this update of the 742 00:38:12,700 --> 00:38:16,100 fact that even most processed or not needs to be done also in an 743 00:38:16,100 --> 00:38:18,700 academic way. But yeah, I have this in my 744 00:38:18,700 --> 00:38:20,400 chopper, as well. In that case. 745 00:38:20,400 --> 00:38:22,500 You'll need to apply this modification. 746 00:38:22,600 --> 00:38:26,100 On the database itself, not supposed to say the state and to 747 00:38:26,100 --> 00:38:29,100 do some intermediate operations, but it needs to be one Atomic 748 00:38:29,100 --> 00:38:31,500 operation. For example, comparing, some 749 00:38:31,500 --> 00:38:35,100 kind of a compare and set on the database and it's nosql 750 00:38:35,100 --> 00:38:38,600 databases offers that as well. So you can Implement applicants. 751 00:38:39,200 --> 00:38:41,600 Another thing that is, commonly related to this delivery, 752 00:38:41,600 --> 00:38:45,000 semantics is when you choose your messaging cure, I think 753 00:38:45,000 --> 00:38:48,100 maybe these days, a lot of messaging queue up for, at least 754 00:38:48,100 --> 00:38:51,200 once as well, but there are some products that offer different 755 00:38:51,200 --> 00:38:53,700 delivery semantics Maybe. From your point of view, any 756 00:38:53,700 --> 00:38:56,600 kind of thought, what kind of messaging you should people are 757 00:38:56,600 --> 00:38:59,100 four or maybe some kind of technologies that people should 758 00:38:59,100 --> 00:39:00,900 be aware of, with all these different delivery. 759 00:39:00,900 --> 00:39:04,400 Semantics in this talk to, and I'm referring to Kafka, because 760 00:39:04,400 --> 00:39:08,400 I have to because experience in this technology of coral is nice 761 00:39:08,400 --> 00:39:12,000 in that way that it can allow you to configure your producer 762 00:39:12,200 --> 00:39:15,600 and consumer Behavior to work in either of those ways. 763 00:39:15,800 --> 00:39:18,900 You can have at least once at most once depending on your 764 00:39:18,900 --> 00:39:21,100 needs. So then you can tune your 765 00:39:21,100 --> 00:39:22,400 settings properly. Come. 766 00:39:22,500 --> 00:39:25,900 Offsets in the proper way and you can design your hands to and 767 00:39:25,900 --> 00:39:28,300 pipeline to work in either of those situations. 768 00:39:28,300 --> 00:39:32,200 Because she has mentioned, you can have these cases that are 769 00:39:32,200 --> 00:39:35,600 good enough with utmost words, but also some use cases when you 770 00:39:35,600 --> 00:39:39,300 have and you need at least once. So using Kafka, you can have 771 00:39:39,300 --> 00:39:42,200 both of those. It's only the matter of 772 00:39:42,200 --> 00:39:45,700 configuration and configuring Consular producers properly. 773 00:39:45,700 --> 00:39:49,000 I have this in chapter 11 of my book. 774 00:39:49,200 --> 00:39:51,800 Thanks for sharing that. So for those of you who are 775 00:39:51,800 --> 00:39:54,400 interested in, In looking into more details about delivery, 776 00:39:54,400 --> 00:39:57,700 semantics make sure you check the chapter 11 in particular 777 00:39:57,700 --> 00:40:00,900 about messaging, qubit Kafka and all the configurations that you 778 00:40:00,900 --> 00:40:03,100 can do. So, Thomas, I think it's been a 779 00:40:03,107 --> 00:40:05,200 pleasure learning from you. But all these different 780 00:40:05,200 --> 00:40:07,400 trade-offs. I'm sure as a software engineer. 781 00:40:07,400 --> 00:40:10,600 I hope we can all upscale ourselves to be aware of what 782 00:40:10,600 --> 00:40:13,300 kind of mistakes that could possibly happen and what kind of 783 00:40:13,300 --> 00:40:16,100 trade-offs that we should think in the beginning before we 784 00:40:16,100 --> 00:40:19,000 Implement something so that we don't make costly decision. 785 00:40:19,100 --> 00:40:22,500 That is quite difficult to retrofit or quite impossible. 786 00:40:22,600 --> 00:40:25,600 To actually fix sometimes because when you have the data 787 00:40:25,700 --> 00:40:28,100 actually involve, right? Sometimes of fixing data is not 788 00:40:28,100 --> 00:40:30,400 so easy. So Thomas Before I Let You Go, 789 00:40:30,400 --> 00:40:33,600 normally, I have this one last question that I always ask for 790 00:40:33,600 --> 00:40:35,500 all my guests, which is to share your tree. 791 00:40:35,500 --> 00:40:38,900 Technical leadership is done for all of us to learn maybe from 792 00:40:38,900 --> 00:40:40,500 your journey, or from your career. 793 00:40:40,700 --> 00:40:42,800 So, can you share your three technical leadership? 794 00:40:42,800 --> 00:40:47,100 Wisdom, but also the first of all bleeding, but example, if 795 00:40:47,100 --> 00:40:50,800 you want your team to enforce some specific standards, we 796 00:40:50,800 --> 00:40:53,800 should give an example. For example, if you wants to 797 00:40:53,800 --> 00:40:56,600 health good test coverage, you should also do it. 798 00:40:56,800 --> 00:40:59,600 If you want to have good description of your work also 799 00:40:59,600 --> 00:41:02,200 should do it. And all I will follow is the 800 00:41:02,200 --> 00:41:06,100 good direction, second one. So it's always ask the question, 801 00:41:06,100 --> 00:41:09,000 why? So if you are given to do 802 00:41:09,000 --> 00:41:12,600 something Implement a specific feature that will result in 803 00:41:12,600 --> 00:41:16,100 complexity. You should always be aware what. 804 00:41:16,100 --> 00:41:19,900 Value it will bring if it gives you an eval you or not. 805 00:41:20,200 --> 00:41:22,400 What's the ants to Aunt Flo of the city? 806 00:41:22,600 --> 00:41:25,000 Turn how it will impact your customers. 807 00:41:25,000 --> 00:41:28,500 And so on. So being aware of this, not only 808 00:41:28,600 --> 00:41:32,300 about the technical things, ask why we do even need to 809 00:41:32,308 --> 00:41:36,800 implement, but because every code is maintenance overhead and 810 00:41:36,800 --> 00:41:39,300 cost. So, if you are able to solve the 811 00:41:39,300 --> 00:41:42,800 problem without code at all, then it will be ideal. 812 00:41:43,200 --> 00:41:47,100 And the put one is to create a blameless culture. 813 00:41:47,300 --> 00:41:51,100 So that there is no blame of a single person if you are doing 814 00:41:51,100 --> 00:41:54,100 so blender with some error. Or failure on production. 815 00:41:54,200 --> 00:41:57,200 There are high chances that there was a problem of a process 816 00:41:57,500 --> 00:42:00,900 and not a single person. So it means that you should time 817 00:42:00,900 --> 00:42:04,500 to process fix the process to not do the same mistake in the 818 00:42:04,500 --> 00:42:06,900 future and learn from their mistakes. 819 00:42:07,100 --> 00:42:09,300 So create the some meeting discussing. 820 00:42:09,300 --> 00:42:13,000 How does it happen? And try to incorporate that in 821 00:42:13,000 --> 00:42:15,300 that new process that will not have it. 822 00:42:15,900 --> 00:42:17,300 Thanks for sharing all this wisdom. 823 00:42:17,500 --> 00:42:20,500 I find it interesting. Especially the second one always 824 00:42:20,500 --> 00:42:23,700 asks, why especially if it involves Some kind of a complex 825 00:42:23,700 --> 00:42:27,000 or a big kind of effort before you actually go down the rabbit 826 00:42:27,000 --> 00:42:29,200 hole and you realize, oh actually it's not so important 827 00:42:29,200 --> 00:42:30,600 all. That's another alternative way 828 00:42:30,600 --> 00:42:32,900 where you actually don't need to write so much code. 829 00:42:33,100 --> 00:42:36,100 So, thanks again. Thomas for people who wants to 830 00:42:36,100 --> 00:42:38,700 reach out to you or learn more about the book itself. 831 00:42:38,700 --> 00:42:40,200 When is it going to be published? 832 00:42:40,200 --> 00:42:44,900 Where can they find you online? So on LinkedIn, also Twitter, my 833 00:42:44,900 --> 00:42:49,200 Twitter handle is stomach. I'll 007, and it's also for get 834 00:42:49,200 --> 00:42:51,300 help. I will respond any questions. 835 00:42:51,300 --> 00:42:53,800 Feel free to ask. Ask them regarding bold. 836 00:42:53,800 --> 00:42:57,000 You can also join demanding slack Channel this week. 837 00:42:57,000 --> 00:43:00,200 We have book of the week and our book is book of the week. 838 00:43:00,200 --> 00:43:03,500 It means that everyone can ask any question regarding teamwork, 839 00:43:03,800 --> 00:43:06,200 and I'm answering them. That's cool. 840 00:43:06,200 --> 00:43:07,700 That's cool. So, thanks again. 841 00:43:07,700 --> 00:43:09,200 Thomas. I wish you good luck with the 842 00:43:09,200 --> 00:43:11,900 publication of the book. So looking forward for that. 843 00:43:14,500 --> 00:43:17,900 Thank you for listening to this episode and for staying right 844 00:43:17,900 --> 00:43:20,700 till the end. If you're highly enjoyed, please 845 00:43:20,700 --> 00:43:23,600 share it with your friends and colleagues who you think would 846 00:43:23,600 --> 00:43:26,300 also benefit from listening to this episode. 847 00:43:26,600 --> 00:43:29,500 And if you're new to the podcast, make sure to subscribe 848 00:43:29,500 --> 00:43:32,300 and leave me your valuable review and feedback. 849 00:43:32,500 --> 00:43:36,200 It really, really helps me a lot in order to grow these podcasts 850 00:43:36,200 --> 00:43:38,800 better. You can also find the full show 851 00:43:38,800 --> 00:43:42,200 notes of this conversation on the episode page at technically 852 00:43:42,200 --> 00:43:44,900 journal, the death. Site, including the full 853 00:43:44,900 --> 00:43:48,500 transcript, interesting quotes, and links to the resources and 854 00:43:48,500 --> 00:43:52,100 mentions from the conversation. And lastly, make sure to 855 00:43:52,100 --> 00:43:54,600 subscribe to the show's mailing list on technology. 856 00:43:54,600 --> 00:43:58,100 No, the deaf to get notified for any future episodes. 857 00:43:58,400 --> 00:44:01,100 Stay tuned for the next technique Journal episode. 858 00:44:01,200 --> 00:44:02,900 And until then. Goodbye.