now. Welcome everyone. This is the Jenkins documentation special interest group. It's the 30th of August 2019. Let's go through our agenda today. Thanks very much for being here. I'm going to share my screen. So today's agenda includes a and this is just a review first and then we'll actually run the agenda. So report on previous action items, discussion of collaboration with other special interest groups, hosting the Jenkins Restay API specs on Swagger Hub, adding a plugin site to GitHub integration sub project from Oleg, and then community bridge sub projects for docs from Oleg. And if time allows, we can talk about the latest data from the contributors to the site based on some reports that I regularly gather. Any other topics that need to be added to the agenda. Okay. Yeah, that may be through cross sig communication for docs. Okay. All right. Well, let's put it in there. So documenting the infrastructure. Good good topic. Okay. Yeah. Mark correctly. Lowercase T. Oh, and, and Marky Jackson is one word. Oh, oh, I'm getting it wrong. Like that. And then the M and the J is lowercase. Okay. So the name to get hop ID. Got it. Yeah. Okay. I'll fix it. I can fix it later. Excuse me. Not getting things exactly right. No, no worries. I'm also on there. I can fix it too. I may have had it. Super. So in terms of action items, I've still got the open action item to get the docs project ideas. I've gathered a couple more ideas. So there are more things growing in mind. I will get those posted. Oleg and I have decided that we're not going to bother with reviewing the Google Summer of Docs topics again. We'll take that up as we get closer to Google Summer of Docs. Is that a fair statement Oleg? Yes, but partial because even if we stop talking about Google season of dogs, there are two programs which are coming soon. So for example, there is outreach. We used that line late next week. And there is also community bridge below. And both topics basically are the same in terms of projects. Ah, okay. So project ideas are helpful no matter what and consider them in the context of outreach and community bridge. Thanks. But this thing then be retained. You want me to just delete this one and I think just delete it. Okay. We really need to create project ideas but we need to find contributors in this. Great. All right. So a Docs SIG summary, we've been doing that to highlight progress for governance. We'll continue doing that. That feels like it's just a standing action item. I'm not sure if we need to leave it in the action item list. I guess I'll leave it for now. Okay. Next topic, collaboration with other special interest groups. So any specific items here, Google Summer of Code for instance, Oleg from you or Markey from you. From documenting of the infrastructure side part. I'm being onboarded and right now I'm starting to document how our Kubernetes infrastructure looks in Azure. And the next part that I will probably start working in terms of documentation will be documenting the monitoring infrastructure. Now there's a lot more to do but that's just kind of where I've decided to throw myself in. Just some bits. I started documenting the plugin site ecosystem. The plugin site ecosystem was already documented pretty well, I would say. Yeah, I'm just doing some refactoring and grouping of the documentation because it was completed across three repositories. Yep, it may also contribute. Excellent. Thank you. Any other SIGs that are active we should consider connecting and encouraging? To write documentation specifically? Correct. So regarding SIGs, you have Chinese localization SIG and they keep translating Jenkins IO website and they start moving some documentation to Chinese. So yeah, but it happens within the Chinese localization SIG. I'm definitely not using the infrastructure part. Oh, right. Regarding other SIGs, you have to be honest, I'm not aware about activities which would be specific to the documentation. So yeah, we indeed could do something in platform SIG. For example, I have a long-standing infection item to document Windows support policy and propose it as a job. Right. Just don't have Windows support policy. Well, and I have the long-standing action item for Docker or for Docker image support policy. Yep, good. Okay, thanks for that reminder. Yeah, but basically since Bosnian and the market are in both SIGs, so we just record our alternatives from one SIG to another. Right, sorry. Yeah. Okay. Okay, anything else on collaboration with other SIGs? Not SIGs. So regarding sub-projects, there might be some investment into JCASC documentation. Yeah, because Jenkins configuration documentation could be improved. There is a lot of community pool requests going into this documentation, but we can definitely do more. So it could be one of the projects for documentation SIG, actually. Quick question that I have is there or do we have any interest in reaching out to maybe plug-in maintainers for possibly documenting their plug-ins? I don't know if that falls into what we're talking about in this SIG. I will talk about it a bit later because there are some related activities. Awesome. Thank you. So it's just two items below. Great, yeah. So anything else on this topic before we move on to the Jenkins REST API topic? Okay, so let's go on. There's a proposal recently raised by Abu Jha Sharma suggesting that we consider hosting REST API specifications on SwaggerHub. There's a proposal thread in the Jenkins developers mailing list and an example that has been created on SwaggerHub. I've opened an account on, as opened and as created an organization, Jenkins, whoops, Jenkins, on SwaggerHub. It's a 14-day trial is all. I assume that means that they want to charge for it. I've sent the mail asking them if they would be willing to donate so that we could host as an open-source organization without being charged for it. Yeah, so SwaggerHub is hosted by SmartBear. They're actually somewhat active in Jenkins community. They maintain plug-ins for Jenkins, so they will sponsor in the Jenkins world, if I recall correctly, at least once. So yeah, that might be open to that. And for organization it would be really interesting. The problem is that right now there is no way to automatically generate REST API specification for Jenkins plug-ins. It was one of the project ideas for Google Summer of Code this year. We just didn't get applications we could have accepted, but the project idea is still there. So it might be again reduced in community breach, in outreach, in Resort 2020. So let's see. The project today, we have a mentor team potentially for that. So if somebody is interested, just let us know. Thank you. And could you envision that during this trial that we could do a test drive with things interactively created, the way Abuja did, even without having the automatic generation from the project idea? Yes, we could. So if you just need to take several plug-ins, which are heavily used as REST APIs, and create a swagger specification for them manually, is something we can do. Or somebody, for example, could start documenting the Jenkins core, because the Jenkins core REST API is some more structured. So I was thinking I was going to engage Abuja over the weekend and try to document the notify commit API for the get plug-in, for instance, and see if I could get some experience with one little thing, but it's a little thing that I'm somewhat familiar with. Yeah. So yeah, swagger is a pretty simple idea. Okay. Even the generation from Stapler, well, at least the generating skeleton of swagger shouldn't be a big deal. But it's just a question of somebody working on that. All right. Anything else on the Jenkins REST API on swagger hub? Okay, next topic. An additional plug-in site to GitHub integration sub-project. Oleg, do you want to take the lead on that? Yeah. So do you want to share? Sure, that'd be great. Just a second. Okay. Do you see my screen? We do. So yeah, this is what I was referring to when Mark asked about the plug-in documentation. So one of the problems Jenkins project has is that now almost all plug-in documentation is some way in Viki. So, for example, we can Google for Mark's get plug-in, get plug-in in Viki. And you can go there, you can discover that there's a lot of historical documentation and you can fill the first problem. Time to access this documentation is quite long. Then if you want to edit this documentation, there is a capture, there is no review process, there is basically no recognition for contributors. And it's an old way which is hard to manage. But many plugins has already started moving to GitHub. So basically, the documentation is a thing. And yes, even several years ago, we had a lot of documentation being hosted on GitHub. So, for example, I can take the configuration called plug-in as an example. So, I just realized that Zoom's panel has exactly the same background color as the GitHub header. And I was just confused. Okay. So, yeah, here you can see that there is documentation which is basically located in GitHub now. And it's pretty common for many plugins. And the plugins gradually move to GitHub even now. The problem for us is that this GitHub documentation is not easily accessible to Jenkins users. So, for example, the links going from a plug-in documentation, et cetera, they basically put a point to plug-ins Jenkins.io. So, this is a plug-in site. And here what you can see, for example, for configuration as code. Documentation for this plugin is here. The configuration is called plug-in. Well, you can follow the link and then you will get there. But obviously, it's not the best outcome. Sometimes, the generation of this page also takes time because basically, it's been retrieved from Confluence API on demand. So, performance is pretty bad. And the idea is that what if we just embed GitHub documentation straight into plug-in sites, straight in Jenkins update sites, Jenkins user interfaces. And yet, again, it's not a new idea in 2016. When we were running the Google Summer, of course, first time in Jenkins project, we already had a project for GitHub to plug-in site documentation publishing. The problem is that it has never been fully completed. There is a pull request from Uzbinik who actually wanted to publish documentation. So, yeah, this is GitHub for documentation. But yeah, when I started working on this story two months ago, basically, for me, it started from a release drafter because I wanted to have changed local automation. And really, I want to change logs to be also published on this site. So, at some point, I just converted it to the API with support in documentation and changed logs from GitHub. Plus, there are other relatively low-hanging routes. For example, posting plug-in logos, if you have some. For example, Mark would post a Git plug-in logo or something like that. So, yeah, just to make it look better. And, yeah, also, label integration because currently plug-in labels are partially defunct in the plug-in site because labels either come from Wiki. And the Wiki is not well maintained in terms of labels or from metadata in the update site, which is hard to manage. So, if you were able to pull this information from GitHub, it would be also preferable. So, yeah. I'm not sure I understood on the labels. What sorts of labels do you envision there? Okay. So, let's see. So, here you have a list of categories. You have a list of things. And basically, these categories come from labels. So, for example, you can go to, let's say, build tools. And you get something like 100 plugins. Okay. That's cool. You're probably, I need to offer an example with less results. Okay. So, for example, it should be somewhere here. Okay. It looks like, yeah, we wrote something. So, yeah, anyway, the problem that all these labels are kind of manually managed, they either Wiki, there is no user-relevant categories. For example, yeah, we have .NET, we have IOS, Ruby development. But for example, we don't have categories for Java developers, or something like that. So, yeah, it's hard to understand what's from where. And if we were just using a more relaxed way to label plugins, like GitHub labels, topics, it would actually help a lot though, yeah, it would require significant investment in aligning them. It's just idea from the top of my head. Right now, I rather want to focus on getting Xbenyx pull requests over the line because, yeah, it submitted them in May. But basically, there was no activity. And yeah, I want to have a bigger storage tree completed. And yeah, that's why I propose it as a sub-project for documentation seek. Because yeah, I think it would be important. Firstly, for better plugin documentation, then for recognition, because yeah, what we have that, for example, if you go to configuration as code is our automatic change logs and here are documentation updates. So, they're exactly the same. They also get to the change logs, private information to users. And the most important issue that documentation can be developed in parallel with this code, because yeah, it's now documentation is code. So, to answer your question, Marky, my preference would be to, yeah, to advertise better documentation, but yeah, better documentation, which would be a part of GitHub repositories and which would provide ways to review the documentation. Because right now, anybody can go to Git plugin and basically visualize this page if they want. Fortunately, it doesn't happen so often, but yeah, you had cases when somebody replacing pages with advertisement. So, yeah. My question would be, so first of all, just to add to plus one what you're saying, I think this is an awesome plan. I think it really goes to, if we start moving to sort of a Git style of infrastructure, I think that'll be awesome. Remember, the question that I do have is the particular page that you're on right now, will we be deprecating the use of this page? Because what my fear is, is that with this still being editable, people will still be able to edit that site. And it might create confusion. So, what I would suggest is, if it's possible, and we do go to the Git changelog style that updates the plugin site, we deprecate this particular Wiki site, if that's possible. Well, deprecating the entire Wiki site, it's unlikely possible because it's about solvents of repositories. And even if you have all Jenkins contributors working on migrating documentation, it will take a while. There is no good automated documentation, migration from Confluence to GitHub. I tried a few options. I didn't like any of them. But yeah, we can do something on the organization level. So, for example, you can install a plugin for Confluence, dump everything to mark it down, or ask it out and get it published. But yeah, we still need to get to it. So, what I do right now, so there is a label Verify plugin. You can see that it was a bit on July 20th. And basically what I did, I just moved all the documentation to GitHub. So, to two places. One is GitHub releases where now I have changelogs. And another one is just a route where I have documentation which used to be on the Wiki page. And here we have clear disclaimers. And the late evening, we can set up redirect or just put a big box saying that everything was moved outside. Beautiful. Okay, that's fine. That answers my question. And that sort of incremental transition is what I've used in the Git plugin as well for the changelog. I think others are doing the same thing, right? I didn't even bother to put the old changelog entries into GitHub. I just put a tombstone at the top of the changelog which says all future changelog entries are here and they link to GitHub. I moved the label to Verify because there were just 40 releases or something like that. So, it wasn't a big deal to just move that. But yeah, in some plugins, we have hundreds of releases. And, for example, for a new project, I just edited in like Mark said, it's not ideal, but whatever works. Got it. Okay, thank you. Yeah, so regarding the current status. So, yeah, there is some tooling for release drafter, which is evolving in a separate project. So, this one works pretty well. It's been explore request. It's ready to go. So, I'm waiting for Olivier to help use infrastructure. There is full request to Jenkins Info and GitHub tokens, because we need to retrieve information from GitHub. And yeah, it needs tokens. Otherwise, it's too slow. Yeah, I didn't prepare a live demo, but I can show you an example of the recent folder-based authorization plugin, so one which was created by a beauty. And you can see that this is just a screenshot of the current state of plugins site API. It's a backend repository which serves the information to frontend. And there you can see that information has been just retrieved from GitHub. If you go to this page right now, so it would look like something like that. Yeah. So, these pages are pretty embarrassing, because it's a landing page, so they didn't some documentation they wouldn't hit. Okay, so, yeah, this project is basically in progress. I would be interested if there are contributors and early adopters. Actually, yeah, once we have an infrastructure in place, we will have something like 20 or 30 plugins with information being put from GitHub, because we just rely on a URL specified in the metadata to understand what is the source of documentation. But yeah, going forward, once we have change logs today and other things, it might require some update. So, when you say URL and the metadata, which metadata is it so that I can make sure, for instance, that the Git plugin documentation and others like it will be pointed. Is it something in the POM XML file? Yeah, it's in POM XML. So, basically, we rely on this URL. So, your URL points to Viki. And in your case, Viki will be displayed. In the case of this plugin, for example, authorization. So, it already includes reference to GitHub in metadata, but it's still this place Viki because there is no GitHub. But, yeah, once we have the engine in place, it will start displaying GitHub and all plugins which have URL pointing to GitHub here, they will start displaying documentation from GitHub. The credentials plugin, for instance, has a very nice documentation inside of it. And all it would need is that its URL attribute points to that and then it's and it currently points to the Viki. So, it could be taught, though, to if this plugin were changed and pointed to its own documentation, then that will be extracted, concept should be extracted into the plugins.jenkins.io site. That's the idea. Yes. Yeah, that's the idea. So, original Apache from Hispanic, there will be some glitches with it because, yeah, our problem that if you use GitHub API, basically, you can get a readme page or any other page in a view-ready format, but this view-ready format relies on related things. So, you can adjust and eject the data to plug inside. You need to replace URLs, for example, to images or to internal references. So, there were some glitches with it, which I was fixing, but right now, I believe it's ready to go. So, that pull request then needs testing and verification steps and then merge and we watch what happens? Well, basically, I tested it as being tested it and we agreed that it's good enough. So, yeah, there was a branch here and waiting for infrastructure team to enable this drafter because there are other changes. But, yeah, basically, this is the biggest change we integrate and it's already in a master branch. Actually, it's not. So, yeah, there is a promotion pull request. The build is green. So, I'll probably just integrate it and after that, you'll need to update Jenkins infrastructure. And for Jenkins infrastructure, there is a pull request, which I'll go to link here. Jenkins infrastructure. Yeah, this one. So, this is a pull request which basically injects GitHub client-matter data. And, yeah, once we update Docker container because your plugin site is packaged in Docker. So, once we have this pull request, it should start magically working. But, yeah, basically the only way to test it right now is to test it in production. But, yeah, in the worst case, it will be a really simple fix to reverse it. So, yeah, this story is almost ready to go. Hopefully, we'll have a live demo at the next SIG meeting. But, yeah, the biggest story was wondering what is the level of interest from documentation contributors. Because, yeah, once it's integrated, we can do a lot with documentation. We can create maybe hundreds of new different tickets for migration of documentation and clean up. We can do many other things that need it. Well, that would enable me to have a place now to express all of the different details and tiny little pieces that are involved in the plugins I maintain. There are things that aren't described anywhere right now except in the online help. And that online help is insufficient. So, this is an ideal thing. I'm very interested in it. Thanks, Oleg. Very, very. Okay. So, if anybody is watching that, please feel free to contribute.  But, yeah, too long didn't read. We recover some activities around plugins. So, basically, it was small as tail since Jenkins 2.0. But, yeah, apparently, the development flow is pretty easy. So, there is front-end. There is back-end. Well, it is my very limited knowledge of whatever front-end stuff. I was able to get it running on top of some patches. So, yeah, I think that it's pretty hackable if you get support from the infrastructure team. That's great news. Thank you. Thanks very much. Okay. So, this is from me. Thank you. All right. So, we'll plan for a report two weeks from now on how that's gone. Next topic was community bridge sub-project for docs. And, Oleg, I think that's again you. Yeah. So, yeah, one of the reasons why we started talking about community bridge was Google's season of docs because we weren't accepted last spring. So, we can use community bridge to run projects. And, we already have a kind of framework for that. So, now there is a student, Slading Nunes, working on a JCASC. It's the first project we run on community bridge. Basically, the format is pretty similar to Google summer of code. We don't have restrictions about what can be handled there. So, yeah, we can use it to run documentation projects. But, to run documentation projects, we need mentors and we need a list of project ideas. So, yeah, here's the question. So, the question is, do we have mentors? Well, I need mentors, let's do project ideas. Okay, sorry, I get it. Yeah. So, yeah, we had a long-standing action item to just post project ideas and potential mentors. So, similarly to what we do for JSOC project ideas, we can post it independently of a program. So, community bridge, outreach, Google season of docs, they can basically take ideas from the simple, because the program is more or less aligned in terms of duration and effort to be put. So, yeah, for that, if we had a pool of maybe four and five potential project ideas with contributors who might be interested, it would be already a good start. You can add me as a potential mentor. Great. Okay. Yeah. But make sure to bring your own potential project idea. Yeah, I have two that I can think of off the top of my head. Would you have these ones? One would be just the infrastructure. I mean, we could just start leasing that out, right? If that's possible. Number two, I think using if we could get documentation for our onboarding process in terms of plug-in contribution. I think it would be awesome if maybe we could reach out to possible past Google summer of code students to see if they would be willing to come on to this particular project to say, I want to show you how to onboard a new plug-in. That's just something, and I'm thinking from the top of my head. Yeah. So, thank you, the documentation for onboarding procedures would be nice. So, right now, we have a landing page to participate. So, but the problem that if you start choosing options, you immediately get from a fancy interface to a fancy interface of your weekend, going to whatever random links. So, we still have a lot to improve there. Well, and we do have a pending pull request on how to do IDE setup for plug-in development. It's a pull request that was submitted few weeks ago, still is in my queue to review. So, I think that's the right direction. Absolutely. There's also, for me, there's the, in terms of ideas, there's the, oops, wrong place. The get use cases that I've enumerated out a whole bunch of different use cases. We also had a proposal for a tutorial to be added from the LabView team at National Instruments. They wanted to put up a tutorial and I offered, hey, yes, we'll happily code review it. Here's where you submit a pull request. Mm-hmm. That nothing happened, right? Hasn't happened yet. They only asked that one or two days ago. Oh, that's fine. I think another really good idea would be Kubernetes use cases as it pertains to Jenkins. The reason I think that would be a very good idea is it would get a lot of traction because that's such a hot space right now. Right. Or even, you know, use of Jenkins X is another idea. Well, Jenkins X is now a separate site. So it's basically not Jenkins. And currently, your car is working on setting up a framework for Jenkins X. Though, yeah, they will definitely welcome contributions. Well, you know, another part could be sort of maybe from a documentation idea, the difference between Jenkins and Jenkins X or how to go from Jenkins to Jenkins X. So maybe if there's sort of a bridge of documentation, that could be an idea. It would be nice. Yeah. So I'm actually having dinner with, I'm having dinner with Oscar tonight. So I'm going to bring that up to him. Okay. Yeah, it would be nice. Regarding Kubernetes use cases. So we had a cloud native specialist group. I'm not sure what tends to use there because right now this group is rather inactive. Right. I'm interested in recovering that. I just have no time. But yeah, there is Kubernetes operator project, which is ongoing. Sorry, I missed what you just, there was what project that's ongoing? Jenkins Kubernetes operator. Oh, oh, the Kubernetes operator project. Yeah, there is also a great progress around Helen charts. The Helen charts, I've issued the leaf outside the Jenkins organization. So they are maintained by Helen community. Speaking of that, they consider doing more integrations with configuration as code. But yes, still you have a lot of things like just Kubernetes plugin, whatever other integration plugins. So for me, it's a bit of a cloud native seek to drive it. But yeah, it can be whatever joint project. I need to get back as well. I need to get back into the cloud native SIG because I see that that's going to be a very hot area. And I think we can make it, I use hot in a loose term, but I think we could definitely re re put a fire under there. You see where I'm bringing the whole circle of hotness here. I think we could, we could read really reinvigorate that SIG and make it a little bit more. Yeah, I'm interested. Well, yeah, my interest rather comes from the Jenkins file runner perspective. Oh, it's about Kubernetes ticked on again. So yeah. Well, Jenkins file runner isn't really the Kubernetes use case. But yeah, there are so many layers. So finally, everything becomes Kubernetes. Yeah, well, but you're right. Yeah. So yeah, cloud native special interest group. If you mark your some of the other interests to just poke with this group, it would be nice because there is still pretty big mailing list. So if you just start sending stuff there, maybe there will be some replies. Yeah, I'll make it. I'll make it create a task for myself to start getting that moving again. Okay, that's cool. Great. Anything else? And so I'm going to take the project ideas we've listed here, the others that we gathered for Google's season of docs. And I will get those into a project ideas pull request. So anything else on sub projects that we want to discuss? I don't think so. Okay. It's rather a program of action. Yeah, maybe I need to do something. Yeah, certainly. Yep, you're right. Okay. So last item, we've got just two minutes left on our scheduled time for your info. I've been gathering every two weeks data on contributors to the Jenkins.io site. I don't know if this data is useful. I just gather it in case it might someday be useful. So for example, this is from the CDF site where they gather metrics. These are the pull request time from open to merged across the last 90 days as a moving average. The hyperlink there will take you to the graph and show you the current. My read of this graph is we have improved somewhat and we don't appear to be dramatically worse than we've been in the past. So those were measures that, okay, that indicator seems reasonably healthy. The next thing that I've been capturing is contributors for the last month. And we've actually increased both in the number of contributors and the number of contributions in the last month. So I consider that quite a positive. This graph I like a lot better than the one from a month ago, which was fewer contributors and fewer contributions. Then open pull request, this one, the number that we have closed has increased substantially in the last month. So that's a plus. The number that we have open is also increased. And that's somewhat of a cause for concern. Just a reminder to those of us who are reviewers, try to close pull request quickly. Any questions on the metrics? Well, metrics for the last month's problem are not that relevant because a lot of contributions come from Google Summer of Code. Well, even without Google Summer of Code, we had some blog posts posted. We had some changes in this site. But yeah, maybe it's better to have statistics for one year. Good, good suggestion. I've been gathering this one for the month thing. You're thinking this one would be good across the full year. I can't get the period of a year from GitHub, but good idea. Okay, let me see what I can do. Yeah, you can use the CDF graph on instance. Because it provides a lot of statistics and you can query for one year. Yeah, 90 days. If you query for 90 days, it's a question of how I spent the summer. And usually in summer there is much less contributions. Good point. Yeah, and one month was crazy because of JSOC, so the data wouldn't be relevant. Right, okay. Let me take that as I'll do that and we will increase to measure for a year, report for a year next time. Good, we'll do that. Thank you. Yeah, so we have five blog posts in the queue. Wish we need to handle. So yeah, I'm going to measure blog posts from Rika right now about CLI. Okay, yeah, that one's been a long time coming. Thanks very much. Well, there was issue with CLI because CLI for JSOC is not very stable. And it was failing for a while. No, I'm not happy that we deleted so much. Any other topics that we need to review in today's session? Nothing for me. Nothing for me. All right, thanks everyone. I'm going to stop the recording, stop the meeting, and thanks very much. We'll meet again in two weeks, same time. Have a good day everybody. Have a good evening and good weekend. Thank you. Thank you. Bye-bye.


Or staying with security martyrs, the emo state governor, Hope Uzodemma says that his administration will introduce an insurance policy for all the security operative 7 in the state. Uzodemma also advised cops to stop allowing themselves to be killed by bandits who attack police facilities in the state. The governor spoke on Tuesday when he paid a condolence visit to the state police command headquarters in Oreghe to sympathize with its leadership over the killing of policemen and burning of formations in the state in the past few months by bandits.


Hi, everyone, and welcome. Platforms, platforms, platforms. We've been hearing and talking about platforms the past few years so much. And along the way, we learn one thing or two about platforms. First of all, we want to focus on why we're building platforms, right? So we want to build platforms to enable product teams to deliver software better, faster, and safer. So we learned that we want to establish a platform as a product mindset. We want to definitely talk with the end users, understand better their needs, their requirements, and then expose a platform API, design an API, which can fulfill those requests from the end users of the platform. Then internally in the backend, we can do whatever makes sense for us to implement the platform, implementing different capabilities to support those functionality. But recently, we've been getting more and more requests about new types of application. And we got to hear a lot of different buzzwords, generative AI, large language models, embeddings, rug, vector stores. What's that all about? So before we even start extending our platform to support these use cases, I really would like to know more about this domain. And we have Lisa here. She's an expert in generative AI. So can you tell us a bit more about that? Yes, Thomas. So generative AI is the latest buzzword. Artificial intelligence has moved from this initial machine learning phase where it could categorize or analyze data to a point where it can really generate new things itself, text, images, you name it. So for this session, we're going to be talking about large language models. We want to integrate these into our programs as developers. Large language models, there's a couple of categories in them. So quickly, a language model is a completion model. If you send in, I like, it will probably say chocolate or something. There's chat models. They are instructed and trained to chat with you. So if you say, I like, it's going to say, oh, what is it that you like? Can I help you with something? And then we have a bit of a different beast there. Embedding models, they turn your text into a numerical vector that encodes the meaning, which gets very interesting, because you can use it, for example, to group text or fragments of text that have similar meanings by just looking which vectors are closest together. In a large language model, you send in text, which we call a prompt. So you probably have heard of prompt engineering, which is just hard words to say you tweak what you send in so you can tweak what comes out. And all large language models have a context window, so they limit what you can send in from 200 characters to 20 pages, for example. And then a next step we would want to do with a large language model. If we don't want to go train it or fine tune it ourselves, we can still make it learn from our documents, for example, our company documents that it didn't know about because they were not in the original training data. We can use these embedding models and these embedding stores where we store these numerical meaning vectors to actually go find the parts of our documents that are relevant to the questions we ask. That's called retrieval augmented generation, or RAG, again, a hard word to say chat with your documents. You see here the schema of how it goes. You split your documents in parts. You store the segments in a embedding store or a vector store together with their numerical vectors that represent the meaning. Then in a second step, when your user interacts with your large language model, you go find the relevant segments by also embedding the question and finding the pieces that are probably most relevant meaning-wise. And then instead of just sending your question to your large language model, you're going to send, hey, this was the question, the original question. And then here are parts of the documents that might be relevant in answering. So I hope that the platforms that Thomas is going to build will support these basic building blocks of AI powered applications. I quickly present myself. I'm Lisa Rass. I'm an AI transition specialist at OpenTide and also a collaborator of the open source framework LangChain4j. I'm also a committee member of the Cloud Native Hacks that are going on in parallel here. And I love everything AI and open source. Yeah, and I'm Thomas Vitale. I work at Systematic, a software company from Denmark. I'm a software engineer and CNCF ambassador. I'm really passionate about anything Java and Cloud Native. I combine these passions of mine and wrote the book recently, Cloud Native Spring in Action. And in general, I'm a big supporter of open source technologies and try to contribute as much as I can across both the Cloud Native ecosystem and the Java space. So I want to make sure that I understood correctly the problem. So we're talking about applications that are powered by large language models. And these applications are actually implemented using regular programming languages. So we're talking about Java, Golang, Python. But then we have two new types of integrations that you're looking for supporting a platform. One is towards a model provider. And it could be a local model providers like Colama, which is great to run large language models locally on your local development environment or for on-premises deployments. There could be cloud services, for example, Mistral AI or Open AI. And then we have a second type of integration towards these databases that really don't store data, but they store the meaning of data as numerical vectors. And we call them vector store. So it could be Weaviate as an open source example, right? Correct. All right. So I think we have all the ingredients to start designing a new golden path in our platform to support these new types of application. And let's start from how developers will interact with this new golden path. We're going to have a portal where we can extend the amount of golden paths that we have with a new one. I have created already a template for a new Java application, integrated with large language models and a vector database. So you can start the new project from here. Let's call it my app, because I'm really a creative person. And so that will be owned by Liz's team. And then we can provide information. I'll just use my GitHub repository for now as an example. And I'll give it a name, my app, super creative. And then let's define some parameters. This is specific to the Java application. It's called my app. So we can customize this onboarding procedure here. The interesting part, you can choose a model provider. For example, Olama, if you're working for a local model on-premises or OpenAI or Mistral AI or whatever other service, let's say Olama, and then pick a vector store. And here in the platform, then we can provide a list of whatever we support for now. We'll use GitHub actions for the pipeline and create a repository. So now you can go and check out the repository. But there's an important question we need to ask ourselves when we implement a platform. And it's all about the continuous development loop. So once a developer check out the Git repository, are we forcing developers to run Kubernetes, to have a Kubernetes environment to run the application? The answer is actually it depends. We talk with the development teams and find out a strategy that works best for them. In this case, we want to meet developers where they are. And developers across different teams are using, for example, Java, like Lisa's example, or maybe Python, or Node.js. And they already have a nice developer experience flow from the frameworks that they're using. So we want to keep that so to not introduce additional cognitive load to developers. In parallel, though, we have to solve the problem of, how do we provide these new integrations that the applications need? How do we provide a model provider and a vector database if this is running locally on a developer computer and we are not providing services from a Kubernetes cluster? And a great solution to that is using a tool which is really developer-friendly. It's called Test Containers. With Test Containers, you can have all your different integrations. For example, you can run all Lama. As a local model provider, you can run Weaviate as a vector database. And developers can use it both at development time when working locally, but also to run integration tests. Because testing is also important, we want to test against the real thing. And Test Containers allow to do that. It integrates with the application lifecycle. And it supports Java.net Ruby Go lang. So it's not Java specific. So in the context of the platform, we also want to provide a polyglot solution. So we are seeing an example in Java. But all the tools that we're going to implement inside the platform will actually be flexible enough to support different languages. So maybe we can test it out. I'm curious to get some feedback from you. And if that works. So this is what came out of your platform just like that. So let's have a look. I lost the side part. But it's a great application that let me try to run it. It's normally functional right like that. And I see I have a bean here with a chat language model, an embedding model, and an embedding store. So this is all set up for me. That's super convenient. What else do I find here? A document loader. So I know if I want to interact with documents, where to store them and how to use them. This ingester phase is there. The content retriever is there with some parameters that I might want to tweak for my application. That's great that I don't have to set all of that up. I see a chat memory. And then AI service here, a chat agent, which in Langtain4j is the workhorse of our application. And it gets to use the chat language model, the content retriever to talk with the documents. And it has this memory already there. So that's really a great start for me to work from. I have a look at this chat agent AI service here. So imagine I want to make something else. I can now directly jump into the business logic. And I want here not a chat agent, but I would want a composer agent. Because we're talking about orchestration here. And we're both musicians. So let's get some music in here. The nice thing in Langtain4j is these interfaces, these AI services, you can just declare what you want to happen there. You don't have to write much code for that. Ah, wait. Good. Okay, this is not my usual computer or ID. So I want a method called give composition advice. Also the nice thing is LLMs are very forgiving when there's typos. And then if I wanted to know what to do, I can just make an annotation at a system message here, which is the instruction for our LLM. And we want to say give composition advice for scoring the following movie scene. And then the movie scene itself is gonna be what we sent in. It's gonna be the prompt here. And so that's really all we have to do. And then we can just build it like this AI service builds from our composer agent and it will know what to do. Maybe we wanna give it a couple of tools because that's super cool. You can tell LLMs that they can use programmable tools, something I define here that runs in Java, accesses my database or whatever I want to happen. If I describe it well, my LLM will know that it has this and will call it when it's needed. And work with the result. So let's make a tool. I'm also very creative here. Let's see if I can get these curly brackets out. Yes. Yeah, the magic of the Italian keeper there. So we want a method that gives the virtual instrument code because we will wanna be using Thomas as a virtual instruments, not any instrument, but that takes the normal instrument name as an input. And then again, curly braces, yes. In this case, we will just, for the demo return one to three, but you can do any Java code here. And then to let the model know it has this tool, we're gonna make tool annotation saying gives Thomas's virtual instrument code for normal instrument name. Jet language model will know what to do with this. Anything we understand, they usually also understand. And then here we will add tools and say we built these tools. And voila, that's it. So it knows it can use this instrument retriever and it will also do so when it's appropriate. So imagine I'm ready with my application here. Can we now take it into production? Yes, but first I'm interesting because I'm interested in knowing more about how these type of applications work. Like we talked about Java, but I think that it might be nice to know how we can support other teams working with different technologies. And in general, what are these AI orchestration framework? If you can tell us a bit more. So we can support different languages in the platform. I'm sure other teams will be really happy. We would also be happy, yes. So with this boom of generative AI, there's also a boom in people that wanna build applications around these models, maybe have multiple models in there that interact with each other and everything. So there has also been a boom of AI orchestration frameworks. So the most famous one, the first one was Langchain, which was made by the Python folks. Of course, because machine learning and training, data engineering happens mostly in Python, but they also now have a version for Go and for JavaScript. Then there's, for example, semantic kernel for Microsoft, supporting JavaScript.net and Java, and then Langchain for J that I'm a collaborator of myself. It's a very popular one for Java at the moment and it's just great, of course. So they're all having similar building blocks. So let me dive into the building blocks for Langchain for J just to show you. You see here these language models, image models, more types of models will be supported in the future. The tools, which we just saw, they're there too, there's the memory, because models are stateless, and if you add a memory, then they become stateful. Output parsers are an amazing feature there because the LLM always returns text, or sometimes JSON, if you ask it to. What Langchain for J does for you is parse the output to real Java objects. So you're just calling your AI service and you get a list back or a plain old Java object, whatever you want, and you can just continue from there. You don't have to parse any strings. At the right, you see all the reg components to chat with your documents, and then usually all the AI orchestration frameworks have a layer on top to abstract away even more, like AI service we just saw or chains in Langchain for J. All right, so basically from the platform, we can actually support different programming languages, and then we know that for each programming language, the development team would use one of these orchestration frameworks, and then in the platforms, though, we need to provide the integrations to the actual model provider and vector database. So let's try to go to production because we need to complete this golden path. So for now, we talked about the development workflow. So the first thing we want to do is containerize the application, and we could use a Docker file, we could even make it part of the template bootstrapped from backstage, but using a Docker file would not be that much of a deal, not for the platform team because you lose control over all the security and performance optimizations, and for the developers means additional complexity, additional responsibilities. So instead for this example, we chose a cloud native build packs where as a platform team, we can centralize the logic to build production ready images without the need for a Docker file, and it works across different languages. So in this case, we are going to use it with Java, but it works with other types of languages, and then with one command, you can get the production ready image. You can use the CLI that comes with the project, you can have it part of the pipeline, or if you're working with Kubernetes, there's also Kubernetes native implementation, it's called KPAC, and in KPAC, you get a custom resource, it's called image, and you point to a Git repository, every time there's a change, it automatically builds an image, it also signs it with cosine, it generates a salsa at the station, so you have a quite secure artifact also pushed to the container registry. And then we need to configure the workload for deployments. And at this point, there are many different alternatives, but the key part here that I want to focus on is I don't want to expose the internal details and internal tools to developers, for example Helm, Customizer, Istio. Instead, we are defining a developer-friendly API, in this case, I'm using crossplane, to define a workload API, which only contains the information that the developer needs to provide. And this is just a few things that the platform cannot infer by itself, for example, what's the name of the application or what are the integrations. In this case, we have OpenAI and VV8 as a vector database. And then internally, we can implement it using all our favorite tools. In this case, I decided to go with a crossplane composition to implement the API and use Knative to achieve serverless deployments using, defining some application conventions. I'd like the platform to be application aware, instead of having applications that are platform aware. So there are some conventions across different languages on how to run application in productions. I would like to codify all those conventions in the platform. So we are removing even more cognitive load from the development teams. And then we're using service binding. This is an API from the Kubernetes project to bind in an autonomous and automatic way applications to external services. But we have a problem here. The platform, as it is now, doesn't have those services, doesn't have a model provider, doesn't have a vector database. I need to build that. And for the platform, we are using Carvel. So Carvel is a CNCF sandbox project. Each capability in the platform is bundled as a Carvel package and delivered as an OCI artifact. So what I did is, because the platform engineer experience also counts, it's not just about the developer experience, I made a template to build a new Carvel package in a nice way. So I can create now a new repository for this new package. I have already pulled out the repository. So what I can do is using the CLI that comes with Carvel, K-Control package unit. And then I define the name of the package. In this case, it's Vidiette. What is the foundation of this package? We typically don't start from scratch. So I can point to an existing Helen chart or an existing GitHub release with some Kubernetes manifest or some local files if it's a first-party product. And then I confirm all the versions and now I have my package. At this point, I can configure it any way I want using different tools. I can use Helm, I can use YTT, I can use Q, I can use SOPs to resolve secrets. And once I'm done with it, I can say K-Control package release. Of course I would do this in a pipeline and I give it a name. It's a container artifact. So it will go on my container registry on GitHub and then now it's delivered. And I can use it directly from my platform thanks to the package management functionality from Carvel, which is Kubernetes native. What it means is that I get a custom resource called package where I have a reference to my package and I can configure how I'm gonna customize this. In this case, I'm using Helm, YTT and K-Build in sequence. All right, I think we have everything in place for the application to be in production. So maybe we could give it a try. What do you think? All right. Okay, this is really amazing. You're making developers lazy, but we love that. Good. Here is our file application. It's a composer assistant. We picked four videos of which we will orchestrate one at the end. So the large language model is gonna tell us how to do it. We will execute this. So when we click on compose, we will get the advice here. So I wish to ask you which one you would like. So we have a romantic scene that we could orchestrate. Getting ready for the composition. The demo gods, please. Yeah. All right, so we have a romantic scene. We have a stroll in a gloomy forest for who likes that. There's an alien attack over the city. And then there's some sad melancholic video and we can make the music for any of those. Who would vote for a romantic scene? I thought we were in the city of love. Thank you for the two people. Who would go for a mysterious stroll through the forest? Ah, some gloomy developers here. All right, who would go for the alien attack? Ha, surprise. Okay. I think if it would really happen, we would have to talk again if it's so much fun. Okay, anybody that would like to sad, be doing it. Okay, so we will go for the action movie because that was the majority vote, but anybody that choose sad can come to me after the session and I will make you sad. That's not the problem. All right. But Thomas. Yeah, but first maybe let's talk more about the application. I'm happy to show you the architecture. Yes, I'm really interested in that. Going on there. I will need to myself. Okay. Yes. There we go. All right, so the way this application is built up. We have this UI. When we click compose, it will send the video description to our composer assistant application who will first fetch in our Reviate embedding store any instrument descriptions that are similar to our video description. For example, action, impeding, scary, heroic, will probably be words that are gonna be searched for or like meaning clusters. Once it has these relevant segments, it's gonna send to our LLM. Please give us composing instructions. We want to use Thomas's virtual instruments and we have a singer. Here is the video you have to score. This is the scene description and here are parts of instrument descriptions that you might want to use. And then the model itself will see that, oh, if I need Thomas's virtual instrument codes, I don't have that in my training data. I'm gonna call the tool that is there. So for every instrument, it is supposed to call the tool that will fetch the virtual instrument code from the database. And then it will take everything and give us a clean answer back in the application. I did not click yet, so I will do that right now. We choose action. So now it's generating a strategy. While we wait for this, hopefully it comes. I should have prepared some drum rolls, you know. We're talking about this. I wonder, I mean, everybody is now completely enthusiastic because composing advice, for sure it's everybody has been waiting for this, right? So in now the whole room here wants to go on our application right away. Can we visualize the load? Yes, because we can see it fails and of course we cannot go in production without having observability. And the good news is we have OpenTelemetry configured everywhere in the platform. And on top of that, we also added some specific conventions on top of OpenTelemetry to get information from the models and interaction with the model provider. We used our own custom ones, but there is a working group currently defining a standard set of conventions in OpenTelemetry also to represent data around large language models. So I'm really looking forward to that. So let's see what happens. We can also give this another try. And in the meantime, we want to see why it failed. So we can check the Composer Assistant and we have some specific spans for the AR orchestration framework used in here. All collected from OpenTelemetry so we can see the result. So the second one succeeded, the first one failed. So for the first one, we can see at which point it failed. So the model is called, or the application is calling the model multiple times because it needs to integrate with the tools. So we have to debug what's happening in that workflow, that chain of execution. But if we look at the one that succeeded, then we can also get additional information about the prompt. So you get all the prompt here if you'd like to tune it a bit and do some prompt design. You can see the finish reason and also all the tokens. So we can see at the end how much we're spending for this demo, right? That's great. That's perfect. Yeah. That's amazing. That's all I wanted to know. That looks good. So we got a recommendation here. Let's have a look. So we want to score an action scene. We got three core progression. I think they look fine. So maybe we can go with the first one. What do you think? Looks good to me. Yes. So let's try it out and see what happens. So Thomas, yeah. You're preparing your audio editor. Yes, let's do, let's start with something strong. All right. Do we have sound? Okay, we got some percussions. And now I'll cheat and just loop through it because that's fun, right? All right. So should we add some strings perhaps? We got the percussions. We got some strings. It says use Albion strings and some drones. So we'll follow the recommendation from the model. Nope, not that wrong one. All right. So how's it going so far? Alien attack. Should we add some more strings? Yes, the arpa. Yeah, that's weird, right? That's not really action with the arp but we can do something a bit better. Let's see down here. Yes. All right. We're getting there. So how are you feeling with the voice? We're almost there. Should we add some cello? I think he's suggesting a cello. So we could add some cello and then layer up the voice. Yeah. Let's add some cello. All right. Let's do it here. And like this. Oh, I don't want that. Go away. Like that. Yeah, should we give it a try? Okay. Drum rolls. I think that worked out. Where? I think we survived this. And it was a risky one. What an amazing voice. Okay, so to recap, we got the AI to help us generate this composition and it even gives some interesting results but we could probably improve it, right? Because the model has not been trained specifically with this purpose. So we integrated some of our knowledge around the feelings that each instrument's deliver, right? And some of the virtual instruments. And yes, we got the observability. I think we can move on and just go very quickly across the journey we've done so far. The first thing is we talked with the development team. That's the most important thing. First, we hear what's the problem that they have and of course, generative AI is super high right now but we want to know exactly what the needs are. So after understanding better the needs, we defined the project boost trapping phase using backstage, the boost trap also builds the local project using test containers for the local developer experience. And next, it will also set up a pipeline. In this case, GitHub Actions but you can use whatever pipeline engine you prefer. And then the other important thing is we are not exposing an internal Kubernetes tool or knowledge to developers. We are using crossplane compositions in order to define a developer friendly API and then we keep all the complexity inside the implementation. The development workflow again is based on test containers. We got the build pipeline in particular using build packs to help containerize all these applications. The deployment configuration was based on crossplane and the actual implementation was using Knative. We want to scale this. So when people are relying on generative AI and large language models, we also need to talk about scaling because there will be many requests. Some requests will be slow because as you saw, it took some seconds in order to process all the requests. There's a big back and forth between the model and the application because we are integrating knowledge from database and tools. We bind services using this API called service binding from the Kubernetes project. So as part of the golden path, we also automatically bind the application to the list of services that the developer mentions while bootstrapping the project. We got observability. That's really important. You saw things can fail and when you add large language models, they can fail even more. So we need visibility into the tokens, into the cost, into the prompt. So we can do some prompt design. And finally, of course, we want to go to production because if you don't get to production in a fast and secure way, our application is useless, right? It's in production that it delivers value. And the important thing, and I like to know if you also enjoyed that part, is developers are only involved in these first two steps, bootstrapping the project and then working on the actual business logic. And the platform obstructs everything else away. Yeah, I mean, as a developer, as a developer, this is the dream. So I didn't have to do anything for my project setup, except for choosing what I actually want and where I want this project to live. And then, all the rest, making sure there's observability, going to deployment. I didn't have to do anything. Like the VV8 setup, nothing. So the moment your platform is out, I'm definitely gonna use it and I'm never gonna waste, let's say I waste maybe two hours on the whole setup just to even start coding properly and then my business logic is done in another hour. So this cuts all this time. This is just really amazing. Okay, that's great to hear. Thank you. Yeah, so we did some music together. I mean, we are in Paris, you know. So music, it was a good fit. But you can reach out to us afterwards and in particular Lisa is really an expert in generative AI. So if you have questions around use cases and how it can help with improving the society, she's the person to talk to. So reach out afterwards. Yes. Okay, thank you very much for your attention. Yeah, we'll be around for questions if you need to. So just come to us. Also, I'm giving another presentation tomorrow if you'd like to join with Mauricio. We're gonna talk about unlocking new platform experiences with open interfaces. So we'll dive even deeper into how we can improve the developer experience across the distributed systems and integrate even more services in a transparent way for developers. Thank you.


It is just a few days to the release of one of India's most controversial films. The movie from the moment it's released around November last year has obviously generated bars in India and around the world because of its theme on terrorism and forced conversion of Karela women who eventually travelled to Afghanistan, joined ISIS and were jailed. Yesterday Islam trended across Twitter as a film director who is the controversy-ridden Sudipto Sen released a thriller despite the opera the movie has generated. I see wonder perhaps why the national film archive of India NFIA and the NFDC approved this distorted movie in the first place. As I prepare for this video I carefully read the timeline of the movie. The evidence upon which the story was based and what critics say about it and I came to a very plausible conclusion that the film was made in bad faith. While the film director Sudipto Sen intends to tell a similarly heartbreaking tale of incidences of alleged forced religious conversion of women in Karela it run into the problem of obvious over-generalization and outright lies. Islamist extremists led by ISIS that they want to convert Karela into the hub of the ISIS and for that they are taking all sorts of means I mean you have to understand that Karela has a very unique kind of demography of the population as in Muslim population in Karela is something close to 22 to 25% Christian population is almost similar little less and rest are Hindu population now if you go to Karela the majority Hindu population which is 50% plus they will most of them will not say they are Hindu they all say they are atheist they are communists but they don't consider as a Hindu population so if you go by the religious demography religious pattern the quote-unquote Hindu population is not more than 10 to 15% rest are atheists so I got sir I when when when I heard we are such an unknown press conference in Delhi I started it it really aroused a huge kind of panic in me because Karela used to be our paradise you know Karela is to it's not only it's a God's own country but also Karela is like a photographer's filmmaker's paradise he claimed that the movie onettes the events behind 32,000 women going missing in Karela marked that 32 women what does the fact say to be honest if he's ashamed that a movie production company is massive as sunshine pictures private would rely on imaginary figures to make a movie addressing a sensitive issue of religion in an India where religious tolerance is often you know marred by seasonal tensions according to the Observer Research Foundation an independent global think time based in Delhi India there are no official reports of systemic forced conversion in Karela that anybody or group with the propensities of reaching that massive 32,000 magic figure 2010 so I'm shifting from 2005 we have such the random statement to 2010 when Oman Chandi was Karela's chief minister on he he put a report on the floor of Karela assembly he cannot deny the fact and and you know he in front of my camera he denied the fact that no nothing had nothing of that sort had happened but I have document that in 2010 in Karela assembly Oman Chandi presented a case where been said that every year 3000 approximately 2800 to 3200 girls being converted into is and taking up Islam so and this this number 2800 to 3200 just calculate in 10 years and following 10 years the number is staggering 32 to 33,000 girls being converted now you tell me that if it is a love then love should prevail in a relationship religion never come into into into that periphery of love so why a girl needs to convert to get married to to get accomplishment of of their love I want you to take note of three key things he said one he mentioned an alleged address of the Karela parliament my chief minister Oman Chandi two he also alleged that Oman Chandi referred to the concept of forced conversion three he claimed his aim are to combat Islamist extremism what are the facts but before the facts a special announcement from our sponsors the videos proudly supported or sponsored by the like and share buttons please smash the like and share with your family and friends there are no records of any news in India about forced conversions in Karela less than 200 Indians had joined ISIS and Karela having over nine million Muslims accounts for less than a quarter interestingly the interview of the chief minister he cited I found was a 2012 Indian to their report would say quote on June 25th Karela chief minister Oman Chandi informed the state legislator that 2,667 young women converted to Islam in the state since 2006 that is from 2006 2012 there was no mention in the reports of women joining ISIS the report added that China had said there was no evidence for forced conversion in the state of Karela and the fears about love to hard were completely business with this in mind what are the facts how can Muslims combat this apparent misinformation using a poorly written movie and what are the lessons we must learn from this latest development assalamu alaikum brothers and sisters welcome to another episode of the open minded thinker show please if you are new to this channel like share and subscribe to let youtube show this video to others to combat lies and islamophobia let's start with who is behind this movie there are two culprits here the producer vipul amrital Shah and director seductive sin for context let's probe the antecedents of the writer and director mr seductive this is a very controversial person he identifies as a communist but has a strong base in the bgp the karela story is not his first attempt at going viral for the wrong reasons in 2018 seductive directed a documentary titled in the name of love the story allegedly centered on what he said was that involuntary mass conversion of 33 000 hindu and christian girls to islam as part of an international conspiracy to render karela an islamic state this was actually found to be false he has been on the forefront of attempt to stay a controversy in islamic india with the support of the bgp and other islamophobes in india he was once asked to present his evidence of false conversion in karela and he said and i quote let the intolerance reach a crescendo i will share my data after the film is released why should i defer the course of my film now how can we trust someone like this he wants to release the movie and then release it cooktop statistics later the truth is that he's been mischievous and by the way what is he hiding yes he's hiding the fact that he's been covertly urged on this path by some anti islamic forces in the ruling party of india and of course other places or tell me why he is not also presenting the official report of the united state department of states country reports on terrorism 2020 where it was established that there were 66 known indian origin fighters affiliated with isis as of november 2020 a number of mainstream media houses including the holistan times and then indian experts had covered publication of the report and mentioned the number 66 in their headlines the same report said and i quote through the end of september the nia had investigated 34 terrorism crises it indicates it indicated we're related to isis and arrested 160 persons by the way when did isis brand of islam authentic islam almost the entire umma are against style and structure of isis and their radical ideology so how is he connecting isis interpretation of islam with a sushu political stage of islam in india this is very poor this indeed a poor guy many a times people ask me that what are my comments regarding isis killing innocent human means and in reply i say that if i say that i am the president of usa will the media report that the president of usa is in south arabia and the answer is no because all of them know very well that i'm not the president of usa they will say some lunatic is saying he's the president or if i speak against his view saying i'm the president of usa they will say an enemy of the president of usa is saying this similarly unfortunately unintentionally ignorantly many of us muslims and the muslim media they promote the enemies of islam the enemies of islam have coined this word isis islamic state of iraq and syria and when the non muslim media says that the islamic state of iraq and syria has killed innocent people many of the muslims they repeat and they say the same thing if you ask me the question has the islamic state of iraq and syria killed the innocent human beings i would say no it is the anti islamic state of iraq and syria which has killed the innocent human beings because islam condemns the killing of innocent human being quran clearly says in surah maya chapter 5 waslam 32 if anyone kills any innocent human being whether it be a muslim or non muslim it is as though you have killed the whole of humanity so the best way for muslims to combat this evil is simply to trend the truth of the faith when the karela story goes live and the coming days let the world know that islam is not what the media says it is let people get to know the faith better this way morsels will be won for god muslims can use their creativity and talents to produce films documentaries and social media content that highlight the diversity beauty and richness of islamic culture and history let live iraq there ladies and gentlemen until next time salaamu alaikum


I've got you. I'm sharing four networking tips for newbie designers today. Tip one, listen more and talk less. Don't talk more than you listen. Networking is what I'm being curious about others. So take the chance to practice your active listening skills. That leads us to number two. Ask questions even if they might seem dumb. If you're new to the industry, nobody expects you to talk like an expert, and that's fine. So ask questions that you're genuinely curious about. Tip three, it doesn't have to be in person. Networking is building connections. So a quick chat on LinkedIn or a five minute call also counts. Tip number four, embrace the awkwardness. Nobody talks about this, but it's okay to feel awkward as hell at networking events. Hell, I feel awkward sometimes. And it shouldn't be deemed as a bad thing. Acknowledge, accept your awkwardness. This is Chris, and I'm always here for a sharing Sunday. Follow me for more tips and hacks in case you don't know.


Minnesota's health insurance exchange says it has signed up more than 20,000 people for coverage in the first nine days of open enrollment. That's a milestone that took six weeks to reach last year. The health plan option is no longer available. After Medica announced today, it has reached an enrollment cap for 2017 and will no longer be selling to new customers either on or off the Minshore exchange. This does not affect current Medica subscribers who wish to renew their policies. Huge premium increases have driven consumers to Minshore, the only place to sign up for subsidies. Open enrollment runs through January 31st. If you've enjoyed this segment of Lakeland News, please consider making a tax-deductible contribution to Lakeland Public Television.