 Yeah, sweet. Thanks everyone. Can you all hear me? Sweet. Yeah, it wasn't expecting a room so full. Thanks for jumping in. This session's about disruptive trends in the web, and this session was given to a customer, a media customer in Singapore. It was originally one hour with the content, so I'm gonna rush through some of the slides and not play all the videos, but by all means check the slides out afterwards and give it a watch of the stuff you missed. A little bit about me. I'm Sean, I'm a technical account manager for AQUIA, working out of Wellington. There's three employees in Wellington, or New Zealand, and I've been with Drupal for about eight years, give or take. And about the session. Hopefully we can give you some insight into some things I see coming this year and next year. It is interactive, so don't feel you need to hold on to that question until right at the very end. Just raise your hand and yell it out. It won't be too technical. I'm gonna paint everything with pictures. And here's a link you can copy down other than having to remember a Google Docs URL. You can remember bit.ly slash dtw, or disruptive trends in the web Drupal South DS. And there's a lot of links at the back as well. So at the back of the slides are like 10 pages of links. So if you wanna research more stuff, you can. The first one is progressive web apps, which is what I call the rise of the service worker. And what this means, essentially it's a set of browser features that enable the browser to feel more like a native application. And as far as what that means feature-wise, you've got offline first. So traditionally, if you're on a web browser and you go to a website and there's no internet, you don't have a good time, right? There is always integration. So you get, it feels more like a native app with things such as app drawers and menu items. You get push notifications. So say you're operating at a news site and there's breaking news in your area, potentially this might be useful. And potentially it might be more useful to synchronize some stuff in the background when you don't even have the website open. So as I said earlier, traditional website with internet. Guy's pretty happy, right? He's a big happy face. And then here's no internet. Now he's sad. As you can see, I'm really good at this kind of stuff, right? Now what we do is introduce this concept of a service worker which acts as a broker and between yourself and the internet. And why that's kind of cool is you can also maintain this cache sort of version of the site as well. So that when you do have no internet. Cache comes, there's a little bit of a sequence that says you're offline and you're dressing up in the site. Yeah. It goes into the cache and then I guess it syncs with the web. Yeah, so the background synchronization can do that. Can like, for instance, it can retrieve recent news items and can store that in the cache. So that when you do come online and there is no internet, you still get a representation of the site. It may not be perfectly up to date because you don't have internet, but it'll be up to date enough. What I'm going to do is I'm like pushing something from your local, you create on your thing, you're offline and then publish that one. Oh, you're referring to creating data locally and have that synchronized later? Yeah. Yeah, I guess it could be used for that as well. I mean, the idea is it's just a bucket you can store stuff in. I mean, there's actually a check in the service worker to say, do I have internet? So in your JavaScript, you could do some cool stuff to say, if I do have internet, then try, send it. And if I don't, do it later. A real life example for this is say that you are on a train and, you know, internet's always a bit patchy, especially in Sydney, you go through tunnels. You get a breaking news item pop up on your phone saying, you know, I don't know, kangaroos broken loose from the zoo. And you click on a notification and you get to read the article immediately, even though you have really terrible internet and all the assets are there and it's generally a good experience. And here's a slide I just ripped off a Google presentation. But it gives you the idea, if you have a service worker, then things can happen in the background. So the initial time to load the page, you get something like, if you've ever used the Twitter app on a mobile where it loads immediately and then when you have it open, it then synchronizes. So you can have a model like that when the first render is incredibly quick and fresh content comes in later, AKA there's two seconds. And the question when everyone's mine is that, can I actually use it? The answer is maybe. About 60% of the devices on the internet now support it to some degree. The most notable exception is mobile iOS. And the great thing about it is that if it doesn't support it, it gracefully degrades. So you just don't get the features that you do get with the service worker. Cool. Next one is accelerated mobile pages, which is essentially a Google initiative to make the mobile web faster. So this or AMP is what this is affectionately known as. So it relies on this new kind of standard called AMP HTML. It's open and it relies on existing technologies such as HTML. And these are, you can link your normal page of content to the AMP version with canonical URLs and stuff like that. Here's an example of that in action. So there's a Drupal module, affectionately called AMP as well. There's a Drupal theme, which you're required as well. And how it works is you just append query per amp on the end of your URL and it will produce markup that will conform to the spec. And then you ask, well, why would I go to all that trouble to make another version of the website? Like, isn't this going backwards 10 years? And it's a good question. Here's some reasons why you might want to think about doing this. Number one, Google caches the content. You don't serve any of these page views. And Google has a CDM. They're pretty good at it, right? They've been doing it for a while now. These pages are by design limited with what you can do. They're optimized for speed. And pretty much all pages on AMP will load on a decent phone these days in one second or less. That's complete. That's done. That's finished rendering or done. You can still use standard plugins or extensions. There are ads, for instance, if you need ads. You can still have analytics. It's just that the syntax is slightly different. There are other extensions as well, like there's for YouTube videos, Brightcode videos, all sorts of other plugins like that. There's zero impact to SEO, as long as you use the canonical URL and point that back to your master version. And there are Drupal modules as well. So if this is something that interests you, give them a will. They actually make it pretty easy out of the box. And if we just talk a bit more about this SEO aspect of things, it's no secret that PageRank does take into account things such as how fast your website loads and whether you're not your site is mobile friendly. And there's a tool you can go to check how fast your site is and whether it's mobile friendly. And it wouldn't be too hard to say that in the future, Google will start biasing AMP content versus non-AMP content. And then this killer question comes up, well, why do I want to give my content to Google, right? It's my content, I like it, you know? Here's some just numbers, just shotgun over the fence. So these are actual media organizations with actual implementations of AMP. And this is what they've seen. And this is quite recent, this came out and I think during these stats as well. So in general, there's some pretty awesome benefits for adopting this. And yeah, the next question is like, for people who have never seen it, this little icon down the bottom, AMP with a little lightning bolt, looks basically what that means. So when you click on that result, you'll get the AMP version. And it will load pretty quickly. At the back of the slides, there's a URL you can go to called g.co slash amp demo, which will give you this experience on a mobile phone. You can actually use it now. So you'll only see it on mobile phone? Correct, yep, it's only on mobile. So if you search on desktop, you won't see AMP. But you get sort of two results on your mobile phone. One the AMP version, one the AMP version. Yep, Google will bias AMP over the non-AMP version on a mobile. And at the moment, non-AMP and AMP will be spliced together. But as it gets more popularity, as people start adopting it, as I said, I think they might sort of change that mentality. And for people that have seen Facebook Instant Articles, has anyone heard of that? Just raise your hand, Facebook Instant Articles. Cool, so about half, but it's like the same thing, but essentially Facebook is very much a walled garden and you need to have a login to get to it and you're in Facebook city once a year. Anyway, next one, Drupal 8. This probably won't be too revolutionary for the people in the room, but I'll gloss over at a high level. This was aimed at non-technical folks. So in general, Drupal 8, content authoring, much nicer. Especially if you add on lightning into the mix as well. And James is doing a talk tomorrow on lightning, so give that a will. That's responsive. Drupal 7 and fingers, not the best. Drupal 8 and fingers, pretty good. Views can expose web services now. So that means making decoupled apps with Drupal 8 as a back end is much nicer. And for the devs in the room, you already know this, but I go anyway, symphony, twig, front-end libraries and more kick-ass testing. So if you went to the last session on PHP unit, this will ring a bell. And what's happened since 8.0? We've had 8.1 come out in April, where we got a few new experimental modules, big pipe written by Wim Lears, who's some sort of caching ninja. Migrate UI, now you can actually see what migration looks like rather than the command line. So that's pretty helpful. Inline form errors, so I don't know, you've ever seen a Drupal, you fill a form in and you stuff something up. Quick save, you get scrolled right to the top with some vague message saying so you fill something in wrong. That module at least aims to make that subclass. 8.2 just came out recently and quite a lot of new modules in here as well. So place block, if you've not heard about these things, definitely jump in and read about them, but place block is basically bringing the concept of going away from the admin in the back end to bring it in the front end. So you can see where you're gonna place the block before placing it. The same with the settings tray module is an attempt to configure certain parts of the site while you're in the site. You've got workbench moderation, essentially. It's been renamed content moderation. You've got date time range, so you can have start and end dates. And big pipe got promoted from Alpha to Beta. So that's pretty good. And I don't know if this will work. It may or may not. Maybe I don't have into it. But does that work on Acreo? Big pipe, I suppose it works. Big pipe, all big pipe requires is, this is a demo for if you don't know what it is. Big pipe is a mechanism for flushing early and keeping the connection open. So you can essentially flush the easy stuff quickly like you see here. And then as your hard stuff renders, it will flush it incrementally. So all you need to have is a connection to a service that supports streaming, essentially. And if you're using Acreo, you're potentially using Cloudflare, Cloudflare supports it. And Acreo balances also support it as well through Varnish. So you can start using this now. Just Drupal distributions. The key theme here is why reinvent the wheel. And so many people love reinventing the wheel, but the wheel is pretty round now. So let's just use someone else's wheel. And you'll find in organizations that as they grow in complexity, as a number of, I guess, web properties increases that it gets quite complex to keep them up to date, keep them consistent. And if you saw Dave Sparks talk earlier, they're talking about a bit of this, trying to reduce that complexity, reducing the custom craft, reducing the snowflakeiness of each site. So the solution, have a look at extracting those common parts of functionality that you use for every single build. And examples are your workflow, your content types, how you do media, how you integrate with social media, your email marketing, your EDMs and use this as a base for all your sites. So things that are out there right now. One example is Thunder. ThunderDrupalDistro, which is Drupal8, which is focused entirely on digital publishing. So if you have a new site, a magazine, anything editorial, then give this a serious consideration. This is funded by a German conglomerate, I think, called BertaMedia. They have like 300 web properties under their control and this is their solution to it. So, and they're still actively working like right now. So in terms of just bundling a whole bunch of functionality that you normally see, like paragraphs for making the content, so they can slam stuff in really nicely. Oh, embed for embedding Twitter, it's all been thought about. And here's a little quote by Dries, but he says, I believe that publishers should not compete through CMS technology, but through their content and their brand. So Dries is basically saying that this is more or less a solved problem for these guys. You know, you don't need to be competing on that stuff. Let's focus on what you actually do well. And there's a video I won't play here because it's just too damn long, but BertaMedia, this are the guys who make it. And check that out later. I need to talk about lightning a little bit. It's, I guess it's a distribution made by Acquia that aims to empower developers to create basically better editorial experiences than they could be allowed. And empower the editorial teams. So the idea with lightning is you don't, you shouldn't need to undo anything that lightning has done. And normally with a distribution, you start with and get, oh, I don't really like that. That sucks. So that's not the idea with lightning. So the idea of lightning, you start with that, it gives you a really good head start, gives you some better content editorial experiences. Gives you a bit of a launching pad. Last thing is this idea of having OmniChannel. So kind of sounds like a buzzword that they kind of like to chuck around at things, I'll kind of break that down to what I mean, well, what I think that means in the context for Drupal. So traditionally with websites, you've got stuff that's risky to change. And you've also got stuff that's, so the risky stuff is anything that requires like change control, like if you've got, like, I don't know, an imported script that's scraping Reuters and then importing that, you don't really want to make radical changes to that imported script. Whereas at the same time, you still want to better innovate on the front end, like the technologies I've just mentioned, you still want to be able to adopt AMP, for instance. You want to do better do that quickly without too much fuss. So you have an idea of an experience platform to which you can drive that out of. And how this could be done is, again, with my sweet Photoshop skills here, you can have your left-hand side click, then the critical business system. So this is the systems you don't change very often. You can think of it like your content silo. And then on the right-hand side, you can syndicate that to a Drupal 8 site, for instance. And then it can deliver the experiences for your apps, your responsive websites, your decoupled front end, et cetera. So this way, you've kind of got a separation of concerns. And where this kind of gets really interesting, if you do have more than one brand, is that you can use that same data to drive more than one experience. So what sits in the middle here is a product that Acre does sell called Content Hub, but basically it's a storage, entity storage engine that stores your entities and JSON and allows you to syndicate that out. So the idea here, Content Hub, would be to deliver experiences to the right user, be the right channel, access that same content through each one of those different platforms, and be able to distribute that content. So if you make an update on that piece of content on one site, you can syndicate that back to the next site. PHP 7, hands up, who's using PHP 7? Nice. That's awesome. So here's a slide, it's pretty compelling. This was done by Jeff Gehrling, and he's a pretty smart dude, but he spun up a bunch of VMs, so they're not perfect, but they're as bad as good as you're gonna get without doing it on raw metal. But this is PHP 5.6, it was the latest version of the time, and no longer is, but you get the idea. It's roughly twice as fast for uncached page loads, and approximately twice as fast for cached page loads. And it's even faster than the hip-hop VM, and hip-hop VM for those that don't know is Facebook's kind of compiling thing that turns it into C code. So somehow PHP 7 is faster than C code, I don't know how. And also consumes less RAM as well. So those requests that you are serving, not only are they faster, they use less memory. So potentially this means that you can drop your hardware as a result of moving to PHP 7. If you use New Relic, this is what your graph could look like. It's a very happy graph. Again, why care about speed? It's just hardware, right? Just talk more about it. Well, page rank is one. You can save money. That's always nice. Then you can build new features. People like faster pages, so make them faster. And here's just a random stat, but about half the people expect a web page to load in two seconds or less. And I think Amazon proved that if they slow down a page by 100 milliseconds, 1% of sales dropped off. So if you're doing it by a second, yeah, that's 10% or more. Perfect. Especially if you use Drupal 8 and PHP 7. Drupal 8 and PHP 7 really go together. The test bot that tests core tested against 5.6, 5.5, and 7. So you guarantee that it will work with Drupal 8. Contra modules, I mean, is everything. They vary depending on who maintains them, but in general, with Drupal 8, you're pretty much set. With Drupal 7, they've just recently solved a lot of bugs with it with PHP 7, but Contra again, might be the thing you need to worry about. But in general, Drupal 8, start there with if you want PHP 7. On Acquire, there is a private beta, which means if you do want in, come chat to me, and we can do it for non-production environments at the moment with the view that at some point in the future, we can roll it out to production. We are waiting on a few things to become stable, so Memcache apparently has a version that may or may not work, and New Relic is still dragging the chain. Personalization, so this is often checked around as well, but this is the idea of serving the right content to the right user at the right time. And this problem is specific to media, but potentially it will impact your clients as well. As they shift away from print, they're basically noticing that their revenues like just been smashed. And even though they've moved to online and adopted maybe a subscription model in some way, like maybe a paywall or something like that, they've recouped some, but it's nowhere near the levels they used to have. But a lot of the time, they don't even know who their readers are. They don't know what they like. They don't know how to sell to them. They might just send out an email blast, they'll go to every single one of the users saying, do you want to stuff kangaroo? And they'll go, no, I don't like them. So how do you even know what your users like? How do you know what they like to spend their time on? So you basically need to track that. You need to track them. So segmentation and personalization is a key requirement here. And I talk about bird and media again. One of their properties is in style. It's not in English, it's not very fun to read. But the idea was they had an anonymous only site. So no login, no sign up. And now they're tracking them. So they can basically track what content they consume, what products they likely are using, and all this context is kind of used. And how they use it is with this concept of a third revenue stream. This is where you can market those products or those services to them, but rather than sort of shotgun approach where you just kind of do it to everybody, you might go, well, actually I'm gonna offer the Tui Kangaroos to the children and see what happens. But you can also partner with other brands or other sponsors to advertise their stuff through your site. And maybe look at using e-commerce as a way of recouping a bit of that money. And this is the CTO of better media. They already had the readers. They already have the tools. And they had 52 million anonymous readers who have no idea what they were really doing. And now they've got 52 million people put in buckets, put in segments, so they can send an email blast out to the people with a certain like or maybe a certain interest in a particular topic. And so this should have been green. I do apologize. I'll fix that for next time. Clearly that's wrong. So DDoS, we've already seen how to do that this morning with the sweet ping command. So what is a DDoS? It's distributed. So that means it's more than one address basically. Normally it's all around the world. And it's a denial of service. And so basically they're looking to impact your ability to serve regular customers content. And how they typically do this is with a flood. You can think of it like if you've got eight lane highway coming into your city and you can take a thousand cars a minute, they'll send a hundred million. And then you'll soon notice that no cars are coming through. And that's a DDoS. And a lot of people will say, oh, it's okay, I've got a pretty good firewall. Well, it's kind of like having like a toll bridge, right? But if your cars can't get over to the toll bridge, then what does it matter? And you might say, well, why do people DDoS people? Like we've already seen script kitties, they just do it for fun. But something more malicious I guess is competitors. You can hire DDoS bots. Maybe you want to extort someone. Maybe you don't agree with what they're saying. Maybe it's when I show someone else something you've done. And this graph is quite old, like maybe six months old. So at like where we do partner with Cloudflare and we get access to a few things, but this is attack traffic for, what, like a month. And it's measured in gigabits for those who can't read it. And it goes up to about 400 and something. You put this in perspective. The total bandwidth of Kenya is 500 gigabits. So you can take out country of this type of traffic. So these aren't small. More fun facts. And this is not doing to scare you. Like there's no hacketype here, right? This is what's actually happening. And the DDoS attacks are relentless. Half of all application layer attacks, they'll happen again. So you think, ah, it's gone away. I don't actually need protection. It's fine. Target's a hit once a week on average. Most people also think, oh, they'll be gone in half an hour. I'll be right in half an hour. Yeah, the longest attack was 54 days. And you need to ask yourself, is that really a length of time I can do without my business? And this is also mentioned this morning. This is awesome. So KiwiCon, for those who did go, this was a talk. I shamelessly stole the slide title from it, but the intent of garbage things and go watch the KiwiCon talk as well. It's actually amazing. They dissect a bunch of things like Barbie dolls and analyze them. This is essentially what's creating your DDoS attacks. It's stuff that you buy that you think's a cool idea, like a light bulb that can hook up to your phone. It's your security cameras that you want to check from your phone where you're not at home. It's a smoke alarm. Like, who makes this stuff? So there's basically one vendor in China that makes these chips that come out of the box. You can't modify them and they come with insecure software. Someone open sourced the code to make your own bot name. It's called Marai, M-A-R-A-I. So you can go check that on GitHub and you can go start ponying some of these devices if you want. This is a recent attack that Cloudflare saw, just a single site, whereas the graph you saw earlier was aggregate. This is layer seven. So this is HTTP requests. Typically, these are post requests. Typically, these come with a rather large post body. We're talking, I don't know, half a meg, a meg, more. And we're seeing, I don't know, 1.7 million requests per second coming in. Yeah, there's bonkers. This is all coming from internet of things as well. And Capsula, who's a CDN WAF provider, well, basically, they did their best to come up with some numbers around this. And an unmitigated attack, they said, is likely to cost around $40,000 an hour. And the impact is more than just, ah, a few people didn't sign up and buy Twig and Groose. It's actually consumers lose faith in your website, right? Because it doesn't work. Maybe data theft. Maybe they pinch some of your stuff when you end up on Have I Been Pwned. Maybe they pinch your IP and now you're no longer the only person who makes that product. So now that you've heard the scary things, like, how do I stop it? Basically, it's a specialist's task. You can't just be good at IP tables. You need someone with a lot of bandwidth and a lot of points of presence all around the world. So there's a high barrier to entry. You don't see startups that do DDoS protection. We do partner with Cloudflare. We do resell their services. Acquire edge protect is what we call it. And we can reach out to their version of me to basically get direct technical advice when we need to, which is pretty helpful, you know? Like sometimes you don't want to deal with level one, level two. Sometimes you just want to talk to the people who know what they're doing. A bit of a recap here. Sorry, team was a bit of a shocker in the face in terms of information, but roughly that's what we covered. Did you want to hear anything to raise? Any questions? Hey, thanks. I was just wondering how the HTB2 might have one crucial thing that has just doubled down to a really strong HTB1 center towards you. Yep. So HTB2, I know Cloudflare supports it. That's the first thing. And then I believe that what Speedy was merged into that, right? The protocol, anyway, is a bunch of performance benefits for HTB2, which is the reason why you should be looking at this as well. I'm approaching a slide on that as well. Good point. So HTB2 normally browsers are restricted to the number of resources they can download parallel, right? And the headers on those resources are not gzipped. And that can be a problem if you're sending 200k headers, which I have, yeah, long story. Anyway, so it can make your website a bit faster, I guess, as well. And Cloudflare already support that, so you just toggle that on, and then you're good to go. In terms of making it better for Drupal, I guess that does make it for better for Drupal. I was thinking more about the system connection. So delivering content and maintaining the seismic connection. What kind of like a web socket or? Yeah, I suppose. Yeah. Leveraging those abilities. Yeah, OK, that's interesting. I need to find out a bit more about that one. But web sockets have come up in the past. It's just that PHP is not a great tool for web sockets, because typically you need event-driven frameworks, like Node.js is a good example of one. Ruby also have one. Whereas PHP is like, I get a request, it's stateless. I send it back. And then I get another request. I have no idea what happened for the previous request. There's a new request. And yeah. It's interesting, though, at AQUA, we are looking at that and potentially seeing if there's a use case to support more event-driven applications. So I'll be keen to hear more about the app or the idea or the website or whatever it is. Cool. Well, thank you. And there's pages of links after this road talk, right? So get the slides. And yeah. Happy reading. Question was, what's the difference between the mobile and the website and Android sockets? So mDocs are traditionally used to do, right? They have mDoc your website. And then they made a responsive site. And we'll just go talk to it.