 All righty, hopefully you intend to be in the business showcase session for commerce guys. We have titled it sell anything to anyone anywhere because they asked for a title before we had content. So we ran with it, and we will be providing more or less an update on both Drupal commerce and platform.sh, the two primary things that commerce guys does, including how it's bringing value to our partners and our direct customers and clients. Just a brief bit of background on commerce guys. We are a five year old Drupal agency based in Paris, London and Ann Arbor, Michigan. We formed the company to be experts in Drupal e-commerce. At the time I had just released uber cart 2 on Drupal 6 and we merged forces with the team from Paris to then relaunch our efforts around Drupal commerce. That's now continuing to grow and do its thing. We're here at the booth to talk about where it's going in the future. In the meantime, we've also decided to build a hosting platform that manages the full development and production lifecycle of any Drupal project, not just a Drupal commerce project, but obviously we built it specifically for our own projects first and have now made it more generally available. So Augustine will talk more about that. We didn't feel good talking about ourselves a whole lot in introducing the session, so I'm going to let him introduce me and then I'll introduce him. We're going to see who can sort of strike the lowest blow. So I introduce you, right? So I'm lucky because every one of you guys know Ryan already, right? He's been the founder of, one of the founder of commerce guys and he's built on his own, almost on his own, uber cart for Drupal 6. It's your daughter, right? On the picture? Yes. Yeah, right. So it's his daughter. He has an incredible family and now he's been the technical lead on Drupal commerce 1.x, the one that you currently play with and he's also an architect of Drupal commerce 2.x that we're going to introduce you today. And by saying selling anything to anyone anywhere, he's selling homie cheese in the US, so with Drupal commerce. So that's very true. And otherwise known as Amish, if you don't have a French accent. Homie. Augustin is also a merchant and a user of Drupal commerce, sorry, okay. He sells his and her t-shirts using Drupal commerce, hosted on platform.sh. This is his, kind of standing, it's a model, right? And you tell us all that you're married to her. I can't remember how. It's also my wife. Okay. Augustin is the product delivery manager for us at commerce guys. So he's the one directly responsible now as of like six days ago for making sure that we have platform releases on time and other product releases on time. So that's who we are. And as an overview of the four topics we'll be covering, it will be a Drupal commerce 2.x update, which is the next version of Drupal commerce targeting Drupal 8. And then also still a look at where the contributed module ecosystem is today for Drupal commerce 1, because we aren't all rushing out to build Drupal 8 websites, I imagine. And then Augustin will give us an update on the platform.sh launch that happened this summer and the voucher system that now sort of drives our free access system that is also available to anybody else building a software as a service tool that needs that sort of building and voucher capability. So without further ado, diving into Drupal commerce. I don't believe he's in here, Boyan. I don't see him. Okay, Boyan Zavanovich is the Drupal commerce 2.x lead developer and my co-maintenor now of the project. And we sort of gave him a trial by fire in Paris in June and July, where we brought all of our partner CTOs and other e-commerce application developers and architects to our offices in Paris to host an architecture sprint, where we more or less made Boyan defend his ideas for the future. So we had Fabien Potentier from Symphony or Cincio Labs and a variety of other folks including other symphony based e-commerce applications join us to validate the proposed architecture for Drupal commerce 2, which involves, first of all, moving code out of Drupal into generally available PHP libraries that I'll introduce in a minute. The idea being now that we have a Drupal 8 core that depends on Symphony and has Composer as a sort of core package management or dependency management solution, we could take advantage of that as well and move code out of our Drupal modules into widely generally available modules to attract perhaps greater consensus from the PHP community to contribute to and use these components. So things like address management pricing and whatnot that are similar challenges for all e-commerce applications, not just for Drupal users. We're trying to build consensus and bring more people to the table to, I guess maybe expand the influence of our solutions and so that's what happened in Paris. While we were there we did first validate a new proposed I guess entity relationship model. So in commerce 1.x if you're familiar at all we have five entity types that we have defined to extend Drupal including products, line items, orders, customer profiles and payment transactions. They're all strung together using custom reference fields that sort of provide a reference implementation of e-commerce out of the box in Drupal 7 and then of course it's up to each site developer or maintainer to I guess add additional functionality to this base framework. So what's an example? Shipping for example is not covered here. So if you need to track shipments and deliveries and have those matched up against specific line items or specific payments for the purposes of refunds or taxing, that's something that you sort of have to add to your Drupal site using some contributed module in our ecosystem. And so we sort of looked at it, decided do we need to do more as a core concern? Can we do less in some cases? And we arrived at our commerce 2.x entity relationship model which I'll only briefly mention is using entity reference field in core for Drupal 8 now to tie all of our entities together. So we no longer have these sort of one off use case specific reference fields like we do in commerce 1.x. I'm not sure, who's used uberkart? Is that maybe familiar to a lot of us and then who's used commerce in the room? Okay, so a few more views commerce than uberkart which is cool, yay. Something got better hopefully. But the challenge is when you develop a big project on Drupal like that as you're developing each new field and each new entity type there are new modules released in the Drupal community that like improve upon what you've been doing. And so each successive field that you write and each successive entity type that you define gets a little bit more complete but you still have all this old code that you have to carry around with you like a weight tied to your foot. And so each of our reference fields for example in commerce 1.x are implemented differently until we finally arrived at the entity reference field but by that time we already had commerce 1.x released. So we didn't have that to take advantage of but in commerce 2.x we'll be able to get rid of about 3,000 lines of inconsistent code and just use the core entity reference field module instead which is a huge win for us. Additionally we are maybe mapping out more entity types than we've had before. But part of that is because we, it's just easier. Like the entity API in Drupal 8 is more robust and more complete than what we have in Drupal 7. But we also realize that there are more things that are inherent to e-commerce than we provided for or allowed for in commerce 1.x. So one example is in the bottom right hand here you can see that we've separated out a payment transaction from a payment allocation. And a lot of people think well that's stupid it's just needless abstraction. But the real challenge comes in whenever you have a payment and you need to refund a part of that payment because some of it went toward this line item, some of it went toward shipping and this much was tax. Well I need to know whenever I come to process a refund is the part that I'm refunding was that taxed or was that just some digital product that wasn't taxed? There's a lot of things there that separating out like the actual payment transaction with the gateway from how it was allocated on an order will make a significant difference too. Other things include no longer separating out products from product displays, which is one of the sort of key steps or differences that we made in coming to commerce from UberCard was the idea that all of your products skews are defined independently and sort of exist in their own table and they're referenced by other pieces of content on the website to create what we call a product display which looks like an add to cart form that may or may not have options that you're selecting. And we had a lot of good reasons for separating things out but we've realized that a lot of those good reasons have sort of evaporated now with innovations in Drupalate itself. So we'll go back to products themselves being displayable entities that may or may not have children that determine things like the size of a T-shirt that you're selecting from a group. But that's two of the biggest changes that we'll have in the entity relationship model around products and also around payment. Some other things will be coming down the pipe like having an actual store entity where you define your store global level configuration or to facilitate marketplaces and that kind of thing. So those are things that are going to change in the entity relationship model, we'll tease those out over time. But honestly, we really dove into commerce 2.x development by focusing on the libraries first and on some of that consensus building first. So the first one that we put up was the commerce guys slash INTL library, which is just an internationalization library that's focusing on currency formatting and management and also locale management. So the idea here is that you may have seen Boyan's blog post on the topic, it's linked here, it'll be linked in the slides. But the idea is that the Euro doesn't have a format. Who here has background in trying to just do multi international like e-commerce in Europe, a few of us? Did you actually use one format for the Euro? Or did you make it dependent on the country? So in the UK the sign might come before and in France it'll come after and in some places it's going to have a comma versus a period and so on. Even though it's one currency, it actually has a wide variety of ways for it to be displayed to the end user. And so this library actually accommodates all of that for basically every currency known to mankind, except for the ones that are no longer used. We have tried to cull out some of the craft from the database. But what's great about this library is that because Boyan started here and did such a stellar job producing it, it is now influencing the direction of Symphony itself. So Symphony 2.6 is going to have our JSON source files or data files here and use some of the concepts that we have implemented for locale and currency selection. And then Symphony 2.7 should actually have this code in it. So we no longer even have to have this as a dependency. So that's obviously not set in stone and if Fabian were here he might take issue. But the idea is that Symphony is generally moving in the direction of the implementation we have here for currency and number formatting, which would be a huge win for us. Obviously one less thing for us to depend on and manage and maintain. Once you have currency formatting and currency handling, the next thing you have to care about is how to actually build and manipulate a price. Because of course if you're talking about European usage versus the US you have different types of taxes in sales tax versus VAT. But even with VAT rules you have different orders in which they might apply relative to certain types of discounts. Obviously if you're doing business to business in a mix of B to C then you have different ways that you have to apply your VAT and manage those prices. So this library is all about instantiating a price object, actually having an API to manipulate the price and then tracking the changes as necessary relative to one another. So that's probably the least developed of the three. The next one being the second most developed is the addressing library. And Boyan recently blogged about this as well if you're interested. As with currencies you have locale specific address formatting and address requirements. Obviously for different countries you have the selection of provinces and states and regions and the like. And what we did in this library is we're still using the XAL, the extensible address language XML schema that we adopted for the address field module in Commerce 1. But here we've actually taken Google's data set from the Android SDK to get all of the address formats for every country in the world and including their locale specific address formats. And so one example is just that if you have a Chinese e-commerce site, if you're viewing this site in Chinese the order of the address elements is reversed from if you're viewing this site in English, even if the destination address were a Chinese address. So there are real funny requirements like that that Google took, who knows how much time, to condense into one giant data set that they've let us re-license under an MIT license and package it up in the JSON files that we can then use both to build address forms and to format addresses for display. And we also differentiate between formatting an address for display on the screen versus on a printed label. For example, in the United States so that the postal services machines can read the addresses for automatic sorting. You have to have everything in all capital letters, whereas on the website you wouldn't do that. So a lot of things are commented by the addressing library. It feels like we finally have an actual answer to the mess of our own creation in the address field module that you might currently be using. And all this sort of leads up to the point that we're doing something right because it's attracted attention not just within the Drupal community but even beyond our borders. So we've often talked about getting off the island in the Drupal community by taking advantage of third-party libraries and not maintaining everything in-house, but we're now actually exporting as well. So we're not just importing new tools. We're able to push our solutions upstream and get folks following along to put us in a nice hot trending spot for one day anyways because they like the solution and they're looking to use them in their own e-commerce applications even outside of Drupal. So if you want to learn more about where 2.x is headed or what's already been developed, Boyan Zvanovich will be leading up off. He's our 2.x lead developer. That will be tomorrow in the Emerald Lounge at 10.45 AM. So that's Drupal Commerce 2 in a nutshell. Yeah, that's very cool, Ryan. Thanks very much. But that's also for the future, right? That's a commerce 2.x coming. But there are already lots of very interesting stuff on 1.x, the Drupal Commerce. And can you tell more about that? Yes, I will, Augustin. Thanks for that prompt. We rehearsed that. Finish up? No, we didn't. OK. So commerce 1.x is also still getting attention, obviously. We're nearing 50,000 sites, which means in probably just a few weeks we will have more Drupal Commerce sites than there are Uberkart sites. So that's kind of, I don't know, who here played Mario Kart a lot on the Super Nintendo? Is that? You know how you could race against your ghost? I kind of feel like I've been chasing that Uberkart number ever since we released commerce, and we're almost there. But that represents a huge traction, more than I ever expected. And what we're finding is that every week somebody is releasing a new module to integrate a new payment system. We're doing several. You might find them in our marketplace, a new fulfillment system, a new niche concern for Chinese e-commerce versus Russian e-commerce versus whatever. I think whenever Bitcoin became big, there were suddenly like six different Bitcoin payment modules available. So we've sort of reached the tipping point where people use commerce as their sort of de facto solution free commerce on Drupal 7. And we continue to integrate new service providers and try to flesh out the weak systems where need be. But there's still more to do. I think the most pressing changes revolve around digitally commerce in the EU. You're going to have changes to how you have to charge tax. I believe it's country of destination taxing for digital products versus source country. And I'm not sure how it all works out. But the idea is that these modules will continue to provide full EU VAT support, even with the upcoming changes. And these are maintained by David Kitchin out of our office in the UK. And then we also have a couple of tax services integrated exactor in Avalara. And I'm not sure if Avalara manages VAT in the EU, but I know exact where it does. So we continue to focus on making sure that you can sell anything to anyone anywhere, including every country in the EU, through both VAT support and multi-currency support. But what has me most excited, and I call it my vertical to watch, is digital commerce. And was anybody here at DrupalCon Austin? A few? Did you catch the digital commerce ecosystem presentation? Many a chance, no? Bojan and David Kitchin were there. It's recorded here for you to go and view. But it basically walks through the entire suite of modules that we've developed to power the billing and subscription management behind platform and behind our marketplace. So what you have in the whole digital commerce ecosystem now for Drupal is the full capability to license digital assets, whether that's membership on a website or access to a file or ownership of a platform. You can then tie that to some sort of card-on-file payment method, obviously managed through a payment gateway. And then you have license billing, which supports both metered usage and just monthly billing or recurring billing. And you then have dunning management modules to close the loop on making sure that expired credit cards get notified and people continue to pay their bills on time. So that whole suite of modules existed. I feel like there was something I'm missing in there as well. It slips my mind. What's that invoice, yeah, invoicing? Yeah, I can't remember. Not important. But the big idea is that I see right now, Drupal Commerce actually provides one of the most robust digital commerce offerings on the market. I know that some of the big names are Digital River and other big digital commerce specific applications. But in what we have here, both with Drupal as the base both to build communities and to manage private files and divvy out access based on any number of parameters. We have the foundation that we need to then just add commerce to it to really create any kind of digital commerce site imaginable. And so some of our biggest client successes lately have been from, whether ticketing or subscription management or digital streaming, video services, or whatever. Anyways, I see this as a vertical to watch. And it's something that I'm most interested in selling today is finding more digital commerce opportunities for us to take on and continue to test and build out the ecosystem of modules around it. So what's next for us is a virtual sprint after DrupalCon Amsterdam, where we'll focus on Drupal Commerce 1.11 release. Some of us may have seen the security release recently for Commerce 1.10. There's more that we hoped to do before we had to put that release out, but we also wanted to get the username bug fixed. So we'll do that sprint after Amsterdam. If anybody would like to join us virtually, there is a thread on DrupalCommerce.org that I can't remember the title of that organizing this whole thing. We're also looking to make significant merchant usability improvements. So in partnership with ICOS, we've developed a new backend that's much more rational for a non-technical merchant to manage returns and do customer service on orders. And I kind of think the last report I got indicated that might have been a bit tightly coupled requirements, so we may have to do some abstraction before. That's totally publishable up on Drupal.org, but I expect that to happen soon. And then finally, I'm also personally committed to refocusing our efforts on marketing and reporting tools. Once upon a time, we integrated with Giraffe that provided a full e-commerce analytics dashboard out of the box in the back end of your commerce site. Then once upon a time, they stopped supporting Drupal Commerce. I can't remember exactly what it was. It was a refocusing on their part on other e-commerce platforms at the same time that they rebuilt their API. So suddenly, we were left without anything except a views-powered reporting dashboard. So I'm in talks with Keen.io, which is kind of my favorite service at the moment, for taking reporting out of the Drupal database and then still having nice fancy visualizations and widgets for the store merchant and marketer to use to track the success of their store. So looking for those things to happen, probably over the next six months, all of the usability improvements to the back end should land sooner. If you have any questions about this, feel free to find me afterwards. And I'd love to get you plugged in to help making these things more robust. So without further ado, I'll hand the mic over to Augustin to talk about the exciting developments in platform.sh. Thank you, Ryan. And I'll take your mic so I can heck with you. Oh, you can't do the reverse, right? Yeah. Hey, guys, sorry for my accent. I'm French, so I need to still work on that. Could you repeat that? I couldn't understand. OK. I'll try to do it better. Thanks, Ryan. And we did reverse that. So any of you guys have heard about platform.sh? OK, that's a small amount. We have work to do. OK. I mean, a lot of work. So we're switched the station. OK, so to just summarize what's platform, platform is the new development and hosting solution that we've built at Commerce Guys. We've been building that for our first on-use case. And then we've decided to market that as a product and deliver that for anyone to build Drupal projects. And now all sort of PHP projects is not only specific to Drupal. You can build any symphony application, any WordPress application, any PHP, custom PHP. Basically, the whole idea is that each Git branch gets its own URL. So each time you create a branch, platform will deploy a complete new environment for you where you can test your feature that you're implementing on that branch and have a complete live environment which will implement that feature. So that's the main idea. I really encourage you to go to our booth to get a demo and just see how it works. Because I'm not going to just go very deep into the details of platform, I'm going to talk about one website that we launched on platform enterprise, which is flixbus.de, which has been implemented by Wunderkraut, which is our platform partner. So they have decided to move all of their development into platform usage for all of their projects. So we're very proud of that. And they have recently launched the flixbus.de, which is a very big website for ticketing systems. So one of the 10 most ticketing systems in Europe. They sell like long distance buses. And why does it matter? Why are we talking now about that project? Because this is really a big project. Their website is where they make business. That's where they sell their products. The website just can never go down. They have to have a very, very high availability. And how do we fix that? Why did they choose platform for that? Why is it so important for them to have platform? That's because our architecture and platform implement a triple redundancy architecture. So we have three, each environment is deployed into three different data centers. We are using Amazon AWS to deploy your website. And each of the project is hosted in three different instances. So we can just kill one host and take down one host or two hosts and your website will still be running. That's very important for them. And what's even more important is that their website has lots of fluctuations over the year. If it's during vacation times, they are going to have lots and lots of sales. And then they want to be able to scale very easily without any downtime. They cannot have any downtime. And what we do is with platform, we can have zero downtime scalability also horizontally, but also more importantly vertically. So we can just make a host grow over time without any downtime by just taking down one host, rebooting it later. And the other hosts are going to take care of the traffic of the website. And we also provide, like since security is really important for any e-commerce website, we provide 100% SSL security. And we use CloudFront for the CDN. So we use CloudFront to really do the caching of all the assets that are served on the website. And the main thing of a platform is that it really helps to keep things organized. Because platforms allows you to have a lot of different development environments. Each branch is an environment so that you can work with as many environments as you want in the workflow that you want. So if you look at the platform UI, it allows you to have lots of environments and you can give each of the environments to one specific developer or you can give it to a client to test on that. You can give it to a specific front end integrator and just start an environment directly for him where he can just test his stuff and then you merge back to the live environment. And you manage all your deployment directly into the platform SH interface. So that's really something powerful that all the other providers don't provide. Like all those environments where you can just test your stuff in the live conditions. And the idea there is that an environment then just sort of becomes a cheap resource. It's meant to be spun up, used, and then once it's served its purpose thrown away. So on a project that I have in Greenville, it's just me and another developer. Obviously we want to continue to develop in parallel to one another. So we have our master environment that then had a sprint specific environment beneath it and because it maintains the hierarchy for the purposes of synchronizing commits up and data down. We then beneath the sprint environment have one each development environment for myself and the other individual I'm working with. And then we're able to synchronize things in our sprint branch and then merge everything back up to master. And then at the end of the sprint just delete those environments and start afresh. And then what's great about having access controlled environments is that if we needed to use somebody else. So let's say we had to outsource part of the development to some consultant or freelancer. We could create an environment that was the only environment that user can access in our platform. So they couldn't then control the deployment of new features or mess up anything else that we have going on at all. So we found that to be particularly useful as an end user of the project. Exactly, specifically for big project where you have lots of people working on the project and not all of them are working at the same time. So you just want to be able to create environment really easily and destroy the environment once the user has been done working on that feature. And if you have any question about platform please come at our booth. We'll have lots of sessions, lots of demonstration about the platform. And I think it's really interesting. But why are we again talking about platform and why did Ryan mention the digital commerce stuff? That's because acquiring customers when you're doing recurring business like selling platform subscription or selling trainings or selling events that's really hard. Like recurring subscriptions, acquiring customers for recurring subscription is really hard. And you have a couple of models to fix that. One of them is the freemium. Okay, you can give part of your project, like part of your product for free to your customers. But since each of the new environments on the platform case for example, each of the environments cost money, we cannot really afford that. We're going to lose a lot of money just by doing freemium because we cannot just reduce the product to something that we can give for free, right? So we've decided to implement the vouchers, what we call vouchers, which is a time-based subscription for free that people can use your product and that people can just say whether they like it or not. And then after a while, you're going to start paying for that. And that's actually, that's been like proposed to DrupalCommerce.org so you can find the voucher module in DrupalCommerce.org and implement that on your own website if you're doing any recurring business. And that's very effective. I mean Google AdWords for example has been using that and they were giving like $100 for free to any new subscription for their product and that we are now all using their product. So that's very effective. And that's also allows your sales team to do their own job, right? They can create vouchers on your website, they can give that to your customers and they can track the revenue of your, like any campaign that they want to create, they can just track what's been happening, when it's been happening, they can improve the voucher, they can really play with your product. So I'm not there. Yeah, that's very important and that's really built by commerce guys and deployed on DrupalCommerce. So feel free to use it and feel free to report it. And yeah, we have lots of vouchers for platform and we're going to give that to you. So just come at the end of the session and ask me for a voucher and I'll give you a voucher for trying platform. I think I'm good and I give the mic to Ryan. Okay, yeah. All right, so that's most of what's going on in commerce guys these days. If there are any questions we can entertain them for a few minutes. Otherwise if you'd like to know more you can come join us at the booth or at the commerce village where you can find a variety of our technical partners there to talk about their payment and email and fulfillment solutions. So I had one in the corner. Yeah, the question is is platform.sh specifically tooled up for commerce? Or is it, you know, generally? Yeah, yeah, it's, no, it's not. I mean, yeah, it's not specific to commerce. Maybe the only differentiating thing would be that you get an SSL certificate for free on any level of platform subscription. I think last I checked it was like SSL started at $100 a month on Pantheon. I'm not sure what it is on AQUIA. But I mean, that's kind of a minor thing. The underlying architecture is much like what you would use for any Drupal website. So the full stack of, you know, IngenX, PHP 5.3 maybe for PHP 5. something, MySQL, Redis, Solar, et cetera. It's all pretty, pretty similar, you know, grid of services. Yeah, basically platform is not specific to Drupal commerce but it's more in a sense specific to Drupal because we are leveraging all the best practices that we have in Drupal. For example, you can just push a Mac file and platform will build your project for you without needing to just pull all the Drupal files. So basically that's really easy to maintain your modules because you can just edit your Mac file and repush something and your environments are going to get deployed with those new versions. So you get your repository very clean. And since we support also symphony applications, we do that exactly the same way with Composer.json files. Yeah, another one on the wall? Yeah, so the question is, how long does it take to build an environment once you've created the branch? So the current response is a bit less than 30 seconds and we are still not happy about that because 30 seconds makes the difference between something that is instant or something that is like very short and we want the instant version. It's a long enough for me to start a chess match. I mean, yeah, 30 seconds like you can, if you're waiting 30 seconds for your new environment to build, you can just switch page and go to Facebook.com or something like that. So we really want to improve that and make sure it's going to be instance. No, they're not there. We are doing like a snapshot of all the containers running at the instance level. So we're not doing an export of the database. We don't have any downtime on the website. We're really doing a snapshot and using that snapshot. Yeah, yeah, yeah. That doesn't really depend on the size of the website because it's like, it's really a snapshot. So yeah, a bit less than 30 seconds for now. Yeah. So that's a good question. We are going like deep into the platform. The question is about synchronizing databases. And yeah, directly from the platform, S-H-U-I, you have a hierarchy between the environments. So when you create an environment, the environment knows about its parent. So if you clone the live environment, you create a child of the live environment and you can synchronize the database from the live environment into the child environment. And then again, that child environment, you can branch it again and synchronize the database. And once you do the synchronization of the database, you can also run sanitization strips using Drush. And those configurations are including to your Git repository, which means that directly from the UI, when you branch an environment or you synchronize a database, you can run sanitization. So all your development environments will not get any live data like user passwords or user emails or... Okay, the CLI, the command line interface that we've provided, which is available on github.github.com, is an extension of the platform. Platform provides an API, and the UI that you saw on the screenshot uses that API, but the CLI also uses that API. So everything that is available on the UI will be available on CLI. And the CLI offers, like, helps you to kickstart your project, like you can branch, you can synchronize, you can destroy environments, but that's not an extension to Drush. You still need, you still use Drush the same way that you were using Drush before. So that's a good question. Now, platform usage, we don't provide a way of just doing your local environment because we think that the best practice is really to have as many development environments live on platform, but you can still use the CLI to build your website locally. That means that if you run the platform build command from the CLI, it's going to build your files on your local server, and they're going to get deployed the same way as they would if they were on a platform, except that you can use Drush to, like, synchronize your database and get the, if you need solar, for example, you need to set that up yourself. Yeah, and platform provides you the aliases automatically, so you just, when you get a branch, you also get the aliases directly, so that's handy. Really, I encourage you to go to our booth and learn more about platform. Augustine does good demos. Yeah. Any other questions about what's going on with commerce guys or triple commerce? Yeah. Is it possible to host it on what? Yeah, the question is, is it possible to host it only in European data centers? And the answer is yes. We actually started, we're not using Ireland for? Both US and Europe. Yeah. Which is yes, right? Yeah, yeah, yeah. Yeah, okay. Oh, not an, yeah, right. So yes, yeah, but yeah, using two different Amazon data centers, one in the US and one in the EU. And the roadmap for platform is to not only be able to get deployed on AWS, so we also want to be able to give you platform and that you can deploy on your own data center. Or Raspberry Pi, or Raspberry Pi, if you have a power from Raspberry Pi, right? I know you do, right? All right, well, we'll tie it off there. If you have any further questions about platform, feel free to come harass Augustine. And if you have any about triple commerce, feel free to harass me. And we'll see you at the rest of the con. Thank you very much, guys. And yeah, come to me to get Voucher if you want to try a platform. I got.