So, hi everybody. Welcome to Dependencies, Do's and Don'ts. I'm Guy Barguil, head of Product Lead Growth at MEND. This is Reese Arkins VP Product at MEND. We'll introduce ourselves further in just a little bit. Yeah, for now let's get started. So, today we're going to talk about sandwiches, which is I'm sure exactly what you were expecting from a- Also Dependencies. Also Dependencies. Yeah, this is probably what you were expecting from a talk called Dependencies, Do's and Don'ts, but also we have Dependencies. So, actually we're going to be talking about a specific sandwich. It's a framework we put together called the Dependency Management Sandwich. Each layer of the sandwich actually represents a key pillar in Dependency Management. So, what we're going to do today is we're going to go from the bottom to the top layer by layer. So, we'll start a little bit with me talking about transparency, which in this context is creating visibility into the Dependencies your application is using. Then we'll go to Reese to talk a little bit about security and maintainability. Bounce back to me for a short story on why it's important to understand the legal implications of your Dependencies licenses. Then finally, Reese is going to finish off with some words on automation. The talk is titled Dependencies, Do's and Don'ts. We're going to be focusing mostly on the Do's to make sure it's practical, and that you have something that you can take home and implement. So, yeah, with that I'll introduce ourselves a little bit. So, as I mentioned, I'm Guy Barguil, Head of Product Light Growth at MEND. I've been at MEND for the past four years in the Product Department. Yeah, in my free time I like to kite surf. It's like the one with the kite that looks like a parachute in the ocean, and I play and watch a lot of basketball and Reese. Hi, so my name is Reese Arkins. I'm VP Product at MEND. I joined MEND when it was known as White Source in 2019. Through the acquisition of a company and dev ops tool, I founded called Renovate Bot, and these days I am responsible for particularly developer tooling and supply chain security as part of the MEND portfolio, and I omitted the free time part because I couldn't think of anything as exciting as kite surfing and basketball. Thanks, Guy. Yeah, no problem. Okay. So, yeah, let's get started. So, we'll begin with the bottom loaf of bread transparency. It's really the one that's holding up the whole sandwich, all the dependency management. So, again, we're going to go layer by layer, and we'll start with transparency, which in this case means creating visibility into the dependencies that your application is using. But in order to create visibility into the dependencies you're using, you need to know what a dependency really is. So, usually when I speak to developers and I say the word dependency, then they think of an open source package or a third party library and this definitely falls under the umbrella of the definition of dependency, but I think the real definition is actually much broader than that and that's going to take us to do number one, which is to treat anything that you use in your app that you didn't create yourself as a dependency. So, that of course includes open source packages. This is definitely the most common use of the word, but also Docker images from Docker Hub, common code that was written internally by other teams that you're using. So, inner source, infrastructure as code files, maybe Kubernetes manifests, and source files that you very hopefully didn't just copy and paste from GitHub into your app. We see some strange things it meant. Yeah, all of these pieces of external code, they need to be managed. So, that could mean scanning them for security vulnerabilities, it could mean making sure that their licenses comply with your organization's policies, and it could also just mean day-to-day maintenance. So, making sure that your components are relatively up-to-date and you don't amass too much technical debt in your apps, so most of the organizations we see are definitely doing the mapping of the open source components and the packages, but without taking into consideration the Docker images that you're basing your deployments on or the infrastructure that you're actually running the application on, then the job is really only being partly done. So, if you do this, then you're at a great starting point for all of your direct dependencies. But, I mean your dependencies also have dependencies that you need to consider, and that's going to take us to do number two, which is to use lock files and to consider pinning your dependencies. We'll begin maybe with the lock files, so if anyone doesn't know what a lock file is, it's just a file that locks all of your dependency versions in place, and this includes direct dependencies, of course, but also transitive dependencies, which are your dependencies' dependencies, and the reason that this is important is because it creates a situation where if somebody clones your repo and builds your app, they're going to be using the exact same dependency versions that you were using when you were building and testing your app, and this helps resolve many like works on my machine types of issues. So, it's a good practice to use a lock file, and as for pinning dependencies, so using just specific dependency versions in your package files as opposed to Sember ranges, then this is important because it helps you prevent unexpected upgrades, prevents unexpected upgrades, and basically when you upgrade the dependency, there are two risks that come into play. The first and the most common one is that you might break something, and this is a problem if you do it unexpectedly because you won't necessarily know what's breaking the build. You don't even know that you upgraded the dependency, and then figuring out what's breaking you can take a lot of time, a lot of frustration, a lot of back and forth, and large enterprises can be a huge, huge waste of time. Pinning your dependency versions, of course, prevents that, and the second, much less common, but much more catastrophic risk is that some malicious code was inserted into the new dependency version, and yeah, you definitely want to vet the dependencies before you do the upgrade, so you don't want to do it unexpectedly. But the reason I say to consider pinning the dependency versions and not to necessarily pin them is because pinning dependencies also has some downsides. So, if for example, you're writing a library that's meant to be used by a downstream developer, and this developer is using maybe a hundred other libraries, and each of those libraries are pinning their dependency versions, this developer could end up with 10 versions of the same dependency in their application, and then that brings two problems. One is just the application size perspective, if that's a consideration, and the second is just it's a burden from a dependency management perspective in general. But if you're writing a web app that's not meant to be used downstream, then pinning your dependencies is probably the best way to go for you. So, to summarize, writing a library meant to be used downstream, probably consider using SEMVA ranges for better user experience, and if you're writing a web app, pinning dependencies, probably a good idea. Yeah, and then let's move on to do number three. So, number three, it's the final one for this section is to track and communicate the projects dependencies using an S-bomb to the software bill of materials. This is the same concept as a physical products bill of materials. So, for example, you're an automobile manufacturer, then you're going to keep a list of all of the components that go into each car. So, that if there's a defective piece, then you know who has the car with a defective piece, and you can communicate it to them, and you can send a replacement part, issue a warning, or in a severe case, maybe issue a complete recall. This is the same idea with the software bill of materials. So, you know exactly which third-party components are going into each piece of software and then if a critical vulnerability is discovered in any of your applications, then you know who you can communicate that to. Well, first of all, you know that the problematic component is there, you know who you can communicate to, and then your customers can make sure they're taking the proper mitigations on their end, you can work to fix everything on your end, and overall, it's definitely the most efficient way to deal with defective or vulnerable components. One common criticism of S-bombs is that it's just like a snapshot in time, and this is a very widely used criticism, and it's only partly true though, because the only part of the S-bomb that's not really static is the vulnerabilities. So, the dependencies names are going to be static, the versions are static, and the license is static for each version, but only the vulnerabilities are being continuously discovered over time. So, if you're receiving an S-bomb, what you want to do is you want to make sure that that initial risk posture is acceptable to you, and then monitor for new critical vulnerabilities, or vulnerabilities that might be problematic for your organization over time, and make sure that that risk posture doesn't get out of hand for you, and yeah, over to Rhys. All right, thanks Guy. She'll switch over so I can do my own slides and ask you. So, as we covered the transparency part first, one way you could think about this is that there's this kind of joke people have about nobody wants to know how sausages are made, or nobody wants to know what goes into the sausage. The reality is it's a little bit like that with software, where we've had a bit of a habit of people being quite neglectful about what goes into their software, and the reality is that anyone who's in the business of making software needs to know what's gone into that software, and as I'll get to it in a little bit, a couple of slides, like there's the time for kind of excuses for that is over, and the better that software teams are about understanding what goes into their software, I think the better prepared they are for the future. So on that note, this section is security, but we're starting with maintainability. So security and maintainability are very closely related.  It's very hard to be great at security if you have a difficult to maintain project. And so this can include, for example, that you don't declare your dependencies in an easily maintainable or passable way, but it also means scenarios where you are, what we might call deep in technical debt, where you might have some dependencies which are two years behind or even more. So often software projects and software teams have an approach of like, if it ain't broke, don't fix it. And there's of course some merit to that. But the challenge is that you can never be sure that it won't be broken down the future. That one day you won't have the log for shell kind of incidents where somebody says, okay, this dependency needs to be like swapped out or updated like immediately yesterday. And so software projects which are poorly maintained when it comes to dependencies are at a much higher technical risk from a security point of view, even if at the moment, at this moment in time, they seem to look okay, even if one of those very rare projects that has zero vulnerabilities or something like that, if your dependencies are falling further and further behind, that it greatly increases the chance of there being a scenario in the future where you have a vulnerability that you can't patch quickly. You can't update because of how far behind you got. And that can be things like peer dependencies and breaking changes of APIs and things like that. So that's why maintainability is really a building block for security. All right, so the to do number one in security and maintainability, but as Guy mentioned earlier, that the title of the presentation is do's and don'ts, but we decided we should actually just try to put everything as a do. Do's are a lot more actionable than don'ts. So they're all to do's. So number one we put here, highest priority and security maintainability is a process for vulnerability prioritization. The reality is not all vulnerabilities are created equal. And the other reality that people don't like to admit easily enough is that pretty much everybody has vulnerabilities. Even enterprises using the leading software and vendor tools in this area will have dozens, hundreds or thousands of open vulnerabilities. Now, hopefully they're not critical or high, but even in that case, hope is not a strategy. So the reality is that there are a lot of vulnerabilities and you do need the ability to prioritize. That prioritization should go beyond just purely like CVSS score and things like that. So there's other factors to consider and as an industry we're still getting better at these, but for example, like the business risk and exploitability. So for business risk, that's things like, does this contain, does this application contain the type of data, which if it was leaked or exploited would cause a very massive problem due to either regulation or reputational problems. Secondly, like a business risk could also include, is this like a critical system? So for example, if somebody is like an ISP, a network provider and the system is used for provisioning new customers, the business risk would be pretty high if it was say like a DDoS risk, meaning that like, oh, we may not be able to provision customers for days or weeks if we don't fix this. Exploitability is one that for many can be difficult to measure, but like as an example of a highly exploitable case, the log for J, like log for shell, the reason why that one was essentially like dinner table talk was because of its exploitability because it was essentially very easy for people to find and exploit those who are using the vulnerable versions. That was why it rated very high with exploitability. The severity of course can't be ignored, but like if a tool is internal or it's essentially or very difficult to exploit, then even with a high severity, it could be rated a lower priority to fix than one which is easily exploitable. Naturally, the availability of fixes is one, like when there are problems which don't have a fix and would take a long time for mitigation, people generally favor the ones that they can upgrade to fix that's gonna be more of a low hanging fruit. And then the final one is reachability or effective usage analysis. And so if it's not possible to apply a quick fix, running analysis to determine if this code is actually reachable or not, which essentially is another way of saying is it exploitable because if the code cannot be touched, let's say it was the log for shell, if that particular line of code was impossible to reach due to the way you were using the tool, which unfortunately wasn't very common for log for J, but if it were impossible to reach, then you're not truly exploitable. It's still a good idea to get rid of the vulnerability through upgrading, but it's a very important factor to know if that line of code cannot be touched. For example, the Go ecosystem has recently attempted to do this actually as part of their free and open source approach where they're trying to bring reachability analysis into vulnerabilities to let people be able to prioritize. Of course, commercial solutions, including men, have this capability as well. So do number two is then having a process for remediation and acting quickly. So a favorite quote of mine is the enemy always gets a vote. And so this is a little bit different to most other security concerns. So if you have a security concern in your own proprietary code, like, oh, somebody reported to us that it's possible to leak user details with a very carefully crafted string or playing around with cookies or CSRF or something like that. It is feasible that you could look at that and say, okay, well, it was reported to us by like a white hat researcher. The chances of it being exploited by someone else are hopefully low at the same time. We have like a week to fix or something like that. Let's, you know, a week is a reasonable point. But in open source vulnerabilities, generally the baddies, the attackers, they will know about the problem as fast or faster than you will as like a user of open source. And so, you know, by that we mean they get the vote. Like they get the vote, whether they're gonna try to exploit you, you can't, you don't just get to choose, we'll wait a week or a week is fine. In open source vulnerabilities, that attack always gets a vote. And in the case like log4j, they were voting right away. They were, you know, scanning and attempting to exploit. So you don't get the only choice, the only vote about whether to act quickly when it comes to open source security. I, yes? Yes, please go ahead, yeah. Do you have data about that? So, Can you repeat the question? Yeah, sorry, I repeat the question. I do have data about whether open source vulnerabilities are exploited faster than non-open source vulnerabilities. The answer is no, not on that, exactly what you're asking, because the challenge can be that the people that actually are exploiting are generally not like documenting their, you don't know what you don't know. But what there is data on, I don't have it offhand, is about how quickly open source vulnerabilities are getting exploited over time. So if you go back say five years when maybe it was, finally the first point was mainstream that, hey, there is CVEs and reporting. At that point, it might take weeks or months before people would be attempting to exploit that. And we're seeing that in some cases, drop down to hours. So again, harping on the log for J1, there was people running scans, which could be detected, right? People have the ability to detect scans. People were running scans based upon like essentially almost like rumors on Twitter before it was even like mainstream in databases. That was a very exceptional case, but still people are seeing it go from weeks to days down to hours. It's getting almost to the point where you need to assume that it's kind of real time, that once you hear about it, there is someone attempting to exploit you. I think in terms of certainly future planning, like we'll say the next five years and sooner, you pretty much have to plan on that fact that the attacker will be responding in real time. Maybe even the same way that you see people have built automation and bots to trade on SEC disclosures and things like that. I think you'll see people attempting to even automate, maybe even like GPT-3 like or something like that on vulnerabilities. I think that's the world we have to plan for if it's not already happening. All right, so I think I kind of covered all that. Actually, the last point is really important, sorry. You need a process for publishing such fixtures to production. So during the log4j, again, for example, we had a customer who was very satisfied with their ability to remediate quickly, and that was because they had the transparency part that Guy talked about earlier, like they knew what they were using. When they heard this news, they didn't have to say, okay, everybody, let's go scan everything and see what we have. They were confident that they were already scanning everything and they knew what they had. They then proceeded to remediate, again, ideally automated, but when they'd done that, they'd remediated the problem out of all of their source repositories. Their comment to us was the job's only half done because now I have to go track down all of the images we built in the past that contain the vulnerable code and also all the production environments that are running that and also kind of work forwards and backwards from those. So your ability to respond to vulnerabilities and security is not just how quickly your developers can, but it's also a DevOps challenge, how quickly you can get that into production as well. A problem which is remediated only in a source repository, but not in production, is essentially not remediated at all. Okay, so this is an oldie, but a goodie. I know there's at least two or three presentations this week with Equifax still. This is from 2017.  So even back five years ago, this term I was using for a long, long time ago in open source security, already it was considered no excuse that if you have known disclosed open source vulnerabilities that you do not upgrade and do not patch, there is no excuse for that, you are liable. Equifax were held liable. They were brought in front of US government and things like that. So we're five years on from that, from this point where people already kind of said in a mainstream way that there is no excuse. All right, so now getting a little bit more into the proactive way. To do number three is ensure your dependencies are actively maintained. So before I've been talking about this concept that there is a fix that you can apply, but there can be scenarios where vulnerabilities are found in open source packages where there is no like essentially no fixed inversion. And that can be because the library is no longer maintained, that there wasn't somebody around to publish that fix. Or it may have been because it was irresponsibly disclosed through an issue or a pull request. And because this project hasn't been released in a year, it took days or even weeks for that project to release a new version. So it is useful to understand in dependencies, like to audit them regularly. Like when was the last release? If there hasn't been a release for a year, in rare cases, it might be because it's feature complete with no dependencies, but in the majority of cases it's because there's something wrong with the maintainability of that open source project. Are commits happening on the source repo? Are the issues and pull requests getting responded to? Again, if it's feature complete, you probably don't see issues and pull requests piling up, but if it's not, you will. And then importantly, are the security patches being applied? I mean, that's probably a very trailing indicator. If you're looking at a dependency and seeing unapplied security patches, it's probably because you're aware that it's the weak link in your supply chain. So as well as keeping your own clean desk, it is an important characteristic to have maintained dependencies. So final to do for security maintainability is to be proactive and maintain recent dependencies. So we have a figure here, 90%. I'd like to explain that one. We looked at disclosed vulnerabilities in the NPM ecosystem in 2021. So you look at the CVEs and then you look at the fixed recommendation like fixed inversion 1.2.3. And then we compared the disclosure date of that vulnerability to the published date of the earliest fixed inversion. And what we found was that in 90% of cases that fixed inversion was published like same day or earlier than the disclosure. What a lot of people don't realize is that vulnerability fixes are often made days or even weeks before the disclosure. They're often done in a discrete way, like fixed memory problem or revalidated string or something like that. They don't say, oh, fixed the vulnerability. Sometimes they do, of course, and there's people looking for those. Both good and bad, white and black hat we'll say. So this is not like what I would call a simple recommendation, but if for example, if all you did was just be up to date with dependencies, just kept the latest versions, just let's say even blindly. Then in 90% of the cases you would automatically have remediated any vulnerabilities that you could have. Because in 90% of the cases of CVEs, at the time you hear of it, the latest version is non-vulnerable. So this is also a big change compared to the past where you used to maybe have to apply like monkey patching, like manual patching of dependencies. Instead, today you mostly can just upgrade. All right, so the benefits of up to date dependencies, it's vulnerability prevention. In some cases you can actually, depends how you define it, but you can have upgraded to the fixed version of a dependency before it is a known vulnerability. The point being, you can hopefully have already upgraded to a non-vulnerable version before the people who might attack you are even aware that the old version was vulnerable. Of course, you get the latest features and APIs and bug fixes. This is just a general software benefit. And then the final point is this, avoiding zero-day fire drills. So by this we've borrowed a meme here. This is the challenge I was describing earlier, where you've got like say an out-of-date project, you have a vulnerability alert saying you must update. And you've really got this choice between do I remain vulnerable until I'm satisfied that this fix is okay, that it doesn't change anything for me, or do I kind of succumb to the pressure of updating without adequate testing? That's the situation you find yourself in when you have a poorly maintained project, where you're far behind in dependencies. All right, so final point here about this, technical debt is that when we say to people, stay updated with dependencies, a lot of people do have a hesitancy in that. They say, well, we don't have good tests. All the people who wrote this code left long ago and we're just maintaining it. And I don't really wanna take responsibility for it. So we believe strongly in safety of the crowd in this case. So as an example of safety through crowd testing, you may have even weak or no tests, but if there are hundreds or thousands of other projects who've tested the same upgrade as you're about to apply, and there is a 98% test passing across that crowd, that would be a very positive indicator to you. Similarly, crowd adoption, safety through crowd adoption is a second factor. So for example, if there is an update that you should apply and you're a bit nervous about it, but you find out that 25% of users of this package are already running that version in production, that again would be a very strong indicator. Even if you yourself have no confidence based on your own tests or your own technical debt situation, if you know that a new version passed tests and is widely adopted, you may be able to kind of take that leap without still having confidence in your own abilities. All right guys, so last one here. So wisecrack, but updating dependencies is like going to the dentist. If you go once in every five years, it's gonna hurt. So that's a good way to summarize. All right, yeah, so the last two sections are gonna be shorter than the first two. I'm just gonna tell a short story now about two companies called Small Comp and Large Comp that are in the middle of an M&A. It's based on a true story by the way from 2018, but the company name Small Comp and Large Comp are obviously fake for the sake of anonymity. So we have Small Comp, which is a small software company and Large Comp, which is an enterprise scale software company. And as part of any standard like M&A or OEM agreement between two software companies, so Small Comp was required to do what's called an open source audit, which basically means to list all of their open source components as well as their licenses so that Large Comp can ensure that they're not inheriting any legal risk with the taking of Small Comp's dependencies into their code base. A little bit of background just on licensing. So some licenses for software are very permissive, right? All code is licensed under certain legal terms. Some license is very permissive, like MIT, for example, where all you're really required to do is to pass on a copy of the copyright and the license, and then you can do pretty much whatever you want with the software. And some are less permissive, like GPL, for example. So these are copy left licenses. So if copy right means all rights reserved, copy left is the opposite, which means no rights reserved. So basically anything that's attached to this component has no rights reserved. It has to be open sourced and anybody can use it under the same terms. And Small Comp actually found a dependency license under AGPL, which is an even more restrictive version of AGPL inside their software. And what happened is that the large comp immediately took action on this and they took $4 million out of the deal and put it into an escrow on the side. Under the following terms, that Small Comp had to remove every single trace of the AGPL from the software. They had to completely swap out the component. And also 80% of their customers have to deploy the updated software to production. All this has to be done in a two year timeframe and the related cost of development or deployment are gonna be deducted from this $4 million. So if it costs $500,000 to develop and deploy the fix, then Small Comp's shareholders are only gonna receive $3.5 million from the deal. It doesn't sound too complicated, right removing one open source component and deploying it to production. But Small Comp actually had two main obstacles during this time. The first was that just removing the component was estimated at like one year for one person of development in QA. And again, Small Comp, it's a very small company so they don't have many resources and they can only afford to put one person on this task. So that's one year out of the two pretty much gone right there. And the second is that Small Comp's customers are hospitals and if anybody's here has ever worked with hospitals, you know things are very, very manual when it comes to like software and deployment. And yeah, so Small Comp's technicians were actually required to fly out to all of their customers across the globe and persuade them to update the software from like the AGPL version to the non-AGPL version all within the year once the fix was ready. And it's not an easy task but they were actually able to do it and they fulfilled the terms of the escrow after one year and eight months and it only cost them $500,000. It's not too bad I guess but still 500K for one bad license is quite a price to pay. At least there was a relatively happy ending here. And yeah, I think there are two things that we can take away from the story pretty much. One from the developer perspective, the other more from an organizational perspective. The first is that as a developer then you really need to understand like your organization's legal policies. You can't be a licensing expert yourself and or you can't be expected to be a licensing expert yourself and you should have somebody who is an expert on that create clear policies and you just need to make sure you understand them so you don't cost $500,000 worth of damage. And the second from an organizational standpoint is that you need to make sure that first of all you have these policies and that you're also scanning and making sure that when a new component is included then it has an acceptable policy to you and also during upgrades you need to make sure that the license isn't changing. So a dependency in version 3.0 can have license X and 3.1 can already have version Y. You need to make sure the license is staying consistent when you're upgrading. Yeah, Rhys, final layer. Thanks. So the final one is automation. Let's skip it to the slide. So essentially what we're looking to do is to automate all of these that we've spoken about. So in terms of transparency that was like knowing what you have. So automated scanning with every build, every day. That's essentially the key requirement there. Like I mentioned in the log for J scenario you want to already know what you're using not have to go out and scan when you think there might be a problem. That's preparation. For security, like automating the prioritization or remediation is really important at any scale because it's just, otherwise it's very hard to manage things manually if you don't have an automation of that. For maintainability, automate dependency updates. So keeping relatively up to date is something that you shouldn't burden your teams are doing manually. Use a solution like Renovate Bot from Mend, for example. There are alternatives as well, but do something to stay up to date with dependencies. It's a good way of saying you have a good security posture if you're ready to respond. And then finally, the legal, like Guy said, really this one is probably the best case scenario for breaking builds. So there was a pull request that introduces a license that doesn't comply with policies. Really, you want to stop that as early as possible. You don't want that getting certainly not into production. So the best place would be to scan and block builds for that. So do that in an automated way. Don't expect developers to be manually inspecting every dependency change in a lock file and every license and things like that. I think we're good, yeah. Thanks, everyone. I think we have time five, yeah, five minutes for questions if there's any remaining. You ask them and we'll repeat them. Yeah, hi. Yeah, thanks. So the question from Cornelius was about automation and about prioritization and that some of those factors are very hard to automate. I guess, I mean, this one was a sponsored session, so I guess I'll just take the opportunity to say this is one that is very hard to do without help. I mean, the reality is it is a very hard challenge, the automation, the prioritization. So it can be a challenge probably to do this one with cobbling together your own tools. There are companies and not ours, for example, that specialize in like exploitability scoring and things like that. So in general, most companies would need, would not have the capabilities of doing like prioritization scoring and automation on their own. Also for reasons like the crowd, like I mentioned, that sometimes some of these, this information such as like, is this being actively exploited or something or attempted to be exploited is not easy to gather on your own. That is data that you need to kind of pull in in real time from a third party source. So this will be one where I would say like, realistically, you need to kind of get help on that, there does need to be like a system which can sort and prioritize for you on these matters. Some of the factors though will need to be internal. So like no third party vendor can say, tell you, oh, this app is public facing or this app is internal only, or this app contains like personally identifying information, this one does not. That's a type of like metadata tagging that will always need curation and annotation from development teams to help whatever system you have to know. I'll summarize the question first. Thank you, it's a very good one. So it's about, you know, it's very common, especially saying Dockerfile, suggest like, you know, not specify exact versions and just be like, hey, let's install, you know, Debian and Appget and things like that. So you're correct, it's very common and it's not irrational, like it makes it easier on people and it means that when they build, they get the latest versions. And 99% of the time, latest versions are gonna be good for you. The challenge is that it's not deterministic and that, you know, one day everyone can just come in and the build is broken for everybody. Like no one, everybody running Docker build. It doesn't work. So I think that the future of software is not non-determinism, you know, that for example, when building images, this concept that you have Dockerfiles and run Appget, you know, that's a very, that's like taking it back 10 years ago in software where people would just pull things in off CDNs or copy paste off internet sources. The reality is we need like better package management and we need the ability to lock dependencies and when building an image, be able to like reference essentially a manifest and ideally a locked manifest so that you have like repeatable builds. Something that you can do to make things a little bit better in the short term is attempt to use exact versions where it is possible. So where you can actually install a specific version of a dependency, including with apt, do so. On the flip side, then people will say, yeah, but then I'll forget to update it. So that's where you need the automation part, you know. So pin it to an exact version and then automate the updating of those exact versions. This is a scenario where automation gives you the capability to do things that like realistically is beyond humans alone. Like no one is so worthless that they should just be checking non-stop, you know, Dockerfiles for versions scattered throughout and updating them manually. Please go ahead. So the question is about lock files and they're not present everywhere. So do we have recommendations for how to deal with that? And I think we have a stop. So Guy, quick one. We don't have a stop or anything. Okay, yeah, you can answer. Yeah. I mean, if you don't have a lock file and you can't lock like transit dependency versions in place, then there's nothing you can do. You can, first of all, you can lock the direct dependency versions in place and you can get a lot done that way. Yeah, I don't have too much time. Yeah, there are ecosystems lacking in lock dependencies and it's low hanging fruit in terms of security. Like the industry collectively should be doing better. It's like, you know, Maven, Gradle, NuGet does have lock files out as possible. So that has improved. But in general, that is a weakness in those ecosystems that should lead either to those ecosystems improving it or to people who care about security seeing if there's alternatives to those. Okay, we've reached our time. So thank you very much everyone for attending. Thank you for the questions. And as I understand it, this will be available on YouTube in the coming weeks thanks to the Linux Foundation. Thanks everyone. Thank you.


Next write down, okay write down, nomenclature of alkene and alkyne, in this the write down to select the longest carbon chain, select the longest carbon chain which has maximum number of double or triple bond present, select the longest carbon chain, longest possible carbon chain which has the maximum number of double or triple bond, means the double or triple bond must present in the primary chain, the parent chain, double bond is preferred over triple bond. How is it wrong? What does it mean? In the molecule if you have double or triple bond and choose in the initial, yeah then we will try to give least possible to the double bond. Sir, double bond chain has two double bonds and another chain has two triple bonds, means if the parent chain takes the double bond. Sir, what is the double bond? This one alkyne, what does it mean? We show examples, what if you do double bond? Sir, there is no alkyne with double bond here, all alkyne has two double bonds, it is two pi bond not double bond, two pi bond. Alkyne can't have double bond here, because then you give priority to the double bond to become an alkyne small bond. Like an alkyne, double bond, but we give priority to a double bond. So for it to be an alkyne there should be zero double bond. No, how? Because if there was a double bond we give that chain priority and it will become an alkyne. Yes. Sir, how would you say double bond? I will give you the example, suppose my guys are like now C, F, D, B, C and single bond, C and single bond, C, double bond, C, F, this is possible. Sir, is there an alkyne or an alkyne? So that's why it's a normal feature of alkyne and alkyne, it is a mixture of both, and it's possible we have double bond and double bond, because balance is complex. So what is this thing called? This one, me. One by one minute, I said jump, you cannot jump. What I was discussing. Double bond preferred over double bond, right? You see this example. Suppose we have a molecule C, H, double bond, C, H, single bond, C, H, C, triple bond, C, H. This is the molecule. C, H, 2. C, H, 2. Okay. Now in this you see the position of triple bond and double bond. If you start from this side one, if you start from this side one, right? So we have the same position on both sides. So we'll get priority to the double bond. So we start numbering from here. One, two, three and four. Okay. So name of this compound will be butte. Butte, 1, E, 3, I, and this will write alphabetically. E we should write first and then Y. Butte, 1, E, 3, I. One more thing we have here. This E you have to drop. This you should not write. It should be E and not E and E. If you write E and E, you'll get 0 again. Sir, is there a double bond for triple bond? E, E and I. No. In numbering we'll prefer this. But this we'll write not the vertical sections. What? I know sir, I have to E. So why are we dropping this E? For that we have a reason. Okay. So for this write down one note here. Because if we don't it becomes E and Y and that's weird. With this we don't have any personal grads with this E. There are rules. That's what we have in dropping it. This E is there because again this is not called up by any other elements like A, I, Y, X and Y. A, I, O, something like that. Y also becomes Y. So when we have to drop this E for that we have a rule that we'll write down. The terminal E in the name should be dropped when it is followed by a suffix beginning with A, I, O, U and Y. E is not there. Okay. So when it is followed by these suffixes beginning with these letters like here we have Y. So this E is very important. It's very important. This note is very important. You must take care of this. Sometimes what happens in the option they'll give you this name and this E will be there and one of the options will be none of these. Okay. This is not dance. Understood. Another example you see. What is the name of this compound? CH2 double bond CH. Single bond CH, double bond CH2. Okay. So that will like be like, okay. You called me. You put a C. I put a D. Super. Ok. Super. Super. Super. Yeah, super. Super. Super. Super. Super. Super. Super. Super. Yeah. Super. Super. Super. Super. Super. Super. Super. It is 2 methyl or 4 methyl, double and triple bond will give priority over the substituents. See any substituents if you have, then will give priority to the double bond or triple bond over the substituents. So, the correct number will be from this side 1, 2, 3, 4 and 5. So, what is the name? 4 methyl. Spend 2 i. The name of this compound we have dienes right. So, we call it as hexa diene, hexa 1, 3 diene. Sir, can we write 1, 3 hexa diene? Yes. Here also, buta 1, 3 diene. Whenever we have diene, then we will write, we don't write buta. We will write buta, hexa, penta. Try it actually. Try it. But sir, it is followed by a prefix i, 2p, not 3p. It is followed by the prefix i. This i. Here we have, why that's why we are dropping this i. Oh right, sorry. Sir, fill it down first one. First one, this one. Sir, is it fine to write 1, 3 diene? 1, 3 diene. 1, 3 diene. Yeah. This is also right. 1, 3 hexa diene. Okay. What is the name of this compound? Cyclosautic. Sir, will you start from this end of the compound of that end of the compound? No way, sir. Can we use… Tell me the position of this study. You… Sir, can we start from this end of the compound? Sir, can we start from this end of the compound? Sir, can we start from this end of the compound? Sir, can we start… Okay, stop. See whenever the ring contains double bond then we… When the ring contains double bond, that means always is first and second position with that double bonded carbon atom in it, right? When the ring has double bond right down, in this right down note, when the ring contains double bond, then we always give first and second position to the double bonded carbon So, now you see here, this can be first or this can be first, both possibility. If this is first, one, then it is true, we cannot take this as two, because first and second position will have to give to this carbon atom. So, one, two, three, the position of this will be six. But if you go this way, one, two, three, so here we have the least possible number, correct numbering is this. Here also the rule is what? We always give first and second position to the double bonded carbon atom, so you don't have to write x1e, simply hexene. Cyclohexene symbol, because it is understood that it is the first atom, the rule we have, first carbon atom will have the double bond. If you write x1e, it is not wrong but not required, because the rule is what? So, let me finish this. So, if you have two consecutive terms, consecutive is, you can't have a ring, in that ring it is not possible, because high angle is stable, not stable. If you have double bond here also, it is sp hybridized. So, the angle is still very large. Generally, the ring is two consecutive double bonded molecules. Sir, it is a 3-bromo, 1,4-cyclo-battery. Or a q3-bromo. 5-bromo. 5-bromo. 5-bromo. 5-bromo. Say, what are the things we can do, you see? One thing is what? We can take 1, 2, 3, 4 and 5. But then, that double bond is? Okay. Another possibility is what? Oh, priority has to be double bond. Yeah, so, that's a 5-bromo. 1, 2, 3, 4, 5-bromo. Okay. Now, in this way, you see, the position of double bond is first and third. Yeah. Here, it is first and fourth. This double bond is preferred over the locans, bromine and all, whatever locans we have. So, this numbering is not correct, because the double bond has higher number. Sir, but this we won't see that. So, fine. We won't see that. No, we will prefer this. Double bond over the locans. Okay. This one is correct. Double bond over the locans. Double bond over the locans. Double bond over the locans. Double bond over the locans. So, the sum is the same for both. So, the super has one and double bond. So, what is the difference?  So, here we have, you see? No, sir. Take 2 as 1 and 3 as 2. Size? How do you think? That's not possible. One is normal. No, that's not possible. No, sir. No, no, sir. One. One. One. Ten. One on the right. One on the right. How do you think? First and second to the left. First and second to the right. Again emotional error. First and second, okay, sir. We can reduce it, but according to the rules. Okay. So, this is the correct bond. Bipromo. Bipromo. Bipromo. Bipromo. Bipromo. Bipromo. Bipromo. Bipromo. Bipromo. Bipromo. I don't know what order. Pat者. Penta. I. One on the left. One on the right. One on my 3. Ten. Nine. Ten. Ten. Ten. Nine Nine. Wait, wait. Let me finish this after this video. Not here. C-H-2 double bond C-H-2 double bond C-H-2 So, do you count the diazons as C-H-2 double bond C-H-2 double bond C-H-2 double bond C-H-2 double bond must be taken to the parentage The smaller ring will be the parentage, the higher the number of fiber atoms One comma two is not required because when you have one comma two is not required because when you have props, this is the only position you are left with. There is no other way where you can place the double bond, propa diene. See in this one, when you have double bond in the ring and any double bond carbon atom, if it contains any substituents, then we are bound to give first position to this carbon atom. In the sixth group, half sixth group, some of blocans we will not follow. Whenever the substituents present onto the double bonded carbon atom, that carbon atom will be the first position. So, if it is first, we cannot take this as second because second will be this. Substituents first position. If it is present onto the double bonded carbon atom, another rule is what? If any substituents present onto the double bonded carbon atom in the ring, then that carbon will be the first carbon atom. Question will be the first carbon atom. Then we will see alphabetically which one is the first one. Or if it is same, then we will see the sum of blocans. So, in that we will see. So, that is sum of blocans. It depends what position it is, how you are going. So, when you see the molecule, if you follow this rule, then you will understand what is the correct numbering of that molecule. What is the name of this compound? Six-chromo-1-clotocyclohexene. This one, this is one because bromine comes first alphabetically. This is one, this is two. One-chromo-2-clotocyclohexene. One-chromo-2-clotocyclohexene. In this one, the only difference is what? Instead of this bromine, we have cyclo-propyl. So, name will be 5-cyclo-propyl, cyclo-penta-13-tion. Okay? Now, in this one you see, this ring has double bond. So, this is the parent chain of this compound. However, the number of carbons it will give priority to the double bond. Now, in this one, this carbon is one, this carbon is two, this is three. Because double bonded carbon at a must have first and second position. Three-cyclo-penta-3-cyclo-propyl. Okay? Got it? Why don't you do some practice so you can do it? Now, the best thing is what you can do. What is the double bond? What is the double bond? How do you name the other one? Propenyl. Cyclo-propyl becomes cyclo-propenyl, cyclo-propyl. If it is double bond, then it is cyclo-propenyl. If double bond is there, then simply cyclo-propyl. Right? If it is placed at the substituents, then it is cyclo-propenyl.


Welcome to ToffeeTV, it is the Everton News Daily. Marco Silva has held his press conference ahead of the trip down to Southampton on Saturday and has jumped to the defence of Ray Charleston on the accusation of him being a diver. He said he's not a diver, he said he's never been booked for diving, so that isn't a problem. He did say they are telling him to stay on his feet as much as possible. The coaches are saying he's got to be strong when he's telling me he's got to be strong but he said he's not a diver. He's been here in the Premier League for just over two seasons now and has never been booked for diving, so how can he be a diver? So interest and very strong from the manager got quite animated when talking about it, obviously something that he felt he had to get out, something that sounded a little bit like he'd already decided to speak about before the press conference. It's good to see other elements of the press conference he was in has animated and seemed a little bit more laid back, especially when he spoke about VAR and the impact it had on Everton. He said they're going to have meetings on that and obviously there has been a letter sent to the referees association in the Premier League from the Everton Fans Forum and the club have backed that without getting too involved. He never got too animated about that which I felt a little bit annoying personally. I thought there was a chance and stuff he handled well but I thought he could have done and should have led the club a little bit better in the VAR discussions that he was asked about. Just on the VAR, three or four times by this guy, Vinal Connors, who is obviously in Evertonian but he didn't really want to go too much in that, just saying he respected the decisions and they have their own feelings on that but I felt like he could have gone a little bit more into that but on Rich Arleson obviously, just said he's not a diver and he sort of hinted that other players maybe have been booked recently for diving and Rich Arleson hasn't so you can't call him a diver if he's not been punished for being a diver. I know there's a lot of fans out there who do believe Rich Arleson is a diver or certainly believe that he doesn't help himself by going down so easy and maybe that if he stood up and tried to protect the ball a little bit more that he would get the decisions when it matters. I do believe there is a little bit about that, I think Rich Arleson needs to pick and choose where and when is the best time to try and get the files but certainly in the last two games Everton have been denied Stonewall penalties from me because referees have decided against it, now that shouldn't matter if someone has a reputation or is gaining a reputation, if the files are as simple as that and it's where we are failing in this country and where the VAR is failing and where the Premier League is failing and most of the ball where the referees are failing so yeah. Also in the press conference he discussed the possible absentees for the weekend he said Fabian Delphi is very very doubtful he picked up a hamstring injury towards the end of the game on Sunday and he's very very doubtful but he did say Morgan Snidland is ready to go in there and obviously Everton facing a bit of a midfield crisis at the moment with only Tom Davis and Morgan Snidland fit in those two positions of course we've got players like a Wobby and we've got players like Guilty Sigerton who can play in midfield as well but we are down to the bare bones and we could see someone like Benny Benningham on the bench or I imagine we will see Benny Benningham on the bench. The manager was also asked about Andy Gordon as well and he said you know those players are getting close and he said that more recently he said yesterday that Bernard he feels should be back or he wants him back for after the international break so Bernard hopefully this will be you know this hopefully will be the last game he misses or maybe the knowledge game as well but we should see him back and then obviously the barman is still a couple of months until we get him back and on the situation of Gomez he said it was great that he came in and seen everybody he's gone home now and he said it is possible that we will see him again this season he said he spoke to the medical staff at Everton and he said there is a chance that we'll see him back on the field again this season and obviously that would be barring any complications to the injury whatsoever the surgeon said was very happy with how it went and the club were quite happy it's gone home now he'll rest I'm sure he'll be given a plan because they do say now straight away that player shouldn't just sit there with a foot in plaster it should they should start moving get that board circulating around as much as possible of course this injury was a lot more a lot more of a free injury than just a simple broken leg so we'll have to see what happens with that he also mentioned the fact that Sun had text Gomez to give him a personal apology and we've seen some well something in the celebrations and Sun's goals last night which were referencing Gomez as well but in terms of that any way you any way you want to pace I think it's nonsense which I have stated yeah so we're looking threadbare for four Saturdays trips to Southampton but this is where players have got to roll up the sleeves and just get get the job done because otherwise we are in a mess and the Southampton manager has already said this is a six-pointer so we've got to go down there and just try and get the try and get a job done and I tell you what if we did go to get a job done down then we did bring back three points it'd be a massive boost I think for everyone at the club and and a massive boost for the fans as well and get really really be huge which not only the three points but the fact that we do seem to be really really low at the moment and a lot of things are going against us so you know this could be a massive turning point on Saturdays if Everton can get three points against the team who let's not forget lost their last game 9-0 and the one before that 4-1 I think so yeah up to Everton to do that at the weekend international breakers coming up obviously next week Luca Dean is back in the French squad Michael Keane is not in the England squad ahead of their their games Jordan pick for days and five in Delphi's as well you know he's got an injury so I imagine he'll pull out at some point but Michael Keane is not in the squad which is no real supplies after him after his last performance for England was utterly terrible and I'll be honest I said a couple weeks I didn't think I'll ever see Michael Keane play for England ever again and I don't I stand by that so he's not in the squad which from an Everton point of view is I think it's positive news because I think the lab now has to again get himself sorted and after start showing performances if he's in the team too many players I think at Everton I've had it too easy whether it be at Everton on international stage and need to get back to basics so hopefully Michael Keane is one of those players so there you have it this has been the Everton News Daily the match preview is up for the Southampton game now on YouTube starting 11 will be available tomorrow it'll be available for our viewers on patron tonight and as well as the footy show which is also on page and so check them out as well as our live shows thank you for watching toffee TV don't forget if you haven't already subscribed please do click the bell for the let's and as I said if you want more great videos join us over on page and see you later


Hello everyone, welcome to the talk, building your first Bosch release. So we're going to talk about what is Bosch, what are releases, and how to build them. So what is Bosch? Bosch is an open source cluster management tool developed and used by Pivotal and other companies to efficiently manage large scale systems like cloud funding. It can handle infrastructure provisioning, release engineering, configuration management, and deployment life cycle of a complex distributed system. Several people asked me during CF Summit if Bosch is something like Chef or Puppet. Well, some features of Bosch can be compared to configuration management systems, but it does much more than just configuration management. It can manage deployments that span hundreds of VMs, providing all required tooling for release engineering, rolling cluster updates, operating system updates, real time monitoring, and recovery. It can utilize your infrastructure efficiently by provisioning, allocating, and releasing resources for your deployment in a controlled manner. Rolling updates is a hard problem to solve. So many systems leave it up to operator to figure out the proper order of updates and minimize the number of disruptions to production systems. Bosch deployment manifest is completely declarative. The system itself takes care of understanding what is currently running in your cloud, what do you intend to run, and figures out the best way of running updates, minimizing the number of disruptions. If something did not change, it's not gonna get updated, only affected nodes will be touched. Release engineering is part of Bosch. It is opinionated about structure and lifecycle of the release. It provides required tooling for creating and updating your releases. It is easy to iterate on your releases while developing and create production releases. Everything is fingerprinted and incremental. If something did not change, it's not gonna get included in release, rebuilt, and deployed. Bosch can perform all kind of complex updates, including operating system updates. So operator can specify the OS image version he wants to deploy and Bosch will take care of recreating every node in a deployment with the base OS image, with the new version of base OS image. Bosch provides a built-in mechanism for detecting potential infrastructure problems. It provides recovery mechanisms for failing services and inconsistent infrastructure state. As you can see, Bosch takes a holistic approach to managing your deployments. It is a prescribed solution that will take care of your complex workloads every step of the way. Let's quickly take a look how Bosch works. So the main Bosch component is director.  You configure director with the cloud config, which contains your cloud provider properties that define types of resources that your deployments can use, like networks, VM types, disks. Director interacts with cloud providers via something we call cloud provider interface, or CPI. CPI abstracts away infrastructure details to a well-defined interface. It has methods like create VM, create disk, attach disk. This way, if you have your Amazon or GCE or any other infrastructure, you can make it work with Bosch by just implementing the CPI. We officially support CPIs for AWS OpenStack, vSphere, and other infrastructures, but since it's all open source, you can add support for infrastructure by implementing the CPI. Bosch creates VMs from a set of predefined templates, which we call stem cells. You can think of a stem cell as AMI for AWS, for example. And at its core, stem cell is a base OS image with some hardening on top of it and Bosch agent. Bosch agent is a process that runs on every VM. We officially support stem cells for multiple infrastructures. You can download them at bosch.io website, and they're constantly released with new security updates to kernel and base OS packages. So once VM that was created from stem cell boots up, Bosch agent starts running on that VM. And agent bootstraps itself. It fetches information provided by CPI, and that information tells agent how to interact with the rest of the system. So once agent is ready, it starts reporting to director, and director starts issuing commands to the agent to configure VM in a certain way, like configure networks, setup disks, and install software. Agents are also responsible for supervising jobs that are running on that VM and also perform some housekeeping, like rolling over debug logs, reporting resource usages, and et cetera. In order for software to be runnable on Bosch, it needs to be packaged into release. Manifest is where it ties it all together. Manifest defines your deployment layout, what releases to deploy, and what stem cells to use. So let's quickly take a look at deployment manifest. So manifest consists of the following sections. It has some deployment information, list of stem cells to use to provision VMs, releases to deploy, update section defines how to perform a rolling update of your deployment, and instance groups define what software to install, what stem cells to use to provision VM, and what jobs from releases to install on that VM. So what is release? Let's say you have some source files, and in order to deploy those source files, you need to package them into release. This is how Bosch understands how to run your software, how to deploy it. Release contains all the bits that needed to be deployed, like your package contents, installation scripts, and configuration file templates. So every release consists of the following parts. It has your software source files, it has packages that define how to install your software, and it has jobs that specify how to run your software. So let's take a look at example release, simple release. Let's say you have some goal application, you will need to include its source files in a source directory. Then in order to install those files, you will need to provide a goaling binary. So usually releases live in Git repos, and large objects are not included in release itself. Instead they're referenced as some block store identifiers like S3 or Swift. And Bosch will take care of downloading those binaries and including them in your release once you're gonna create your release for the first time, and then it's gonna cache them for subsequent use. Also you need to provide a packaging script where you will specify how to install your software. And then you'll have to provide the startup script that will define how to run your software on Bosch. So let's take a look what Bosch will do, how it's gonna deploy your release. So it will start by compiling packages that were updated. It detects what source files were changed, it will create a predefined number of compilation VMs, and it will start compiling all your source packages that were changed. Packages might depend on other packages and Bosch will take care of resolving dependency graph and making sure to provide all the packages that your dependencies need on the node that runs them. So once the packages are compiled, Bosch will store them in its block store. One of the nice things about this approach is that Bosch only compiles packages once, and then it distributes them across all the nodes that need those packages. So this way, scaling up the number of instances is not slowed down by package compilation because Bosch already has all the packages pre-compiled in its block store. So release engineering is completely automated in the sense that if you change one file, then every package that is using that file and every job that is using that package is going to be rebuilt for that new version. If something did not change, it won't get rebuilt. And one of the design principles of Bosch is that it does a minimal amount of work to deploy the new version of your software. If something did not change, it's not gonna get updated, restarted, and deployed. Whether you're working on a new deployment or an existing deployment, the flow every time the same. You create a new version of your release. You upload that version of your release to director. Then you can make some changes to your manifest file, and then you would run Bosch Deploy. The deployment process will reach out to every node in the existing deployment and try to match its state and its actual state to your desired intent that is declared in your deployment manifest and by your release. Release and deployment manifest are completely declarative. Bosch makes sure that record of intent matches the actual state of the system. So let's take a look how you can configure release. You can specify a list of properties in your job manifest file and then you can reference those properties in your release configuration template. Also, you will provide values for those properties in your manifest. These properties will be filled out by Bosch when it's gonna process those configuration file templates. So this is how you configure your releases. In case if you wanna connect two services together, you can use links feature. So let's say you have a web server release and your web application needs a database access. So it can define that it needs these database properties. Then your MySQL release on the other hand can say that it provides these database properties. So what that means is that if these two jobs are deployed together, Bosch will wire them up automatically and it will make database properties available to your web server job. So now your web server job can reference those properties in its configuration templates. Let's do demo. Okay, so I have a concourse release deployed and let's take a look at it. So this is a concourse release. Concourse is a CI system that we use in Cloud Fundry and you can deploy it with Bosch. So it provides source files. As you can see it contains a bunch of goal link packages so they need to be provided in the source directory. Then it includes packages that specify how to install them. So let's take a look at this ATC package. Every package contains a manifest file which specifies what files to include from your source files and also what dependencies need to be provided when this package is gonna be compiled. As you can see this package depends on goal link package and that means that Bosch will first compile goal link package and then provide it to the compilation VM that will install your ATC package. So the important part of the package is the packaging script which defines how to install your software.  So basically that tells Bosch how to transform your software into something that's runnable on Bosch. Then release contains jobs folder. These are different services that you can reference in your manifest and they specify how to run your software. So here every job has a manifest file which defines what packages are included in this job and what properties this job exposes. So what that means is that if you're going to deploy this job you can configure these properties in your deploy manifest. How these properties are being used? They're being used in the configuration file templates that also are included in the job. So here we have this template ATC CTL. So let's take a look at it and you can see how here these properties are being referenced. So Bosch will fill out the values for these properties that you specified in your manifest during deploy. Then also this package here is using links. So it depends on database and it specifies that it consumes database properties and if it's going to be deployed alongside with your database job or job that provides a database link Bosch will make your database job properties available to this package. So let's take a look at this Postgres SQL manifest file so you can see here it provides link database with these properties. So now your ATC configuration file templates can use these properties directly in a template. Depending on which platform your release is going to be running release offers must provide job supervisor configuration file. So for Linux platform, Bosch is using a monit to supervise running jobs and release offers might must include the monit file. So every monit file specifies what processes are going to be running as part of this job, how to start and how to stop these processes. So these are how the jobs look like and here we have also some blobs included in this release just to show you that these are some S-free references. So some binaries or tar balls, they will be downloaded when you for the first time gonna create this release. All right, so maybe let's change our release somehow and redeploy it. So I'm gonna show you my running concourse here. So this is a concourse that was deployed before and let's just add some color to it. So I'm gonna add some nice background image. So we are updating a source file which is somewhere here in the source directory. Then I'm going to my concourse release directory. And before I start anything, I need to regenerate JavaScript files. Then I'm gonna build new version of my release. So let's take a look. I'm gonna run Bosch create release. Then I'm gonna upload this release to director and then I'm gonna run deploy. So as you can see, Bosch figures out that ATC package was changed and it generates a new version of the release. So here that's a new version of release and then it's uploading this release to director and then it's running deploy. So it notices that the only thing that was changed is the release version. And both of these packages depend on the source file that I just changed. So it's gonna recompile both of these packages and then it's gonna update the job with the new compiled bits. So while it's doing that, let's take a look how Bosch versions releases. Usually developers iterate quite a lot on their releases until they happy with their feature until it's stable enough or it passed CI pipeline. Once they happy with their dev releases, they can mark it as final. And doing so basically applies a different versioning schema to your release and make it available to other people. So if you wanna share your release with others, you will share your final release. Others don't see your dev release history and you can internally iterate on it as much as you want. It is guaranteed that the final release will have exactly the same package contents as the dev release it was generated from on every machine every time. So let's take a look how our deploy is going. So it's still going. So maybe. You just couldn't leave it alone, could you? If you work on a bump Bosch, it's a two point error. Yeah, you're not allowed, you can tell people. I do have a question though. Yeah. When you have the different shots and stuff showing the different blocks and all that, do you say they were on S3? How does it know they're on S3 as opposed to... So there is a configuration also included in your release that specifies the Blob Store information. Okay, thank you. So here I have this. Final YAML, which contains your Blob Store. And also this is where your final releases will be stored. So if you're gonna upload them, you would put them in a separate configuration file which is usually git ignored so that you don't accidentally push it. And whenever you're gonna update your packages, you will have this file in your release directory. Exactly. All right, so we got our new version of Concord's deployed. So let's take a look at it. So it's hard to beat that, but... I also wanted to show that we can change some properties in our manifest that our release exposes. So here we have our job that defines properties that you can configure in your deploying manifest. So like this IP port, and also like this username and password. So let's maybe add some authentication to our Concord's deployment. So I'm gonna modify manifest file. And I'm gonna specify properties for ATC drop here because it exposes those properties. So we're gonna provide username, password, very secure, and I'm gonna run for deploy. And it notices that those properties were changed and let's deploy it. As you can see, it's not recompiling any packages. There were no source file changes. The only thing that was changed is your deployment and what it's gonna do is gonna process your configuration templates and provide them to your job and restart the job of the new configuration. So here we go. That was fast. Now let's take a look. Now our pipeline is gone and it requires us to log in with some basic authentication. Yep, that's one. So you can learn more about Bosch at these resources. We just looked at release engineering process, structure of deployment manifest, but there's much more to Bosch. So go to Bosch.io website. You can, it's a great source of Bosch documentation. Check out this Bosch tutorial. Also good introduction to Bosch. And if you're interested in contributing to Bosch, it's all open source. Go to our GitHub repo and start contributing. Do we have any other questions? We have a mic here. Stand up and ask a question. Any more questions? Okay, great. Thank you very much.


My study is clinical study to evaluate the value of C2 urography in hematuria. Myself, Dr. Nitin Sharma, I am a junior resident from Department of Rated Diagnosis DMC Jammu. Hematuria is a sign that can arise from the constellation of disorders ranging from urinary tract infection to invasive malignancy. Our study aim to evaluate the value of C2 urography in hematuria. So hematuria is one of the most common manifestations of urinary tract disease and it can originate from any site along the new track. And it has a wide range of causes, including Calculi, Neoplasm, Infection, Trauma, Coagulobethy and renal pyrenchyma disease. And this makes the differential diagnosis wide and extensive and seemingly disjointed. So the concept is to evaluate both the renal pyrenchyma and urethelium for variety of causes which can cause this hematuria. So this hematuria can be of two types. It could be microscopic or macroscopic hematuria. Microscopic hematuria is when it is only apparent under a microscope and the color of the urine is not changing. When the color of the urine changes to brown or red, that is called as a gross hematuria or your macroscopic hematuria. So this study was a prospective study and it was conducted in department of radio diagnosis in Super Speciality Hospital GMC Jammu for a period of six months from Jan 23 to June 23. So inclusion criteria was the patients who presented with hematuria. Exclusion criteria included pregnant and lactating patient, severe renal failure, previous allergic reactions to contrast media. The patients underwent a three-phase CT examination after obtaining informed consent in written form. First phase is an initial non-contrast phase. Second phase is a nephrographic phase which will be acquired following delay of 90 to 100 seconds after administration of the contrast to evaluate the renal pyrenchyma. And this is followed by a pyrographic phase which was taken 8 to 10 minutes following administration of the contrast to evaluate the urethelium from the pelvic additional system to the bladder. And this was performed using a 64-slice multi-director row CT scanner. So this is our first case. As you can see, in this case, there is a axial and coronal sections of CT showing right renal HDN due to a right renal pelvic calculus with peripelvic stranding. This is another case showing axial and sagittal CT sections which shows or demonstrates a heterogeneously enhancing vesicle mass lesion along with an extra vesicle component and concomitant involvement of the right VUJ causing right renal HDN. This is another case of a vesicle mass lesion which shows heterogeneously enhancing vesicle mass lesion along left posterior lateral wall with ill-defined fat planes with prostate. This is a case of a patient who was hypertensive and diabetic and in this case, the patient was presenting with fever and we saw on the contrast enhanced images that there is non-enhancing areas in upper pole of right kidney along with right nephrolithiasis and the findings were suggestive of pyronephritis. This is another case where there was trauma after catheterization and there was an intraperitoneal spill of the dye following contrast administration through catheter from the bladder. This is another case which shows directed left collecting system with enhancing pelvic wall and periuretic collection and multiple feeling defects in collecting system suggestive of pyronephrosis. This is a case where the patient presented with features of scleroderma and on the contrast enhanced images they were bi-literally heterogeneously enhancing lesion with internal fat content suggestive of angiomyeliboma. This is another case where the patient underwent hystectomy and following that she was complaining of hematuria and she was complaining of discharge through vaginal remnant and on CT during the excretory phase we saw a midline fistula communication between posterior bladder wall and vaginal remnant which was suggestive of vizicovaginal fistula. This is another case who presented to us with hematuria and the ultrasound findings were suggestive of ADPKD and on the CT bi-literally enlarged kidneys with multiple renal and hepatic cysts were seen suggestive of ADPKD. And this was another case where patient was presenting to us with hematuria and the lesion which on the non-contrast images was of attenuation of 45 HU. This lesion enhanced after a contrast administration likely a renal mass. So most common age group for hematuria was 61 to 90 years which constituted 38% of the study group and least common age group was more than 90 years which constituted just 2% prevalence of hematuria was more common among males compared to females. The cause of hematuria was divided to urolythiasis, infective, inflammatory, congenital, traumatic, neoplasms and other miscellaneous conditions. CT urography detected 16 patients having urolythiasis as the cause for hematuria including renal, POJ, uretric and VOJ calculi and which constituted nearly 38% of the total number of cases. Most of the cases of neoplasm in our study were above 50 years. These are the tables showing the age-wise proportionate distribution of the patients showing that 61 to 90 groups were the maximum number of the patients had the findings. Males were more commonly affected as compared to the females and the most common cause of urolythiasis followed by the bladder CA and followed by the normal cases. So hematuria is one of the most common manifestations of the urethrax disease and it can originate from any site along the urethrax and has a spectrum of causes including calculi, neoplasm, infection, trauma, medications, coagulopathy and renal pyromania diseases. And thus CT urography has a very high sensitivity in detecting these causes and appropriate management can be done for the following after detailed evaluation. Thanks. These are the references.