ok. Can everyone hear me or I need to be louder it is ok ok. Thank you everyone for joining the session today. My name is Rishita, me and my colleague Lynn will be presenting the session today to you. So, today we are going to talk about some of the coding best practices basically clean code. So, let us start our topic. So, before moving forward this will be our agenda. We will speak a bit on what do we mean by clean code, then some of the principles on how to write clean code, what are code smells, some common code smells and ways to refactor them, good practices more on engineering practices for cleaner code, then what next for you and some resources. This will be our agenda followed by Q and A and feedback session. So, before starting on actual content let me just clarify and set the expectation. So, we assume that most of the audience here are developers and a newbie developer and we assume that you have a basic understanding of object oriented programming. So, moving forward in the slides when I use the term classes, objects, methods you understand what that means and we would not go into too much of details into that. However, if you are a newbie and you find it difficult to absorb so many information in one hour, feel relaxed, we will be sharing the resources with you and you can explore more at your own pace later. So, that is our intent for this session and if you are an experienced developer you will find it as a maybe quick refresher for the clean code practices. So, and this is a very huge topic, it is difficult to cover it in one hour. Let us start. So, on a lighter note, how many of you can relate to this?  So, this is a very common thing which usually happens. So, when you write the code in real business project we work in a team and the business requirements change very often. So, when you write a piece of code it is working fine that is good enough, that is not good enough, it is working beautifully it is ok, but there will be other team members who are going to touch that part of code and if they do not understand it over time it will become messy and over a period of time it will become so messy that the whole team productivity will just fall down. So, that is the reason we as a developers it is our responsibility to have clean code. Starting with some of the codes here it is not enough for code to work and by Robert C Martin and from Martin Fuller any fool can write code that computer can understand, good programmers write code that humans can understand. The reason I already explained because your team members need to understand the code which you write for to make it maintainable. Now, writing coding software like writing coding is a two step process. First step is to make it work that is the most important step. Once you have it working the next step is to clean it up. So, in real business projects usually what happens the developers tend to forget about the step 2 which leads to a messy code. So, that is why we all are here like there is a step to always remind yourself when your code is actually working now there is a step 2 to clean it up. So, let us see what do we mean by clean code. Now there is no such formal definition of a clean code, but these are some of the maybe like characteristic of clean code and these have come from what most of the pioneers in our software industries say about clean code. So, it is easy to read simple and clear small and obvious code covered by test it when you read through the code you feel like it is a well written prose it is easy to deliver new feature it is hard for bugs to hide written you feel like it is written by someone who cares and it has minimal dependency. So, the definition can vary from person to person, but you can consider these like main characteristic of clean code. Next, so how do we write clean code? Now, writing a clean code is an art and there are lot of principle techniques guidelines which helps you to achieve writing a clean code and today we are going to discuss mostly these four sections and the good part is the principles which we will be discussing our language agnostic. So, any language you might be working it is applicable to all of them and today's session these four I will be covering we came up with these four because we feel these are the most important and the most basic to follow ones to follow. So, let us start with our first thing the naming convention. Now, even though it may sound very trivial very easy, but this is something which is highly abused and just having a descriptive name improves readability a lot and saves a lot of effort for the developers because of the name itself is descriptive enough sometimes the developers might not go to in like if we have a function the name clearly reveals the intention no need to go inside the working logic to understand it that saves a lot of time because usually we will have a huge code with complex functionalities. So, let us say for example, we will be having lot of examples in the later slides and one more thing to highlight is it is these guidelines and principles are not casted in stone. So, everything has a trade off do what is best for your team or what makes your code readable the end goal is to have it clear and simple. So, always remember clarity is king. So, it is not that if it is written like do not do this do not do that you have to follow it what is best for your team what best best for your current structure of code you need to do that to make it to keep it clear and simple. So, let us start with our first convention always provide descriptive names and use intention revealing name. So, for example you can yourself identify which one would you prefer is int d and then writing a comment is that better to read or just elapsed time in days it is very obvious from here that the second one is much more cleaner and readable and other thing to highlight here the moment you feel like you need to comment it is it is an alarm that something is wrong the name is not descriptive enough that you are going to add a comment for it. The next one is like avoid temporal names like example a 1 a 2 these are not concerned because it does not reveal the intention of what do you want to do with it. Then avoid noisy words sometimes like you have a user array or a user table adding that array or table in the end does not adds any extra information or any value for the reader it makes it just more worthy. The next one is be consistent for example for doing the same thing there can be many words like fetch retrieve get now you want to fetch something from the API. So, have a be consistent in all your classes if you are fetching API then use fetch it should not be like some classes fetch some classes retrieve be consistent another example can be like some people in your team are using handle click in some classes some classes on click we should avoid that have a standard naming convention and be consistent with the names you follow. Another thing is again an example use pronunciable names from the code example itself you can identify obviously the second one is more readable and more understandable. So, even though you can like assume like MDH MS may be minute days hour something like that, but when you just read three lines of code you see that how much difference it can make and imagine if it is a very huge complex code having a proper name how much different it can bring and how much efforts it can save. Then avoid abbreviations for example the first one is not very clear now let us say here you have M underscore DSC what say you have P underscore DSC or L underscore DSC you yourself will have to keep track what does that mean. However, if the names are very clear you your mind does not need to keep track of all the variables and you can easily follow along. The next one is you name your classes differently and methods differently why because the classes and objects are basically designated by nouns the good example can be like it can be invoice product user these names are like good names for classes the methods must be designated by verbs why because the sole purpose of the functions or the methods are to do something we know that we write functions to do something. So, what they do their intention should reveal in their name for example, send proposal it is very clear pay taxes if I name a function proposal then you might not know ok what this function does you will go inside the function check what it does if you name this function as proposal or let us think about send proposal to be approved this name also is not very accurate why because the function might be like I am sending the proposal for getting the approval it might get rejected also there are 2 cases approved or rejected, but the name says to be approved it is a bit vague not very clearly identifying what the function will be doing. Next we will be ok that was all for the naming convention and stating again that is not an exhaustive list there are lot many guidelines and rules, but since we have 1 hour session we try to pick only the important ones what we felt was more important. The another topic we will be discussing is object and data structure. Now towards writing cleaning code this is also one step you should clearly understand the difference between your objects and data structure when should you use object when should you use data structures. Now objects are something like they hide their data behind like abstract their data and only expose their functions and the sole purpose of data structure should be to expose the data while it should not have any meaningful names. I will show the example of an object and data structure usually in the code we see what happens is when the developer is confused and they mix up. So, some structures are half object and half data structure it makes it very difficult to add new changes later. So, it is not a clean code when you mix the data structure and object together. So, the rule is always hide the internal structure of your object we should be telling it to do something and not exposing the internal implementation of it and for that reason be always mindful when to add getter and setter. So, usually developers might be adding getter and setter for every of the variable which is not a good practice and there are some data structure like data transformation objects and active recalls and the sole purpose for them is to communicate with the databases to pick up the raw data transform it and expose it to the code for being used in other classes. So, we should avoid adding any logic to the our DTOs and active recalls to have a more proper understanding. So, now here you see the first one is the data structure why because it is not exposing any behavior it is exposing only its data it does not have any behavior only data and on the other side is an object. So, you see the data is like the private variables it is not exposed outside what is it is exposing is its function it only is exposing its behavior while the data it is working on it is completely hidden. So, this is an example what is your object and how this side is the data structure and when you have a data structure do not add any business logic to it this is like what clean code says to have a cleaner code and now to achieve this like hiding internal structure of your object there is a principle called the law of demitter or the principle of least knowledge. So, what this principle says is a method of a class C should only call the method of class C in object created by F or an object passed as an argument argument or an object held in the instance variable of C which the meaning in very simple terms would be talk to your friends not to strangers and talk to only your close units. So, in the diagram also you can see a communication between A and C is discouraged the diagram like it violates the law of demitter. In terms of example, if you see the red block here the CT XT context is an object. Now, I mentioned the to have a cleaner code we want our object to hide its implementation details, but here you see there is lot of dependency and there is lot of information we are exposing. However, let us say CT XT the context is a data structure. Now, the sole purpose of data structure to is to expose its data. So, if it is something like that that is ok because its purpose is to expose the data that is fine, but if it is an object following this coding style is not a good one and it will be it will lead to messy code later on. So, let us think how should be the good thing. So, let us say the requirement is we want to create a new file and for that we want to get the absolute path and here I am not showing you the complete code the idea is just to expose the thought process behind this. So, now if say we want to achieve it one way is to think is ok get the absolute path and then do something and create file or we can have something like this. Now, obviously the next one is much more cleaner because it is not exposing anything it is it is hiding all its implementation detail. So, it always depends on the requirement and what do you want to achieve mostly how do you design your code maybe. So, if you always want to hide the internal implementation for an object this was about data structure let us move on to classes now.  So, what clean code if you want to achieve cleaner code the classes should be small the classes should be responsible for doing one thing and that can be achieved through single responsibility principle. Things that change together should be placed together and unrelated things should be kept separate. So, classes should maintain cohesion the classes we write should be prepared to allow changes because changes inevitable. So, some principle which help you achieve that is if you follow open close principle and we want our classes to be isolated from change the principle that helps us to achieve that is dependency inversion principle we will be looking at these principles with some example, but why do we want our classes to be small and organized. So, what do you prefer you would like to have organized tool boxes with small drawers with well defined components or do you want few drawers with everything tossed into it which one will you prefer. Obviously the first one right it will be easy to manage when we have the small drawers with well defined components. So, the idea behind organizing our class is to keep the classes small and organized. So, let us see the first principle which is single responsibility principle. So, we say that classes should have one responsibility and look at the picture which one would you prefer the first one is a big class doing too many things the or this the below one which is each class has its defined responsibility and each one is doing its own work not dependent on others. Let us say if I want to change the cooking structure cooking instructions. Obviously making any change in the above diagram will impact the other works because the same entity is doing all the task. In the second diagram what if I want to change the cooking instruction I just need to bother the last one who is cooking the other classes can continue doing its job no impact on others. So, like this is what in the picture form we want to achieve we want small organized class and for that we have single responsibility principle which says that every class should be responsible only for one thing there should be only one reason to change that thing. Another thing you can think of is if you cannot come up with a concise name for your class then something is wrong. Let us say in the name if you have some if and or it is a clear indication that your class is doing more than one thing or if your class name is something like manager processor super it is also a clear indication that your class is doing more than one thing. So, let us see what do you think about this class now this class I have just taken a snippet this is only half of it there are lot more up and there were lot more functions up and down. So, if you encounter this kind of class you can think what how difficult it is to make any change or any amendment here. So, usually this kind of class is referred to as a god class which is like doing all the things doing everything. So, we we do not want this kind of code this one of classes in our code and what we can do for this if you encounter this big class the first step should be extract out smaller classes from it. So, from this you can see the the three I can easily identify that get project first project get last project this is it is it can be extracted out into the smaller class and this has lot of scope into extracting into smaller class. So, whenever you have like this big class that is that is a alarm that ok something is wrong you should not have this big class. Moving on to the next thing is maintain cohesion. So, we see that our classes we write should maintain cohesion to keep it small. Now, what do we mean by cohesion now this is an example of a class here we have two variables and three methods. If you see the three of the methods are highly dependent on those variables. So, these two methods are using all the two variables the first method is using one of the variable. So, here we see that the methods and the variables are highly co-dependent. So, this is a example of highly cohesive class let us say another example of less cohesive class let us say you have four variables and two methods. So, the green variables are being used in the green method the orange one are you being used in the orange method. However, the green one has nothing to do with the orange variables. So, this one is less cohesive and this one is in clear indication that there is a scope of breaking it into two separate smaller classes because this is less cohesive. So, when you try to maintain cohesion you will end up having many smaller classes and that is the intent of clear code clean code. Now, when we write our classes we need to be prepared for change because change is inevitable. Now, let us see an example if we have a class something like this SQL which have certain behaviors if we know that this class is going to be changed very frequently. How do we ensure that when we add new features here the existing features do not get impacted and if this class is a very volatile one we need too many changes very frequent changes we need to do something about it to every time ensure that the existing functionality did not break. So, how do we ensure that? So, there is a principle called open close principle which states that the classes should be open for extension but closed for modification. So, what it means is we organize our classes or write a code in such a way that when we add new behaviors we can easily extend it, but we should not be touching the existing code. So, let me explain it with a diagram view if we organize the same classes in this way. So, what we did was we just in introduced an abstract method and then each of the functionalities have is created as its own class. Now, this gives us flexibility in future we want to add new items we can just add the new classes without really touching the existing ones. So, we are very sure that we did not touch the existing classes the there will be no breaking in the existing functionalities and we can easily integrate our new behaviors. So, this is one way of ensuring that the existing functionalities do not break and this also leads to many smaller classes. And moving on to the next one how do we isolate our classes from changes? So, we do not want our classes to be rigid we want it to be flexible. So, how there is a principle called dependency inversion principle. So, the one you see here we have a class A which is depending on the concrete implementation of class B. We do not want that because every time there is a change in B it will impact the A because it is directly dependent. Now, what do we do to isolate the changes of B from A? So, we can introduce an abstract layer by introducing an interface. So, the flexible the green diagram we you see we do not directly depend on the concrete implementation of class B instead we are depending on the abstract implementation. So, now any change in class B will not impact class A even though they are dependent. So, let us see an example let us say we have a portfolio class and that depends on stock exchange. So, now if the stock exchange keep changing our portfolio also keeps changing. So, how can we avoid that? So, following the dependency inversion principle what we can do is we can introduce an abstract layer. So, instead of a concrete stock exchange class we create an interface and that whichever functionality wants to implement we can extend it and pass it as a constructor or constructor or something and this is how we avoid the direct dependency on concrete implementation. Now the portfolio class depends on the abstraction of stock exchange and any change in stock or let us say you are writing a test you can easily write a test for portfolio because now the stock exchange you are not directly depending on the current price. You can just mimic the current price in your test and that is how your class is completely isolated from stock exchange concrete implementation. Now this slide we have because we decided when we are talking about clean code and not talking about test it is incomplete to bring up test. However, this is like just scratching on the surface it is a very huge topic, but we just wanted to ensure that we introduce this to you. So, now test code is as important as production code. Usually we tend to ignore the test and do not clean our test, but it is as important to clean our test as much as we clean our production code. So, why should we do that is because test gives you the actual confidence to make changes to your production code. If your tests are not clean eventually the test will rot and so will your production code. So, it is very important to keep your tests clean. Some of the like rules for having a clean test is following the first rules that is fast, independent, repeatable, self validating and timely. So, what this says is your test should be fast, it should run very quickly. The reason for this is if imagine your tests are running very slow and the developers need to run the test every time they make some changes. If it is running very slow they will be very demotivated it to run very frequently. So, for that reason we want it to be fast independent means the test should not depend on each other, repeatable in any environment for example, QA or staging the same set of test can be repeated. Self validating that means it should have a Boolean output like either pass or fail no other manual interpretation of the results or something. Timely like we should be following TDD it should always be written before writing the production code. Now some of the things here are already taken care by the latest test frameworks, but as a developer like when we write test it is our responsibility to keep it clean like single concept per test. We should not write test with like too many assertions in that for example, if you want to write a test for approving something and notifying something. So, your test should not be should approve and notify. If you have something to test like that it should be should approve should be in one test and the notification feature be tested in another test. So, basically your test also needs to be clean. Consider your test give your test the same weightage as you give to your production code. Now next we will be covering some of the code smell and for that I will pass on to Lin to continue on the code smell topic. Thank you. How is everyone doing? Stay can come with the other session. We have a few chairs here also like if you guys want to be move along or like there's some empty spaces here also before we start. Yeah, there's some few chairs behind also. Okay, are we good? Shall we start? Okay, what is code smell? So, literally they don't smell but definitely they can stink. So, let's talk about what are the code smells. So, the code smells means that there is any symptom in our source code. Probably they are indicating about that there's a deeper problem. They are not technically they are not a bugs. They are not technically incorrect or they are do any prevention from program for functioning but they are usually like weakness in design and implementation choice that could hinder for us to be further development and also maintenance also very hard to evolve our code and also as a result it could also increase the risk of some failure and a defect also. So, bad code smell could be also an indicator of the factor that contributed the technique at that because of the poor quality of the code is written. So, if you have a if you want to change a some code in a one place right, you have to change in many places and other places too. That means that we have a code smell and usually even those we learn about all those clean code and all that technique and the principle right because we are working on the very tight line or like there's no good engineering practice or sometimes like we don't have like you know good code review or like we missed some code review. This code smell could not be inevitable. So, determining what or what is not a code smell is very subjective. So, it can be very by the like language and the global and a methodology also but from this session we have covered for some of those common codes smell and we will see as some of the way how to refer to them. So, let's start with the first smell. Duplicated code. So, duplicated codes like they are like identity care or very similar piece of code or can more than one places. So, in a buff exam he also write we have a two method one is called the is pass another one is passed with credit. What do they do? So, we got the sum marks from the student and then calculate the average and checking. So, they are exactly the identity care just only the one line is different. So, this is also a sign of the duplication. So, sometimes also even those that cope may look like not exactly the same. The duplication also could be occur. They are performing the same job. So, there might be some cope with the different method name, different implementation but they are doing the same thing. So, this is also a duplication. This is a sign of duplication and usually also like when we are working on the same project with the cross team and we have a lot of communication and a paper time to produce a same code over or over again and again. So, how we can refer to this kind of duplicated code. So, from here right this code and this code are duplicated. So, if there is a duplication in the same class what we can do is we can extract it into a new method or if there is a duplication in different classes we can create some class hierarchy. If there is some duplication occur in some child classes then we can put it into the parent class or super class. So, from the above exam also right we create another private method to calculate for the average then we don't need to duplicate it anywhere and the one good thing about this refituring is our method also began as shorter and easier to understand and easy to maintain and more over because we make centralize all those like code duplication in one place right if there's something need to be changed we only have to change it on our private method. We don't need to change on the two different places also. Okay, next. So, this is very very common also like when we start writing a code right like as a double bar also we try to be like very futuristic. So, we always put some place folder for the future requirement. We always justify like yeah we might need it for later but in the end of those classes like nobody use nobody care also nobody maintain and then some of those classes like like some interface or abstract classes they are only implemented by one class and they even have a chance to live once probably called by the some task method or task class only and like those classes also right we tend to add on a more feature or more implementation getting forgotten buries and then loss in a documentation also. So, this exam here we have an abstract address class and we have an interface to implement some logic and we have a home address extent. So, from the exam method I can justify like yeah we might need it for address office address that's why that's we have an abstract and we have an interface. So, this is a sign of the cosme also do we really need it for the like those abstract class and our interfaces actually know right. So, how we could refactor this kind of cosme. So, if we see this kind of cosme right if we see there's some end use abstract class or interface we can collapse into hierarchy if there's some unnecessary delegation of the functionality to another object we can maybe put it into the inline class or we can use the inline method and totally remove those end use parameter feed or method these are they are just noise in our code base only. Just rule of ten is like create a code for the current requirement nothing more nothing less. So, from the above exam after we refactor right we can totally get rid of our address and interface it's no longer necessary even though we need it for the office address we can instantiate it from the existing address class okay next. So, this is like one of the very common cosme in everywhere. So, this we have a like this checkout method and it's doing a lot of things this is like one of the client code violating the client code principle also it's doing more than one job. So, because of it's doing so many things right we have to put in the common also to understand about which session of code is doing what. So, and also there's no clear cohesion also there is it's very hard to understand why do we need to this checkout method is like doing so many things like so many jobs like calculating the total price calculating the delivery fee and also storing the database also maybe creating some object and return or something. So, how we can be understand about this kind of a cosme right if you are writing a method and your method is too long people tend to like subject like you know how many line that we should be inside in the method. So, most of the people agree is like it's more than 10 line we should ask a question is it this method is doing this one thing or like doing the many things okay and usually what could be happen is of course no one intend to implement this kind of long method right we tend to add more thing because we are adding more feature or more implementation. So, usually this kind of class this is kind of cosme are like large class or long method. So, how can we refactor that one if we found this kind of long method we can be extracted into the smaller methods for large classes also we cannot split into the smaller class and it create a hierarchy for those common logic. So, above right for checkout method of course this is just one level of refactoring only we cannot be put it into the private method for calculate total price calculate delivery fee. So, we don't need to be like putting so many things inside our checkout method and a good thing about here also it seems we use the semi clinical principle of the like naming convention and descriptive name we don't even need to write a comment by checking here we can understand like this checkout method is doing calculate the price delivery fees update db and so forth and so forth right if someone don't want to interested what is the implementation they can do the individual private method and sc okay and now one of those good thing about this refactoring is it can also help us to avoid duplication also because we isolated those logic and a code into a different smaller method okay next cosme slown parameter list this is also similar to the previous exam also so usually when we are adding a new function or when we are adding a new feature we might be in turn off we are considering for the good design and a code consideration we might be adding on the existing method and like it ended like having a so many parameter list and also it could be possible because of the sums method multiple methods are merged into a single method so that's why that we meet we need so many parameter list one good rule of thumbs is like if we need more than three parameter right we need to ask do we need all those parameter for this method implementation if yes probably we might be any have a long matter we have to consider how we can refer to it okay and also this kind of long parameter list method are very hard to understand hard to change also and even hard to reuse so people will be afraid to call this method from somewhere else even this slide want to get the formatted address or get the order because we don't know what is why do we need so many parameter in the first place so how we can refer to this kind of long parameter list one way is those group related parameter together and introduce in the parameter object so from the above example right instead of passing down all those string value for formatted address then we can pass the address object is less less parameter and do the same job also same for the below example also to get the orders right this is kind of like a look like that is query the data from the maybe order table or something we can create the query object so put it all those like related information into the one class then we can pass it down into our method so there's another way also it's like we can also replace the parameter with the method call if we follow those parameters as a result of another method call instead of passing down getting the result and passing down into the separate method we cannot directly use the method call and we can also preserve the whole object instead of passing down from the group of parameter okay and also benefit of this refactoring is is shorter it's more readable yeah next one so this is called is a primitive obsession so why did this this is a very bad practice of using the permitted type to represent the domain object so from here right we have a customer class with the name email unit streets city country post echo and blah blah blah so it this kind of code also the one of the disadvantages is they could tend to grow in a number of primitive along with the behavior so if we need it for let's say office address are we going to add a summer other variable here related to office address and it could be get worse when this same primitives are need to be defined at different places we will be end up having a duplicated code so how could we refactor this kind of thing very simple create a class to represent those related together and also move along with the behavior it will be give us a more flexible to use the object instead of using the permitted type and also bring us a more cohesion organization to the domain level so from the above example right instead of using all those string value we create the address class then we can make use of the address class in our customer okay next one so this one is data club so data club is like piece of data found in a many place many part of the our code base when they can be related they are seems to be related together they doesn't make sense in isolation but only make sense together so how we can do that this kind of data clam right if you want to make sure whether we have a data clam or not just delete one of those part of those of the data value and see whether they as they make sense so in an example there's a two example right for the apply leave to apply the leave we need a front and two right if we remove the one of those it doesn't make sense this matter is doing nothing and for the booking also to make a booking we need a like customer name guest name or passport number passport issue day passport expiration date right if we remove one of those value it doesn't make sense if this matter is doing nothing so how could be refer to this kind of data clam group those like data together into a class and introduce the parameter object so instead of passing the two many parameter right we create the data range as a class and passes as a parameter object same for the booking also we create the guest info class and pass it down and also issuing the parameter list and it's also much cleaner to see right the next one is nested condition so the nested conditions like this is very common also like in our code base right there's a so many layer of if a statement or sometimes switch statement also so why do we have this kind of nested condition it could be possible as like maybe initially we just start with a very simple conditional checking and we need to add for more feature or maybe we need to fix some defect then we end up having so many nested condition so these nested conditions are very hard to read hard to understand hard to maintain also the deeper the nesting the longer it will take us to refer to so there's a few techniques that we can use use a tannery operator most of the modern programming language support tannery operator so instead of we are having an if statement use the tannery operator here to do for the same logic and same thing and also it's much more cleaner instead we have a four line right we can end up with the one line of code and our next one is a simplified condition so what is this doing is like this total quantity is greater than 50 we set it to some value to true or false we cannot put it into the one line only why do we have to do for the nested of course this is just a some exam only but in reality right there might be a many layer of like if a statement that we have to go through right next technique is we can combine those conditioners also so this is also very common one like we have so many layer of a statement and it might be analyzed we only have one statement so why we cannot combine those conditioners we can use an or or operator to combine those nested layer it will be much more cleaner much more easy to read also and the next one is we can use a guard clause to exit Ali so here is the exam is if the quarry is not now we want to do something right we can think about the other way if quarry now what we want to achieve so we try to exit Ali before we go into the all those nested now and just be aware that everything must be in a moderation don't abuse so even if we suggest to use for those kind of techniques and all those things right the below azimuths are very hard to read what is this doing there's a very there is statement with like not a and b or c and d i even coordinate differentiate like what would be the output of that one i'm saying for the tannery operator also this is abusing we have two level of tannery operator okay so try to avoid this kind of things and less but not least so for the cosmer we cannot talk about we cannot end the cosmer without the bad comment so bad comments are also like some piece of a call they are not says explanatory that's why that we have to put a comment in the first examer right what is fdf history we don't know so that's why that we have to put a comment why we cannot use the clean code techniques like use the descriptive name then we don't even need to have a comment and the second called second examer is like to do this is very like most of the developer also tend to do we are writing a the comment should not be on your reminder if you see this kind of do-do thing we need to take it and we need to check why do we have to to do to do comment is it we cannot do it at the moment or something is blocking us if we can this kind of to do is like at a unit test why you don't write a unit test in the first place why you have to put for the reminder and the second uh and the third examer so this this test that examer also is like do something big we don't know what is this method is doing that's why that we have to put the some description on the top of the method so when I was preparing for the slide I just want to make a joke so like this method get the item from db watch dishes take a walk blah blah blah so we don't even know what is doing so you know one of the sign also this is doing so many things and we don't understand if we break down into smaller method we can totally get rid of those comment and unless best not least some of the code also we cannot put it for the um we have those commented code okay why do we have to comment it out code that's we are using a source control system right why do we have to use a source if you the code are no longer needed why we cannot totally get get rid of from our code base so it will be much more cleaner also and also if you see this kind of comment code right usually people will also tend to forget also and they also afraid to delete because oh my someone is do this like maybe there's a some meaning behind so it's very um very very annoying okay that's all for the um cosme there's a many cosme that we haven't talked about in our session because of a due to time limit but I hope that that that you guys understand about the some of those common cosme and how we can refactor it and can be produced a better code so the next is some good practices for the um cleaner code so we have come up with a summer idea what should be the good engineering practices to write a cleaner code okay usually right we don't always get a chance to start up from the clean state many time and most of the time also we are working on the existing report and it is very important to clean otherwise very difficult so first thing is remember about the be mindful about the wise cop rule leave your code better than you found it so even though the code is clean before you you found it and then you must say that that is like your responsibility to clean it clean it also and what we should refactor is every time remember to refactor next one have a summer good engineer practices in place so have a good regular code review not everyone is perfect even the senior deaf also could reproduce a bad code and a cosme when we are rushing for the some delivery or some type um timeline right so we can detect all those cosme during the code review so don't skip the code review I mean like I have encountered sometimes also like in a project right when we are rushing like people say oh let's skip the code review and then push the code okay and next one is like people are scared of refactoring because they are afraid of breaking things so if we have a good test we will it will make our life easier we can have an ease of mind to refactor the bad code from the clean code if we have another test so you will know you break something if your test is fake so try to have some some uh good um practice of the uh having some TDD or like test code and test method and last but not least leverage the latest tools and plucking so most of the IDE right we have those refactoring functionality instead of like manually deleting your code or like putting extracting into the different uh method or class try to use the existing IDE functionality there's a lot of function for refactoring most of the um IDE supported so we can also leverage the using of like you know checking for some safety check like this code is used in which places and so far and also some of those um very good uh well known um code analysis do is a sonar queue sonar queue is a static code analysis too it can give us like a what is a code quality of your code and also can provide some of the recommendation also okay how to refactor and uh how to improve your code quality so that's it what's next so if you want to practice more on those clean code and uh to practice more on the refactoring and like understand about learn more about the coltsman and everything we want to recommend first book from the clean code by the robot c martin and get this should be one of the handbook from the author software developer then the next one is refactoring book this is from the martin fowler so here it shows a lot of techniques and rules like how can we refactor and the next one is this is a git report you can download those you can go to this git report and practice to refactor the code also that intention of this report it is written in many languages so you can pick at which programming language that you prefer that intention of this git report is they are intentionally right in the like bad code so your main responsibility is to refer to okay yeah this is some of the resources that we use it in our slide and question and answer any question any comment any thoughts any sharing yes um we will share this slide also right yes yes yes so this one is a very popular cutoff to especially learn the refactoring part i would highly recommend it go there and one thing if you really want to learn don't look into the solutions there are a lot of solution available on internet don't directly go and watch the solution videos or the blocks try try it out yourself try to understand there is the business requirement explained the code is intentionally kept bad try to refactor it like it's really good thing good learning if you do a practice on this cutoff highly recommended any other questions any comments suggestion yeah so um this is like we are just giving a some surface of the idea only so usually like most of the organization i guess sona q is using for the code quality improvement um it's also not very cheap so far what i know uh and uh some of those like refactoring functionality right regardless of which id that you are using there should be some basic function of the refactoring like extra method extra class of like you know create parameter or whatever that should be keep on using all those kind of things instead of like manually copying a piece on the different places because definitely if you do manually something might break also your code may not be like a lie and some this is es links is usually most of their front end developer used for their javascript formatting everything it's also recommended there are much more also we just give some idea and an example here only yes sona q support that so if you run the usually most of the enterprise project like we have set up for the sona q report and then whenever people start checking the code right sona q will automatically run there i i know that there's some plugin available for sona q also you can use it in your id level within your project level or whatever because it will be quite huge to scan all those like the whole code report right but usually most of organization level we do for the sona q when you check in at the some code sona q will automatically run it will give you if you have set up for some notification also you can i get some kind of like how many um you know issues or like based on the um severity level like what is a critical issue what is a major issue high issue and they can also provide you some recommendation also those duplicated code where is duplicated which line is duplicated so far and so forth any others if you're using an open source project you can also use something like code requirement yes yes of course this is very common question right so like yes um you can recommend of course may not be get approved for sure also uh another way also like since you have no about how to write the clean code and what is the cost may arrive you cannot keep on practicing also even those like you are just newly joined to the project you are very junior also you can suggest like maybe try to get practice get keep on get more practice and try to influence other people also so maybe you start with your colleagues that who are you trust or you you you cannot you know talk or share or whatever at least like i feel like most of the case right code review is a very good approach because nobody's perfect even like you know people will be tend to forget all those principles and a good practices so have a share review within your peer or like your colleagues and like you can also suggest to your senior like or maybe if you are not sure also you can check with them why this code is too long why is written in this way is there any way that we can improve you can suggest also just uh just to add on so there is something called tech depth so there is always a trade-off and we understand that sometimes the business is hurry to deliver so the internal quality of code sometimes can get ignored but there's always a trade-off like uh you want to pay less now or you want to pay more later so the more you uh ignore your tech tech depth so as you mentioned it's one year so either you start working towards it and later if you if you say you want to improve it after two years it will be much more costly because the code has become much more messier so the phrase that goes on pay less now or pay more later so which one will you prefer so you can always like encourage the team to get on the good practices and like keep track of your tech depth so even if we can highly understand that in a real business it's not every time we don't have the super clean code it's okay we but we don't ignore it we keep a backlog of it and we will work on it later so you can try to follow that thing like yeah pay less now or pay more later don't don't forget to clear out those tech depth also like don't keep on adding and like forgetting to clean those tech deck yes any others thoughts comments yes yes yes yes i think it depends depends on the which line that you want to go for approach so like even those read it did and like functional also right there's a sum of the rules and principle can be applied applicable even for functional programming or ob programming and also you of course there might be some kind of like certain principles rule only can be applied applicable for the functional programming so maybe if you want to go for that kind of journey you can learn more and i get on practice so sorry like i don't have any clear answer for that kind of question yeah even i don't have much knowledge on that but one thing i can explain you in a similar context let's say we have microservice architecture and because it's a fancy everyone running towards it so like everything tends to solve a particular problem so you need to decide what problem are you solving so the object oriented functional programming there is a particular problem they both are trying to solve what kind of problem you want to solve so like i can explain more on microservice and monolithic for example now the microservice is more fancier and everybody is doing it so everybody kind of rushed towards it but that's not a good thing to do try to focus what problem you're trying to solve and there might be simpler solutions for that so in this context as well so object oriented or functional or reactive like the front end react you need to identify what type of problem and whether the solution you're choosing it focuses on solving that kind of problem or not rather than whether it's easy to test on or that's not the criteria to choose the language i think it's depends on there not on the programming language i think it's depends on the depth whether you create a cleanup code or you create a messico is up to you only the programming is just just just a tools to write the software solution solve the problem yeah so just to add some more context now these programming languages are again created by some human who has some intention in his mind just for an example when i was going through how to write a clean code i said do not expose like getter and setter be mindful but in java beans by default you will have a getter and setter for all the variables so each thing has a different intent like it's your responsibility to use it wisely to have a cleaner code so certain languages like there the the programmer who built it had certain things in his mind certain focus in his mind and that's why it's built in certain way it's it's not like this language is much cleaner this language is it's not like that as a developer it's your responsibility to choose the features and to use its characteristic in a well proper way so that you achieve a clean code yes yes true yeah so usually one thing that what i can say is like you show the business what is the value of the clean code like we have explained right like down the road also at the end of the day your code will be very messy even those like they want to deliver they want to push us to do the some delivery also they couldn't achieve because of the code are very messy a lot of things to be referred to a lot of things are broken one we integrated together right yeah yeah we actually had a diagram we wanted to include that but because of time constraint we could not so usually to explain this a bit we we highly yeah this was the one so there are two things external quality and internal quality so for the business showing that external quality is good meaning your user experience and the number of defects this is your external quality and business can understand they will focus on improving the external quality but your code quality is like something internal and as a developer you can understand it and it's not so visible to the business but it's more of a mindset and it's our responsibility to convince our business that this is equally important now this is from martin folers website so usually let's say we are starting with a fresh idea we are create like a startup thing we try to deliver things very very faster so the yellow line you see is of low internal quality so initially the time to deliver is faster however if you try to maintain high internal quality initially you might feel that you are slowed down but after a certain point and that is in weeks not even months you will be much you will be able to deliver and our productivity of the team will be much higher when you have a higher internal quality so it's more of convincing the business as a developer it's our responsibility to convince them because the business people cannot see the internal quality it's us who are able to visualize the internal quality so if we want to keep delivering faster we need to maintain high internal quality that's i hope that answers any any more questions yeah so usually for those junior like i mean one way that what we practice is like we have some kind of pay programming this is one way that we cannot practice also either like you are less experienced programmer also like you know you can pair with those senior deaf then you can learn about more about the business and also like some of the good practices and some contests also so this is what we are encouraging but of course like maybe some organization also the pair programming not usually practice and very expensive to practice yeah so yeah so i completely agree with lin and just to add on top pair programming is the solution for that but if that's really not possible given your current context so maybe take small steps when you have a very big complex code usually you will find that the 20 percent of it comes like the 80 percent of the actual logic comes from 20 percent of it like the Pareto principle try to focus on understanding the most the most frequently used part of code once you're able to get hold of that slowly you will be able to understand more so i'm not sure if that's the correct name i think it's the Pareto principle so 80 percent of the value comes from the 20 percent of the code something like that so try to identify which is of the like since it's very huge and very complex take a small step and identify which one is mostly used and start learning small on it or let's say one thing you can do is if there are not tests you can start writing the test from my personal experience uh i was working on a code and it was really complex i could not understand there was no test also start writing tests for it it will give you a lot of confidence in terms of understanding the code and also the change you are making you are very confident that your tests are there to back up you like if it fails you know what fails so you can start like take a first step towards it maybe in your team encourage people to start something towards writing test yes please uh we can use like to do comment so we have to i just give some some you know exam and like make some joke here only so if we know that that to do to do common is like you have to write a unit test right why you don't study in the first place is like you are violating one of those rules already right and another thing is like the comment is not bad we can put the comment sometimes the comment can help for the some um you know developer who are not familiar with the system or how the things are doing it but usually right as a developer most of the time nobody read those comment we just did dive into the code and then check what is doing and what is this function doing what is this class is doing right so why we spend so much effort on writing those comment which is those are very obvious maybe it's a very very important information that you want to deliver you can stay write the comment but i grant you like 90 percent of the death are like just start looking for the code just to add so to do comments are not bad comments they are considered as good comments but what what we want to avoid is don't get in a habit of writing to do comments one to do one or two here and there it's fine acceptable but don't get in a habit of i'll just ignore it let someone do it to do i'll add to do everywhere okay write a test here do this do that you are like take step to refactor like you can spot something and if you want to refactor do it yourself if you don't have the capacity we understand we need to add the to do but don't get in a habit of adding it every time like too many of to do is wrong to do is a good comment in itself but too many of it is something messy yes any other thoughts sharing comments yes please do you mind to share more a bit like how do you usually you usually also write like you can also think from the light like recital share also stuff from the small step so even those like you know that they're very messy code what you want to achieve you will be adding for maybe one or two function or like doing something of course the existing code with the very long method or long parameter laser is very hard to start writing a test and most of the time also people tend to like forget about the test and then just add the code right so but if you know that maybe there's a small function that you are adding there's more feature you can understand test why don't we start it just to add on so if you follow tdd you write test before your production code and that's much easier to do but if you're writing test for an existing code it's it's much much difficult to do so how to start like i'm not so what i understand is usually you we write like characterization tests so for an existing code when you write you tend to just follow the code like the test will pass so that you understand what the code is doing from your test once you have the characterization test you start refactoring like let's say you have a big function so just don't jump into refactoring first write a test that's already passed on your existing code now there is a test to save your back so if when you start refactoring now you know that the test will tell you if you messed up something so just write a test and maybe that test can be uh how do i say it i'm not getting the correct word for that but maybe you get some kind of safety net like something broke yeah your intention the first step should be to get a safety net then start refactoring and don't forget to refactor your test as well the same principle so if you remember the dependency inversion principle single single responsibility those are all applicable for your tests as well so yeah experience writing like uh working on it legacy code right i'm sure you're talking about legacy code there so i guess if legacy code usually the first thing i'll do i would have done would have been to write unit tests to cover that function but usually with legacy code there's a lot of spaghetti code and there's a lot of entanglements and a lot of dependency already in that function which is which also lets you let's you understand a little bit better why the function is like so badly written right but if we can figure out right the test coverage for that one function right along with all the dependencies all the needs and you can go proceed to refactor slowly uh since oh okay now there's too many things being entangled into this function maybe i should break it up and helps you reorganize the code better as well along the way yeah so start with uh test coverage for at least the existing functions there's no test uh then you make then you make uh the update the test to introduce a new new feature of behavior and then you try to introduce a fix uh introduce a new behavior that's one of the ways you can try yeah there was one more slide we added for that i was looking for that but we have skipped it i'm not sure if that can come you the approach we should take there were like list of approaches uh i i'll try to get um okay i think i think i close it it's really difficult to come up in one hour for clean code and code smell we wanted to cover a lot of things but we decided to cut down kadoom and yeah this one is like uh ensure you have test for your existing code start writing test for your existing code so that it has it has a safety net then you should start writing test for your new feature and pledge that whichever new code you're adding you will have a test for it before you start writing the code uh yeah this is like the cycle that will be followed any others yes yes that's also good approach and uh yeah so we will be taking on more questions meanwhile we will be it will be very helpful for us if you can have submit the feedback for us and meanwhile meanwhile we can continue q and a so if you have any more questions it's very interesting for us to hear and i guess everyone is hungry now also yeah let me check with kevin do we have more questions uh the previous slide this one no the links a few links uh okay yes do we have any more questions yes yeah as mentioned like a certain programming like i i may not be very uh expert on answering that but from my experience what i can tell you is it's not that language gives you clean code you need to identify which features went to use for what to use as mentioned before like we say that avoid adding like exposing the private variable avoid uh adding getter and setter for your variables but java but java has it beans where it allows by default the getter and setters so js doc also has certain features for certain problems try to use it wisely and that will result in a clean code it's not that js doc promotes cleaner code every language has certain features it's it's your job to choose wisely which one is for what type of problem in terms of energy efficiency i am really not knowledgeable on that but uh anyone else can answer that in terms of energy efficiency clean code for AI projects yeah thank you so much for the answer i i hope that really answered yeah so even yeah thanks a lot for sharing that mm-hmm it depends on uh okay it depends on your passion like do you really want to do it like i think it it really depends on you if you have a passion you can easily learn it so nowadays the coding like you might feel it oh my god what is it but with time it has become easier and easier the languages have become much easier so they are here to help the developers it's it's not like it's it just depends on you how much you want to learn how much you want to do but there are a lot of languages and to start with i would suggest you can start with javascript i mean that's very the common language how we speak the english language format the other languages are also not so difficult but maybe for starting point i i can suggest maybe start with javascript and then uh you can move on to something else but trust me the languages have become easier more human friendly so it's not that big thing anyone can learn to code now and you just need to find the right forum and right resources that can help you i hope that answers uh you have a lot of udemy courses like in in internally thought works we we follow the udemy platform you have plural site you you can join conferences like this and i would prefer like i would suggest don't do it alone find a buddy who is someone like you trying to learn and that is much more helpful uh join some like he mentioned developer jim or something those kind of events join them that will be helpful my answer for that would be stay in that project for long because you are there when you are creating it you are not there when it's failing so if you really want to hold your horses stay there for longer and see how it fails as he mentioned developing is 10 percent maintaining is 90 percent be for the maintaining phase then you will really understand the pain points and then you will never try to jump on the next feature without cleaning it up so try to experience that pain stay there for longer maybe with that project which you created so yeah that would be like because usually developers like if you don't experience the pain you will not clean it up maybe because you haven't experienced the pain yet or the people around you haven't like come and shouted at you so be like be like acting more professional let's say not for developer let's say a plumber come to your house he knows all the bit and tricks you ask him to fix your tap or something he knows that doing this will will do it for now but maybe 10 days later it might not so if he fixes is just for 10 days and goes away are you going to call him again like you realize every 10 days it's getting the same problem are you going to call that plumber again no right you will start looking for another plumber so it's same kind of thing with the developer we also need to be like have some more professionalism and once you experience that pain definitely you will start working on the clean code and apart from this mostly how like I have experiences there are code reviews because some like senior or someone is going to do that code review in my team if I write a code it works beautifully but it's not clean it it cannot get merged at all I'll have to spend like 10 more days to clean it whatever it takes it takes but I need to make it clean so that code review is like one maybe you would in your team it was not practiced well enough so try to have good engineering practices some of the things they will take care it's not just your responsibility the the setup nowadays with the latest tools and technologies they enforce you to have a clean code so the first barrier would be the code review I would say yeah then a senior dev or an expert would never allow the messy code to get merged into the production so that's what we follow in our team and that's the first line of blockage for messy code yeah I hope that answers okay any any more questions I don't know where Lin went I am a front end and back end developer I I usually I I have very minimal knowledge on that part I will skip this question or maybe in the audience somebody have a better answer because I really don't have that expertise to answer like how do we like maintain cleanliness in the cloud architecture I am sorry I really can't think of any answer for that any anyone cloud experience can share more on his okay you want to share I'm really sorry I don't have expertise in that area I haven't really touched that part in my career till now okay I think that's all since I was not able to answer I'm not going to take any more questions let's move to


Alrighty, I have a construction update for you guys today, and things are really heating up at Canada's Wonderland, not only that, it's getting really confusing to predict this coaster layout and what's happening at Wonderland. As I've said on my podcast and other places as well, Wonderland is really upping their game in terms of a budget, and you're seeing that. Wonderland has projects all over the park, has removals going on, cleaning up of areas, enhancing of areas, and of course this major 2025 coaster that is being worked on already. So as you see on the screen, Extreme Skyflyer is starting to get removed. Again, my videos are always a day delayed unless there is breaking news. So yesterday we posted the Extreme Skyflyer removal. This is footage from yesterday, and then tomorrow's video will have it completely removed, just a little heads up. But with that being said, lots of work going on over at the mountain, so they are almost done reinforcing this tunnel. This is filmed in the morning. Again, if you fly in the morning, the sun reflects off things, and it looks like just pure white, so it's hard to get that angle. You'll get a better shot at 5pm. Our 5pm shot is so much clearer. But over here, we noticed that they disconnected the gas line and the electrical lines in this building a bit ago, but they finally finished disconnecting, which led me to believe that they were going to demolish this building. There's a couple buildings in this area that look like they're up for demolition, but there's the demolition vehicle. So I knew in the morning that they were probably going to demolish these buildings. I forecast that they were on break, and that they're probably going to do it later on or the next day. But you'll see they start demolition in this video, so you'll see it. The drink stand that is right next to Thunder Run's old station is moving on over beside Clockworks by the looks at things. Also, they started pouring concrete into this little, what looks like either a ramp, staircase, queue line, or pole out of the mountain, whatever it ends up being. They started pouring concrete into there. We have two holes in the tunnel right now. We need a third. So we're on the lookout for a third. There is no third hole that I can report. There is obviously a blank space that I can't see. So underneath Thunder Run's station would be a prime area to have another hole. So we'll definitely have to keep an eye over there or for the birdies at all. If a hole opens up there, we've seen no vehicles or demolition work going on there. So there's no signs of a hole yet. But here's that drink stand. As you can see, if you look really closely, there's holes in the wall. Definitely going to be demolished as well. And that little arcade booth that is beside the construction area also looks like it's been emptied out as well. There they are installing the new fast lane. Well, the equipment isn't being installed yet. They're cutting to install the electrical for the new fast lane systems. So Leviathan is having its installed yesterday as well. So that's really interesting. I'm really excited to see how this works. Very curious. Outside of that, we are heading on into the 5pm shots, I believe. So here they are removing more of the tower at around 5pm. They're very quick, by the way. So when they start cutting, as you can see in this clip that they're doing, they're very close to removing. But to put it into perspective, this was a couple hours later. So this was about an hour later, and bam! The whole tower is gone except for the two dropping towers right there. Those two towers are all that was remaining yesterday. And I can confirm, when you watch this video tomorrow, the whole thing is gone. So that's exciting. Definitely really curious to see what that's going to be used for. Outside of that front gate is looking about the same. They were adding some theming pieces already. So it looks like some botanical gardens. I don't know if that's the right word, maybe just gardens. But here is the demolition. This is Thunder Run's old station getting demolished. So a little sad to see, but that to me confirms that something important in the works for Elpin. So I'm really excited to see what that ends up being. The drink stand right there with the door open just beside it is going to be demolished as well. These two little buildings, not quite sure. For Patreons, you're going to get a really detailed map about what I think is going on. And what I know is going on, as promised, I will continue to do those as things progress. Just to track what we know for sure and what is speculated. And yeah, there's a lot going on in Elpin. Almost every single one of these buildings has some sort of something happening to it. So really curious to see what Wonderlands plans are for Elpin. If you've watched the podcast last year, we kind of been predicting that Elpin was going to be receiving an upgrade. And lo and behold, it has. This is the finished product. As you can tell, it has like slight little inclines downward. Now, what doesn't make sense is it looks like it goes to meet the floor down there. But then there's an elevation that goes up because you have to remember that there's a level down there. So it slightly doesn't make sense. But you'll see a better view of this in tomorrow's update.  The finished product definitely really confused as to what this is going to be. It's looking like a building or staircase or possible ramp. Very similar in size to the first tunnel, to be honest, once they add the walls. So that makes it a little weird as well because still don't know where they're going to fit trains or track pieces horizontally into the mountains. Unless once this is constructed, it really does come out to be a ramp. But this is really confusing. I'm not going to lie. This whole project is really confusing and it's kind of stressful to watch because it's like it could go either way. It could come out the Elpin side of the mountain or it can come out the extreme sky flyer side of the mountain. Or it's going to come out both and use a little bit of land on one side. Who knows? This is really confusing, really stressful. Here's that 5pm shot. Again, they're about halfway done the other side of the tunnel. So that's really exciting. You can see them here working on it. They actually stayed late yesterday because I filmed this at like 5.30pm and they were still working really hard. And there's another angle from the other side of the pond of the old Thunder Run station demolition. So, oh yes. And this is the shot. You can see the holes in the old drink stand where they removed the equipment. So definitely lots of things up in the air for this season. Okay. Lots of things. Is the Elpin refresh connected to the New Coaster? Who knows? It could be a completely separate project. Is the extreme sky flyer side of the land connected to the 2025 project? Who knows? Maybe it's not. Maybe it is. There's two tunnels. Both tunnels lead to both areas, which makes it that much more confusing. So very interested. I will tell you Whitewater West pieces have started to arrive on site. So that was really exciting. I think I'll show that in the next shot. So our new waterslide has started to arrive on site. Yay. It would be nice if it was our new Coaster arriving on site, but not yet. A little early for that. But everywhere else I've looked, no other signs of any other construction on the extreme sky flyer side. Just that they set up the cinder block blocking off international show place. But that has been there for about a week and a half. And then there's the angle of the Guardian piece of track that's sitting on the ground. And yeah, not too much else exciting going on. Thanks for watching our construction updates. And that's everything for today's update. Alright guys, have a good one. Bye.


Good morning, everyone and welcome. This is Melissa Armo with Stock Swoosh here, reviewing MoMo. Amazing gap today. It actually had a swoosh. So here it is, a late, late earnings season and still getting swooshes. Good sign, nice. Nice to see a sell-off deal and something like this with a very bullish market, which we had today. Great move. Actually, this looks like it's continuing. Gonna break the low. I did do two trades in this today, and I said it probably continues and goes to 36-something. So it'll be interesting to see tomorrow morning who's still in this, but what an amazing move in this today. Let's just go over it. So ended up shorting it here. Could have done the ad here. I just did the normal trade. Got the drop, got out. Ended up doing a second trade in this then in here. Got the drop, got out. It is breaking the low here now. Look at this. 36-91, it's gonna do it. So really, really, really nice bearish move in the MoMo today. Very happy, good, solid, strong day, and I'll look to continue to do that the rest of the week. Wednesday, Thursday, Friday, we got three more days left in the week, and then next week before the holiday, and we'll see what we're gonna get. So it's been overall a good-earning season, and the market clearly turned around and showed its hand today, which it's still holding the bullish up trend. So happy to have something that worked so big, so swiftly, so smooth, so fast today in the MoMo on a Tuesday, because we've still got three more days left in the week. And this was a big bar. I mean, actually, this is more than $3, so this thing is really rockin' and rollin'. Good job, everybody. Congratulations for everyone in the room today. Some people had their first comedies. Always, always nice. Here, look at this. It's gonna break the low right now. Wow, here it goes. Anyways, congratulations to everyone in the stocks. We'll show live training room. Have a great day, everyone, and we'll see you tomorrow.


I don't know how much time I have nor do I know what will happen to me But I want to send this out to everyone so you will know how I'm not entirely sure why this has occurred But to the best of my ability I will explain it all started on a rainy day I like listening to chilled out music on rainy days I especially love listening to ambient music the definition of ambient can differ from person to person But what it is to me is usually music with drones, minimal processions, and can have varied moods Usually either happy, dark and depressing, or just mysterious Selected Ambient Works volume 2 by Afex Twin was my selection for the afternoon The album is more dark than its former selected ambient works 85 to 92 The album lasting around two and a half hours was a perfect choice as there was nothing better to do for the day Everything was seemingly normal until spots Spots, the 22nd song on the album, was what started it all The song is a continual drone, which sounds to me like a hollowed out, abandoned mental institution Left a long time ago to succumb to nature, but not just that, the dead of the hospital Yes, throughout the album, there are samples put all over the place, such as a deep, distorted, demonic sounding moan in white blur too Or what sounds like a spirit trying to contact someone via radio in Radiator Or a conversation in white blur one, held between a man and woman, taken up so high in pitch And sped up to a certain degree, that it is almost impossible to decide for what they are saying But what I heard in spots is something I never heard before There were whispers in the song in the original disc, but that was normal, because every other copy I have listened to contained it But what I heard was this dark, demonic growling, as if it was saying something I could not make a word out of it though Puzzled, I just sat through it, staring at my radio That growling was not supposed to be there I was so scared, and I had to do something about it The best option there was to call my friends, I had them come over to hear it The thing is though, they didn't hear anything Nothing At this point, I couldn't take it I was scared, and I couldn't do anything about it When my friends went home, I took out the CD and never listened to it, until yesterday I may have listened to it, but not willingly No I was on iTunes, listening to some dead mothied And then the song just froze, playing of the song only one part, counting as one eighth note, just repeating itself Over and over, I heard the same part of the song But then things took a turn for the worse It was back Spots was back, but it was in reverse Then it came to the part where the growling came in This time, I made something out of it I could understand it The growling was reversed when the song was in reversed But as the song was reversed, the growling was in reversed If I remember it correctly, I heard it say You cannot hide, you cannot resist Your friends will be of no aid to you And your family will succumb to us Your life will be reversed as ours A parallel We will find you We will make your life as ours, we'll make by them There is nothing you can do You cannot hide You cannot You can't You can't You Then there was static That was never there either I locked myself in my room There was only one thing I could do I kept my Bible next to me at all times I only could leave in the morning for school But until then, I had to stay up All night, I was awake, making sure nothing happened The next day, today, I felt nothing I feel nothing Everyone asked me why I was so pale Why I had dark rings under my eyes The worst part was, my crush started noticing Oh, I wish I could see her again But I fear it's too late I listened to my iPod while doing my homework at the study hall But I didn't control it It automatically went to spots I did nothing about it You cannot resist I listened to it Near the end of the song, it was automatically put on repeat Each time I listened, the air got heavier I was about to throw up As it is allergy season I got up to blow my nose I did, but blood came out, not mucus And blood started pouring out of my nose As the blood poured on the floor, it moved It literally moved It formed the word, hide Whatever was talking to me through spots, was toying with me It tells me there is hope in hiding, but there is none I cannot hide I cannot resist I went home, and now I am writing this I don't know what will happen I don't know why it happened But I know, soon, I have to join them Because I cannot hide I cannot resist Right now, as I type this, spots is sneaking into my mind, playing I know by this that I don't have much time I cannot hide I cannot resist


We are with Vijay Kumar, head of marketing at PNG Health and we will be chilling out with Vijay and exploring his life out of PNG and marketing. So, Vijay, on a typical weekend, what do you do? You see, weekends are for friends and family and personal life, so I completely switch off from work. So much so that I turn off the notifications of all the outputs and the interconnectivity apps that I have on my mobile and from work, so completely distance there. So, since you said series, what is that series that you are binge watching now? Uh-huh. But I'm into a lot of thrillers or rides. What's your go-to food, Vijay? I love Mexican food. Okay. And you know, when is your next vacation going to be and where is it going to be? See, I just came back from Malmuth last week, so when and where, probably Thailand like is going to be the main cover mix. Uh-huh. I like the wink. The last question is, what is that one skill that you want to learn next? See, one skill that I want to learn next is I'm in this, you know, the juncture of my career where I'm going to be. Thank you very much, Vijay. Have a great day. Thank you so much and catch up next year for me here in Malmuth.


Well, back now to tonight's main news, and I'm sorry if you're enjoying your dinner, but the Food Standards Agency says the discovery of horse meat in a finda's beef lasagna is appalling, but maintains there's no immediate health risks to the public. Meat products from across Europe have been found to be contaminated with horse meat. Horse meat is being passed off as beef for kebabs and burgers in Britain. They may never know exactly how many people have unwittingly eaten horse meat labeled as beef. We're very sorry this has happened. The consumption of meat processed drops by 30%. This story is remembered as the Horse Meat Scandal, and it has shown that we don't know the huge amounts of meat before arriving on our tables. In the case of the Horse Meat Scandal, it went like this. TESCO orders a burger with a French company. The French company opposes the order to an establishment in Luxembourg, but it's said in Luxembourg that it doesn't have meat, so it's ordered from the south of France. The French establishment doesn't have meat, so it's ordered by a Cypriot supplier, who sometimes buys meat from a Dutch distributor. From the Netherlands, they're sent to Bovini, live horses to a macello in Romania. The Romanian butcher then sends the macello meat to the French establishment, which is sent in Luxembourg, where it's finally transformed into a burger and then shipped to TESCO. Do you also turn to TESCO? Everything to buy the raw material costs less, but in this big tour it becomes difficult to get to the province, and it's easy to spend a product for another one. This leaves a white paper on the frode and makes me wonder, but then our food, how does it arrive? To understand it, we went to the Netherlands, in the neutral centre of the food transport, the Rotterdam port. For 42 km, it's the biggest port in Europe, and it's grown by a few steps in our consumption. Peter Van de Larn, the director of Rotterdam FruitWare, one of the main import and export ports in Europe. Every year, about 30,000 ships pass through this port, and all of this has been made possible to advance technology, like the container that was introduced in the 1950s. With the refrigerated container, it has been possible to industrialise the food transport, which today is moved, mainly by the sea, from one side to the other of the planet. In Europe, we import the most fruit, only in 2020, 27 tonnes per minute have arrived. At the beginning of its journey, after it has been collected, it passes through a quality control made by the producer. During the journey, the fruits are separated and we go to sleep. And the oxygen is replaced with nitrogen to delay their maturation. No apples and kiwis together, because apples are producing 80-layne gas. 80-layne gas starts the ripening process immediately of the kiwis. We check the temperature. If the temperature is up to the requirements of the fruit, nothing happens. We do the phytosanitary inspection, and when that is done, the goods can be picked up to go free into Europe. This can be loaded. Then we start discharging the pellets into the cold store and we give away the empty container to the depot. The last step is to remove the pellets that will be delivered directly to the supermarkets. You see Lithuania, you see Poland, and you see Italy. However, by doing research, I found this map. And I realized that when we talk about how the food arrives, you can't just talk about its movements. But you also have to keep in mind everything that is used to produce it. To better understand it, I spoke with Professor Rob Zwidwick, expert in global distribution chains. Anything that you would like to associate with this red meat is dependent on whatever happens here. What we get is a web of connections. Chemicals are maybe produced here, but they will also source from different parts of the world, creating this web of connections. And it's getting confusing and that's exactly the point. The world market is under the control of only four companies. Half of the world's cheese is produced with bacteria and enzymes of a single company. A beer on four is under the monopoly of a single producer. Brazil is responsible for 50% of the export of sugar and five countries represent almost 70% of the export of grain. In other words, only a handful of countries and companies have the monopoly of the global trade of some products.  This system so complex and industrialized is not to be demonized. We always have access to food that comes from all over the world in perfect conditions. And countries no longer have to worry about producing all the food they need internally. All this thanks to an extremely efficient and controlled system which is so efficient and fragile. We do realize that those fantastic global supply chains that we have built also show some risks that are difficult to control and are difficult to oversee. In just two years a sanitary crisis, a logistics crisis and a policy showed that this system can be affected by problems that we often cannot predict. For example, we take the Russian invasion of Ukraine. Ukraine was called the grain of the world. It represented more than 30% of all the importation of grain in Europe. But when Russia blocked the exportation it attracted the main source of supply of many countries. The global problem of this crisis, however, was the increase in the price of gas. That exporters of bananas, for instance, can continue to have a profitable business. Then we have to stop our business. We have a third of all the food we produce. Almost half of the waste comes before the food reaches the supermarket. In South Africa, for example, 165 kg of food per person is wasted every year. But only five of these are wasted indirectly by the consumer. The rest is thrown away before they can buy it. In Europe, the proportions are very different. Each year, 280 kg of food is wasted per person. However, the consumer is wasted directly by the consumer. Another thing we can see from this graph is that the waste of food before the consumer reaches the supermarket is more or less homogeneous around the world. But the waste along the line comes from poor countries due to lack of infrastructure such as transportation and refrigeration. While in rich countries, for the standard, all that is not perfectly aligned with our aesthetic tastes are wasted. Another problem is the emissions. This study has calculated the impact of the whole branch, including machinery and raw materials that are needed to prove it. The result is that today 20% of the total emissions of the food system are represented. And as usual, most of these come from industrialized countries. On the one hand, the system is causing emissions and thereby impacting climate change. On the other hand, climate change is also impacting the system, especially the food system. And that could be indeed a vicious cycle because you are creating a lot of emissions and not creating so much food. Another big problem is the fraud and illegality. What happened with Tesco and with the horse meat is certainly not an isolated case. A study conducted on a large scale showed that in Europe a fish on three does not correspond to what was declared on the package. In the United States, they found wood pulp at the Parmesan's place. But the most black chapter of the food fraud was seen in 2009, when Stuart Barnell sold burro di arachidi contaminated by Salmonella killing seven people and hurting hundreds of people. Just one person who tries to take a shortcut to get to catastrophic consequences. The issue that leads to all these problems is that of responsibility. Because in such an intricate system it is easier to do it frankly. For example, unloading the blame on someone else to hide their mistakes. The European Union is trying to find a solution and is evaluating a law that will determine who sells the final product responsible for what happens throughout the whole branch. But the problem is how it is possible to apply a law of this type in a system that is essentially opaque. When the food comes in and you pick it up how much can you see of the chain that the food has gone through up to that moment? For us, nothing. To solve the problem of fraud blockchain. Blockchain is the technology that has made it possible to create transparency between all the transactions in the Bitcoin trade. Who proposes it for the food system says that we can create a transparent record for all the steps that the branch is taking. But the problem when it comes to trackability is not only in the digital part it is above all in the physical part. The food is physical and therefore there will always be someone to reduce the information from the physical to the digital and vice versa. What could happen is that more or less fraudulent the fruit or the burger are associated with a label that is wrong with transparency, with transparency. Blockchain does not allow me to guarantee that the quality of the data is correct, it only allows me to create a record shared between non-modifiable parts. The other horse of battle that you can hear speak as a solution to the problems is the Kilometre Zero. But after what we have seen what can be defined local? That's an interesting question. Of course if you grow a certain food you might say the food is grown locally but to claim that everything that you need to produce that is sourced locally will maybe to be one step too far. If I grow at Kilometre Zero so next to my house on January inside a warm, illuminated mountain I am using a quantity of resources that is not sustainable. And then because we are deeply dependent on each other it is impossible to think of a solution for which every country produces everything for itself. I think it's important to diversify. To do local production next to global production So it must be, for example, integrated with a speech of this journalism. Eat what the land is able to give you at that time of the year. But if we pretend that all the annals of the branch take their own responsibilities we also have to take ours. To understand how food arrives and what are the problems linked to our distribution systems has made me reflect on how I contribute to the problems I have talked about. And above all what could I do to solve them? For example, I could stop giving so much weight to the food aesthetics. I could try to waste as little as possible buying only what I know that I will be able to eat. Then it is true that not all have the same possibilities to choose and to change our consumption. Each of us can do a evaluation of how much it contributes to the problem and how many habits it could change. Understand this we need the will. And no matter how many steps we can make in this story we have not talked about who makes all this system possible the workers. To better understand what is behind we went to know who really pays the price of what we eat. Thank you.


Hello, hello, hello everybody and welcome to the Google, the Jenkins Google summer of Docs office hours. My name is Marky Jackson. I am one of the org admins and mentors for the Kubernetes project. And Mark will not be joining us today. He is spending some great quality time with his family. So, Mark, if you're watching this later, we hope you're enjoying yourself. The Jenkins does abide by the code of conduct, which essentially amounts to be nice to everyone. And let's go ahead and get started. We have, let's look at our items from last meeting. I know there is a pool request currently open and reviews are taking place on that. Currently, Chris and I saw some of your bits on there today. Yeah, I just went over the pool request and kind of had some like formatting stuff. I think it generally flowed really well, like I thought, I thought it was very conversational that you could follow it to exactly what you needed so Give me a second, and I will pull up that full request just solid Okay, there are the comments that I see there. Xenob, do you have any questions regarding Kristen's comments on the PR. Xenob, do you have any questions in regards to the comments that Kristen gave for the PR. Can you still hear me, everyone? Oh, I've not been able to. Yes, I can hear you. Okay. To work on the comments that Kristen dropped yet, but I'll do that after the call. Can you hear me? Yes. Okay, so Xenob that is an action item for you to review the comments. Let's see timeline reminders we've gone over that December 5 project finalization December 10 mentor evaluation finalized, and then January 6 2021 the results will be announced. So does anyone have any questions or comments that they'd like to bring up for anything else? There's nothing from my end. Sure, I thought I actually one of the things I noticed when I was reviewing the startup guide is Xenob you put like a lot of really cool like extra comments like about administrating or like kind of, I guess more advanced like usage. I didn't know if we wanted to highlight some of those or like, maybe. I don't know if we wanted to have another like a tips and tricks section, or even just a few of those pieces that you had called out like into a separate section on the page or if that's something that would be as useful. I don't know what everyone thinks about that. Again, it's just kind of like a interesting thing that we could also highlight that maybe like things that maybe you saw when you were writing the tutorials like I got you. Or something that you had to remember to do. I don't know if that would be useful. What do you think is enough. I'm really not sure I understand what Christine just said. I'll do a look back and go back and see if I can find an example and then maybe I'll write in the channel but I noticed that there were some really good like, I'm going to be doing Jenkins tips that were in the document that is like I wanted to make sure like, maybe you can go back and highlight those specifically that, you know, be good for people who have not just starting up on Kubernetes, but also kind of a, they're maybe already are administrating a Jenkins. I'll go back and look and see if I can find one and point out. Okay, okay. I get why you're saying, Christine, you're saying about having something for people who are already using Jenkins on Kubernetes. Right, yeah, I kind of came into this thinking like, oh, this would be just into the meeting very cold on this idea. Let me formalize it and write it up at the channel because something else that maybe we can add as just maybe a subsection on that getting started. Okay, I'm making note there. Is there anything else anybody would like to discuss today. Okay, well if there's nothing else then I will go ahead and close out this meeting. The recording will be available on the playlist for viewing pleasures later on. If anybody has anything that like to talk about otherwise we cannot do it asynchronously in the getters channel. Alrighty. If nobody has anything else everybody have a great rest of the day Kristen and a great evening Zina. Thank you, you too. I thanks. Cheers everybody. Okay, bye.


This song is about being on the road. It's called see my baby soon It's as late as late now, and her plate is mousse. She stirs clear all the jars, and the booze. I'm gonna see my baby soon, see my baby soon. I'm gonna see my baby soon, see my baby soon. If I'm an addict, she's my fix. If I'm a guitar, she's my licks.  Gonna see my baby soon, see my baby soon. I'm gonna see my baby soon, see my baby soon. Road traveling, day dreaming, got this lazy eye. On the road feeling, gonna see my baby soon. See my baby soon, gonna see my, see my, see my baby soon. I'm gonna see my, see my, see my baby soon. I'm gonna see my baby soon, see my baby soon. See my baby soon.