 We'll kind of stretch out the intro a little bit to give people time to sit down, but thought we might as well get started here. We're from Princess Cruises. We're gonna do a little talk here about Drupal at sea, how we're using Drupal on board our ships, which is kind of a cool, interesting, weird use case for Drupal. So this is Subbu, and I am Nate, and we're two of the project leads for Princess at Sea, which is our guest-facing experience app on board the ships. Our Twitter handles are down there at the bottom, so feel free to add us. We love talking to people and sharing helpful tips we've had and so on. So a little bit of history about Princess, kind of put in context what the environment we're working on. This is our 50th anniversary this year. We were founded in 1965. We have 18 cruise ships operating around the world, and we carry over 1.7 million guests each year. So a lot of people actually will know us as the love boat. Subbu always gets upset when I do that, so I always do it. He has to do it all the time. It was a pretty popular show that ran from 1977 to 1987. We actually incorporated that into our 50th anniversary celebration this year. Had actually a lot of the cast come out and do the christening and naming ceremony of Regal Princess, our newest ship. So to kind of give you a little idea of what these ships are like and the kind of size of the infrastructure that we work with. Royal Princess was the first ship we deployed our application on in 2013. It itself took three million man hours to construct. It's made of 37,000 tons of steel. It has almost 2,500 miles of electrical cable running throughout the ship. To paint it, that wonderful white color takes 95,000 gallons of paint and it has a 14 ton anchor. And to give you a little idea of the scale of the brand in total, every month at Princess, we serve 14 million slices of pizza on board the ships. Million and a half gallons of soda pop. One million cookies, which I've definitely added to that number. And this is kind of a frightening one. Out of the one million cookies, only 120,000 bananas were served too. So you can see where people's priorities are when they're on board. And enough ice cream to fill an Olympic-sized pool, which is kind of a lot when you think about it. So what are we doing with Drupal? So I'm gonna show a little video here. This is actually made by Acquia with us to kind of promote what we were doing on board the ship and how we're using Drupal overall. So two minute long, give us a good introduction. At Princess we pride ourselves of being the destination experts. We strive for creating a meaningful passenger experience. The company has been in business for many years. In fact, in 2015, it will be our 50th anniversary. We have a fleet of 18 ships delivering an incredible product to our passengers every single day. Our ships are getting bigger and more complex. Princess NC really has kind of fundamentally changed the way the passenger can find information on the ship. When they get on board and they're looking at this application, it has to show them everything from events to itineraries. I mean, Princess NC is the hub of everything they're doing on board. The ability to have a reliable technology delivery platform for us is key. And Drupal really allowed us to do that. Using Drupal as a base, we've been able to basically deploy the app and then we can continue building on that for the future. Whenever there was a new idea of being floated out by the team, there was almost already the answer, a package somewhere within the community. I believe we wouldn't be able to do this without the support of Drupal community. Every passenger facing screen on the ship is connected to Princess NC and their board crew pool. And we kind of want to create a customized experience. So when you get on board the ship and you open our application, you know, you aren't seeing the same thing as everybody else. If you're a foodie, you're seeing events that are more specific to kind of your interests. And that way it creates a unique experience for every crew's passenger. Open Source definitely gave us the opportunity to move a lot faster on our project. We can roll out to any ship within a month's time, which is really great. One of the things that really excites me about this project is that we have a real opportunity to improve the passenger experience overall. From the moment they book to after they get off the ship and have that experience be a memorable one for the rest of their lives. So there we go. That's what we're doing with Drupal. Thank you very much. So the application, it is Princess NC. That's the name of it. We'll go into a little bit more detail about it over the course of this presentation. But we've deployed now onto 11 ships next week, actually tomorrow. Davis, who's sitting right over there, flies out to Hong Kong to install it on Sun Princess, I think, right? Sun, yeah. So that'll be number 12. We'll be on the rest of the fleet by the end of the year. And like we've kind of said already, Drupal really powers our guest experience platform that we're building out on the ships. So what is Princess NC? It's many things. It's a way for the passenger to experience the events on board and see the events and the schedule of events and all that stuff. A way for the passenger to look at their bill at any time during the course of the voyage. It is a multilingual experience for the passengers. Some of our friends from Lingotech are here right now and they definitely have been a key part of making this happen for us. We'll talk a little bit more detail about that later on, but it's a key component for us. And our newest thing, which is actually something that wouldn't have been possible without this platform on board is messaging. Allowing passenger to passenger messaging for free. So before we get too far into the details of what Princess NC is, every story has a backstory. So we're gonna look back a little bit and talk about how we got to where we are. So we started with Drupal in 2007, Drupal 5 building a shipboard crew intranet. It was a success because Drupal really was a platform that allowed our crew members to collaborate with each other, ship to ship. It can be kind of a solitary experience. When you're on a ship, you're kind of cut off from the rest of the world and your channels of communication are actually very limited. So they really liked the fact that they could post things to their friends on different contracts on different ships. Based on that success, we then rebuilt the entire corporate intranet, which was both ship and shore side and merged it all into one for port holes. It was really an extension of what we had done with the cruise connections and taking all this stuff that we had in an old content management system, shore side and merging that into connections. And based on those successes in 2012, Princess was getting ready to do the final steps in the build and rollout of our newest ship, Royal Princess, and they wanted to have an interactive guest experience platform on board. So they sent it to our team because we were able to build out these things with Drupal very quickly and effectively. So at the time we thought we were building kind of a responsive website that would allow the passenger to view their build and their events in a mobile phone. So we really thought we were just building a website. But as we started looking at what Princess at sea actually was and started looking at all the different areas of contents, the different business units, the different content workflows and curation that we would have added on to that, looking at the different systems that Drupal on board would be tying into, like video on demand or digital signage, the printed newsletter, all of these things. We kind of started suspecting that we were building something more, more than just a website. And then something interesting happened. We went to DrupalCon Portland while we were in development. It was actually in a break between when we were out at the shipyard looking at the ship and installing things on the ship. And we saw two keynotes there. One was Dries keynote that year. Highly recommend going back and watching it. It's really interesting looking at it two years later. The key thing for us was really it defined what we were trying to achieve. It talks a lot in that keynote about digital and being digital and Drupal being digital. And the other keynote we saw that really changed our perspective was from Karen McGrane. Again, highly recommend watching that. It's awesome. But really what we took away from that was this whole idea of separating content from presentation, doing cope. That's what we were already starting down the path for that. So we had kind of an aha moment. And that was that we should have a slide full of cats. But really we did have like an aha moment at this point. We had a new perspective on what we're doing in building. And that was that what we were building was really in the center of all of these different pieces of technology on board. That we were touching the VOD system or kiosks, the mobile phones, tablets, desktops, the printed newsletter and all of that. And that Drupal was gonna be at the center of all this and maintaining content for all of this stuff. So we realized something that we were actually doing was causing a digital transformation on board the ship. And what is digital transformation? That is, and I'm gonna read this directly because it's a pretty good quote. The process of shifting your organization from a legacy approach. And that can be technology or just business processes to new ways of working and thinking about digital, social media, mobile and all these emerging technologies. So what it really breaks down to is kind of three key areas. Transforming operational processes, transforming business models and transforming customer experiences. And we really knew we were doing that already so we decided to really embrace that and make it a core part of what we were doing. So transformation of this nature is more than just a technology or a set of tools. You have to start challenging some of your own assumptions. And one of the assumptions that we had was what were we actually building? And as a note, we're gonna show a lot of these kind of behind the scenes slides so I'll kind of say what they are. This was actually Regal Princess being built in Mont Falcone, Italy. It was taken from Royal Princess as we were leaving the shipyard. This is about a year out from its inaugural. So when we talked about transforming our thinking, and this is kind of why this slide works for us here, is that we were building a platform and not just a project. We were laying the foundation for that end user experience that was gonna connect to all of these different things. And we were responsible for that end user experience. So once you've done that, you've transformed the idea of what you're building that has big ramifications. And this shot here is from on Royal Princess during its voyage from the shipyard to Southampton for its naming ceremony. And what you see here is basically as much of the crew that could be packed into the open decks as possible. It's all sorts of people. There's senior staff members. There's accommodations. There's cooks and deck and all that kind of stuff. So that's the next step we had to do is kind of transform our idea of what the team was. We're building something that would benefit the passenger and would have that we would be involved in from end to end, from concept to delivery. And so when you look at this, these are the people that are actually delivering the products to the passenger that are actually giving them the vacation experience. And we were having to expand the scope of who we consider part of the project team or the platform team all the way from us working on these initial wireframes and coming up with ideas all the way to these people actually interacting with the passenger day to day and helping them use the application and getting feedback from them and really bringing them into the process. Oh, and one more note on that slide before I move on, but part of that is especially with Drupal is that these people are also the people that are gonna make this product successful, the project, the platform successful in the end because they are the ones who are gonna be maintaining the content on board and maintaining the ship site. So without them being actively involved and engaged, the project itself could fail. So this slide here is the data center slash broadcast center on Regal Princess. They've got all the different satellite channels coming in they can monitor, there's a whole another bank of screens where they have monitoring for all the servers and all that stuff. So when you're dealing with a large distributed team like this, you also have to think about how you're gonna transform your communication strategy and figure out how ways you're gonna be agile with the distributed team. And we do that, we sat in a couple of presentations yesterday and you see the same kind of tools everywhere. JIRA, Confluence for Documentation, Slack or HipChat for Instant Communication and other tools, Slack works awesome for us, we were doing deployments. We can have a constant stream of what's going on on board. When we're dealing with our offshore teams or working with people in other locations, screen sharing, go to meeting, WebEx, whatever it's very critical. Okay, so this one is unfortunately he had to go home normally, but this is a guy from our team, Jerry. He's on Royal Princess here doing the last 1% of a deployment for something. He's actually testing card swipes and he's in a hard hat because this is actually a construction zone at this point. There's people welding stuff, painting stuff, sanding stuff, all that on the ship at this point. And we like this slide a lot because the idea here is that you're transforming how you execute on the product or the project mode and deliver features and this is definitely something you wouldn't expect to be doing if you're just building software. He's physically out on the ship testing the equipment. This is where really like Drupal really starts coming into play for us. We're able to build stuff out very quickly early on, show it to our business very quickly, get their okay on it and then take it from a proof of concept all the way to the final feature that's gonna be delivered. Messaging was one of those that started out that way. It was a test of some modules. Ratings and reviews is kinda coming up that way too. At Dynamics we're using that to monitor and see the performance of our servers, see where we may be having issues, automatically correct stuff, stash for code sharing, B-hat for feature testing. And of course we're moving into AngularJS right now as well. So this photo here is Regal Princess off the coast of Italy somewhere probably in a tender port. So we'll come back to this in a moment but look at the scale here. What you see over on the left hand side is a tender boat actually coming up to dock with the ship and exchange passengers in and passengers out. So if you think about this right here it's a gigantic ship, it's too big to even fit on screen. You have this tiny little tender boat coming up and that's the conduit of people getting in and on and off the ship when we're anchored like this. So transforming the way you deliver. And in this case we like this because it talks about the constraints that we have this image. That we have a ship out at sea and we have to figure out how that we can be flexible, fast, execute things consistently. We use tools like Saltstack for configuration management. Of course Drupal is a key part here. We basically make the assumption that we're not gonna be able to physically do anything. Human cannot interact with the server on board the ship. It all has to be automated. So we leverage things like features and migrates, drush heavily. For making backups and being able to recover if a deploy goes wrong. We're actively looking at Docker right now to more standardize our environment on board. And make it more flexible than it is now. Like I said before we use drush heavily. It's throughout our entire deployment pipeline. There's a lot of really cool features. We also use it as a means of feature flagging too. So that we can build new features in modules, have them on in certain environments and off in others. So when we're ready to activate a brand new feature on board the ship we can just include that as part of our deploy and drush handles the actual activation of that thing for us. It's really pretty cool. Jenkins actually of course manages all the actual orchestration pieces there. And we heavily use Bay rent on our local boxes. One thing to note here is we actually run Jenkins and Solstack on board the ship. Just because in case some of the deployment fails we have auto roll back to the previous known good version. Because we probably may not even able to connect to the ship and then debug. So it has to auto roll back and self heal. So that's one point to note here. Yeah, that's a real critical point too. And we'll go into it in a second. Actually it's a really good time to bring this up because that's actually one of our biggest constraints. This photo is a nice lead in because our biggest constraint really is that we have a shore side master repository of all corporate approved content and Drupal. And then we have all these 18 other Drupal instances running out there. And the thing that constrains actually our communication there is the satellite connectivity. Much like the tender boat and the dock there and being able to dock onto the ship is a limiting factor on how many people you can get on and off the ship at once. The satellite is really a limiting factor in how much data we can send back and forth. And it's also not something we can always count on being there. So if we start a deployment, the satellite goes down, we have to have contingency plans to handle that automatically for us. Especially if the code got out there fine, Jenkins starts this process, the satellite goes down, it's gotta be able to not kill the entire system if something goes awry. So this photo here, this is what they call the bulbous. It's on top of the ship. It's what covers all the radio, the satellite equipment, the radio equipment, all that stuff. There's actually multiple of these. They have different purposes for different, they carry different kinds of equipment packages. But that's where we had to kind of go through this. What does the content lifecycle look like when we have a shore side master kind of controlling the majority of the content? We have these individual ship based sites out there that are handling their own publishing but have to rely on this one. And changes that happen on there that we wanna bring back and then reincorporate into that master shore side system. It's a really tricky thing. It's kind of something that's probably way too big to go into in this presentation. But come by, we have a booth, so swing by, we'd love to talk about if you have any questions about that, because it is pretty cool, I think what we've been able to do there. And this is kind of where that Kira McGrane's keynote really hit us. And the way that the content is really structured is that we are actively supporting multiple different end points with the system. So it has to be reusable, content is reusable everywhere. The ship actually has really embraced, the ships have really embraced this because when you talk about what events, titles, descriptions, images all look like, it's a tremendous amount of work for AShip to manage this library of potentially thousands of unique titles, descriptions, all that stuff for the event listing. And we've been able to now leverage all the ships together to create this like community maintained and curated library of events. So they all can add ones to it. It may not make its way back into the master one, but it has a workflow where it comes back shore side, they can review it, edit it, update the one on the ship and then redeploy it out to all the other ships. So ultimately reusable. And that content type, or I mean that taxonomy type actually has multiple other use cases for it too. So there's a field for the newsletter version of that event description. There's image upload areas for digital signage and for use on princessy. So we can reuse that one image or that one scheduled event to publish out to all of these different endpoints. And this is like I said, a key one. We'll show some examples of this in a moment. But multi-language is one thing we always have to keep in mind. If you haven't done multiple languages yet, be prepared to underestimate the amount of effort that it's gonna take to do. It's a very challenging topic, very challenging subject, a very challenging thing to do right. I don't think we've done it totally right, but I think we've done it 95% right. It is key for us. We're an international brand. We're in China now. We sail through Europe throughout the summer. Which used to be heavily booked by North Americans. Now it's getting more heavily skewed towards Europeans actually booking. So we have to be able to support and through our system all these different languages. And this is a key thing too we'll talk about in a second when I show it. That has made a big difference that we couldn't have done without a digital platform like this. So a couple of the key things we use here. Lingotech, like I said, I can't talk enough about how awesome the relationship has been with Lingotech. They're a key partner for us. We're looking at further bulletproofing our content lifecycle with message queues like RabbitMQ or something along that way. And we heavily use, heavily, heavily use Drupal to Drupal kind of migration, using migrate and services. That's something we couldn't do this project without. So we spent kind of a long time talking about digital transformation from operational and business side. So now let's talk about the actual fun stuff to look at which is transforming the customer experience. So this was kind of the first version of Prinsensee that deployed on Royal Princess. What Prinsensee really does overall is transform the way passengers interact with the ship, experience their vacation, and communicate with each other. We'll show some little bits and pieces of that right now. So this here is actually Regal Princess, I think. The front desk area as it was finalizing construction. Now before Prinsensee, the passenger wanted to view their bill. They'd have to go to the front desk, wait in the line, get a paper print out. Or they could go to a kiosk, maybe wait in the line, and get a paper print out. Or wait until the end of the voyage, get a paper print out of their bill. And those are kind of the three ways. Now they can pretty much view this at any time on their own device. It's on demand. They can go and look at it at any point. It's up to date. Basically, I always go and buy a martini when we actually get it up and running so I can test to see if it is actually billing me right. That's just what I say to hide the fact that I like martinis. This is where it gets kind of cool though. As we've rolled this out, the staff on board, we hear this from them anecdotally. We've seen it a little bit. But it's definitely decreased the lines of people waiting for this bill at the front desk. They actually have come up to us unasked and said, this is great. This lets us focus on really helping passengers who may be having a real problem, not just wanting a print out of their bill. And from a budget standpoint, it's great too because now we have to print less junk out and don't have to spend as much money on paper and don't have to throw a whole bunch of paper away or incinerated or whatever. And one thing that this has also done is allow us to do kind of uniquely digital things. Like adding a filter on the top so they can actually look at the different kinds of things they're spending on. So they can kind of manage how much they want to spend and which different areas a little bit better. And it's really designed to be simpler to understand and look at and all that stuff. Even though it does have dollar dollar sign tours and stuff like that on there. That's the system that feeds us. That's the problem we're working on right now actually. Okay. So there's a few of the modules we used to make this happen at the bottom. We'll have those on a few of these different slides. So this photo here is from during Royal Princess inaugural. It's actually the upper deck on board the ship. We have kind of a, I think they call it watercolor fantasy or something like that. A one note, all these photos Sabu and I took to here. So if you think they're cool, let us know. We'll feel good about ourselves. So this is kind of some of the kinds of events that we have. The ship is a hotel. It's a dining place. It's a mall. It's a bunch of entertainment. So it's all self-contained. So there's a ton of stuff to be doing on board at all times. Before Princessy really like the passenger had to look at a printed newsletter every day, which is actually pretty dense with a lot of competing things. Ads, venue hours, the note from the captain, all this kind of stuff. But after Princessy they're actually able to do quite a few cool things beyond just looking at the events even though that's a key part of this is being able to see these up to the minute events. Sometimes event venues change like what happened actually this morning when they had to announce a whole bunch of time changes for different events that were happening here. We can just go in and change the time and so on on here and it's updated immediately. Occasionally, weather might be too bad. We can't go into port. So that means the entire day's events change like that before they would have to actually go print a whole new run of the Princess pattern which is our newsletter to let people know what the new events are gonna be on board that day. Now they can just go in and do it immediately. So we're able to show more detail than we could in the printed version of the newsletter. We're able to show deck plans where the thing is let them slide around, get more detail about this stuff. Some of the other cool things we can do now that we have this kind of a platform out there is we're able to now extend this concept of an event to passengers themselves. So they're able to actually go and create events that only they or the people they invite can see. So that also implies they can share these events and more than implies that it actually allows them to do that they're able to create an event saying let's go meet for dinner at Sabatini's at 8 p.m. Share it to the people in their group and now they all have it in their personalized schedule to go see. And for us, one of the things that is a benefit both to the passenger and princess is that the passenger can flag events that they intend to go see, create their kind of own personalized schedule and then what we get as a company which is awesome is now we can see how what are the events passengers are planning to attend? And do we need to change maybe the amount of crew members that are deployed at this event if it's much more popular than we think it's gonna be? So we can have more bar stewards out there making sure the passenger gets the kind of service they want. And here it's kind of like what it looks like when they craft their own schedule the homepage totally changes into their personalized schedule. So this is a key one for events. What I'm gonna show is not actually screenshots of events but just general stuff but this has been a huge one for us. Being able to display these events in multiple languages on demand by the passenger powered by Drupal and the Lingotek connection that we have. But previously we really could only print multi-lingual event listings on demand. If we knew there were guests there and if we had the proper people on board to be able to make sure that the language was correct, all that kind of stuff. Now we can do this whenever. We're using the standardized library of titles and descriptions that are pre-translated. The ship just has to select one of these pre-translated items and then now magically we have the entire event listing and whatever languages we support. Currently it is limited to Chinese and Japanese, we're launching Spanish later this month and then we'll ultimately have nine languages available. French, German, Portuguese, Russian and I can't remember all of them, Italian. That's right. The ships also have the freedom to create new events which may not be translated initially but we have a workflow that's been created so that the events are getting migrated back to the show set instance, gets translated through Lingotek and comes back to the ship when it's ready for showing to the passengers. So this is kind of what Sapphire Princess looked like over the summer last year. We were able to leverage Drupal's language detection on the device so people that were coming to look at it and simplified Chinese would automatically get the version in Chinese. I knew we must have done this right when I used these slides and presentations with native Chinese speakers and nobody started laughing at me or showing something crazy. They actually, I kept asking, does this really say what I think it means, what I think it says and so. But this was really, this is a key feature for us. This is a huge thing for us to have in China last year and Japan this year when we launched it on Diamond Princess a month and a half ago. And I can't really, I just can't talk enough about how great the working relationship with Lingotek is and there'll be a reason why we can talk even further about this at the end that I'll show at the end of the presentation. Here's kind of some of the modules we use. Don't worry about writing all this stuff down. It'll be up for viewing later. So one interesting use case that we didn't even think about was the passengers and crew talk using this for communication. So just in case a passenger is a non-native speaker and the crew doesn't know how to speak to this passenger in that language and if the passenger is looking for something, they actually browse to the location in English and then switch the language and show the passenger. So this was used as a means of communication and which we never thought that would be used like that. Yeah, and that was a cool one we heard on deployment is actually one of those things like, just behaviors that start happening when tools like this are out there. Okay, so now we're gonna talk about one of the big challenges on board and one of the things that is actually unique to having a platform like this out there. This was kind of a comedy photo we took on Coral Princess during our deployment. We had these speaker phones in the room and we could hear everybody else on the speaker but nobody could hear us. We found the way to do it was take the handset up and speak right into the phone like it's a microphone. So that leads us into kind of the big feature that we launched that's rolling out to all the ships right now, messaging. So when you're on a ship, it can be kind of hard to coordinate with all the other people you're traveling with. There's not really, there's phone and voicemail and all that stuff but that requires going to your state room, checking your voicemail and who wants, you're not on the cruise to stay in your state room all the time, checking your voicemail, that's what you do at home. So to combat this, some passengers have gotten pretty creative. I think we talked with somebody earlier today who's planning or was planning to get walkie-talkies to keep in touch with each other. But what messaging really allowed us to do was to provide kind of a text messaging platform for the ship. It's not really a text, it's more of a chat kind of thing. Doesn't require any charge, it's free. That was a key driver from our president is that it should be free, which I love. So now passengers don't have to bring walkie-talkies on board, they can just connect to this system, use it freely. They can use it in a passive manner where it's more like leaving a note in a box. There's an app they can download additionally that will give them notifications. But this is all driven by Drupal. So the app is native, it's there just to capture that device ID and be able to push the notifications out. But it's been kind of a challenge getting this one out because there's a lot of things to think about when you're activating notifications on a kind of a closed network. So it's been tricky, but it's been, apart from the notification part, the messaging itself has been kind of a transformative experience for the guests. And for Princess, too, because one of the cool things we now have is another channel to send messaging out directly to the guests. Previously, we'd have to make an announcement over the ship's loudspeakers. If there was immigration coming up or change in venue, the cruise director likes to get on there and hear his own voice a lot of times. But we're now able to send these kind of things through the system and out directly to the passengers. And even potentially in the future, target specific passengers themselves with specific kind of messaging as well. And one of the kind of the cool things that allows, too, is kind of like corralling your group. It's not just a one-to-one communication, it can be a one-to-many kind of thing where groups themselves can chat. And the kind of why this even came into being is that socializing the ship is actually a very important thing on a cruise. It's why there's traditional dining where you have a large table with multiple guests who are on different, in different state rooms, may not know each other. The idea is that you meet new people and meet new friends. So we didn't want to have that only tied to that one time you have dinner or those times you have dinner with them. So when you meet them, you can become contacts with them and messaging and then now have more people that you can plan events for through the rest of the cruise. And one of the kind of cool things about this whole infrastructure here is that we've been able to leverage it for a lot of other features. So we have charters and large groups coming on board quite a bit. And this now gives them a way to, instead of having, they actually have like big flip charts like the ones you see here in a table set up to coordinate all their people on the charter or on the group. Now they can use a large group messaging that's automatically set up for them. They have kind of their own space and wall within Rizzi to manage and provide a great experience for their customers who are their members of their charter. So this was taken on Sapphire Princess last year off the coast of Korea. It was, I got up at insanely early hour, one morning for some reason and took this photo. But I like it because it makes me think about the future. So what we have now is really just the beginning, the start of what we're doing. It's all revolves around what we've been able to do with Drupal and the way we've been able to use a lot of the contributed module space and a lot of the great service providers that have sprung around Drupal. So we're planning a lot of really kind of cool features. We really want to extend kind of this sharing concept beyond just the ship and out to the world itself and your real group of friends back home. So we're looking at ways we can integrate social into this. We definitely want to get into more transaction stuff that's coming very quickly down the pipe. We've been experimenting a lot with ways we can do kind of location aware on board the ship. We can't really rely on GPS because you're moving constantly so we have to look at interesting other ways to do that. And one of the key things for us is as we get more and more information about the passengers, we're on a very space constrained device. We need to be able to provide more relevant information to the passenger without throwing too many things at them at once so we're looking at all sorts of ways we can do that. Of course all of these are made only the more fun and challenging by being on a ship out in the middle of the ocean that can't use any cloud service. So the challenge that we have is like Drupal itself is powering digital signages, video and demand systems and everything like and our primary use case is also the passengers and personal devices. And we have, we do too many things like e-commerce like we have messaging, we have information, we have everything into one tiny screen. So we want to build more intelligence towards it so that when the passenger looks at his like profile and how he gets what he needs to have. But we have real-time engines running around like we have it here but it's getting to work and on board the ship is a big challenge. We're working towards it. So if there's one thing though that this entire project up to this point has taught us is that Drupal really is a platform for making platforms. It's very, very flexible. It's geared towards what we want to do which is be digital and cause these digital transformations and therefore Drupal is digital. Going back to like what Drew said at that keynote two years ago really resonated with us and the direction we're heading. By the way, this was taken off of Japan as the sun was setting and I just thought it was nice that this is the way the land of the rising sun says goodbye to you is by the sun setting on a beautiful ocean. So thank you very much for listening to me, and we're on for 45 minutes. Couple notes though, we do wanna do some questions and we're gonna bribe you with some giveaways. So whoever asks a question, we'll get an umbrella or a cookbook, princess cookbook, so it's branded. But two notes, we are hiring. So please, if you or anyone you know, it's thinking about working at somewhere kind of cool and weird and fun, stop by our booth. I'm there quite often. Actually, Subbu will be there quite often. A lot of people from our team are there, so we love talking about the project and what we're doing and finding people that mesh really well with the team that we have. One other note, and this is definitely one that you should plan on attending, we're doing Lingotech as graciously invited us to their booth tomorrow for a couple hours for a session, well it's not really a session, it's more about beer drinking, kind of fun, Q&A kind of thing, called beers, boats and booths. It's tomorrow from three to five at Lingotech's booth, which is booth number 806. So definitely mark that on your calendars, there's gonna be some cool swag you can get and all that. While we do questions, just one note, please leave feedback for us on what you think of the session. Was it helpful, was it cool, was it terrible? Leave it all. So let's get started with the questions. Great presentation. Thanks. What do you guys do to disseminate user logins? Does each fan, even one login, or does each person have it? How do they get access to the bills, et cetera? Sure, so right now the user logins are tied with their booking onboard the ship, so it's directly tied into their shipboard account. We are gonna be integrating that with our princess.com login in the near future, so it'll be a one-time persistent, only one login, single login. Right now though, it's really just there for use when you're on the ship, and when you leave it, you lose everything that you set up on the ship. That's something we really wanna change. So like contacts you create on the ship will follow you around all of these things, so. So if you have a family with like four kids, for example, do they all get their own logins? Yes, yeah. So it is unique per person, and that's mainly because of the billing, the way the billing is done. Basically, everybody in a state room can be charging to one card, or there can be multiple cards, so there's kind of this layering of who gets to see what parts of the bill and all that stuff. The owner of the card always gets to see everything. The users who are underneath it get to see bits and pieces. So everybody has their own specific login tied to their kind of loyalty number that everyone gets when they take a cruise with us. Thank you. Cool, come and get a book or an umbrella. We only have two umbrellas, so if you want an umbrella, run up and ask a question. Okay, one's left. Yeah. Now you're set for the five times of rains in LA. Hopefully you're from a rainy area, you know. Cool. All right, I have a couple of questions. First, so if a cruise director or the powers that we need to add an event, change an event, whatever, there's, are they logging into a local instance of Drupal and as soon as they add that event, it gets published or is it a thing of you were saying it goes back to state side and there's some kind of approval system or something and then comes back to the ship? What's that process? So there's kind of two things. There's two systems in play and kind of two parts to it. There is a separate scheduling system that they use that does directly tie to us for all the titles and descriptions of events. That populates us and then we have the ability to override or create additional ones in parentheses in Drupal. Those are all content types that's a node that's being created at that point. The actual title, description, images, all that stuff, those are all taxonomy terms. While they create their own events and they can do that on-demand publish immediately, they have a limited subset of functionality they can do on the terms themselves. So there's the short side of proof terms which are locked down, they can't even touch, they can look at them and browse them. They can create new terms which they can publish immediately because the nature of the ship, they may have guest entertainers change all that stuff so we have to give them some flexibility there. But those will, once they create it in the background, it does come back short side. We can do our own editing workflow, republish it back out and override whatever they have with the corporate approved branding. So it's kind of a mix of both. Okay, once it comes back, it also goes to Lingertag and gets translated. So if the event is good for, one ship creates an event and the corporate thinks that it's good for every ship. It'll go for translation and then it gets streamed out to all the other ships for the library on those ships. Okay, and then the other question is, so you have the billing system, I'm assuming is not in Drupal. So how do the two systems talk to each other and you're using services? Yeah, the rule we made early on for every system that was either gonna look at us or that we were gonna look at was everything had to be restful, Jason. There was, believe me, we've had many other systems asked to have direct access to the database, which we've denied every time. I always use the excuse, you don't wanna figure out how Drupal is storing all this stuff in the database and I don't really wanna explain it to you either, so just, we'll create a service, it'll give you what you need, you create a service to us and we can all agree that, then if, say, God forbid, one day we do switch to something else so we can have the service look identical and not break any of the functionality. And you're literally using the services module or are you using something homegrown or? So for us, we do use services module. So everything we do, we build custom services for. The other systems are using their own stuff, it's a mix of, there's Lotus, Lotus Notes stuff, if you believe it, that's where the event scheduling system is in. There's Java stuff out there, there's some .NET sprinkled in there. Mainframe core ball. Yeah, we don't talk to them very often. We sit right next to them but they're a quiet bunch. Yeah. Cool, yeah, that's all I had. Cool, if you want a book or an umbrella, please come. It's a cookbook from the chef. Yeah, the cookbooks, by the way, are all stuff that they serve on board the ships, so give it a taste of Princess at home. Yes. I'm new to Drupal, I just know, I've been in IT for a while, but new to Drupal. I noticed you have 15, 20, 25 different modules that are not Drupal plugged in. What processes did you go through to decide which ones to use? That's a good question. There's ones that we always use, some core ones that we always, no matter what project we're doing in Drupal we use, there's activating multilingual and languages adds quite a few. We tend to look at quite a few things, one, we do review the code of the module that we're looking at adding, just to make sure that we're not uncomfortable with anything. We always look at how many sites have installed that module. When the last commit date was, how many issues it has in its issue queue, all this stuff is, it's great on Drupal.org because you can see all this stuff very easy, it's very transparent. So we look at all of those things, mainly to determine is this actively supported and is it actively being developed. And there is a line in there that says whether it's actively being developed or maintained or it's abandoned or looking for a new maintainer, et cetera. So Drupal.org, that's the key thing. Thank you. Hi. Hello, I'd be interested to know if you did any sort of user testing first of all or if the first ship it went live on, were they the first people using it or how much did you test it out before? Well, the answer is none. Okay. It, the timeline was really tight for Royal Princess. It was a very, very basic site at that time. It was pattern wise, we weren't doing anything to, that felt too crazy. We also didn't really have, it had to roll out when the new ship rolled out and no other ships really at that time had the wifi coverage that we really needed. So we really just, it was kind of rolling the dice. You know, I mean, we knew that it was gonna work. We knew passengers were gonna like it but we didn't really know. We've done more. We do look at feedback. There's a very, very active cruise community out there called Cruise Critic. If you do something wrong, you're going to see it on there in about five seconds. So we look at that. We've started doing informal passenger focus groups as we do deployments, but it's something we lack right now that we really wanna make it a more formalized part of our process. Would that be something that you would expect them, like if they give passengers, give feedback on the ship or do you like send them a survey and hope they get back to you? So we do it, we'd like to do it directly on the ship cause it's in the environment. I think you'd look at the thing differently when you're in the moment versus not but when, you know, if it's usable or not, it can be done at any point, you know? And that's one of the things we're convincing everyone right now is you don't need a large group to get good results. We haven't really determined how we're gonna, you know, our methodology for that yet. There, we're gonna try and leverage some of the stuff that our Princess.com team is using and see how we can extend it even further and go from there. So it's still evolving, you know? Kind of a, not totally succinct answer, but... Cool. Thank you. Okay, we've got three things left, so the three people in the line, so you're all good. Hey, thanks again for the presentation. I apologize if I missed the first couple of minutes but some of the screenshots were confusing. The passengers, do they access this through a web browser or through an app? Yeah, so it is all browser-based. We made that decision very early on because we didn't, you know, cost money to connect to the app stores and download it for the internet really more than anything, so we didn't want somebody to have to remember to do something before they got on board. Exactly, perfect, okay, great. And then also, it's just hosted locally on the ship, right? Yeah, yeah, yeah, so it doesn't, it's not affected by internet assets, outages, any of that stuff. And so that kind of leads into my next question, which is about the future. I mean, is the globe gonna get more coverage? Is that something you guys are thinking about as far as like, is the internet gonna be available in the middle of the ocean someday? Yeah, yeah, so we are looking at ways we can do it. Luckily, the majority of our cruises don't go more than like 50 miles off the coast. So there's, I know there's some stuff that are actively being deployed right now to, you know, we're not raw Caribbean who can do, you know, spend billions of dollars on their internet infrastructure, so we're looking at smarter ways we can spend a smaller amount of money to do that, so we're looking at stuff that's more land-based, is one that's rolled out in Alaska already, and working with our satellite providers to optimize the bandwidth we have right now. Yeah, because I mean, it seems to make sense to host it on the ship, and just always reliable, but I'm just wondering about, you know, you've had to overcome so many challenges with the fact that the internet isn't available on a cruise, I'm wondering if it'll improve your processes if the internet becomes available? Yeah, yeah, and really, then that's the thing, like we do have, you know, it is available the majority of the time, so it's not, it just may not be great, is all, you know. So luckily, Drupal zips up pretty small, you know, so we need to deploy the code, it's not, you know, gigantic, so we're not faced with some of the same challenges that other teams are. It's still, you know, it's one of those things we don't have a good solution for yet, though, you know, real high speed kind of internet access. And I might have missed this too, I'm sorry, but like how do they access, do they just open their browser and it's like when you're at a hotel, it just kind of takes over? Yes, yeah, so it's just like a hotel, we have a cap portal on board, you connect to the passenger Wi-Fi, and any request you make is gonna redirect you to us. Awesome, thanks guys. Cool. We also made the domain really easy, by the way, so we have princess.com, so every site that runs on the ship is the ship name, so royal.princess.com or sapphire.princess.com, so on, so. Hi. So it was implied, I just wanted to clarify, you have no technical staff on board to maintain these systems. Right, so we do have an IT officer, who they are, but they are more of a support person for computer stuff more than a server, somebody who might understand the server or understand Drupal or any of that stuff. We do have a content manager on board, so they manage content purely, but they're not really a developer, so everything we do, we have to be able to remotely support. So do you have a remote data center and a sense of what kind of tools you use out of that data center? Yeah, yeah, so I mean we do have, there is, I wouldn't say it's beefy, but there is a nice sized data center on board, and. Oh, and that remotely, where's your, you have a central? Yes, yeah, so we have our own data center here in Los Angeles, I think is replicated somewhere else too, but yeah, so we have one here, we have a simulation of the ship data center here too. Doesn't unfortunately cover the full in the end, we don't have the full passenger wifi kind of simulation in our office, which has led to some snafus here and there, but. I was wondering about specifically performance testing and what you do for performance testing. So we have an automated pipeline that so every commit goes automatically to dev, it also now, it didn't do this in the past, but it's now triggering our test runs as well on every commit basically. We use Jmeter in there, we use, what else we got, PageSpeed or something, SiteSpeed, yeah. Is there anything specifically in your code that you focus on to make the site more efficient? I'm not sure what sort of constraints you have based on like the ship's server architecture, if there's differences there. Yeah, we actually don't have to worry about it too much. We have a, the max we're gonna have is 4,000 people on there and we haven't had to really optimize it too much to make it run well. I mean, we barely use caching whatsoever on board because it's not an issue for us. We have a fairly decent size VM so we don't have to worry too much about it. More than anything, it's a memory problem that we run into more than anything. Cool, thanks. Recovery from any failure, I mean, that's what we have to look at more than performance. It's more predictability. Yeah, I'm excited.