Gallwch chi a ddechrau y cyfrifur ar roi awr chi gefnogaeth am y cyfrifur a i chi'n gallu anodd ni yw wneud yn bwysig hon i chi'n gweld. Felly, rwy'n gweithio byrddwch y cwrwm ar fy gwestiynau, byrddwch ar wyeb y cyfrifur ar y cyfrifur. Rhywbodd yn oed yn gweithio ddwybr yn gysylltu'r gafodol, o ffwrdd, sgu weld cyfrifirwyr, o'r log ffordd deolпа, o'r log ffordd deolpa. Gweithio byrwyd yn gwneud gan ein bod nhw'n gweithio byrdd y grant, ond rydyn ni wneud y gallwch yn rhywbeth yn eich problem. Rydyn ni'n rwy'n meddwl, yn gyflawn i'r ysgolwyd, ac yn ei wneud i ni i ddaeth y cyfrifio a'r ysgolwyddennig yn ysgrifennu ei wneud i'r ysgolwyd yn cyfrifio o'r ysgolwyd. Yn rywbeth, rydyn ni'n rhan o'r random. Rydyn ni'n rhan o'r ysgolwyd cyfrifio yn gyfrifio. Rydyn ni wedi yw hwnnw'n neud yn gweithio i'r cyfrifio, mae'n bydd y defacto web server mewn node. Felly mae'n ystod ychydig yn fawr. Felly mae'n gwneud yn y ffigurau yno, mae'n fawr o'r 50,000... Mae'r byddoch yn fawr yn fawr. Mae'n fawr o'r 50,000 ystod o'r ddod o github. Mae'n ddod o 14 miliwn ydy yn cymdeithas. Felly mae'n fawr o'r byddoch yn fawr. Mae'n ddod o phobl yn fawr. Mae'n ddod o fawr o'r fawr, mae'n ddod o fawr o'r wneud ydw i'n fawr, about ExpressJS, and see what I find. So, to start off, I downloaded it, started using it, and funnily enough, I was happy. It's a fantastic tool, it's very mature, and it's free, what's not to love, you know, it's brilliant. But, you know, being a responsible developer, I wanted to do a little bit of due diligence on the project. I wanted to pick it apart and have a look at are there any particular security challenges here? Are there any particular licensing challenges? So, let's take a look under the covers of ExpressJS. So, the first thing I did was I downloaded a lot of the project metadata, and I wanted to look at how this particular project had evolved over time. So, this is the number of different dependencies of ExpressJS over a 10-year period. So, what you see is, way back at the beginning, Express was composed of, you know, a small handful of modules. Over time, the complexity of ExpressJS grew. So, the project itself is not a single project. It's an ecosystem of projects. And what happens is, over time it gets more and more complex, and then what often happens is, at major releases, they consolidate, they rationalise, and the number of projects decreases. This is pretty typical stuff. Almost every project you use these days is not one project. It's typically tens of projects, or maybe even hundreds of projects. So, I guess that's kind of fine. That's the way things are these days. But at this point, I'm starting to feel a little bit uneasy, because at the outset, I was looking at ExpressJS. I was trying to understand whether it's well maintained. What are the security issues? Now I'm not checking one project. I've now got to check 49 projects. So, my project has just, my problem has just got a lot bigger. So, for example, I can do some simple checks. I can check the licences of these 49 projects. In this case, all of them had relatively traditional, permissive, open source licences. That was fine. Funnily enough, I did this a few years ago with a project called Electron. You're probably all using Electron. If you use Microsoft Teams, if you use Spotify, you'll be using Electron. At that time, when I checked it, one of the thousand dependencies didn't have a licence at all, which meant you're not actually allowed to use it. And the comment in it said, I've just copied this code from someone else. I thought it was hilarious. But it's a growing problem. However, the problem is actually a lot more complicated than that. ExpressJS has 49 dependencies. So, when you deploy it to node, you're deploying 49 different projects. However, Express itself, the project has 195 dependencies. So, where do all these other ones come from? These dependencies are the development dependencies. These are the dependencies that Express itself uses to create Express. This is the tool chain itself that's used to form Express. So, why should we care about this? Does that really matter? Well, these days, it actually matters quite a lot. You will have probably heard of the concept of software supply chain attacks.  I can sneak in and attack through one of the 49 dependencies. I can also sneak in attack through one of the 195 development dependencies. I can add malicious code to the software supply chain. And this does happen. And it's happening increasingly. So, okay. So, the complexity of this is starting to make me a little bit nervous. My initial goal of checking one project has now meant I've got to check 195 projects. Whenever I install Express, I'm installing all of this code onto my machine. So, the next question I wanted to ask myself is, when I install it, is it the same as when you install it? Is it the same as when I installed it last week or the week before? Funnily enough, it's not. Between Express 14.16.4 and 14.17, Express itself changed 33 times, which might seem a little bit odd. What's happened is, as developers, we've come up with this fantastic concept called semantic versioning, where our dependencies are somewhat woolly. We basically say, I'm happy with version 1.1 of this project, maybe 1.2, 1.3, but not version 2. When you have a complex web of dependencies, what that actually means is your deployed configuration changes a surprising number of times. Now I'm getting a little bit scared. I've got 195 dependencies, and they keep changing under my feet. How on earth am I going to work out whether this is a sustainable and secure project? And the other thing that it got me wondering is, who are the people that hold the keys to all these projects? Who are the people who determine whether this is an official release of all of these dependencies? So I started taking a look at that. And I found out that in the direct dependencies, the ecosystem of 49 dependencies, there are actually 88 maintainers who have the ability to push a new release. So I am now dependent on the good practices of these 88 maintainers. Interestingly, NPM, which is the repository that people use to release JavaScript code, only 9% of developers use two-factor authentication. 91% use a simple single-factor, which is their password. The vast majority of people recycle passwords, and I now have the email addresses of these 88 maintainers. You may have heard of a guy called Troy Hunt, he's a very famous security researcher. He publishes a website which indicates, which allows you to look up via an email address whether one of their accounts has been compromised. I can pretty much guarantee if I run these 88 email addresses through his website, I will find one that's been compromised, and I will find a password, and there's a very good likelihood that they will have reused that password. So what I'm saying is, if I wanted to attack Express, I've actually got a pretty good chance of finding a route in. Okay, I'm going to get a bit scared now. This isn't what I was hoping to find. I think we've gone quite far down this rabbit hole, and I think it's time to come up for air. Surely there is someone at the top of this all, the sort of benevolent maintainer of ExpressJS who's worrying about all of this on my behalf. Maybe there's a whole team of people working on ExpressJS worrying about this on my behalf. Ah, no, there isn't. Actually ExpressJS that's downloaded 14 million times every week is maintained by a single individual. They're doing all this feature development, making it wonderful. They probably don't have time for all of the problems that I've just been talking about. Interestingly, I had to look at the history of ExpressJS. In its 10-year history, it's been through two sole maintainers. The very first maintainer approximately five years ago decided he had enough and sold the project to a company called Strongloop. So it's an open source project that he sold to a startup. And a lot of people in the open source community went, hang on, you can't do that. And he said, yeah, I can. It's not a license violation for me to sell this open source project. So the community had a bit of a fallout, but this is something to bear in mind just because something is free and open source now doesn't mean that it's going to be free and open source in the future. Now fortunately in this case, the startup Strongloop were acquired by IBM and one of the things they did when they acquired Strongloop is they took the decision that ExpressJS should be a community project. So they moved it under OpenJS, which is part of Linux Foundation. So that sounds like a happy ending. And after TJ, the original author, abandoned it, sold it and Strongloop then were bought by IBM and it moved into OpenJS, a new maintainer took over. And that didn't go terribly well either. Again, they were in the position of having a sole maintainer. And what happened this time round was there was a particular security vulnerability and this was an interesting one. It was a security vulnerability which had an element of interpretation to it. And if you've ever looked at, if you've ever been involved in security issues, more often than not they're black and white, there's a gray area with respect to the responsibility of each of the parts of your platform and the system. For various reasons the maintainer interpreted a particular requirement in one way and a security vendor, a prominent security vendor interpreted it another way. They released a CVE which was distributed to tens of thousands of their clients who immediately landed on the ExpressJS GitHub repository and said, you have to fix this thing for me now. And the maintainer who doesn't get paid for this quite rightly said, I'm out of here. I'm not enjoying this anymore. Thankfully he stepped back in after a while. Now, to be honest, I wasn't expecting to find any of this. I honestly picked ExpressJS at random. I was astonished at the level of complexity that I uncovered and I was equally astonished at the story, the timeline of ExpressJS, the project itself. It was entirely picked by random which makes me think if I pick another project I may well find a similar story. So, what are the solutions to this problem? First one, yeah, money. Money's the answer to everything, isn't it? Surely there's nothing you can't solve by throwing a decent slug of money at it. So I thought, let's have a look at the relationship between ExpressJS and money. So I looked at the dependencies of ExpressJS, all 195 of them to determine whether any of them had a funding model and I found one. It's a project called ESLint. So ESLint is a tool that helps create a consistent format for JavaScript code. It's really quite popular. And ESLint has funding through a website called Open Collective. So that took me down the next rabbit hole. I thought, okay, that's great. At least part of the Express ecosystem is funded. Let's have a look at Open Collective, see how that's going. So I looked at the 30 most popular and most funded projects on Open Collective. You can see their annual budgets and I converted those annual budgets into full-time employee equivalents. How much developer time would this fund? I found that the top five projects were able to fund one or more developers. ESLint is in the fortunate position that it can fund around about 1.2 developers full time. Open Collective has thousands of projects that are funded through their mechanisms. The vast majority sit on the long tail. In the first 30, you can already see that a number of them can only fund 0.1 full-time equivalents. Whilst I think Open Collective does a fantastic job and I don't want to knock what they do, I really do like them and I use them myself, they are only addressing a tiny fraction of what needs to be done. If we look at Open Source in general, Open UK published a report a couple of years ago where they had some economists to determine the overall value of Open Source to the UK economy. They estimated it contributing around about 43 billion annually to our GDP. Open Collective collects about 0.5 million each year. Tiedlift is the largest entity that's running an Open Source funding model. They distributed about 40 million in funds in the same year. The difference here is many orders of magnitude. There's a huge mismatch between the value that Open Source delivers and the money that it collects. So, how do we solve this? Well, funny enough, most large enterprises take a somewhat medieval approach to the problem. Rather than fixing the problems that they observe, what they more often than not, they spend their time and their funds on building up their own defences. The kind of defences I'm talking about here are paying third parties to do your vulnerability scanning, paying for tooling that protects you from some of the challenges that you see within Open Source. This is big business. Black Duck sold for 500 million just a few years ago. This is, and again, so a company that helps protect you from the challenges of Open Source sold for far... many orders of magnitude more money than the funds that people put into Open Source. We're starting to see an imbalance here. And it does actually cause damage. There was an interesting blog post I read from someone who was a prominent Open Source maintainer who went to an Open Source conference. And, funny enough, a lot of the vendors at Open Source conferences are providing security services to companies. And he was chatting away to one of them and thought, hang on, they charge a 50-person start-up $30,000 a year to help them feel safe using the code that authors like me have been giving away for free. It kind of doesn't make sense anymore, does it? From my perspective, we need to have a radical rethink around our relationship with Open Source in order to fix these problems. And the first thing you need to do when you're having a big rethink is to gain a better understanding and have empathy with the Open Source community. Now, this is a huge topic of itself. If you haven't read this book or seen this book before, I very much encourage you to get a copy of it. It's called Working in Public and it's by a lady called Nadir Egbull and she spent a lot of time immersing herself within the Open Source community and culture to understand and empathise with it. Some of the things that really jumped out at me is GitHub has had a fantastic effect on the community in that it has centralised the community. It's a world-class platform for creating Open Source. However, it's also resulted in a fairly significant challenge. It's much easier now to contribute to Open Source than it was before. Historically, Open Source was behind closed doors tight-knit communities whereas now it's more often than not people having fleeting relationships with projects. She called it the stadium model. You have an Open Source maintainer who is working with thousands of people who have very brief fleeting relationships with their projects and that itself is creating challenges. Probably the most important thing that I read in this book is the most prized assets of most Open Source maintainers is their attention. It's not money, it's attention. They want to be able to spend their time, often their own personal time, doing the thing that excites them most. What I want to do is give you an example of how this can go horribly wrong if you do not understand this. You may have heard of a thing called Hacktoberfest. It's a competition that digital ocean run every year and on the surface of it, it sounds really quite good. Every year, they give away a whole load of t-shirts to people who contribute to Open Source. Again, on the surface, that sounds pretty good. Open Source contribution is good. T-shirts, yeah, people like t-shirts. Unfortunately, what happened a couple of years ago is there was a significant rise in the number of people providing incredibly low quality contributions to Open Source projects just to get a t-shirt. A number of Open Source maintainers actually termed this a distributed denial of service attack on Open Source as a whole. Unfortunately, because digital ocean didn't understand that attention is the most prized asset of a maintainer, they didn't understand the negative impact of the Hacktoberfest project. Now, it's still running and they're trying to address these challenges. But again, you really need to understand the community in order to propose a good fix. So where do we go from there? One of the things I think we need to do is change the terminology. I don't think Open Source is a terribly good term for describing what it is that we are working with and what it is we need to maintain. Commons is something that we're already familiar with. The concept of commons is something we're familiar with from the world around us. The commons is the cultural and natural resources accessible to all members of society, including air, water, habitable earth. These resources are held in common, not privately owned. You probably personally benefit from environmental commons. I know where I live. We've got a dean, for example. There's common land which we all benefit from and we all understand our shared responsibility. Now, with a little tweak, the commons are the software resources accessible to the entire development community, including code, standards and shared infrastructure. These resources are held in common, not privately owned. I'm not the first person to draw this parallel. There's a term that's slowly starting to gain traction, which is that of digital commons. Digital commons actually addresses more than just Open Source. It encompasses things like Wikipedia. I think the term digital commons is a much better way of getting non-technical people to understand that there is this fragile and precious resource that we all have a shared responsibility for maintaining. Once we have an understanding of our shared responsibility, we can start to look at some of the techniques and tools that are already at our disposal to fix this problem. This is what gets us onto the subject of corporate social responsibility. This isn't a new thing. This term emerged in the 60s and it's becoming increasingly important as part of legislation. For example, government procurement contracts of a certain size are only awarded if you have a carbon reduction plan. Corporate social responsibility, or CSR, is becoming a growing concern. I won't go into it in any great detail. A very simplified view of corporate social responsibility can be conveyed by a thing called Carol's Pyramid. At the very bottom, as a business, you have an economic responsibility. Your economic responsibility for most for-profit businesses is to maintain profitability so that you can pay your staff. The next level up of the pyramid is legal, your obligation to obey the law, whether that's regulatory requirements in financial services industry or whether that's employment law. You have a requirement to do so. Next up is your ethical responsibility. Now, this isn't mandatory. It's a choice whether, as a business, you want to operate in an ethical fashion, although legislation is creeping in to the ethical layer. This is your responsibility to be fair, to be reasonable, to do no harm. At the very top of the pyramid is the philanthropy, giving back to the community that you take from, being a net positive contributor as a business. More and more businesses are waking up to the need to be ethical and philanthropic. So, how do you relate this to open source? Well, if we start to draw parallels, a parallel to the economic responsibility is that of consumption. Consumption is simply the fact that you're having... There's an economic benefit to consuming free software. There's a direct relationship between the two. Legal obligations, yes. Within open source software, there are legal obligations obeying the licensing restrictions, trademarks, copyrights. At this point, the parallels seem to end. What I'm arguing is that in the same way businesses should be considering their ethical responsibility and their philanthropic responsibility, I believe there are strong parallels to those within the open source community. Once you change the language to that of the digital commons and understand your responsibility towards the commons, you should start being able to elevate higher up Carroll's Pyramid. So, the final thing I want to do is talk a little bit about turning principle into practice. It's all very good for me to stand up here and be very preachy and say, you know, whichever business you may work in, you should be considering your responsibility to the digital commons. What I wanted to do is talk a little bit about the company I work for, Scott Logic, and how we are looking at embedding open source sustainability into what we do. Now, I'm not going to go into a whole lot of detail, but most businesses will have vision and mission and purpose. You'll probably have language that you use to talk about your purpose to your clients, to your employees. And Scott Logic is similar to most businesses in that regard. Our purpose is to create opportunity and sustainable prosperity through technical innovation. We also have a client mission and an economic mission. I'm not going to go through those. The interesting one here is we have a social mission and that is to operate the company in a way that actively recognizes the role that businesses play in society by initiating innovative ways to create opportunity in our community and to safeguard the future of the natural environment. Now, this social mission has not been written from the perspective of a technologist. However, I would argue and what we are doing in Scott Logic is we are starting to leverage our social mission to better understand our responsibility to the digital commons and our digital environment in the same way that we have a responsibility to maintaining our natural environment. What we're doing in practice is we're looking at some of the consultancy work we're doing for our clients and we are finding areas where we are relying on open source projects that are struggling. Those where we see that the foundations to the products and platforms we're building for our clients where those foundations are fragile and we are actively contributing back to them. We're not making financial contributions. We're looking at how we can spend our time, our developer effort in solving some of the sustainability problems that we see in front of us and that's something I'd encourage you all to do. So in summary, our open source commons are valuable, precious, but fundamentally highly fragile and this is becoming increasingly apparent. What I'd advise is that you need to better understand the community, better understand the motives, better understand the people behind the projects that you're relying upon. And finally, come to a realisation that it's your responsibility, our responsibility to formalise a commitment to sustaining open source. Thank you very much.


What's up everybody jason from jazby's case breaks.com 2019-20 panini select uefa soccer Euro soccer that is hobby edition one box break number 26 random country just sold out excuse me Just sold out And again 20 spots all-carts ship Country list is right here. Austria down to Wales and Good luck guys Let's roll the dice And we got ourselves a three and a four for seven times. So good luck seven times From Juan Donna Christopher one two three four five six seven Christopher at the top Donna Patrick and mosquitoes. All right seven times one two three four five six seven Poland down to Belgium so Christopher Poland Benjamin with checker public Derek with Turkey Chris You have the combo team with Finland all of the countries and skills II Mojo you got Spain one with Austria David with Switzerland Hubert with Wales Joseph with Ukraine David with Sweden Derek with Denmark Joseph with Russia travel Portugal Christopher with Germany France David with Italy Roger with Netherlands you were with Croatia Roger with England and Patrick with Belgium Mojo right there All right, if anybody wants to trade give you guys a quick minute All right mean time really quick Kevin. You got some spots. Thank you man. All right, Ben I think I'm just gonna close the trade window Stickle what you got All right go guys All right guys. Good luck. All right guys. Good luck So you got Frankie de Jong We got a Harry Maguire Silver there for England. Wow. We have caught. I believe he's a big one in this tie-dye 20 out of 25 Who has Germany? Christopher you do man There you go. Very nice. You got a blue Valentino was our Out of 125 that is for Austria Kevin Strutman autograph for the Netherlands Going to Roger Jan out of Poland Robin log out of 25 field level For Finland that's the combo team going to Chris Robert Lewandowski And we got a silver Ronin for Finland Pecan and Kev. That's nice man. Yeah, so far so good. I Would have took seven and a half Google Loris a little Jadon Sancho field level Bulgwa, we got a Michael Lustig out of 149 Jadon Sancho Roger with England And we got Ivan Periscope Croatia Croatia's one of Hubert. We got a Harry Kane orange out of 125 I pulled a Tony for a customer and Daniel James I pulled it the same day as a LeBron That was the first one and then Joe pulled a LeBron out of 175. I don't know Tony. It's gonna go to auction. So Anybody wants to offer they're gonna have to bid Bit on it through auction. Oh, there you go. That's some silvers all the inserts I Quickly top load these cards over here. Alrighty guys. Well, there you go another box of Euro Soccer in the books. There you go. They're gonna stuff as always Little chi-tie that right there as well So appreciate it guys. I'll post up number 27 right now Jaspis case breaks calm


This is getting cold finally, not 90 degrees in January. But January! I know. And the winds, we don't have Santa Ana winds in January. No, we don't. And we don't have 90 degree weather in January. It's such a weird, it's such a weird year. Oh, hey, what's up? Oh, hi. Da de da dee da dee da dee da deed da dee da dee da dee da dee da dee da dee da dee da dee da dee da dee da dee da... живот et tope Hey, welcome back to our stupidly ex Grazie date. I'm Corman. I am Mocani feci di hallova. And you also. Instagram Twitter juicycom. Tengu some page on Follow and Twitter again, ring the bell for me to get a squad. Hey! Eh! Follow someone personally who just can't... Man, there's a script you don't know. It's sobergaseau. Today we're at the throat trailer. We are. We are. Oh yes hooray ha ha join us won't you this is for the great Indian kitchen. Ah, yes It's a big kitchen. Yes. I've been there. It's a really big kitchen really big really big utensils Yeah, yeah, big really big pots and pans big ol Yep, I believe this trailer came out a few weeks ago, but I think the film just came out Okay, and I'm what's it about? I don't know Rick. It's about a great Indian kitchen. I don't know all right We'll find out from the trailer. I'm assuming tell us but it's with a Suraj venture a moodu and Nimisha Shajayan and Let's just get into the I think just came out. I'm hearing lots of good reviews So if you've seen it, let us know how it is before we even get going here Here we Know There we've seen I don't know if it's a good idea to tell you about the film, but I don't know if it's a good idea to tell you about the film. You want to see in theaters for a million reasons, not the least of which is how good the sound is, and it captures what the sound people did. And if you can't do that, the next best thing I have found is to be able to watch it with my AirPods connected, because it gives me the more intimate cinematic kind of sound design that was done. And I have a feeling the sound design on this is going to be pretty awesome based on that. The trailer had some beautiful little intimate, the slicing, the cutting, the boiling. Kind of like Jelly Taku. Yeah, exactly, exactly. And I'm a big fan of both for sound design and makeup artistry. I am far more impressed with the smaller things, not that I don't like the bigger ones, but when I see really great, just small scars or cuts with continuity connected to them. And the same thing with sound, the intimate little intricacies that they capture are to me more difficult. That's what we saw him in. Oh, yeah. Yes, yes, yes, you're absolutely right. I know I recognize this face. And her, she also looked familiar with, she wasn't his wife in it, was she? And was that Molly Ollum? Because it looked, the writing looked Molly Ollum. I will look it up. Yeah, it was, it was both of them. I knew they looked familiar, but it was because they were together in that film. So they're doing another one together. And it's Molly Ollum. Read this.  The story follows her journey as she changes herself and even more so, changes the household. Don't change yourself. Well, yes, you should.  For you, yeah. I'm sorry, don't change for other people. Of course. No, but I think it says, the story follows her journey. They expect her to be. Right, but then it says she changes herself and even more so changes the household as she changes herself. And it just says they expect her to be. Well, there was a period at the end of that sentence. I don't like that. Don't change for anyone ever.  And then change. I'm trying to figure out, this is a Molly Ollum. It sounded like it and the script looked like it. Yeah, the script does look like it. The writing. Yeah, it is. Right there, Molly Ollum. So, if you've seen it, let us know if this is where the watch. I'm hoping we can get to more films this year that actually came out this year. You know what? I don't know, man. The track record with Molly Ollum's cinema. Are you sure we're going to like this? It's probably garbage. I don't know. Let us know about this film down below.


All right. Hello, everyone. Hi. I'm Aditi, the head of design at Referralcandy. Not sure how many people have heard of Referralcandy. We're a small startup based in Singapore. So today I'm going to talk about designing for automated conversations. PS, it's not AI, so more on that later. So we have two products. We are working currently on two products, Referralcandy and Candybar. And we have actually built out automated conversations or bots for both our products. So I'm going to talk about a bit about, I guess, stories, things that we've learnt. But before I start talking about the actual bots and the actual conversations, let me explain a bit about what we do. So Referralcandy is an automated referral program for small and medium businesses. So online stores. And how it works is you install Referralcandy on an online store and then it automates your referral program. And it works with any online store. We have a wide range of merchants using us. So they could be selling clothes, shoes, food, tea, coffee, really anything at all. And it works. So it's already automated, but we thought, you know, and this product has been sort of live for five years. We are doing quite well. And we thought, can something like a messenger bot really make automation better? So it was more like an experiment when we tried it out. So these are a few images of our Referral Assistant. So you can have a look there. Pretty straightforward. I mean, our hope when we built it was, you know, we hope this will be a better experience for people rather than the sort of regular automation. We hope that, you know, it's more personal. It's a more personal experience. It's easier for people to, you know, get their referral code, share it with their friends, stuff like that. We have another product too. It's called Candy Bar. And this is for offline merchants. So Referral Candy is for online merchants and stores, and Candy Bar is for offline brick and mortar merchants. And this is actually how we got into trying out these experiments and trying out these automated conversations because Referral Candy is, you know, five years doing really well and Candy Bar is super new. We recently launched it. And so it was easier for us as a team to do something this new with Candy Bar. It's used by many, many kinds of small and medium businesses like donut shops, cafes, hair salons all over. So we have U.S. merchants. We have merchants in Singapore. We have merchants in the Philippines using us. This is Joel. He's from Mission Juice, and he's in Singapore, and he uses Candy Bar. I think it's important at this point to talk about how much our team actually cares about people like Joel. We really want to make a better experience for people like Joel. And that's why we started out trying and experimenting with automated conversations. This is an image of the Candy Bar assistant. So this is the first assistant that we built out. Pretty straightforward Candy Bar is an automated rewards program for brick-and-mortar merchants. And what you get is you get notified about, you know, when's your next reward? How many points do you have? How many stamps do you have? And stuff like that. So straightforward notifications. But we also built out a feedback feature where we asked people, how was your visit? So after you visit a cafe, we would ask them, you know, was your visit good? Was it bad? And we tried to collect feedback. So this was interesting, and this was sort of our first step into this whole field. So why automated conversations? I think it's good to question, you know, I think Prakriti also mentioned that in her talk, that you shouldn't just do this stuff for the sake of it.  So of course, you know, we want to improve the customer experience. Our products are both merchant-facing and customer-facing. So the merchants see the dashboards, and the customer uses the rewards program or uses the referral program, right? So yeah, it all started with an experiment, and it started with the SMS. So when we first started building out Candy Bar, we had a pretty straightforward SMS. Here's a very real example of our SMS. And a lot of my examples are all real. So very straightforward, as you can see, it's an SMS that is sent to a customer when they join the rewards program, saying, hey, here's your stamp, here's your reward. Please tap on this link. So initially, I was quite obsessed with trying to fix this SMS. I made it shorter. I tried to make the links neater. I tried to rewrite it many, many times. We did a lot of testing with the SMS too. We found out that people really like the unsub link, so we kept it in. So we did a lot of testing, but there are a lot of limitations with SMS. And it was an MVP product, so we let it go initially. I started looking at examples from my everyday life. So these are all real examples from my everyday life in Singapore. Body shops sending me these horrible messages. I'm actually in the loyalty program, and I do use it. But as you can see from this SMS, it's just like characters, and it's not really readable. It's a mess. And then, of course, I get spammed from some random number. And the Redmart delivery notification is not bad. You know, pretty straightforward. Here's your delivery. Apple's SMS also not so bad. That was actually about the time I got my Apple Watch, so I was really excited. And it said, Apple Store, today is the day. So I was like, oh, that's really nice writing, and maybe we should, you know, get a writer to help us improve our SMS. At the same time, I think when you look at the screen, you realize that all of these SMSes sort of look the same from a distance. And there's a limit to how much you can improve your customer's experience with just SMS. So we looked at alternatives to SMS. I started looking at, in my own life, what are the alternatives to SMS that I'm exposed to? So one really nice example from Ninja Van. Again, a delivery notification, but so much better than an SMS. And I was like, thank you. There are other teams experimenting with this and really trying to break out of the SMS situation. Netflix also texts me, which is a bit weird, but once a month, it's not a very useful notification, but it's only once a month, so I don't mind, to be very honest. So yeah, so Netflix also texts me. And I guess what I realized was when you are looking at alternatives to SMS, you're pretty limited, this is the range. The formats are limited, but let's work with what we have, let's stick to the goal, let's try to build a better conversation with our customers and make it more engaging. So that was a pretty sort of starting point for our experiment with Candy Bar. So yeah, why did we first build Candy Bar Assistant before we built Referral Candy Assistant? It's because Candy Bar was a newer product. It was easier for the team to experiment with Candy Bar, Referral Candy, five-year-old product. Most of our revenue comes from there and so we wanted to be more careful with Referral Candy. So after building these two assistants, I think the team and me personally, I think we learned a lot of things and so I'm going to share a few things that we learned. Hopefully some of this is going to be helpful for all of you. It'd be interesting to hear. Number one, take away that I had from working on Candy Bar Assistant especially was don't make it look like a human. Now this sounds a bit counter-intuitive, but hear me out. I think what's happened is we are surrounded by automation already and this is, I think, what I'm trying to say. Samantha is not a real person. This photo is from unsplash.com and is a free commercial image. This is not real. Don't make your bot be Samantha. Be truthful and honest about what you have built. It's an automation, it's a machine. Call it that and so call it Candy Bar Assistant. Use an image that is truthful, please. I think as designers, we should be a little bit more responsible here and we should make sure that we are seeing the right things. The reason for this is that trust is very fragile in an automated conversation and so it's very easy to lose it. It's very easy to figure out that this thing is a bot, so don't even try to act like you're human. Forget about it. This is an example, again, this is a real example from Referral Candy. We have a 15-person customer support team. They are all amazing and they talk to our merchants using Intercom. This is an Intercom conversation between a real human merchant and a real human customer support person. Now, this merchant has become very frustrated because a lot of Shopify merchants, this person is very successful, use a lot of SaaS services. A lot of SaaS services use a lot of bots. This person says, I feel like I've been in a chatbot all last week and this week trying to fix one issue, so you can sort of hear the frustration already in this chat conversation. Unfortunately, Tippi, who is by the way an amazing, amazing guy, has to say, I'm a real person, so no need to worry. This is already happening, folks. People are confused about whether the person they are talking to is a bot or a real person. You know, half the time, you're not really paying attention when you're chatting with some service person. And so it's really, and this sort of underlines this point that I'm making, which is please don't make it act like a human. And so, the conversation ends with Tippi sending a link to our Referral Candy about page where his photo is there and it's very clear that he's part of our team. And so really think about the impact that you're having on the ecosystem. You know, we don't do this, but a lot of other services do. And so as designers, try to pay attention to what's happening. This is a mistake that we made which I like to show people. So we send this automated message. It's not a bot, but Intercom allows you to send automated messages to people. And the photo here, which I've hidden with a smiley face, is somebody from our team and it's a real person. So you can make it seem like a message is sent by a real person, but this is not real, it's automated. So what happens is when this person does a specific task, like an event is triggered, we send this message. So it seems really personal because only this person is getting it at that particular time when you did that task. So this merchant thought it was real and thought it was a real time chat. And so I said, so in the automated message, it said, welcome to your free trial of Candy Bar. Have you tried your first stamp yet? And the person says, hey, sorry, that was rude of me. No, I haven't. So I was shocked. I was like, oh my God, people are so nice. And also I felt so bad because this person is feeling guilty that they didn't do it. So from a quantitative point of view, this is an excellent message. This message does really well. And right after this, we can see on full story that this person actually goes and does their first step of onboarding, which is trying your first stamp. So it's a success. But in the long term, it's not a success, right? We need to make sure that it's clear that this was not a real conversation. This was not a customer support person because we have real customer support people too. So we have to differentiate that this is not real. It's an automation. It's just a reminder and a nod saying, hey, try your first onboarding task and the real customer support is different, right? So yeah, trust is fragile in an automated conversation. Be honest, transparent. That is just a bot. And it's limited. This is not necessarily a bad thing. It's OK. It's just accept that and design accordingly. The other big takeaway for me was design basics are the same, but tools are different. So your design basics are basically the same. You know, iterate a product design, have clear goals, test, design, iterate. In the center of your circle, you have your user data, your content quality, user data coming in and you're sort of testing a lot and all of that. So your basics are pretty much the same. OK. This is a picture of one of the first rounds of testing we did for KaniBar Assistant with real people. It was very important because we were building out the feedback feature. When you ask for feedback, it's a very sort of delicate point. The tone of voice has to be correct. The timing has to be correct. And so we did a lot of testing for that. So here you can see how our feedback feature actually looks. But the tools are different. So initially, I sort of went the same way. I tried to do wireframes. So these are my wireframes initially when I was trying to design the candy bot. I designed them in Sketch and I uploaded them to Zeppelin. But it was a big fail and it doesn't really work to talk to your team about an automated conversation through wireframes. Obviously it doesn't work. And then I downloaded the Sketch files from Facebook.  They look really nice. So I used them and when you're creating Facebook Messenger bot, these are some of the UI elements. So you have quick replies like these three bubbles and stuff like that. So I started making some really nice stuff. But again, this doesn't really work to talk about an automated conversation with your team. They can't really give you feedback on this. It's just like what? So yeah, I actually fell back to this conversation tree especially when I was pairing with senior engineers and they wanted to know the logic of it and so we just drew it out like this and we were iterating very, very fast. So every two days we were changing it as we tried to work towards the MVP. So when you're iterating really fast, you can't make really beautiful looking mockups. You have to sort of just stick to the flow, understand what is the MVP that you are really building. How do you MVP an automated conversation is something I'm trying to share here. The other thing that you have to do is write your MVP script. So that's, I mean, at least that's my recommendation. So think of the script like a movie script. So this is an example from Indiana Jones, I think, yeah. And think of it as a movie script with characters, actions, scenes, stage changes and stuff like that. And this is an example of the candy bar assistant script that I wrote for one of the flows. So what it helps you do is it helps you go through each and every flow, each and every persona and to check for whether this actually makes sense. So you can't only look at it like this, especially from a design point of view, it's very easy to end up writing something that sounds weird. So use a script at least to get to the MVP phase where you need to define what is your MVP script. Once you have your conversation tree and your MVP script then you can sort of start visualizing your little story elements. So for example that's like one of our elements for how the bot says hello. We have four versions of what we say when somebody gives feedback. So if somebody gives bad feedback, the bot mimics empathy and it says oh I'm so sorry about that. Do you want to tell me more about it? So we don't force the person to give us more feedback. But we give them the option. Do you want to add more? So that's how you sort of end up having your story elements and it sort of helps at this point as you build on top of your MVP. The other thing I recommend once you have your MVP script, your conversation tree and all of this in place is prototype it obviously. So we actually build the prototype afterwards because it went live pretty fast. So after it went live I ended up making a prototype. I've tried a few and I like bot society but feel free to explore. This was pretty easy to use and simple. You can share a clickable prototype with the customer support team with the product team and business so that they understand what exactly it is that you're doing. So yeah design basics are the same but the tools are different. And write your MVP script and of course test a lot. Testing is just basics but it helps to say it again. The next big takeaway is become a really good writer or get a really good writer. So I think becoming a really good writer is very difficult so if you can't do that then get a really good writer. And I can't underline this enough because a lot of people think of these automated conversations at a very functional level but the thing is even at the functional level the tone of voice is crucial for success. So it's not about what you say it so make sure you really put in those hours and that time in crafting the right words and something about cultural details. So we have some US merchants using Canibar assistant and I thought oh we had a bit of a brainstorming session in the office and we were like how should we say hello so everybody was like oh cute Jimmy Fallon Jeff would be nice and then we had people replying saying I hate Jimmy Kimmel it's not Jimmy Kimmel it's Jimmy Fallon and you would be surprised how many people hate Jimmy Fallon it's I was surprised I was like oh my god okay yeah so yeah cultural details is easily missable and connected to you know getting a good writer the words you use the details are important in your MVP especially in a script right so please pay attention to this after we got several complaints we actually replaced it with a more generic hi so and by the way no complaints after this it has just been all good so yeah so just be careful about the cultural details here the nuances are important when it comes to text only and chat you know people react in a surprising manners and then the next big take away is it's okay to say sorry it's okay to say I don't know your bot isn't smart it's eventually going to lead to a situation where it doesn't know anything so this is what we do in candy bar assistant but feel free to get creative so the person is actually asking a very relevant question how many points do I have and that's literally what candy bar does it tells you how many points you have how many stamps you have how far you are from the next reward that's all but it doesn't understand right and so you have to apologize at this point and that's okay don't try to write a vague thing that maybe I understood no just be very clear it's a failure point and people figure out pretty quickly so we did a lot of testing and if things don't work people find the right action pretty quickly so you can see this person has immediately tapped on view rewards to find out how many points they have so people can navigate around this sort of UI pretty easily last point and not the least it's not AI so this is the bit from my talk title and it doesn't have to be AI I think a lot of people feel like if you're doing an automated conversation it has to be smart it has to somehow understand everything that the person is saying but it doesn't have to I think as long as your basics are good as long as you're building this automation for good reasons you can still create a really good experience for your customers you can still make something that's enjoyable that's nice and still works and you can still hit your metrics you still do all of that with something that is a dumb bot I think it sort of reminds me of this sort of command line interface from when I was a kid that you used to load up games it's just a basic Q and A format you type in a query and the system does a thing if you type in the wrong query it's an absolute horrible failure and so that is basically what a lot of this automation is you're just making it nicer more human more friendly with emojis and gifs and stuff like that but it is limited and that's okay okay so when I started on this automated conversation design I was pretty much in this phase where I literally asked the internet how do you design an automated conversation then I got a bunch of links and I read medium articles so I hope that after this talk you have a little bit more knowledge at least from what we faced from designing these two very different bots so quick summary number one don't make it look like a human be very clear who is a human and who is not a human so that both can work together in a happy collaboration trust is fragile in an automated conversation so be as honest and truthful as possible of what limitations your bot has your design basics are the same so make sure your goals are very clear make sure a stakeholder alignment is there make sure your qual and quant metrics are balanced make sure you are testing a lot and all of that sort of basic stuff but your tools are different when you are designing an automated conversation write your MVP script and test it as much as possible and try as hard as possible to get a very very very good writer it's okay to say sorry and I don't know and last but not least it's not AI it doesn't have to be you can make a really great experience using something like this as a stand-alone product as an addition to your already existing product it just depends what you want to use it for that's it from me thank you so much thank you so much Ajithi can we get our Slido up we are just going to bring up our Slido can we take questions on the floor we are just struggling a bit with our Slido questions? no one has tried to do that but they do ask a lot of questions some people ask about the weather some people ask for the menu which is more relevant not yet but it's definitely in the plans for now we are very focused on getting it to work really well one of the challenges we are facing is the time out because the conversation should time out that's what people expect but the system remembers and so then it leads to weird there is this loss of stuff to solve before we get to the jokes alright so we have one question which is how does your team measure success with this feature and did you meet your goals? good question so we have metrics product metrics for each thing that we built so initially we measured success with the initial test experiment to see whether it performed better than an SMS pretty simple first step and then when it did perform better than an SMS then we could come up with a new goal can it do other things so initial experiment and then you have your MVP then you have a different goal for your MVP and then you keep building on top of that obviously keep your metrics user centric so for example in referral candy and user metric is referral revenue the more revenue our merchants make it's a win for us it's a win for our merchants and it's a win for the customers too because they are getting rewards so come up with the right metric which is aligned across and then it's easy how long did your testing phase for candy bar really take any tips on how to convince clients that want implementations ASAP clients ok so testing never ends whose question is this ok hi so testing never really we didn't have a testing phase we just constantly testing so how we do testing is we are a really small team we are 4 designers right and about 10 engineers so how testing usually works is I want to test something tomorrow so I send out the word that come into the office and we'll give you $50 Amazon gift voucher and people come it's fine I would definitely come for that yeah yeah participate in usability testing we are always doing it so something that I personally believe and thankfully I've been able to do it with the support of the founders is constant research constant testing so if you have a phase then the whole conversation comes up should we have a testing phase don't even let it get to that point just be testing constantly you just need 5 people anyway for a basic testing so keep doing it constantly so whenever you do need to update there's already so much that you already know sorry does that answer your question ok do you use eb test to test your automatic messages in production environment not yet but it would be nice if we could do that there are a lot of limitations with facebook and facebook messenger and the way it works so it's just more complex but definitely it would be a good thing to try out how do you avoid users frustration how do you avoid users frustration I've been talking about talking to a bot but at the same time make your bot limited to take care of your customers trust wow that's a tough question I think if people are frustrated with your bot and they say I've been talking to a bot that is not a good sign and you should probably switch off your bot for some time and think about it are you sure that you build the right thing because we've had our bot up for a very long time and we haven't had that yet also I think when it comes to the limitations at some point a human has to step in if somebody is having a really bad experience and so luckily we've had an amazing customer support team they do a lot of chat support so they are really familiar with how to say things the right way how to say a welcome message annoying and fake so really learn I think from your customer support team and absorb that and try to put that into your bot and then I would just ask the customer support team if you are having this sort of issue so we have one question from Menaka who is saying did you build a tone of voice system like a design system to keep your messages consistent I'm not sure what a tone of voice system is but definitely we whose question is this it's very difficult actually what I meant is like you have a design system to keep design elements consistent do you have any system like a brand tone of voice that you follow to keep your chat bot messages consistent it would be nice but no I don't think we do I think we should have one we did what I did what I did initially when we first started the experiment was I did a branding workshop with the marketing team there are some really good writers on that team and very good content people so we got them to input you know how should the bot say hi how should it of course that led to the Jimmy Fallon GIF bot I think in terms of branding sure we did that there was a lot of clarity also in terms of what we don't want to do we wanted to be very sort of designed for the metric that we were working towards so all of the decoration was later I'm not sure if I answered your question but we don't have a formal system but there is in a small team it's easier to have a shared understanding of what is okay and what is agreed in terms of our brand there's a lot of sweet because it's candy there's some words and things that we can use more often than others but it can also get annoying so you just have to be very careful I think these are all the questions I did notice during your talk a lot of dog lovers went like so cute are there any cat lovers in there who have any questions why no cats no alright awesome thank you so much Aditi thank you so much for coming in today


It's time for the Lawn Jean Chronoscope, a television journal of the important issues of the hour, brought to you every Monday, Wednesday, and Friday. A presentation of the Lawn Jean Wittner Watch Company, maker of Lawn Jean, the world's most honored watch, and Wittner, distinguished companion to the world honored Lawn Jean. Good evening, this is Frank Knight. May I introduce our co-editors for this edition of the Lawn Jean Chronoscope? Mr. William Bradford Huey, editor of the American Mercury, and Mr. Henry Haslett, contributing editor of Newsweek Magazine. Our distinguished guest for this evening is the right honorable Richard G. Casey, Australian Minister of External Affairs. Mr. Casey, of course, Australia has many friends in our audience tonight because many of us were down in Australia during the war. And you, of course, are the Australian Foreign Minister who's been here for the meeting of the United Nations. Tonight, sir, I'm sure that our viewers would first like your comment on the resignation of Mr. Trig Valley as Secretary General of the UN. What significance do you see in this, sir? Well, Mr. Huey, it was a most dramatic moment this afternoon when Mr. Trig Valley announced his resignation from the Secretary of Generalship. It was quite an emotional moment, too. He directed a good deal of what he had to say towards the Communist Russians, Mr. Vashinsky, and his friends. Well, had the Russians forced him out? Well, there's been bad feeling, you know, between the Russians and Mr. Trig Valley. In fact, Mr. Vashinsky the other day referred to him as the man who calls himself the Secretary General. Well, do you regard this as a blow to our side in the UN, the resignation of Lee? No, I don't really think so. It's an extraordinary difficult task, you know, being Secretary General of immense gatherings such as this. As the resignation anything to do or will it have any effect on our chances for achieving peace in Korea? I don't really think it's got much relationship to that, you know. We've been giving our minds in a few hours since this happened to wondering how we're going to get another Secretary General. Is there any guessing on who that might be? Well, yes. There are certain people, I think, that would not be reluctant to be asked to be Secretary General. But the difficulty is, you see, that the Security Council has got to be unanimous about it, which means the Russians have got to agree. They have the veto power on them, Secretary General. So it likely will be someone from a fairly neutral area, like Sweden or something of that sort. I should think certainly from one of the smaller countries, you know, countries that are not directly involved in the to and fro of this business. Well, Mr. Vashinsky made another one of his long speeches there today, sir. Have you had any opportunity to observe Mr. Vashinsky?  Yes, indeed I have. Both last year when the United Nations was held in Paris and this year Mr. Vashinsky's period of speaking seems to be to vary between two hours as the lower limit and four hours as after the present the upper limit. It's quite an interesting study, I think, because he appears to me to be doing everything possible to increase international tension by what he says and not to decrease it. The minds, of course, work completely differently to ours. We say what we've got to say, what's in our minds. And that at the moment is doing everything possible towards getting a ceasefire and career. We don't try and make debating points. The thing is too serious for that. Is there anything personal about this attitude on his part or is he simply following orders from Moscow and can't do anything else? Oh, and I think he wouldn't object to my saying that he's really the mouthpiece of Moscow and I think he's got to speak as directed. What would be the purpose of these four hour speeches? Simply propaganda against the United States? Oh, certainly. Oh, yes. Oh, quite certainly. I mean, they do definitely regard this United Nations as the best and cheapest propaganda platform in the world. The chief purpose of your meeting now is to try to make a peace in Korea, is try to get a truce in Korea, is it not? Oh, certainly. What progress have you been making in that? Well, it's almost like asking what progress a hen makes in laying an egg. There's not much progress until the egg is laid. And in this case the egg is an agreement between the outside, the United Nations side, the United States side, and the Communists on their side as to the conditions of dealing with the prisoners of war. It's narrowed itself down to the prisoners of war problem. I'm sure that our viewers would like just a straight out prediction from you, Mr. Casey. How do you feel about our chances for getting a ceasefire? Are you hopeful? Well, to be put this way, we've got to assume that the other side wants to see it into the fighting in Korea. I mean, if they don't, well, the fighting goes on. There's no doubt about that. So we've got to make it at the assumption, whether it's true or not, that the Communists want a ceasefire in Korea. Otherwise, all these talk is just completely beside the point. We're prepared, I'm quite sure, to be reasonable in the matter. All we say is that the prisoners of war should individually have the right to say whether they are going to be repatriated to their own country or somewhere else. Well, there's no disposition to yield on that point. Well, I think that's a basic principle with us. It's a simple humanitarian principle, I think. There's nothing further that the United Nations can yield on, is there? No, because it's everything else. All the other factors to bring about a ceasefire have already been agreed. That's the one single outstanding point that we talk endlessly about that. Well, much has been said in our own country about the upcoming visit of General Eisenhower to Korea. Now, sir, how do you feel about that? Do you think that some good might be served, might come from that visit? Oh, yes, indeed. I can very well imagine General Eisenhower wanting to go to Korea. After all, he'll see all the top people on our side. If he goes there, he'll get their views. He'll see the terrain, what the countryside is like. He'll see the South Koreans. He'll meet Shingman Rhee. And he'll gather a very great deal of information that will enable him, I think, to deal with the problem when he assumes the presidency, I think, with a very much greater knowledge. I know, sir, that you would be extremely reluctant to comment on our internal politics. But I wonder if you could give us an answer on this. General Eisenhower has been associated most of his career with Europe. Now, are you people in the Pacific fearful that we will neglect the Pacific area under Eisenhower presidency? No, I don't think so at all. Personally, I'm not at all anxious on that score because General Eisenhower, beyond anything else, he knows world strategy and world tactics, and I think one can be very sure that he'll sum up that situation and realize that the world is one whole, and it's no good winning the Cold War or the Hot War in Europe and leaving the other side of the picture, the East, leaving it out of account. I'm sure he'll get a balanced conception of both sides of the picture. What do you think General Eisenhower can do in Korea that hasn't already been done? Oh, I think, mainly, his purpose would be going, I've no means of reading his mind, but I should think he'd go there to inform his own mind, to get the views of the people, your senior generals and many others, who've been in close contact with this problem there for nearly a couple of years. If I were in his place, I would certainly want to go there. Well, assuming the Chinese communists don't at present want to cease fire, isn't there some kind of pressure that could be put on them in a military way to make them want to cease fire? Some threat that could be used. Well, yes, I wouldn't be prepared offhand to suggest what it might be, but I think if I would be reasonably sure that General Eisenhower would be able to discover what extra pressure could be put on them, and he'd do that, I think, much more easily by a visit there. On that point, sir, of course, Australia has been a rather valiant ally of ours in two wars. Now, how do the Australians feel about the war in Korea? Are you one of our reluctant allies in Korea, or do you think the war has been worth fighting? Well, of course, war is a pretty unpleasant business at any time, and wherever it is. But we've been in it right from the beginning with infantry and naval vessels and air squadrons, and we believe that it's been essential to combat aggression in Korea, because if Korea had not been immediately tackled in the way that it was tackled, very largely, of course, by yourselves, then we believe that the communists would have quite certainly broken out in some other place, and maybe under even worse conditions than the war in Korea. I believe in fact that, as I say, although war is a very unpleasant process, wherever it is, that it's been essential to fight this war in Korea. Are you fearful of what may happen in Japan, of the resurgence of Japan? Well, we people in Australia certainly are a bit anxious about the possibility of the revival of militarism in Japan, because we, like you, have suffered from Japanese militarism in the past, but we certainly agree with you that we've got to do everything possible to try and keep Japan in the democratic camp, not let us slide off onto the communist side. To do that, we've got to, I think, all of us help her to become a normal economy again, a normal country. Well, Mr. Casey is a final question I'd like to ask you about the status of the Pacific Pact now. Well, the Pact, the ENZUS Pact, we call it ANZUS. That's a treaty in being. We had our meeting at Honolulu with Mr. Anderson and my New Zealand colleague and myself three or four months ago, and the military discussions are going on now. The planners are meeting there. It's a Pact in being and we're extremely grateful and glad for its existence. I can assure you. Well, thank you very much, Mr. Casey, for being with us tonight. Thank you, Mr. Hazel. The opinions that you've heard our speakers express tonight have been entirely their own. The editorial board for this edition of the Lawn Jean Chronoscope was Mr. William Bradford Huey and Mr. Henry Haslett. Our distinguished guest for this evening was the right Honorable Richard G. Casey, Australian Minister of External Affairs. The introduction and Rondo Capricioso of Saint-Saëns, played by Michel Piazzaro with the Lawn Jean symphony, is one of the five magnificent selections on the face of this new Lawn Jean Wetner anniversary record album. On the other face, there's a group of half-warming selections sung by the Wetner corollaires. Now, this 12-inch long-playing album, magnificently recorded with almost a full hour of enchanted music, would cost anywhere from four to five dollars, if commercially made. Now, you can buy it right in your own community during the month of November, as the goodwill offer of your Lawn Jean Wetner jeweler for only $1.95. This Lawn Jean Wetner anniversary album is the November goodwill offer of your Lawn Jean Wetner jeweler, a reliable jeweler from whom to buy diamonds and fine gold jewelry, and of course, Lawn Jean and Wetner watches. From coast to coast, there are more than 4,000 Lawn Jean Wetner jeweler agencies. Now, tomorrow, take advantage of this opportunity to obtain the symphony and corollaires anniversary album at only $1.95. And at the same time, see these new and beautiful Lawn Jean and Wetner watches for Christmas giving. We invite you to join us every Monday, Wednesday and Friday evening at this same time for the Lawn Jean Chronoscope, a television journal of the important issues of the hour, broadcast on behalf of Lawn Jean, the world's most honored watch, and Wetner distinguished companion to the world honored Lawn Jean. This is Frank Knight reminding you that Lawn Jean and Wetner watches are sold and serviced from coast to coast by more than 4,000 leading jewelers who proudly display this emblem. Agency for Lawn Jean Wetner watches. Tuesday night thrills, danger on the CBS television network.


Hey everyone, welcome back to theCUBE's coverage of KUPA Inspire 2022. This is day two, we've been on the ground in Las Vegas at the Cosmopolitan. Lisa Martin here with Kyle Rogers. Great to be talking with KUPA customers, partners, all the good stuff. Kyle, you are the partner finance effectiveness at ClearSulting, welcome to the program. Thank you, thank you. I'm super happy to be here and we're really excited to be a partner with KUPA. Talk to me a little bit about ClearSulting so the audience gets an understanding of what you guys are doing. Perfect, so I'll introduce myself first. I'm Kyle Rogers, as you mentioned, I'm a partner at the firm. I lead our finance effectiveness practice and we focus on a few things. So first is like general finance and accounting operating model work. The second is a lot of global business services, shared services work, helping clients think about where their talent should sit and how those global work flows should work. And then what's really important this week is we've got a deep capability and procure to pay. And at ClearSulting, we work with our clients to drive kind of thoughtful and complex solutions for procurement and finance executives using digital as a key enabler in that. And we've got a number of practices so we focus on finance effectiveness, which I lead. We've got enterprise performance management, risk advisory, record to report and treasury. One of the things that is the spirit of KUPA is collaboration, the community. How does ClearSulting, how do you collaborate with your clients? Yeah, it's a great question because we think collaboration is so core to being successful and driving good outcomes. So the ways we collaborate with our clients, at first we bring like deep expertise around procure to pay, functional, subject matter experts. And we complement that with our innovation center, which is a team that's focused on really staying on the forefront of digital and technical solutions and making sure we bring them together to give robust and powerful outcomes for our clients. And then lastly and really importantly, we meet our clients where they are. They're all at different stages in their maturity. They've got different goals and objectives. Some might be trying to have a focused, kind of really niche outcome whereas others might be transformational in nature. So we make sure that we right size our solutions to really get them where they're trying to go. When you're talking with customers that are maybe in the infancy of digitizing procure to pay, for example, what are some of the concerns that they have? I mean, I guess these days, if you're not digital, you're not very competitive. Right. Digital is so important to what they do, not only to reduce costs and taking efficiencies out of the business, but also when you think about the importance of decision support, right? So tightening the cycle time between business activity and making sense of it, using technology as core and fundamental to being successful. What are some of the trends that you're seeing in procurement, especially anything top of mind the last two years? Yeah. So what we love about Clear Solting is we've got a broad base of clients. And when we meet and work with each of them, they all have their different needs and goals. And we've been able to see some through lines across each that have started to emerge. And we've really seen three trends emerge. So the first is there's a big focus on operational efficiency. So moving towards a touchless world, taking cost out of the business and really moving towards exception-based, system-driven processes and more towards end-side generation decision support and the like. And then the second is there's a real increased focus on getting total visibility in your spend management, right?  And that's really come to the fore through a lot of the supply chain volatility, a lot of the volatility around pricing, especially when you look at things like commodities and just getting real your arms around what you're spending on. And then lastly, there's a new and diverse set of talent in the workforce today, right? And the last 10 to 20 years, we've seen digitally native talent graduate into the workforce. And what their hopes and desires and needs are in the workplace are very different than the generation before them. So just giving them tools and digital technologies that will attract them but also retain them when they're here, yeah. And then also when you think about some of the shifts towards a more remote or hybrid model, having tools and capabilities that allow you to do that. And Koopa's a great example. Right, well, you talked about, different generations and the younger generations. I think there's four or five generations that are in the workforce today. Wow. And so, and you think of, you talked about the remote and this hybrid environment that we're still living in, how everything has changed so dramatically in the last couple of years that being touchless, contactless, paperless, really became essential for so many businesses. How do you guys, what do you define as touchless? How is it different than, say, paperless? Is it just another way of saying it or does it actually mean something different? It's a little different. And it's not truly touchless because you still need to have the human as part of the process, right? But when we say touchless, it's identifying those points of, where is it rules-based? Where can we use business logic to drive some system-based decisions and taking the robot out of the human as some say and really having the human spend their time on, how can I use this information to support the business, get insights out of it and focus my time on work that's meaningful and powerful? Well, work that's meaningful and powerful to them that will make them want to stay at their jobs, but also work that allows them to be able to focus on more strategic projects for the business, let the other stuff be touchless and automated where it can be so that their focus is on more business-critical activities or initiatives. Absolutely, absolutely. So when you think about things like supporting, sourcing, on making sure that they've got their strategic suppliers set up and they're spending with the right suppliers, that is so much more valuable of use of your time than reconciling an invoice to a goods receipt. Right. Right. You mentioned insights and visibility, and visibility, I was just talking with a Koopa customer that had uncovered $2 billion in indirect spend that they couldn't see before Koopa, and I just can't help but think how many businesses in every industry are out there with billions in indirect spend that they literally can't see. If you can't see it, you can't be able to make the right decisions on it. Talk to me about enabling that visibility as a key outcome for your clients. Right. And I think that to your point, it's not just that. What we also see is there's not great duplicate detection. So a lot of times our customers are, our clients are paying their suppliers more than once for the same inventory. So getting their view on exactly what they're spending, what's paid, what's not paid, how is it impacting our supply chain? How is that balancing up against our revenue forecast to make sure that we've got inventory moving through our supply chain at the right time? Visibility there is fundamental to being successful in the current day marketplace. Talk to me about now some of your experiences working directly with Koopa clients. What are some of the things that you've been able to enable? Any stories stick out in your mind as this really articulates the value that we bring with to Koopa? Absolutely. So we worked with, we just wrapped up a project and the client was using some legacy ERPs. They had gone through a period of pretty significant M&A. So they have a pretty diverse technology landscape and they wanted to find a peculiar pay solution that met all of their requirements. And Koopa was the perfect fit. He helped work them through the process and move towards where a point where every single invoice had to get manually entered, every single invoice had to get manually matched. Oh wow. Yeah, to leveraging a lot of the capabilities Koopa has around EDI and DCR and the supplier portal to automate a lot of that and then streamline a lot of the matching and on the backend, just getting visibility into who you're spending your money with. As you mentioned, you said $2 billion of an indirect spend that they had no idea where that was going. That is very common. Common.  Are you seeing any trends towards that maybe changing considering what we've all been through in the last two years when suddenly everybody went home and you couldn't get to those paper invoices or those paper POs? Do you see more businesses going, help us out, we've got to digitize, we don't have a choice? Yes, absolutely, absolutely. So it's moving suppliers on to more digital invoice submission methods, whether it be the portal, whether it be digital PDF sending in through common inboxes and then moving it away from invoices, not going to the manufacturing plants anymore. We've got that going to a central location. If it needs to be physical, you've got one place that houses it versus many disparate ones. Well, and Koopa talked a lot about that the last couple of days about the, essentially the getting rid of the silos. I was talking with Rob earlier today, Rajah Hamoud was here as well and talking about, there's still a lot of silos out there that our organizations are operating under which limits their visibility and limits their potential, I think, to be competitive. Right, and I think what we find is procurement is historically has been a very siloed organization because that's been the back of what a lot of businesses grow on as either R&D or procurement buyers and they don't want to have a lot of control in their space. So making sure that they can have the flexibility to buy real time, maybe use a lot of institutional knowledge to overcome some process or system gaps. So there can be some challenges moving them into centralized model. But when you think about the broader business case on rationalizing your supplier base and making sure that you're getting most favorable terms with your suppliers and then also having control over when cash goes out the door, who goes out the door to is far outweighs some of the other benefits associated with having a decentralized. These days businesses in any industry don't have time to wait for tribal knowledge to be able to help determine the next direction. We are also used to everything on demand that the real time access to the data, the insights, where's the money going, who are we contracting with. That real time is no longer a nice thing to have for organizations, it's a requirement. Right, and I think one big shift we've seen is a lot of companies used to be organized functionally. So meaning you had finance operating as silo, procurement operating as silo, IT operating as silo, but that's really been flipped on its head. And they're now organized around ending processes. So when you look at procure to pay, you're touching a diverse set of stakeholders from sourcing, procurement, IT, treasury, legal, finance, and so on. So tribal knowledge doesn't work anymore. You have to have tight handoffs, you have to have tight orchestration and you need to have stakeholders aligned. How do you help customers navigate that? Cause one of the things that can be challenging is especially for maybe more history organizations that are used to and very comfortable in their swim lanes and their silos. How do you help them from a change management perspective be able to connect all those pieces together so that ultimately everybody's job is able to deliver more value to the business? Right, so one of the things that we at ClearSolting are really good at is we understand the language of each of those stakeholder groups. So we can talk to finance, we can talk to procurement, we can talk to sourcing and IT, and we understand what makes them tick and what their objectives are and how they think. So when we work with our clients, we really make sure that we have that through line around what's the common story here, the common message that's going to resonate with everyone because it's really important that your stakeholders engage and on board to have successful outcomes with Coupa or any sort of P2P transformation. I want to talk about talent for a second. You mentioned that a minute ago and you know, we're all living through the great resignation. I'm sure you have friends I do too that decided to make changes during the last couple of years. The opportunities are there, but it's important for companies to be able to retain talent. But, and part of that to your point earlier was especially for the younger generations, you need to be able to have the technology and the capabilities to enable that generation to want to stay and grow within an organization. Right, and I think Coupa has really driven value to our client's talent strategies in a couple of ways. Chiefly, it's moving the robot out of a human which I mentioned a little bit about earlier. So a lot of the activities that are repetitive, rule-based that historically we've thrown people at to try and get it done, now the system can handle that. As long as you've got your processes designed accordingly it can accommodate a lot of those exceptions. And the work that people are supporting after that is more meaningful, right? It's understanding, okay, what's valuable to the business? How can I help support decisions to do that? And what can we do around continuous improvement to continue to maximize what we're doing? And then secondly, around the great resignation, the remote or hybrid model is a key recruitment mechanism and using Coupa, which is a SaaS solution and one that can be orchestrated and designed globally allows for more flexible models, both from remote to in-person but also allows for global flexibility, right? And global workflows. Global flexibility, global workflows but also that global collaboration that I think we all need to have and that's really what Coupa thrives on, that community that's really, I always say, it's very symbiotic. Yeah, absolutely, absolutely. And Coupa being an integrated solution that as we mentioned is end-to-end source-to-pay allows for seamless integration across each of your communities and each a part of your business because then you can look at things globally as well as opposed to some of the siloed and more regional views that they had before. Right. What are some of the last question for you? What are some of the things that are exciting to you about what you've heard at the event the last couple of days, some of the future direction of clear-silting? What's on your plate? You know, the session yesterday morning around collaboration was really powerful to us because we find that collaboration with our clients is a big change agent to driving value and then thinking about your supplier network as an ecosystem to collaborate on is a big takeaway from us this weekend and it's been really powerful to see everyone working together and finding creative solutions that meet everyone's needs in a global workforce. Yep, I agree. Kyle, thank you for joining me on the program this afternoon talking about clear-silting, your partnership with Coupa and how you're helping those customers go touchless. We appreciate your insights. Thank you, Lisa. It's a pleasure to be here. All right. Kyle Rogers, I'm Lisa Martin. You're watching theCUBE's coverage of Coupa-inspired day two coming at ya from Las Vegas.


And here's a question from Cuba 667. Does the involvement in the Octo project will result in a new product line where a double MCU will be used in a single package? Where's the first MCU more powerful can run Linux and the second one RTOS? Real-time operations are still critical in some cases but the standard Linux kernel can't deliver the hard real-time capabilities that are a large number of embedded systems demand or maybe there is something much bigger planned like QNX. Hello, so I'm Gerard Baizard. I am the STM32MP1 software architect. So thanks for your question. This is a very good question with very pertinent assumption inside. So when this question was raised, you were not already aware that we were about to announce the STM32MP1. You can move on. So the STM32MP1 is the first MPU that extends the original non-STM32MCU family. In this processor, it is a heterogeneous architecture so you will find on the right Cortex-M4 running STM32Q. So this one can be dedicated to run some real-time applications. For instance, in this demo, it is used to control the water. We have all the external memories. The good thing is you have a Raspberry Pi on the left. On the diagram, you can see that this MPU embed also a dual Cortex-A7 that is running Linux. Our Linux distribution is called Poplan-STL Linux distribution and indeed, as you noticed, it is based on your project. So that is for the demonstration. If you want more information, you can use STM32MP1. So it would be easy to develop this? Yes. And it sounds that it could be complicated. There's two things going on at the same time. You have to manage, how do you manage? Yes, so we try to make it easy extending the STM32Q by mixed tool. Maybe we can have a look on it. So you do a mixed tool. There is now a panel with several contexts. And you can easily select to which execution context you want. You just say I want an A7 or I want an Cortex-M4. Exactly. And what's the one in the middle there? What is the difference between those two? A7NS is for A7 secure. Let's say it runs on. A7NS is for A7 non-secure. That is running Linux. And the Cortex-M4, of course, is for STM32Q. And is this thing you just choose? Yes, you choose and after you can generate the initialization code. So it will generate the STM32Q firmware as it used to do with the MCU. And for Linux side, we generate the device tree that is used for the product configuration. What is this? This is a pinout. So this is directly inherited from what we had in the past already in STM32Q by mixed. This way, the customer can easily choose a pinout and assign each pin to the function he wants on his product. Define each pin? Yeah. That's a deep level control. Yes. All right. You're welcome. Bye.