Okay. How's that? Yeah? Okay. All right. So we're a couple of minutes past, we still got some people filing in here. So we're just going to go ahead and get started and other people can catch up or whatever. This is the Drupal 8 plugin deep dive session and so very quickly we wanted to introduce ourselves. I'm Chris Vanderwater, I'm with Commerce Guys, I'm a lead dev over there. I'm also the initiative owner for the Drupal 8 blocks and layouts initiative. I'll let everybody introduce themselves. Well, I'll also do James Gilliland real quick. He's not on the panel today because he couldn't make it to DrupalCon, but he was going to if he had made it here. I've left him up here because he was significant in the development of the plugin system, so he's still up there. Great music. Hi. I'm Alex Bronstein. I'm a software engineer for Acquia. I work for Akto, our office of the CTO, and that actually gives me a lot of time to work on Drupal 8 core. I'm Tim Plunkett. I work at Stanford, the Graduate School of Business as a developer, and I'm on the views in core team. So I've got a handful of slides here that I'm just going to kind of walk through real quickly, and this is an attempt at a visual explanation of what plugins really is. I gave this same talk at Drupal Camp Dallas, and it went really, really long because I had definitions for everything, so we're not going to do that. We're going to talk about the Drupal, like, specific stuff here and then acknowledge what's really just like plain old PHP, as Larry Garfield says, and we'll kind of take it from there. Our attempt here is probably going to be to spend the first half telling you what this is, and then maybe the last half doing question and answer and maybe showing some code examples or things like that. So this is very much designed to be an interactive session. Start getting your questions ready. So really quickly, we'll run through just kind of a glossary of terms. We have a whole bunch of things that we throw around when we start talking about plugins, and we have plugin types and managers and discovery and factory and mappers and plugins themselves, and all of this can be kind of daunting. So I've tried to put it together into what I'm hoping will be a fairly concise visual representation of how this code flows, and we'll talk about what really is specific to Drupal and what would have worked anywhere, anyhow, right? So the first and really one of the most important things that we're going to talk about here is the manager. The manager is a class. It does some stuff. It does three major things and can be used as a really great place to attach various helper functions for your plugin types. If you dig through, say, the entity types manager, it has all sorts of helpers on it for getting the controllers and various other things like that. One of the responsibilities of the manager is to do discovery. Discovery is the clear Drupalism in what we're doing here. Drupal has an awful lot of configurableness in it, and plugins is really kind of an answer to that. In many ways, plugins is designed to replace what we've traditionally thought of as being info hooks. So any sort of info hook that you might have in your own contrib or any that we may not have killed in Drupal 8 yet, and I'll get to that topic, could likely be replaced with plugins. So Discovery's job is to go out and discover plugins. If you've ever implemented an info hook, you've functionally done what Discovery is trying to do through a different mechanism. And so there is this metadata out there which it finds and parses and brings back one way or another. There's some really cool stuff around metadata that Tim has worked very, very hard on, and we'll show you that if we have time and what it's meant to do and how you can do some really cool stuff with it. But for purposes of kind of the low level conversation that we've started here, it's the info hook implementation. And unlike the way previous versions of Drupal have done this, where a single module might have many of these sitting in its info hook implementation, each one of these generally stands alone. And we'll cover that topic a little bit as well. And you guys feel free to jump in on this at any time. Once the metadata is returned back to Discovery, we have a methodology through which we can wrap decorators around the Discovery mechanism and the metadata that comes back. We are in process of kind of disassembling some of those right now in favor of more direct establishment of what we want to happen inside the manager. So a great example of this is, who in here has used an altar hook? Amen, brother. Okay. Everyone raised their hand. Yeah. So, yeah, yeah, exactly. So we have an altar decorator that takes all of the various collected metadata and gives you an altar hook for it. And we're probably going to kill that before it's all out. And you'll be able to just, in your manager, do that. And we're going to provide a default manager that does that. And if you want to use it, then great, the default manager works for you. Another example of this might be caching or derivatives, which is a topic that we may lightly cover. But this concept exists at least. We're likely to reduce it down as much as possible in favor of letting the manager handle most of that, which means probably just derivatives as a decorator. But we'll see what actually happens come release. And then we have a factory. This, again, is the manager's responsibility. The three things that will be close to the manager are all its responsibilities. And the factory is really just plain old PHP. Who here has done enough OO that you've ever written a factory for instantiating classes? Yeah, this is exact same thing. And so the manager can either use a factory class that exists or it can be a factory class itself. I'm not going to get into that topic because it's mildly contentious, but it can happen. And what happens from there is you instantiate a plug-in or perhaps multiple plug-ins, and this is, again, plain old PHP. We are just instantiating a class. Generally speaking, all plug-ins of a type are instantiated the same way. There are some plug-in types in Drupal who code around this in certain ways. We probably won't cover that topic unless some of those people are here and want to discuss it further. But we will show you some examples of exactly how this happens. And most importantly, plug-in and metadata for virtually all, not all, but virtually all plug-ins in Drupal 8 right now, those are the same class. So the class that you are instantiating also has the metadata on it in the form of annotations, okay? And finally, there's this thing called a mapper. The mapper is really just business logic. You can hand, say, an array of values to it, and it can parse that array of values and determine which plug-in configured how should be handed back to you. And we do have an example of that actually in core at this point. It's not used. Yeah, it is. We have one that is actively used now. Archiver. Yeah. I am. Yay, chicks. I killed the other one. And so a quick code example. And we're really close to the end of my slides, so we are going to be digging into questions real quick here. I have two managers here. I just grabbed code snippets from two different managers. This one doesn't actually look this way. If you look in head right now, I reformatted it so that it would fit on my slide. But this is the block manager. And that is the entirety of the code in the block manager, from class beginning to class end. It has one function that's the construct method wherein it sets the various discovery and discovery decorators it needs and sets the particular factory it needs. There are methods implemented on the managers, which are in the interface, that do the active discovery when you ask for it and do the class instantiation when you ask for it and mapping if you ever have need for that. We aren't really going to cover that today. But I want you to be aware that it exists. And by contrast, this is the archiver manager. It's a little bit larger. It uses the create instance method here, which you may or may not be able to read. The font was a little bit smaller for this one because there's more code. And it also has the get instance. These are the two methods that do factory instantiation and mapping accordingly. So with that, there are a whole bunch of plug-in managers in core. These are all but one of them, excluding the test ones. Editors, there's two editor managers. And I didn't really feel like trying to differentiate them on the screen, but there are two. And they're used for totally different things. Who's the, whoa, the edit module is what for inline editing. And they're going to rename it the in-place editor module. And the other one's editor, which is for WYSIWYG. And yeah, they both have the same class. They both have editor manager. And it's one of the more confusing things when you're debugging. So they'll fix it. But that's a good list. I was very surprised, frankly. So we wrote this just the system. Actually, like a year ago it got in maybe at this point. Something like that. And we had no clue whether core was really going to use it. Obviously core did. And this actually, this is an even every plug-in type. If we go through here, Views Plugins and Views Handlers are two plug-in managers that actually handle multiple plug-in types. 22. It's a lot. It's a double-digit number, which would double what I have on screen here. And so they did some interesting things there so that they only had to write one manager and they can get away with some cool stuff there. So within all of these, you have quite a list of cool stuff to dig through and see how people implemented it. Not everybody implemented stuff the way I would have wanted them to, but plenty are implemented very nicely and work very well. I'm sure Contrib will do things that make me unhappy too. But who cares? We have an awesome system. So with that, I think, yeah, no, no. You're on this panel, but you can't talk. So there's also some that aren't on here yet. Like, for example, image effects are not on this list, but could be. Actions, text filters. Text filters went in. Yay. I guess I didn't pull from head, sorry. So yeah, so if anyone here is inspired to want to kind of convert whatever is left in core that can use plugins that isn't, there's a code sprint Friday and there's another four weeks before code freeze. Yeah, which takes us back to into hooks. So actually, some of these, I don't even know if all of these were necessarily info hooks. Some of these are new things. Some aren't. OK, so as you said, a lot of this stuff is new to core. So like conditions and constraints and REST type data seekator. So field formatters and field widgets were the one thing I know in D7 was my least favorite info hooks. But blocks, anything where you have an info hook and then you have another hook that it called. So hook block info, hook block view, hook field formatter info, field formatter view. But yeah, a lot of these were all info hooks, I don't think, or their new code to begin with. And I think there's only like two or three info hooks left that would even make sense. As of it stands right now, the only info hooks we will probably ship with will be hook menu or its derivatives. And hook library info, because we're not going to make our JavaScript things into plugins, because that makes no sense. OK, so that's actually the end of the slides I have. I'm just going to start pulling up code and hopefully digging through stuff. But really, I think I want to open it up for questions. Is there anybody who's actively working with plugins right now in Contrib or in Core who's running into stuff? And just come up to the mic. Yeah. And we'll start answering questions. I'm going to bring up probably, I mean, Blocks is what I know best, but we have an awful lot of knowledge up here with regard to some of these various plugin systems. So we can show some cool stuff. If you have questions, just come up to the mic. But you have to come up to the mic. Really? Come on. So I was trying to help out with the responsive toolbar. And initially, it only took links in that top level toolbar. And now it can take render elements. And I was feeling pretty good. And then someone said, oh, but you should really make it a plugin in Do Blocks. And I said, oh, I have no idea how to do that. And so I'm hoping to get some answers from this session. And for a specific question for you, can you name one module, maybe two, that would be a good model to work off of? Something not too complicated that gives me an idea of how I can get started in plugins, something I can emulate? The Tor module, TOUR, they provide tips plugins. So if anyone hasn't seen the module, it uses the JoyRide jQuery plugin. And it shows you what different parts of your page do. And each of those, you can provide these tips, they're called. And the Tor module, since it's new code and it's very one purpose, it has really, really clear steps that you can see what does what. And there's not all this baggage from previous systems. I mean, the Blocks and Views are really good examples for doing hard things, but that's after you've already figured out the baseline. So I'd recommend using the tips plugin manager in the Tor module as an example. OK, thanks. That wasn't on my radar. Another one worth looking at. This is easily the simplest plugin conversion in all of core was Archivers. Who in here is familiar with Archiver?  Who knew? I ran into this because one of my coworkers was using it on a Drupal 7 system. And I was like, how are you doing that? So I went and I figured out what he was doing. And I was like, that's an info hook. We need to replace it. And the whole thing was already classes. If you go and you look at the code that's in Drupal 8 and the code that's in Drupal 7, it didn't change. It's the same code. We just threw away the info hook and put a manager in place. Literally, that's what the conversion was. No other conversion has been that simple. But this was all already classes and objects. And like I said, from the factory forward, it's plain old PHP. So CHX actually did that conversion.  So if you want a before-after, look at that in Drupal 7. Look at it in Drupal 8. You're going to be like, ooh, OK. It's very, very straightforward and obvious. In addition to that, I believe it's possible to use a manager to invoke hooks, right? To still have hook-based plugins. You would have won that probably. But you probably could just in addition. My question was about the hard work. I had some interesting discussions about plugins with Tim on IRC. Say you have an entity that I'm going to make this abstract, Tim, so don't worry. That uses a plugin to do something. But it also needs to use configuration for that particular plugin. Because the plugin itself contains logic. And if you save the entity, you only want to specify. It uses that plugin. And this is the configuration. It's probably use case that is going to be required a lot in contrib. Can you give a short demonstration or an overview of schema of how that should be done in a good way? I mean, we can walk through blocks. No? Can I try plugging in real quick? I mean, well, I don't think it's going to work, but I can't see the screen. So everyone tell me if it works. It's very Drupal blue. Too bad. Sorry. Are you wanting actions or what? Yeah. I'll go get it and apply that. OK, yeah, I'll talk while you do that. So the block module got ported. And then it got rewritten. And then it got rewritten again.  It is a really good example of that, what you just described. An entity that needs a plugin to do a thing and it wants to store it, et cetera. But the block module has been around for a little while. And it has a lot of baggage. So it's not a real concise example of that. But just the other last weekend, I was working on porting the action module to make it not useless, but not quite as crazy as rules. And it actually followed the same exact architecture that we used for blocks, where you have an entity that needs configuration to store for its plugin. And now that we have two of them, I mean, it's not in Core yet. It will be. But now that we have two of them, I think we can take some steps to make that easier and more obvious and documented. So, oh, I have this set up. What do I, you know, I just extend this base class instead of figuring out, again, from scratch. Because I ended up doing the same exact things from each example. So OK. Well, no. Take another question. Yeah, let's take another question. We'll come back to the action stuff then. Hello. I would like to ask you to go briefly about standard discovery decorators and factories that are used and what are they aimed for if you can. The factories in what? Yeah, discovery. Oh, discovery. OK, yeah. So there are two main types of discovery right now, just the info hook and the annotations, right? Oh, yeah, yeah, yeah. So there's one for tests. OK, right now there's a discovery class that just uses, like, module and vocall so that you don't have to actually do any conversions. And you can leave your info hooks in place. But the resulting code will be plugins, not just procedural functions. That's the one. The other one is the static discovery, and that's mostly just for tests. And you just hand it a list of, like, this maps to this class. And that's, it's not intelligent. It doesn't do anything. You just, it's for testing purposes. The third and the actually, you know, useful one is this annotated class discovery. And that's the thing that we mentioned and haven't shown yet, which is how to, your plugin will have this metadata that gets read out and processed and stored. And we'll get there, I guess. But so those are the three kinds of discovery. Really, you're just going to use annotated classes. The info hun's basically just for backwards compatibility. Factories, we have two main kinds of factories. Excluding the, like, specialized ones. The one is just, it calls new dollar class, and dollar class is a string. And that's it. The other one calls a method and passes it the dependency injection container. And you can use that to do all your dependency injection stuff. And that's called container factory. But they, what? That went in. Like, yeah, two weeks ago, something. I was looking at the. Stop using the internet so we can work on that. Yeah, container factory is recent to core. So now your plugins can have services injected into them. Please don't do that. Well, views doesn't. So, yeah. I don't know if I answered any of your actual questions. Yes, and the decorators. Decorators. Yeah. I'm good to say. Yeah, so the decorators that we currently have are, we have an alter decorator. So that's basically, once you read, for example, let's say you're using the annotated class discovery and you get back the values of the annotations from the class. It invokes alter hooks so that modules can alter that. We also have a cache decorator. So that's, and a very important one. We have a derivative decorator. So the idea behind derivatives is, let's say you have something like a menu block.  You have the main menu, the administration menu, the tools menu, whatever user menu, whatever custom menus there are out there. So you only have a single class called menu block. But for every menu that is administrator configured, you sort of expose, in the blocks UI, a separate block. So that's the use case for derivatives, anything like that. It's not just for blocks, that same use case exists in other plugins. Right, yeah. So if discovery within plugins replaces info hooks, derivatives replace for each loops within info hooks. So that's another kind of decorator that's in use. One thing that Chris mentioned is that we're currently in progress of setting up a base class. So now that we have all of these different managers, when the plugin system first went in, we weren't sure how similar the different core managers would end up being. So now that we have 20 or so plugin managers in core, we see how similar they are. And so we're actually working to make them more similar to each other. And then instead of them duplicating all those decisions, like instead of 18 of the 20 core managers saying, we want annotated class discovery with an altered decorator and a cast decorator and such and such, that we can have a base class that sort of makes all those decisions. And once we do that, then there's also some argument for moving away from the decorator architecture and putting some of that logic directly on the manager. There's some pros and cons of each approach. So it may be the case that that same functionality that currently exists in decorators will move to just functionality on the base manager class, if depending on how the issue queue debate goes on that. Okay, thank you. Who has ever used trigger module? Okay, you've used it more than I have. The trigger module is removed from Drupal 8 and it was the only thing that really actually used the action module.  So, but the idea was you have an info hook called hook action info and you provide a list of actions. And it's sort of, it's not exactly used, but it's like on the content listing or the admin people, you can block users and publish nodes and whatnot. So you just had a list here and Drupal style just a massive array. And so the node publish action is one of the actions. And this is also met, it's the name of the function it should call later. It only works on nodes. It publishes your content. It's not configurable. And then this stuff is still just left over from trigger module. And the actual function is node publish action and it takes a node and it sets its status to published and then it writes the watchdog. And it doesn't actually even call save. Save is managed somewhere else. But that's the basic setup of just plain actions. So, yeah. Can you guys see that? Eh? That's blurry. Is it like fuzzy and then stop? And then fuzzy and stop? Fuzzy, it could be a little bigger. Well, okay, let's see. For a while. Yeah, just feel free to hijack that one. I'll just make it like 20. Oh, 20. How's that? All right. How do I make that go away? Whatever. Okay, cool. So instead of having, so the equivalent of this function and its info hook is all contained right here. So you're in this publish node class. It has a method that takes an entity, sets its status and calls save. And instead of having an info hook, it's right here. So you have your ID, you have a label that gets translated and it works on nodes. And that's it. So instead of having to write out annotation class, yeah, yeah. So, yeah, right. So instead of every time you wanna add a new action before you had to go find your node hook and add a new, like 10 lines to this and then go somewhere else and put another procedural function. Now you can just drop in a file and it just gets picked up. And this is the info hook path and this is the rest of it. So you'll notice this says at action. This is an annotation and we use doctrine to parse our annotations. And this just maps to another class that is hidden right here called Drupal core annotation action. So this is just, this provides the default values as well as documentation. So this shows you what you can and should use to create a new action and how to document it. So the plugin ID, the human readable name and a URL. So now you know you can use a URL. And if you don't specify one, it'll give you an empty string. Right, and then the action manager is, yeah, okay. So we use annotated classes and then we have an alter hook and then we're using this thing called container factory. And that's the factory just looks like this, container, yeah. And it just calls a create method and passes in the dependency injection container. And you mentioned earlier that you can, the managers are where you put useful methods. So for example, very often you wanna get a list of all your actions. But more often than that, you wanna get all the actions for a specific type. So I want all the node actions now. So I just tack on a new method, get definitions by type. It just gets all the definitions and then uses array filter and anonymous function and filters it all out. So then in code somewhere else, you'd just be like, this is VimMode in an IDE, it's tricky. You'd just be like manager, get definitions by type, node, and then you'd have all of your, it'd just be like calling the info hook yourself. Okay, so, yeah. Therefore, you now know everything about plugins. The actual question though is about configurable plugins. So, action. So this is going a little off topic because it's config entity. So we have these concept of configuration entities, like a view or an image style and it gets written out to YAML. And this is the entity that has the configuration of a plugin. So this one has an ID, it has a label, it has a UD, et cetera. And then it has a plugin. And an actual, let's see if this, cool. Action.action, there we go. So this is the YAML file for that configured plugin. It knows, this is what plugin to call, it's in English, it works on a node. A more complex one would be like, where'd it go? Oh, you don't have it. Oh, right, you didn't install. You didn't reinstall Drupal, okay. Damn. Well, yeah. These, no, it's not worth it. Some of these actions are configured in a way that you can just do this and you'll just have settings and it's like, oh yeah, yeah, yeah, yeah, what am I thinking? Locked up, lock. Looks like this, where you just have a settings array. And then this gets, this whole array gets passed to the plugin. So you use the one system to store the configuration for the other one and it just gets instantiated when you need it. Like in, you talk. So like the important point on that is that the config entity in this case actually has a settings property and only the stuff in the settings property, the array that sits in there is what's used to actually bootstrap and configure the plugin, right? You don't want to pass the whole entity in. There are a whole bunch of reasons for that that we could spend literally hours discussing much less days we have. But the point being, like those settings are, they're isolated from everything else in the entity. In the case of block, like blocks are a really good example because the region that a block exists in and its weight aren't really things that matter to the plugin. They're things that matter when it's rendered on screen when you're dealing with a whole bunch of block entities, their various configuration. But it's not at the same level as say, how many users are we gonna show in the, who's online block, right? That's something the plugin cares about. And so, I mean, this is something that you kind of have to go over it with a fine tooth comb when you run into one of these and make sure that you're really appropriately separating your entity from your plugin configuration. And it can be quite tricky, but it's also well worth it in the end. So do you pass on the settings when creating a plugin, like creating a plugin instance, or only when the plugin actually needs it? Because then you have a lot of, you could potentially end up with a lot of instances of the same plugin, but every one of them would have their own few configuration. So because, okay, so in views, a view is just a wrapper around displays.  And those are all plugins. And the idea was if you want to just display a block on your page, you don't wanna have to load the entire page display of that view that's used somewhere else. So we added a little layer to lazily instantiate them, and I named it plugin bag. Named after, the symphony stuff, it was like a parameter bag. It's like a bag.  So, it's a bag of holding. It's a, yeah. So this is the action bag, and the action bag, that sounds awesome. Where's my other class? Okay, so in my entity, whoa, in the construct, all it does is just call parent construct, and then stores my bag. And I pass in the plugin manager, I pass in the plugin, and I pass in the configuration I know about. So that's basically taking that file and saying, okay, here's what I know, and go forth and give me plugins later. So action bag in its constructor takes the plugin manager, it takes a list of possible instance IDs that it may eventually instantiate, and then any configuration needed, and stores it for later. And then when it comes time to initialize, it calls manager create instance with the configuration. In short, until the entity, in this case the configuration entity needs the plugin, it doesn't exist. And then once it needs it, it instantiates it, and does pass the entirety of the configuration that the plugin needs at that point. But if you aren't necessarily going to be using config entities and plugins in conjunction all the time, it's likely to happen a lot, but it's, wow, I'm getting feedback. It's not, okay, it's you. It's not something that absolutely has to be done by any stretch of the imagination. There are plenty of ways to do it without. It's also very likely that you're going to end up with a configuration entity that might actually compose many plugins together. Views do this. Rules will do that. Rules, page manager. Views does that. Yeah, I mean. There are only maybe four that do it like this right now where you have a plugin views filters and form, like a text format configuration contains filter plugins now. So there is a model, there's a lot of code there that you can like copy and paste from and read and learn. But I do think we can now take the steps to codify that and make it easier to do that and contribute because it's gonna happen. So. Yeah, but the harder part on that is actually gonna come down to you as a developer identifying what's relevant to the entity, what's relevant to the plugin. Next question. Actually, while we wait for more people to come to the mic, just curious, who here is familiar with what config entities are and why we have them and what purpose they serve? Okay, I'd say. That was like a dozen people. Less than 10, way less than 10%. Yeah. Okay, so there was a question at an sort of an earlier call about sort of when to use config entities, when to use plugins and sort of what that whole distinction is. So here's a quick summary. So when the configuration system went in, we just had this concept of configuration files. So great, we have, and we could get rid of things like the variable table and variable get and variable set. So if you wanna store something like the site front page, you put that in system.settings.yaml. So that's a one, that's a single configuration file. But then we also sort of know that we have some configuration files that sort of follow a particular pattern but that the specific instances get created depending on what the user does. So for example, for image styles, if the user adds a large image style, that's a whole set of configuration and then if the administrator adds a medium image style, that's a whole another set of configuration and so on and so on, same for views, right, every view you make. So there's this idea of like, there's a particular kind of schema of configuration, like that defines an image style in the abstract and then there's the specific instances of like a large image style, a medium image style. And at first those were just sort of configuration files that weren't treated in a special way but for various reasons it actually became really useful to codify those kinds of configurations as entities, they're instantiated objects that get stored, which is pretty much what entities are. So that's the config entity system. So a config entity represents basically a piece of configuration that gets stored and that can exist in multiple instantiations. In contrast, a plugin is a piece of behavior. It exists, you instantiate it within a particular request to accomplish some action and then once the process stops, it's out of memory and it's not stored. So for example, if you look at an image effect, as part of an image style, you're gonna instantiate like a resize effect, but you're instantiating that in PHP code, telling it to run and then you don't need that effect object anymore. So there's the distinction between for example, the configuration that represents an image style and each plugin that represents an image effect. And so it's really like sort of a unit of configuration storage versus a unit of behavior that you pass configuration to. And that's a really good example of a config entity that it's got n plugins that it's configuring. Yeah. So when it's an n to one situation or one to n situation, like an image style contains an n image effect or a view contains n displays or a text format contains n filters, it's pretty easy to conceptualize about what goes in which one. With things like block, it becomes a bit harder because the way our current block system works, one block config entity, one unit of block configuration storage maps to a single block plugin. So now you have a one to one relationship, it becomes a little harder to reason about which goes where, but you follow the same sort of principles of what represents the unit of storage and what represents the behavior. And one way to start thinking about that separation is to think what other situations can that plugin be useful for. So for example, in core, currently, blocks are stored as individual units of configuration. Each block is stored as its own configuration entity, its own configuration file. But maybe panels wants to introduce a concept of displays that store multiple block configurations as panes within a single unit of configuration. So if you start thinking in terms of like, okay, so now the behavior of rendering a block can be potentially via contrived like panels, the configuration for that plugin or for a set of those plugins can actually be stored in a different config entity, that's where sort of separating those two becomes useful because then as long as the block plugin only acts on past in configuration rather than making assumptions about how that configuration is stored, it allows a module like panels to allow the configurations of blocks to be stored in a different way than what core defines us, than what core provides. And that's really useful when you start talking about if you've got a situation where you're building a plugin that you know is gonna be useful outside of your own circumstances, you can build a single manager that makes the assumptions you need made for your implementation, but if you take care of your plugins appropriately, then someone else can come along and reuse them in a completely different situation. So in the case of blocks, yes, core currently has this block manager that assumes a one-to-one relationship between block entities and block plugins, but it's not a requirement of using it. You could go out and do something totally different. We also have a condition system that could be done the same way and frankly actions. Yeah, that was the logic behind the actions, plugins versus the config is that rules is obviously gonna run and reuse these and not have to rewrite all of it again. So I mean the rules module completely duplicates what's in core because it's inadequate and now ideally it will be able to just swap out the parts it doesn't like and the rest will, you write an action and it'll work anywhere. Which brings us to an interesting topic. These managers, within core at least, all the managers are actually registered within the dependency injection container. Anybody in the room have the foggiest clue what I'm talking about there? Dependency injection container. Okay, that's not trivial. So the dependency injection container currently knows about basically any class within the system that's likely to be asked for on its own and needs to have some sort of dependency fulfilled. In the case of most plugin managers, they currently need a list of all of the modules that exist because they're using the annotation based discovery system. And so they get that injected into them when you ask for one. But because they exist in the dependency injection container by virtue of that fact, it actually means you could replace the block manager with your own class that may do different things. And this gives you a level of flexibility in core that you've not really had before because you can replace core's actual implementation, the code that is making these decisions. If you take that and go really crazy with it, I'm not suggesting this. I'm just going crazy for a moment. You could look at, say, the entity system and throw away the entity manager, which is likely a really bad idea, but you could, right? And then you could get at your entities or their controllers or something like that in different ways and through different methodologies. It is unlikely that you need to do that. More likely you'll end up creating new managers for existing plugin types when you just need a slightly different implementation, but the old one needs to continue functioning as well. There are a lot of possibilities there. And while we're talking about the swappability of this, the alter decorator that we have talked about with regard to the metadata, when that comes back, it actually comes back with the class that it's going to invoke, which means that if you use the alter decorator, people could actually swap out your plugin class whole hog. So if we use the menu block example, if you aren't, say, thrilled with the output that menu block has and you wanted to change the output completely, you could extend the menu block class to some custom class, use the alter decorator to put it in place for menu blocks and then from there, you would be in a position to completely rewrite the output of all menu blocks on the entire system simultaneously. Just write a single method over write our build, right? And so this is a level of power that I don't know if the front-enders are likely to use it. I know the developers are likely to use it, but I don't know if the front-enders are likely to use it, but really whole hog. And since that class contains everything, it contains the configuration form, the validation for that form, the submission for that form, all of that stuff, you really have the whole world at your fingertips there. You can just replace it. Yeah, for the menu block example, a module like menu block would of course follow best practices and make sure that all HTML markup that was output was done via a template, right? So for front-end developers to customize the markup of a menu block, it would be overriding a template just like normal theming, but the example that Chris was giving was, like let's say the, you know, something more, not necessarily the markup, but let's say the render array structure or some of the internal logic that the menu block implements for whatever reason you decide doesn't suit your needs, then that would be the kind of functionality you could replace with the class. That's not a tool that's meant for theming, it would be more for a tool meant for changing the actual sort of functionality of the menu block. But any plugin manager that implements alterations like this, you're gonna have that ability on. So, I mean, and the vast majority of them do. So you can do some really cool. They all do, yeah. I don't know if type data does. Oh, well, I, oh, that's true. Okay, all the annotated ones now have alters. Type data still uses info hooks for some other reasons. We'll fix that. If you wanna come help fix that, find us on Friday, which is tomorrow. What are you pulling up right now? Oh, I was just showing that you could take over menu block and decide that they don't get a form anymore. You could do that. You could do that. You could totally do that. No form for you. One of the other things that we haven't really touched on at all is that plugins actually have this notion of contextuality. And so there are a set of base classes which you can extend and use, which make your plugins context aware. And at that point they're actually consuming various objects, say like a node or a string or a user or something like that. And so you can actually define what sort of constraints are on that object.  Yeah, so just look at the annotation. So in this annotation there's actually an array of contexts. It currently says node. Node is just the name that I chose for it there. But underneath node it actually specifies the type of type data that it is and any constraints on that. So it says we are going to have an entity type data and the constraint of entity type node. So you can only pass nodes through here. If you handed it a user it would actually like throw an exception and say you can't do that. So what's really cool about this is that this gives us kind of a, if you've used C tools or panels or anything like that this gives us the same sort of structure. Rules does these same sort of things where there are certain conditions or certain blocks or certain actions that only work if you have a node available or they only work on a node. And so for example, you can't very well show a node title if you don't have a node. So why would we give you a block to show a node title? These sorts of things. The only plugins in core that are using it right now is conditions. We are likely to give blocks the ability to do it but might not have an implementation of it in core but the base system for doing it does have test coverage so we can do that with pretty good surety of what's going on there. We got a question. So with all these classes being used throughout system and modules incorporating some of the base classes are there any visual tools that would just give us a snapshot of what some modules are using and all the methods available in those classes? I mean, this is not an endorsement. I don't work for JetBrains but get PHPStorm. It's worth it. Or IntelliJ, which is a big brother. The same thing, but yeah, I'm a Vim guy but I'm using PHPStorm now because there's too much. I mean, api.jp.org, I pulled this up earlier shows you what, these are all the config entities and stuff but it is hard to see and it's hard to discover what is this module doing because the file structure is verbose, to say the least. And you've been working really hard to trim that down lately. Yeah, I deleted two levels of directories but it's still like eight. Yeah, so that's worth talking about. You can see it up here at the top. This is in core modules node, lib, drupal, node, plugin, condition, node type. Those are directories, that's a lot. Yeah, I mean it's PSR0, most of it is PSR0 and some of it is our convention so that we are protecting against namespace clashes. I mean we don't want to do all this work and then have it not work and contribute. So we're kind of being a little paranoid. If you were at the keynote this morning you kind of talked about that. We're, it's for the best, I swear. So when annotations went in, I was very adamant that we needed to know about who was the owner, right? What module or subsystem declared this plugin type exists and then what plugin type is it because a single subsystem or module could declare multiples, say I don't know, views. And so when you look at that you want to know that this is a views field. This is views cache. You don't just want to know this is cache because guess what? Everybody in their dog might have a cache plugin type so you can't just squat the cache namespace, right? And so I was very adamant that we had to have these two directories worth of separation. Tim has worked really hard on giving us better annotations so you've seen the action annotation and it sets defaults. The entity type annotation is a really great example of this. It sets default controllers and some default base keys and things like that for various things. And so it's really smart stuff but we didn't have that initially. We just had an at plugin annotation which basically gave you an annotation as an array that you could then treat kind of like you might have an info hooks array and that sort of stuff. But because we have these annotations now we could in a worst case scenario if two different plugin types ended up in the same cache directory they should have different annotation classes on them so we'll still have a separation even if we don't have one that's separated by directory. So we're still being paranoid. We've just figured out how to be paranoid without as many directories. Also two of those directories as Tim mentioned come from just sort of having to follow PSR0 standard just because that's sort of the only standard that's available now but there is an issue in the queue to move to what may end up becoming a PSR4 standard. Is it four or five? It'll be, well depends on the timing. Depends on which one lands first. But it's currently a proposal but basically allows it's sort of a new auto loading standard that's proposed by different PHP projects that allows shallower directories for use cases like we have. So potentially we'll be able to get two directory shallower for all classes implemented by modules not just plugins. Yeah, the F, was it framework interoperability group? I think, if the Google does a thing. But yeah, PSR4, if you're interested in that kind of stuff it's a pretty interesting read. If the Google does the thing. I'm waiting for your browser. Yeah, and it's on GitHub which is cool too and mailing lists and whatnot but yeah. So we've thrown an awful lot at you from the perspective of what's sitting here. I think like what would be good that we haven't really done yet and we don't have a lot of time left is can we just, let's just pull up the plugin manager interface real quick. The plugin manager interface is, I mean, yeah. So discovery and the manager are really the two clear Drupalisms here. There are four methods on the manager that we're going to talk about. There are no methods on the manager interface. It's just remember. Oh yeah, okay. All right, nope, even better. Okay, so it implements, yeah, I guess pull up base or pull up those interfaces, one of the two. So the plugin manager interface actually extends three other interfaces, the factory interface, the discovery interface and the mapper interface. And these have one, one and two accordingly. So the discovery interface has two methods. The factory interface has one and the mapper interface has one. And so discovery is, as you might suspect, responsible for discovery. And it has the methods of get definitions and get definition. And so you can get individual plugin definitions or you can get all of them simultaneously. The factory oftentimes calls the get definition for whatever ID was passed to it and it finds out the class and then instantiates that class and hands it off to you. And then, as I said, the mapper is kind of a clear use case for specific business logic that you might have. We were using it in lieu of config entities for a while until those landed and we converted over to them. The archiver manager is using it for determining which archiver to use. So you handed a file name and it goes, oh, that's a zip file. And then it loads up the zip plugin and unzips it and gives you stuff, right? So that's kind of the idea there. But managers really at their core are just these four methods. Get definition, get definitions, create instance, get instance. That's all that has to be in a manager. And actually, there are some managers that don't even implement all of that because they extend the base manager class that we provided, which tries to give you some same defaults. So we've tried to keep these as simple as possible. The one thing I would encourage you to do is if you find yourself writing a custom factory class, stop and go, am I ever going to reuse this? If the answer is no, write your logic in the manager's create instance. It will solve a lot of headaches for you in the long term. And one other point I just wanna come back to with the question around, there's a lot of classes in Drupal 8 and how do we sort of navigate them either if we don't wanna use PHPStorm or if we wanna navigate them some way other than through PHPStorm? And that's a question that's a broader than just plugins. Plugins is just one area in which we're using object-oriented programming within Drupal 8. We're using object-oriented programming within Drupal 8 in lots of other areas. So we have a lot of classes and a lot of interfaces. And so I think it's sort of a community challenge. So I guess I point it to challenge all of us to find out how we can improve our documentation on d.o, improve tools and sort of what are the best practices that if we're becoming an object-oriented project, how do we make that friendly for people? Yeah, I hate to turn this into an advertisement for JetBrains, but their product is really good. It is really, really good. So if you haven't stopped by their booth, they are here and they have yo-yos. I would encourage you to. Their product's reasonably priced and has been really helpful in development of D8, just so you know. Yeah, that's time. So we'll be here and available to answer questions, but yeah, you are officially dismissed.


We are now well over halfway through the 12 days of Tiskey. I'll look back at the big stories of the year and how we cover them at the time on Tiskey Sour. And what a year it has been. A global pandemic rising unemployment and the end of a 40 year trading relationship with our closest partners has presented enormous challenges to our government and a bunch of meaty issues for our media class to contend with. However, being Britain none of this meant that our establishment couldn't find time for that long-standing British tradition, migrant bashing. In August, after small numbers of migrants were spotted crossing the channel in dinghies, that conveyor belt of hate that runs from Nigel Farage through the billionaire-owned press right up to the Prime Minister was set in motion. And as Preeti Patel was promising to send gunboats to guard our shores, Aaron and I spent an evening debunking the xenophobic arguments propagated by our billionaire-backed ruling class. Is it beyond the ability of the government to stop this from happening? Clearly at the moment it is. Good morning to you. Look, this goes back, I think, the current problem to something that the Prime Minister said in August last year. He said, we will send you back.  Well, how many have gone back? 155. We've had something like 6,000 already. We reckon that just this year alone there are 4,000 have already arrived and there will be anything up to 8,000 by Christmas.  Unless we really get a grip, the numbers are simply going to continue going on. So he's saying that 4,000 people already have crossed the channel and by Christmas it could go up to 8,000. We need to get a grip before the number of asylum seekers coming to this country via Calais and via the channel reaches such great numbers as 8,000. Come on, I think it is the director of Migration Watch who needs to get a grip. Let's do some comparisons. Keep that number in your mind. This is all of the scaremongering, all of these headlines, that segment on talk radio, the comments from Pretty Patel, the comments from Rishi Sunak. They're all about 8,000 migrants coming or projections for 8,000, 4,000 so far this year. Now, let's look at how Britain compares to other countries because the message we get, you know, Britain's a light touch. People come here because we give out asylum claims like their lollipops, right? That's not remotely true. We should be factual here, not like Julie Hartley Brewer and her guests tend to be. So France and the UK have the same population size, both 66 million. And we're going to get up some stats now of number of first-time asylum applicants in European countries. Now, what you can see there is that in France, we've got about 120,000 people seeking asylum between 2018 and 2019. In the United Kingdom, less than 50,000, 40,000, tiny, tiny numbers. Greece as well, population of 11 million, 75,000 applicants. Germany, their population is slightly bigger. But as you can see, the number of asylum applications made in that country are huge. So this idea that Britain is becoming too overwhelmed because 4,000 to 8,000 people are going to arrive on our shores from Calais, it's nonsense.  So these are exactly the same kind of people who want to say, ah, Britain is the best country in the world. We have the capacity and the strength to compete with other countries on all levels. And they're also exactly the kind of people who say that Britain is the least racist country in the world. Now, if we are both the country with the best economy, the most talented people, the biggest sort of economic capacity, and we're the least racist, then why the hell are we so worried about 8,000 people arriving on our shores? I should also say, I gave you European examples. The most, I suppose, important and striking contrast to make with Britain is that of Lebanon. So in Lebanon, there are 1.5 million Syrian refugees in a country with a population of 7 million. In Britain, 66 million people. And we're having headlines, government ministers, talk show hosts, railing against 8,000 people, 4,000 people arriving in Dingy's. I do want to show you Julia Hartley-Bruer, because obviously the representative for migration watched there. There was no pushback saying 8,000. Is that all you're talking about? There was no pushback because Julia Hartley-Bruer wholeheartedly agrees. Let's take a look at her monologue this morning. This is happening on a grand industrial scale every single day, and it has been four years on end. It's always worse in the summer months. Two years ago, we were told it's an emergency situation. So why hasn't the government, whoever's in charge at any one time as Home Secretary, acted already? Why does it wait for the Brexit party leader Nigel Farage to actually show video footage of this for everyone else to pay attention? I don't care what your views are on immigration or not. Whether you want mass immigration from the EU or not, well tough. You lost that vote in 2016, folks. But even if you want that, on what planet do you think that mass illegal immigration is a good thing? No one getting on a dingy in France is desperate. They might have been desperate on their way to France. Yes, I don't want to live in Libya or any other war-torn countries either. But you're in France. It's a safe country. Claim asylum there. You're not our problem.  I mean, first of all, this idea that you might be for migration, you might be for legal migration, but not illegal migration. Now, the problem with that argument is you can only really claim asylum once you're on Britain's shores. So the way to become a legal migrant, to become a refugee, to get granted asylum is to first come illegally. If yes, if there was an office, a branch of the Home Office out in Yemen or out in Syria where you could apply for British citizenship and be treated incredibly fairly, then maybe that argument would work. But that's not the case. The way you get asylum to this country or to most countries, in fact, is you have to arrive there. So to say, I've got no problem with migration, but I hate illegal migration. Ultimately, you have a problem with migration, don't you? The other point she makes, unbelievable, this idea that people in France, even if they had a difficult time on the way, are having a great time. Now, I've been to Calais. I'm not a huge Calais activist. There are people who are doing way more work than me, but I've been there and I've spoken to people who are living in camps, in tents over there. There are people who are getting beat up constantly by racist riot police whose makeshift homes are being constantly crushed to the ground, who are having to live through all of the seasons without proper housing. It is not a nice place to be. These are not people who are having a nice time sipping wine and eating nice cheese and just because they want to, they're coming to this country. As to whether it's our problem, right? Now, when I went to Calais, it was about 10 years ago and the people who were there were from Afghanistan. So why were they there? Because our country had gone and bombed their country and the state had collapsed. Where are many of the migrants who are coming over this summer from? From Yemen. Their state has also collapsed because they've been bombed by Britain's ally, Saudi Arabia, who were armed to the teeth by our country, right? So this idea that, oh yes, it might be nice to let in migrants, but ultimately it's not our problem, is completely bullshit. So many people in the world, the reason they are moving, the reason they have to move is because of crimes this country has committed. And now Julia Hartley-Brew after, I don't know if she backed those wars in fact actually, but I mean, there are many people in this country who backed those wars, who have completely destroyed states. Now, 8,000 people arriving on our shores. Oh, terrible, everything's going to collapse. There are very strong arguments for saying that the governments in those respective countries, Gaddafi and Libya, Assad and Syria, aren't good people. I agree with that. But the point is, if you're going to engage in a military intervention, if you're going to back a certain faction, if you're going to potentially see state failure, which is what we now see in Libya, you also have to have a domestic political consensus which says, well, one of the downsides of that set of choices is we'll see a flood of people leaving those countries coming here. Many, many immigrants, not all, many undocumented migrants coming to Britain today are from Afghanistan, Iraq, some are from Iran, a country that's been subject to decades of sanctions, Libya, across North Africa. These are places which have been destabilized for decades as part of Western foreign policy. We've fundamentally sort of undermined democratic governments. Whenever they've appeared, however rarely it's been in these exact same places, Syria in the 1950s, Iran in the 1950s, would presently support a tyrant in Egypt in the form of Al-Sisi. It's such an irony that the very people who are so happy, joyful, ecstatic to intervene militarily in these countries don't want to have to deal with some of the adverse consequences, which is mass displacement of human beings. I mean, the thing I just find really maddening is like on the Julie Hartley Brewer show of these right-wing pundits, their main talking point at the moment is stop doing our country down. Our country is actually brilliant and we can do great things. Why are the left so miserable? It's the reason Boris Johnson won is because he told the British people, you actually aren't that bad. You can be great. This country does have potential. There are also the people who spend the other half of their time saying, why is everyone calling Britain racist? Britain is the least racist, most tolerant, progressive country in the world and not just in the world, in world history. So the ideas people like Tom Harwood are saying, Britain is exceptionally anti-racist welcoming. If those two things are the case, if we're both a country with enormous potential, with enormous capacity, and we're the least racist country in human history, then why can we not just accept 8,000 people in a desperate situation who are looking for a better life? And yeah, you can use the Julie Hartley Brewer, but that's a legal immigration. What about legal immigration? So I've shown you the numbers already. The United Kingdom accepts 40,000 migration applicants between 2018 and 2019, a country like Germany, up 160,000. And as I said before, Lebanon, a country with 7 million people, has 1.5 million refugees. Now, if we as a country are as great as Julie Hartley Brewer thinks, and as non-racist as Julie Hartley Brewer thinks, then I would suggest we can take that proportion of refugees. And if we can't, then you have to ask the question, why? What is wrong with this country that means that people think there's going to be civilizational collapse if 8,000 people arrive in Dinges? Julia, say it with your heart. I don't want these people here. That's what she wants to say. And that's what all of these people want to say. Sometimes they do explicitly say it, but the argument that we can't afford to look after these people is patently ridiculous. We've just socialized the wages of 10 million people. Like you say, these exact same voices in the media, Julie Hartley Brewer and Nigel Farage, the exact same people are calling on the Blitz and the Battle of Britain and how that same spirit and zeitgeist can push us through a no-deal Brexit, and yet we can't deal with several thousand people rocking up in Dinges on the South Coast. So it's clearly not a resource issue. It's clearly not a governance or competence issue. We can clearly bring these people into the labour market. Some will need help. Some won't. Some will be a net benefit to the majority of them. Young able-bodied people will be a significant benefit in terms of tax and spend. We don't want to go into a sort of economic calculus here, but that's just a fact. But that isn't the point to these people. It's because they don't want them here. Now, why don't they want them here? One argument was if they just don't like foreign people. Another argument isn't I think Trump did this very well to say, look, I love legal migration. As many people can come legally as they want. Obviously, he doesn't mean that. But illegal migration can't happen. You're absolutely right, Michael. The minute somebody's here, they're claiming asylum. That's not illegal. They're here entirely legally. There are multiple international treaties designed precisely for these events. It's covered by international law in a number of ways.


So the part between SQL and NoSQL, a lot of you might have heard what SQL is, a lot of you might have heard what SQL is, so I will give you a brief introduction what SQL and NoSQL is, I will help you understand some concepts around it and then I will work at the end of my talk, you get a clear picture what SQL and NoSQL is and it helps you to make a decision for which database architecture you should use in the next project. So my name is Hershel Agrabal, I am basically a java key developer, I am a computer engineering undergrad at SVIT in India, I am a GitHub Amperage expert at a DAC lead, yeah that's for me, so how I got into database, I started with front end, I came across Firebase, I really like the concept of Firebase, so I read the documentation, I started building a few projects on that and I was reading the documentation, I came across NoSQL, I was very curious to know what NoSQL is because I had heard about SQL from my history and all that thing, so I started working on that and then in college I got introduced to SQL where I learned how, where I learned more things about SQL and then the questions came like why there is so much difference between SQL and NoSQL and which thing I should go for if I am building my next project, so here is what I am going to talk about, so I talk about SQL, for most of the people they think that SQL is a database but that's not right, SQL is not a database, it is a query language, so a language which is used to query the data, that is it drives the data, updates the data or even delete or insert the data, this is how a query for SQL looks like, so select and so on, they are the keywords in the command and the asterisk and the products are the data parameters, so what this query does is this query selects all the data that is present in the product table and gives you the output, so this is only the simple query for SQL but there are other commands also, there are commands which are the data, delete the data, update, even create the table, so SQL stores the data in the form of tables, so tables are the database where all the content is present and within those tables we have fields, now the most important thing about SQL is schema, SQL has a precise schema, so if you want to have a different field for a different record that's not possible, you need to have the same field for all the records or you cannot have the field for only one record and the data in SQL is known as records, so this is an example of a product table where we have the fields for ID named rise and description and below that are the records for that, now if I want to add a new record, let's say if I want to add a pension to this, so I do that simple insert query and I insert the record for this, but now if I want to have a new field for only the record pension, like short description if I want to add short description to a record, that's not possible, so if I want to do that, I need to have the short description data for both and all the other records that I have in particular data, so that was SQL, now let's see what noSQL is, so noSQL basically it's not SQL, it's not relational, a database that is not relational and it stores data more flexibly than columns and rows is basically noSQL data, so noSQL data is various types, these are the main basic types of noSQL data, that's graph store, key value, column store and document database, so graph store data if you are building the next Facebook, like a social media network or if you have road maps or you want to have network to follow this, then the graph store is best for you and the example for that is Neo4j, key value stores, it is simplest form if you know about JSON, JavaScript of the notion, it stores the value in the form of key and value, so that's what a key value like that, it's similar to key value and that is a very famous example for that and if you want to, if you have large data sets and if you want to do real-life analytics for that and the data structure, then you should go for column stores because it helps to optimize the query and Cassandra is very famous for that and MongoDB, a lot of people might have heard MongoDB and you might have used MongoDB, so MongoDB will see how MongoDB stores the data, will see the data structure for that, so we have a database and within those data base we have collections, so we can compare collections with tables in SQL and within those collections we have a document, the document are basically the records, so like if we have an example, so we have an example here, shop is a database and within that we have collections called products and orders and within those we have different documents, in product we have a document for code and something for pen and something like that, even we can have a, even we can have a collection of users for this, so this is the structure of document, price is name, price and description, now if I want to have a new document, if I want to add penchant, now for penchant if I want to have a short description, it's okay I can have a short description only for penchant and not for code, so that is how flexible and no SQL is, this is a query for no SQL, db.products are fine, here products is the data parameter when db and fine are the keywords, so what this way does is it gives you all the data from the product table, now before moving on let's talk about scaling, because whenever we are building an application we always come across scaling, what type of scaling we need and when we need the scaling, so let's understand what scalability actually means, scalability actually means it refers to the capability of a system to handle the growing amount of work, so if a system is scalable, if it can increase the workload and the throughput when additional resources are added, there are basically two types of scaling, vertical scaling, so vertical scaling is like adding resources to an existing system, let's take an example like there is a building, so adding more flows to the building, that's kind of similar to vertical scaling, but vertical scaling comes with limitations, like it becomes costly because every time you need to buy a new hardware and to configure that hardware, your system goes offline for a particular amount of time, so you lose your interest and then every machine has limitations, like a machine cannot be scaled up to a certain limit, like if we take an example of my machine, so I have an 8GB RAM, but I can only scale it up to 16GB, I cannot increase its processing power memory, then there is horizontal scaling, horizontal scaling is like adding more hardware to the existing system and not a particular server, so it's like adding more buildings to the neighborhood, the only limitation we face because horizontal scaling is splitting up data, so if we are using SQL, it becomes difficult to split the data and that's why horizontal scaling is difficult for low SQL, now let's see why you should go with SQL, so schema, if you have structured data and you want to have a tight schema, then you should go with SQL, relations, so if there are a lot of relations, like if you have a table for orders, if you have a table of products and then you have a table of users, so you store only the particular information that you need, like for orders we store the product ID, the user ID and the quantity, so what it does is this also reduces the duplications, so yeah, and fast join, so if you want to join the tables, SQL provides fast join, that was about SQL, now but why, if we want to go to low SQL, why we should go with low SQL, low SQL provides scalability, it can have both vertical and horizontal scaling, there is a simple data model like this one, there is another dynamic schema, so you don't have to have a particular structure for data, and low-intensity high performance are the best features for no SQL, now let's see the examples, like which companies are using SQL and no SQL, so this is booking.com, booking.com uses my SQL, they use it for browsing, reservation managing, pay match, analytics, and in the Intel system too, so what benefit they found with SQL is that they use relational models, so it makes it very convenient for them and easy for them to run complex queries with SQL, then there is Shavan, Shavan is a music streaming service, it's very popular in India, and they have catalogs for more than 75 languages, they use MongoDB, they use MongoDB because features like horizontal scaling, flexible schema, and high availability, this has helped them with tremendous growth, they store users, they store users covert, and then they set highly targeted push notifications, so this is why they go with no SQL because it helps them to do real-time data analysis, so still the question is what you should go with, SQL or no SQL, I don't want any of you to be like this, so you need to before building your project, you need to ask yourself, do you have structured data, do you need a clear schema, and do you use a lot of relations, if the answer for all these questions is yes, then you should go with SQL, but before going to debt, you should also ask this question to yourself, do you need to perform a lot of real-time rights, does scaling really matter to you, and do you need real-time analysis, and if the answer to all these questions is yes, then you should go with no SQL, so let's have a quick overview, SQL has schema and no SQL has schema rest, SQL with SQL you can have relations, with no SQL you can have like very few or no relations, SQL is very difficult to do horizontal scaling, but vertical scaling is possible, with no SQL both horizontal and vertical scaling is possible, and there are huge limitations for read and write queries per second with SQL, and no SQL provides great performance for thousands of read and write queries per second, that's it, thank you, questions?


This is an introduction to a rant. The rant follows the introduction.  My name is Sam Dutney and I'm the author of Malignance of Love, Narcissism Revisited and a Ranting Professor of Psychology. A few weeks ago a prestigious media outlet had modified an article I've written about narcissism. The reason to castigate narcissists, to present them or cast them as predators, is a form of ableism, a discrimination against the disabled. You see, narcissists are disabled. It's not nice to say not nice things about them because they are disabled. Yes, I said they are disabled, but they're also predators. For example, we attack viruses. We cast viruses is in a way malignant, dangerous. This is not a form of speciesism. It's not a form of discriminating against another living species. It's just a fact. Viruses are dangerous. Very often they are deadly. It's the same with narcissists. They are dangerous. They are predators. The fact that they are disabled has nothing to do with it. And so this narcissistic virtue signalling, you know, ableism or avoiding ableism is a rank form of stupidity. Stupidity is taking over the world. Before we go there an announcement. There's a seven days free seminar. I'm giving a seven days free seminar in Turno Severin, Turnu Severin, which is a fairy tale town in Romania. And so it's September 19th to September 25th. There are a few seats left. I advise you to register if you want to attend. Now, during the seminar, I'm going to be in Turno Severin starting on September 18th and well into September 28th. During the seminar and the days before and after the seminar, I'm available available to give in person counseling. So if you're interested, contact me. If you want me to reserve a seat in the seminar for you, contact me. Contact me in any case. Sam Vaknin, that's my name, one word, small letters, Sam Vaknin at gmail.com. Write to me, I'll reserve a seat for you and let me know if you're interested in in-person counseling.   That's been the case in the Middle Ages. That's been the case in the ancient world.   They were careful. They were cautious. They were afraid to express these opinions lest they be shamed, ridiculed and shunned by their betters.  They knew that if they were to venture out and offer their inane opinions or judgments or ideas, they would be put down metaphorically and sometimes physically. So they were afraid. They kept their counsel to themselves. But this is no longer the case.  They are vociferous. They drown out by sheer force of numbers, all the other informed intelligent voices.  They trust their own pitiable life experience over science. They adhere to magical thinking and they are fierce. In the defense of their grandiose, inflated, fantastic self-image is undiscovered geniuses. This is called by the way the Dunning Kruger effect. And I have a video dedicated to it.  They think they are very clever. Many of them believe themselves to be geniuses.  Technology empowers mediocre failures.  Technology engenders a self-delusion of malignant egalitarianism. We're all equal to each other in terms of our endowments, intellectual and otherwise. Access to raw information is not the same as position of structured knowledge.   I know more than my professor or my therapist because I can Google. My opinions therefore count as facts. More and more we hear these claims. Truthism. My facts and your facts. I've come across an amazing thread in a forum where someone said the battle of Hastings took place in 1066. And another guy answered that's only your opinion. My opinion is different. Stupidity is on the rise. And it is on the rise for two reasons. Number one, a reverse Flynn effect. A reverse Flynn effect that has been a precipitous decline in average IQ scores in the past four decades. Yes, contrary to online nonsense, there's been a decline in IQ, not a rise in IQ. The Flynn effect has been effectively reversed in the 1980s. And the decline is massive in some countries. For example, Norway and other countries, the decline equals something like 10%. The second reason why stupidity is on the rise is that inanity is tolerated. Stupidity is legitimized. We tolerate the dumb. And we encourage indolence, entitlement, niche ignorance. We say, you know, everyone is entitled to have their own lifestyle, their own choices. We tolerate every personality. We accept any way of life. This is malignant tolerance. Malignant tolerance is anything goes and everything goes. No boundaries, no values, no beliefs, no guiding principles. Nothing, anything goes. That's malignant tolerance. And so we tend to tolerate and legitimize stupidity. And there's a very big corpus body of knowledge in psychology, sociology, anthropology and similar sizes, which concludes definitively that when we tolerate and legitimize a behavior or trait, the incidents and prevalence of these behaviors and traits tend to skyrocket. Societal legitimacy, peer, peer tolerance, encourage specific behaviors. They provide what we call positive reinforcements.  Now the way I see it, stupidity is a form of assault. What is assault? What is rape? Rape is the invasion of your body without consent. Any part of your body could be your genitalia, but could also be your brain.  Ambient noise pollution is auditory rape. The great unwashed is olfactory rape. Unwanted touch, invasion of private space are tactile rape. Not fully consensual sex. Is rape pure and simple? All forms of abuse constitute emotional rape.  It's an intellectual rape.  Rape should be criminalized in all its forms. Rape should be penalized in all its forms. The perpetrators should be relegated to penal colonies, virtual or otherwise. Otherwise, otherwise. Because if we don't, we may end up in idiocracy. Watch this movie. It's a portent of the future. It's a dystopian view, which is fast becoming reality. And so now on to the rant, as promised. Yes, this has been not only the introduction. Poor you.   So they are willing to take on the world without fear of the consequences of their actions that makes them better entrepreneurs, better businessmen, better politicians.  That's a fact established in numerous studies. So their reproductive success is much higher.    And so we are heading into the age of stupidity, idiocracy.    Intelligence and intellect will be outsourced technologically into our devices. The only smart things in our lives will be the smartphone. I, of course, am terrified by the veracity of these claims. I wish I could say that this is tongue in cheek. It is not. Humanity is under an imminent danger, an imminent threat of being overrun by idiots, diluted by imbeciles. And this risk is growing by the day. And so we are submerged by a tidal wave of retardation. We often confuse technology with culture and civilization with progress. Nazi Germany is proof that such reflexive linkages are spurious. In Nazi Germany, technology was at the apex. And yet they were barbarians.  In truth, we have become barbarians with iPads and iPhones. We use the latest innovations to play Angry Birds or whatever it is that we play nowadays. And to watch inane videos on YouTube and to exchange trivialities on Facebook. Traits are not desirable or undesirable in themselves. Traits, qualities, properties, characteristics of the organism, the phenotype, the genotype, the psychology of the organism. These are advantageous, adaptive, or they are detrimental depending on the environment. That's all. The environment determines which traits will survive and which will not. Traits that afford you reproductive success. Traits and qualities and skills and talents that allow you to have children make sure that you will propagate your genes. These survive. And in today's world, if you're intelligent, your chances of reproducing are much lower. Women prefer men with an IQ lower than 120 to men with an IQ higher than 145. Not that these are the results of a study published two years ago, several years ago.  Why is that?  It's governed by the feeble-minded. Dimwits are empowered by technology and everything is dumbed down to foster mass consumption. Education is a mismomer. Higher education institutions teach how to have fun, how to go on hookups, basically, and how to gain the system to obtain a degree which is pretty much useless in later life. And of course, how to make student debt. This is the world we live in. And women select for better males, as the monosphere calls them. Women select for inferior men because in the current environment, better traits are preferable to alpha traits. In the current environment, what used to be inferiority is an evolutionary advantage, a positive adaptation. Stupidity is a case in point. It is a paradigm shift of mind-bending proportions for those of us in possession of a mind. A study of one million young adults over 40 years, that's four zero years, conducted by Jean Twenge and her colleagues and published in the March 2012 issue of the Journal of Personality and Social Psychology, this study rocked me, shocked me. It has starkly demonstrated the deterioration from one generation to another. Youngsters today, according to this study, are focused on money, image, and fame, and they disparage values such as community, volunteerism, the environment, and knowledge acquisition. Ostentatious social activism is a form of virtual signaling. These youngers are socially active, demand justice and must protest on camera. They're posing, they're faking, they're out to garner likes and attention. Other surveys have documented a rising level of illiteracy in the newer, in the younger generations. Many of them are unable to read a label on a bottle or a medicine. As if to illustrate the imminence of these new, dark ages, the Encyclopedia Britannica and others, Newsweek and so on, announced that they will seize publication of their print editions. Encyclopedia Britannica has survived for 244 years, but it did not survive the tsunami of idiocy and stupidity and intellectually challenged readers, so to speak. The surviving digital editions of the Britannica are a far cry from the print equivalent in terms of depth, length, and irredition.    And the cacophony of these constituencies of intellectually challenged people, their cacophony drowns the few voices of wisdom, expertise, and experience.  Rather than fight back this tsunami, which is futile, the well-educated, the irredite, and the intelligent choose to withdraw. They avoid the world, they seclude themselves in self-constructed schizoid ivy towers, and they draw all the bridges.  We may end up being all homo, no sapiens.  There's been a drop of seven points in global IQ since the 1950s.  Modern medicine makes sure that they intellectually challenge the plain dim-witted, live on to a ripe old age and reproduce. That we are faced with the daunting prospect of idiocracy is the fault of the malignant transformation of the democratic ideal and the recent onslaught of the media, both old and new.  In the not too distant past, dim-witted people had the right to vote once in a while and thus expressed their completely inconsequential opinion where it mattered least in the ballot box.  Alas, the inane idea of one person, one vote has invaded and permeated either two hierarchical environments such as government, the workplace and the military.   You know what I mean? This is unbelievably idiotic, these malignant egalitarians. People should not have the right, the equal right to vote. People should not have equal rights period because people are not equal. With technology at their disposal, the stupids repeatedly interfere with and disrupt the proper functioning of virtually every system, every institution, every process. Even the generation and transfer of knowledge have been democratized as crowdsourcing yielded enterprises such as Wikipedia, the so-called encyclopedia that anyone can edit, add to delete from and generally vandalize. Internet search engines rank results not according to the quality of the content, the merits and authority of the author. No, they rank the results by the number of votes, by the number of views, by the number of likes, and these votes and these views and these likes come from, they are cast by, you guessed it, mostly dense people, mostly stupid people who now congregate on social networks.  This widespread and much-loaded vandalism of human knowledge and even human information, this information is the raw material for knowledge. There's a vandalism going on which reflects the utter collapse and disintegration of the education system. Our education system turns out illiterate, niche and irrational graduates having annihilated these standards in order to lucratively embrace them as students in the first place. And so we have honorary doctorates. Taylor Swift is the new PhD, the stupid, dimly aware of their innate inferiority.  But while in the past these remained only sentiments, today they have become an ethos, a code of conduct, a set of values and ideals embodied or reified in the walk movements, for example, in political correctness. It is politically incorrect and impolitic and impolite to claim any advantage, any superiority.   And so they are victimized. Egalitarianism is running a muck. Everyone is equal, the doctor, the medical doctor and his patient. They're negotiating, they're talking as equals, they're not equals. Professors and their students, the students dictate to the professor what to teach and how to teach. Experts and laymen, the layman says, it's only your opinion. Expertise is just another opinion equal to anyone else's. This is beyond sick, this is dangerous, this is counterfactual of course. People are not equal.  End of story, I'm not interested in your opinion. I would of course be interested in your opinion if you acquire an education equal to mine, but not a minute before. And even then, if I'm more clever than you, if I have a higher IQ, you should still shut up and listen to me and learn from me, because you are not my equal.   There, the intellectually challenged could safely torment each other with their vulgarities and rampant uninformed idiocy. In these settlements, establishments, enclaves, prison islands, call them whatever you wish.  We isolated their toxic impact, but the advent of the radio, television and most egregiously the internet, these technologies have changed all that.  They control the kind of technology that allows them to pollute the airwaves and the broadband in our screens with their inferior analytic capacity. Low-brow output, trivial observations, monosyllabic exclamations and harebrained queries. So the new media have transformed stupidity from a mental endemic or pandemic to a viral pandemic.   These are decimating traditional print and electronic media. And as I say, I would like to repeat this. Stupidity used to be an endemic and endemic situation, an epidemic limited to specific locations. Now it's a global viral pandemic.  The technological empowerment is the crux of the problem. There are no barriers to entry, no gatekeepers, no institutional filters, no erudite and experience intermediaries or moderators to hold back the avalanche of doltish bladder dash, boulder dash, the tsunami of nonsense, the flood of misinformation, factories and conspiracies that corrupt our intellectual space. There's a problem of discovery, separating the wheat from the shaft. It's a mission impossible. You can't tell apart the pearls from the trash they're buried in. Millions of books, so-called books are published by Amazon every year. 99.9999 and I don't know how many minds of them should have never been published. Or in the best tradition should have been, should be burned. Because they make it impossible to find the 100 truly good qualitative books that are published simultaneously. Commercial interests inevitably and invariably side with the brainless masses. Because the brainless masses have a much bigger aggregate purchasing power. The privatization of education is one manifestation of this creeping decadence. The mindless nature of television programming is another example. Video games. The empty one-liners that comprise most conversations on social networks are the culmination of this. We are surrounded with clothes harassed by the lame brain, criticized, censored and ordered by simpletons. This may be the new Dark Ages, but we have hit a new low because the original Dark Ages were still controlled by intellectual elites of the church. The elite of the church for example, educated clergymen. These new Dark Ages are controlled by the peasants. The peasants have revolted, the sewer had exploded and we are all floating in, you know what.