So that's gonna be our agenda. Is that all good? All right, cool. So how many people are using end-to-end of functional testing? Have two arms? Good. So what is actually functional testing is and what's the, what actually the problem we have with why do we need functional testing and end-to-end testing is the reason for it is we don't need to hire people to test, click and test. We actually wanna get as close as possible to the user without getting the user into the room and testing it. Don't get me wrong, it's not a replacement for the user, but how we can get most of the job done and get the repetitive task out of the way. To obviously simulate the user and use some sort of a tool for it. And in implementation of end-to-end you'll find two definitions, which is one is a test runner and another is browser-automated tool. So that's where Nightwatch just kicks in. It is actually our test runner. So tool that controls the test, it's written in JavaScript and it's just basically your NPM dependency. So if you ever use NPM dependency you just go type NPM install Nightwatch and you have Nightwatch on your machine. So the development been on and off, but it's open source, it's on GitHub, you can contribute to it.  So let's just without further ado go rather than going into much theory, let's write a test. Anyone wrote a Nightwatch test before? Good. So we're gonna do that. And actually I was thinking what to test should we install Drupal website and do that? I was like nah, we already have one Drupal Camp Singapore. And I mean the simplest test we can do is actually go to the page. So our requirements is to have the title, right? Of the conference Drupal Camp Singapore. Let's go to the page, let's just check if we can load the URL and see the title. Simple. So Nightwatch tests are pretty simple. If you use JavaScript before, so you just do module export, then you define a number of functions. Here there are two before each and after. Can anyone tell me two more? Judging by this. There's after each, there's before. The difference is before and after runs only once. Before each and after each, obviously run before each test and after each test. So after we will start the way, we'll say browser and browser variable for Nightwatch is your client. So how to control your browser, you supply browser space and you send it. Woo. I hope it's only one slide that does that. Otherwise we're in trouble. I think the resolution is wrong. Yeah. But for the browser, we'll just say which URL we want to go to. I may, that's better. So everyone can see that still. Do you want to move closer? Because I was expecting a resolution would be just a bit bigger. Sorry for that. But we chain command. So here we supply, let's see how we'll go further. We'll supply the URL, which is DrupalCam.sg. And then the second command we're gonna use is wait for element visible. And can't remove this. There you go. Maybe a bit better this way. And then we say, okay, let's wait until the body element is actually there. So this is, we put that in before each. So it means as many tests as we're gonna put in, every time it's gonna run, it's gonna go to URL, type in URL and wait for the element body. And here are our first tests we're gonna put in. So you just put the body of the function. So you supply, you tell what's the name of the function. In this case, it's a first Drupal Singapore test. And then we'll write our test. So we wanted to test the title. So there's a number of commands called assert. So we're gonna assert the title and it's gonna be a Drupal Camp Singapore 2018. Any questions so far? Pretty simple. So let's run it. Let's pray to the gods of the live demo. So what's happening here is I'm actually conducting the service. So outsource partial stuff to the service in the cloud. So it goes there and the service actually, the test is on my machine. So now it was still sits here. So there were two assertions as you saw. So two assertions. First one is element body is visible after 900 milliseconds and the second one testing the page title equals Drupal Camp Singapore 2018. If you look back at our code, so we can see that the first assertion came from wait for element body, right? So it actually came in from before each and the second one came from when we actually assert the title. So let's actually see what happened when we executed the test. So the first thing we did was actually calling night watch, right? Then we supplied the configuration file which we're gonna talk a little bit later about and then we provided the test file. That's all we did. I wrap it up in NPM run command but that's pretty much it. And of course the output we already kind of look at it before but as I said, the wait for element visible body was going into the first assertion and the second assertion was actually checking that the title is correct. All right, so let's see how it actually all runs together, how we pull all together. And depending on your setup or your project, if it's a personal one, you might run it on your local machine. If it's something a bit more experimental you might try something else. So at the moment we have my laptop and our night, our cold night watch is sitting there. That's pretty much simple. And what night watch is actually, it uses WS3 foundation web driver API. It performs command and assertion on a DOM element of your HTML page. That's all it does. It also have some cloud service support, continuous integration support where you can connect it to the services which we're gonna look at right now. It also provides querying by CSS and by XPath and we will have a bit of time and then we're gonna look how it actually works. What's the difference between CSS and XPath if you haven't seen it before? And it's easy to extend so it's easy to write your own command, easy to write your own tests. So let's see where we're at the moment. So we actually know we have a test runner, it's in our machine, but as we said before for automated testing we need two things. We need a test runner and a browser automation tool. So what actually automated the browser? There's this thing called Selenium and it's free to use and download. It's not open source though. It's a web testing frameworks and it runs on Java. You can use it standalone and decouple. We're gonna look at it in a second and it provides a great artifacts for testing. Apart from the logs it also can provide your screenshots. It also available as a Docker image which is quite handy these days because your Ops team probably would, if you ask for them they would install it much faster just to experiment with if you don't have control over what you install and what services you are using. So again, I'll see it's on our laptop but here's our Selenium server which runs on Java and our night watch talks to Selenium and says here's my test, run with it and then send me the answer back. Did it fail, did it pass? What happened? So when we look inside what actually Selenium does it talks to drivers. So it talks to different browser drivers. So it can talk to Firefox, it can talk to Safari, it can talk to Chrome, it can talk to Edge and there are different browsers provided for different tools. Sometimes as a part of the Selenium team writes them, sometimes I think Google writes Chrome browser. I'm not sure about Edge if it's Microsoft or Selenium team. So any question about that setup? The machine which is a development machine and the web driver is it also on the same machine? Good question and that's what we're gonna look at. You actually have three choices. So you can have it locally, everything, what we just look at all three parts sitting on your machine. You can use cloud services and you can use containers and with containers means you can either put it in the cloud and connect it or you can leave it on your machine and run containers on your local machine. So three ways to set it up, local stuff.  So I'm just joking but it takes a while to actually get it all up and running on your local machine. There are good guides there but there is no quick way to do it. I find like it's a good way to find out how it all works but it means you need to install every browser and the driver for each browser driver that talks to Selenium and then make sure the Selenium is running and not hang, open the ports up and then configure Nightwatch to talk to you locally. I've done that before. The good thing about this setup, if you set it up and run it, the browser will open up and you'll see the actually all the clicks it would be automated on your machine. There are links provided to blog posts where you can see the video how it's done on your local machine. So this is the advantage of this setup. It's also cheap. I mean, not time-wise cheap but cheap in terms of you don't need to pay for any cloud services. And as I said, it's all executables. So the second one, cloud services. It's the one that I just showed you. So all I had on my machine was Nightwatch. The rest of the stuff I just outsourced. The most two popular cloud services are browser stack and source labs. Anyone use browser stack before, source labs? So second, actually the most useful part how those services started is manual testing. So you would go to source labs, you would select I want Windows machine with IE6 running or Windows XP with IE6. You would go, they spin up machine and you could actually manually click in the web interface and test your browser. And then they, as a kind of guess second generation of their services, they roll out the automated stuff. That's what they charge more money for. Starts from about $100 a month. Free trials, two week trial for source labs. I think two week trial for browser stack. Very similar pricing. Yeah, so and they set up Selenium for you, drivers, virtual machines. All you care about is just providing the correct settings file by the API key that they give you. So that's how it works. So again, Nightwatch sits on our local machine and in the cloud we have all the Selenium setup. So here's our source labs, here's our browser stack. And that's what happened. So I just ran a command, Nightwatch send it according to the configuration file, got the answers back. Whatever happened in the cloud, stay in the cloud. In fact, we have results. To prove that, I would go to my source lab account and nine minutes ago, we just executed the test. In fact, you probably didn't know, but it ran on Windows 7 on Firefox 61. And if you still didn't believe me, you can actually play it. That was the test really. We just checked that it is a title, took 10 seconds. Any questions about the cloud setup? Let's move on. And you of course can roll out your implementation of this stack and not pay $100 to source labs or browser stack and pay $100 to AWS, Google Cloud, DigitalOcean or your preferred cloud provider. But it means again, you need to have a look after your setup. So if you have Ops team or if you have people interested in it, so there are options. And the last but not least is a container and Docker service. The good thing about the containers is you can either run them in the cloud or locally. So if you spin off the machine in the AWS, you can spin off Selenium server using the container in about five seconds after it downloads. So depending on your browser speed. And the good thing about the container setup thanks to Selenium, you can have all of it being wrapped up in a single container or you can have Hub as they call it for Selenium and nodes as a separate containers and make them talk to each other. So this setup is usually good for a big enterprise production apps where you need multiple nodes, lots of browsers. I'm still using that. In fact, the only thing I'm using, it's called node stand alone. So Selenium node stand alone. I think that's what it's called Selenium stand alone Chrome. Sorry, Selenium stand alone Chrome. And it basically wraps up Chrome browser, Chrome driver, Selenium in one container. And you can, using your tool of choice, either Circle CI, my preferences, GitLab CI, you can wrap it up and just using one command. If you're not familiar with Docker, don't worry about it. But if you are, that's all you need to write to be able to have a container up and running, three lines. And two of them actually define its name. And one of them define where to grab container. That sits on a Docker hub right here. So Selenium provided and the one I was talking about is the Selenium stand alone Chrome container. Again, if you don't know about much about containers or the operation stuff, don't worry, I'm not gonna go deeper than that. This is just something for you to research if you're interested. So any questions about the container set up, cloud set up or local set up for your tests? All good? Okay, so here's some links to actually do those containers. So you can see the first one is a hub. So just Selenium, second one is stand alone Chrome. So it's a Selenium and a Chrome. And another one is just node Chrome. So you can have hub and Chrome. You can also have Firefox and other browsers as well. And actually the configuration file, remember the one we provided? There you define a few things. Again, we're not gonna go just a lot of lines and every blog post you go about night which would talk about it. So all we're gonna say it defines test location. So we're a test city. It also defines your extra commands. If you wrote any extra commands, it would define you at the local machine where the driver is sitting. And it actually can be in JSON and JS file. This is I found out just recently. The good thing about JavaScript file configuration is that you can use the environment variables. So you won't commit your API key from a source labs, for example. You can provide as a variable. I don't think you can do it for JSON file. Okay, so how is Night word JS relevant in Drupal? And has anyone used any other tools that available in Drupal at the moment? Phantom JS, yep. Web driver, did you use a web driver? Yep. So before 8.5, so before March, April this year, there was simple test in PHP unit. It means if you wanna write a test for Drupal just using core, you would need to know PHP. The Phantom JS was used. Phantom JS is another one of those drivers. Like we look at the Chrome driver and Firefox driver. Phantom JS was one of the first one appeared and it was made basically to emulate any browser. So it was like a very tiny, teeny browser engine and lots of people used it before browser companies decided now we need to put our engines there so people can test with them. So as a result, it's minimally maintained and apparently it's crashing a lot on Drupal CI. So when you submit a patch for Drupal core and you see this red or green things that's when Drupal CI runs and if you wrote any of the front end tests it might crash just because Phantom JS just becomes more and more unstable. So first there was a decision for 8.5 to actually bring the Chrome driver. Chrome driver is what Selenium is using to control all this stuff. So it's like W3C standard for talking to a browser and terminating the browser. The problem is with the current latest live version of Drupal is most of the tests are still using Phantom JS. Obviously they're gonna crash and show me how many front end developers know PHP. Like that's another big issue. Especially PHP and then you can try to teach them PHP which is fine. Then you show them PHP unit and they're gonna run away from you. That's my experience. So as of 5th of September this year the night watch gonna be in a core. And what you can do you can actually go and install Drupal 8.6 core. I did. Here it is.  Look what we got here. You got night watch. And they even wrote some commands like Drupal install, Drupal log and end and Drupal relative URLs. So there's already a start point there. So if you're thinking about contributing to Drupal have a look in this folder and they read a bit of the commutation there. So it's interesting. It's all written ES6 as well, which is good. All of my tests still running like old school JavaScript. But yeah, this is how it looks at the moment in Drupal 6 core. So comes 5th of September it's gonna be up and stable. So you can actually put it in your, if you read the documentation you can put it in your module file, your theme file and start putting the night watch scripts like the one we wrote before straight. Right, any questions about Drupal 8? Good. So should we write more tests? Yes, let's do that. So let's see, like for example how about we'll check if the get ticket button is there. So let's do that. I already wrote some tests but I'm gonna, can everyone see that? Probably not, right? Is it fine? What did it do? Doesn't assume, does it? Let me do it this way. So that's the function we wrote, right? So let's see what night watch can do for us to actually make it testable the click button. So we not only need to test the button we probably need to click on it, right? So let's write Drupal Camp Singapore by button text. Everyone's happy with the name? Sure, okay. Just let me know. Cause, you know, the artifacts like test logs they're important. So when you manager look at it they don't see some gibberish they actually see, ooh, we have a buy button and it is working. There is another talk I did in one of the Drupal cons. You can check it out. It's more focused on managers and how to sell testing to managers. And it's all about night watch as well. So I'll provide the links there. Anyway, so let's go to actually Drupal Camp Singapore website. Here we go. Let's see. What's there? So this is the usual thing I would do for testing to actually go and expect. Ooh, I got a div with buy ticket. Whoa. So copy that. I got buy ticket clone and buy ticket. Seems like it's the only class so it's fine. So it's buy ticket and then there is directly a tag. There, right? So what I'll do, sorry for jumping too much. So what I'll do, I'll go browser, wait for element visible. So I'll just copy that. And then I'll go and say, oh, please now it's green. Excellent. So let's wait for element visible and then we have a command called click. So we're gonna click on it and provide the same thing. Great. So and then another page should appear. So maybe we should do exactly the same as we did in the before test. So we're gonna do that. And here's our test. So we're gonna go to, so this file called to more tests. I'm gonna replace all the previous tests, except the first one because it works here. So here's our second test, buy button test. And let's run it. So we're going into our cloud. Waiting and waiting and waiting. Who wrote tests for Selenium before? Like using web driver.  What did you use just direct Selenium test in JavaScript? Yeah, so how long would it usually take you to write? Well, the test, yeah, for your project, for example. Okay. So you didn't have any issues where you would spend maybe 50% of the time coding and then 50% of the time writing test. Fair enough. We're actually having an issue. So it says buy ticket not visible. I waited for 10 seconds. That's what we have in configuration. So any ideas. It's always good to test it. Yourself, but if we'll test it ourselves that's what we just did, right? So we went to the browser. We checked it all, the button is there but we can't see it. Maybe we should go cause Selenium records it all. Sorry, so slept. Anyone noticed stuff before? Who's gonna be first to notice stuff? Who said it? Well done. So it's actually using mobile button, completely different button. Cause we didn't provide the, you know render it in 1080p on the latest Chrome browser. We provided some Asian window system and the mobile menu is there. And if you actually go and have a look, so inspect mobile menu, you can see class toggler here. But if you look at get tickets, it actually uses buy ticket clone. It hides the other button and the test actually succeeded. So the test was correct. We just provided the wrong thing. So if we'll update our test with here at the moment. I mean, you would actually go and put the normal browser in and your test should succeed but because we have time restrictions and all that, it's a good idea to put this selector in a variable as well. And maybe let's see what's happened when we click get tickets and maybe instead of that, let's see what title is gonna appear. So it goes to Eventbrite and it gets this title. So I'm gonna paste this title. So our test gonna look like that, right? So wait for element visible, click and assert the title and see if that's gonna work for our current setup. So a few things you'll see when you're doing the test for Nightwish. For example, you'll never see it's telling you about clicking. So the click kind of silent. So you can extend Nightwish test with your own commands. And the two commands I was using on all projects pretty much, one of them called log and another is click log. So all log does is logs stuff for you like to the screen. So while the test is still running, I'll show you the log command. So first the configuration file that I said we don't need to look at. Here it is. And here, apart from the source folder for the scripts, we would also have a, it's actually couldn't connect to Selenium. Might have a connection problem. So we are going to connect to Selenium. So we also have a custom path for the commands. And at the moment here, it says that miscellaneous command. So if we go to this particular folder, we can see there are two functions, log and click log. I wrote them, the log is pretty simple. It just returns console log with a blue information thing, really. A quick question, previously the test was failed because people mentioned it's because of the mobile. Is it means that the night watch is actually? No, it means that source less setup by default uses Firefox on Windows 7. That's all it means. If you would use it locally or in, for example, Chrome setup, Chrome would use the latest version of Chrome. I'm not sure about the resolution because I actually ran into those issues two days ago when the resolution was by default small or maybe it's just a browser that converts menu into mobile. Yes, yep. So the configuration file here, it's a default environment. So you can set up default environment, Chrome 64, Chrome 64 at 100 pixels, Android mobile, and you can go on and on and on and on. By the way, don't write this access key. I still need it. Yeah, so default is just a default environment, but you can set up the environments, the one you specifically want to target and provide the either. So for example, if you're gonna run it locally, you're gonna have different nodes. So for Firefox and for Safari and for the Chrome and for Edge, you would send it to a different executables, which you're gonna define. So for example, these are settings for defining the Chrome driver, Edge driver and Chrome driver. Yeah, but yeah, so you would set up some things and there are blog posts again, how to set up resolutions as well. And I saw a few people trying to change the resolution in the same test, but I think it's a bit hacky in my perspective. But apparently it's possible as well with the Selenium. Okay, so a few more things. So again, log and a click log just uses log and uses different format of the test, which I copied from one of the core Nightwish stuff. And all it does is basically says clicking something, right? So if we would test those two things, so click log here instead of click and maybe just log to see what log does. Say hello, triple camp. Okay, let's run it, see what's gonna happen. And you saw before the connection, the previous time it failed, the connection with Selenium couldn't be established. So it might be connectivity issues, but you occasionally would get those on the local setup as well. So Selenium is a bit like they working on it heavily. And yeah, you might find yourself in a very interesting situation where it might end session before finishing all the tests. So you need to get a bit of a trickery in configuration on the way you finish in your sessions. So it depends on the setup as well. So you can see it says hello, Drupal can Singapore and output and then it actually, instead of click, we use my function which overrides click, click log and says clicking.byticketclone.a. So you can actually extend your commands and that's exactly what they did in Drupal core. So again, if you look at the web core tests, Nightwatch commands, you can now jump in and as an expert, have a look what they didn't have done. It's quite interesting. They're not massive, so you can actually go on search. So any questions about extending and writing your own commands for Nightwatch? All good. Right, let's wrap it up. So as I said before, you can expand the Nightwatch not only with commands, but with the other services as well. There is a great pause from previous next from last week, I think. So they actually use a service called ashexie to extend the Nightwatch and the past accessibility testing using the repo Nightwatch accessibility. So the link is there or if you type accessibility Nightwatch there's only one post on that from previous next. Have a look at them. But you can actually use other services with Nightwatch. It's quite an active development as well. So this is the accessibility testing tool I never used to do for myself. So I'll just give it to you if in case you would need accessibility services, accessibility testing. And I would really, really, really again advise you to go in and contribute to the documentation test. If you don't know what to contribute, try to develop something and see what's like in documentation. And then just go to documentation, click edit and place the header, for example, extended Nightwatch for Drupal Core, TBA. So for people who actively contribute to the documentation that's a good sign what people needed. And because now you cannot leave the comments in the documentation, just communicate some other way. I know the documentation for Drupal 8 is not up to scratch in development one as well. It's getting there. I'm contributing on migration and planning to contribute to the Nightwatch. So if you think of something, I don't know, do it on Twitter, but do it on Drupal.org as well. Because we need your input as well. We need to know what people need, what they're lacking in the current documentation. So here where it is, just type testing in Drupal 8. And one of the links below would be types of testing in Drupal 8 and Night, which is one of those. A few tips to wrap it up. So for automated testing, I would recommend spend up to 30% while I ask the question about the writing test directly for Selenium. I had a project where we would spend up to 50% of the time because it would just ridiculously slow to actually debug the test. So make sure your time box yourself but also don't fall in a trap where are we gonna do test later? That's like number one answer, I think from all the managers I've been talking to. I will do it later, it's not important. Make sure you spend at least 10%. So between 10 and 20 is very good. If you can't stretch it up to 30, if your budget allows it to, and if your project needs it, so it's not one of project you know which you released and dropped it, but something that's gonna live for two plus years, definitely spend more than 20% on testing. Doesn't matter which one. But people ask me, do we need to do the full coverage? How long is it gonna take to actually cover the whole project? You don't need the whole project coverage. I had 10 tests and when Drupal 8.4 was released. So jQuery was updated to jQuery 3. It broke, dropped down menus for Bootstrap 3 theme. What else was there? The views broke. There was some relationship issue in views and there was something else. So three bugs I detected within just by changing the version of Drupal and sending it to my CI. So yeah, it's not 100% coverage. It's actually the crucial bits of your project that you really need to concentrate on and test. Even if you're just trying to create the node, as simple as that might give you enough insight. So jQuery version changes, your tests were failing, but how was that? How tests was failing? Because you identified how was your opening? No, no, I would go and click and wait for the menu to appear and because drop-down functionality was broken, the menu would never appear and tests would be broken. So do... Sorry. So in order to make your menu appearing, so you do the same thing, like every time you go to buy what was the part of it. So once you get something broken, which was working before, you start looking at what you actually updated. And yeah, so and then just trying to figure out what's actually was broken, what's not. Yeah, so that's pretty much how we did it, but we found three bugs before even updating to a Drupal 8.4. So any more questions about that? No? Okay, so we're gonna conclude, but before that I'm gonna jump on one of my projects, just an example. It's not the biggest one, the biggest amount of tests, but I'll just show you the setup. So tests. So here's the test, right? So they correlate directly to a user storage and if you look at the videos I would provide the links for, you'll see the tests correlate directly to a user storage. So for example, this one, as an anonymous user I want to see homepage with the header and footer as on the current SOQ website. When go to this particular URL, so very simple task, but then they go deeper and deeper and deeper and then we start logging in as a separate users and creating by just a, so this is number of tests actually, they're half of them are empty. I just asked my team to do that because they weren't priority, I would spend too much time on actual tasks, but half of them are still operating. So when I go to my GitLab account for this particular project, I can look at my CI and part of the CI is actually installing the Drupal at the moment it's all linked together. So get independence installing Drupal and running tests, but you can see I can go and see which tests are running which tests. And also some of them are quite big. As a content admin, I want to be able to add file, title, description, text when I'm creating, editing, new document media item, right? So it correlates to the story. So now I can grab the title, can go to my project manager and say, here's all the tests I actually wrote tests for. Any questions about tests and running in GitLab CI or other CI? All right, let's wrap it up then. So in the conclusion, again, to do an automated testing, we need two things, we need test runner and a browser automation tool and a test runner called, thank you, and the browser automation tool called, excellent. So, and why do we need them? So they're JavaScript based. Again, try to, if you want to get rid of all your front vendors, teach them PHP. And if you still got half, teach them PHP unit. Or just give them night watch and the error can write the actual tests in JavaScript. Night watch open source and free, you can contribute to it. Will be in Drupal 8.6 core and additional services available like source labs and browser stack. So as I said before, why do we need it? Discover bugs early, test upgrades early. And by upgrades, I don't mean just night watch upgrades and Drupal upgrades. Don't forget you have PHP 7.1 to 7.2 updates. Or if you're still running 5.6, the time is a pressure now to move on to seven. That's all can be done using a night watch test as well, making sure just like what I do, I change the containers, send it off to the cloud, get a report if it's actually doable for me to upgrade to 7.2. Maybe Drupal isn't working. Maybe PHP isn't working. Maybe my SQL isn't working. Something might be broken. So this setup will allow you to actually do that and test it. And again, you get awesome artifacts, text report and coverage. You can set up Selenium to do screenshots for you or you can outsource it to those cloud tools. Again, cloud tools also record your video of your tests. Any final questions? Yep. So we went very crazy on one of the first projects we were running in. It would take 40 minutes. So I'll, oh, might actually get some here. Yeah. So just an example of a pipeline. So you get the idea. So we went very crazy. So apart from the tests, which were here, you can see Selenium 3.7, we would also have LinkedIn and Drupal installation and then checking the Composer and Drupal security updates. Which again, the longest part would be running the actual tests and it would take up to 40 minutes. So you go push your code in. So eventually we decided, okay, don't run over the whole code base. We divide the core tests. I would take on average 10 minutes. It's a good time to like maximum good time to run core tests. If you're getting over 10 minutes on overall pipeline, cut something down. Another thing is this project would have three massive workflows. Where document would go into 20 different stages, shifted between six different user roles. So it was a big project to test. And because we were writing tests as stories, eventually lots of tests became duplicates of each other. So the first test would go and check if the author can send it to an owner. And the second test would go owner to send it to a manager. But because we made tests independent, it would go create a document, send it to an owner, login as an owner, owner would send it to a manager. And eventually it's snowballed. So then we would just say, oh, why don't we kind of write a document function, send this document to this stage and then test what you need. So refactoring is a big thing. Again, once you hit 10 minute mark on your CI, review your stuff, see if you can wrap it up, cut some stuff in by using specific commands. So for example, hashtag run all tests would run the whole 40 minutes of CI, but without this hashtag, it would just run, you know, five core tests like that it can log in, it can create a document and maybe can do something else. Yeah, that's what we did. It kind of optimized it, but yeah, it was still like full on release, just testing would take about 40 minutes. So yeah. And especially if you have juniors, all juniors do is, sorry, all right. See it and twiddle the thumbs. Sorry for the sound effects. Any more questions? That's it then. Thank you very much. Test more, test often. I'm gonna be sending the slides and yeah, so you can go through all the links and the videos as well. The slides of the Lachigo and Closing stuff happening in the...


Hey everyone, it's Gabrielle with Oxmerotic Group. I'm here today at Oxmer Toyota for our Facebook use vehicles of the week now this week I've picked out three vehicles. I'd like to share with you guys. Let's go over some information on this first one now This is a 2016 Jeep Wrangler Sahara So the exterior color is called bright white clear coat. So the vehicle is the 75th anniversary edition The vehicle was locally owned so it's super clean on the exterior and on the interior and this one also is a manual transmission So super fun to drive Interior is a black the mileage on this is 44,099 the price is 26,699 now moving on to our second one This is a Certified pre-owned 2019 Toyota 4Runner. This is a TRD off-road. It is a premium So the exterior color is in a magnetic gray metallic. The vehicle is four-wheel drive There is navigation The interior does have leather seating. There's Bluetooth backup camera The vehicle does have what's called the wilderness package Had one previous owner and there's a clean car fax the mileage on here is 4,256 the price is 37,995 for our last vehicle. This is a certified pre-owned 2019 Toyota 4Runner TRD off-road Next year color is in a classic silver metallic This vehicle does have 17-inch alloy wheels. So this one was actually a retired service loaner It is four-wheel drive vehicle has four-wheel. I'm sorry navigation. There's a backup camera sunroof There's heated leather seating on the exterior There was predator tube steps and the vehicle does have a clean car fax So that interior you saw was black mileage on here is 5,771 and the price is 36,619 if you guys have any questions on any one, please feel free to let us know Best of numbers<PHONE_NUMBER> also make sure to check out our new express or which is on our website at oxmartoyota.com I'll have a link to each one that I just went over in the comments. Thanks guys for watching and I'll see y'all soon. Bye


Hello there everyone and welcome. This is Melissa Armo with the Stock Swoosh and I'm here reviewing the Stock Swoosh 2018 trade room tracking We'll go over here if you have any questions You can feel free to call me at 929-3200 gap or email me at Melissa at thestockswoosh.com Remember this is about empowering yourself to trade the market you you alone can do it When you come to me if you do my golden gap course You will be eligible to join the live training room and receive all of these calls, but you learn everything in the class I don't hold anything back that you could do to trade by yourself So going back here Start off to the year January 4th lb was a winner 5th bks was a winner 8th play was a winner Dks was a loser everyone was a loser a yi was a winner one thing you'll notice is many of the days It's only one ticker symbol one trade Uh, we usually if I start out and there's a loser at the beginning of the morning I I do a second gap, but in an ideal world you only have one trade one play a day with size And that's the way to do it. It's the focus January 10th svu was a winner the 11th no trades gme was a winner in the 12th room close in the 15th 16th 5 was a winner ibm was a winner no trades on the 18th. Nike was a winner in the 19th January 26 s a n m was a winner 23rd no trades uil was a winner and wl was a winner intc was a winner in the 26 really was a good start to the year 29th So who was a winner met was a winner juniper was a winner ebay was a winner apple was a winner to start out february And then some days there was no trades because there's nothing that meets my criteria Again part of the focus February 5th no trades swks winner cmg was a winner.  That's fantastic and 48 winners. So win ratio of almost 80 79 If you want to learn my method how I figure out all these picks how I find the picks how I take the entries I teach a class. It's online It's a full two-day course in how to strategically find pick and play stocks that are professional bearish gaps Classes online can be anywhere in the world and take it Class tuition is 54 99 dates are april 14th and 15th 9 to 5. That's the class for april And it is a professional bearish gap system If you're interested email me at melissa at the stockswush.com if you want to sign up It's going to be a great second quarter for 2018 looking to continue all the great calls And very excited about the rest of this year for many many reasons


Good morning, everyone. Thank you very much for coming today. My name's Alex Sika, and I'm a product manager working on web payments. Hi, I'm Ruslan Solmokin. I'm an engineer on the Chrome payments team. Today, we're talking about how you can provide your users on the mobile web with an amazing checkout experience. I want to start with talking about mobile commerce a little bit in general. It probably comes as no surprise to anyone here that a majority of traffic is coming on mobile devices. What is surprising is that if you look at all mobile purchases, 66% of these are happening on the mobile web. So it's imperative for you to create an amazing mobile experience if you're going to engage with your customers. In recent years, we've seen a ton of improvements to mobile websites, better, more responsive design, better mobile optimization. But these improvements haven't really translated into what's important, which is increased commerce conversion. So how far does mobile have to go to equal the kind of conversion we see on other platforms? Turns out that the answer is actually pretty far. In fact, consistently across the web, we see mobile converting at about 66% lower rate than desktop. This means that every visitor to a desktop site spends about $3, and every visitor to that same site on mobile only spends about 1. Why is this? Before I reveal our thought, I want to ask everyone a question. So I want to see a show of hands. How many of you have ever abandoned a purchase because of the checkout form? Pretty common problem. So this question actually kind of gives away our thesis a little bit. But we think the fundamental reason why mobile is lagging so far behind other platforms is this checkout form. There's just no getting around the fact that on a small mobile screen, it's an incredibly painful process to have to tap through a checkout form. Yet the checkout form today is still the predominant way that we engage with our users and collect payment on the mobile web. So let's talk a little bit about checkout forms. They've gotten a lot slicker since we all ordered our first packages online 20 years ago. But what hasn't changed is I still have to manually type in the same information, my address, my shipping address, and my credit card information. So it's incredibly manual. It's also incredibly tedious to have to do this on every subsequent website. You have to type in the same information on every website. Third, checkout on mobile is slow, especially in areas of low connectivity. And as we've seen in some of the sessions talking about the web this week, if it takes more than a few seconds to load a page, there's a very high opportunity for your users to bounce. Yet it's still the norm to put them through a multi-step, multi-section checkout process that requires lots of taps to complete. So before we talk about how we're trying to tackle these problems and the products we're building to solve checkout on the web, I'd like Ruslan to talk a little bit about what our overall design philosophy is. Thank you, Alex. Today we're going to show you several demos of how we're going to improve the mobile checkout experience. Throughout our work, we concentrate on two core principles. First, from the standpoint of the user, we want the checkout experience to be as seamless and painless as possible. If you type in your credit card in the web browser once, you shouldn't have to type it in again. You shouldn't have to type in your information into every website on the internet. Second, from the standpoint of the web developer, you should be able to get all of the information that you need to complete this transaction as quickly and frictionlessly as possible. That means whatever solution we come up with should be straightforward, and it should be able to integrate into existing products in solutions. So you see speed is very important to us, and we will address this during our demos. So keeping in mind these two design philosophies and also keeping in mind that checkout forms are still today the predominant way of collecting payment from a user, we started thinking, how can we make this experience more pleasant for our users on the web? The answer is with Autofill. And Autofill is a pretty basic function that's been in Chrome for quite some time. And the way it works is by when you tap on a form, you can automatically fill any information that you've saved to the browser into that form. The best part about Autofill is that it just works. The web developer, the site doesn't have to change any part of their code. They can automatically fill the form with any user information that the user has securely stored within the Chrome browser. So going back to our checkout form here, we can see that the first real issue is that it's manual. And Autofill solves this by being able to save automatically your information and fill it in without you having to enter a keystroke. Next, it takes this tedious process of having to fill out a checkout form on every new website, and it makes it simple. So this is a real win for users. It really enhances the user experience as I'm going on a mobile website and filling out my information. But what does this actually mean for you? What does this actually mean for sites? What does this mean for developers? We recently conducted a study with the Chrome research team, and we found that Autofill actually drove a 25% increase in conversion rates. And this is extremely powerful because you don't have to modify your site at all. If a user comes to your site and they have Autofill enabled, they are 25% more likely to complete the checkout form. So how does Autofill actually work under the hood? The process begins when the user saves the information into the browser. This can be done either manually in settings or automatically when the user fills in a form. Next, Chrome will securely synchronize this information across all of the devices where the user is logged in. Finally, Chrome will automatically detect the forms on the web page and fill them in for the user with minimal user interaction. The primary component that makes this work is the Autofill server, because form detection works through a combination of client-side heuristics and server-side modeling. This is one of the areas where we have been making great improvements. In fact, today, we have over 95% accuracy for form detection for the top 100 e-commerce websites. The best thing about Autofill is that it requires no integration from the website developers. The Chrome does all the work for you. In the rare cases where Autofill does not work, we do support autocomplete types to guarantee Autofill and get that sweet, sweet 25% increase in conversion rates. OK, so let's slip over and see a demo of Autofill in action. So before we see the actual demo, I want to say we've actually collaborated with the Polymer team to create a really awesome site experience that we're going to be showcasing here in addition to Autofill. So I'm going to tap in here to my shop. And again, this is the Polymer part of the Polymer toolkit. It's the e-commerce shop experience. And since it's so much colder this morning, I'm going to shop for a little men's outerwear. This neon, what do you think, Ruslan, about this nylon jacket? It'll look good on you. So I'm going to add it to my cart. So I want to point out that up until this point, it's been a really amazing experience. Got to browse an amazing catalog of Google products. But I now encounter the part of the e-commerce experience that I dread. I'm going to have to fill out my entire credit card information, my shipping address, and my billing address. There's got to be a better way. As you can see, this is a pretty nice design form. But it still doesn't get around the fact that I'm going to have to manually type this in. But as you see with Autofill, I'm able to tap into the form and automatically fill in my information. It immediately is filled into the form. And if I happen to have a separate billing address, I could also fill that in. And then finally, just like the addresses are securely stored, my credit card information is also securely stored with the browser. So I'm going to fill in my MasterCard here. Now, the one piece that Autofill doesn't save is the CVV of your credit card. So for security purposes, you're still going to need to enter this into the site. So you see I placed my order. It was done. It was simple. Let's flip back to the slides. Great. Autofill is amazing. This is a product that I use myself almost on a daily basis. And it really simplifies the process of going through a web form today. I also want to point out that we're continuously launching improvements to Autofill to make it faster and more available to more users on Chrome. But Autofill, again, is tied to existing form infrastructure. We use web forms as essentially the tool by which we're passing the user's payment and shipping information back to the website. So because of this, there are some key limitations. First, we can't solve the latency problem. We can't make the page load faster with Autofill. And secondly, as you saw in the demo, it still takes multiple sections, multiple taps to get through a checkout process and actually submit my order. So going back to our two design principles, we wanted to start thinking beyond Autofill. And it led us to the idea that maybe the best way to solve checkouts was not simply to improve on the checkout form, but to actually completely eliminate the checkout form. So I want to go through a quick exercise here. And I want everyone to close your eyes and imagine a world without checkout forms. This isn't a rhetorical exercise. I actually want everyone to close your eyes and just imagine a world without checkout forms. So what does this mean? For users, this means that when I find something I want to buy, I can just tap and buy it. I don't have to go through a complicated process of re-entering all the same information. What does this mean for sites, for developers, for merchants? It means that you can focus on creating an amazing and engaging experience for your users and not have to worry about creating a checkout process, not have to worry about optimizing that checkout process. We're really excited to bring you the Payment Request API, which is the way that we're going to make this formless world a reality. Payment Request is a JavaScript API that allows the browser to handle the heavy lifting of payment collection. The result is a simple one-tap experience for the user and an easy way for a site to receive and request payment. Our goal with Payment Request is to create an open API. So no matter what browser, what device, what platform, or what payment method you choose, you'll never have to enter another checkout form. The Payment Request API is currently under development in the W3C Web Payments Working Group. Our goal is to create a universal cross-browser standard for any website to accept any form of payment. There are three key points to keep in mind when thinking about Payment Request. First, this is not Chrome-only, Google-only, custom-provided API. No. This is a cross-browser, standards-based effort where we are collaborating with other browser vendors and members of the developer community in order to define something that any browser should be able to implement. Second, we're targeting mobile platform first, because this is where we can solve the biggest problem. But the Payment Request API is designed to be extensible and will be available on other platforms as well. Third, our goal is to create an open ecosystem. Any website should be able to accept any form of payment that they desire without the need for complicated custom integration points. So we're excited to announce that Chrome has an implementation of Payment Request today for you, the developers, to try. We expect other browsers to be implemented soon. Shout out to Microsoft in particular. They have been a great partner in the W3C Web Payments Working Group. So let's go back for a second to our checkout form. So just like with Autofill, we take this manual and tedious process, and we make it simple. In fact, in our implementation that we have, that we're going to show you today in Chrome, we actually are using the same data that the users already saved to the browser through Autofill, and we're exposing that data to the Payment Request API. But what makes this even faster is that rather than relying on the checkout form, we pass it directly via this open API. We're also able to reduce latency because Chrome is rendering the payment collection UI natively. So you don't have to render a complicated checkout form that takes several seconds to load. So Payment Request is extremely fast. What this all amounts to is taking a multi-step, multi-section, long checkout process, and makes it truly one tap. Let's take a look at how Payment Request works. The process begins when the website passes to the browser information necessary to negotiate this payment. This information includes, for example, how much is being charged, what is in the shopping cart so the browser can present it. Most importantly, this information includes what are the accepted payment methods on this website. The browser then determines the intersection between the website's accepted payment methods and what the user has installed on their device. The browser presents this UI to the user where the user can select their preferred method of payment and authorize this transaction explicitly. A payment method can be anything as simple as a credit card stored in autofill or a third-party application that you and I can write that would provide the payment to the website. Once the user authorizes the transaction, Chrome invokes this payment app, gets the response back, and passes it directly back to the website from this standpoint of the website. The only thing that happened is a single JavaScript call that retrieved all of the information that the website needs to process the transaction. Let's actually take a look at the code of how you would implement this. The W3C members are working really hard to make this API as simple as possible while still passing in all the information required to negotiate the transaction. The code that you see is how it is implemented today in Chrome developer version. The W3C is continuously evolving this API based on the feedback from merchants and website developers. So please participate in the process and give us your feedback. We would appreciate it. There are several parameters that you need to specify for payment requests. The first two are required. The first one in particular is the list of payment methods that this website accepts. For the legacy case of credit cards, which is what we're showcasing here, you would pass in the credit card types. The second parameter are the shopping card contents and possibly the shipping options. Finally, we're showing here the third parameter, which is optional, which specifies that this website is indeed selling physical goods and would like to request the shipping information from the user. Remember, our goal is to pass in to the website all the information that the website needs to process the transaction. And one of the most common pieces of information that the website needs is shipping address for the user. So the website would use this request ship on true parameter to specify that they do, in fact, need the shipping information, and then they have the option of updating the total based on the shipping speed or the shipping address that the user has selected. So yeah, let's actually see how it works. So let's flip back to the phone and leave the code up so we can walk through what's happening as we go. So I'm back on my Polymer shop, but we've implemented this relatively minimal 15 lines of code to include a call to payment request when the user clicks the checkout button. So I'm going to come back into Men's Outerware. And this time, I'm going to buy this nice YouTube hoodie here. I'm going to add it to my cart. I'm going to view the cart. And then again, we get to my least favorite part of the e-commerce experience. I'm about to check out. I'm about to land on a long, complicated form. But now that we've implemented payment request, Chrome is actually going to natively expose a UI where I can select all of my billing and shipping information. So there it goes. See how fast that was? Zero latency, no loading new pages. Chrome natively services this UI where I can select my shipping and my payment information. And again, this is the same shipping and payment information that we previously used in the Autofill demo. But now it's available within this nice Chrome UI. So talk about a little bit about what's going on with the top row here, Ruslan. Sure. In the top row, the user sees the identification information for this website. This information is the title of the website, some iconography from the website to make sure the website can be easily recognizable. And for security purposes, the origin of the website, where the user can make sure they're indeed passing their money into the right hands. The total information comes from the website. This is the shop end card. The shipping and the payment is something that's most frequently and recently used by Alex on his phone. So this is smartly selected. But if Alex wanted to change his shipping address, for example, he could tap in and change the selection if he wanted to. So let's go ahead. OK. So the only step when I click Pay, because our goal is to return everything the merchant needs to process the transaction, the merchant presumably needs the three-digit CVV. So just like with Autofill, I'm going to have to enter it here in this minimal form. And I click Continue, and it automatically returned it to the website. The other thing to note about this interaction is that the response that you get back from the web browser when you invoke payment request is exactly the same as the response you'd get back when your web form is submitted. So we're really trying to simplify this so that we're really trying to take the process of implementing a web form and really encapsulate it in this nice native Chrome UI. So let's flip back to the slides. So you've seen how easy it is to request credit cards. And again, all of the credit cards that are available in Autofill are also available via the Payment Request API. But one of the most important features of the Payment Request API is the ability to support other forms of payment and other more secure forms of payment, like Android Pay, will now be available in the browser via the Payment Request API. What makes the Android Pay experience even more seamless than traditional credit cards is that rather than passing the actual credit card number, we pass a secure tokenized representation of the user's credit card number, and we use device authentication to further protect your transaction. This means better security for the user, and for the site, your users get a much more secure, easy checkout experience. So when we launched Android Pay last year, we had a really ambitious goal to make it everywhere. But obviously, we can't call Android Pay an everywhere platform if it's not supported on the mobile web. So as you've heard earlier, via the Payment Request API, we're now bringing Android Pay support to Chrome. And so you're probably thinking this is going to be a really complicated integration. But actually, it's just a few lines of code that you add to the Payment Request to be able to request and bring all the security and simplicity of Android Pay to your mobile website. The reason why it's so simple to add Android Pay integration is because Payment Request is designed specifically to be extensible to work with any payment application out there. So the first thing they need to modify in your existing Payment Request call is to specify the identifier for the payment application. In this case, it is android.com slash pay, which identifies Android Pay. Next, payment applications might require some extra information. So in this case, the demo that we're making is integrated with Stripe. And in order to work with Stripe, Android Pay requires us to tell Android Pay that it is, in fact, the Stripe gateway that we're using. But you might be using a different one on your own website. And for Stripe, there are two pieces of required information, the publishable key and the version of the Stripe API that you're using. So while we're showcasing Android Pay here, it is important to remember that the changes to your payment request constructor to support new payment applications is going to be essentially the same. You're going to add another payment identifier. And if the app requires some extra information, you add it in the last optional parameter. Great. So let's leave this code up, and we're actually going to go back to our Polymer demo site one last time and show you with this easy integration how we can now accept Android Pay on the web.   No more authorware for you. I don't need any more outerwear. And it wouldn't make sense for one of the first Android Pay transactions on the web to buy anything other than this Android Pay T-shirt. So this is what I'm going to get today. So I'm going to add it to my shopping cart. I'm going to click Check Out. And again, you see this Chrome UI renders just as quickly as before in the case where we were requesting credit cards. But now it's actually with Android Pay. So this is really cool that with just those few lines of code, you're able to now bring the security of Android Pay into the browser. So what's going to happen when I press the Pay button is Chrome is actually going to be making a request to the Android Pay APIs on behalf of the website. So for security reasons, Android Pay is going to surface just a very simplistic UI where the user is going to be able to authenticate with their device unlock. So in this case, I'm going to show my fingerprint. So now Chrome is communicating with Android Pay. And Android Pay is going to surface this nice UI where it gives me the option to pay with my MasterCard. I'm going to authenticate with Android Pay. The response is going to be returned back instantaneously to Chrome. And Chrome's going to then pass it back to the website. Now they have everything they need to process the transaction. So one of the really additional cool features about Android Pay is that it has this notion of rich receipts. So as you see here, this is a live transaction that's taking place with the Stripe account that Ruslan has set up. So you can actually see that that shop with my MasterCard was actually charged $8.99. So this is a real live transaction that's taking place today with Android Pay. And if you were to click into the Android Pay experience, you'd be able to see all of the rich receipts for all the transactions you've made in store via your NFC terminal or in Android Pay apps. It's all together. Anytime you use Android Pay in store, in Android applications or on the web, all the receipts show up in the nice Android Pay interface. We are excited to announce the payment request is available for developers in Chrome today. It's going to be available in Dev and Beta versions for now until we release in stable version of Chrome in late 2016. And in 2017, we expect to be able to integrate with third-party payment applications and to come to other platforms aside from Android. So today, if you were to go and do a payment request in the Dev or Beta channel of Chrome, you'd be able to access all of the credit cards that are currently stored with Autofill. And it's really an amazing experience. We're also really excited to announce that with our stable launch this fall, we're also going to be bringing the Android Pay support you just saw into the web browser. So we're really excited to continue bringing these first two implementations into payment requests, but there's so much more. And next year, we're going to continue to work to grow the ecosystem of payment applications that are available through payment request. So our goal in developing this API, we really want to get it into your hands as quickly as possible. That's the only way we're going to be able to provide an amazing experience for our users is getting you the ability to test this API now. We're really excited to announce that we're already working with these amazing partners to make sure that payment request and our Chrome implementation of payment request works across a variety of mobile web use cases. I actually want to showcase one of these use cases today and show you what the payment request experience would look like on Shopify's mobile website. We're really excited to be testing with Shopify. In fact, they've already started sharing their insights with us, and they have some deep insights about mobile purchases because they work with thousands of online retailers. And so they've shared their feedback with us, and they've shared their feedback with the W3C to really help improve payment request and make it better. So we really see this as an evolving standard. This is not a fixed product that we're implementing now. We really would encourage you to provide us feedback so we can develop this together. Please visit the Google Spaces app to stay connected. We will post the video of this talk there. We will also post the link to become a beta tester in there as well. We want to remind you that this is an open standard. We would love your feedback on the HTML spec. Everything is available on the W3C GitHub page. Please go ahead, read through the spec, browse through the issues we're discussing today, open another issue if you have a suggestion, or if you have a concrete suggestion, go ahead and write a pull request on GitHub. Everything is public, and we take your opinion very seriously. And Ruslan's actually made the generous offer of anyone who implements payment request. He says he'll come buy something from your store. That's right. Go build something, and I will buy it. So thanks again. I'm Alex Sika. I'm Ruslan Selamaken. Thank you.


and welcome to HealthFocus, a production of the Ministry of Health and Wellness. I am Fenel Neptune. Every year, St. Lucia joins in celebrating vaccination week in the Americas and of course, it is important that we place a focus on vaccination. Today, we have with us the Assistant Principal Nursing Officer, who's also the Immunization Manager, Tecla Jabatis, who will speak with us on vaccination. Welcome to the program. Thank you. Before we go in depth in the conversation as we list the vaccination, can you tell us what are vaccines? Vaccines really are either killed or weakened from the virus or bacteria, which when given into the body, actually trains the body to respond to first identify the virus or the germ and then respond to it if the body becomes infected, if the body, if someone becomes exposed. Because as you know, we live in an environment and we get exposed to bacteria, we get exposed to germs because it's all around us. So when somebody receives a vaccine, it creates sort of a memory. So the body remembers that germ or that virus. And if the body were to encounter it again another time, then the body would respond to it. And all of that is to help prevent us from getting sick or even dying in the whiskey scenario. Okay, so you mentioned a little bit as to how the vaccine works in terms of it getting into the body. But why vaccination, the process of vaccination so important for us here in St. Lucia? Vaccination is very important to us. Vaccination is probably one of the most cost effective public health strategy, one of the most effective preventative strategies. This is very important because for many reasons, one to provide that protection of our citizenry, of our population from infectious diseases that could cause increased mobility and mortality, death and illness in our population. Of course, you know, with increased death and illness in a population that raises your burden of disease, all of that too can have implications on our economy. St.  This risk is always there. And it is important that persons are immunized to protect themselves and of course the population at large from these infectious diseases that could be very detrimental to not just us but the economy and the whole. Okay, so you spoke in terms of how it helps with the economy as a whole. But we know vaccination has been around for quite some time. Can you speak on the history? What are some of the challenges and successes for St. Lucia as it relates to vaccination? St. Lucia's immunization program started way back in 1977. At that point, very early in the program when it started, we started off very, with just a few vaccines. At that point as a matter of fact, it was just BCG, DPT and polio vaccines that were administered. But as the program grew over the years, newer vaccines were introduced. First with measles and then you had the measles containing vaccines like the MMR. Today we have had many other vaccines introduced into our program. Some of the later ones include the hepatitis B vaccine which is given at birth and also the human papillomavirus vaccine that we introduced to our grade six boys and girls. All of this as a cancer prevention strategy. The program has grown over the years. Initially when the program started, we saw coverages of about 40%. But over the years, we've seen significant increases of vaccine coverages up to the recommended 95% and over, especially in our primary doses. As anything else, the program does have its challenges and we continually monitor and evaluate the program year after year, identify our gaps, identify any challenges that we have, and put together strategies to address those challenges. For us in St. Lucia, our coverages in our primary doses, and I speak of our children under one year, we continually meet the recommended 95% and older. However, as the children get a little older, we note a decrease in the coverages. So the children over one year and over fives, you know, up to five years, we note that decrease. But I must say that it's a continuous improvement process. This has existed over the past, let's say five to 10 years. But over the years, we do see results of our efforts. So these coverages, which were down to maybe like in the 60s, 60, 70%, we see increases up to about 80%. So we are confident that persons in St. Lucia understand the importance of vaccine. They see the importance of having the children vaccinated. And of course, they are coming forward. We continue to track our defaults because it's very important that especially our under five population that they are covered and that their vaccination status is up to date. So we can definitely say, although there have been challenges, there have also been great successes with the vaccine. Definitely, definitely. And we've seen these successes. I mean, St. Lucia has not had a case of measles since in the 1980s. I mean, we don't see polio. And it's because of a successful immunization program in St. Lucia. That is why many of us, you know, we can't even identify, except if we see it in books and we see it on the internet.  Sorry, but I like you to hold on to that thought because we are due for a break. We'll be back in a moment. Tired of battling large numbers of mosquitoes in the comfort of your home? The more you fight, the more defeated you feel. How about taking on a longer lasting solution? Ensure that drums or buckets are properly covered after each use. Drain and dispose of any unwanted containers to reduce potential breeding grounds for mosquitoes. Do not allow tires to collect water on your property. Fill them with soil to make your own vegetable gardens or plant flowers.  Use secure bins when disposing of garbage in order to reduce mosquito breeding. Keep vegetation low to allow daylight in and remove hiding places for mosquitoes and other pests. Check your roof gutters regularly to prevent mosquito breeding. Regularly inspect your property for signs of mosquitoes. Following these tips once a week can reduce the population of mosquitoes in and around your home. For more information visit or call the Environmental Health Division at 468-3700 or 468-3737. Welcome back. We will continue our discussion with Nurse Techno-Javatis on vaccination. Before we took the break you were speaking on measles and vaccination for measles in St Lucia given that we've not seen cases of measles for a very long time in St Lucia. Can you speak on that and also speak on what other diseases are these vaccines actually protect against? In our vaccination program there are a wide range of vaccines that are offered all of which protects against some some sort of disease. For example we have the BCG vaccine. BCG protects against tuberculosis and we we have the polio vaccine which protects against polio, DPT against dipheria, pertussis, tetanus and hepatitis B vaccine of course which protects from viral hepatitis and the human papillomavirus which you know as the HPV vaccine. As I said earlier I would have alluded to a little earlier in the discussion it does protect against HPV which is a cancer-causing virus here. Okay so you've spoken about the different diseases that it has protected against but for some persons they might say is it really effective? Is it safe? Can you tell us speak on the safety and effectiveness of vaccines on a whole? As it relates to the safety of vaccines in St Lucia, St Lucia through the Pan American Health we depend on pre-qualification from the Pan American Health Organization and the World Health Organization for our vaccines and this has been from the time of the beginning of the vaccination program. Any vaccine that is introduced into our that is introduced to our population would have been pre-qualified for use by the Pan American Health Organization. It is on that basis that we know that whatever vaccines that we are introducing it is safe, it is of good quality and it is effective. I mean in terms of effectiveness I mean we have not seen a case of these infectious diseases, these vaccine preventable diseases in our population and it's all because of vaccination and an effective program as I would have alluded to earlier and of course we know the risk, we know there are still some vaccine preventive diseases that are still circulating and I go back to measles and we know we have lots of people traveling, we have lots of people coming into the island and we travel on whether it's business, whether it's pleasure and it is very important when travelers you know that especially if when we travel that our vaccination status is up to date so that we're not at risk of bringing in something into the country. Okay and with any vaccine there are side effects and how does the ministry go about actually monitoring those vaccines that they administer solutions? Yes so vaccines like any other medication does have side effects you know and when someone receives a vaccine it's not that they will but it's there's always that possibility that someone may experience a side effect and of course there are adverse events which is a more serious which is more serious and more and puts an a little and lasts a little longer sorry but in terms of side effects of course we continue to monitor there is a monitoring system when someone receives a vaccine they are educated they are informed at the point of care that if they were to experience any side effect whether it's a rash whether it's typing in the chest whether it's a fever that has persisted over over over two or three days a very high fever whatever it is that they're experiencing that they need to notify the healthcare provider they need to notify the healthcare provider notify the nurse it could be either them or family member once we have been notified of course that would that that incident or that event as we would call it is reported to the next level which is the immunization manager it is reported to us at the national level we would collect adequate I mean detailed information surrounding the event and of course that involves the vaccine etc once this is done we would launch an investigation by the investigating team and all of that is to ascertain whether there's any causality with the any association between what the person is experiencing and the vaccine so yes there is a monitoring system in terms of our general vaccination program we do not we rarely have any of any serious events except in you know the fever the pain in the arm etc very mild very mild side effects that would resolve in a matter of two to three days okay thank you so much well we definitely have come to the end of the program I want to thank you so much for being here and for providing us with such valuable information on vaccination thank you so much you're most welcome on behalf of the entire production team I am Funnel Neptune thanks for watching until next time


Singer-songwriter Jimmy Buffett, who parlayed his song Margaritaville into a billion-dollar fortune, has recently passed away at the age of 76. Jimmy was known for popularizing his own tropical vacation style of soft rock music, and his hit 1977 song Margaritaville became an empire of restaurants, resorts, and frozen fruity drinks. Seeing as that song is about a laid-back beach bum lifestyle, does it come as any surprise that Jimmy and his wife spent much of their life living in Palm Beach, Florida? And, according to Forbes, Jimmy reached billionaire status recently, thanks to his Margaritaville and cheeseburger and paradise brands. This allowed the singer to buy and sell plenty of Florida real estate, including a lavish and modern beachside estate he sold in 2020 for $6.9 million, and a larger oceanfront mansion that sold for a record-breaking $18.5 million back in 2010. At the time of his death, Buffett owned at least two homes on a route trail, a short ocean block street lined with historic cottages and townhomes. Jimmy Buffett, the singer-songwriter who turned his hit song Margaritaville into an entire lifestyle brand, has passed away at the age of 76. The song, from the album Changes in Latitudes, Changes in Attitudes, spent 22 weeks on the Billboard charts back when it was released in the late 70s. Margaritaville was further inducted into the Grammy Hall of Fame in 2016 for its cultural and historic significance. It became a karaoke standard and even helped brand Key West Florida as a global destination. Buffett had been added to Forbes Billionaires back in April 2023. His wealth wasn't just from ticket sales and his expansive music catalog, but from his Margarita Holdings chain of merch, resorts and restaurants, which he created with the focus on his style of his carefree, tropical-escape music. Jimmy Buffett was born in Mississippi and raised in Alabama, but made Florida home with its ocean breeze, laid-back life and happy hour afternoons, both through his music and his personal life. A long-time resident of the Palm Beach area, he made no excuses for living the good life. A statement posted to his official website and social media on September 1st stated, Jimmy passed away peacefully on the night of September 1st surrounded by his family, friends, music and dogs. He lived his life like a song till the very last breath and will be missed beyond measure by so many. No doubt, Jimmy also lived quite the Margaritaville legacy behind as well. Jimmy Buffett had deep residential ties to Palm Beach dating back to the early 1990s or even before. The time of his passing, he owned at least two properties on Root Trail, a short, ocean-side street lined with historic cottages and townhouses. In December 2020, he and his wife Jane sold a Palm Beach house. They owned on Garden Road for nearly $7 million, where they had lived since 2011. A decade prior to that sale, the Buffett sold an even larger, five-bedroom waterfront mansion across town for a record-breaking $18.5 million. They had paid $4.4 million for the 1.6-seeker property in 1994, but the house was later demolished and eventually replaced by a mansion under a new owner. In 2013, Jimmy had purchased what is his last known property on Root Trail in Palm Beach. Reports suggest that the singer paid around $1 million for a newly rebuilt, Key West-style home right across the street from another place Jimmy owned for over a decade. Records revealed that Buffett bought the second house on Root Trail through the same limited liability company he used back in 2002 to snag the building across the street on Root Trail. The most recent Buffett residence purchased in 2013 was a three-bedroom home, boasting 3,163 square feet. At the time of sale, it boasted unfinished interiors and was once a four-unit apartment building built in the early 20th century. The property had architecture reminiscent of many Key West homes and while the original clay walls were preserved, the home was transformed from a multi-unit structure into a single-family home before Jimmy purchased it. However, there were no photos or other details shared about this home aside from that. In 2020, Jimmy Buffett and his wife Jane sold one of their Palm Beach homes on the town's north end for $6.9 million. This island contemporary-style home was ideal for the Florida lifestyle. Are B a more suitable place you'd picture the Margaritaville singer living? Buffett purchased the property for just under $5 million in December 2011 and inside, it featured three bedrooms, three and a half baths, as well as almost 5,000 square feet of space. The modern island residence was built in 2003 and had stunning living spaces throughout, most of which were airy, white, and bright. The layout of the home centered around a combined living and dining room with soaring vaulted ceilings, boasting skylights, and a wall mahogany-framed glass sliders that lead out to the pool. The kitchen where Jimmy no doubt whipped up his fair share of Margaritas at one point featured a nearly all-white theme, as well as modern appliances and snack bar-style seating. The way that the living areas opened right up to the deck outside gave the full experience of the indoor-outdoor vibe perfect for Florida. Each of the bedrooms boasted an en suite while the sprawling master bedroom had sliding glass doors opening to both the pool and luxury spa-style bath. The fact that there were views of the lush gardens in pool from nearly every room completed the resort-like feel of this home. A covered terrace just outside allowed for an al fresco dining area while the focal point of the property was no doubt the deep blue-colored sparkling swimming pool. The pool area featured plenty of lounging surrounding it, while it's also set amongst a ton of tropical plants in a fountain. Other highlights of Jimmy's former home included a detached two-car garage with dedicated guest suite built above it, and exclusive beach access at Eden Road and Via Marilla. While that's not the only sale the Buffets had made in the town of Palm Beach, back in May 2010 they sold a five-bedroom mansion on Ocean Boulevard for a record-breaking $18.5 million. It was quite the epic sale considering the Buffets bought the place for a mere $4.4 million in 1994. The five-bedroom nine-bathroom abode was built back in 1925 and had been designed in a Mediterranean style by Marion Sims Wyatt. Later, it was remodeled into a British colonial-style home. Situated on 1.6 acres, Jimmy's former residence was also Ocean Front, boasting features like a tennis court, pool, guest house, and more. Unfortunately, there are no interior pictures of this mansion and some time after the Buffets moved, it was eventually demolished to prepare the land for an estate built by British real estate mogul Sir Peter Wood. Jimmy Buffet was often associated with Hawaiian shirts, flip-flops, and a laid-back beach style, and spending most of his time in Palm Beach suited him best. This area of Florida is well known for being home to other billionaires and celebrities too, including former President Donald Trump. Jimmy's involvement in the South Florida community while he was still with us included being a board member on the Everglades Foundation, as well as a regular participant at a number of annual charity fundraisers in Palm Beach. Buffet's mega-brand began in 1985, with the opening of a handful of Margaritaville-themed stores and restaurants in Key West, followed in 1987 with the first Margaritaville cafe nearby. Over the next two decades, several more of each opened throughout Florida, New Orleans, as well as California, just to name a few locations. Brand has since expanded to dozens of categories, including resorts, apparel for men and women, a radio station, a beer brand, iced tea, tequila and rum, home decor, food items like salad dressing, salsa and shrimp bites, the Margaritaville at Sea Cruise Line and restaurants, including Margaritaville Restaurant, JWB Prime Steak & Seafood, Five O'Clock Somewhere Bar, and Land Shark Bar & Grill. Unsurprisingly, much of Jimmy's Margaritaville branding was in Florida. The first Margaritaville was at the Universal City Walk in Orlando in 1999. The singer further licensed the name to a Florida developer to create a $50 million oceanfront hotel in Pensacola in 2010, promising barefoot elegance, which kicked off the run of Margaritaville luxury hotels. When Jimmy Buffett released Margaritaville in 1977, he had no way of knowing that his beach theme song would become an instant hit. The classic tune is still in rotation today and has led to a complete Margaritaville lifestyle brand. Jimmy might have passed away, but the billionaire has no doubt left behind a lasting legacy. After looking at the Palm Beach properties of Jimmy Buffett, that's going to wrap up today's special edition of House Tour. But before we go, answer this question for me. If you could create a lifestyle brand based on one destination that was special to you, where and what would it be? Let me know down in the comments and don't forget to like, subscribe, and follow me on Instagram to chat. I'm Keira the Vampire Slayer and I'll see you all in another video. Bye!


Hey folks, if you watched the last episode of Code Club, what you really should do, you may have noticed that I seemed a little bit unsure of the analysis that I was doing. I was getting results and I think I had little pop-ups to this effect. I got results that didn't quite square with my experience or what I thought was right. Something seemed off, right? So I have gone back into my code and just to kind of refresh you and remind you what we're doing. I am looking at precipitation data collected at NOAA weather stations from across the globe and I am looking at the last 30 days of precipitation for each region on a degree-by-degree latitude longitude grid across the globe. I am summing up the total amount of precipitation for the previous 30 days and then I want to calculate the Z score for this year and every other year so I can see how drowdy was the last 30 days compared to all the other data that we have on record for that region. So we're at this point where I'm reading in precipitation data, station data, we're joining it together, we're grouping by the latitude and longitude, and then we're summarizing that all together. I then made a data frame that had the data for this year, for 2022, and then I did a join. And so I've gone ahead and inserted a filter statement in here with the latitude and longitude for where I live just outside of Ann Arbor, Michigan, and again the year 2022. And when I run this what I notice is that for this year the total precipitation was 0.117 centimeters of precipitation. Now I feel like we've had a fairly wet September. I'm recording this on October 7th and so I recorded the previous video on October 6th and so that would more or less mean that from like September 6th or September 5th or so all the way to yesterday there was a fraction of a centimeter of precipitation and that's just not true. Or maybe there's something wrong with the gauges and everything. And so I got to thinking what happened? Why is this happening? Because that doesn't seem right. And I actually went and spot checked a lot of other areas and found everybody seemed to have a really low precipitation for September. And while that might be true, I thought that seems a little bit fishy. So I recalled that when I went back into my ReadSplitDly files, this R script that reads in the individual files or the individual data for each of the weather stations and months, I recorded today's Julian date using the today function, right? And so that then that comes from Luber date, right? If I do Luber date on that, or sorry, I got to do library Luber date, right? I load that and then if I look at today that that comes up as October 7th, right? And so when I ran this was a week or so ago, right? And it was using data that was originally downloaded a couple weeks ago, actually, right? So if I look at LSLTH on data, the data that we're getting this from is the GHCND all tar GZ file, which again, I got September 8th, and probably has data from September 6th or 7th, maybe, right? And so if I then ran that on October 4th, right, hopefully you're catching on that if today was October 4th, we subtract 30 days to get to the window, we're at about September 4th. And so what that means that most of the data that we actually were looking at in that 30 day window were zeros, right? Because we didn't have the data, it was missing, it was being treated as missing data. Regardless of it was being treated as missing data, NA is whatever. If you sum up the precipitation over that 30 day window, it's going to be much smaller than it actually was, because we didn't actually have all the data from that window. So what I need to do is I need to go ahead and bump this to get the newer version of GHCND all tar GZ. So I could certainly rewrite how I did line 32 here. So instead of being the actual day of today, it could be the last day that we got data from the weather stations. But that's not really something that I want to be able to do on the fly because the way this is reading it in, it's basically getting chunks of the overall GHCND all file, right? We basically took that large 3.3 gig archive, which is really 30 gigabytes decompressed, and we're pulling out different chunks of that. So I don't really have the ability to get today, so to speak, from that data. I need to give it today. And I'm happy with leaving it as today. So I need to go ahead and basically update this file. Now, we have done everything in snake make to this point, you'll recall that we have a snake file way back up at the top here, I have this get all archive rule, which goes out and gets data GHCND all tar GZ. So I could delete this file, and then it and then run snake make on my targets, and it will then regenerate this file and then regenerate everything else. That seems a little in elegant. So what I'd rather do is force snake make to rerun this rule, right? And so one question we might have is, well, if we update this target, this output, what, what else will change, right? And so one thing that we might think about doing is looking at the DAG, the directed acyclic graph of what the overall pipeline looks like at this point. And so I want to make sure that I'm in the right environment so I can do conda, ENV list, I see I'm in my base environment, I'll do conda, activate, drought, to build a visualization of the pipeline, I can do snake make, hyphen hyphen DAG, and then targets. So recall that targets is this main target up at the very top. It's the very first rule that has the targets or the output of all of my different rules. So GHCND all tar GZ is there, of course. And so I can then pipe this to a special tool called dot. And then I'll use the argument hyphen T, PNG, to say that I want to output the DAG, the image as a PNG, and then I'll redirect the output to a file that'll call DAG dot PNG. And we can see all of the different rules and how they link back together. And so this get all archive, if I update this, that's basically the rule I really want to update because it's got that all data, right, that will then update the get all file names rule, the summarize DIY files, and then the final targets, which again is what's going into this merge weather stations, our script that I started out talking about today, right? So that's what we're thinking about. We're going to basically kick this rule to force snake make to update it, and then it'll update everything else. But because the inventory file, as well as the station data might also get updated along the way, I'm going to force snake make to do those as well. I'll do snake make hyphen capital R. And so capital R will force running of the rule, right? And so we'll do hyphen R. And then we will do the names of the rules we want to force it to regenerate. So we'll do get all archive, and then get inventory. And then get station data. And again, it's going to rerun those rules, and then everything else that depends on them. And so I'll go ahead and put hyphen C one, because it needs the number of processors or threads that it's going to use, and everything I've got has one processor. So this will run, it'll probably take 45 minutes to an hour to run because it takes a while to download the files. It takes a while to process the data. And then we'll come back and see what we actually get for the amount of precipitation in Ann Arbor over the last month. So it took about 45 minutes to redownload the data and reprocess the data to the point where we're ready to read it back in again into our merge weather station data R script. I hope you agree with me that snake make is just a really invaluable tool for keeping track of our pipelines. I think it's just so awesome that I was able to basically kick snake make and let it run walk away, come back 45 minutes later. And the analysis has been redone without any error messages. To me, that is the main bonus main benefit of engaging in reproducible research, I'm going to come back over to our and I'll go ahead and reload these different data frames and see what we get for Ann Arbor see if we get a value that's a little bit more along the lines of what I think it would be. And sure enough, we see that for this year, we had a total precipitation for the last 30 days of 4.26 centimeters again that 4.26 divided by 2.54 centimeters per inch about 1.67 1.68 inches of rain. And I think that squares pretty well with what I think our rain gauge out in the front of my house had accumulated over the course of the month. So yeah, that seems a lot more reasonable than tenths of centimeters. So I'm going to go ahead and grab this filter statement and throw it at the end. Because what I want to know is what was the Z score for this area, right? So I'll go ahead and rerun this up and I've got year 2022. There is no year column at this point in the data frame. So what we see is that yeah, I guess it was a little bit drier than normal, based on 151 years worth of data that we have for the Ann Arbor area. So I'd like to refactor my code. One of the kind of thought bubbles I had as I was watching back through the last video was that I probably didn't need to create this separate data frame with data for this year. And what I'd like to do is try to bring it all together into a single pipeline. I'm going to go ahead and grab this output, and I will plop it up here. And I'm going to comment it out because what I want to do is save this for when I refactor it, make sure I get the same result. Let's get some more breathing room here. And what I'm going to do is I'm going to forego these first few steps. So I'll go ahead and comment those out. And I'm going to grab the lat long PRCP and pipe that into everything else. Also go ahead and comment out this code chunk up here. When I comment it out, that's kind of like fodder for the cutting board. So again, we've got lat long PRCP, maybe I do need this up a little bit higher. I've got my latitude, my longitude, the year and the mean PRCP. So I want to group it by the latitude and longitude. And before we did summarize to get the Z score, where we got one Z score for each latitude and longitude. Again, summarize takes all the data in a group and synthesizes it down to a smaller number of values. Instead, what I will do is I'm going to use a mutate. And so this is going to create a column, but my calculations are going to be done within the group. Okay, so again, where I have mean all years, that was the mean PRCP column for all the years, right? So instead of mean all years, I'll do mean PRCP. And I'll also do this standard deviation of that as well. Now, I also did the min on this year column. And so that was the column that came from our 2022 data frame, to get us a single value for the X value basically for calculating our Z score. Because I'm doing a mutate, I'm going to get back the same number of rows that I put in. And to do that, then each row is a different year. I'm going to go ahead and put mean PRCP in here to then give me basically a Z score for every year for every region of data that I have. And now if we go ahead and run this, I see that I get different Z scores depending on the mean PRCP value. And if I run this whole pipeline, again, I'll get the Ann Arbor data. And I then see the Ann Arbor data going back to 1872, which was the first year full year that we had data for, right? And I've got this dot groups equals drop column, because it made a column, because this was leftover from the summarize function. So I'll go ahead and remove that. So let's go ahead and add to this filter year equals equals 2022. And sure enough, we get the same output that we had the previous way we did it, with a lot less code, right? That's pretty slick. Again, all that matters is that we get the right answer. But I like to have, I like to have simplicity, right? The other thing I can do then because through this point of the pipeline, we're going to have that column and I can go ahead and remove that column, I could then do select minus and to get rid of the end column. Again, if I wanted to see what that looked like with the Ann Arbor data, we would then see the Z score, I do see that I still have things being grouped. And so at the very end of this, I'll go ahead and do an ungroup on that. Maybe I'll move the ungroup back up here after the mutate, so that I don't have things being grouped for too long. It probably doesn't matter whether or not the data are grouped at this point. But I've seen weird things when data are being grouped for too long into a pipeline. So I always like to remove the grouping as soon as possible. Very good. So let me go ahead and clean this up. We'll remove this commented out code. Also go ahead and remove this final bit of code. I'll go ahead and also remove the filter for the Ann Arbor area. And I think what I'd like to do is go ahead and add in here the year being 2022. And then what I could also do is I can also remove the year column, right? So do hyphen minus year. And this then will give me the lat, the long, the mean PRCP and the Z score. I don't really need that mean PRCP. So I'll also go ahead and remove that. At this point, I may as well have said what columns I actually want. But hey, this all works. So we now have our latitude, longitude and Z score. Those are the three values that in the next episode, I will be generating a plot for so that you don't miss that episode. Please, please, please make sure that you've subscribed to the channel. You click that bell icon, you give me a thumbs up that way, you'll know when that episode is released.