Now I have this other terminology that we had on there, which is a dilution series. And this dilution series, where they have the same components, but at different concentrations. So, at a stock, in lab we used a dye, right? And we had pre-tubes, right? And here we took one male into that one, 0.2 males into this one, and 0.1 male into that one. To this one we added 9 males, so we had 1 to 1 plus 9, or 1 to 10. This one we brought up to 10 males again, so we had to add 9.8 males. So, in this case, so that gives us 0.2 to 0.2 plus 9.8, which is going to give us a 1 to 50 dilution. So that 0.2 males is 1.50 of the 10 males. So, we can see then, in this one where we've got 1 tenth, we'd have to add 9.9 males yet. So in this case we've got 0.1, or 0.1 plus male plus 9.9 males. So that's going to be 1 to 100. So there's 1 tenth to 100 tenths, so that's a 1 to 100 dilution. So they're all in this case coming from the stock, and so there are series that were making these components. So in this case it's just terminology, but it's related to our third group. And this is a form you'll see used often in the lab, serial dilutions. This is a series of dilution, the same dilution factor. Now, up in this dilution series, which we just did, we had a factor of 10 and a factor of 5th in 100. They were all dilutions of the same stock, but they had different dilution factors. So in our serial dilution, we're going to set these up so that they all have the same dilution factor. So you can find this on your lab sheet. So hopefully you've read it and you may already understand it. So we have these set of tubes here. We're going to say that each one of these tubes has one male in it. And we're going to move one male from this tube into this tube, which is going to bring it up to two males initially, but then we're going to mix it up well. Get it a homogeneous mixture and then move one male from that tube to the next. We'll do the same thing. We'll mix it well and move a male to the next tube, repeat the male after we mix it, and then finally here we'll move a male from there. So this is a serial dilution. Each one is diluted from the previous dilution into the next one. So we're seeing this one male plus one male is a one to two. Next dilution is also a one to two because it's one plus one to two, but it is a dilution of a one to two. So now it's really a one to four. We can put this one concentration of one to two. So the concentration of this tube is one fourth what it was in the original tube because it's one half of this one half. So then we're going to do another one to two, but now that's going to be one eighth, right? So we see the same thing going on. We're repeating the same dilution factor. In this case the dilution factor is two. So each one you can see is getting our denominator is doubling. So we go one half, one fourth, one eighth and one sixteenth and then one thirty seconds. So by doing these sets of serial dilution we've gone from our undiluted sample here in the first tube to a one to thirty two dilution. So the concentration of what we're diluting our stock here in tube one is one thirty second, right? Or we could say that it's a thirty two fold, right? Total dilution is supposed to be thirty two, right? And the other thing we can say that this is a two fold serial dilution. So the terminology tells us that it's a serial dilution because we're doing a series of two fold dilutions. So in this case our definition says that it has the same dilution factor. In this case the dilution factor is two, right? So let's just do another quick example here to just show another one. So here I've got another set of tubes. In this case we have our stock here in this first tube, right? And then we have our serial dilution one. We have nine mills in each one and we're moving one mill across mixing it. So there nine plus one, right? One, so that's a one to ten. Now if we mix it we're going to take one mill of that. We only have nine mills of that left since we're taking one mill away. But the concentration is based on that one plus the nine. So we're taking one into this nine. So it's one right here again plus the nine with one. So we've got another one tenth, but this is what? One tenth over one tenth. So that's going to be one to a hundred. Likewise we take one mill over. So we've got another one ten. But since it's one to ten over one to ten it'll be another ten fold, which from a hundred would now be one to a thousand. And here again another one to ten would give us one to ten thousand ten. And here a one to ten would be one to a hundred thousand. Now we have other ways to write this. Okay so we've got one to ten. We could just write this one to ten square. We could write this one. Hold on. The ten cubed one over ten to the fourth or one over ten to the fifth. So this is kind of a better way of writing it and having those two zeros and those are equivalent. Another way that we can write this without the fractional form is we can say that's ten to the negative one, ten to the negative two, ten to the negative three, ten to the minus four, ten to the minus five. So if you remember your thing about negative exponents, right, those are equivalent. One tenth is ten to the one. So if you see in this case ten to the minus two, it's the same thing as one over ten to the plus two. So these are all ways of writing that in this case. This is a serial tenfold dilution. So in this case from our undiluted concentration, which we're saying one, by doing one, two, three, four, five dilutions, we've gotten a hundred thousand fold dilution of this stop. So it's another tool. It's a frequently used tool in doing that.  For instance, if you had a concentration we have there on the paper, blue-cut grams per mil, and we added one mil plus nine mils of water, right, to give us a one over one plus nine is a one to ten dilution. Then we would say four grams per mil, and one tenth is equal to zero point four grams per mil. And that seems reasonable, point four gram is a tenth, right, a four gram. So by diluting it tenfold, we've got one tenth the concentration. Let me, I don't know what that line is there, let me get that worked out. That's one over one plus nine, one over ten, let me get that there. Okay, so that's kind of a lot of information there. I say it's in your book, it's in the lab and you've hopefully done a lab on this, so you get a notion of what's going on with dilutions. But this is kind of a, kind of went, wanted to go over the information on that sheet with you to kind of verbally explain what's going on with that. And that will conclude this kind of introduction and dilutions. And I'll set up another video to talk about solutions. Thanks for listening.


I'm a climate scientist and I have to say that the importance of having, I love your phrase in the film, a recovering politician, of your statue of being able to communicate and actually push the agenda for the climate crisis has been very important. And it's clear that the first film had a huge impact. So it adds to the question, why do you sequel? What was the motivation behind you doing a sequel? Well, when we reached the 10-year anniversary of the first movie, it seemed like an appropriate time to present what's new in the previous decade. And there have been two very big changes and a third that occurred during the filming of the movie. The first is that unfortunately the climate-related extreme weather events have, of course, become far more common and more destructive. The nature is speaking up in a very persuasive way. The second big change is that the solutions are here now. A decade ago you could see them on the horizon, but you had to have the technology experts reassure you that they're coming. They'll be here. Well, now they're here. And for example, electricity from wind and solar has fallen so quickly in price that in many regions it's much cheaper than electricity from fossil fuels and soon will be almost everywhere. Electric cars are becoming affordable. Batteries are now beginning to decline sharply in price, which will be a real game changer for the energy industry. LEDs and hundreds of new, far more efficient technologies are helping to stabilize and soon reduce emissions. I was struck in the middle of your film there was a profound statement you made which really resonated with me where you said, to fix the climate crisis, we need to fix democracy. And I'm like, yes. And then unfortunately the film moved on to something else and I thought, no. So can I take this opportunity to say, how do you think we can fix our democracies now in the 21st century? Well, big money has hacked our democracy even before Putin did. And it accompanied the transition from the printing press to television when all of a sudden candidates, especially in the U.S., were made to feel they have to spend all their time begging rich people and special interests for money so they can buy more TV ads than their opponents. And that's really given an enormous unhealthy and toxic degree of influence to lobbyists and special interests. Now just as television replaced the printing press, now internet-based media are beginning to displace television and once again open up the doorways to the public forum for individuals who can use knowledge and the best available evidence. And if you believe in democracy as I do and if you believe in harvesting the wisdom of crowds, then the interaction of free people exchanging the best available evidence of what's more likely to be true than not will once again push us toward a government ob-bye and for the people. One quick example. Last year, the Bernie Sanders campaign, regardless of what you might think about his agenda, proved that it is now possible on the internet to run a very credible nationwide campaign without taking any money from lobbyists and special interests or billionaires. Instead, you can raise money in small amounts from individuals on the internet and then be accountable to them and not have to worry about being accountable to the big donors. It's really interesting that quite a few companies are also using that small donations and small raising of funds to actually crowdsource quite a lot of the renewables that we need in the future.  We both have countries have a problem with having a two-party system. Can I ask you, how do you reach out to those Republicans and some of the Democrats that still don't get climate change?  Well, part of it is related to the changes necessary and the financing of campaigns. A famous journalist in the US over a century ago, Upton Sinclair, wrote, it's difficult to get a man to understand something if his salary depends upon him not understanding it. And if you substitute campaign finance for salary, you get part of the answer. But I know for a fact that there are many Republican members of the Senate and House who know that what they've been advocating is wrong and would like to crawl back from the end of the limb. They've put themselves on and as more and more people express the passionate view that we've got to solve the climate crisis that can give them the backbone to change their position. Some of them already have. There's a new Noah's Ark caucus in the Congress, a reference to the biblical deluge, but also a reference to the fact that they only can join by twos, one Democrat, one Republican, and more Republicans are now switching sides. I also want to ask a couple of commentators have mentioned that perhaps you've done a great, well, you have done a great job communicating climate change around the world, but perhaps you being a very prominent, highly respected liberal Democrat has actually incensed some Republicans and actually hardened their view. Do you feel that's fair or do you think that they have that view anyway? Oh, I don't think that's fair at all. And in fact, there's been a great deal of social science research that shows that's completely inaccurate. You may know Joe Rome, who is a great climate blogger. He's compiled all that research for two and a half years after the first movie bipartisanship increased significantly on this issue. The Republican nominee in 2000, a John McCain, what had a very responsible position on this issue. But what happened was in the wake of the Great Recession, the carbon polluters launched the Tea Party movement. Some of them joined on their own, but they actually provided the seed money and insisted that climate denial be a part of that political movement. The carbon polluters have done exactly what the tobacco companies did years ago when they hired actors and dressed them up as doctors and put them on camera to say there are no health problems with cigarettes. A hundred million people died as a result. Well, now the carbon polluters have taken that same approach, hired the same PR firms and have spent more than a billion dollars to put out pseudoscience and false information. They're not necessarily going to win the debate. They just want to give the appearance that there is a debate in order to paralyze the political process, but people are seeing through it now.


Okay, thanks for joining this session. So our next section is about choosing cloud-name technology for the journey to the multi-cloud. And thanks for joining this session once again, including the virtual audience as well. So quick introduction to myself. My name is Daniel Loh. I'm a CNCP ambassador and then a lot of stuff in track chair and a track committee member in KubeCon. I'm so happy to be here to introduce now our great speaker Darina from Form 3 as a technical evangelist. So please welcome our next great speaker. Hello, everyone. Hi, I'm Adelina and today we'll be talking about Form 3's journey to multi-cloud, some of the technologies that we use and exactly how they fit together. It's my first time at KubeCon and my first time speaking on this amazing stage. And I really appreciate that so many of you took the time to hear me. So Daniel already said that I'm a technology evangelist of Form 3, but I just wanted to give a shout out to our amazing engineering team who have done all of the great work that I have the honor to present to you today. All right, so this talk will consist of a quick introduction of why we decided to go multi-cloud and what it actually means. I'll set the background and I'll show you our previous architecture. And then I will introduce each of the technologies that have made the multi-cloud transition possible. And in particular, it'll be Kubernetes, Selium, Nats, and CockroachDB. And these are amazing cloud agnostic technologies that we'll be learning about today. All right, so let's begin. We've got a lot, a lot of ground to cover. First, I'd like to introduce exactly what Form 3 does. So Form 3 sits between our customers, which are financial institutions and the external payments infrastructure that power interbank transactions. As you can imagine, banks don't directly integrate with each other, that would be a maintenance nightmare. Instead, when they process payments in between banks, they go through external payments infrastructure that actually define the standards that we use for interbank transactions. And we make our customers' lives easier because we take care of all of the securing of actual payments processing and then they integrate with our APIs. So a lot of the decisions that we make when it comes to architecture and technologies come from some of the challenges that we face in the world of payments processing. First, we process a huge number of transactions. So we have a large volume that comes from virtually an unlimited number of users. Next, we have reliability and durability. We need to recover from outages without dropping or repeating transactions because if we drop transactions, then money disappears. And if we repeat it, then we invent it in thin air. So that's not really good, except, you know, hopefully if we gave you more money, you wouldn't be upset with us. And thirdly, there is quite a bit of maintenance. The external payments infrastructures that you saw, there's a few kind of different payments and they also update their external payment schemes, their endpoints. So it can be difficult for a client that has maybe a smaller engineering team to keep on top of all of these changes. And this is another thing that we are able to take care of. All right, so this is the architecture that we had before the multi-cloud project. And it's not the beginning architecture of Form 3, but it will be our starting point today. So we had our payment services hosted in AWS and our platform is written in Go. That's why you see the really cute gophers with their little stack there. We used SQS and SNS fan out for messaging. We used Postgres hosted on RDS as our database. Then due to regulatory requirements for the FPS payment scheme, which stands for faster payment services, we have to process transactions on least lines. And this is why we actually started with a hybrid architecture. We have two data centers hosted by our partners at Equinix. And this, the data centers used run on bare metal Kubernetes and again have payment services that are written in Go, use NAT streaming and Cockroach DB as messaging and data. And then they were meshed with Selium as well. So what the banking sector is regulated and that is also one of the reasons why it was the last to move to the cloud. And as we take on more and more clients and we have to process an increasing number of transactions, neither our clients nor the regulator want us to be dependent on a particular cloud vendor. Instead, we wanted to give our clients the peace of mind and the flexibility to run on multi-cloud. And in particular, we wanted to treat the cloud as undifferentiated heavy lifting, allowing our clients to connect to whatever cloud vendor they wanted to. And then we would achieve high availability because then they could connect to whichever payment service that was either running or that they preferred. So going multi-cloud, obviously that's gonna be really easy, right? Like what could possibly go wrong? In fact, the team identified a large amount of challenges from the very beginning. And in particular, networking and service discovery was expected to be the most difficult part of going to the multi-cloud. And we needed to continue keeping our latency down as our platform is strongly consistent. Of course, we could have opted to build our platform all over again on another cloud provider like GCP, for example, but that would be a very difficult and long project. So we decided instead to move to cloud agnostic technologies which is the story that I will be telling you today. Okay, so first off, the challenge of deployment. And in particular, we wanted our teams to have the same development and deployment experience regardless of what cloud they were running on. And regardless of whether it was the public or the private cloud. We needed to abstract away whether in which cloud you're running. So it didn't really matter what you were doing. And we also wanted to be able to not hinder them in any case, in any way. So deployment, the development and deployment should continue to happen at the same speed that they were used to. So we decided to use Kubernetes. And obviously Kubernetes is so well known that I won't go into actually presenting it to you. But it allows us, these are the main three reasons why we decided to go with it. First off, it allows automation of deployment, scaling and management of even more most difficult applications. It is cloud agnostic and deploys workloads in any public or private cloud. And that would make us, that would take the box of actually I don't really care what cloud I'm running in. And with its operators and CRDs, it is extendable. So it's a really great system for us to use. So this is what we ended up doing. Like we deploy our payment services across three cloud vendors, AWS, Azure and GCP. And we decided to opt for the managed Kubernetes offering because that would allow us to offload a lot of the work and expertise that was needed to run the Kubernetes clusters. Of course, we could have used, we could have chosen to run, to have the cloud provider provision VMs and for us to run, but to run the Kubernetes clusters ourselves. But that actually would have been a lot more difficult and it can require quite a bit of expertise. So we, from the very beginning, this is one of the things that our engineers always do, which is like to push as much responsibility to the specialists, if you can call them that, to the specialists that maintain the public cloud. And this allows us to use our engineering resources optimally and have our engineers do as much, do what they do best. So we like to push as much responsibility to the public cloud vendor while avoiding lock-in as possible. So this shows you a little bit, an overview of our stacks and environments. We have multi-cloud stacks, as you can see on AWS, GCP and Azure. And then the deployments go in order from dev to test to production. And stacks contain exactly the same services except that they are ring-fenced copies that allow our engineers to test their work end to end. Then we also have the possibility to run in bespoke accounts for data location and isolation requirements. And most importantly, this showcases the fact that we need to connect and manage many multi-cloud stacks, not just a couple. Okay, so now we've deployed some services. So how do we connect them together, right? These are some of the requirements that we had from our cloud connectivity. We needed a very quick networking solution that would form the backbone of our entire multi-cloud architecture. In particular, it should be resilient and fault tolerant and have automatic failover built into it. And the latency should be kept down since we don't want the multi-cloud platform to have higher SLAs than before. Okay, so I'm going to now give you a quick introduction to Cillium. This is a 101 session, so I'd like to make sure that everyone is on the same page. So Cillium is built on the Linux kernel technology called EBPF. And what it does is it deploys an agent alongside your nodes and your servers. And it provides all of the functionality that you see on this diagram, which I've taken from their documentation. So it'll provide network policies, services and load balancing and a whole bunch of metrics together with Hubble and Grafana. So why did we choose Cillium? Cillium provides network policies on levels three, four and seven. So it gives us a way to restrict egress from our multi-cloud platform. It is cloud agnostic, so it provides connectivity, service discovery and load balancing across the clouds, making it really easy for us to deploy it anywhere. And it has the inbuilt observability with Hubble, which was written for Cillium in particular. And we already used Prometheus and Grafana. So that was a great fit for our platform. So the way that we decided to do multi-cloud connectivity was to leverage the already existing connections that we had to our data centers. Our data centers had already highly available and tolerant connections to our cloud architecture. So we decided to use that instead. So we allocate sider ranges to our clouds and then the edge routers have very high level routing built into them. So they are able to send the traffic to the correct cloud. On the cloud side, we have gateways that can then forward the traffic to the correct service. And the cloud vendors provide native routing with their Kubernetes CNIs. And Cillium provides CNI chaining, so we're able to use Cillium together with the cloud vendor CNIs. We make sure that the addresses of our stacks don't overlap, but because we choose very wide sider ranges, then we have lots of room to grow. So this allows us to have a very low latency of connectivity between our clouds of only a couple of milliseconds. So Cillium also provides the ability to run the multi-cloud solution using cluster mesh, but that's not something that we've built in. You can read about the good folks that Cillium have done an excellent presentation about cluster mesh on their blog, which I encourage you to read or watch, and if you want to learn more about it. We might decide to mesh our multi-cloud solution in the future, but right now, it does not run in cluster mesh. Okay, so now we've deployed our services, we've connected them, and it's time to pass some information between them. So we had some requirements for our messaging system. First, it should support multi-cloud because the whole thing that we're talking about is actually deploying to multi-cloud. Then it should be persistent because again, we don't want to lose messages and we need to ensure that they get delivered. And it needs to have good Go client support because our platform is written in Go. So enter NATs, Jetstream. So I'm going to give you a quick introduction to what NATs is and then we will look into how we use it. So NATs, core NATs is very fast messaging technology and it provides very quick message delivery but it doesn't provide any persistence guarantees. On the other hand, NATs, Jetstream does provide exactly one's message delivery and it has inbuilt persistence and durability guarantees. So we are only using NATs, Jetstream. Messages are, messages, so in NATs, messages are organized into subjects and then the stream defines the retention of a given subject. Would NAT servers are then deployed and they expose endpoints and NAT clients can then go and connect to it and receive their messages either in push or pull mode. If you choose for pull mode, then NATs will deliver your messages as quickly as it can but if you decide to go for pull mode, then you can have on-demand message consumption and you are also able to patch them. So the reason we chose NATs, Jetstream, as you remember from our initial architecture, we did have some in-house experience with using NATs streaming but we decided to use NATs, Jetstream in the multi-cloud project because it has the push and pull clients that I was talking about and it also supports wildcard subscriptions which is another really cool feature. It's cloud agnostic, open-source and written in-goal so obviously the go client support was there and it provides horizontal scalability as well as exactly one's message guarantees. So it is a very fast, very fast, very scalable solution that we decided to leverage in our multi-cloud platform. So this is what it looks like. We have the data centers run in one cluster so remember that there's two data centers, not one with one in the cloud for replication and together they make one cluster and then the multi-cloud makes it another cluster. The two clouds together form a NAT super cluster. Inside a cluster, a servers use gossip to use a gossip protocol to actually send messages between each other and then when you connect to the two clusters together with leaf nodes, with the leaf node functionality which you can read more about later, then it allows us to pass through traffic between clusters and our NAT servers are deployed in Kubernetes because NAT also supports that natively. So this allows us to actually pass information between clouds very easily. So finally, we get to the database storage part and we can look at CockroachDB. We needed, we had some requirements for our database solution. It should of course support multi-cloud and if possible it should have SQL compatibility. As we were running our previous solution in Postgres, it would be great if we could still use those kind of the same kind of patterns as opposed to like rewriting a whole bunch of code as well as going to multi-cloud. It should easily run in Kubernetes and of course it should be scalable. So what is CockroachDB? So Cockroach is a distributed database and you can write and read from any node. It organizes data into ranges which Cockroach then rebalances and partitions accordingly. Each range is assigned a node that is the leaseholder and that node is in charge of coordinating reads and writes to a particular, to the particular partition. To the particular range, apologies. And it is a distributed database that is strongly consistent and is asset compliant. So why did we choose it? First, the Postgres SQL compatibility was huge. It was a huge plus for us because it allows us to switch our workloads and use the same kind of like data structures that we have from using Postgres. And it's cloud agnostic and is able to run in Kubernetes across vendors, which again is great for us. Strongly consistent because it requires a quorum to write data to ranges. So that was absolutely, that was great for us as well. Okay, so this is how our ranges are, we organize Cockroach in the multi-cloud. We, our data has a replication factor of three. So this is why what I'm representing with the different colored nodes. Each range is replicated across each cloud. Because we have very fast connectivity in between the clouds then this allows us to actually spread the ranges across clouds and then still have the strong consistency on each right. Yeah, and then furthermore, Cockroach have been great for the actual, so the Cockroach Postgres dialect has been a really seamless experience for our engineers to use in the application. So when it comes to CAP Theorem, Cockroach DB is technically a CP system because it requires a quorum to write. And, but we achieve availability with our multi-cloud setup and Cockroach is built in self-healing which rebalances nodes and catches them up once they've been disconnected. So if they've been disconnected then connect again. The good folks at Cockroach have done a nice series about the CAP Theorem and how it applies to Cockroach DB which you can of course look up as well. It's a really cool series. Okay, so this brings us to the end of the exploration of our platform. But we can leave you with three rules of thumb. So when it comes to, if you're thinking about going to multi-cloud then we recommend that you test your services end to end with a variety of load types. This has been absolutely crucial for us and we use Toxy Proxy to be able to test our services in a variety of connectivity scenarios. Expect errors in retries. In multi-cloud we have noticed that they are more prevalent so make sure you design your services with this in mind. And remember to go cloud agnostic first of all but also push as much work to specialize services as possible and rely on the public cloud vendor while avoiding lock-in. So you see the new, this is the new stack after multi-cloud. So we run our payment, our go payment services with the managed Kubernetes offering of each cloud vendor. We use NAT JetStream as our event bus which runs on multi-cloud and we use CockroachDB as our distributed SQL storage. We haven't changed anything on the other side on the data center side but we might, there is a project ongoing to replace NAT Streaming with NAT JetStream as that is being deprecated. So this is the end of my talk. Thank you so much for listening. Remember to check out our podcast and our engineering site as well as our Twitter account. We have so many, we're very proud to say that we have a lot of engineers from forum three at KubeCon. So do come to our stand in Pavilion One and we can chat more about multi-cloud and yeah, just like embrace the community feeling of this conference. Thank you. All right. All right, thanks for great presentation, Elena. So we got a few more minutes for the question. If you have any questions, I'm gonna pass the mic to on. So please don't hesitate, hand you up. And then, okay, so any question? Oh yeah, here we go. You said that the client can choose on which cloud he wants to run on. Is it also possible that one client, like he said, it doesn't matter and there are multiple clouds working for him or does he actually has to choose one? So I may have phrased. So the question was about how our clients choose where they connect to which cloud provider they connect. So our clients have high availability connections to all of our cloud providers so they can connect on any payment service and then they can choose exactly which one to connect to. They don't have to like only connect to one and then that's the one you've got. And then yeah, if there is an outage then they can go and connect to the other provider. Thank you. Any other questions? Oh yeah, sure. Thank you for a great talk. I wanna ask how do you handle private keys and key sharing and secrets across multiple clouds? Is that something you have solved as well? So that's an excellent question. The question is about how we secure connections in multi-cloud. So all of the connections in between the clouds are secure but I'm not a security expert. We'll be happy to tell you more about exactly how the client side security works if you come to our stand. Thank you. All right, any questions? We have a, by the way, the mic in the center so you can just step up and then ask any questions. All right, I think it's a really good presentation and you already explained a lot of stuff and then people already understand. Okay, thanks again. Thanks for a great presentation really now today and then thanks for attending this session and hope you enjoy the rest of the Q-Code. Thank you. Thank you very much everyone.


For 23 years the Bemidji High School Volcomotive Show Choir has been competing across the region as one of the state's top show choir programs. Josh Peterson tonight shows us how this year's show has the group derailed. With many rehearsals and long hours the Bemidji High School Volcomotive Show Choir has been busy putting finishing touches on this year's show. This year's routine takes the audience aboard a crazy train ride that ends up being derailed. It's about trying to get started in life and we use the symbolism of getting on a train and we end up on a crazy train of life. For seniors this year's show is unlike any other the show choir has performed in recent years. We think the show is really different. It's got a more like personal feel I think compared to other years I've been in. With expectations running high ahead of their first competition the message presented in this year's show is one of inspiration. Whenever you get down there's always light at the end of the tunnel. Everything's gonna be okay in the end. For the group the hope is that this year's performance will leave the judges with a story that they will remember. You could have the same show take the story away and it's not as good as the show so the story is definitely a huge huge aspect in the judging I believe. But when the show choir season comes to an end it's all the memories and friendships that were formed that will last a lifetime. I really enjoy the people in the community I like hanging out with all the people and I just think it's really fun activity to do. For some members this marks the final year of their show choir career making sure that every performance counts this season. This year I was selected to be a dance captain and so I'm so thankful for that opportunity and so I've been really giving that extra 150 percent to make sure that I can make the show as good as I can. With the team all on board this year's competitive season should be one crazy train ride. Inbemiji Josh Peterson, Lakeland News. The show choir program will host its annual dinner show on January 26th through the 28th. Tickets are available at the high school box office. If you enjoyed this segment of Lakeland News please consider making a tax-deductible contribution to Lakeland PBS.


I'm going to talk today about open event web app, but we have a word in front of it that is progressive open event web app. So you might be using open event web application throughout this conference. If you are using this, can you believe or a good question will be, can you tell me how much time it will take to design this website? Anyone, any random guesses? Six months, good. Anybody else want to take it up? Who thinks less than six months? Then, OK, everybody thinks less than six months. Then what time do you think? How much time it takes to design this web application? Three months. Less than three months. Who is going to have less than three months? OK, you two guys. What do you think? Two weeks. Oh, that is too much less, OK. How many of you think less than two weeks? OK, 10 days.  How many of you guys think less than 10 days? Anyone else who thinks less than 10 days? This application, less than 10 days. Nobody thinks, right? What do you think? 40 days. OK. If I give you some comment that this took two minutes to design this whole web application, would you like to design your web application for this event or not? So whenever you are organizing an event for a conference, for a meetup, you just want to use a generator, which we have designed in Google Son of Code 2016. And you have to put your data into it, and it will design a web application in two minutes for you. So you can host your event for free. You can give your custom domain into it and host it on your own domain. Or you can use our existing domain to host it. It's all about you. I have done this project in 2016 and then mentoring this project from two years. At this time, we are going to make it progressive. Progressive because after analyzing our users, we found out that this is going to be a crucial need to work this application offline in each of your mobile phones. So this is about me. So I'm a web developer in Fawcetia from past two years. I'm a product engineer in coding blocks that is a startup based in New Delhi, India. I teach students at weekends. I teach, obviously, coding to students. I was GSOC student in 2016 with Fawcetia and mentoring constantly with Fawcetia from past two years. Apart from that, I love to contribute to organizations like Cloud CV, which are having interest in AI and ML. And I am a contributor to NASA as well in an OpenMCT project. Let's take a glimpse of how this whole OpenEventWebApp works. And also, if you want to generate your application that can run in two minutes, that can give you the whole website in two minutes, how you are going to do that. Is the internet working? Wait. So let's see how OpenEventWebApp works. So you have given your API link and then you click hit. So this is the whole website for you in just two minutes. Now, if you give your link to it, the API endpoint, then it will generate a website for you. Now, the question is, how are you going to have this API endpoint? For that, we have a separate project.  Again, coming to the point, OpenEventWebApp was prepared in 2016. Then why we are going to make it progressive? We are going to make it progressive because we have analyzed it in conferences that there are issues in internet connections and people found it difficult to find schedules. So we thought if it is progressive, then everything will be offline sync. So you can watch the schedule on your phone, whether the internet is present with you or not. Obviously, we found it very challenging and we are still doing it. It has not yet completed. Today, I'm going to tell you what is left and what we are already done. So let's start with a PWA process flow. So what is a PWA? It's a progressive web application. It's just a simple web application which you make and then you add some with some tools, you add some code, extra code to it so that it can work like a native app on your mobile phones. Starting with process flow of this progressive web application, it starts with a cup of coffee when you have a cup of coffee in your hand and you are still thinking, what can I do? And the first thing you have to analyze is you have to analyze. So you have to analyze first what you are going to do. For analyzing, I'll be covering what you can do for analyzing. There are a variety of tools present in the internet. You can take one tool and analyze your existing web application. So here we are seeing you have a whole website ready with you. Now it's your time to make it a progressive web application. The first phase comes out to be analyzing your existing web application. The second point after analyzing is prioritizing. Now you know that this application is good. That much good for progressive web application. You have a lot of feedback when you want to change it to a progressive web application. You have to prioritize what you are going to do first and what you are going to do next. The third point comes out to be the tools. Which tools are you going to use to make it a progressive web application? The fourth point comes out to be the implementation. After you are ready with your tools, now is the phase where you can go and implement directly. And the next time, whenever you do it, you have to re-evaluate whatever you have done before. So talking about some small concepts which are related to PWA and which is better to understand first before you go to PWA is whenever you talk about PWA, the Progressive Web Application with someone, you always talk about these three major concepts. Or somebody will come out to you and tell, OK, my website is going to be a PWA. So he is talking about you these three main concepts always. The first one comes out to be Service Worker, which is a misconception among all developers that the Service Worker is the only thing which you can do for progressive web application. But this is not the end of the story. A Progressive Web Application contains all these things while the Service Worker is just 10% or 15% part out of it. We have push notifications feature. So in your native mobile Android app, if you are an Android developer, you must have seen notifications all around. But can you generate notifications for a web application? A web application that works on your browser but also works on your mobile and you are having push notification for it with the same code. With PWA, we can do that. And this is very easy. It is just a tool. You have to integrate and get your all work done. Add to home screen feature. A PWA consists of add to home screen feature. You have a mobile. And you have an icon right there. Just click that icon and it flashes up with an app, just like a native Android app. You have now an icon in your mobile that can open your web application. STTPS. Don't forget this. This is going to be very important. For security, it is already written in the whole documentation of Progressive Web Application that you cannot host your web application on STTPS. You need to go for STTPS. So even if you are testing it locally, you have to make it sure that it is STTPS. How many of you believe in performance of a web application? Nice. Why don't you believe in the performance? Why don't you believe? I'm just going to put my hand up. OK. So performance is the crucial factor whenever you talk about a web application. Whenever you test a web application, you come out with some statistics saying, OK, this is 15% good. It is 30% good. And then you iterate, iterate, iterate to increase its performance. When you talk about specifically for progressive web application, your performance factor is the most important factor. And that's why I have took that in the front. So whenever you talk about this performance factor, your progressive web application grows exponentially better. So this is performance. These are the four concepts. And then comes out to be two more important concepts. One is the user experience. And the second one is the measuring your progressive web applications. User experience, the most important stuff, whenever you are doing anything on mobile, it should be responsive. There should not be any junk in the code. It should be very fast on the first load. Lot of things you have to talk about when you are talking about user experience. User experience starts from making a thing responsive when you are making a website, but when you talk about specifically for progressive web application, instead of just thinking about responsiveness, you have to think in deep with the performance whenever your page is loading. So you have to make sure that your first load should be very fast. It should be very fast so that users should not wait for more than 30 seconds for the first load. And 30 seconds is a crucial time for me, at least, on the mobile. And it is obviously because you cannot load each and everything in a shortest span. So you have to take something as a priority to load at the first instance and then take the other things for the second instance. And that's how you take everything step by step, step by step, and give a better experience to your user. Measuring the application time to time is always very important. If you are making stuff but not measuring it at time to time, you don't know what needs to be improved. So measuring a web application is going to be very important for you. We come to our second part. After grabbing up coffee, after just analyzing, now we learn how to analyze. The best tool to analyze, the Lighthouse. So Lighthouse is the most important tool right now for all the developers to analyze their web applications. This is very simple. That's why it is very easy to integrate your web application into it and then get the whole report what is bad and what is good inside your web application. In Chrome latest versions, if you have seen the audits tab in the inspect integrated in it, just need to go to audits, run a Lighthouse script on your website, and you get the whole report of the Lighthouse in front of it, in front of you. So what else, apart from Lighthouse? So apart from Lighthouse, there are other tools that are present on internet, starting from web page test, page speed insights, Chrome DevTools. Chrome DevTools helps you for the speed of your website and also counting the number of HTTP requests. But the profiling it gives is something that is not that much understandable in comparison to Lighthouse. The Lighthouse is for the developers who are not much into the depth and front end development, but they want to know what is good and what is bad in their websites. Web page test helps you in caching and to analyze your time of your first load. So I'll suggest before you are going to change your existing website into your web application, into your progressive web application, go through all these tools, generate a report for yourself, take a PDF out of it, share with others to just get the insights from them, what is better, what needs to be improved, and then start taking your web application into a progressive web app. If you think that you have a slow Wi-Fi or internet issues, then comes out to be the use of service workers. A service worker is just a background script. It works at background and helps you to cache your data. If you are making a lot of HTTP requests which you don't want to make, actually, you can directly write a service worker script and that will cache your HTTP request data. And next time, you are not going to make HTTP requests if the data is already present with you. That's how you save a lot of load whenever you make a progressive web application to work offline. Next time, if the data is not present and if you don't have an internet connection, the data is already cached. So you can directly, with the use of service workers, you can directly take that data and have it displayed on your app. Using Lighthouse, we analyze the open event web app which we have worked on in 2016. So in the last year and this year, we have analyzed our open event web app to check what is left and what we need to improve. So we started with a performance matrix where we started with a matrix of Lighthouse right now and then we take a snapshot of all the details that Lighthouse tools gives to us. So if you are running your website through the Lighthouse tool, you'll get the whole report like that where you can judge your performance, your progressive web app capability for your existing website, your accessibility, your best practices, and your SEO improvements. This is not that much detail, but if you see the actual Lighthouse tool, this report is off two to three pages where it tells you each and every line specifically where you need to improve and where not. It directly tells you, OK, this is going to be a progressive web app if you fulfill these five or 10 requirements. And then you go through each and every requirement, complete that, and again test and analyze if that fits up for your progressive web application or not. So here you can see the time to load and it comes out that the time to load, the first load was at 4.7 seconds instead of the 941 milliseconds. These are the snapshots of the website whenever you run it through the Lighthouse tool. The second point after analyzing comes out to be prioritize. How you are going to prioritize things? The prioritize things happens in this order for us when we have analyzed our website, the OpenEvent web app, and started to take it to progressive web application. It's starting with optimizing images, which includes compression and lazy loading of images because if you have seen the OpenEvent web application, it contains a lot of speaker images. So you can't load all of them in one go. If you load, it will increase your first load time. So you need to apply lazy loading for that. Compression is also going to important. So whenever you are coming to our platform and adding that endpoint, we compress your image automatically so you don't need to worry about that. Writing known blocking code. This is going to be important because if you have worked with CSS or JS, you should know that what is render blocking code. I'm going to talk about how you can change your render blocking code to non-blocking code right now after this slide. Removing extra code. This is going to be very important because you have seen the spaghetti code all around. You have seen the spaghetti code all around. And then you just have to take that code and remove the extra code and make your web app more faster. So this is the tool I want to work. I have worked on and I want you to apply the same that is SW Workbox. You don't need to worry about progressive web application. You just need to take this tool and then have to take the boilerplate this tool gives to you. This is going to be the non-blocking code. And if you see the third one where you have specified the minimum width of 40 AM. So you specify the width of each and every CSS file in the media query. You say, OK, load this file when the minimum width of the page is going to be 40 AM. And that's how you make it non-blocking.   So this was the chart when we analyzed it. And that's how we improved till now. The next part comes out to be the evaluate. Once you are done with all of these steps, you have to evaluate your application again. So we evaluated it with the current web progress. And right now, from there to here, we reached out to be 45 at the Progressive Web App Score. We still need to improve. And we are still looking for developers to contribute to FOSS Asia Open Event Web App Project, where they can come in and help us to make this Progressive Web App for 100% in Lighthouse tool. But still, you need to iterate again and again. Even if you have done all of this work, you have to check again what else is left with the Lighthouse tool, and then have to prioritize and analyze again to do everything. The solve from my side, if you have any questions, you can ask. Get, OK. If you have come across the tools, which I have told right now. So the Lighthouse, whenever you run the whole website to the Lighthouse, you get the whole report, where you get some pointers, how you are going to increase your accessibility, where you get, OK, you have to add area level into it. You have to do three things like that. You have to approach in this direction. This is the Lighthouse that is helping you to cover all those points. Yeah. How long do you think it will take you to finish the Progressive Web? I think this is going to be a bit challenging for us. So we are looking for developers for this Google Summer of Code proposals. So we are expecting someone to come up the specific solution in Progressive Web Application Direction, if they can help us in that. So we are expecting one year. The next conference will be with the Progressive Web application, not yet. So it is still in process in Lighthouse. Yeah. It's a pretty great app. Like, I think I'll use it in Australia next summer. Sure, sure. Just let me know. And it's Django title, so.


Liver cirrhosis is characterized by extensive fibrosis of the liver, and understanding the underpinning immunological processes is important in designing intervention. Here authors show that mucosal-associated invariant T cells are instrumental to controlling the balance between profibrogenic and restorative macrophages and inhibiting their activation might reverse liver fibrosis. This article was authored by Morgan Mobiah, Pushpa Hegde, Adele Hamatine, and others.