And we're here at the Lunaro Connect and this is the world's first ARM developer box. Now, it's third. It was third. The third. Or maybe the fourth. I heard something. I heard the fourth as well, yes. Somebody said that it was a Seattle base, right? No, no, not the Seattle, but there was a PC after the RISC PC, yes. So, how are you? I'm Daniel Thompson. I work at Lunaro in the support and solutions engineering team. And it's been my privilege to be playing around with the developer box. So I've had one of these on my desk. I've had it for six months. I've been using it as my day-to-day computer for the last four months. This has been your main desktop machine? Yes. Unless I'm in a coffee shop, I've done every bit of work I do for Lunaro on this board for the last month. When you're home? Yeah, okay. Obviously, it doesn't work well in a coffee shop. Is it not yet the laptop? No. But it could be, you're waiting for a laptop? It would be quite a pokey laptop. Let's get a laptop soon. You want a laptop that's ARM powered? I would love a laptop that's ARM powered. I mean, I like this one a lot because it can take a lot of RAM. So I run mine with 8GB, but you can put up to 64GB of RAM into this box. And for me, I don't want a device with less than 8GB regularly. Why? Why do you need with 8GB? I find that you see swapping if you run 4GB and you have Chromium open, and I also run other applications. Chromium at home will survive, but you open the next application and you tend to see swapping. Swapping, that means it goes into the main memory inside the RAM? It's the process where when you start to run out of memory, it puts memory on the disk instead. And even with modern fast SSDs, the delays of getting stuff on the SSD and back again are enough to make it feel lumpy. And I don't want to work on something that feels lumpy. So you say you're in the what support group? The support and solutions engineering. So what does that do? We look at a whole bunch of things. The short version is we help members exploit their membership with Lunaro. So the core engineering teams will enable pieces of hardware occasionally, but they want to enable technology. And our members want to sell chips. What's that? The club and core members want to sell chips. And so you need to help bridge the technology and help the members exploit the technology that Lunaro has created. So how awesome to have an ARM developer box compared to have an Intel thing. Yes. How does that change? Surprisingly little. I've run it for four months and you don't get up in the morning and think, oh, I wish I had this this program or this program. Everything has, what I say everything, but it's a few tiny, you know, two tiny problems. Almost everything has just worked. And it's always been, you know, quite obscure developer centric tools that haven't quite been made to work yet. What's the most important thing you do? Usually you open a terminal and you start typing stuff or what do you do? I have some managerial responsibilities. So the most important program I open is a mail reader. A mail reader. And that's actually true for job-earning engineers as well. I mean engineering is now a social discipline. So open source is a social process. So for every developer, I think mail is probably their most important tool. But email is maybe not very multi-threaded, right? You need a single thread performance to run an email program? It depends which programs you run, of course. Yes, so the one I liked or the one I was using before I went to the Swiss Thunderbird and that didn't feel very snappy. That's a single-threaded app. I don't know how threaded it is, but it certainly wasn't very snappy. And so that's the only change I made to my set of applications. All my other applications that I've used, you know, Chromium, things like that, they've all come across fine. But Thunderbird just didn't work for me. I switched to MUT, which I used years ago. Is that a good one? I don't know if I've been installed on this device, but it's a terminal one. Terminal-based email? Yes, security people are very fond of it, because it's harder to attack. It's got a smaller attack surface than a GUI browser. So we're in a terminal right now? Yeah, I should imagine it's not installed. Cool stuff. Well, it is merely a terminal. It will do the same thing as every other terminal on every other Linux machine. That's the point. We want it to be like using any other device. We don't want surprises when you look at the terminal. So what would you do, for example? The nice things you can see is H-Top. So H-Top has this nice representation of the number of processors running. So when you can see here sitting up, they're not really doing a great job. I hope opening Chromium is usually a good way to get six or eight of the cores running. Have we gotten Chromium? Internet? Oh, we haven't, no. This hasn't got Chromium installed yet. So you need to do an app get or something? Yes. If that works, I'd be rather... The Internet is pretty fast here. It's nice in Hong Kong, right? How's it in your home? It's not making it through, so I think it's not good it plugged into the net. Okay, but how's your Internet at home? How's my Internet at home? It's modern broadband. I live in a city, so I get good broadband, yeah. So you can do anything you want to get stuff downloaded? So we had some cool tricks on it. So we got Minecraft running on one of these. Because it's written in Java. And because it's written in Java, we had to change a couple of shared libraries, but it just ran Minecraft and it worked. It was fine. My summer's very happy. Is the stuff about using an ARM developer box the most important that you can compile on native architecture? Yes, so the very best thing for me is when I need to spin up a virtual machine to test something on. I just type QMU and then I say, use the kernel that's in slash boot slash vmlinus. So I didn't even have to remember where I left the kernel because the kernel that booted the box is also the same kernel that runs the virtual machine. And that just makes it, it just reduces the amount of remembering things you have to do to start a QMU session. But is it also better for like testing ARM on ARM? Yeah, I mean that's very much yeah. So by spinning up that virtual machine that is all about testing ARM on ARM. It's allowing me to make kernel changes and spin up a kernel and see what happens if it works. I also did a bunch of stuff with containers similarly. Being able to create native ARM containers to test if you've done it right, if you've generated your root of S correctly, all these types of things I can now do without having to spin up a developer board, a small, singable computer. I can do it all on the one platform so much more easily. If you were doing that on an Intel, would there be some issues that you wouldn't notice because it's not native? Well, the first thing is, even with the relatively slow single-formance of this device, it's still far better at being an ARM than a PCS, right? So if you get the PC to pretend to be an ARM, it will never be as fast and you will never expose the memory ordering. So PCs are perhaps over-aggressive in memory ordering. They've got really strong constraints on how the multiple processors can interleave when they work in memory. And ARM has what's called a much more relaxed model. And that relaxed model has benefits and it also has some testing needs. So for all the interior engineers, all people working on ARM software, it would be better to use an ARM device to develop ARM. I'm not going to preach to other people they should do, but yeah, for me it's a great way to do ARM development. And the only thing that might be missing is just single thread, right? So this device is a kind of performance per watt design. So it's designed to offer a quite incredible performance per watt. And when this machine is red-lined, it only uses about five watts more than it does when it's idle because the CPU only ever draws five watts. So yeah, for sure. So it's a performance per watt machine. It's very wide and when you can exploit that width, everything's fine. But when you can't get all of those CPUs lit up, then you do sometimes see slowdowns in particular single-threaded activity. And here they're doing a demo. Let's just check this one out first. This is the box that people get when they order it. Yes. So there's like the desktop here. And what is in here? Actually, it comes as a kit. So the kit contains the motherboard and graphics card and memory and a disk. And then you assemble that yourself into a case. And there's a really nice assembly guide for people to follow. Anyone can order. Anyone can order. Anyone needs to own a screwdriver. And the price is good. The price I'm not quite sure of at the moment. The price is like, is it $1,000 or? $1,250 for the whole like this. For the kit, yeah. Shipped all of the world. All of the world. So it has CE, FCC and all that, I guess. So it just comes smoothly through the... And this is an AI demo right here. Can we check it out? This is an example of what happens when you have multiple PCI slots. So this device has a lot of PCI capability. So it has a graphics card in it. It also has... You've talked to one person some extent, but it has a really powerful AI accelerator that made a big splash at CES. What AI accelerator is that? I don't know. It's written on the wall. It's a neural processor. So it's there to help do all the matrix multiplications. So that's on the SoC, the AI accelerator? No, no, it's attached to the PCIe. Ah, it's a PCIe. Read. So it's simply an example of what happens when you have PCIe slots that have lots of them. So actually if you need some of those singles, could you add that on PCIe somehow? Could you add another big armchair? In principle, yes, but somebody would have to make such a board. And you might have some challenges with the memory benefit, not memory benefit, making sure they can access memory efficiently. So this is going to launch up a pattern recognizer, which is a train neural network to try and classify images. So it's now playing videos, and it's able to recognize each of these images and classify it for what's contained in the image at an impressive speed and at an even more impressive power cost. So that was reading 32. 32 is kind of the overhead of power supply and refreshing the RAM and all the other things you have on your board. And on a PC, a conventional PC, which you do that if you start to use those cores that the PC has, you'll see the power level triple quite often, whereas this has gone up by three watts. Three watts to do all this stuff? So it's like a 22.4... Terra-flops, I believe. No, not flops. Terra-operations. They're not flops. Terra-operations per second. Powerful CNN. Is that to do with TV channel? No, something else. It's a type of neural network. So I come with what the C stands for, but the N and the N are neural network. 200 frames per second system. Just a three-watt increase in the AI. So that's just another A accelerator. That's actually a Socialnext chipset. It's not. Socialnext partnered with what they call Greifonkin. All right. Partnered with the... Yeah. Somewhere. Yeah, so it's on an M2. The actual accelerator is on an M2 format, which allows, in theory, you could drop it into other devices. But that means it's ready to go into small-scale embedded systems because M2 is nice and compact. But in this case, it's been attached to an adapter card and placed in the PCI slots. And that's the PCIe you can... Usually, in yours, you put an NVIDIA? Yes, I run NVIDIA GT10. GT10 is quite elderly, and the reason we picked it was the least power. So it is... It's actually one of the highest power-consuming components in the box is the graphics card. Which, you know, would be nice to find... If we could find a lower-powered PCIe graphics card, then the numbers for the base idle at 32 would go down quite substantially. There's just one PCIe slot, right? No, no, there's three PCIe slots. There's three. So you can have a GPU, an AI accelerator, and what else? Well, sound card. I'm an audio guy, historically. I used to do GSP, so plugging in a sound card is a nice thing to do. And you can get a very high-spec sound card to slot in PCIe slots. At home, I've got HDMI running out, and then audio comes out the side of my monitor. And there's all kinds of other things, potentially, there could be more memory. Fast memory, fast networking, fast all kinds of things in PCIe. It's got a good bit of ethernet. It's got a fairly performant RAM. Like I say, you can put quite a lot in it. It goes up to 64 gigs. And how many other linear engineers have been able to use it constantly for four months? Are you like the record holder? Or do you have some other guys, too? I think I'm the only one doing arm-on-arm on developer box at the moment. There's a couple of people in the server groups who are doing arm-on-arm on more expensive boxes. Like they have the big server chips, maybe? Yeah. Or in some cases, some harder-to-find boxes that they don't make anymore. Do you have to have one of those? In my garage, but not in my study. The other thing about these things is they're pretty much silent. They're passively cooled. The graphics card is passively cooled. There's not a fan. It's passively cooled. You have no noise. And that's quite special. And how about your electricity bill has gone up a little bit? My electricity bill hasn't gone up. I can't really measure the effect of this on my electricity bill. There are many, many people in my family. A few cents, right?  Well, it will have been using less power than what I was using before. So I would have saved something, but I couldn't tell you what.


Welcome to All Hands Update. I'm Petty Officer Tyrell Morris. These are your headlines from around the fleet. The Center for Personal and Professional Development, or CPPD, released the 2015 edition of the Naval Leader Planning Guide, November 21. This year's guide includes a 15-month calendar, a complete list of CPPD courses and services, and contact information for all CPPD learning sites. Sellers can download the PDF version of the guide from Navy Knowledge Online under the Leadership tab. The President has nominated Vice Admiral Scott Swift to receive his fourth star and assume the position of U.S. Pacific Fleet Commander, or PAC Fleet. PAC Fleet oversees ships from California, Washington, the Western Pacific, and Indian Ocean. Swift is currently serving as Director Navy Staff for the Office of the Chief of Naval Operations.


Oh, hey guys, I didn't see you there. I was just about to play the game of the summer. You know, it's not the new Diablo game. It's not League of Dota. It's not Roblox. It's called Fed Nudge 2023. Basically in this game, you operate, you know, in Persona Christie.  It's an awesome game.  In that case, you have to push the arky and get a new level. But basically, this game is just incredible and I'm so proud. It took me two days to code this up. So yeah, and it was done, you know, without any libraries. I think the entire code is like, yeah, it's five, five kilobytes, it's actually less when you assemble it all into binary. So yeah, it's not too big. And yeah, we'll talk about how that works in this video because today's topic is, let me get my window up, is basically reading and parsing files as well as processing key presses, basically just getting input from the user. How would you do that? And as far as I can tell, there's four different forms of user input. You have, we just talked about key presses, that's like what you'd have for games or for navigating. If you have the arrow keys to control, if you have WASD to control, you may have experienced that, A, in video games, but also maybe in some installers, maybe when you installed, you know, your OS or Linux or whatever, maybe you had to navigate around something and pick certain things, select certain things. That would have all been handling key presses. Then you have input files. This is how most scientific computing software works. Basically you have your data in a file and your program reads from that file, does some kind of computation based on the data, and then puts some kind of output, possibly also in a file. So pretty much just data, IO, and that's pretty much how real software works. Back when computers were used for actually computing things. And then also you have standard input, both typed and piped input there from the user. Again, you maybe had experienced this kind of stuff from installers and utilities.  I am Brian or something, right? You have to put your name in or maybe your host name when you start your computer up. I don't know. These kind of things would be from standard input. That's all boomer stuff. And then also piped input. This is actually somewhat useful. Thank you, boomers, because a lot of the utilities that are on Unix kind of deal with piped input. You can pipe strings into different commands and do things. So just have some uses there as well. But there's a lot of diversity as far as user input goes, but thankfully one tiny function is all you need to handle all four of them. Little caveat there, but pretty much just this one functional load is all you need to handle all those four different types of input. And that's just our wrapper for the read syscall. So pretty much this function, we wrote it a few videos ago, basically called read characters. You pass into register RDI, the file descriptor that you're trying to read from. That can be an actual file that you've opened. Maybe you have a high score file like in our game that we're opening and reading the value inside. Or it could be a standard input file. So I think on Linux and on BSD that's a zero, it's the hard-coded zero value. That's also an input file, but it's opened by default when your program starts. So the kernel opens that file descriptor for you automatically. So that's what would be an RDI. In RSI would be the memory to which you want to copy bytes to some buffer. You have some buffer of maybe four, eight, 16, a thousand bytes that you want to copy data into. And then RDX is how many bytes you want to read from the file. So it's pretty straightforward. This call, this is just a wrapper. All it does is it sets the read syscall ID number into RX and then calls syscall. It's pretty much a waste of a function, but it does make things a little bit easier when you're programming. So yeah, this tiny function is pretty much all we need to handle all four of these different types of user input. So the question is now, what's the algorithm if you can even call it that? It's a very simple algorithm. So if you have an input file, let's say you're a teacher. Let's say you want to, let's say you have all your students test scores in a file and you want to calculate the average, the standard deviation, you want to calculate percentiles or whatever, you would open that text file and you'd save that file descriptor, be it five, be it six, it's some number. You'd save that number in a register, maybe in memory. And then you would just read from that number. Read from that file descriptor, that file, some number of bytes into a buffer. Then you parse it in some way, you do your math, and you'd be done. It's a very similar story with reading from standard input because it's the same thing. The only difference is it's actually easier because you'd have to open a file. The file descriptor input is already open, open by default. So you just select standard input as the file that you want to read from, read some number of bytes from it, and profit, very simple. That works for both typed and for piped input. So that handles this, this, and this. How about key presses? Now for key presses, it's a lot harder and that's because you have to handle, well you have to basically use what's called raw mode, and I'll tell you what that is in the next slide. But basically, the story is that when you're handling key presses like the arrow keys, or like enter or backspace, one thing you don't want them to appear on the screen.  You want to turn off echoing. And then you also want to make sure that key presses are handled as they are made. Normally when you're in the terminal, you can type stuff.   And so you have a lot of ability to edit lines before you hit enter. And so you don't want that when you're handling key presses in a game. You don't want to be able to edit your inputs. Obviously, you want to handle each input at a time. You want to handle the arrow keys. You want to handle the shoot button or whatever you have as it's pressed. So for that, you have to use raw mode. And besides that, it's the same story. All you do is you put the terminal in raw mode, then you pick standard input as your file descriptor, and then you keep reading from that input file. However many bytes, I picked four. I think that's the safe number to pick because each key press can be, I think, up to four bytes in how long that code is, and then you just process the keys. So you keep checking. Did the user push Q? Did the user push space? Did the user push the shoot button? User push, escape, whatever. Let's say Q and escape quit. You keep checking for Q and escape every time a key is pressed. And then maybe Q means leave, so you just quit. But when you quit, you have to remember one thing, and that's you have to revert the terminal back to the way it was before you put it into raw mode. The reason why is because if you don't, your computer won't, you won't be able to see what you're typing. And that's a big problem. It happened to me plenty of times when I was debugging this code, basically your code will crash, and then you won't be able to see what's going on. You'll have to figure out how to fix it without being able to see, which is a little bit of a problem, in my opinion. So yeah. Now what is raw mode? That's a very good question, Gerr. So I guess there are like a lot of different combinations of flags for the terminal, but basically the two kind of categories are cooked mode and raw mode. And actually these have almost like a preset configuration on both Linux and BSD. I'll get into what that is in the next slide. But basically cooked mode is what you're used to on the terminal. You can edit lines before submitting. As raw mode, I said every keystroke sends a unique byte string to standard input. So let's say Gerr is typing hello, but he typed it wrong. He typed helco, H-E-L-K-O, then he hit backspace twice, backspace, backspace. He fixed the L-O, then hit enter. That would send this string of bytes into standard input in cooked mode, but it would send these bytes one at a time as the keys are pressed into the standard input if you were in raw mode. So the H you can see would send a 104, E would send 101, L would send 108, K-107, backspace would send 8 and 8 twice. So yeah, you get every single key one at a time and you just be checking. Let's say you wanted to check if the user pushed H. Maybe a help menu would pop up. You just keep checking for 104, 104, 104, 104. Did the user push 104? If yes, go to the help menu. So yeah, pretty straightforward difference there between cooked mode and raw mode. Now, how do you get into and out of raw mode? This is, it looks complicated, but I'll tell you it's, I mean it kind of is, but you only have to do it once. And honestly, I already wrapped this into the toggle raw mode file. So all this is handled and you could toggle into and out of raw mode at a whim just by calling a single function. So all this is built into there if you don't care about watching this next explanation. Basically the way this works is it's a little bit complicated. So you have to read the terminal configuration before you start. So that's what I'm calling termios, I think that stands for terminal IO status, just a guess I have no idea, but basically you can use the IO control syscall. Now what is that syscall? Let me check because I actually don't know the official words here. Check the manual IO control, IO control system call manipulates the underlying device parameters of special files. So basically that includes standard input and what we're going to do is let me go back. Make sure you can see we're going to pick the standard input special file and we're going to use this get attributes, this is mean terminal configuration get attributes, I have no idea. Basically we're going to just save the initial terminal configuration for standard input and we're going to save it into the address old. I think from my experimentation, it's around 48 bytes. If it's more, I'll change it in the code, but as far as I can tell it's just 48 bytes. So we have some memory locations here. We have one called old, that's just 48 bytes initialized to zero but it's just 48 bytes of space. We have a similar address called new of 48 bytes and then we have a buffer I'll get into that in a second. But basically, we're going to read the initial terminal configuration, it's going to be a series of flags zeros and ones 48 bytes worth of zeros and ones into the memory location called old. Again, we're going to copy that we're going to repeat that process for new address. So that's going to be we're going to have two copies of the current terminal configuration. One will be in the address called old one in the address called new. And then we're going to tweak the new one just a little bit. We're going to tweak some of these flags and you can find these flags if you open up the term Ios manual, you can see what some of them mean. This is like the interrupts for break and carriage returns versus new lines. How should they be considered echoing onto the screen, new lines, all this kind of stuff. Just look up if you're curious what they mean, you can look them up in the manual they're all described. And basically this entire five lines of code is pretty much exactly what's being done by CF make draw that's a built in function on both Linux and BSD. And we just kind of copied that and put it put it here in our assembly code. And basically we're just tweaking some of those flags in the 48 bytes that we're calling new. So we've we've saved the old configuration into both old and new. And now we've just tweaked some of the flags in new. And then you can see we just set the terminal configuration to the new values. So in this case, we don't use TC get attributes, we use TC set attributes. And all these values I've I've hard coded them into the operating system dependent include that will automatically be grabbed whenever you compile this on your computer. If you're on Linux, it will pick the right values. All of these are different on Linux and BST. So it will work on Linux or work on BST just out of the box. So yeah, so basically we copied the terminal configuration into old and to new. We tweaked the new one. And then we set the terminal to the new one straight forward. Now once you've said it to that, you have to parse the input. And so in this case, I'm showing you how that works. We're just reading a double word. So four bytes worth of information, actually, we're we're clearing it out here. So we're clearing the rebuffer to zero rebuffers four bytes worth. Then we're just reading four bytes into the buffer. And again, that's because some of these key codes, I'm pretty sure are up to four bytes in length. And then that's what this lines do here is read four bytes. So you know, let's say you push the Q key. It would be your rebuffer would have a 113 in the first byte and then you'd have three zeros. So you just got to read and check, hey, did the user push Q, did the user push enter or what did the user push and just have a comparison for all these possibilities. And then jump to a certain, you know, address where you handle that possibility. In this case, I say, if the byte that you read from the rebuffer is a Q, then jump to done. And what does done done leads the done leads, I should say done leaves the program. Or it leaves this loop. Otherwise this loop goes forever. You can see it jumps to itself over and over again. If you don't push Q or enter, I guess. And then done, you're done. One thing you have to do and done is you have to make sure to restore the old terminal configuration. And that's why we saved it in the first place is because you have to put it back. Otherwise, you're going to be like Lee Sin here trying to figure out what's wrong with your computer because you will see anything because echoing will be off and you're going to have a hard time. So yeah, make sure you do this at the end and you should be good to go. Now let's check out the code. So I've got four different examples here. I have some very basic ones. This is extremely basic. This is extremely basic. And then these two kind of, you know, deal with key presses. So they're a little bit more advanced, but they should be pretty straightforward. Now that I've explained the underlying process. So yeah, let's go to that right now. So the four examples are in this example, six directory in the suppository. You can check them out. Let's go to the first one. And let's look at the, actually, let's just execute the code first. So compile and run. So what is my name? My name is Matthew. How old am I? I'm currently 28. And you can see it is a couple of things. Obviously it parsed the input. It says I hope you make it to 29, Matthew. So obviously it saved my name and then it also saved my age, but then it converted my age into a number and added one and then printed a string out at the end. So how would you do this? Maybe think about it for a minute. How would you implement this? And I'm just going to show you what I did for this. So in this case, I have a couple of included functions. We have print characters to print out, you know, characters to the screen. Also we have print int to print out the number my age to the screen. And we also have some other functions. We have strlen, that obviously computes length of a string, very simple. And then we have parse int. That's a function that computes the integer value of a string. So you pass in 28. It gives you the number, quantity 28, because remember when you type in numbers, they're not numbers. Well, I guess they are numbers, but they're not the numbers you want them to be. They're ASCII values. 28 is, you know, two ASCII characters with certain numbers. It's not 28. You have to parse that and do that in some way. So this function handles, I believe it handles hexadecimal and octal and binary as well. So it does all that kind of computations all built in. So it's pretty cool. I'm not going to go into it in this video. It's all in the subository. Then we have recharacters, which I've already explained is just reading characters from a file descriptor into a buffer. So very simple. Here you can see what's going on. It asks my name. This is just prints out the question about my name. Flushes the buffer. So it prints to the screen. Then it reads 32 bytes from standard input into a buffer called name buffer. Then it asks my age again, flushes the screen so you can see the question. If you didn't have this line here, if you commented this out, it wouldn't be visible necessarily. So we have to flush the print buffer. And then you can see it just does some computations. It prints out, I hope you make it two. Then it computes the length of the string in your age. Then it parses the number in your age. It increases that by one, and it prints that number to the screen. So in my case, I typed in 28. It basically figured out what number is those two ASCII bytes. Then it incremented it by one and printed it out. Then it prints out a comma. Then it prints out my name. My name is Matthew. So it printed that out, and then it flushed, and then it left. So very simple program and very simple operating principle. So the next thing I wanted to show you was, let's go to example D. That's also just the same thing, just piped. So in this case, this function just turns things to capitals. So you can basically... So let me compile it first. Okay. So let's compile. I have a binary now. So I can run binary, and I could type things in, and you can see it capitalizes them. Or I can actually pipe in that value. So if I... Let me... If I echo... I hate... Oh, that's the two lowercase here.  You can see it capitalized. Also get rid of the spaces. I'll talk about that maybe in a bit later. But next, you can also pipe it in a different way. So let's say you run binary and you pass the value in this way. I can pass the string in this way, and it will capitalize that as well. So you can look at the code if you want. I'm running out of time, so I won't get into the code on this one. But it's a very straightforward operating principle. Again, this is just piped values in standard input. So now let's go into the example B. This is not the game. This is just key presses. In this case, I've handled... This is basically doing what I showed you before, is processing key presses. And I've processed a few, and I have different strings printed out. So let's say you push the arrow keys. It knows what the arrow keys are. If you push the space key, it knows space. I think it knows the enter key. It knows... It knows J. I think it knows capital V. I didn't do everything, but I did the whole bunch. And then I think both Q and escape leave the program. So I'll go into that right now. So how does that work? This should all look familiar to you, because it's just what I explained before. In this case, I only have four included functions, actually just really three, besides exit. I have print characters, print int. Do I even use that? Do I even use print int d? I don't. Okay. Let's get rid of that. It must have been for debugging. Okay. We don't even use that. So in this case, we're just basically using read characters and print characters. So we're just manipulating stuff in memory and reading it and printing it out. So here you can see I've saved the old terminal configuration. I've saved it again, the new. I've tweaked the new one a little bit. I've set the terminal to the new configuration. I have that loop I described. Here you can see I'm reading in those four bytes. I have the up arrow handled down arrow, right arrow, left arrow, J, capital V, enter space, et cetera. And then I have two characters here for quitting. I think both escape. I think this is escape and this one is Q. And then I have just different things to jump to in those cases. So if the up arrow is pushed, I print out a certain string, same as all the other buttons, right? So it's very straightforward. And then when you're done, let's say you pushed Q or you pushed escape, it would jump to done and then it would reset the terminal back to what it was before the program was run. So very straightforward process there. Now the game, this is going to be pretty complicated, but I think it's going to be fun. So let's go to the example C. Let's look at the code. This is long. This is a very long code. I won't get into the nitty-gritty. I'm just going to explain the overall process. I think it's interesting how this is an actual bit of software now. This is an actual program that somebody could distribute, not a very good game, but it's a game nonetheless. So I've got a bunch of includes, nothing you haven't seen before, except for these two, I think, and see move cursor. I didn't explain in previous video, basically, there's an ANSI escape code to position the cursor on the screen. So we don't have to keep printing out spaces to put our character on the screen. We can actually move the cursor to a certain location and draw our character there. Similarly, we can draw the whole and we can draw the CIA agent, you know, in different spots just by moving the cursor around to where it is. So that's how that works. And then I have this random integer function. We'll cover that in either the next or the second next video, how randomness works. I had to do something with randomness because otherwise the games are very boring if they're not random. But anyway, we'll talk about that in a later video. Besides that, it's pretty much the same thing. So you can see the first thing I do here is I'm reading from the high score file. I have a file that we're saving the high score to. And so I'm just reading from it. I'm opening the file. I'm reading from it into a buffer. I'm checking if the file even exists in the first place, etc., etc. Then we get to the part where we are printing out the main menu. So when you open the program, there's a menu that appears that says Fed Nodes 2023. And so first thing I do is I put it in raw mode. You can see here I have that function called toggle raw mode. And here you can see I'm going into raw mode. Now that when I type, the letters won't appear on the screen one by one. They will be processed as you push them.  So I have a couple of different things here. Basically we're going to print out, where is it? I have a whole big, yeah, here you can see I have a whole big thing for Fed Nodes 2023, just a bunch of memory being allocated to spaces. They probably could make this smaller if you really wanted to. Actually I know you could. You can save some space, but I'm not really concerned about the file size. It's only 5K, so not a big deal. And these things here, the slash E, that means escape, and this basically means color. I think this is red. This might be yellow or green, and this one I think is orange. Either way, just changes the colors of different things on the screen. So yeah, basically all this stuff is just to handle that cursor. When you play the game there's a cursor there, and this position is that up and down. Let me actually show you. See that cursor is orange. I can move it up and down. I can go up, and then overflow to the bottom. I can move down, overflow is down. So it handles that, and then you can hit enter. I think space also works on any of these options, and something else happens when you do so. So if I quit, it quits. If I clear the record, it goes to zero. That does two things. It also, first it sets this value here to zero. Also in the code there's a register that encodes the current high score. And then it also writes that file to the high score. So if I show you the high score file, you can see it's zero right now, because we just cleared it. So when I go back into the code, you can enter the function, into the game. Now it says zero. So anyway, yeah, all that's left is being handled. And then when you hit new game, a whole new operation pops up. So let me show you that now. So if you had selected on the new game option, it jumps to game. So in this case, I have a bunch of math in here. I'm not going to go into all the details about what's going on. So basically, we're just going to track, you know, your current score in register nine. Clear the screen. I have some stuff to move the, to check if we have a valid game. So here you can see I'm calling random, random integer that will, hey, where should we put the whole? Hey, where should we put the CA agent? Make sure we're not coincident, because that would be a very boring game if the agent was on top of the whole already. So make sure no one's in the same spot. Then I have a map loop. This loop is kind of like drawing the map. And here you can see this is where I'm actually parsing the input. So here, the buttons that are of interest to us are the arrow keys up, down, up, and right, as well as R that restarts the level case to get soft locked, as well as escape and queue both quit the game. So you can leave. And all those things have a corresponding bit of logic here. I'm not going to get into the details. There's just too much to talk about. You just have to know that whenever you move yourself, you have to cover up where you used to be with an empty space. And then you have to constantly check, oh, am I against the wall? Am I against the agent? Is the hole there? Just constantly be checking these things to handle the game. And that's just about game development. I'm not going to talk about game development. I mean, I don't know anything about that, so that's just on you. But this logic should be pretty basic. We have a test if you died, this is the agent died. You increment the counter for your high score. Then when you leave the game, it will see, hey, is our score a new high score? If so, save the value to the high score file and also update the value on the screen. So all that makes sense. And then when you're done, as I mentioned before, you have to, well, both clear the screen as well as return to cooked input mode. But then also, I did mention this, we are doing something with the cursor. So right now you can see on the screen, my cursor is visible. You can see that rectangle there. You can turn that off. And there's an ANSI code to turn off the cursor. Here you can see it.  Basically, it's just the escape code, question mark 25L. That will turn off the cursor. So that means whenever I'm, you wouldn't be constantly seeing that rectangle on the screen. So everything of this code, I actually hid the cursor. So at the end, I also turn the cursor back on. So that's what this line here is doing, this three lines. I'm printing out the ANSI code that would make the cursor a rectangle again as opposed to being invisible because you want to be able to see that. With that, I'm pretty much done with showing you different things here. It's a pretty cool game. Without looking into the code more in detail. I will do one thing though. I talked about that, yeah, this part here. So the reason why this wasn't putting the spaces in is because the way I implemented it. So this was when we were piping in a string into standard, just going to put into the function here. I did very, very rudimentary logic. So let me show you how the code works. So the thing is in ASCII, all the letters are together. So A through Z lowercase and A through Z uppercase. I think uppercase ones come first, but either way, they're adjacent. So here all I'm doing, you kind of can see is, yeah, you can see here, I'm basically I'm reading in the string in a very rudimentary way here. You can see I'm just, I'm reading in from standard input 32 bytes of data. So up to 32 bytes of a string I'm reading in from standard input. I'm checking the length of the string. I'm removing the trilling new line. And then also here's the loop. So in this case, I'm going through each byte and I'm subtracting 32 from it. That's because the difference between capital A and lowercase A in ASCII is 32. The problem is space is not space when you minus 32. So you should have some extra logic here that says, oh, make sure we're only dealing with letters. We're not dealing with numbers. We're not dealing with fancy symbols. We're not dealing with, because you can't capitalize a percent sign. You can't capitalize a space. So there should be some kind of logic built into this. I didn't do that because I wanted to keep everything simple, but yeah, so that's kind of what's going on here and that's kind of why you were seeing lack of spaces just because we didn't do any input pre-processing to make sure that there was nothing besides lowercase letters. Anyway, with that out of the way, we're pretty much done here. I will, now that it's been 32 minutes and all the normies have left, I will plug the Discord. We have a Fed Honeypot, no, no, sorry, Discord server. You can check the link in the description. It's secret. So check it out. All right, guys, see you in the next video.


Abiotic resource depletion is a controversial topic in life cycle assessment, LCA, with multiple definitions and approaches to measuring its impact. In this paper, we review the current state of the art in abiotic resource depletion, including the parameters used to measure it, the data sources available, and the latest updates to the models. We then suggest several new directions for research on abiotic resource depletion, including redefining the problem as a dilution problem rather than extraction rate and incorporating economic reserves and leakage into the models.


I'm very happy to start this day, where we're going to be sharing a lot of stories from the global community around DHS2 and the global COVID-19 response. So I'll get things kicked off with a small presentation around how we've achieved speed and scale through our global goods and local innovation. And then most of today will be dedicated to our various implementers in our global community to share their stories. So a couple of snapshots here, but today I'm just very happy to be able to share and I'm having a little trouble with the changing of the slides. Okay, so our global deployment of DHS2. So to open today, I will talk just a bit about our global goods and also around our local innovation. And so this is built around a long history and the foundations that we have built as a community over the course of many years. Then I will go into a little bit about how we have highlighted the local innovations that are at the very heart of how we have worked for decades and looking at a persistent focus on meeting the needs of end users in countries. So looking at district level, national UNOZERS, but also where health services are delivered in facilities and communities. So this first slide, it really is intended to just highlight what we consider to be our global public goods. So there is the DHS2 platform itself, the DHS2 Android capture app that has fast-tracked minor releases and critical support for the global deployment. We have our COVID-19 metadata packages. So this is a part of the body of work with the health organization around taking global standards and developing DHS2 products to help disseminate those standards. And last but not least, we also have our DHS2 Academy curriculum and that includes end user training templates, remote training support and moving a lot of these in-person academies into online webinars and academies. So a lot of innovation in how we continue to support countries during the time of no travel. So taking a bit of a step back, not as far as the birth of DHS2, but at least back to 2014, we had a lot of learning from the Ebola outbreak response in West Africa. And I believe it was the Ministry of Health in Liberia who first contacted UIO to send a delegation to the country to see how they could support the use of DHS2. So this was the system that was already being used in country and many users were familiar with it. And we also learned that even with the health system under duress in several of these countries during the Ebola outbreak, reporting into DHS2 was sustained. So we still had access to data through an established system. So what we've learned is that we need to be strengthening existing systems when these crises happen. We shouldn't be introducing parallel systems. We know that we need flexibility to facilitate these rapid transitions between detailed case-based surveillance and line listings when the outbreaks start to happen and then also being able to move to aggregated daily data collection when the burden is just too heavy. We know that we need simplicity collecting only the data that is needed to ensure that we have good quality data to be used and that we're not overburdening the healthcare workers from their real task which is providing the healthcare and the response. We know there's a lot of work to do around decentralization. So distributing the workload to subnational levels to facilities and even to community health workers. And these are the people who are really the source of data when it comes to early warning. We've learned a lot about data standards, the extent to which we can preset these and be able to disseminate these so that we can mitigate the proliferation of tools in the field and also be thinking about data exchange principles long before there is an urgent need. And lastly, we've learned a lot about making sustainable gains. So using these emergencies to step up surveillance capacities. So not just being able to respond to Ebola but to be able to respond to the next emergency outbreak. So we'll hear from Sierra Leone today. They have really honed their experience in disease surveillance and over four years they've been scaling decentralized case-based reporting. And they've recently introduced DHIS-2 as a national electronic case-based disease surveillance system. It helped them to detect Lassa fever outbreak in 2019 and it's being further leveraged now. So we have some really great stories around how countries who have made this happen. And lastly, this is also work that had sparked our first CDC partnership to further develop DHIS-2 and the software to be able to respond to the functionality that's needed for disease surveillance use cases. In 2016, the health data collaborative was established. This was a response to the development of the sustainable development goals. So this platform aligns technical and financial resources. So many, many partners that we work with and others, Gavi, Global Fund, Norad, the Gates Foundation, they have really brought themselves together around a common framework for strengthening routine health information systems. So this gave us a global platform to align our resources and really be able to dedicate several years of work into helping countries to improve their own M&E systems for health and also being able to emphasize that national ownership of those systems. In 2017, the University of Oslo became a WHO collaborating center for innovation and implementation research on health information systems strengthening. So we've partnered with the WHO for many, many years, but this gave us a place to work where we could expand upon the WHO Health Facility Data Toolkit and be able to develop these DHIS-2 metadata packages. So it's like an extension of those WHO standards that can be installed into a country's local DHIS-2 instance. So we're really looking at using DHIS-2 as a platform for disseminating these types of data standards. It crosses facility data, but also with linkages around civil registration and vital statistics, as well as integrating other types of data, mortality databases and population level data for better analysis. In 2018, we saw some major investments in malaria elimination systems. So the Gates Foundation launched the Digital Solutions for Malaria Elimination Project, and that helped expand the DHIS-2 core platform, as well as the DHIS-2 Android Capture app with new functionality that supports malaria elimination surveillance. And much of this functionality has now been repurposed for COVID-19. So many of these disease use cases, the software requirements are very similar. So we're looking at one screenshot here, which is some enhancements to relationship analytics that were built out to analyze the relationship of malaria cases with foci in an elimination context. But now we're able to re-conceptualize and repurpose that functionality for COVID, as well, using those same principles to be able to link index cases with their contacts and with clusters of cases. So when we develop in a generic way, much of the functionality has a life and a benefit beyond the specific disease use case. We also have a screenshot here of the Android Capture app, and a lot of improvements have gone in here to the Android app to really help the operational activities among field workers and helping them to answer the question, what is it that I need to do today? Towards the end of 2019 in Athens, there was an advisory group convened with experts from WHO and CDC on surveillance, and they joined a delegation from the University of Oslo and our HIST partners. And this entire week was designed to really develop and understand the requirements for vaccine preventable disease surveillance. And so this work, we are working on vaccine preventable disease case-based metadata packages and aggregate IDSR packages, but these design prototypes actually became the foundation for our COVID-19 metadata packages. So we were able to pull on years of expertise and experience, and many of these designs have already experienced some field testing and some validation in countries like Sierra Leone and Uganda. We will also have Dr. Ellen Poy, who will be sharing how the WHO African Regional Office has capitalized on this with many, many countries in Africa using DHIS-2 already for the aggregate IDSR reporting and being able to implement a surveillance system at a regional platform level. So now we can skip forward to 2020, this very interesting year. You will hear from Pamad next around Sri Lanka, but I wanted to emphasize here that from January, Sri Lanka customized DHIS-2 for COVID-19 surveillance. So there's this huge importance of having a global network of regional in-country expertise. And there are many countries who are able to move faster than we did at the global level to mobilize their systems for a COVID-19 response. A few more that come to mind include Bangladesh and Indonesia who were quickly able to update some of their aggregate daily reporting forms, as well as Myanmar who was able to update an event-based patient registry to capture COVID cases very early on. So this type of national capacity and ownership is critical to what we see as a successful response. March 11th, 2020. So this is the day that we officially released our COVID-19 metadata packages. And this is quite interesting because we have our tracker implementers here, Sherjeet and Yuri and Enzo at the Ghana Tracker Implementation Academy in Accra during this time. So they were working day and night to develop the first version of the COVID-19 case-based surveillance tracker package. And it also gave us this possibility for real-time validation because we had several country teams at this academy bringing their critical insights from their own implementation experiences to help us understand if this design is something that matches what their experience shows about what works in the field. And so all of this happened just as the academy was cut short and borders began to close. In April, 2020, we saw the Norwegian Municipality Organization launch DHIS-2 for contact tracing. So you'll hear a little more about this in one of our parallel sessions, but it just emphasizes that the challenges we face are not unique to low and middle income countries. There's a lot to be learned from the disease surveillance expertise across Africa and Asia and Latin America. So there's some really interesting use cases here at Municipality, a very more local level organizations who had switched from using Excel to DHIS-2. And finally, here we are in September on a virtual conference because we can no longer meet in person, but you can see that 36 countries have now operationalized DHIS-2 for COVID-19. And when I say operational, we mean that there's actually data actively being entered into the system for analysis and use. So I think at least from my experience is one of the fastest scale-ups I've really ever seen. And I think based on this presentation, you can see that it was really, this was built on years of collaborative work with our global community that helped us to respond. So now let's switch gears just a bit to tell a little bit more about some of these global goods. So there's the COVID-19 Digital Health Data Toolkit. So this was designed in a modular way. We have currently five different modules, case-based surveillance and laboratory reporting. We have a points of entry, screening and follow-up program, a contact tracing program that has relationships built in to those case-based surveillance. There's an outbreak line listing for when some of the caseloads get too high to do proper decentralized case-based surveillance. And then we also have daily reporting of cases of transmission status at some national level and key resources. So we have designed with the idea that we should be optimizing data collection and field-based workflows at the bottom, but also we need to be having a rapid data-driven response at the top. So being able to bring all of this data together and comprehensive dashboards to support the analysis and use. I'll talk a little bit more about what's actually in the toolkit. I think many of you have heard of the WHO metadata packages. So these are installable JSON files that contain all of the preconfigured metadata. And the idea is that every country doesn't need to start from scratch and redesign DHIS too. We can provide a bit of a template and we can match that template to what the global standards are. And in this case, this was all aligned to the WHO COVID-19 guidance, the technical guidance that was published publicly. So at that point, a country can take this package, they install it in their own national instance, but then they're able to adapt it to their own use cases. So it's a bit of an accelerator that way. In the interest of data exchange, we've included coded mechanisms for the WHO case-based data dictionary. And we are looking at SNOMED, global patient data set codes being incorporated in the future. We also supplement this with documentation. So detailed installation guides, how do I actually get this into my instance? System design guides that tell you how did we make certain design decisions based on the technical guidance we had and what we know about design practices. And finally, all of this, we need to be able to find new ways to train users in the field, particularly with travel restricted. So we've been working with a lot of these end user training templates to make it a little more ready to go. And I know many of our countries have been supporting virtual trainings down to facility and district level. And these are also developed in collaboration with our regional HIST groups. So we have a lot of field-based knowledge being input into these products. So these packages, as I've mentioned, the whole point of collecting data is being able to use the data. So we really want to emphasize having data at the fingertips of decision makers. So all of our packages come with DHIs2 dashboards out of the box. To the best extent possible, they are being updated for emerging COVID analysis practices and new KPIs, particularly on contact tracing that are coming on board. But we've also looked at expanding existing WHO health data tool kits for DHIs2. So for example, we've had a cause of death package for a while that supports the WHO SMOL codes to be able to support countries in better capturing the medical certificate cause of death data. But we've also expanded this with some prototypes for rapid mortality surveillance. So where it can be very difficult to capture cause of death in the community, we have a more simple prototype that allows capturing all cause death and being able to do key analyses around excess death, particularly when we know that it's very hard to get good numbers about what deaths are truly attributable to COVID-19. We're looking at the expansion of non-communical disease registries and trackers with WHO and others. And these will become really critical as the analysis of comorbidities and really understanding what are the vulnerabilities in different populations are as you plan COVID response. And lastly, we have some really great sessions around secondary impact monitoring. So this is around measuring COVID-19 impact on health service delivery. So we know that COVID-19 cases and deaths are not the only ones affected. There are many people who are not receiving the key health services they need. So Global Fund and UNICEF and even at country level have begun to explore some frameworks about where we can use this very robust HMIS data that has been supported and strengthened over many years. It provides us a baseline for doing these types of analyses.  So I had told you we were able to achieve scale rapidly around using these global products where I've showed you but also being able to really tap into a very long tradition of the University of Oslo through action research. So again, this is the idea of being able to learn by doing and we develop a global product. So say that is the DHIS2 software release but then through local use we're understanding how our country is adapting this and what are the new requirements that they need. And in the perspective of COVID-19 what are those new emerging requirements as people are really testing out this platform for new use cases. And it's this virtuous cycle of global standards coming top down and local innovation and best practices moving up that helps us to really develop a product that's going to meet the needs of our end users. So I'm going to share a couple of examples here around how our national and regional experts have expanded and innovated on the DHIS2 platform but these are really just teasers for some of the other sessions today that I hope you'll be able to participate and learn more. So you have a snapshot here on this is a custom dashboard that was developed through web apps. DHIS2 has really invested in leveraging itself as a platform and making the app framework as a way for countries and implementers to be able to innovate more easily on top of the core software. So here we have a custom dashboard used by the LOW-PDR epidemiologists and in their emergency operations center for being able to analyze more quickly the relationships between index cases and contacts and where those cases are moving around the country. I think one of the most interesting aspects from the global package was the wide adoption of points of entry screenings. So we've talked about case-based surveillance for many years, a little less emphasis on points of entry, but this has really taken off with incredible innovative examples from Sri Lanka, from Uganda using Android apps and travel passes at the land borders from Guinea-Bissau generating travel passes based on validated laboratory surveillance data. So this is really fascinating and it shows a bit of an ability to be able to cross sectors because points of entry, they are generally not controlled by ministries of health. So we are seeing sectors work together and bring data together in a way that we haven't really seen before. For many, many years, the ability to link case data with laboratory data, so laboratory data coming from one source, case data coming from more of clinical points of diagnosis, it's a challenge to link this data not only in low and middle income countries, but also in Western countries like the U.S. So we've seen some very interesting solutions that really support complex workflows and they really are complex workflows. So we have some presentations from Rwanda Ministry of Health and from Hismose Ambique in Guinea-Bissau, how they've developed some tools to be able to bring these different data sets together. And last but not least, we've seen the importance of getting data out of DHIS2. So data from DHIS2, it's a source for national program planners for the national response teams, but also we need to be able to support risk communication to the public. And so increasingly we are seeing solutions and innovation around how to better get that data out of DHIS2 and put it out there for communities and the public to understand and feel confident and feel some transparency with what's happening with the epidemic situation in their country and locally. So I will stop here just with a small reflection after the Ebola crisis. So there were ministries of health and finance in Ebola-affected countries in West and Central Africa. They convened in Geneva and the Lancet wrote, the lesson painfully learned shows that we don't need another vertical program for a specific health condition or challenge. What we need is to build resilient health systems. So I've summarized a bit of our roadmap this year, but what I'd really like to emphasize is that we are very much on a pathway forward together. And when we close with a plenary session at the end of the day, Gavi and Global Fund and CDC will join us to share some perspectives as global partners around how we can work together to really build resilient health systems and to be able to know that when the next emerging disease X appears that we're going to be ready for it. And so with that, I thank you very much for letting me open the day and I'm very pleased to hand it over to my colleague Pamad Amarakun, who will share the experiences, the pioneering experiences from Sri Lanka in developing DHIS-2 for the COVID-19 response. Thank you. Thank you so much, Rebecca. So good morning, good afternoon, good evening, everyone from wherever you are joining. I'm Pamad Amarakun representing his Sri Lanka and I'll be talking briefly about COVID-19 response with experience from Sri Lanka. So let me just start with some background about history. We are all aware that COVID-19 started off somewhere in late December. In fact, on 31st December, China reported it's the first cluster of COVID-19. And then with regard to Sri Lankan context, it was not about whether we would get COVID-19, but we were more worried about when we were going to get it because we had so many Chinese tourists and employees who were working in Sri Lanka and we were not sure like when we would be getting this disease into Sri Lanka through one of the tourists who were entering the country. So in fact, Sri Lanka got its first case of COVID-19 on 27th January. And interestingly, by the time we got the first case of COVID-19, we had already thought about what to do with regard to information collection and surveillance on COVID-19. So how it all started was on 20th January, 2020. So on 20th January, so about one week before we got the first case of COVID-19, we had an initial discussion with the Ministry of Health Sri Lanka. So what did they ask? So they had few specific concerns about setting up the information system because the main issue was that we did not have an integrated disease surveillance system, digital one, which connects various institutes of under the Ministry of Health as well as other stakeholders such as immigration department, the ports of entry. So one major issue they had was to share this information that is coming with different stakeholders. So these stakeholders include Ministry of Health stakeholders as well as non-Ministry of Health stakeholders such as those who are there at the ports of entry. And then whatever it is, like we were certain that we are going to get this disease in like a few days probably. So they wanted something to be developed really fast, not about weeks, so usually it takes weeks, but this was to be developed in few days. And then of course, usually the Ministry procurement process even when it comes to information system, it's a really lengthy process, but they did not want to get that process involved, but rather it had to be like a really fast procurement or establishment of the system in the Ministry setting itself. And then of course, they were not sure because nobody was sure, like we are talking about early January, no one really knew how the disease was progressing and which I mean, like when you consider about a country, what's the scale it will be affecting. So they were not sure where we are going to implement the system. So what they only knew was like we may start with a few facilities, but we may really need to scale it up as time passes. And then of course, the scope of requirements, we were not sure. I mean, it could have, it could change rapidly. So you can't go for a detailed SRS at the time of designing the system, but it has to be agile that there'll be requirements that are changing and we had to incorporate modules even after the system has been set up and is functioning. And then because we had so many stakeholders joining and entering data, sharing data, weaving data, they wanted some sort of access control so that say, for example, a particular department, they will only have access to a particular set of analytics or data. And of course, like the training, because now it was COVID-19, we could not get people gathered at training centers. So the training was one major issue. So they preferred a platform where the health staff was already having some experience. So the training, the learning curve of the system was not that great. And of course, there was some concerns whether they would prefer to have some mobile data entry as opposed to entering data from a laptop or computer. And also to integrate with existing information system because like already they knew, like we had to start off with somewhere about the port of entry, the airport, so that itself had its own information system. So there was scope for integration as well. So, I mean, after the discussion looking at all these requirements, what we felt was DHIS-2 was the ideal candidate even though at that time, talking about third week of January, this was not tested anywhere in the world. But then again, we took on the task and in like three days, we were able to get the first version piloted. And in fact, what you're seeing now is an extract from one of the popular newspapers in Sri Lanka where the Director General of Health Service informs the parliament that this kind of system has been set up and we have piloted in and it's ready for implementation at the ports of entry. So in fact, like there was so much of support from the ministry administrators all the way up to the Director General of Health Services in getting past approval to the implementation of this system. And then about the community, right? So this, as you can see is a screenshot from the DHIS-2 Slack. In fact, this was on 29th January. So this was in fact my official, the first official communication with the DHIS-2 community. So what I did was after having the first pilot, I mean, so we were ready around 25th January, I informed the community about what we have done in Sri Lanka and that we have launched it. So as you can see here, it was that time it was novel coronavirus, it was not COVID-19, this January. So with this communication, of course I received so much of feedback from the DHIS-2 community, from University of Austria especially and even from other, his notes as well as the community, right? So about the functionality of what we developed. So it was mostly about customizing DHIS-2. So initially the first version, it was about the port of entry, which was just a DHIS-2 simple customization. But the thing was, it was getting more and more complex because there were so many user requests that we had to cater because of the urgency of the situation where we had to think of some custom development. So this custom development was required for certain functionalities, which is not possible by using code DHIS-2 applications. Sometimes there were like the customizations we have already done, which also required some kind of development on top of it. This was where in around mid-March, we had a hackathon developed and so many freelance developers, Sri Lankans who were joining from Sri Lanka as well as outside were gathered along with all these stakeholders mentioned, including the government ICT agency who did a major task, as well as the University of Oslo who provided support and guidance all throughout this process. So more about this hackathon and the local innovations in this symposium that we are having on local innovations. But we had the customization plus the development component also, which ran parallel. So what you're seeing here is the entire ecosystem of the modules that you have in our COVID-19 surveillance system. So the first component that was developed, of course, was the point of entry program. So this was very simple initially where we wanted all the tourists who were entering the country registered there and that data to be available to the field health staff so that they can perform a visit while they are in the country within the next 14 days. But then again, it was always changing. The requirements were changing. So by about first or second week of March, the country's policy changed and they mandated everyone who was entering the country should go for mandatory quarantine. So everyone was put on government quarantine center. So this was when they wanted the system to be customized so that all quarantine patients or persons information should also be there in the system along with what's, I mean, they are their symptoms and the tests they have undergone. So this is where the quarantine health center information module also came into the system. And thereafter, of course, by about the third week of March, we had a huge rise of cases. So this was when they wanted to have the case information also integrated into the system and the suspect information. And then also to go along with this, they wanted different kinds of mappings about case to suspect. So these components also had to be developed in addition to the routine laboratory and the hospital information that they've required from the cases. And then, I mean, it's the same in almost all the countries because of the enthusiasm, a lot of people try to contribute to the ecosystem of information in COVID-19. So there were so many third party applications, mobile applications that were coming up. So the government also required, the ministry also required some kind of support to integrate the information that is coming from these third party solutions into the system. So we had to work on that part as well. And then once we started seeing a sudden rising cases as well as the deaths, they were more concerned about having an idea about the ICU beds, the level of ICU beds. So this was when the ICU bed monitoring, another custom application was developed.  So this was when other integrations such as integrating with the immigration system was required on top of already existing functioning modules. So I just wanted to briefly highlight, it's not about just one module that was there in the system, but it was catering a wide range of requirements. And what you're seeing is the timeline of how these modules were developed along with how the COVID-19 progress in the country. And you may be able to see that from late January and by about the late April, within that three months time, we were able to get all these modules developed as well as share it back with the community. So what you're seeing here is a contact mapping visualization, which is of course a custom application, custom web application be developed based on the requirements, because the core DHS2 system does not support this kind of visualization where you wanted to see how this is progressed from a confirmed case to suspect. So this mapping was required and this was done, this was made in fact as an output from the hackathon we had. So more about this in the next symposium. But what I wanted to highlight is that this local innovation about the contact mapping visualization, we share it with the community and the University of Oslo took it up and identified the generic requirements and with the help of the University of Oslo developers as well as local developers, we were able to come up with this generic contact tracing application, which was then released in the DHS2 app store. So this was in fact contributing back to the community. And then again, we further expanded the contact tracing application by like they wanted to check where are the persons, if someone is confirmed, they wanted to check where this person has visited in the last two weeks. So for that one, they wanted to take data from mobile tower, of course with the consent from the patient as well as with government authority. So there was an integration component that was developed which kind of pulls data from this mobile network information to the DHS2 which shows where the person has traveled in the last two weeks. So this was again another custom development we did on top of the contact tracing model. And then again, this is the ICU bed tracking which is in fact a very simple tracker implementation but due to the prevailing situation where they required some custom visualizations and very simple interfaces, we had to develop this ICU bed tracking simple web application within like two weeks time. So there are a lot of challenges in this entire procedure. The thing is like the biggest challenge we had was uncertainty of requirements because we were not sure we never thought that we had to incorporate all these modules when we first developed the initial version with the port of entry program in late January. But now when you look at the system, it has about six or seven components and some of them are even custom made. So the requirements were always changing and we had to be agile to the changing requirements. And then sometimes because the health staff was too much burdened with data entry and even at the ports of entry, they had other tasks to attend to so we could not allocate too much of time for the data entry. So for that one, there had to be some solution. And then again, there are a lot of other requirements that were coming which were not possible using the DHS to co-applications. This was also a challenge we had during the initial period. And the biggest task, one of the biggest tasks was training of end users because not only the other biggest challenge with the COVID-19 was that mobility of everyone was limited. So we could not bring health staff to usual training centers that we were used to do. So we had to explore other means of training and that was a major task in the first couple of months. And then again, there were a lot of applications, third-party applications. There were a lot of mushrooming of applications, but some of them, they really had a lot of good things about them and we had to integrate with them so that there has to be some kind of data sharing. So we had to think about integrations. And then the strategies, a lot of them. The first strategy, of course, was using the DHS to itself because it was a customizable platform. Had we grown for a custom-made third-party software, with all these changing requirements, it would have been a nightmare. So it was one of the best decisions that we took early in the early days of COVID-19. And then we had to integrate with existing information systems in the government sector, such as, for example, we had the immigration system which already had passenger information there before the flight landed in Sri Lanka. So that information, we had to push to the DHS to instance so that they only had to enter data about the health conditions. And then again, of course, what we did was, we designed a few web applications. Of course, with the concurrence of the university was slow because like the thing was, there was too much of expertise required for a totally new set of developers. And without their support, of course, this would not have been possible. But with this web application, we were able to quickly address the issues that were not possible with ODHS to applications. And then we had to support third-party solutions. And also we had to think about the country, had to think about the roadmap for the personal health application. So there were some discussions about the country's information system as well. Now that the country is even thinking about going for a central HMIS, which gets these all the vital indicators from all the programs so that dashboards are visible, which we didn't have before. And then of course, the training. So we used so many technologies, especially the Zoom. So we thought it would be a very difficult task, but it was not so. So we mainly use Zoom platform for most of the online training. And then for troubleshooting, we had to use remote desktop software like TeamWeaver. So these kind of tools, which we didn't use much before, especially to provide end user support and training, we had to use during the COVID-19 era. And of course, I must definitely highlight the multi-sector collaboration because this was not just a task possible with health ministry or the history Lanka. There were a lot of parties, the government entities, as well as the private sector and the freelance volunteers, as well as the health staff who were always there to support the information system. So I would just stop here, but I must really thank the health staff of Sri Lanka without whom this would never have been a success. So thank you so much. Yeah, thanks very much, Pamod. Take it on from Pamod to also again, share experience from COVID response with support of the HIS too. This is a presentation from Uganda, HISP Uganda, appreciation to a team behind the COVID response support at HISP Uganda. Pamod and Rebecca have shared Uganda has not been also left behind in the COVID response. My background picture is at the border of Uganda where we did emphasize use of DHHIS too for COVID response. For Uganda, I'm going to focus on our approach to all this. Our approach was mainly to help with the data collection at source and be able to visualize. And so is the map, is the dashboard I'm sharing here that Rebecca has highlighted here before as a local innovation to be able to support the COVID response. So what you see here as from our government server is a replica of what is currently being used at the command center to be able to respond to a response. And what it does is it allows to bring data from different sources, from different tools that is all reported into DHHIS too and display. And particularly what you would be able to see that the high level visuals that really allowed the decision makers to be able to take a decision on where and how the outbreak is progressing and what measures need to be controlled. And you will also be able to see that we do support quite a number of pillars in the COVID response. For example, you have the laboratory, you have the surveillance, you have the case management and logistics dashboards. And again, you also, our point of key, point of entries have been our most focused and we will see data scrolling down and showing the different data from the different points of way. So this attempt is to really bring almost near to real data representation at the high level senior management for COVID response. So our journey started way by looking at what the preparedness in terms of data management, in terms of data transmission, in terms of data collection were laid out by the ICT COVID response pillar. So you will see that this picture or this diagram of flow shows the different sources and how data is exchanged and interlinked with the different response pillars and also visualized. So here I will highlight more where the DHHIS too has played a key role in terms of capturing data and also in terms of being able to visualize. So one of the key areas in this COVID response was the self-reporting or the reporting from the community. And that was through the rumors, alerts and signals as many of you may know them as. So particularly at this point, our DHHIS too allows us to receive SMSs from anonymous users. And for particularly for Uganda, the system was being configured to be able to allow community, Uganda to be able to send notification to the send pro team to be able to follow up. So under this point, the DHHIS too again was configured to allow that messages around COVID symptoms, COVID suspects would be reported by the community. And this also worked alongside with other tools that were put in place. Another area that was key to COVID, that is very key to COVID response is the different sources where this data is coming from, where the suspects are. And particularly for this, we're looking at the points of entry, which is our borders and airports, the health facilities where the patients would have contacts and the community, plus the quarantine centers for those who have probably been exposed and the isolation center for those who are positive. And at this point, we were able to reconfigure our EIDS as we called it the DHHIS to tracker to be able to support the investigation at this point. The other key area that we also have supported with the DHHIS too is the investigation and outcome in the isolation centers. Over here, you will be able to see that for all the isolated cases in data is collected from these cases, aggregate and individual level. And the DHHIS too has been configured to be able to support that. And lastly, we were also able to allow the DHHIS to visualize this data integrated from the different systems. And so the dashboard I shared. As cardboard shared, when everything shut down, of course, for Uganda, the borders did not shut down because we highly depend on imports through load, by load from Tanzania and in Kenya. So in the picture here is one of our busy points of entry where we deployed the DHHIS to Android tracker to be able to capture information real time from the travelers. So at this point, the tracker is where we really started from in terms of our COVID response implementation. And slowly by slowly, we've been able to reconfigure our tracker to support investigations at the health facility, community, hunting centers and the isolation. And purely here, we used the Android DHHIS to be able to collect data in real time. The alert notification process was continued where the command center and the teams responsible for follow up were able to follow up the notifications or rumors that were coming through the system. Again, at the points of entry, at this point, we are able to collect all the information from the travelers regarding their bio data, regarding their travel history, science and symptoms and automatically integrate it with the lab information management system so that we'll be able to reduce the lab, the results turn around time. And over time, the East African has also developed a track driver tracking system that we've also been able to integrate our EIDSR with. And then also for the community, the module has also been configured to allow for investigations within the community and also the returning Ugandans who were in abroad. During the, in the beginning of the COVID in Uganda at the borders, we had a process that would allow a track driver be sampled. And after sampled, it would be allowed to travel. And once the results have come back, then you would have to locate where the driver is so that we can be able to either isolate them or give them the results. In case they're positive, then they will be isolated. So we did develop a tracker app, DHS2 integrated that allowed us to be able to scan the QR code for this driver on different checkpoints so that we were able to identify whenever the results were received, we would be able to identify the point at which this driver would be. And here we use the GPS coordinates of the scanning points so that we can be able to locate where the traveler was. And this would give us the point and the time when the driver would be at that station. Slowly with the outbreak now shifting to more numbers and then getting to more aggregate cases and also being able to expand to more COVID treatment units. We have also remodified our implementation to be able to support investigations and outcomes within the treatment site. And at this point, we're able to capture the details of all the patients who are in isolation and then also at admission but also during admission and also at discharge. The DHS2 has slowly become the central repository for data from different systems. So now it serves as they have for when data is supposed to be analyzed and picked into other systems or analyzed and also displayed on the dashboard as we've shared. In terms of visualization, we use a combination of visuals. We do have, of course, the core DHS2 dashboards that do help mostly at the implementation sites for the teams to be able to appreciate the data and see the progress and also be able to identify some of the challenges they have with the response. Over here, we are moving now towards a tool built on the same dashboard to help the command center to be able to narrow down and drill down to the individual level. For example, for any given CTU, which is a COVID treatment unit, we're able to see the cumulative numbers in admissions and death and more information. And also we're able to drill down and be able to see individual level data for the patients. So at this point, once you click on the view cases, you are able to drill down and see the individual data in the line list but also as an individual patient chart. And lastly, in terms of the achievements we've done, we've been able to create a repository for COVID data. And as you can see here, we've quite a number of data sources and datasets that have been created both at the individual level and aggregate level that are currently being updated routinely either by direct import of the data into the system or direct entry of the data into the system, but also using exchange from other systems, especially the lab and ODK. With that, I come to the end of my presentation and I wish to appreciate the teams that have been supporting this implementation not to not forget Minnesota Health that is at the forefront of this response and use data from the system to be able to make decisions and they manage the outbreak. Finding from CDC through infectious disease control that supported the development of these pieces and the rollout of the system to many points of entry but also supporting the team that has been supporting the Minnesota Health to build a dashboard and not forgetting the HIST team that has worked tirelessly day and night to make sure that we are keeping the team informed of what is happening in the field. Thank you very much.


Rydw i'n amlianneud Rachel Pearson. I am the Team Lead for the Residential Placement Team within CPSG. I just wanted to have a conversation basically to go through the kind of skills that we're looking for for people within the Care & Support Broke of Rolls. So we're looking for people that are really good at being part of a team that are able to share information and knowledge with their peers but also able to give advice and support and receive advice and support from others. On the flip side of that as well, we need you to be able to work independently and autonomously and basically show an initiative that you can work on your own and you can take on challenges and progress the work even though there are challenges that you may come across. So Cairns Port Brokers need to be good verbal communicators. We have to be able to communicate openly and clearly with the customer and their families and ex-ofkins but we also will be working closely with social work teams and with other partner services as well. So we do a lot of our communication via email and telephone so by having really strong telephone communication skills and being able to note everything on the system but also being able to use software and spreadsheets as well and when working with care homes and with families, we need to be able to explain what we're doing to them and explain the services that we are looking into. There will be negotiations that will be taking place with care homes on behalf of West Sussex and when it comes to finances it's the case of having to explain what we're doing to families and being able to really help and guide them through the process because when they do come into our services not always do they know what is going on so it's really good that we can give really open and clear explanations of what we are doing, the processes that we follow and it helps reassure them at that time. We also need people to be able to work in an organised way that when work comes through they can prioritise their work and they can risk assess so currently our care homes support brokers do this throughout the day it's the case of having a look at what cases they've got allocated to them seeing obviously what they are able to do on that cases day before but things may have changed by the next day and we may have other cases that are come through that actually then need to be prioritised over cases that they have already worked on so again it's using the knowledge and the skillset that you have and the skills that you can transfer from any previous job that you've done and use that within the care and support broker role and to be organised and risk assess and basically make sure that you are keeping on top of the cases that you have and using your team for support along the way so care and support brokers need to be able to actively listen to customers and their families but also be non-judgmental no two cases are the same so it's taken on board what has come through on the assessments from the social workers and just having a look at what the information you've been provided with and us trying to find the best options for that customers and remaining person centred at all times. We need care and support brokers to be able to build relationships and report with people whether that is again families and customers it's external services as care homes could be that you need to speak to the social workers or nursing services to make sure that the needs can be met in the care homes that are being sourced so it's about being really open and having them clear communication whether it is on the telephone or via email. We would like people that are passionate and enthusiastic about helping people within our community yes we need to be aware of budgets and how much care homes are costing but we also like I said need to be person centred keeping that customer at the forefront of what we do at all times making sure that we can find the best fit for them and that their care and support needs are going to be met in the safest way possible but also it's about being flexible and adaptable within your role and we do get urgent cases that come through and we do at times get more than one case that comes through where we need to find a placement very quickly so it's about being able to think on your on your feet it can be a very fast paced job but it's also a very rewarding job so there's some of the skills that we are looking for at the moment within the care and support broker role within ZPS team.