Hello, I'm P3, responsible for analyzing and improving the performance of in-vehicle importainment platform at Hyundai Motor Company. Today, I would like to introduce various platform analysis features and automatic performance monitoring capabilities using an open source program called GUIDER. First, let's briefly discuss performance issues, and then I'll introduce performance analysis tools, including GUIDER. Next, I'll showcase features that enable automatic performance monitoring and generation of analysis reports when issues arise. Finally, I'll share what performance data generated in vehicles can be collected on the server and utilized well. As we develop our product, we encounter various performance issues. If there is something perceptible, it would be things like slowness, instability, and stuttering. Analyzing performance issues at the level of a single app is not very challenging. Most platforms provide good debugging and analysis features for apps. However, when the scope of the problem extends to the platform level, such as corner, analyzing and improving it becomes much more difficult. And the reason is that the areas to use mind broaden the amount of study requires increases and their analysis programs to be used are multiplied. So in the case of the importable system developed our team, various apps and services within the system are interconnected to implement complex and sophisticated specs, considering features that interact with external systems like head-up display and cluster and ADAS and others. Those systems become extremely complex. Performance issues arising from such complex systems are truly diverse and often challenging to analyze. To quickly analyze issues and pinpoint their causes in such complex systems, the best approach is to swiftly select and adaptively use the optimal tools. So what performance analysis tools should be used effectively? Analysis tools can be broadly categorized in three types. Monitoring programs that show the current state in real time. Profiling programs that collect and summarize information over a 13th period. And tracing programs that display all detailed operations. As performance analysis tools are diverse for each system area, users need to choose them wisely according to their priority and experience. However, when actual performance issues arise, knowing where to start, which tools to use first can be quite challenging without prior experience. Having worked in performance analysis for several years, I have come to realize that many of these tasks are inconvenient and insubstant and even impossible with the tools available. Over time, I found myself in situations where I had to analyze systems without access to the source code and compiler relying only on a root shell. In light of these challenges, I decided that I would be more practical to create my own tool, leading to the development of an open source program called Gaider. Gaider, as mentioned earlier, provides visualization features along with monitoring and profiling and tracing features. All these features operate immediately under target without the need for source code and compiler. Developed for comprehensive performance analysis, Gaider currently comprises around 150 comments and various options, the details of which will be explained later. It utilizes GPL2 with the official repository hosted on GitHub, supporting also PIP and open embedded. Gaider can be executed with basic Python without the need for separating building and installation or environment setup. It supports popular CPU architectures and requires about two megabytes of storage size. During system monitoring, CPU resources are consumed about two or three percent of one core, and RAM usage is around 17 megabytes. Gaider operates as a stand-alone on all Linux-based platforms, Android and Azure, particularly on macOS and Windows also. There are two examples to use Gaider. One is by installing it using PIP and the other is by downloading it from GitHub. I'm sorry for the color and size of font. It's a little bit difficult to see. First, let's try installing it using PIP. It's done. Next is the method of downloading from GitHub. It's done to use Gaider. Gaider currently incorporates approximately 150 built-in comments. It's implemented directly without relying on external execution binaries, ensuring independence from dependencies. In addition to the monitoring, profiling and tracing and visualization features you see in the diagram. Gaider also supports more functions, experimental analysis features that is capabilities to control systems and tasks. Communication features in a server client structure for remote control and system load testing and various utility features are included. Due to time constraints, I will provide a brief overview of the most commonly used ones today. Let me guide you through the frequently used features in Gaider with the video demo. I hope this helps understanding Gaider. First, let's explore the help and examples. Gaider has about 150 commands supporting various operating systems. You can check the help for each command by running it with H option. At the top of the command, help, you will find descriptions, options and examples for the respective command. Before analysis, let's create a workload. Gaider supports the creation of CPU workload with the CPU test command. This command creates a task called GaiderWorker that uses 100% of one CPU core. Similarly, you can allocate and monitor system memory every second with the memtest command. There is also the IO test command for reading from file or writing to a file repeatedly and measuring at lots of time. Now let's check how much CPU's workload task is using with the top command. This shows that the GaiderWorker task using around 100% of one core. If you use filter option to focus on specific task with G option, you can use like this. It's a for regular expression. You can also save this information to a file with O option and visualize the profile result with the draw command. Then the SVG file is created. Let's open it with Chrome browser. This way you can create a resource usage graph and detailed information about process using a lot of memory. Next, let's check information about files or sockets opened by task with the f-top command. Without filter option, it shows the number and types of file descriptors and sockets of all task. And applying a filter, we can use G option with target task name or ID. It shows details about the file descriptors and socket including position, open options and protocols and others. So now let's move on to function monitoring commands. To monitor in real time which functions of particular task is using CPU or taking a long time to complete, we can use U-top command. So let's create a workload in background like this and start monitoring the functions of the task dynamically with U-top command. This shows functions that are waiting or taking a long time to execute in real time. And you can save this information to a file with O option. After then, I converted the monitoring result into a frame graph file with draw command. The name of the file is a little bit long. Open the generated SVG file with Chrome browser. You can visualize profiling result in a frame graph. So clicking on specific functions provides an extended view of the related call stack. And you can search for specific functions using Ctrl F with regular expressions. Then it's highlighted with red colors. Next, let's monitor system calls for specific tasks in real time. First, create a workload in a background again and start monitoring the system calls of this task with Sys-top command. This shows real time system calls being invoked. And saving, converting result into a frame graph file is also available as before. And similarly, let's monitor Python functions. First, run the IOTAP program that is written in Python and very famous to monitor system IOTAP. And next, start monitoring the Python functions of this task using pytop command. Saving and converting the result into a frame graph file is also available as before. Now let's explore profiling commands at the system level. First, profile the action of threat with the rack command in background. And create a workload for short time. And start profiling and convert the profiling data into a report file. Yeah, it's done. And let's open the auth file. This report file summarizes resource usage for system and task. It also shows scheduling latency and schedule level stats and block operation size and count and more stats. There are many stats. Below you will find histograms for which stats and detailed information on block operation patterns such like sequential or random access. File operations about file paths and access size. And now let's visualize the scheduling information of tasks based on profiling data with a timeline. We can use the draw command to create a SVG file and open it Chrome browser. After drawing, open it in Chrome browser. Then yeah, we can view task scheduling on each call. Mouse over each bar to see task names and scheduling related information. The black color at the top of each bar indicates blocking state. And red indicates pre-emission state in scheduler. Next, let's profile all system calls invoked in this system. Start profiling with the sysleq command in background and generate a workload for a short time. And start profiling and create a report file with the report command again. Then open the generated report file to see stats above all invoked system calls. Then there are many type and duration and call count and error count and time statistics on system level. And you can also check the similar stats about each task. Now let's move on to tracing command. First one is system call tracing with the strace command. It's very similar to Linux strace. You can trace all system calls for specific tasks with backtrace in real time. I think this video's frame rate is a little bit bad. And next, let's trace user-level native functions with the bittrace command like this. If there are too many function called, you can apply function filter with C option. The bittrace command supports additional sub-command for handling when a specific function called. This is the list of sub-commands for function call handling. When the target function is called, you can read or manipulate values of specific register or memory and introduce delays and repeatedly call again or redirect to other functions. For example, to read the data to be written during a write operation, you can use this command. So you can read all verbal data from target's task memory like this. And similarly, let's trace Python functions of IOTAP process executed before with pytop command like this. And let's move on to signal tracing command. First, create a test program source code. This will use out-of-bounds array index. So if you run the following trace command, sigtrace, the process received a signal board due to text-messing detection. So as it uses out-of-bounds array index. And finally, let's explore memory tracing command. First, create an example program. This will allocate about 100 megabyte memory and keep them. Run the retrace command. The guide that our file contains a table at the bottom displaying course text, allocation size, and count of unreleased functions. So additionally, it shows file-level information and open the generate fsvg file. Then you can view a frame graph of these functions. So unlike servers, embedded systems with significant resource constraints always need to archive maximum performance with minimal resource. To archive this, strict validation, analysis, and optimization of performance must be conducted over a considerable period. However, the modern SDV development process requires greater flexibility and development of more features within shorter cycles. So as new features with complex interdependencies are continuously added and fixed test cases alone cannot cover all user scenarios. So furthermore, previous guide commands could only be used in person when the state persists or was reproducible after an issue occurred. So therefore, there is a need for capability to monitor vehicles from the development stage on the world and automatically analyze and report performance issues when they occur. So I updated GUIDER to be the automated performance monitoring demo. GUIDER, DEMON, automatically monitors the performance of the system and generate a performance report based on the correct data in case of any issues. So all of these operations are performed automatically and based on various threshold values defined in file beforehand. So firstly, the object that can be monitored include a wide range of items from the physical devices of the system to logical resources, various logs, diverse types of functions, and even IPC. Everything can be automatically monitored. Not limited to the system level, monitoring at the task level and function level is also possible. To effectively utilize this capability, careful preparation of monitoring settings, conditions, and strategies is crucial. Actually, each monitoring item is detailed with these monitoring values. The automatic performance monitoring function is executed by GUIDER as follows. Initially, GUIDER wrote the configuration file to understand the monitoring targets and conditions such like threshold, and then it begins monitoring. So when an issue occurs, GUIDER automatically executes the corresponding command list sequentially. The command list may involve directly handling the problem and collecting data for performance analysis or sending notification to external systems. If there is a command in the list that generates a performance report, GUIDER creates a performance report as a file in those storage. This continuous performance monitoring function must require minimum system resources. Next is the most crucial part of the performance setup. During initialization, GUIDER wrote the configuration file to understand the monitoring targets, scope, and conditions. Then when the conditions are met during monitoring, registered commands are automatically executed sequentially. Then left side of the screen represents the file format defining these events. The right side shows corresponding example values. At the top level, you define the monitoring targets as shown earlier, such like CPU. In the next level, you specify the scope. If it's for the entire system, it should be entered as system. If it's for the specific task, the task name or ID can be entered. In the subsequent level, you define event conditions and processing method. This includes the applicability of the condition and threshold values and continuous conditions, a list of commands to be automatically executed when an event occurs. The most critical aspects here are the threshold and the list of commands. When the conditions meet the threshold, the commands from the list are automatically executed sequentially. Summarizing the example on the right side, it means monitoring CPU usage at the system level. If the total CPU usage remains above 95% for five seconds, automatically executed the following two commands. The commands may be built-in guide commands starting with save that generate performance report automatically based on collected data or external shared commands executable. I'll explain more about the content of performance report later. Guider operates as a monitoring demo in the background, so there is a need to control it externally for various purposes. To facilitate this, the following control commands are provided for use in the shell. The commands enable you to change settings or control the operation of Guider during runtime without any restarting. Let me explain the automatically generated report files at the time of problem occurrence. Guider continuously collected the system performance information from the start of monitoring and storing it in fixed-size internal ring buffer. When the save command is executed upon encountering an issue, Guider generates a performance report file, and the performance report file summarizes the system state for specific duration around the time of the issue. It includes various details, but I'll specifically mention about the most crucial summary information and snapshot details. Firstly, the top command info table provides a line-by-line summary of the collected system information. It includes CPU, memory, IO, network, and system event information gathered at regular intervals. Below that, there are tables summarizing the resource usage changes for tasks in each resource unit. The usage of the resources for tasks is displayed over time on the right side. In addition to this CPU usage summary table, named top-CPU info, there are also summary tables for delay, and sketch priority, and GPU, and VSS, and RSS, and block, storage, network, and C-group. The previous summary information is extremely useful for analyzing changes in resource uses, either the system or task at a glance. However, since it is summarized information, it can be challenging to examine detailed information at a specific point in the time. In such cases, by reviewing the snapshot information included in the report file, you can access more specific system information. The system status is displayed in the format of the top command output. At the top, the total amount of system events and physical resources are shown. Below that, information such as system latency and resource usage and the number of events are displayed. Of course, usage information for supported GPU is available. In the last section, resource usage and event information for each task are displayed. At the very bottom, special task information, including new and terminated and abnormal tasks, is able to be presented. Based on experience, setting the monitoring vocal size of the guide to 3MB, generating a report file result in approximately 15 minutes of system information, being captured. In reality, analyzing such a large amount of text manually is almost impossible to the extensive numbers that are not easily accommodated on a single screen. In such cases, the report file needs to be visualized as shown on the screen. Guider allows you to convert the text-based report files to SVG files. When opened in a browser, it produces an image that provides a comprehensive view of the entire period. At the top, you can see system CPU usage and GPU usage and task-specific CPU usage. Below that, IU and memory-reclaimed related statistics for storage and network are more displayed. At the very bottom, the system's memory usage is shown. You can also display changes in the task memory usage and IU usage and more. Additionally, it's possible to visualize system log with the report file. When using a conversion command, you can input the log file pass and define log information as events with additional options. Then the output file will display the occurrence time and context of system log at the top of the screen. Since platform context and system context are displayed together, the analysis becomes much more manageable. When there is a problem with performance, a report file is made in a specific territory with the predefined naming format. This naming method avoids making a duplicated file and makes it simple to find them based on the order they were created. Not the system time. You can also set a limit on the directory size to automatically delete the oldest reports when it gets too full. This way, storage will not fill up endlessly, preventing possible problems in our production. Let's start the demo video. First, let's take a look at the configuration file. At the top, you will find the categorized monitoring target, followed by descriptions of each event scope. Very small font. And attributes describing the event conditions are listed like this. Then you will see variables related to the file naming and finally the built-in commands like this. Then let's move on to the section describing performance events to CPU. The first-level CPU represents the monitoring target followed by system as monitoring scope and then attributes for each event. This condition means that if the overall CPU usage remains above 95% for more than five ticks, it will automatically execute the save command. And it will create a report file. Then let's activate events testing conditions. We have a task starting with yes maintains CPU usage above 98% for more than three seconds here. And the CMD t-tap utap2 command for the yes event handles function profiling for two threads showing the highest CPU usage in the process. Saving it. Let's start Guider for automatic performance monitoring like this command. Then it has started with rows about enabled events. Then let's create a workload on another share. The first workload runs the yes program making the yes task utilize 100% of one CPU core. And after three seconds, automatic function profiling for the yes thread begins and the results are stored in a file. Yes, finished. So if you open this file, you will see the functions that consume the significant amount of CPU for the yes thread. The performance information, including the performance report collected through the previous automatic monitoring is specific to a single vehicle and exist only within a vehicle. So to effectively analyze and utilize performance data for large number of vehicles, it needs to be collected on the server. So now let me talk about this in more detail. So the real time performance data generated by Guider can be continuously updated separate JSON file. Here is an example of some of the information in this format, details that are system and task level for each resource unit are represented. So at the top left, you will find threshold events that is a display of performance issues called event that occurred since booting along with its count. At the top right, you will find peak figures for maximum usage for each resource. We can transport this data to our analysis servers for analyzing the performance of driving cars. While it would be impressive to collect and process and display real time information for all devices on the server. But I think real time collection and processing may not be effective considering cost, stability and availability. For your information, our Hyundai Motor Company currently operates approximately 10 million connected cars. So the scenario I have chosen involves not real time but aggregating performance data at the moment when the vehicles stop driving and turn off. So analyzing them on a daily basis. So this process data is then used to provide a dashboard overview of the general performance for a large number of vehicles. In situations where issues arise, detailed analysis is also conducted using performance report. As potential data candidates to collect on the server, we have a list of performance issues and peak resource uses and performance report. As demonstrated earlier with the performance report data alone, not only can we obtain specific snapshots of the moment when an issue occurs, but you can also visualize extended periods before and after the problem arise. Additionally, you can use biolink graph to visualize peak resource uses data collected in large quantities. So this enables us to categorize and observe trends in resource uses among vehicles based on factors like platform and time and version. So for example, we can monitor resource changes after deploying new versions and track corner cases in the operation of complex specs and identify abnormal system behavior. Certainly analyzing the detailed performance reports becomes possible by linking the detected unusual data with the performance report using timestamp, vehicle, and platform information. Beyond peak data, utilizing load average data enables to analyze user overhead in our system. So far I have explained some kind of useful guide features and more features besides the one I described, but I couldn't explain all them because of time limitation. And I introduced in performance monitoring demo features, it will be more expanding to manage and analyze system performance issues itself. And for specific details, please report to the readme file in GitHub. And if you have any questions, please contact me using email or GitHub. So thank you for your listening for a long time. Thank you.


It's simple. It's basic physics and chemistry. It's physics and chemistry that we have known since the 19th century. Carbon dioxide is a greenhouse gas. That means that it's relatively transparent to visible light, but relatively opaque to infrared. Or make it even simpler. Light comes in, heat gets trapped. So if you put more carbon dioxide into the atmosphere, more heat gets trapped. And sooner or later, the earth has to warm up. That's basic physics and there isn't really any other possibility. I think what a lot of people don't realize is that the history of climate change is a very long one, the history of climate science. It was started with Joseph Fourier back in the 1820s. Despite what you might have heard, this is not new in controversial science. We've known about the greenhouse effect for nearly two centuries. Joseph Fourier, a scientist who's well known for the mathematical technique known as the Fourier series. He is the same scientist who produced the law of heat conduction. He's the guy behind the law that governs how heat moves through substances. He understood that there was a greenhouse effect. It's all just basic science. It's physics and chemistry. And the key thing to know is that this isn't some new thing that Al Gore cooked up a few years ago. It's rooted in the basics of physics and chemistry. The experiments on this started 200 years ago. So, yeah, you might see some headline that questions some aspect of it in the news tomorrow. But that can't affect the core because the core is so grounded in what we know at this point that you'd have to tear up most physics and chemistry textbooks for us to be wrong. So, the next person in the story is John Tindall, who's an Irishman who did some very careful experiments in London in the 1860s on the absorption of infrared radiation by various gases. He tried lots of different gases. He had normal air and water vapor and carbon dioxide and methane and other hydrocarbons measuring how much infrared radiation was absorbed by these gases. And he found that various greenhouse gases as they're now called, so carbon dioxide and methane and so on, they absorb infrared radiation in this laboratory experiment. And so this is the basis for what we now call the greenhouse effect. Climate science is 150 years old. We know that CO2 is a greenhouse gas. If it falls, then airplanes would fall out of the sky because the rest of physics would be false. In the late 1890s, we have Swedish professor Svante Arrhenius, who was the next person to start investigating this problem. And again, he was mainly concerned with explaining ice ages, what could cause these large temperature changes in Earth's history. But also at this time it was becoming realized that the emissions of greenhouse gases from human activity could potentially be changing the composition of the Earth's atmosphere. And therefore the role of carbon dioxide could be more than just explaining Earth's history, it could be potentially changing how things change in the future. And this is becoming more important in the late 1890s. So Svante Arrhenius, he went away and again, did some relatively simple calculations on what would happen if the amount of carbon dioxide in the atmosphere was doubled, the kind of force experiment, if you like. And he came up with a number of around about four degrees or so for the change in global temperature if you double carbon dioxide in the atmosphere.  And the physics behind that causing warming are the same physics that the Air Force used to put sensors on heat-seeking missiles. And in some really fundamental sense, if you deny the global warming effect of RCO2, you are climbing the Air Force, doesn't know what to put on their heat-seeking missiles. It's absurd. My scientific hero in this story is an amateur, an amateur meteorologist called Guy Stewart Callender. He was a professional steam engineer, and that was what he did as a day job. But in the evenings and weekends, he used to collect temperature measurements from around the world and he was a very avid meteorologist. He took measurements in his back garden and he just enjoyed collecting data from temperatures all over the world. And in the 1930s, he started to put together a global average temperature. He put together readings from 150 stations all over the world and averaged them all together to try and get an estimate of what the globe was doing instead of just looking at one or two locations. And what he saw was the Earth was warming up over the previous 50 years. The first thing about climate warming is that the physical basis we've known it for centuries. This is nothing new in the science of climate change today. You bring more CO2, more greenhouse gases in the atmosphere, it warms it up. It's undisputable. The rate of emissions was thought to be far too slow to affect global temperatures back in the late 1800s. But by the start of the 20th century, the rate of emissions had gone up an awful lot. And so it had begun to realize that perhaps the rate of human emissions of greenhouse gases could affect the global temperature. And so Calendar also collected for the first time the available carbon dioxide measurements. And he showed that carbon dioxide in the atmosphere had gone up because of human activity. And he linked that to the rise in temperatures that he saw. And he did again, did some simple calculations like Arrhenius had done and showed that carbon dioxide could explain about half of the observed temperature rise that he'd seen in his data. And if you read the work that scientists were writing, say back in the 1950s and even 40s and 30s when they first started worrying about this, this is what almost all of them said. Almost all of them said, well, we don't know for sure when this will happen, but sooner or later, unless we're missing something, the earth has got to warm up. And guess what? That sooner or later has passed. Right? And here we are. Over time, the evidence has become more and more overwhelming that we're having a very damaging effect on the climate system because primarily because of our love affair with oil and fossil fuels. We know that has thermal properties. We know that's going to warm the planet with further fossil fuel emissions. There's absolutely no doubt about that happening. So the evidence is very clear where we're headed and the fact that the humans are driving it. It's a matter of physics and chemistry. And at the end of the day, science is about what is and what is if we're changing the climate system.


I have a small laser light with me and I'm shining it on the wall. Now in this activity, we will see that light actually travels in a straight line. And for this activity, you need a laser light, you can have some incense cones. Even if you do not have incense cones, which is actually called Dhoopatti. Even if you do not have that, a pair of dusters will work as well. Now to begin with, I will light them up and I will arrange them in a straight line. Just, just like this. And now when I shine the laser light on top of it, just see what happens. You can identify, you can locate the light at all of these locations, right? As it is travelling through the smoke. And this tells us that light actually travels in a straight line. As the light interacts with the smoke, we can clearly see the path taken by the light, which is actually a straight line. You must have also seen light coming in through a window and you could have seen the path of the sunlight that enters your room. From that observation, you can also say that light travels in a straight line. And we can see that sunlight because there is a lot of dust and some smoke in our surroundings. That is how we can actually see the path of the light.


Okay, so in my 17 years in IT industry, I've been working on product development. I've worked on Drupal for the last 10 years, or more, and UI design, DevOps, product management, of all of which the toughest thing I had to do was walk into a meat shop and talk to a butcher and help him cut his meat better. And me being a vegetarian was the toughest thing for me to do. The question is why? Why had to do it? For a year ago, I was called upon into the executive management office and said, Subbu, we have seven butchers on board the cruise ship and on an average. If they could cut the meat better and we know where the meat goes, that will save us millions of dollars, millions. So I was like, wow, I'd never realized it. And then the question is why? We run, in Princess Cruises, across our 17 ships, more than 250 restaurants, 250 restaurants of which 51 unique chains, which is the same restaurant in multiple ships, and on an average day, per ship, we sell more than 15,000 meals a day in one ship, times 17. So that's the problem we are trying to attempt. Let me show you one quick video, it's a 10 second video, of what happens in the galley. So it is a formal night where we have the waiters coming up to pick up the appetizer. It's one side of the galley, trying to serve for more than 1,000 people as a one minute one. This is the waiters coming and picking up appetizers, that's one, it's not even main food. So this is the busiest restaurant. We feed around 4,000 people within that period of two hours, the dinner. With this kale, times 17, on a given month, we give out or we make 1.1 million slices of pizza, 1.1 million. And let's think about soda, 51,000 gallons of soda a month. And my favorite, cookies, 1 million cookies that we bake on board. And healthy side, bananas, 220,000 pounds of banana. And ice cream is enough to fill an Olympic-sized pool. That's the size of operation. But for the last 50 years, for a decade, I mean 55 decades, they have been managing all of this because we had, as I said, 250 restaurants, we had so many menus. And we manage over 300 menus on board for managing all the ships. Now for creating all this food, because food is big in cruise ships, we have over 3,000 ingredients that's been kept and monitored. Plus the food, because ships are traveling around the world, we have to carry it and buy it from around 500 ports. So there's a logistical problem to get food items and of course other things too, but in mainly food, 500 plus ports. Now all of this, all of this is managed for the last five decades, as I was saying, with paper. Paper, emails. Now on top of this, with paper, we have crew members from all over the world, and we speak 54 languages. 54 languages. Now with all this, how will be the communication? So let's say that's how we represent it. So let's say there is a problem with lobster, which in fact we had. The product they bought and delivered to the ship from corporate office was not good enough. Now the ship found it while they were cooking food for the passengers, and there was a problem with the product. By the time this message reached shore office, and they found the similar problem that's happened all the other ships, and they took a remedial action of getting the next batch of lobster to these ships, took a month, because to identify this problem and making a remedial action, buying it, because it's all emails and things get lost and it's very difficult, which all amounts to a lot of wastage, and it runs into millions. If you do it right, if you do it forecasting is done right. Then since menus were being sent back and forth using emails, the menus were mismatching, and the recipes could be mismatched. Now what happens because of this is we have changed restaurants. So let's say Crown Grill is one of the popular restaurants on board. Somebody likes a steak or made some way and they expect the same when they go to next ship, and better be the same or it'll be a big customer service issue, because we want to keep the quality of the product. Between the restaurants that you visit, it's a big thing. Now everything with this affects the revenue, and of course that's what time to avoid. So this is a problem that is given to us. As a whole, just want to reflect back on what we are attempting. This is a complex problem. So many people, 300 plus restaurants or 250 plus restaurants, food from all over the place, 54 languages spoken, all managed with paper, this is a typical case where we would say this is a case for digital transformation. So what did we do? And this was a Drupal conference. We did it with Drupal. This is a story of how we did this transformation using Drupal. Of course we used Angular, Couch, the decoupled interface. And we knew and we know Drupal for the last 10 years. Drupal has been powering our guest experience platform for the last five years. And Drupal is living on board all our cruise ships, 17 of them, with the master Drupal and show side, and every ship has a Drupal instance running. We had other presentations where we covered this thing. But what did we have to build with Drupal to face this problem that we are facing about food and making it standard? We had to build this. I'm not expecting everyone to read this. We are just going over. What we built was Princess at Sea, which is our guest experience platform, as I was saying now. We built a digital signage platform for outside the restaurants for people to see what is being served. We have a printing system where digital data is used to physically print. There's a print shop on board to print restaurant menus and newsletters. So we used Drupal and services to provide data and build the menus. There is another session that my colleagues did yesterday about Canvas. This explains the Canvas suite, which is our print system. Next one we did was menu management system, which we had to create because we set 300 menus. We had to manage it, standardize it. There's a menu management system. There is a menu scheduling system because a menu is not the same every single day. There is a recommendation from show side how the ship should manage menu. So there is an intelligent system that we built to do a menu scheduling for the ship to make it easy. We also built a room service. That's where the menus are used to do transactions. You could request for room service. That's pretty fascinating. We also built a reservation system for taking orders for our reservation orders from customers. We did tables at order system. That's also built part of this platform. We did a kitchen display system. It's not a regular kitchen display system because we are talking about thousands of people and the orders are in hundreds. So it's a bulk kitchen system, which is not readily available. So we had to build it. Then meal count system to know what has been cooked should go back to the customer. So that's been counted well. And there's a chef planning system that we built, which also we'll show you, as well as the production system, which gives tickets to the butcher, the vegetable place, or all the production units to bring food to the gallery. We'll put a context around it like what we are talking about in the context of a restaurant. This is what we did. Now, going from left to right, if you see, the first is room service on the top left. That's one part. Princess at sea where the guests can see the menu and order for room service in case they want. There is a digital signage system where the guests can see outside the restaurant. Inside there's a table order system and table assignment. There's a food and beverage office on the top. They have a view of what is happening in every restaurant. Then the chef office where they can plan for food in every galley, the meal count system, the kitchen display system, and the butcher shop. This is the contextual view of how we can look at a restaurant and see what we have done. We'll post this in the site and you can take a look at it in detail. I'll give it to Davis to just go over the menu management side of things. By the way, if you have any questions, please talk to us. Come up to the mic and ask a question. We'll be glad to answer those as we go along. Thanks. So, as of now, we have seen the problem which we are facing and an overview idea of what we have built. I'll go in detail in each of the sections which we built and how we achieved it and how was the connection made using Drupal as a backend system. So, when we looked to the entire problem, one thing which we came to know is we were lacking the digital format for anything, like for restaurant menus or menu items. Just to be aware of menu item is not a Drupal menu item. It is a restaurant dish. It's a plate. So, just keep in context. So, the first thing was like the basic pillar to build the system was the menu items. And we didn't have the menu items in a digital format. So, using Drupal as a backend, we created a menu item system which had like the menu names, descriptions, and all the meta tags information which could actually, you know, look, when you look at a menu item, you could say like, okay, this menu item has this kind of allergens or this kind of dietary or this kind of intolerance. So, all this information was stored in the backend system of Drupal. So, in this way, we could create like when we took an account, it was like more than 5,000 menu items which they had in the entire like 17 ships. So, that is a basic first step which we had to take forward. So, we did that. Then the second step when we looked to it was a collection of menu item is a restaurant menu, right? So, that is the second step which we have to build. So, when we did the first step like creating a menu item, what we did is like we have a, so how the system works in our scenarios, like we have a show set instance where the show set admins can create the menu items and it has been replicated into the 17 instance of our ships. This, this, this, this application has been done using the Migrate model, Drupal's Migrate model which was very helpful for us. And we also have Lingotech which has been attached to the top. So, like our system, we support nine different languages. So, we use Lingotech heavily to translate all the menu items. So, a guest who's coming from China can see the menu in Chinese or a Japanese guest can see it in Japanese. So, so the process what happens here is like the show set admins create a menu item. This menu item has been sent to Lingotech for translation and it's coming back to the show set system and using Drupal's Migrate model it has been sent to all the different ships. So, that's the first step which we did. The second step is like collecting all these menu items and creating a restaurant menu. So, I'll go to the next slide. Yeah, so in, in our, yeah, yeah. Sure. Yeah, one plate. Yeah, so that is a plate. Yeah, yeah. The menu item could have sub-recipe. If you look at, that's an exact example that could have other sub-items to make that dish. The main menu item is one line item in the menu and you could have sub-recipes. Sub-recipes could have ingredients. It's a complex problem. We are trying to, we didn't go that deep. We could definitely go and show you all of that side after the demo is covered. We had to cover a lot, so we are trying to skip some of the areas. So, talking about restaurant menu, we had four different kinds of restaurant menu. Okay, and the, and creating the four different kinds of menu was not an easy task for us because it was like four different scenarios which they were using in the ship. And the first one is what you see here is the static menu. So, static menu is basically, for example, take Cheesecake Factory, which has the largest number of menu items, like 250 menu items. So, it's like constant like throughout the season or throughout the year. So, even in ships, we have specialty restaurants or the room service menu, which is constant, which does not change to entire year. And that's what this kind of static menu is being used. If we had to only create this kind of menu, it was a quite simple job with Drupal, but moving forward with the complexity, I'll go with the next one that is the special menu. So, what this is like, we know in ship there's a lot of events happening, right? And say, it's somebody's wedding happening, so a guest of 300 who comes for the wedding, they have to set a different menu for the wedding. They can't give the normal food. So, they go and request to the chef saying that it's a special location and we need a special menu. So, it is like planned like a voyage before when they give the request to the chef and he asked with all his ingredients with him, he has to create a menu for that particular guest. Or say, if a guest of 300 who are vegans who are coming into a ship, they accommodate those guests by making a special vegan menu for them. So, this is made on fly. Not on fly, it's basically done on a previous voyage so they can plan for just one voyage before. But these menus are not set as not done from the shore side. It is done in the ship itself. That's the second kind of menu. Going to the third kind of menu is an ad hoc menu. So, you know how it's buffet, right? In the ship, we have voyages which is lasting from three days to 100 days voyage and you can't serve the same food for all the 100 days in the ship. So, we have to keep on changing the menu and that's when this ad hoc menu comes because say, you can think like you can create this menu beforehand but the problem is we have the menu has been created based on demographics, based on the ports you go, based on the itinerary, where all this has been taken into consideration and based on all these parameters, we have to create this menu. And this menu is only done on the ship side because they have the rights to do it. And moving forward is the most complex time of life menu, that is the menu sequencing. Talk about menu sequencing. So, this is for the main dining room. This is where the most of people eat every night. Now, menu sequencing is say an example here. It's like say a four-day voyage. We have Italian, Asian, American, Mexican for a day, one, two, three, four dinner, let's say. Now, the ship has based on where they are, what time they come into a port and what time they leave the port. So, for example, the ship is leaving at 10 p.m. at night and the chef wants to make sure that the passengers enjoy this food. They would switch the menus between days. So, what happens is the show side will give a recommendation just for planning purposes. Standard menu saying that this is what your recommendation is, but the ship has a override capacity based on which region they are, what's the weather condition, they could switch menus. This we call it menu sequencing. This is a task they do in the ship. So, we had to build a system which gives a flexibility for the ship to control what they do as well as have show side the visibility of what is happening in the ship. So, that was a very tricky thing to do and we kind of achieved it. I think we did achieve it. We'll show you a demo right after this. This is the first part of the demo. This is one part. If anybody has a question, this is a good time to come up and talk. You can come up with the mic if it's possible. Thank you. So, do you want to show that? So, I think I'm understanding that you're doing a short of ship communication with the Migrate module and I'm wondering what the contingency is on the ship if that breaks down, if you lose connectivity or the migration fails for some reason. As I said, the ship has Drupal instances on board. So, it's not necessary that we have designed everything with that assumption that there could be connection problems. So, in most cases, we have done so much on Migrate, updated that it only transmits a little bit. There are good cases where the ship is disconnected for a couple of days, but we have come to a process where ship can run independently. So, that's how the entire system was designed. We can talk to you about that detail offline, but yeah, that's how we have done it because we knew going into the project, that's the uniqueness of our project is it is built around failure. That's how we architected it. It's not like a cloud instance where you know there is connectivity, only in the rare cases that Amazon will go down where you still have connectivity. Our case is not that. It is very much possible so that the connection will go down regularly. So, it's a different architectural thinking that we had to do, but we took all those from what we built on Princess at Sea, the other application that I was talking about as a guest experience application. We had built those for the last five years. So, that's what we are going to do. We also have a session tomorrow. It's a good plug for you, Nate, which is we are talking about our DevOps methodologies of how we implemented DevOps to deploy to these remote environments. So, last year we did around 3,000 plus deployments to the ship. Every week we have two deployments that goes in. So, check that out in tomorrow's session, Nate. It's called the Realized Stories of DevOps. So, you might have more information there. So, going back here, let's focus on a couple of things here. There's a lot of things afterwards we can go and talk about if you want to see it. One thing I want to talk about is the menu item. We go into and one thing to note here, the admins here are chefs.  Everything is custom built. You'll see a lot more technical. If you have technical questions, please feel free to ask. But everything is custom built so that it's easy for them to see and understand in their way. So, it is built with them. So, here menu item. They click on a menu item. And you'll see there's a list of menu items. And if you click on edit, we have around 5,000 of them. We had to redo the search somehow to bring it up much quicker. The contrast is not very good, but at least hopefully you can see. There's a menu item name here. Which we define menu items. There's a short name that is for the waiters and the galley. Because they don't know the Italian name of a dish. They're not used to doing that.  That's what they know. So, there is a short name and the passenger friendly name. So, that's for the galley. When we found that, you know, they don't understand exactly the long Italian definition of a dish. We had to change it and create something for them. Then there's a description. All of this is translated, as you see on the top, into nine different languages using Lingotech. Then we can add the skew numbers, the pricing. Also categories of which menu category it falls into. We used a module called chosen. You could quickly add, because the same item would be a salad, would be named differently in an Italian cuisine versus a Mexican cuisine or an Asian one. So, it could fall into different category names. They also have subcategories, all the proteins. The lifestyle choices, in fact, have alligator protein. So, we have all of this, as well as the regions. So, there are region-specific menus. Like a baked Alaska is available only in Alaska. So, it is targeted only for Alaskan region. So, we can target by region, by ship, all and by menu. So, specialty items will show only in the dining rooms, fine dining rooms. So, those things are also built in as a menu item. It also goes much more deeper of what are the sub-recipes, as the gentleman was saying, could be the salad, that goes much more deeper in a different section. But, going back, restaurant menu. So, this is where they create the master menus, where they pick a menu, want to create one. So, all they do is, in the ship, if they want to create a menu, they just select the voyage. It's very limited, but it's also controlled. And they have freedom to add stuff, too. So, they pick an itinerary day. So, they say it's an eight-day voyage. They pick day seven, and the dining location, we have so many dining locations in one ship. So, they pick main dining room, and they're talking about which meal time. So, dinner. This is all custom created for the admins. It is not even for the guests. Now, the menu name. So, they have all the master menus that we call, from show side. So, it's Italian menu. It's much zoomed in, but you can see this. This is a menu that is built based on the taxonomies added, the tags added in the background. It builds a menu for them, based on the region they are. It just builds a menu for the ship. Now, here, they can review this. They can move around things if they want to move items in the menu, or they can remove one, because they have an ingredient problem. They could not pick up a chicken from a port. But still, they want to add another, so, oh, they got a gnocchi. So, no, zucchini. So, they add a new item. So, we had to rebuild the whole interface so that it's easy for them to understand how to build a menu. They can also add sections, you know, move sections around. So, in case they want to add. So, if you see dessert can be removed up, or section can be removed. It's like pretty much a layout system, which is a chef-friendly layout system that we had to build. Also, search goes through and searches the 5,000 of our menu items. It is not limited. So, this is how the menu was done. Move forward. So, on the ship, we talked about the menu sequencing. This is where they select what menu goes in which day. And this is what they do once for the Future Voyage. They pick a itinerary and then pick a dining room. So, it shows what has been recommended from ShowSide. If you see, it is a voyage. It says it's day one, San Francisco, arrival time, departure time. What is the recommendation from ShowSide? This is all the different meal times. It shows D1 is a recommendation from ShowSide. The ship can change it to some other menu based on... So, they change it to Chef1. It actually highlights for them and says you have switched it. And in case they want to make a change, they can click a change and they can do the same thing that I said, modify that menu for that day. So, this change happens only on the ship for that one day. It does not modify. It's a node copy that happens. So, it creates a copy of the node and then it lets them modify that. It is saved. So, the ship will have a menu. However, that information is immediately transferred back to ShowSide saying that there's this change that is happening in this restaurant for that day. So, all of this information is fed back to ShowSide so they can plan accordingly what is happening and check with the ship if there's a costing implication. So, all this information gets kind of real-time based on the connectivity. But they have a dashboard to see what all changes happened. So, we built that entire back-and-forth system. Now, moving on. So, at this time, they go back and assign. That's the only thing regular basis on the ship do is they go in every restaurant and make sure that the menu for the next voyage is same. And once that is done, every dining location will have a menu assigned. So, that's the first step that we did. This is where we used Drupal heavily. And from this point, it kind of distributes itself. So, if we go to the next slide, there it is. Hopefully, it shows up. Yes, it does. So, as I said, the menu was assigned now based on each day of the voyage. Now, it goes into Princess at Sea for passengers to see the menu for that day so the passengers can see, the guests can see the menus for that any dining location for that day so they can choose where to go. As well as we have built for room service and everything, we have built the transaction into it so they can order for room service. That is also controlled. We built the entire system for that. Digital signage, as we talked about, the canvas as well as the production side. Now, going back to room service. When you talk about room service, you can talk here. Yeah.  So, for the last 50 decades, Princess was also doing the same thing. They give a menu card in your room where you have to take what items you want for the next day and or you can use the telephone to call the room service station and say what you want for the next day. So, since we had the menus in our system, we thought why not make it digital? And that's when we converted the first kind of menu, the static menu into the digital platform which we call Princessy so the guests can come in and place their order for the entire voyage. And this system was built in Drupal where they could see the menu and place the order. Then we created a room service system where this menu will go to the room service station and they can process the orders. One of the interesting things which we did there is like all the orders which are coming in could be printed out from a thermal printer and based on that they could sort orders and do all the stuff using the sorting system which we built. And this was done using Angular over there. So, in a given day we deliver around 500 breakfasts to the cabins. Now, we had to build a delivery system too, which we did. I think we're talking about so many systems but yeah, it's a lot. Where the person who is in the bell box which is a room service station they can orchestrate what is happening. And when the waiters, we have 10 or 15 waiters based on the day will go and deliver food. They kind of know what happens and when they have delivered they have a fulfillment message which goes back to the room service section so they know exactly and the customer experience is kept. So, that was done. I'll quickly go to the next one. We also did a reservation system where earlier the chefs did not know how much they should plan for. There's how many reservations were there. They had to call back to the dining line. There could be 100 people coming to the fine dining restaurant or it could be like 80. They don't know but based on they could plan. So, now we connected that to the dining line. It's what they call. So, the reservation is streaming in live for the chef to make decisions. We also created the table side assignment. So, when you walk into a restaurant, the restaurant manager can assign you a table which sends a message to the waiter because it's a huge restaurant. If you can imagine it's like 800 people sitting in a restaurant. So, a restaurant manager assigns a table to you and the waiter knows somebody's coming to the table. How many of them are coming to the table? He can arrange the table if he wants. Make sure everything is good so that the best experience can be provided. As well as there's a digital table side order system that we built. Again, we'll have time to show. We'll show all those things. That was also built where they can quickly take order. The order the chef is taking gets streamed into the galley for the kitchen display system. So, it'll be like 150 steaks. So, something like this is very simple. But all the orders coming in from the different tables stream into one screen for the chef to prepare. As well as if you go further, the waiter also has a meal track if it is a non-digital place. So, they take paper and take a digital system. So, we'll show a quick video of what happens. When there's no fully digital system, they take orders and they mark what is going back out. It's a very simple thing to do, but it kind of connected everything together for the chef. You see, there's been the background. So, we go to the ship, work with them, and then understand what they need, and then we build there. So, we have one person from culinary who go to the ship and three people from our team. Because it's a digital transformation. So, we have the culinary person helps us speak the chef language and we take it and talk to them and build something on board, living in the ship. And that's why our application success is that we never have rework because we work with the waiters. We work with the chefs. We have another video which comes up later where we see how they're comparing notes between the butcher and the chef, which never happened in the past. So, moving on. So, all the information that's happening from the kitchen display system plus the menu, meal count, the executive chef who's controlling 16 restaurants, 17 restaurants in his office can know restaurant which is say Da Vinci, which is a restaurant, is running out of chicken. Because the people there order all the chicken dish. So, what action should he take? Should he let the waiters know that please promote lobster tonight because we have a stock of lobster? Or should I request the butcher to bring more chicken to that galley? Earlier this used to be used over the phone. They had a call. It's a panic situation. From his office today he can see what is happening in each galley in a given ship. With that information it's so easy for him to walk around with his phone because all responses will be built and it quickly plays order. The food items will come to the galley and be ready for that. So, this is how it is done. So, all he has to do is like put up plus 100 for say I need 100 portions of chicken, which has salads attached to it. So, it creates an order for the butcher to create 100 portions of chicken. And it sends another ticket for the vegetable section to bring the vegetables for that plate. It sends another notification for the diary section to bring the diary or cheese, whatever is needed. So, every production system gets this notification based on the one click of the chef to say I need to plan for 100 chicken, whatever, and that distributes tickets. There's a full ticket order system that brings in this data. This next one is the video. This is where, just before that let me explain. This is a butcher. So, I think it's a faster second time he's using a tablet. So, and that's the sous chef. And again, they're placing orders and they're comparing notes. And actually, in fact, the thing that happened is the butcher is correcting the sous chef saying that you ordered the wrong thing. You can see there's Davis here and there's Manoj from our team. And I was taking the video and the Greg from culinary. So, what is happening here? He's showing how the orders are placed and then the sous chef and the butcher is comparing the screens. This kind of interaction is so happy to see that because it's never happened in the past. They had something that was happening in the butcher station and something else was happening in the galley. Now it became all standard. They started talking to each other. That's great. Now, it's not bad. The majority who is controlling the front of the house, every single table, right? In the normal day, what he has to do is he is to walk to different restaurants with his team, spread out to find if any table, there's a problem. Our customer is waiting for so much time. But when we implement our table set system with all the restaurants that he has, it's not completely launched, but the idea is he would know every single table in the 16 restaurants or 17 restaurants what is happening. Every click is tracked at what course is table number 27 in Sabatini's is waiting or if the guest is waiting for the last 20 minutes and he needs to take a remedial action, he can do it from his office. And this was never possible. So all this information, just like the executive chef seeing everything that's happening in the back of the house and his restaurants, plus the major DCing front of the house for customer experience, all this information is happening in one ship. They can see what is happening in one ship. Show side, all this data gets streamed in from all the 17 ships. So now, when you have so much data coming in, we never expected to see this much data, but it's a quality problem. Now, once you get this data, then we can do really interesting things with data. That's what we're trying to head to because we never had this much data coming in and we're trying to do predictive analytics, things like that, to even say further, on top of standardization, based on say one scenario, say the ship is in Alaska, we have a specific demographic and the weather condition is based on it, we can help the chef. Today it is his knowledge that, okay, I see so many Australians and I know what they would like, so let me plan accordingly, but in the future, all this data coming in, we can predict what kind of items you should you plan for, where people might eat. If it is, say, it's rainy weather, you might not have people on the deck, they might be coming into the dining room, so dining room can get alerted. So such a level of predictive information can be given to the chef. On top of it, food safety is very, very big for us because we need to know what happened. So once you've connected the butcher to the store, to the galley, to the waiter, to the guest, if you think the entire line we are connecting, you know who touched the food. So if there is a recall for a specific type of item, say Jesus being recalled, we know exactly where it went. And it's much easier for us to track what happened. And the data in our entire platform, there is no edit button. Everything is tracked, every click is tracked, so we know exactly what is happening. Training opportunities for the chef or butcher can be tracked. What is happening will be seen, and that gives us auditability, and everything can be traced of what reaches where. And with that, we'll show a quick demo of the application that we have been talking about. So it's a lot, but we'll just try to show some pieces of it. And anybody who's interested, we can take it after the session, we can show you much more what we built. And this is entirely angular-based application taking the menus from Drupal, the itineraries from Drupal, and it heavily depends on Drupal, but it's completely decoupled. So this is the next level, I believe, for Drupal is not 100% dependent on Drupal, but it's mostly there. But it can do its own thing. It does couch DB, it's saving this data. So in case something happens to Drupal, couch will let the application run. So we'll start with Chef ordering. That's pretty interesting. So if you see, for the Chef here, it's very simple. In his tablet, he can see which day of the itinerary it is, what ship time it is, what voyage number. It shows you the different days of the itinerary. So he can plan for next two or three voyages in advance. So he selects his restaurant, so he picks Crown Grill, and he picks a meal time, which is dinner. And the entire menu shows up to him. So all he has to do is go through this, see, and then add, say, 50 black tiger prawn. So what happens in the right side is pretty interesting. It tells you it's four kilograms of black tiger shrimp, another shrimp for 2.3 kilograms. It's scaling, based on 50 portions, how much will be requested to the butcher. So it's raw quantity. Now on top of it, we'll have vegetables and other things added to this list. And also he can assign a delivery date if they need the meat a couple of days in advance to start cooking, like slow cooking. They can assign a delivery time if they want. So they can add it. So it's just add. That's it. So the Chef did not know when he was planning on getting the paper, all of this in the past. Today, he takes his tablet, picks a day, puts in the numbers, and his job is done. The food will come to his galley. So he just goes in and puts in these numbers. We see there's another shrimp item. It shows you how much kilograms, and say salads or any other lobster tail. They have 30, 50 dollar lobster tail. So he can just put this number. If you see, it also shows the system is connected or not. This also let him, because we have a limited Wi-Fi. So the application is having local cash. So he can still work, but it will tell them that it is not synced to the system so that the information is not reaching the butcher or not. So the connection is always shown on the top right, if you can see. And also there's a bell sign, which is a notification. It's like Facebook notification that you get. It tells them, oh, the butcher X has seen your order. So what happens in a service time is, say, I'm running out of chicken as an earlier scenario. The executive chef says, I need 100 portions to be ordered now. Based on the service time, we know that it's urgent. So it creates another visible notification, take out the entire screen of the butcher, and shows that immediately you need to stop everything, and you need to deliver 100 portions of chicken to the galley. And when he says, OK, that notification comes back to the chef, saying that the Nate, who is a butcher for today, has seen the order he's working on it. So this kind of communication also is happening. So this is, if you see, the chef's job is so simple. He just presses a button and his job is done. This is where we said we worked with the chef, saw how he was working, how his process was, and completely did a transformation. And we go back, so this is, the chef logs in. He only sees his area. For us in admin, we see all the other sections. So on the butcher, when he comes in, he also sees his today, tomorrow, all the days. And he knows, based on if I'm a fish butcher, or doing the fish, he knows what are the orders coming in. If you see on the left, I don't know if you can see the red sign. It tells him the order is not complete. So he clicks on the orders that we put in now for the shrimp, the black tiger shrimp, and he clicks on it. He says Crown View has 50 portions of the shrimp to be ordered. So ideally what happens is it also prints at label at the same time. So once he's prepared this, all that the butcher has to do is click the thing. It's a ticket that came in. He completes the ticket. That sends a message back to the chef that the item is ready to pick up from the butcher. Simple. It's extremely simple. But we change the way butchers work because they are hesitant to touch any technology. But when you saw this, it's like, oh, his work is done. They have like stacks and stacks of paper. Now it's cutting down because everything is through the ticket. And the ticket is so simple. As well as if he has an extra stock, we can have a section called uncommitted. Say he tried to make 50 portions. He has some extra. 10 portions came extra. He just adds that. And it became added. So he has a stock. So next time the order comes in for more, he knows that, oh, in the freezer number three, I have already prepped this shrimp. So I can go and take it from there. And all that he does at the end of the day, he says the total actual usage. So this gives us all this information for us to process. As I said, we go back to the chef. And also the notification on the right side, we see that's coming up what happened on the butcher side and the chef side. We go back, Davis, we go back to the chef. And I just, I don't know if you recall that I said there is no edit button. Let's say the crown grill, it was, you can add another order for tomorrow. Say 100. Accidentally, I clicked 800. Right? So it created 800 orders. It's an accidental order. So now he has to remove it. There is no edit button. He has to click the plus sign again and say, oh, in fact, I wanted only 100. So remove 700. So he just says 700. Sorry. And remove. So it asks for a confirmation. It says, is it a return? Because I did not use that item in the galley for the evening. So I have an extra that has to go back to the butcher. Or is it trash that I dropped the plate or overcooked. So it's a trash that happened. Or is it actually a typo that I, in fact, I'm my orders extra. So this is how we track every single thing. And they can put a comment if there's a trash what happened. So this is streaming in so much data in real time. All this information they're clicking is also streamed back using couch-to-couch replication. So ShowSight is getting data streamed from, currently it's in four ships. All the data that's coming from every butcher, every chef is streaming in ShowSight and throwing like so much of good data they never had. One example to court, which we saw last week, the chef had ordered say 100 portions, which was supposed to be 100 kilogram of a specific meat. What we found was the butcher ordered 300 kilograms, three times more. And that was happening as usual as a regular thing. We did not know because they were using it for other purposes. The premium meat was being used, where they should have taken some other meat. They had a specific meat for this purpose, which the butcher did not know. But this kind of a race of flag, and it says over request for 200 kilograms, it's around 400 plus pounds for one voyage. So this is for one item and one ship, one voyage. That's a differential that we have. So it's bringing in so much standardization with the standard menus, printing all that we've talked about. Yeah, we'll have any questions? Is it too much? So it's table side. Let's see table side. How much time we have? 10 minutes? So table side is also built, where you see it's extremely simple, it's built with the waiters. So we've worked with them for a week, I believe. So every day morning we used to sit with them and we had a 60% done application. And what we did is we sat with them, made them use every day evening to like say two or three tables. And next day morning we had a debrief with them to say what worked for them, what did not work for them. And three of us were developing onboard the ship. And by evening we built a couple of features for them, what they asked in the morning. And then we test that in the evening. And this process continued for seven days. And this happened because we had a decouple environment, we could do it so fast. And by seventh day we had almost 90% of completed application. The good thing is we took it to the other ship, the waiters, like oh, this is easy, I can pick it up, because it was built, it was designed by the waiters, for them. So there is no other system, I believe, which is as simple and they get it so fast. Yeah, we go and live in the ship. Yeah, it's unfortunate because we work so much. It's mostly 16-hour days that we work, because we are in the kitchen, all we need is food. They'll be making good food for us. And we'll just sit and work. So you see there's sections in the restaurant and they see what tables are there, the color code, they can see it's kind of bright, that's why it's not picking it. They have tables and what is available is listed there. All they have to do is pick a section and a table. It's done. So all they have on the left side is how many guests are listed. The entire menu that we did in the beginning is the same menu as being used for table side. So what the customer is seeing on the digital sign or his Princess Etsy application is the same one the waiter is going to use for his table side order. So here it's so quick that they assign a gender lady or child. That's how they identify a big table, where they start and go around. And they can add and remove the number of guests if it is needed quickly. So let's say it's two guests and every click they can see what courses. So it's so easy to see the numbers in the bottom are courses. Course one, two, three. So there's a kid in the group and I say, okay, I want my dessert, ice cream. In the first round itself, it can be added. So that's how we have built. And the M is for main course. So it's like one, two, three for an M. That's how they understand how the system works because they designed it. So let's say the order is complete. What it does here is it shows course one, course two, course three. What are the different items? And if there's a mistake, they can go and edit the order. Edit, go back and resubmit it. Or if they want to move items between courses, they can do that too. So they want to move the scallop and the soup to the top. It says a guest one, guest two is a lady. And when they're done with their, say, the initial they started the drink, they're done with the drink, they want to fire the order. They click the fire order, so that we don't have a printer connector, that's where I show in the error. It's an actual system. So what it does is it sends an order to the galley. So the galley says on how many items are to be prepared. So we actually created a printer profile. So printer knows it was a waiter printer or a galley printer. The waiter printer will show the guest information, what guest is handling what. The galley will have a collective information of, in the table six, I need five steaks, three of them well done. So it's a collection of all the orders. So we did printer profiles on thermal print.  It actually tracks the time. There's another request from the waiter, because we had so many waiters, if you see, they didn't want conflict between themselves. They didn't want to say that, oh, I ordered first. I ordered first. There's no time when they just printed. So they can compare the print and see, okay, who did the order first? And they get the first preference so that there's no conflict. Because this is a feature that came from them. They're so quick, simple things. We built it with them, so it kind of worked. So once the order is complete, let's say that a waiter does multiple tables. That's what they do, right? They have multiple tables. So they go back and take another table and do a quick order here, same way. So orders were so quick and submit order. See, there's also a dynamic navigation between the different tables they're looking at. So that's what we built. So if I'm looking at my table number eight, I also know what is in table number six. It's course two. So we know how much time before the course was started, how much time the table has been waiting. We also had all this information also streamed to the MaterD. So if you go to the MaterD view, you don't have to view, where the MaterD can see that all the tables from every restaurant tells you that just like in the table six here, it says in the restaurant crown grill, it is table number six is on course two for the last five minutes. That information is streamed to the restaurant managers and MaterD to see what is happening in each table. This is visible shore side. A ship which is in Japan, it's a table in Sabatini is waiting for the last 20 minutes. That information will be shown to the corporate office. So that is a little creepy but it happens. So they can see it because the thing is customers are very important. They don't want the customers to wait and have bad experience. So here we know we can have flags coming up saying that okay 15 minutes, nobody should wait for 15 minutes. So you could have flags set up for, and then a remedy election can be taken. Maybe the MaterD goes up to their table, apologizes and gives them a bottle of wine. Something like that can be done. It's delighting the customer. That's a goal. So this is the table side order. Oh, that's an order. What do we have next? So that's a demo they're going to show. And thanks to Benish, he's our team member who drew all these diagrams. Custom drew for us. I made him draw around 30 versions of it. Because there's no other way to show what the complexity of the problem is. So thanks to him. And thank you everyone for showing up. Thank you very much. Any questions, please come up and talk. Please allow questions. Okay, that was phenomenal. And you guys both deserve a cruise. But here's my question. This is mostly back end, but I'm curious about the digital signage on the front end. How much work went into that? And did you have to follow any standards for like contrast or accessibility or type size, or is there anything that you need to do with that? Very good question. We initially, so how would I put it? It's a no answer. It's a website that we have on the front end is an Angular application which has its own playlist and system that we have built. The accessibility part we are working on now because we have a strict deadline to complete that. But on the digital signage, we have not done the accessibility side of things. So that's an open answer for that. Yeah. I understand. We are working on that for the Princess Etsy application. So once that is complete, that's our primary goal. Once that is done, we'll go to other applications. And Princess Etsy is our customer facing the primary application which is what our Drupal system is. So we are getting there. We are getting there. Yes. Amazing, absolutely amazing. Thank you. So I'm sure like with your app, you're level tracking, same thing with the room. Do you do any of that in restaurant like where maybe it's a key card for the room or is there anything like that that allows you to track individual user? We could do it. But the objective was not to do it for the main restaurants. We actually did a demo of using this key card to identify the passenger. But we didn't want to collect unnecessary information if it's not needed. But for the room service, we know the room number so that's all we need. Which helps in our GDPR thing too because we never collect any information that is not necessarily from the beginning. There's no point collecting all the data for the future in case we don't do that. And we delete most of the user information within the second voyage. Whatever is not needed. There's no need to collect information for more than a voyage and we delete it. And all the messages that we have messaging is all encrypted end to end. That is not the goal for the application to track users. But process improvements through data. What for this dessert? And it's going to be featured in this restaurant tomorrow night. Absolutely. But we have not... We could do it, but we scale back first to focus on the entire platform. Now we can go back. We had a lot that we are coming in. The objective was initially to save money and revenue by standardization. And now it seems like it's much more broader than even what business initially expected. So it's getting much better now. So what you mentioned here is very much a possibility. Thank you. Good question. Yes. Your existing system is built on Drupal 7 but you're migrating to Drupal 8? Yes. Have you exposed Drupal with APIs to these decoupled systems? And that's directly to Couch TV or do you have APIs on the Drupal side? What's that connection there? Very good question. Nate was a good person to answer this but I can help. And we ran into all sorts of problems. In D8, we in fact started with custom APIs and in last Drupal Con and just after that we saw the API, JSON API. So we started re-architecting everything. So we grabbed everything that we did and then we started with JSON API and that's the method we are going forward. So with your decoupled systems I think you mentioned that if Drupal is down they just only connected Couch TV Do they talk to Drupal at all? Yes. Couch TV system is a vendor to Drupal so what it does is it takes information from Drupal and periodically it goes and checks for changes in Drupal and updates itself so that even if Drupal is down the Couch can independently work because we don't want the customer to lose an order. That's a bigger problem so we have to change that level to have a different copy in Couch Absolutely. Thank you everyone.


I'm not gonna do this anymore, man.  Yo, what up everybody? It's your boy Mr. Ghana Baby and I'm back again with another video. This is a simple video. It's time for we young Africans to tell our own story. It's time for we young Africans to know our African story, our African culture and our African word history. We are on our way to go find out the African history. Yeah, you get what I mean? You get what I mean? What's your name? Muhammad. My name is Maya. What is your name? Duru. Wow, in my country, you know Danduru is an insult man. Okay, so you know what we're gonna do? We're gonna meet a young African who is gonna educate us on Gambian culture and arts. Are you Maya? Everybody say are you Maya? Are you Maya? Hey, my brother. How are you? Good to see you. Good to see you too. Are you Maya? Yeah, welcome to the Gambia. Thank you so much. Yeah, welcome. That one is gonna take me around today. Of course. Wow. And welcome to Kajikali crocodile pool and museum. Thank you so much. Where is this place? This is the first entrance and where you have a different masquerade place. Wow. And this type of masquerade is called Nyomi Konkurang. Okay. Nyomi is another place, part of a place in the Gambia where most of these masquerades are mostly found. Wow. And you can see the history of these Nyomi Konkurang. They can tell you that, you know, this is the Mandinka masquerade. Mandinka is a social tribe in the Gambia here that, you know, believe to have this type of masquerade called Nyomi Konkurang. And they said it is a tradition of Nyomi Konkurang. Kanuma normally seen during social ceremonies, like when you have naming ceremonies, or you have initiations. That's the time that this type of masquerade appears in the other part of the country called Nyomi. Wow.  And here is the Jola masquerade. Jola masquerade also is another type of masquerade that is believed to have come from a Jola tribe. You know, in the Gambia here, I think we have seven different type of tribes, if I am not wrong. That you are fuller, you have Jola, you have Mandinkas, you have Seire, you have mangyagos, you have named them, you understand? So this is the Jola masquerade, and this is a typical example of a Jola masquerade, okay? And they said it's a Jola max dancing out during a circumcision ceremony, like in the Gambia here we have the tradition.  And here, this is called Fambondi. Fambondi in our local language, meaning a masquerade that appears on his own without someone making that masquerade so far. So when you say Fambondi, it's a Mandinka dialect called a masquerade that always appears, you know, just as by itself, that you can say that okay. And normally when you see, this is the type of masquerade that, you know, the Gambian people normally fear with, because they will tell you that in the history, it normally appears late night, you understand? And sometimes you can see the noise or the sound of this masquerade called Fambondi on top of your ceiling. That some will even believe that, you know, it flies, yeah. And this is the Kumpo. It's another system type of masquerade that is believed to have come from the Jola community, you understand? And they will tell you that it's a Jola masquerade appears mostly during initiation ceremony, like in a newly boy, young boys at the age of maybe seven, we are taking to the booth, initiated, and then this masquerade will mostly appear during those time. And you can see the ways in which it is, you know, prepared and designed. And there is a culture in the Gambia here, they call it Futampaf. Futampaf. Futampaf. And Futampaf is one of the best cultural soul that, you know, one will not love to miss. You will swear, you will see this masquerade with the long stick here, it will place it on the ground and start to rotate in a style way whereby, you know, you will adore and love it so much. So you can see that these are the different types of masquerades so far in the Gambia here. Yeah, this is the Nyomi Kankuran, you have the Kumpo in Jola community, you have Fambondi in the Mandinka community, and then so far, yeah. This is called Jamba Kankuran, yeah. Right from the traditional masquerade so far. And now we are now entering in some of the traditional instruments used by different traditional, you know, tribes in the Gambia. Okay. So here we started with, we call it Simbing. Okay. In our local language, they say it's a seven string bow have in, you know, pentatonic tuning, one plane of string, it's just trying to explain how, you know, it is made. Okay. You can even see that like, it's a seven string. And then so far, they will tell you that these are the, most of the traditional instruments used by different traditional in the Gambia here. Wow.  This is a xylophone, right? Yeah. It's called balafone. Balafone. In the Gambia, but, you know, it's an African xylophone. African xylophone. Yeah. Wow. Mostly it's used by the grids. Okay.  This a beautiful act, man. Like, you know, we just have to appreciate what we have in here. This is Dundun in Ghana. We call it Dundun. This is called Tama. Tama. In the Gambia, here you call it Tama. Tama. Yeah. It's a Mandinka word. Okay. And then in Wolof, it's another traditional ethnic group in the Gambia here, they call it Tama too. Tama. And in Fula, they call it Tamaura. Tamaura. Yeah. That means you have three different kind of language for this. I feel like most African countries have so many things in common. Because if you go to Ghana, we have this kind of drums and we call it like, how do you call it? Dundun. Yeah. That's what I'm actually learning, traveling within African countries. That's why it's very important for us to know the African stories, you know. Wow. These are beautiful, man. Do you have a talking drum? This is a talking drum, eh? Wow. They call it... Bukhara. Bukhara. It is a three different place, three different kind of drums that is used by only one single person. Wow. You can see, even see in the picture, sometimes it might be more than three. Wow. Whereby one person will be displaying these four different type of drums. Amazing. It is mostly used by, you know, the Jolas. The Jolas. It's an ethnic group in the Gambia here that normally use this type of drum. Amazing. Yeah. This one is called tabala or tabulo. It is a Mandinka word. Tabulo means this. Wow. It's a traditional drum too. Wow. You can see in the picture here. Yeah. Normally in our mosque. So you just send us normally you have them there. This is a horn, eh? It's a horn, yeah. Wow. I went the instrument. Yeah. It's amazing. Wow. This is also an instrument? Yeah. Pombo long. It's called Pombo long. It's here. Oh, this is used for the wrestling, eh? They said it's a Jola drum that is covered out of the wood, out of wood and used to entertain in wrestling and circumcision ceremonies. Yeah. Man, I got a lot to learn, man. Wow. And it is used with two sticks. Two sticks. Amazing. This is beautiful. This is beautiful. So all I can tell you is that it's time for us to know that this forms part of our African culture. So it's time for you to learn something every single day. My brother, come, come, come, come. Tell them your name and tell them your name. They don't even know your name. Yeah. Hello viewers. My name is Nyanyi Commander and I am here to be with my colleague in helping him so far. Exactly. You know, the culture and the tradition of the Gambia. I've been following him so far, not today. So that's why I find it deemed necessary to help him so far in knowing the culture and the tradition of this country. Exactly. I am so pleased meeting you, Maya. And I am telling you a big thank you so far. I think we have a fruitful day so far. Yeah. For all, I didn't know so many things and I'm glad that you educated me and I believe that you've educated a lot of people out there. So I just also want to say thank you so much. He's a historian and make sure I'm going to put his Instagram. Make sure you go follow him. Tell him that what Maya told me to follow you. I am Maya. Peace out. That's awesome, bro.


We're here with Dr. Ali Musfi, a member of the Meridian cardiovascular network, now part of the Hackensack Meridian health family. Dr. Musfi, let's talk about the seriousness of heart disease here on Heart Month. It's the number one cause of death in the US and around the world. And unfortunately, many people don't know enough about it. And they think of cancer, they think of other conditions as being the more dangerous conditions because part of the reason is they know a lot of people who have heart disease. So they don't give it as much importance as it should be given. Here are some unbelievable statistics. One in three US deaths caused by cardiovascular disease. Heart disease strikes someone in the US about once every 42 seconds and 64% of women who die suddenly of heart disease display no previous symptoms. So let's get into some of the risk factors that can lead to heart disease. Well, the risk factors are mainly high blood pressure, presence of high cholesterol, smoking, obesity, diabetes. Now, the great news and there is great news here is up to 80% of heart disease is preventable. What do you do to be part of the good side of that number? Well, first and foremost is to know about heart heart disease per se. Try to educate yourself about the condition. And some of the resources are American Heart Association and American College of Cardiology Web sites from where you can get a lot of information about this. After you have done that, try to do the things that they recommend, such as exercising about two and a half hours a week. And that's about 20 to 20 minutes a day. Nowadays, we have these watches and all that you can use to engage your steps and how long you're doing that. And so that makes it a little bit more interesting as such. Eat a healthy diet, rich in fruits and vegetables. Try to avoid carbs. It has for years, it has always been try to avoid fats, but we know a lot about the dangers of carbs. And it's the carbohydrates, which are the primary things that you need to avoid per se. Reduce your strength. That's again much easier to say than to actually do in our kind of lifestyle. Reduce your weight that goes along with exercise and what you're eating. Take steps to good smoking. If you have been a smoker, that's a poison with every puff that you're going to take. And of course, try to see a physician as such on a regular basis. Now, there are some symptoms that people are well aware of, but there is some confusion in what are some of the symptoms of heart disease. What should people look out for? I think the most important ones are chest pain, shortness of breath, weight gain with swelling, etc. Not weight gain due to obesity. People like to confuse those two. So for example, if you the reason you have a heart attack is because there may be a blockage in the arteries that supplies the heart muscle. And when there is no blood supply or reduced blood supply to the heart muscle, that heart muscle cries out in pain. That's the chest pain that you experience. In some individuals, that chest pain can manifest in the chest. It can manifest in other parts of your body, in the arms, in the neck, in the jaw, etc. So they may confuse that with pain coming from the heart. It's typically on the left side, but it can be on the right side also. So there are many varieties of chest pain. That's one thing. The other thing is the shortness of breath that typically occurs when there's heart muscle damage, heart is weak. And as it's not pumping blood enough, it kind of pulls up into the lung and the person becomes short of breath or gets swelling in the legs, weight gain, etc. And that's a different thing. Now, in some cases, you may not get chest pain, you may get shortness of breath as your predominant symptom as such. So fatigue, dizziness, palpitations, all those are symptoms of heart disease. Bottom line though is when you think you have a symptom, don't try to explain it away on your own. Correct. Get it checked out. Correct. You need to have that checked out. But keep the most predominant things in mind again, chest pain and shortness of breath. All right. Now, there's a lot of information. If people want to go somewhere to learn more on the full spectrum of care and technology offered at Hackensack Meridian Health, what's the best way for them to get that info? I think the best way for them to go on the computer, that's how they have been used to doing it. And it's a very easy method. Again, that's a great website from which you can get all the information. And so is American Heart website. So you can visit hackensackmeridianhealth.org slash heart doctor. Thank you so much for all the info. Thank you very much.


Hi, I'm Tosses with RF elements and in today's episode of Inside Wireless we'll talk about link budget. When designing any kind of wireless link, a good place to start is with a link budget equation. It gives you a fairly accurate estimate of the link performance based on the hardware you want to use. Before we go into that topic, if you enjoy our videos, like, comment, or consider subscribing to our channel. This is a link budget equation. It essentially calculates the strength of a signal on the receiver side considering three main components. The power transmitter radio can deliver the gain of both antennas and any loss that occurs during the transfer. To figure out whether a wireless link will deliver the data throughput we're looking for, you need to know the power of the signal the receiver side will seek, PRX. Starting at the transmitter side, the radio uses some output power, PTX. It feeds that signal into an antenna it's connected to with a specific gain, GTX. The antenna radiates signal into space. As the wave travels through space, it loses strength. This loss of power is called path loss and it grows with distance and frequency. If you want to know more about path loss, click the link in the corner or in the video description. Besides path loss, there are many other components that can add to power loss. Cable and connector loss and reflections, atmospheric loss due to changing weather conditions, obstructions such as trees and buildings, and multi-path reflections from all kinds of services, and polarization mismatching occurring when antennas are not perfectly aligned, and so on. On the receiver side, the antenna has a given gain, GRX. Combining all these together gives us what we're looking for, PRX, the power at the receiving side. These loss components can often be hard to pinpoint, which is why the link budget calculations are often approximate for typical WISP scenarios. Once you have the estimate of the received power and you know the noise floor of the receiving radio, you can estimate the expected MCS rate by checking the data sheet of the radio you use. All this can be done on paper, but most of the radio and antenna manufacturers in the WISP industry have an online tool which does the calculation for you. All you need to do is set up the parameters of your link to get a result. Did you enjoy this video? If yes, consider subscribing to our channel. We'll notify you whenever we release a new one.