Hello everyone and welcome to the next edition of the BioXL webinar series. My name is Rosen Apostolouf and I will be today's host. So as you know, Gromach is one of the most widely used applications for molecular dynamics simulations and it's my pleasure to have today Paul Bauer who is working on many aspects of the Gromach's usability and he will tell us more about how you are able to contribute to the Gromach's code and the documentation. For those of you who are new to our webinar series, I'd like to give a very brief overview of BioXL and what we do. BioXL is a center of excellence for computational biomolecular research. We are almost three years old by now. Our three main lines of activity are first the improvement of performance, efficiency and scalability of several key applications which are extensively used in biomolecular research. These are Gromach which you know very well about, Hadoq which is one of the very popular application for docking, for integrative modeling and also CPMD which is extensively used for hybrid QMM simulations of, for example, enzymatic systems. In addition to the key applications, we also work on improving the usability of these codes and also coupling them with various other tools. We do this by devising efficient workflows that let researchers in one goal execute complex pipelines, for example, that are needed by their research and we work with key workflow platforms such as Galaxy, Colts, KNIME, Apache Taverna and a few others. Our center also puts a lot of effort in consultancy and training and we are promoters of best practices in the training of end users, not only in the applications but also how to write code and so software engineering best practices and others. So I'd like to introduce our presenter today Paul Bauer. He received his PhD in computational chemistry last year at Uppsala University while working with Professor Lin Kammerlin on computational understanding of enantioselective enzyme catalysis and although his main part of the doctoral work was also experimental work, he started working on software development where they were developing in half simulation software. After his PhD, Paul took a position as a researcher and scientific programmer at Ellington's Group and for the last year he's been extensively contributing to Gromach's working with the infrastructure, improving the documentation and he's the best person to tell us about how to contribute to Gromach's and why do it and what's the best way. So welcome Paul. Thank you, Wilson, and thank you for the introduction and giving me the opportunity to share this talk with the people that are interested in it in the form of the BioExcel webinar series. During the talk I will go through a few general questions about Gromach's how to contribute to code and especially why you should contribute if possible. I will give you an introduction to Gromach's documentation that has intensive information on that to find the information how to contribute and what you have to consider before contributing. I will go through a few examples that I think will very well from the last year internal and external contributors used our existing documentation to provide us with new functionality and updates to our software and I will finish a few sessions on general advice for users, contributors and the like on what they should consider and do if they want to contribute to projects in general and what is in general a bad idea if they want to contribute because they lead to hassles for the developers and also for the people that are contributing. So to the question why contribute to code, this is something many people ask themselves when they see a large software project especially one that has been established for several years and that has a few core developers that know best what to do. Other people then think there are other people, external people think there are main developers working on it, they know what they are doing so I shouldn't bother. Also it's often in the case of complex codes, one is one of them, they are even more visible examples of this for example in the Linux kernel, that's often the idea of new people that they think they don't have enough expertise to actually do something in the code and they would just be a drag on others. It can also be that they have to try to contribute to different projects or even the same project before and they got harsh review on their contributions. So they didn't like the impossible or they didn't like what has been done and they feel that their effort had been wasted and contributions were not acknowledged and they think that after a few years of nothing being done they shouldn't even try to do anything anymore. My opinion this is a set of own assumptions because there's always good reasons to contribute to whatever project you can think about, it could be just fixing a very small issue that you had found by using the software and it's not new, maybe it's just a type on the output, it is a missing comma in the documentation or a hassle in the user interface where you need to put extra options if you don't need it. It could also be that you have been an expert in the kind of development or the application and you know how to improve it, you know performance improvement, you can prove it, then of course you should contribute this at some point. It could be that you're working on new ways to analyze data that is produced by a program or by other software, you want to include this analysis method to the software and you want to make sure that it can be, that you want to include the analysis method to be a simple part of the code and of course it's always possible that you want to improve documentation because you found something that was unclear that was explained to you but has not been updated in the documentation itself and then of course you can contribute and fix this. So how to do this and what you should think about when you decide that you want to contribute to any project. First as a general advice you always need to have a good idea of what you want to do and what you are planning with your changes, how those changes should look like. You should have worked out the requirements of what is needed or whatever you want to implement or what you want to change and also reduce the scope of your possible changes as much as possible because it's always more difficult to implement something that is itself big, that is maybe hundreds of thousands lines of code changes and that does everything that you can think of at once. That usually is not what is needed. What is needed is the test case that shows that this feature does work as it should in a very simple case without any additional work, even performance improvement aspects and of course always if you want to change something you should have tested it before that it actually works and that's what it does but that's what it's supposed to be doing and it doesn't do anything else, it doesn't interfere with the rest of the running of the program and that's for example in the performance as much as much. So if you want to contribute for example to Gromax and how to contribute there are a few central places that I will also introduce to you, those are www.garromax.org. This is our code review server that is also linked to our integrated testing infrastructure. We have a WebMind issue tracker, WebMind Gromax.org that is used to keep track of what we want to do with the code, conducts that we know of or that users have found tasks to improve aspects of the code and features that should be implemented or kept track of them. Our important resources are user mailing lists where general questions about code comes are usually asked by people that use it and usually you can find any information like a bunch of questions that have been answered or that have already been answered can be also searched by looking for the archives of the maintenance and we also have a developer mailing list that is focused on developer questions and questions that are actually related to code development and what should be changed for some of the new versions of the code and also we can get information of new versions, new features, new releases and our plans for the future. So as I said, we should overview what you can see right now is actually a picture of our code reviews site from yesterday morning. They see that we're currently working on a few changes to the code that are public and can be reviewed by external people and internal people allowing us to vote and judge their code for correctness. It turns to our coding standards and also if they follow the general vision of the project in the end. This infrastructure, the server is our simple infrastructure is linked to our automated testing system that allows us to verify each submission to it to see if it passes our tests on different and build systems. For example, different versions of compilers, different versions of subsidiary software such as CUDA. And also if it works on different versions of creation systems to make sure it works on Linux, Mac and Windows in the end. Another simple information infrastructure is our issue tracker. This is a red line. You'll see that all issues that have been filed by users are kept track of and can be searched and investigated by people that want to know for example which box could be simply fixed. You have this information also in the documentation in the list notes, but sometimes it can be also important to see what actually we're done. And the advantage of the issue tracker is that it also links to the changes in the repository and on the error. Allowing us to quickly crossfire for these changes to issues, features and tasks. Make it possible to see when a task for example is completed and the issue can be closed or to see if the box was fixed recently and can be also checked by users that reported the box. So after you have gone to these pages and informed yourself about what you wanted to do, then if you still think that your project idea is good, what you're coding on here, it's usually a good idea to contact one of the core developers on the mailing list. You can find those developers as simply the most active people on the web. And contact them directly if you have an idea, but it's in general also good idea to post it to the bottom. My name is to see what is the consensus of other people that we are not core developers, but they're invested in the pros of the software. After the discussion there, the discussion usually moves over to Batman with a new issue that can be discussed. There can be important feedback to show how the project tackled. And you can get some ideas for example how to improve your general concept or how to reduce the scope of the problem that you're working on. After this, after the discussion there, it comes just a housekeeping part. You need to have your own test repository, you need to be able to build the software. And you need to of course do the necessary task of preparing for the preparing tests for what will be changed by your new feature that you're implementing to make sure as I said before that it does achieve what it's supposed to be doing. This is the point where you usually upload a change together and this can be also a point where you have to prepare for some frustration that is inherent to the share software development. There's a change that is uploaded together that is something that can be viewable and can be viewed by everyone on the server. And code review and for going with it usually tends to be very on point to keep up our software standards but also helpful. We try to help new people and also code developers to improve their code to always get something better out of that and help to reduce the scope for future bugs so they are not hidden because something was implemented for them. Can be quite possible that any of the changes you're doing, especially if it involves some changes to corporates of governments, to go for a large number of reviews that can go as long as 60 or 70 even in a few weeks, if multiple people have interest and are invested in your change and want to make sure that it's a toaster of standards in the end. It can even be that if some people think that your change is not toaster, it's for that it is maybe not the optimal way to implement a new feature that's initially injected and then you have to consider it and see from the feedback that you got how you could restart your implementation. You could see that the upload and new change that takes those considerations into account first, that goes then again for the ones of code review to actually be accepted. Now it's also important that you have to think that developers, code developers are humans and they also can be frustrated by their work. More on this on what you should be doing and what you should not be doing to reduce frustration on all sides will be mentioned later. But just a few main points, it's not a good idea usually to upload large changes to the code without any context. If we see that someone uploads 20,000 lines of code without any reference to wetman, even though if this is the most beautiful layout code with beautiful documentation, it's likely won't be accepted because we need to have a discussion body first. Another bad thing is to not have tested your changes before and seeing that everything you tried to do with somebody else in our testing infrastructure. This means that we have to go through changes before again. And it keeps at all times that we know that your stuff is getting tested. Other people cannot test their code themselves. Also, we have extensive information about coding style and coding standards. And the new coach has always told us this time to make sure that there is not that much noise about them. You should change your coding style to the standard that we have agreed on. But you can start with this from the beginning. Now, everything that I just talked about, you can actually read about in our documentation. And the Gormex documentation is basically your source for everything that you need to start your own development, that you need to start your own work with Gormex. And that you need to, that you can go through to get more knowledge about the backgrounds, about the physical dimensions of the use of Gormex, and what kinds of model it implements. Gormex documentation itself has been recently needed to be hopefully more accessible to users. And contains as a set of information on how to compile the code, what it can do. But it has always been a work in progress and has always been on the stage of it can be improved, it should be updated more, but there's usually not enough time for it. Currently, the documentation is available both as an online web page where you can get information about how to code. You have to release notes for the different versions, installation guide, user guide, some hard tools for beginners, and a few other sections for some of the reference manual, developer guides, and even for code documentation from Doxigen. You also have most of this available as a PDF, but we think that it is better to have it actually available as a web page that can be cross-linked easily. In the documentation, the different sections are split up according to the topic. The user guide provides information for end-up user people that are new to simulation software, new to Gormex itself, and gives you an idea of what the software can do, answers some frequently asked questions, and gives you also some extended information for how you should manage simulations, and what you should think about before stopping them. The reference manual is the Holy Bible of Simulation with Gormex because it explains everything that is in it for what kind of assumptions are made, what kind of physics are modeled, how the model and how physics is modeled, what kind of different methods are made, and how those methods are connected. The developer guide, on the other hand, contains more information on what you can do if you want to implement your own tools, what you can do to get an idea for contributing to Gormex, for example. There you find the contributing to Gormex section, I think this is probably of most interest for people that are joining you. There you have the checklist for Gormex. We will also give you some ideas for example, if you have a change that is not going to be accepted or you think maybe there is not enough interest in it. For you to fork the Gormex repository, keep track on our current stable versions, but keep your code in a separate repository in the end. You have to find, I hope you can all see those links here. You can see for them in the end. You can find the user guides, reference manual, and other sections of the manual that are released for the current beta version, all online. And can also browse them if you're interested in that at some point. As I mentioned before, you also have full code documentation for everything that is currently documented in Gormex, and it's only been more version. And the documentation material. You can also get all of this directly from the manual documentation, not only for the current beta version, but also for all the previous stable versions, and also the current in-development version that is just the daily build from almost a bunch. Now to some examples that I will just introduce you for how code can be contributed to Gormex, and I will do first the shameless plug, because I'm going to show my first project that was related to Gormex, and that was a rework of the documentation. Initially, documentation in Gormex was always handled as two separate pieces. He had the online documentation that was user guide, install guide, and developer manual, and there was the reference manual that was in external documentation. And then there was the PDF that contained the physics. Those kinds of this kind of split made it actually difficult to relate the different sections, because you needed to always have both of them separately at hand. And it also meant there was additional work needed to keep them in sync. If something got changed in the user guide on managing simulations, it would be more prone to errors. There are also several other pages from previous versions of Gormex that contained some information that they were not kept up to date and are also difficult to access in the end. My process to change this was initially actually learn how our infrastructure works, how, for example, our automated tests are the quarterly system books and how a built environment for the documentation should be set up to test that the documentation actually works. And the following parts they are actually what you would expect. See that the new changes to the documentation can be accepted and to upload the change to the server that tests it following by after a while approval from the other developers. All of this was actually what you saw in the section from the embedded version is that the format got format documentation for the documentation got unified. Now it is all available as RST market, or if someone is not familiar it's restructured text market. This allows us to both provide HTML documentation that we have now on our page and also allows us to build the PDF version from the same source material, meaning that we only have to keep track of one of them in the end. Another advantage of changing this to one or basically one unified documentation is that we can now cross-reference between all different parts and make it easy for users to see what the simulation for example uses a specific simulation method means in terms of the physics explained in the reference manual. Another example is that we therefore were able to duplicate some of the old webpages that were out of sync and we also planned to have the documentation as well as the conspiring that just the unique digital object unit files make it possible for users to always refer to the version of documentation that they used from the release release and not having any ambiguity about this. Another example that we had from working from an external computer was some updates to the GMX cluster tool. Then some discussions started on the developer list and later on RedMind from someone that saw that there were actually some missing functionalities in the tool that default should be easy to fix and could be of use with or could be of a lot of use to other people. The discussion on RedMind led to him uploading a patch to build this work working without any trouble. With the other developers then helping to clean up this patch reviewing it and leading to it to be submitted in the latest release. Another example was updates to public detection that was actually a student from a student contact us and the developer team for a project to get started with software development and get started by looking for example in the performance community. Among these amount of developers was then decided that one possible let's see the type I'm sorry some that's one part that could be updated in a moment would be the hardware detection library HWH that is used to detect what kind of system performance is running on to get the best performance improvement possible performance. We also worked on getting to know our code system and ultimately testing close by working on some smaller issues again in the documentation and successfully was able to upload a patch that was agreed on by the different developers to support a new version of the hardware detection library and considered support for the older version. It led to actually some that they identified and that they fixed by the developers and the contributor is still active in the community and helps both with working on new features and coding. Showing that this is actually quite easy to get integrated in the developer community and be active in the project. What all of the other different examples had in common was that people that wanted to contribute got involved in the community that means actually helping with the software development problem. It not just means uploading code together and fixing things improvement documentation but also helping in giving you other people's changes. It means spending time to go and go to code that you need and think that you understand but you think you can help with you and suggesting how you can improve or saying this works as it should. It should be included. It also means that people should be active or can be active on the users and developer and in this to help people with issues with running the program or with developer questions itself. A very important thing is also that you shouldn't first start with trying to fix the interesting thing you're working on but maybe fix something small first to get better to know what is in the code base how the different systems work how code review usually works and how to quickly get code accepted. Another thing is that it's always good to be actually active on our issue tracker and code review server itself because it means that you care about the state of the program. If someone just uploads a change and expects us to fix it in the future after it got accepted in the code, it's very likely it will be deprecated in a short time because no one will have to acknowledge no harm and time to actually continue to work on it. It's always good to actually care about other people's goals, trying to find errors, trying to find possible improvements and trying to prevent bugs before they happen. But what should be mentioned and what is always an important part of being active in the local community is that code review and discussion on that might get user-maintenance developer-maintenance should be followed to keep up our coding standards to keep up the aim of the project and most importantly to keep the physics correct to make sure that people can continue to do awesome science work comments. But you need to stay civil and kind. You need to be able to show people how to improve their code without being accuses to them or being neglected of their own ideas. So if you find an issue with someone else's code, you should point it out to them. You should just say this can be improved enough. This is just wrong. Just as important are things that definitely shouldn't be done and this is almost all the time just being able to do anything that you want to change. Time for developers is finite. You can only you can only work 24 hours and then there's the night. But developers they cannot spend all day reviewing the change after one project so we have our commitments to work. We're going and reviewing a launch change takes time. It cannot be done within 30 minutes by something else. It's happening or you have downtime from other projects. It takes a lot of time to understand what is happening and also to get an idea of what was meant to be done in general. Another problem is that our testing infrastructure is also limited, has limited resources. For example right now for a single change pass or verification on the current developer branch takes about 22 to 24 minutes for all systems to be freed again. This means if someone uploads different changes that should all be reviewed or should all be checked by our testing system that for more than three hours no one else can do anything. So it's not a good idea to just upload even if you have changes even if they are small we can maybe easily be reviewed if you will block our people from contributing at the same time. This also means that you should definitely check on whatever hardware that is available to you that your code will pass to make sure that the testing infrastructure is not used to build the binary tested in some cases and then having it fail in most of the other cases wasting everyone's time in the code review. And it's also very important to listen to the advice that you actually get from other developers especially from the senior developers. If they think that your code can be improved then it probably can and you should take it into consideration get updated to new coding stars to different constructs in C++ for example and try to implement their changes as good as you can. And another thing that sometimes come up is that you see extremely large changes upload response and yeah we have lenses of 20,000 plus lines changes are bad idea. Because they will make it difficult for review. You can see how much it changes that is uploaded and the 20,000 plus line change will probably scare away even the most hardware developer that is used to review a lot of code at once. This kind of code hides a lot of complexity also because you usually forget what was done in the first file after in your touching and going through file 25. Meaning that there is a sub debug that is hidden because of some strange combination of input method and assumption to be very hard to find. And this kind of changes also means that probably a lot of parts of the code are touched and modified at once making it more and more difficult to understand and levelate what is happening in new change. Yeah this will need to box it may need to be done again. So if you want to have large changes you usually have to see those as I mentioned in the beginning that you can reduce the scope as much as possible and then add more and more different aspects to the code after it has been validated to do what it's supposed to be doing. After calling cases have been identified and probably accounted for. And it has been shown that there is no negative impact on the rest of the code. This concludes the presentation part and I want to thank some people that involved in my framework. This is of course the project needs for Glomax especially Eric Linn of the class in Mark Abraham in Stockholm as well as everyone in the cyber-client that is working on Glomax and of course I want to thank all developers and contributors to Glomax and all the users that continue to do awesome science work with and that shows that they are doing something that is workable. And with this I want to thank everyone and we will go over to the questions and answers session. Thank you Paul for the very thorough explanation and yes so now we have the questions and answers open. Please use the questions tab in the control panel to write your questions. We don't have at the moment yet so please use it. So also Glomax website is under new development when can we expect to see a new one? So the main website is also some of the older information that is difficult to migrate from it. We still keep it but in general we think that most of the different pages should redirect to the manual .org because we have now all the information about the project centralized there and easily accessible for some of the different versions of the program. Download things for every one of the students to all of the different development infrastructure. Yes it did a lot of effort is being put in the code so for infrastructure it requires even more. So if there are questions from the audience please use the questions tab. We have a question by Adam . So I was a clear explanation of how to contribute if I already know the area in which I want to contribute what would you advise is the best way to learn about the parts of the code that are most extensible to learn about the architecture of the codes the parts that can be changed modifying the central part of the code that makes it difficult to test in your opinion what areas of the code or what aspects of it are most accessible for improvements and modifications. So one area is of course the documentation if people want to change something then to get started is always good to look at the documentation and change something there another area in my opinion is quite easily accessible with this framework for analysis methods because we also provide a template that people can modify to implement their own method and to learn how the analysis works in the end. Otherwise to find out how different parts of the software look I think that the documentation is very structured and informative to get started on different aspects that are of interest to use. Okay, thank you. Thank you Adam. So we have a question by Gisun Li for Gisun Li pronunciation let's see if we can get a value connection Hi, can you hear us? Yeah, I can hear. Oh, great. So you're welcome to ask your question. Yeah, I want to know will Gromax consider to support multi-body potential such as EAM used for metastimulation? What do you mean with multiple potentials? I don't think I am that familiar with this kind of approach I'm sorry. So do you mean different potentials for like three-body? Yeah because if I want to do some simulation about the material sometimes Gromax cannot support some potential so I cannot use it so I'm wondering if Gromax will consider to support these potentials. I don't think there are any plans but now to support this kind of potential in Gromax. There is work on providing better support for QMNM approaches to maybe provide something that is closer to this kind of approach but for direct implementation of multi-body potential I don't think that's anything planned at the moment. Okay, thank you. Actually it's a little difficult, it's not easy to implement new potentials straight away without affecting performance and this they touch on the very core parts of the code so it's not easy at the moment to extend with such like lamps for example they support different potentials but this comes at the expense of performance. In Gromax there is support for user-defined potentials using tables of interactions and forces and forces so it is possible to have your own user-defined potentials that you can use for simulating the system. Okay, thank you. But these you need to tabulate Yes, they need to be tabulated for it and they usually are not able to use for this kind of performance in Gromax this available for already implemented potentials. Okay, thank you. You're welcome. Do we have other questions? Still have time? Can you please use the control panel? Well, if there's no more questions we'll be the best way to touch with you all just drop your email. If somebody is maybe hesitating if it's a new user and is a little unsure whether they can actually found a bug or something needs to be changed I suppose everybody is welcome to contribute and the thing is if you think you found a bug then I think you should let us know if you think something is unexpected in the software then most likely is unexpected behavior and even if it's not we may have to explain better by the software behaves in a way that you are not expecting it to. It really helps to get an outside view of how information is presented as well. We have this problem and as developers that we often we see what we are working on and we see what we are doing and what we are used to but we don't know we don't always know how people use this software. You tend to develop like a blind eye for someone I think that's right. So if people use it for interesting science if you didn't think about they need to let us know or if something doesn't behave as they think it should. That's true also for all other community projects. It's always true. But Gromsky has a big user community so he has a big opportunity to improve quickly. All right well since we don't have other questions that we can close today's presentation as I said we will upload a recording of the webinar on the BarXL YouTube channel and on the website so you're welcome to watch it again or forward it to your friends and colleagues and to let you know that coming up next in the BarXL webinar series we have two presentations one is on one high level framework the COM says and it's Python variant PyComps which is exclusively used for development of parallel applications will be presented by Danio Lezzi from the Barcelona Supercomputing Center and for especially for the Gromacs users and our listeners today in November in the month it's time we have a presentation by Michael Gert who will talk about MD benchmark a new system for easy benchmarking of your course something that is very important for everybody who is using in particular large scale approaches that can help you find the optimum way to run your simulations without using too much compute cycles so everyone is welcome to register and join us for these webinars I'd like to thank all the participants for joining today and Paul for the great talk and we will see you again next time thank you and that will be all for today bye


Thanks. Let me wake up my machine here. Yeah, I'm a two month old baby at GitLab in product marketing for the first time. You know, it's funny. Since I joined all of two months ago, there are five or six more newer people just on my team. So that's GitLab right now. I'm going to like feel the pace of it. We're like a thousand people just short of a thousand employees and I had to check again today because yesterday it was in 62 countries and today it's 63 because it's another day. Why not? We're in 63 countries. I googled really hard for that image so I hate to waste a perfectly good welcome slide. I know it's getting a little late for a welcome, but part of what I'm here to do is actually just to generalize the conversation a little bit, tell you a little bit more about GitLab, the company, the software and I believe it was actually promised I would talk about DevOps tool chains. So I will. It's true. I am Brian Glanz and there I am. I actually did tweet something at the hashtag because why not? It's pretty cool out there. At GitLab we work where we live instead of needing to live where we need to work. And I happen to live in like the building out the window, but I have this urge to say welcome to GitLab at the top of the talk because I've been in your seat many times and lots of other companies and you know whether it's over at the spheres actually that way or like further that way I was down at X the innovation labs, the research and development labs at Google and I'm reminded of a time a buddy of mine's given the remarks at the top of the day there and largely a non-Google audience and he's got this big like Hindi film narrator voice like Amitabh Bachchan and he says at the start of it welcome to X you know and I'm just like goosebumps because it's a super dramatic setting and it occurs to me that this building which is just a building but you know the space needle is kind of like GitLab's building today and we don't we don't have a building you know those thousand people in 63 countries they don't go to any one office we don't have a headquarters to welcome you all to but if you get more than a few of us in the same place and at the same time because we're also asynchronous and all our work by default and then customers and users and contributors at that point like somewhere in there we've every right to say this is GitLab right now so so yeah welcome to GitLab and that's a little bit of context about the company you've heard a little bit about me I was in fact a developer and as a consultant I'm thinking you know for all the different operations I was inside of more than a hundred different clients of different sizes over the years I don't know of another one who dog fooded quite as aggressively and in all the same ways as GitLab does and that that I sort of bring up because it was occurring to me like how do we get away with it you know back when we were just crossing the threshold into being what they were calling the first Ukrainian unicorn or sometimes called the San Francisco based startup or Netherlands tech company or of course the first Ukrainian unicorn because that's like I said just a bit of who we are and everywhere that we are but I get this question a lot and I always marveled at it before joining the company like how do we get away with it and we we get away with it by using GitLab is actually now that I'm on the other side the inside of it even this event organized in GitLab so we use the product to develop the product we also use the product to run the company and that'll come back around and actually be relevant in one of these slides let's pull at that DevOps question with software delivery and this question you must have been told to think about so many times in recent years how often do you release I like this needle for kind of pulling at the thread I'll do this a few times in these slides like think of the answer for yourself and then we'll go survey says and we'll show you the answer from lots of other developers or in some cases lots of other folks in in IT on the opposite or in security actually how many people are developers here I'm looking around and already know some of the answer yeah just good to know quite a lot of the room which makes sense so how often do you release I mean we've all been told and I must have told people a thousand times it should be more often but in case this is small I'm gonna walk over here and do so 2014 to 18 over five years this is a question asked by Forrester these are you know their data this is their analysis I'm just bringing it to you we all know we should be releasing more often or so I've been told but many teams are stuck I think stuck is a fair word there over those five years I'm actually really surprised there wasn't a lot more movement on that question but if you zoom in on 2018 and then do a 2019 version finally like a little bit of loosening up and Chris condo the principal on this subject and related subjects at Forrester this is him drawing a box and saying target zone I I don't disagree if I disagree with Chris I'll let you know but I don't generally speaking nor in this case so there's a lot of questions about why I mean even like why why so stuck but also like why release more often matters I think it's just a it's an aspect of being agile not like agile methodologies per se like are you fleet of foot are you ready to react to an opportunity when it presents itself to you know an incident that that requires releasing to to respond to to your competition more quickly releasing something that's better and sooner than you expected over some of these same years Forrester 2013 15 and 17 we're asking just developers in general are your organizations using an agile methodology never mind which flavor 2013 half we're saying that fewer than 25% of their teams were using agile and that script really flipped by 2017 exactly half that is right and saying that more than 75% were using agile but here's another one of those surveys says so when you ask are you using agile oh yeah and lots of movement over those four or five years but if you ask on the specific method level I mean just think of your own answers to these and it doesn't really matter what you call them like do you do stand-ups do you do sprints do you do you know when you ask people more specifically are you actually using these practices associated with modern app development yeah yeah that's what I remembered quite a gap right if you ask people like are you using agile or if you ask him are you doing some of these specific things associated with one of the other one of the other agile methodologies not so much and let's look to the other side of DevOps and ask in this case in the next few some IT professionals with responsibility over toolchain management and they're telling Forrester too many tools create friction kind of obvious from I guess a little bit of my consulting bias I thought some of these numbers would be even worse but two-thirds is pretty bad on the lower right there agree that handoffs between teams using different tools slows down delivery sure it does right and let's let's pick at that just a little bit as Chris condo headlines it teams have too many tool chains and too many tools so how many different software delivery tool chains in your organization one two three to five twenty twenty one plus thankfully only two percent in the twenty one plus club but that's four and five with with two or more tool chains each of which of course are comprised of multiple tools I might have flipped these charts but how many tools per tool chain again with the 21 plus crikey so a solid half with six or more tools per tool chain and four and five with two or more tool chains so sure there's a lot of there's a lot of rub there plenty of friction to go around who who's actually feeling it is the next question put to the same IT professionals here who's responsible for maintaining all of that keeping it all working yeah the developers we all kind of know that but conveniently 31 plus 19 is 50 so exactly half of these organizations know they have a problem to the extent that they have teams devoted to keeping these things working dev ops teams internal tools teams yeah labor intensive so let's pick up just a little bit of how the integration actually is done and the way I read this one is that you want to be here right out of the box solution integrated end-to-end and that that jibes with the sort of one in five being in the old promised land here I don't know what incidentally I don't know how to read this last one our tool chain is not integrated so is it tool chain I'm not sure what that means thankfully small small answers there but you know maybe it's wonderful maybe it's like oh we use one tool so it's not an you know IT people there you know maybe it's like in the days of you know the sneaker net right you'd put data on a thing and walk it across the office and your sneakers maybe it's I don't know if the human is the interface then it's not an integrated I don't know I'm that I don't know what it means thankfully they were asking the smart people this question this is a little convoluted we're looking at of the so the benefits you will you will realize or do you anticipate realizing if you're in that promised land if you're in that one in five with a fully integrated tool chain out of the box and this is I mean I think some obvious ones right like yeah improved developer productivity we just saw the other side of that coin increased revenue I'm impressed that pops is high on that list and so these respondents are quickly connecting those dots between simplifying release releasing more often increasing revenue right easy enough for them to connect the dots I like this one improved developer job satisfaction partly because I still get recruited which is totally inappropriate but they still get recruited as a developer and the messaging in those things says stuff like you know it's a developer's paradise you can use any tools you want is it really is that really like a paradise to be able to use any tools you want no you end up in you end up in the middle of this and so I do I do think that the situation actually leads to improved job satisfaction among deaths so in this case we're only actually asking a subset these are the folks who actually have an out-of-the-box toolchain management system and then all of the benefits they have realized which do they see having the greatest impact on their business and ability to deploy to any cloud somewhat to my surprise really pops there although I'm not surprised at all that three and four would agree they don't want to get locked in I mean who wants to be locked in and and why is multi-cloud important I mean I I think this is fairly self-explanatory but and it also occurs to me that we're standing in an enormous lightning rod in the middle of cloud city and I don't want to get struck down but yeah don't let big cloud lock you in right of course they're developing lots of tools that are intentionally going to work a little more smoothly if you're also yeah locked in we all kind of know that but it's nice to see that and correlated with these other data in these responses so what can you do well of course look for something that doesn't lock you okay that allows you to deploy wherever is best for you including on promises and something that does just as much of this for you as possible this is all still despite the little tanooki up in the corner this is all still chris condos analysis but you see where it's all going you know where I work you know I'm going to turn the corner on this all this lines up extremely well with having one tool to do as much of this for you as possible so let's talk about git lab and Hayden talked about this some and some of these slides just flesh it out even a little bit more get lab is for developers sure that's where it started for and by developers with source code management only at some point there was a big debate there weren't a whole lot of people necessarily in the debate at that point because we're early days like 2011 2012 some of my history is a little fuzzy and someone in here will will tell the story a little better if you're interested but there was a big debate over merging in get lab ci which was a separate thing was a separate code base with source code management and perfectly reasonable to be with lots to be said on both sides like there's a lot to be said for the the temptation of a real best in class tool that does this one thing extremely well but as soon as they did integrate them it was obvious at least there in that bubble that what the benefits were and that they were going to go toward developing things for the full dev ops life cycle it was just clear to them it was I think initially a choice made based on their own needs for efficiency like they wanted to maintain one code base they wanted to have one database that was the size of the get lab team at that point but it became clear what the larger opportunity was and that they would be building this company and this product out in that direction so from the very earliest days of the company get lab is for dev ops was more where that was at now I've already even in my two months talked to plenty of people and certainly in my 20 plus years talked to plenty plenty of people who have even more logos on their crazy wall than this uh yeah and I don't think it's too much to call it a crisis you know it's not when you you've got all that in your hands and how bad is it really it's pretty bad so when you look at some of these sources like the source on the 5.2 billy spent on dev ops tools in 2018 that source projects 15 plus billy being spent in 2023 and still like almost nine and 10 organizations are disappointed with their dev ops initiatives and and so you've got this stuff that you know the marketing people like me now will say it will dissolve it'll digitally dissolve your silos and then ironically uh because you've bought so many tools you end up recreating those silos you know but per tool chain or per tool and it's even harder to mitigate than the silos you were trying to buy your way out of I don't know at this point that we need to say a whole lot more about this particular slide we've all got enough context except that I would add single user interface to that I mean just occasionally as a dev doing ops that's invaluable to me and I only have so much brain RAM so if I'm trying to chase down an incident or something the less I can the less I can do in the way of context switching the better for me this and and all of the maturity related to this this is just one click off of our homepage and and I'm sure everybody in here has you know more detailed interest in a lot of these areas the fact that it's all up here is some of its of course labeled is coming soon but it's not to say it's it's complete by any by any stretch I think we can say more so than anyone else that get lab is a complete dev ops platform doesn't mean everything's feature complete but we're pretty serious about let me go ahead to we're pretty serious about tracking down exactly how complete are we and when will we be where right so which things do we consider lovable and they get a heart not just because they've been around for a long time but but because we actually believe that's the best solution you can find for that thing and there's also something in the mix and quite a hot debate about this inside the company and you're more than welcome to jump into those issue threads and join the debate whether you work for give up or not any informed opinion is as much a contribution as a feature or a fix and there's a lot of debate about like at what point are you lovable I would say review apps I mean I love our review apps I know of customers buying the product just for that and who say they love it so this is a little conservative from my taste maybe that's why I'm in marketing now I wasn't before we're beyond just get lab is for dev ops we're trying to stretch the definition of dev ops and clearly it's not just us like we heard earlier with dev sec ops that's not like just a word that we're making up and I think it's not only fair but but necessary to include security in dev ops and as you see there like as first class citizens shortly after I joined the company a couple months ago this tweet went out from the company account like when folks in ops are actually firing up their machines and and get lab as their main interface for getting their work done and and then de-fed this guy David chimes and he works in in ops and insecurity and says this day already came for me just reading it for the people in the back again doesn't necessarily mean we're all the way there but I think we can already say this as well I very much do it's been a year or two since we've been seriously adding to the security portion these are all really big deals now that I'm looking at these aren't just like little features here and there the up and to the right the sort of pickup of the pace it it's here I would say like I bring it here partly just to say you could doubt whether we'll actually be able to be feature complete or lovable in appreciable number of those different categories in a few years you could doubt that but if you looked at the the growth inside of the product and its capabilities and other aspects of the growth of the company and the product I I bet we get away with it I bet we would and the community contributions themselves up and to the right I hit the dashboard just off of this and it's really interesting to click through just in time to throw a couple more things in here we've even got organizations hiring people to contribute so that that all is part of how it's coming together and just to put a bow on it the company's mission formally is everyone can contribute like I said everyone at GitLab already uses GitLab to do their jobs like even this event is organized in GitLab right it's and and even in HR which of course we call people ops because it's everything is something ops even they use GitLab every day to do their jobs that's how we get away with being completely remote and and asynchronous by default and and still hold it all together and and pretty well and and so this is already true for us we want it to be true for everyone and and that's part of what it means for everyone can contribute there's even sort of a more profound level to it a company does a lot for you know educational users and for open source projects gives a lot of way for free and of course so much is free and open source besides but gives a lot of what would otherwise be paid away for free in all the right places and there's even a larger version of the mission outside of just DevOps which I think I know from some of the conversations I had before coming up here brings even some of us into the room today we're not all just using GitLab for work necessarily and that larger version I saw somebody see it really neatly which was to turn the nature of all digital work from read only to read write and being like a little bit more technical in nature that actually hit me even more than the sort of elegant version of the thing that GitLab wants to make this a read write world I really like that version of it this version of it is great too that's all I brought for conversation happy to go back and answer questions about any specific slides we should also broaden this up and and and let anybody from GitLab or anywhere else answer questions all right so let's give it up for Brian thank you Brian we're going to turn this into an open AMA right so there's a lot of GitLabers here so we're going to help Brian out if you have a question ask it that's what we're here for we still got this place for I think uh I don't know when it shuts down maybe an hour and a half hour there's still some drinks there's still some food but this is your chance to ask a question we'll walk around and it's an ask me anything right so it's an AMA anyone have any questions all right I got two of these so like if you if I'm like I don't know if I want his question I'll hand them to you I promise it's not too terrible um I worked in sales enablement for just a little while um at a big sales org and part of that was doing mind share events um I have a challenge at Disney where a lot of product managers project managers specifically say hey why would I use GitLab I mean it's got some of these things but Jira's like my tool of choice and smart sheet and these other things that PMs are usually indoctrinated into so I guess my question to GitLab would be how do you guys plan on creating mind share with non-technical people use what's been considered least traditionally a technical product anyone want to take it so um a good example that I was really shocked with was our legal department using GitLab right and and using kind of a workflow of how they negotiate contracts and how they manage their their pipeline of of work that they have to get through for the day right I was really shocked and uh and that one head of legal was in Minneapolis and I had a customer in Minneapolis and they asked the exact question you had and I was like hey Jamie can you go present at this customer and just kind of walk through your workflow your daily workflow and why and a lot of it was just hey I needed a place to just kind of organize all this stuff that's coming at me that's better than email right I mean which is not you know that's a pretty low bar right um and then just to be able to pass work to other people when there's you know other people contributing back to it it's a conversation it's just not lost an email and so since we had that in GitLab it just made sense I've had other customers ask the same thing and everyone's a little unique I think it's just smart to find some solution where you can collaborate and everyone can kind of contribute and there's kind of an audit trail of what's going on that's my answer to this question does anyone else want to jump in oh you're known as dojo if you're so uh my take on that is as with everything else at GitLab it's an iterative process and we've gotten to a point now where I think we've satisfied a lot of end users or engineers or developers needs and the next evolution of that the next iteration is to get feedback from those project managers who say I can't live outside of JIRA so we are actively seeking that feedback so it'd be great if we could interface with people like that that have that stance saying this isn't gonna work for me but we need to figure out why because we are satisfying a lot of engineers and developers needs from a project management issue tracking perspective but now we need to get the non- developers feedback it will take a while to prove out and you have to have your early adopters just like with any product um but that's what my focus is next year is figure out so we love to collaborate so challenge accepted in the back of the corner all right any other questions all right uh you mentioned uh feature flags earlier uh when can we expect future flag application in GitLab? I uh I don't know yeah so uh yeah in the back Josh Lambert in the back I don't know if uh here you go sure thanks uh so right now we have a baseline feature flag function which uh we've been iterating upon um so it's based on the unleash API so you can use the unleash client libraries within your application then you can control the feature flags within the GitLab portal or the GitLab user interface I think we did just recently roll out some uh like progressive deployment capabilities and so you can target certain percentages of users and so we are iterating there and so it kind of will depend on how mature and robust the feature that you need but essentially we're on a trajectory there in future flags and we've been iterating on it across the last couple months um so it's continuing to get better uh and um yeah it'll depend on sort of where your needs are versus you know kind of kind of our ramp up but uh so we can talk offline but we've it works now and and we've just had the progressive deployment capabilities and we'll keep on going so we'd love to learn more about what you're looking for what you need great question on our roadmap there's probably an epic about feature flags and I would highly recommend you contribute and say I like this I don't like that and please do this and the more people that raise their hand the make the easier it is for Josh to help steer the ship is how I would say it um but that's a great question um I don't know maybe Hayden looks like he's going to get creative he might pull that up I don't know any other questions I got a question it's more like a quiz does anyone know when GitLab releases uh oh someone in the back wait 20 second of every month like clockwork have we missed it all right not yeah same here I've only been here two and a half and it never happened and I send out an email to a lot of people they're like man you got to stop sending me that email anyways uh any other questions oh in the back back left corner it's kind of a hot hot zone so I'm just curious with uh continuous deployments and delivering more often what's the plan to move towards weekly daily etc with GitLab releasing I'm gonna pass that back to Josh Lambert yeah thanks so uh on GitLab.com we are releasing weekly now um so uh we have a new uh website up at GitLab.com or about.gitlab.com slash releases slash GitLab hyphen com where you can see like what features shipped to GitLab.com that aren't yet available in the GitLab like self-managed release package so you can check that out um it's possible they might be behind a feature flag so they might not they might be merged but not totally deployed yet um but that's a easy way to check out like what's coming um and uh yeah so we're weekly we're working on driving that down to be more quick uh to be uh more rapid um and uh essentially uh we I think we're tackling some of the availability challenges on.com first before we keep on driving forward but we're at weekly now and we end to keep on going but we want to make sure we keep it up first um and then on self-managed I think we feel like a monthly release is about the right cadence for folks as far as a monthly feature release um and that it's it's pretty quick for most self-managed releases uh but um we actually find that uh like 30 percent of users are essentially within n minus one of the release so it's pretty good and I think it's like just under 50 percent are within n minus like completely n minus three yeah so um we keep a close eye on that and make sure upgrades are reliable people are taking them but I think we feel pretty comfortable that's a good cadence but love feedback as far as if you want feature releases faster um or or if that's about right for how fast people can sort of ingest upgrades at this point in time good question uh good discussion josh um how frequently do you upgrade jason so we're self-managed uh and we are typically on a made or a feature release on the 22nd we're usually wait for the first patch release or seven days whichever comes first all right is it manual is it automated it is all automated um we basically just go out and say hey we're ready for the latest release we put in the uh the version that we want which is latest and it pulls down on updates for us all on um no downtime um I have applied security patches in the middle of the day um with no issues awesome you've earned another drink okay any other questions all right we are here it is raining like kind of hard so good luck getting out of here um you could have another drink you could have some more food if you have more questions what we really want you to do is contribute communicate collaborate with each other apparently if it starts with a letter c that's kind of what we do now with events like there's contribute commit uh what was today connect right whatever I mean so we'll eventually run out of c words and come up with something else I don't know who knows um any other questions well I stalled for a little bit so the question was do we have like a local meet up or a local user group here in Seattle is that correct that was your question I don't know I don't live here uh joe d coming soon right so joe is your rep in Seattle um sounds like John's got something to say yeah that was a that was a bad thing this week we're gonna avoid that right yeah so on something else okay kyle james on linkedin he's wide open for a meet up and happy to share what's going on at disney and uh we're waiting for his new channel my kids paid for three years with their allowance they just keep asking me when is it coming I'm kidding so this is just another tip if you ever want to give your kids an allowance I use two dollar bills so they can't use it in vending machines because I'm an evil dad but anyways um yeah here comes Hayden we decided not to get involved in the git lab meetups because we want the community to drive those these git lab connect events are kind of the equivalent of a git lab ink sponsored meetup uh so that's you can consider this kind of a meetup uh but the true meetups are pretty much run by the git lab community so we we generally stay hands off if that makes sense yeah there's like a process I have one I'm setting up in Minneapolis for my customers and I'm letting them drive it known it like we just kind of here's the template you go we're out of it kind of situation so kyle just you know sounds like he just took it all on here today it's recorded so yeah oh good stuff any other questions comments feedback all right like I said we're here for a while there's still coffee beer wine whatever else you like um thank you for coming out go ahead and put a round of applause for yourself for coming out today right you skipped out on work hopefully you learned something all right take care


Hello and welcome to another episode of the Private Property Home Shopper Show, a show where we tour some of the most exclusive and in demand homes around South Africa. Today we are once again back in Copperleaf Estate and we are touring a home behind me that has four bedrooms, four and a half bathrooms and is on the market for 8,950,000 rand. So without further ado, let's take a look at what's in store for us inside.


You better act like you don't hear what I'm saying and everything's all right.  This guy sitting right here, it's John Sanders. John Sanders, first of all, how you gonna not trust a nigga named John Sanders?  No, that's not what we're riding, but he's a custom bike builder, and he's gonna hit with us today, man, all the way out of Miami, Florida, man, let's get some back story, tell me how you guys started in this, man. Okay, back story, bruh, so basically, like I said, playing football at University of Buffalo. Shout out to the University of Buffalo, what position, bruh? I played corner and strong and safe. They just getting away scholarships, bruh, this is not a good position. You gotta have a heart and play strong and safe, bruh. I walked down and got a scholarship. Word, that's natural talent, flex on it, correct me. So, like I said, I need to get to practice, and I don't really wanna wait for like the bus, you know what I mean?  Yeah, yeah, plus it's cold, buffer. It's fucked.  I don't know how a bike was better than a bus, but whatever. I didn't see where you was going with that one.  A bus is only gonna take you. But it snows everywhere in Buffalo. Yeah, but, you know, you gotta make movies, man. You gotta get where you gotta go, so. You was there, I wasn't. You know better than I thought. And I'm like, man, I can't take it to the locker room, cause it's just not right. You know what I mean? So I went home and painted it and whatnot. And then my dog Joe, you know, shout out to Joe. Everybody got a part of the name Joe, man. Shout out to my part of the Joe, he over there. Yo part of the Joe. And all y'all part of his name Joe. Yeah, yeah, Joe. And all the average Joe. And people who smoke Joe. No doubt. Joe off of Kenmore, man, the coupe, check him out, bro. Anyway, he was like, man, you know, you can't paint like that. You gotta paint on the parts, you gotta take all the parts off. Long story short, took me to Go Bikes. It's like a little Buffalo, like community bike shop. Long story short, you know, I wear it every like Tuesday, Thursday and Sunday. And it was just like a sponge, man. Just learning from everybody. Just take bicycles and like ring a man and like fix him or whatnot. You know what I'm saying? So long story short, you know what I'm saying? I get back to the house. Start over. Yeah, yeah, yeah. So I get back home really as my wife, you know, face. She was just like, stop just painting bikes and just like painting for other people. See, that's the difference.  And she not said that. What you mean? I'm better in college. How did you know she was the one?  And like she was very trustworthy from jump. So I think that's how it helps. Hell yeah. Everybody needs somebody they can trust. Especially motherfuckers who don't steal. Like if your girl, if you see your girl to the store, she bring your change back. Whether you keep it or not, let's just show you you're dealing with something. She held it down forever, man. So. Forever.  So long story short, real flame. My grandma hit me up and was like, hey, check this wrestler out. He had wrestling. That was the one who was random. No, but I'm going somewhere. I'm going to watch. But you're just a random girl from grandma. Baby, look at this wrestler here. She was like, she's like, chuck him out. You know, y'all kind of look alike. And I was like, you know, it's kind of all right. So I'll look him up and I'm like, all right. You know, we kind of look alike. You know, so. Jordan Burrows. I'm out the wrestling. No, he's an Olympian, man. Oh, he's okay. Yeah. Let's check him out, man. So he was like, you know, so anyway, check him out. Then his fiance hit me up. And she's like, hey, I see you painting bikes. Like I want to get something for Jordan kind of special. Would you do something? I'm like, yeah, cool, cool. So I'm just like, wait a minute. Jordan like burrows. She's like, yeah, yeah. I'm like, I'm just telling him about this dude last week. You know what I mean? That's more than a coincidence. That's the universe moving. Grandma was on it. Always on it. She been on it from day one telling me to go ahead and go after it. So I appreciate that too. You know what I mean? So you do look like that. For real. So that's what pretty much birthed it, man. Yeah. Had you not looked like that. What did you end up doing for him? Like what piece did you put on?  Like I said, he wanted to go to the Olympics thing in 2013 and what not. And like American flag. So I kind of American flagged it for him. Put some gold rims. This is like my very first, first custom. You know what I mean? So I did that for him. And like I said, I moved back down south to Florida.  Try to do that. I'm just putting this blunt in there. What pieces that you didn't put together so far? So far. It's kind of, I'm like the Michelin man, right? So you make a tire, what? Now you hug it. And he's like, you don't want to see it go. But I feel like everyone I do, I really like. Like, you know, I tap in with the people. Can also, yeah, yeah, what they want. So I know like I did like a frog, dark frog one. That was pretty funny. But the lady was out in Texas. So I was paying her to listen to Texas. You know what I mean? Man, probably had to be Sean Taylor piece. Oh, okay. I did a piece for Sean Taylor, man. I know his peoples. So there was like, everyone was making shoes or, you know, hats. T-shirts. Right. That's why it was so crazy when you sent me this.  You definitely need to be on a platform where people can see it. So do you do just like custom bikes or do you do trikes or just are you in the whole, are you getting into the whole thing? Yeah. I want to tap into like electric as well. For real? That's the way. Right. Electric bikes are pretty dope. But pretty much fixies, you know what I mean?  Fixies. You were dropping the lingo in there like we know this. Fixies is like a fixed bike. So basically it's consistently moving. I'm going to start calling chicks who had the body surgery. Oh, she a fixie. She had to go get fixed. No doubt. So yeah, just pretty much stuff like that. But as far as future for it manages, keep on creating, probably move on to other avenues of painting. I mean, I've also like painted airplanes too.  Yeah. That's what's up. Yeah, yeah. So everything's hand custom, hand designed. So I come up with the idea and just slow it out. But what's the price range running? You know black people want to know how much it costs, man. You got where you starting off at. I got reasonable prices for what I put out. Because they're true one-on-one pieces. Would it be cheaper to bring a fixie?  I got you. Yeah, I could do that. So you do kind of restoration too, huh? Yeah, yeah, yeah. I refurbish it. So you got something that's kind of like messed up where you weren't painting.  Cool, man. Well, you ever find yourself like on something? Like you have to revert back to your real nigga?  Nah, actually, I don't really, you know, I don't really rock with bicycle shops. You know what I mean? Because I can get parts that they can't get. You know what I mean? I create what they can't do. You know what I mean? So I don't really worry about them. If anything, I go in there and let them like fix on one. Yeah. And I take it and get it shipped out. That's what's up, man. I just hope you keep doing your motherfucking thing, man. Because it's dope to see black men getting into other avenues, you know. Do you run into a lot of black people like on that side of the world, you know, in the bike world? Nah. Nah at all, man. I think I've probably met one of the brothers before. Let's start a bike team. Let's do it. I mean, there's one down south with some catchy part of the language, but JRS, yeah.  Yeah, yeah, nah, yeah. It should be hard, too, though. All the kind of bikes we're riding through, like it says mobile art, man. There's things that are true, like I said, one-on-ones that never been seen before. And I feel like this is one of those industries where you are seeing people do more shit like they're, like, getting outside and riding bikes and stuff like that. Especially with the whole pandemic. People, you know, start riding bikes. And so that's hard seeing things move a little bit more that way, you know, with that. But I feel like people always need bikes, man. Man, while we're sitting here chopping it up, just, right quick, let them know where they can find you, check out some of your work and stuff like that. You can find my Instagram, JRSCustomBicycles, my website, JRSCustomBicycles.com. Yeah, yeah, as best as just hitting me up, call me, because like I said, it's detail, right? So I gotta know what you want. So just give me a call, you know, work everything out. So it's not just the bikes that you do.  Yeah, yeah, it's, like I said, it's versatile.  It's an art piece, you know what I mean.  So when people order you bikes and you ship it to them, is it like, is it fully assembled or some assembly? It's probably about 80%, you know what I mean. So just because package size and whatnot, but all you gotta do is put... That's one of the problems I've been running into out here, the package size. Nah, that was too good to pass up. I don't even know who you are. But no, so it's like, you know, I build it up for them, but all you gotta do is put the front tire on just to handle the bar. It's pretty easy.   I've been told you I was gonna order some.  Nah, I got you, man.  This is not my only job. I got a piece for you. What you bringing? So it's an 85 South type of concept, you know what I mean. Hold up, man, where my knife? Anybody want my knife?   Come on, bro. J-R-S Customs. What you bring us, man? J-O-N, you see this? You got your hand held out. I didn't even know this thing had a camera. Bro, we might sue you. You can't put this footage out. We own this footage, bro.  There you have it, folks. We're gonna be looking for a new music director. Find out this thing has been bootlegged in the show. The whole time. It's behind the scenes, on the scenes.  So, bro. It's kinda like, let me see. No, we, man, this is crazy. There we go.    Nah, you don't want to do that. So, here we go. Nigga. Will you see this? There you go. Bro, I want the rest of that. Yeah, yeah, yeah. So, it could be whatever you want, bro. It's gonna be an art piece for now, bro. Yeah, no doubt. How long you in town? Uh, until like Thursday. We want to send you to the bike show.  If I can get whatever you need, man. Bro, you know what I need. I need some wheels. I need a motor. Nigga, y'all have a seat. I'm gonna count to three years.  I like carrot. Can I put a basket on my shoes? You can do that, bro.  Two on the side, in the front. I got you, dawg. You think I'm bullshitting.  Let's do it, man.  I appreciate it.  We got a black-owned bike builder right here in the trail with us. My man John Sanders, 85% show. Black excellence.  It looks like a bar. Appreciate it.


This is the main points that I will draw, I will make an inclusion to continue security, I will present it in two main container solutions like games containers and lockers. Also I will talk about the security pipeline and other main containers like we can finally a set of tools that we can find for auditing container image and auditing the host where we are running our auditing. Well we will try to compile the transition containers, basically the main difference between these two architectures is that containers are isolated and have sharp docking system, libraries and so on. In Dockerforce we have the Docker engine and in other systems we have another engine for running applications over the same operating system. Well we will try to compile, we have the visualization, we have different containers and in containers we have the signal kernel, signal kernel and the containers are what is called syscalls, syscalls are for communication between containers. And containers provide other solutions that I am commenting now that provides the security of these systems. These are the basic security mechanics that provide containers, in general we can see that provides main solutions like capabilities, the classical inus capabilities that we can find in inus containers and in Docker for example the syscrux, the enemy species, the root file system, all these capabilities, we can add the main features that are implemented in containers. I am commenting, I will go into details, for example in a specific, basically what provides an intuitive view of the system where processes cannot see other processes in other containers. Basically it's container also it's own network stuff. And the other features are signal loops. Basically it's the main kernel feature that provides a limitation, limiting and isolating the resources of the machine. That's in the CPU, memory, network and basically the process that are running in our machine. And inus capabilities basically what it does is it divides the previous of root into two distinct units and it's better than the previous. Inus container for example it is one of the first solutions. These all these features that I comment like enemy species, kernel capabilities and so on. Inus containers provide all these features. Also what's another solution like for security, like Aparmol and Selenux. Basically these are the main features that provides the inus containers for security. Inus containers provide basically with LXC command we can start a single process in a container or with LXC start we can mount a specific operating system with applications and dependencies in that image. For limiting resources in inus containers we can use the configuration for inus containers. For example if we want to limit the memory usage or the CPU we can use specific commands, specific configuration for configuring these use cases. For example if we want to limit the memory what we have to do is in this example we can see that we are checking the free memory in our machine and when we secure the inus container over this machine we can see that we can limit the memory. With the limits of memory configuration we can secure the container limiting the memory in an inus way. Docker for example provides in a similar way that we have the LXC start command. We have the Docker run. It provides also basically the Docker command is a combination of same groups, name, species, and image. All three or all these components provide what is where we are running our Docker container or Docker image. This is the classical container per line. When we are working with Docker we have a Docker client with the commands that we can find in Docker. All the commands and we have also the Docker server. This is where we are executing the Docker run. The Docker run is the main process that Docker use for executing the image in the container that we are running. This pipeline is complete with communication with the repositories. The repositories that we have is the public repository that we have in Docker. We can also have our own repositories, private repositories in our organization or in our servers. We can in Docker Hub we can find the main image from operating systems, servers, and so on. And this image when we are downloading this image the execution of this image origin what is called a container. This container basically is an image that is running in our integer Docker host. Basically the image are layers that when you are pulling an image from a public or private repository you are downloading an image that in reality is a file that contains many layers. Depending on your application for example if we are downloading the image, for example with Ubuntu, for example with other systems or servers. And what we do for working with Docker is adding applications, adding layers over the main base image. From the security point of view Docker provides, as I mentioned before, isolation, dependent spaces, additional layer of security with a lot more as a Linux. This container gets its own network stack for communications and also provides control rules for resources in the meeting. Another interesting feature like for example when we are pulling from Docker Hub, this is an interesting feature that created in 1.8 version that is called Docker Container that we can verify the integrity of the image. This feature what it does is checking the checksum of the image when we are pulling from Docker Hub. And in this way we can verify that that image is consistent with the repository that we are downloading. In this example we can see that for using this feature we have to enable Docker content trust environment variable and in this way we can verify that when we are downloading or pulling from the Docker Hub, in the public repository, the Python image, we verify the information. This feature basically what is that is protecting that from that you are downloading an image that is not modified and it's an image with a full integrity from a security point of view. We have also a new command in the new versions of Docker. We have the Docker trust command. This is an experimental way. We can manage in a different way our Docker image. We do this command. We can manage the keys from sending Docker image. We can manage entities to check who is sending the Docker image. This is an experimental command but you can try for checking this kind of security. Also Docker provides what is called Docker capabilities. Basically capabilities is a Linux kernel feature and Docker gets this feature for implementing in Docker. Basically capabilities is a unis action that you should perform. The main can have a lot of capabilities that by default are loaded when you install Docker and you run the first time. You have by default capabilities but you can for example restrict these capabilities. In this example we can see that we have the capabilities that are enabled by default when we are running container. But we can limit to restrict the default configuration that provides Docker by default. For doing this we can add, we can use the cap drop flag for restrict this configuration. In this example we can see that we are dropping the main row function that what it does is basically restrict the function. In this example I disabled the main function in our container and in general functions related with the network. In general what is container security? Container security if we try to go in general for example with the main ideas that we have is that it's about limiting and controlling the attacks you face on the kernel. This means that we have this previous principle that where we have this principle it says that the best practice at this point is not do a process in a container as root to avoid root access for attackers in a convolutional space. Roots file system as real only so that attackers cannot override data or save malicious scripts to file. And in general limiting the kernel system calls that a container can make to reduce the potential attacks you face. This is the main idea in container security. For example for limiting for this is a flag that we can enable in containers. In docker for example is the flag that we can use for avoiding that attacker can override the image creating files and in general modify that image. Other solutions that we have is for example SETCOM, SETCOM provides a limiting the system calls with a restricted system calls basking on a policy file. And now we will see an example. Basically SETCOM blocks and limits things like kernel manipulation, executing more points, change permissions, change the owner and see groups. This is an example where we define a policy action with the commands with the system calls that we want to disable to block when we are executing the docker or docker image. Basically we can use the security of flag and as a parameter we put a policy issue on file. And in this way we are blocking for example the commands like sianmosh, sation, encadir for example and in this way we can see that we can block this kind of command and system calls. Well for the security point of view we have two kind of tools for security for example the docker host that is the machine where docker is running. We have tools like docker and security, this allows auditing our docker environment and containers and it's our open source tool for running automatic pace. Isabel in indica and checks basically what this task is checking for many configurations that comes by default when we are running docker and it shows a report where we can see what are the configurations that we must review for running the docker container. In a more secure way. In this script culture we can see that we are running which shows what is related with the memory usage, the CPU. We can see also that we are running our container with Radoli and in a first view we can see that if our docker container can be a problem or not. And can be useful for a first point of view. We have also other tools like linux linux is not specific of docker but it has an option for auditing our docker file. Basically linux is a unique security auditing for a system hardware tool that includes that option and in a nice way we can see the state of our docker diamond. What are the containers that are running, what are stock linux linux file permissions, it will have any specific options like RRMOS linux it shows that information in this report. Well regarding the security pipeline when we are working with docker we can have this view of the pipeline. Basically we are working in our machine and we have our software repository with a linux repository for example. And we can have for example a continuous integration server like JVS for example for building, testing and package that image before push that image to the docker registry for example. And in this way we can ensure that the image are tested and packaged in a more reliable and security way. We have very many solutions like Jenkins, Ten City, Ambu depending on the project configuration we can use very continuous integration tools for allowing this process. Relative continuous threads basically when we are running our docker image in the docker container we must be careful with these kind of threads that can be for example kernel exploits that can be deployed. So depending we have update our kernel this exploits it will function or not. We can have also vulnerabilities like the GNC buffer overflow that we can see in some image for example if we download an image for example the Python image it has these vulnerabilities because it has a GNC version vulnerability. And others threads like SQL injection or MongoDB and elastic shares from somewhere attacks. Well this is for remember and finally commenting the main auditing containers image that we have in the docker ecosystem. With these tools basically we can scan our image from non vulnerabilities. We have the docker security scanning that is using the docker half for analyzing the image. Basically what this does is analyze the image for the 30 vulnerabilities in binaries, in packets and what this does is compare these binaries with the CME database, the common vulnerabilities and specials database for scanning the variation of the image. This is an example we can see that we are analyzing an image and we detect that some components have specific vulnerabilities because of the regions that is using the image. For example the GNC that I commented before is a thread for if we find this problem can be a critical thread when we are working with that image. As we have another solution like answer open source engine this provides a solution for scanning also vulnerabilities in our image. It detects the binary packets, what is the things and more information related with the packets that the image is running. Finally we are commenting what are the main start-ups that we have in general in containers that these start-ups basically provide a solution in the cloud for managing the thread, the vulnerabilities that have in our image. Thank you.